Internet Engineering Task Force (IETF)                           A. Jain
Request for Comments: 8129                                  Georgia Tech
Updates: 4120                                                  N. Kinder
Category: Standards Track                                    N. McCallum
ISSN: 2070-1721                                            Red Hat, Inc.
                                                              March 2017
        
Internet Engineering Task Force (IETF)                           A. Jain
Request for Comments: 8129                                  Georgia Tech
Updates: 4120                                                  N. Kinder
Category: Standards Track                                    N. McCallum
ISSN: 2070-1721                                            Red Hat, Inc.
                                                              March 2017
        

Authentication Indicator in Kerberos Tickets

Kerberos票据中的身份验证指示符

Abstract

摘要

This document updates RFC 4120, as it specifies an extension in the Kerberos protocol. It defines a new authorization data type, AD-AUTHENTICATION-INDICATOR. The purpose of introducing this data type is to include an indicator of the strength of a client's authentication in service tickets so that application services can use it as an input into policy decisions.

本文档更新了RFC4120,因为它在Kerberos协议中指定了一个扩展。它定义了一种新的授权数据类型AD-AUTHENTICATION-INDICATOR。引入此数据类型的目的是在服务票据中包含客户端身份验证强度的指标,以便应用程序服务可以将其用作策略决策的输入。

Status of This Memo

关于下段备忘

This is an Internet Standards Track document.

这是一份互联网标准跟踪文件。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。有关互联网标准的更多信息,请参见RFC 7841第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8129.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc8129.

Copyright Notice

版权公告

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2017 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents

目录

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Document Conventions  . . . . . . . . . . . . . . . . . . . .   2
   3.  AD Type Specification . . . . . . . . . . . . . . . . . . . .   2
   4.  Assigned Numbers  . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6
        
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Document Conventions  . . . . . . . . . . . . . . . . . . . .   2
   3.  AD Type Specification . . . . . . . . . . . . . . . . . . . .   2
   4.  Assigned Numbers  . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6
        
1. Introduction
1. 介绍

Kerberos [RFC4120] allows secure interaction among users and services over a network. It supports a variety of authentication mechanisms using its pre-authentication framework [RFC6113]. The Kerberos authentication service has been architected to support password-based authentication as well as multi-factor authentication using one-time password devices, public-key cryptography, and other pre-authentication schemes. Implementations that offer pre-authentication mechanisms supporting significantly different strengths of client authentication may choose to keep track of the strength of the authentication that was used, for use as an input into policy decisions.

Kerberos[RFC4120]允许用户和服务通过网络进行安全交互。它使用预认证框架[RFC6113]支持多种认证机制。Kerberos身份验证服务的体系结构支持基于密码的身份验证以及使用一次性密码设备、公钥加密和其他预身份验证方案的多因素身份验证。提供预身份验证机制以支持显著不同的客户端身份验证强度的实现可以选择跟踪所使用的身份验证强度,以作为策略决策的输入。

This document specifies a new authorization data type to convey authentication strength information to application services. Elements of this type appear within an AD-CAMMAC (Authorization Data type Container Authenticated by Multiple Message Authentication Codes) [RFC7751] container.

本文档指定了一种新的授权数据类型,用于向应用程序服务传递身份验证强度信息。此类型的元素出现在AD-CAMMAC(由多个消息身份验证码验证的授权数据类型容器)[RFC7751]容器中。

2. Document Conventions
2. 文件惯例

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。

3. AD Type Specification
3. AD类型规范

The Key Distribution Center (KDC) MAY include authorization data of ad-type 97, wrapped in AD-CAMMAC, in initial credentials. The KDC MAY copy it from a ticket-granting ticket into service tickets.

密钥分发中心(KDC)可以在初始凭证中包括封装在ad-CAMMAC中的ad类型97的授权数据。KDC可以将其从票据授予票据复制到服务票据中。

The corresponding ad-data field contains the DER encoding [X.690] of the following ASN.1 [X.680] type:

对应的ad数据字段包含以下ASN.1[X.680]类型的DER编码[X.690]:

   AD-AUTHENTICATION-INDICATOR ::= SEQUENCE OF UTF8String
        
   AD-AUTHENTICATION-INDICATOR ::= SEQUENCE OF UTF8String
        

Each UTF8String value is a short string that indicates that a particular set of requirements was met during the initial authentication. These strings are intended to be compared against known values. They are not intended to store structured data. Each string MUST be either:

每个UTF8String值都是一个短字符串,表示在初始身份验证期间满足了一组特定的要求。这些字符串旨在与已知值进行比较。它们不用于存储结构化数据。每个字符串必须是:

o A URI that references a Level of Assurance Profile [RFC6711], or

o 引用保证级别概要文件[RFC6711]的URI,或

o A site-defined string, which MUST NOT contain a colon, whose meaning is determined by the realm administrator.

o 站点定义的字符串,不得包含冒号,其含义由领域管理员确定。

Authorization data elements of type AD-AUTHENTICATION-INDICATOR MUST be included in an AD-CAMMAC container so that their contents can be verified as originating from the KDC. Elements of type AD-AUTHENTICATION-INDICATOR MAY safely be ignored by applications and KDCs that do not implement this element.

AD-AUTHENTICATION-INDICATOR类型的授权数据元素必须包含在AD-CAMMAC容器中,以便验证其内容是否源自KDC。AD-AUTHENTICATION-INDICATOR类型的元素可以被未实现此元素的应用程序和KDC安全地忽略。

4. Assigned Numbers
4. 指定号码

RFC 4120 [RFC4120] is updated in the following way:

RFC 4120[RFC4120]按以下方式更新:

o The ad-type number 97 is assigned for AD-AUTHENTICATION-INDICATOR, updating the table in Section 7.5.4 of RFC 4120 [RFC4120].

o ad类型编号97分配给ad-AUTHENTICATION-INDICATOR,更新RFC 4120[RFC4120]第7.5.4节中的表格。

o The table in Section 5.2.6 of RFC 4120 [RFC4120] is updated to map the ad-type 97 to "DER encoding of AD-AUTHENTICATION-INDICATOR".

o 更新RFC 4120[RFC4120]第5.2.6节中的表格,以将ad类型97映射为“ad-AUTHENTICATION-INDICATOR的DER编码”。

5. Security Considerations
5. 安全考虑

Elements of type AD-AUTHENTICATION-INDICATOR are wrapped in AD-CAMMAC containers. AD-CAMMAC supersedes AD-KDC-ISSUED and allows both application services and the KDC to verify the authenticity of the contained authorization data.

AD-AUTHENTICATION-INDICATOR类型的元素包装在AD-CAMMAC容器中。AD-CAMMAC取代AD-KDC-ISTED,并允许应用程序服务和KDC验证包含的授权数据的真实性。

KDC implementations MUST use AD-CAMMAC verifiers as described in the security considerations of RFC 7751 [RFC7751] to ensure that AD-AUTHENTICATION-INDICATOR elements are not modified by an attacker. Application servers MUST validate the AD-CAMMAC container before making authorization decisions based on AD-AUTHENTICATION-INDICATOR elements. Application servers MUST NOT make authorization decisions based on AD-AUTHENTICATION-INDICATOR elements that appear outside of AD-CAMMAC containers.

KDC实现必须使用RFC 7751[RFC7751]安全注意事项中所述的AD-CAMMAC验证器,以确保AD-AUTHENTICATION-INDICATOR元素不会被攻击者修改。在根据AD-AUTHENTICATION-INDICATOR元素做出授权决策之前,应用程序服务器必须验证AD-CAMMAC容器。应用程序服务器不得基于AD-CAMMAC容器外部出现的AD-AUTHENTICATION-INDICATOR元素做出授权决策。

Using multiple strings in AD-AUTHENTICATION-INDICATOR may lead to ambiguity when a service tries to make a decision based on the AD-AUTHENTICATION-INDICATOR values. This ambiguity can be avoided if indicator values are always used as a positive indication of certain requirements being met during the initial authentication. For example, if a "without-password" indicator is inserted whenever authentication occurs without a password, a service might assume this is an indication that a higher-strength client authentication occurred. However, this indicator might also be inserted when no authentication occurred at all (such as anonymous PKINIT).

当服务尝试基于AD-AUTHENTICATION-INDICATOR值做出决策时,在AD-AUTHENTICATION-INDICATOR中使用多个字符串可能会导致歧义。如果指标值始终用作初始认证期间满足某些要求的积极指示,则可以避免这种模糊性。例如,如果在没有密码的情况下进行身份验证时插入“无密码”指示符,则服务可能会认为这表示发生了更高强度的客户端身份验证。但是,当根本没有进行身份验证(例如匿名PKINIT)时,也可以插入此指示符。

Application service evaluation of site-defined indicators MUST consider the realm of original authentication in order to avoid cross-realm indicator collisions. Failure to enforce this property can result in invalid authorization decisions.

站点定义指示符的应用服务评估必须考虑原始认证的范围,以避免跨域指示符冲突。未能强制执行此属性可能会导致无效的授权决策。

6. IANA Considerations
6. IANA考虑

This document does not require any IANA actions.

本文件不要求IANA采取任何行动。

7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,DOI 10.17487/RFC2119,1997年3月<http://www.rfc-editor.org/info/rfc2119>.

[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, <http://www.rfc-editor.org/info/rfc4120>.

[RFC4120]Neuman,C.,Yu,T.,Hartman,S.,和K.Raeburn,“Kerberos网络身份验证服务(V5)”,RFC 4120,DOI 10.17487/RFC4120,2005年7月<http://www.rfc-editor.org/info/rfc4120>.

[RFC6113] Hartman, S. and L. Zhu, "A Generalized Framework for Kerberos Pre-Authentication", RFC 6113, DOI 10.17487/RFC6113, April 2011, <http://www.rfc-editor.org/info/rfc6113>.

[RFC6113]Hartman,S.和L.Zhu,“Kerberos预认证的通用框架”,RFC 6113,DOI 10.17487/RFC6113,2011年4月<http://www.rfc-editor.org/info/rfc6113>.

[RFC7751] Sorce, S. and T. Yu, "Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs)", RFC 7751, DOI 10.17487/RFC7751, March 2016, <http://www.rfc-editor.org/info/rfc7751>.

[RFC7751]Sorce,S.和T.Yu,“通过多个消息身份验证码(MAC)进行身份验证的Kerberos授权数据容器”,RFC 7751,DOI 10.17487/RFC7751,2016年3月<http://www.rfc-editor.org/info/rfc7751>.

[X.680] ITU-T, "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC International Standard 8824-1:2008, November 2008.

[X.680]ITU-T,“信息技术——抽象语法符号1(ASN.1):基本符号规范”,ITU-T建议X.680,ISO/IEC国际标准8824-1:2008,2008年11月。

[X.690] ITU-T, "Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC International Standard 8825-1:2008, November 2008.

[X.690]ITU-T,“信息技术——ASN.1编码规则:基本编码规则(BER)、规范编码规则(CER)和区分编码规则(DER)规范”,ITU-T建议X.690,ISO/IEC国际标准8825-1:2008,2008年11月。

7.2. Informative References
7.2. 资料性引用

[RFC6711] Johansson, L., "An IANA Registry for Level of Assurance (LoA) Profiles", RFC 6711, DOI 10.17487/RFC6711, August 2012, <http://www.rfc-editor.org/info/rfc6711>.

[RFC6711]Johansson,L.“IANA保证水平(LoA)档案注册”,RFC 6711,DOI 10.17487/RFC671112012年8月<http://www.rfc-editor.org/info/rfc6711>.

Appendix A. ASN.1 Module
附录A.ASN.1模块
   KerberosV5AuthenticationIndicators {
           iso(1) identified-organization(3) dod(6) internet(1)
           security(5) kerberosV5(2) modules(4)
           authentication-indicators(9)
   } DEFINITIONS EXPLICIT TAGS ::= BEGIN
        
   KerberosV5AuthenticationIndicators {
           iso(1) identified-organization(3) dod(6) internet(1)
           security(5) kerberosV5(2) modules(4)
           authentication-indicators(9)
   } DEFINITIONS EXPLICIT TAGS ::= BEGIN
        
   AD-AUTHENTICATION-INDICATOR ::= SEQUENCE OF UTF8String
        
   AD-AUTHENTICATION-INDICATOR ::= SEQUENCE OF UTF8String
        

END

终止

Acknowledgements

致谢

Dmitri Pal (Red Hat) Simo Sorce (Red Hat) Greg Hudson (MIT)

德米特里·帕尔(红帽)西莫·索斯(红帽)格雷格·哈德森(麻省理工)

Authors' Addresses

作者地址

Anupam Jain Georgia Tech 225 North Ave NW Atlanta, GA 30332 United States of America

美国佐治亚州亚特兰大西北北大街225号,邮编30332

   Email: ajain323@gatech.edu
        
   Email: ajain323@gatech.edu
        

Nathan Kinder Red Hat, Inc. 444 Castro St. Suite 500 Mountain View, CA 94041 United States of America

美国加利福尼亚州山景城卡斯特罗街444号500室Nathan Kinder Red Hat,Inc.94041

   Email: nkinder@redhat.com
        
   Email: nkinder@redhat.com
        

Nathaniel McCallum Red Hat, Inc. 100 East Davie Street Raleigh, NC 27601 United States of America

美国北卡罗来纳州罗利市东戴维斯街100号Nathaniel McCallum Red Hat公司,邮编:27601

   Email: npmccallum@redhat.com
        
   Email: npmccallum@redhat.com