Network Working Group C. Neuman
Request for Comments: 4120 USC-ISI
Obsoletes: 1510 T. Yu
Category: Standards Track S. Hartman
K. Raeburn
MIT
July 2005
Network Working Group C. Neuman
Request for Comments: 4120 USC-ISI
Obsoletes: 1510 T. Yu
Category: Standards Track S. Hartman
K. Raeburn
MIT
July 2005
The Kerberos Network Authentication Service (V5)
Kerberos网络身份验证服务（V5）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的《互联网官方协议标准》（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document provides an overview and specification of Version 5 of the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC 1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages.
本文档提供了Kerberos协议版本5的概述和规范，并淘汰了RFC 1510，以澄清协议及其预期用途的各个方面，这些方面需要比RFC 1510中提供的更详细或更清晰的解释。本文件旨在提供适用于实施的协议的详细说明，以及协议消息的适当使用说明和这些消息中的字段。
Table of Contents
目录
1. Introduction ....................................................5
1.1. The Kerberos Protocol ......................................6
1.2. Cross-Realm Operation ......................................8
1.3. Choosing a Principal with Which to Communicate .............9
1.4. Authorization .............................................10
1.5. Extending Kerberos without Breaking Interoperability ......11
1.5.1. Compatibility with RFC 1510 ........................11
1.5.2. Sending Extensible Messages ........................12
1.6. Environmental Assumptions .................................12
1.7. Glossary of Terms .........................................13
2. Ticket Flag Uses and Requests ..................................16
2.1. Initial, Pre-authenticated, and
Hardware-Authenticated Tickets ............................17
2.2. Invalid Tickets ...........................................17
2.3. Renewable Tickets .........................................17
2.4. Postdated Tickets .........................................18
2.5. Proxiable and Proxy Tickets ...............................19
2.6. Forwardable Tickets .......................................19
2.7. Transited Policy Checking .................................20
2.8. OK as Delegate ............................................21
2.9. Other KDC Options .........................................21
2.9.1. Renewable-OK .......................................21
2.9.2. ENC-TKT-IN-SKEY ....................................22
2.9.3. Passwordless Hardware Authentication ...............22
3. Message Exchanges ..............................................22
3.1. The Authentication Service Exchange .......................22
3.1.1. Generation of KRB_AS_REQ Message ...................24
3.1.2. Receipt of KRB_AS_REQ Message ......................24
3.1.3. Generation of KRB_AS_REP Message ...................24
3.1.4. Generation of KRB_ERROR Message ....................27
3.1.5. Receipt of KRB_AS_REP Message ......................27
3.1.6. Receipt of KRB_ERROR Message .......................28
3.2. The Client/Server Authentication Exchange .................29
3.2.1. The KRB_AP_REQ Message .............................29
3.2.2. Generation of a KRB_AP_REQ Message .................29
3.2.3. Receipt of KRB_AP_REQ Message ......................30
3.2.4. Generation of a KRB_AP_REP Message .................33
3.2.5. Receipt of KRB_AP_REP Message ......................33
3.2.6. Using the Encryption Key ...........................33
3.3. The Ticket-Granting Service (TGS) Exchange ................34
3.3.1. Generation of KRB_TGS_REQ Message ..................35
3.3.2. Receipt of KRB_TGS_REQ Message .....................37
3.3.3. Generation of KRB_TGS_REP Message ..................38
3.3.4. Receipt of KRB_TGS_REP Message .....................42
1. Introduction ....................................................5
1.1. The Kerberos Protocol ......................................6
1.2. Cross-Realm Operation ......................................8
1.3. Choosing a Principal with Which to Communicate .............9
1.4. Authorization .............................................10
1.5. Extending Kerberos without Breaking Interoperability ......11
1.5.1. Compatibility with RFC 1510 ........................11
1.5.2. Sending Extensible Messages ........................12
1.6. Environmental Assumptions .................................12
1.7. Glossary of Terms .........................................13
2. Ticket Flag Uses and Requests ..................................16
2.1. Initial, Pre-authenticated, and
Hardware-Authenticated Tickets ............................17
2.2. Invalid Tickets ...........................................17
2.3. Renewable Tickets .........................................17
2.4. Postdated Tickets .........................................18
2.5. Proxiable and Proxy Tickets ...............................19
2.6. Forwardable Tickets .......................................19
2.7. Transited Policy Checking .................................20
2.8. OK as Delegate ............................................21
2.9. Other KDC Options .........................................21
2.9.1. Renewable-OK .......................................21
2.9.2. ENC-TKT-IN-SKEY ....................................22
2.9.3. Passwordless Hardware Authentication ...............22
3. Message Exchanges ..............................................22
3.1. The Authentication Service Exchange .......................22
3.1.1. Generation of KRB_AS_REQ Message ...................24
3.1.2. Receipt of KRB_AS_REQ Message ......................24
3.1.3. Generation of KRB_AS_REP Message ...................24
3.1.4. Generation of KRB_ERROR Message ....................27
3.1.5. Receipt of KRB_AS_REP Message ......................27
3.1.6. Receipt of KRB_ERROR Message .......................28
3.2. The Client/Server Authentication Exchange .................29
3.2.1. The KRB_AP_REQ Message .............................29
3.2.2. Generation of a KRB_AP_REQ Message .................29
3.2.3. Receipt of KRB_AP_REQ Message ......................30
3.2.4. Generation of a KRB_AP_REP Message .................33
3.2.5. Receipt of KRB_AP_REP Message ......................33
3.2.6. Using the Encryption Key ...........................33
3.3. The Ticket-Granting Service (TGS) Exchange ................34
3.3.1. Generation of KRB_TGS_REQ Message ..................35
3.3.2. Receipt of KRB_TGS_REQ Message .....................37
3.3.3. Generation of KRB_TGS_REP Message ..................38
3.3.4. Receipt of KRB_TGS_REP Message .....................42
3.4. The KRB_SAFE Exchange .....................................42
3.4.1. Generation of a KRB_SAFE Message ...................42
3.4.2. Receipt of KRB_SAFE Message ........................43
3.5. The KRB_PRIV Exchange .....................................44
3.5.1. Generation of a KRB_PRIV Message ...................44
3.5.2. Receipt of KRB_PRIV Message ........................44
3.6. The KRB_CRED Exchange .....................................45
3.6.1. Generation of a KRB_CRED Message ...................45
3.6.2. Receipt of KRB_CRED Message ........................46
3.7. User-to-User Authentication Exchanges .....................47
4. Encryption and Checksum Specifications .........................48
5. Message Specifications .........................................50
5.1. Specific Compatibility Notes on ASN.1 .....................51
5.1.1. ASN.1 Distinguished Encoding Rules .................51
5.1.2. Optional Integer Fields ............................52
5.1.3. Empty SEQUENCE OF Types ............................52
5.1.4. Unrecognized Tag Numbers ...........................52
5.1.5. Tag Numbers Greater Than 30 ........................53
5.2. Basic Kerberos Types ......................................53
5.2.1. KerberosString .....................................53
5.2.2. Realm and PrincipalName ............................55
5.2.3. KerberosTime .......................................55
5.2.4. Constrained Integer Types ..........................55
5.2.5. HostAddress and HostAddresses ......................56
5.2.6. AuthorizationData ..................................57
5.2.7. PA-DATA ............................................60
5.2.8. KerberosFlags ......................................64
5.2.9. Cryptosystem-Related Types .........................65
5.3. Tickets ...................................................66
5.4. Specifications for the AS and TGS Exchanges ...............73
5.4.1. KRB_KDC_REQ Definition .............................73
5.4.2. KRB_KDC_REP Definition .............................81
5.5. Client/Server (CS) Message Specifications .................84
5.5.1. KRB_AP_REQ Definition ..............................84
5.5.2. KRB_AP_REP Definition ..............................88
5.5.3. Error Message Reply ................................89
5.6. KRB_SAFE Message Specification ............................89
5.6.1. KRB_SAFE definition ................................89
5.7. KRB_PRIV Message Specification ............................91
5.7.1. KRB_PRIV Definition ................................91
5.8. KRB_CRED Message Specification ............................92
5.8.1. KRB_CRED Definition ................................92
5.9. Error Message Specification ...............................94
5.9.1. KRB_ERROR Definition ...............................94
5.10. Application Tag Numbers ..................................96
3.4. The KRB_SAFE Exchange .....................................42
3.4.1. Generation of a KRB_SAFE Message ...................42
3.4.2. Receipt of KRB_SAFE Message ........................43
3.5. The KRB_PRIV Exchange .....................................44
3.5.1. Generation of a KRB_PRIV Message ...................44
3.5.2. Receipt of KRB_PRIV Message ........................44
3.6. The KRB_CRED Exchange .....................................45
3.6.1. Generation of a KRB_CRED Message ...................45
3.6.2. Receipt of KRB_CRED Message ........................46
3.7. User-to-User Authentication Exchanges .....................47
4. Encryption and Checksum Specifications .........................48
5. Message Specifications .........................................50
5.1. Specific Compatibility Notes on ASN.1 .....................51
5.1.1. ASN.1 Distinguished Encoding Rules .................51
5.1.2. Optional Integer Fields ............................52
5.1.3. Empty SEQUENCE OF Types ............................52
5.1.4. Unrecognized Tag Numbers ...........................52
5.1.5. Tag Numbers Greater Than 30 ........................53
5.2. Basic Kerberos Types ......................................53
5.2.1. KerberosString .....................................53
5.2.2. Realm and PrincipalName ............................55
5.2.3. KerberosTime .......................................55
5.2.4. Constrained Integer Types ..........................55
5.2.5. HostAddress and HostAddresses ......................56
5.2.6. AuthorizationData ..................................57
5.2.7. PA-DATA ............................................60
5.2.8. KerberosFlags ......................................64
5.2.9. Cryptosystem-Related Types .........................65
5.3. Tickets ...................................................66
5.4. Specifications for the AS and TGS Exchanges ...............73
5.4.1. KRB_KDC_REQ Definition .............................73
5.4.2. KRB_KDC_REP Definition .............................81
5.5. Client/Server (CS) Message Specifications .................84
5.5.1. KRB_AP_REQ Definition ..............................84
5.5.2. KRB_AP_REP Definition ..............................88
5.5.3. Error Message Reply ................................89
5.6. KRB_SAFE Message Specification ............................89
5.6.1. KRB_SAFE definition ................................89
5.7. KRB_PRIV Message Specification ............................91
5.7.1. KRB_PRIV Definition ................................91
5.8. KRB_CRED Message Specification ............................92
5.8.1. KRB_CRED Definition ................................92
5.9. Error Message Specification ...............................94
5.9.1. KRB_ERROR Definition ...............................94
5.10. Application Tag Numbers ..................................96
6. Naming Constraints .............................................97
6.1. Realm Names ...............................................97
6.2. Principal Names .......................................... 99
6.2.1. Name of Server Principals .........................100
7. Constants and Other Defined Values ............................101
7.1. Host Address Types .......................................101
7.2. KDC Messaging: IP Transports .............................102
7.2.1. UDP/IP transport ..................................102
7.2.2. TCP/IP Transport ..................................103
7.2.3. KDC Discovery on IP Networks ......................104
7.3. Name of the TGS ..........................................105
7.4. OID Arc for KerberosV5 ...................................106
7.5. Protocol Constants and Associated Values .................106
7.5.1. Key Usage Numbers .................................106
7.5.2. PreAuthentication Data Types ......................108
7.5.3. Address Types .....................................109
7.5.4. Authorization Data Types ..........................109
7.5.5. Transited Encoding Types ..........................109
7.5.6. Protocol Version Number ...........................109
7.5.7. Kerberos Message Types ............................110
7.5.8. Name Types ........................................110
7.5.9. Error Codes .......................................110
8. Interoperability Requirements .................................113
8.1. Specification 2 ..........................................113
8.2. Recommended KDC Values ...................................116
9. IANA Considerations ...........................................116
10. Security Considerations ......................................117
11. Acknowledgements .............................................121
A. ASN.1 Module ..................................................123
B. Changes since RFC 1510 ........................................131
Normative References .............................................134
Informative References ...........................................135
6. Naming Constraints .............................................97
6.1. Realm Names ...............................................97
6.2. Principal Names .......................................... 99
6.2.1. Name of Server Principals .........................100
7. Constants and Other Defined Values ............................101
7.1. Host Address Types .......................................101
7.2. KDC Messaging: IP Transports .............................102
7.2.1. UDP/IP transport ..................................102
7.2.2. TCP/IP Transport ..................................103
7.2.3. KDC Discovery on IP Networks ......................104
7.3. Name of the TGS ..........................................105
7.4. OID Arc for KerberosV5 ...................................106
7.5. Protocol Constants and Associated Values .................106
7.5.1. Key Usage Numbers .................................106
7.5.2. PreAuthentication Data Types ......................108
7.5.3. Address Types .....................................109
7.5.4. Authorization Data Types ..........................109
7.5.5. Transited Encoding Types ..........................109
7.5.6. Protocol Version Number ...........................109
7.5.7. Kerberos Message Types ............................110
7.5.8. Name Types ........................................110
7.5.9. Error Codes .......................................110
8. Interoperability Requirements .................................113
8.1. Specification 2 ..........................................113
8.2. Recommended KDC Values ...................................116
9. IANA Considerations ...........................................116
10. Security Considerations ......................................117
11. Acknowledgements .............................................121
A. ASN.1 Module ..................................................123
B. Changes since RFC 1510 ........................................131
Normative References .............................................134
Informative References ...........................................135
This document describes the concepts and model upon which the Kerberos network authentication system is based. It also specifies Version 5 of the Kerberos protocol. The motivations, goals, assumptions, and rationale behind most design decisions are treated cursorily; they are more fully described in a paper available in IEEE communications [NT94] and earlier in the Kerberos portion of the Athena Technical Plan [MNSS87].
本文档描述了Kerberos网络身份验证系统所基于的概念和模型。它还指定Kerberos协议的版本5。大多数设计决策背后的动机、目标、假设和基本原理被粗略地处理；IEEE communications[NT94]和雅典娜技术计划[MNSS87]的Kerberos部分中提供的一篇论文对它们进行了更全面的描述。
This document is not intended to describe Kerberos to the end user, system administrator, or application developer. Higher-level papers describing Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88] are available elsewhere.
本文档无意向最终用户、系统管理员或应用程序开发人员描述Kerberos。描述Kerberos系统[NT94]第5版和记录第4版[SNS88]的高级论文可在其他地方找到。
The Kerberos model is based in part on Needham and Schroeder's trusted third-party authentication protocol [NS78] and on modifications suggested by Denning and Sacco [DS81]. The original design and implementation of Kerberos Versions 1 through 4 was the work of two former Project Athena staff members, Steve Miller of Digital Equipment Corporation and Clifford Neuman (now at the Information Sciences Institute of the University of Southern California), along with Jerome Saltzer, Technical Director of Project Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other members of Project Athena have also contributed to the work on Kerberos.
Kerberos模型部分基于Needham和Schroeder的可信第三方身份验证协议[NS78]以及Denning和Sacco[DS81]建议的修改。Kerberos版本1至4的最初设计和实施是两个以前的项目雅典娜工作人员，数字设备公司的Steve Miller和Clifford Neuman（现在在南加州大学信息科学研究所），以及Jerome Saltzer，雅典娜项目的技术总监，还有麻省理工学院校园网络经理杰弗里·席勒。雅典娜项目的许多其他成员也对Kerberos的工作做出了贡献。
Version 5 of the Kerberos protocol (described in this document) has evolved because of new requirements and desires for features not available in Version 4. The design of Version 5 was led by Clifford Neuman and John Kohl with much input from the community. The development of the MIT reference implementation was led at MIT by John Kohl and Theodore Ts'o, with help and contributed code from many others. Since RFC 1510 was issued, many individuals have proposed extensions and revisions to the protocol. This document reflects some of these proposals. Where such changes involved significant effort, the document cites the contribution of the proposer.
Kerberos协议的第5版（在本文档中描述）由于对第4版中不可用的特性的新要求和期望而有所发展。版本5的设计由Clifford Neuman和John Kohl领导，社区提供了大量投入。麻省理工学院参考实现的开发由John Kohl和Theodore Ts'o在其他许多人的帮助和贡献下在麻省理工学院领导。自RFC 1510发布以来，许多人提出了对协议的扩展和修订。本文件反映了其中一些建议。如果此类变更涉及重大努力，文件将引用投标人的贡献。
Reference implementations of both Version 4 and Version 5 of Kerberos are publicly available, and commercial implementations have been developed and are widely used. Details on the differences between Versions 4 and 5 can be found in [KNT94].
Kerberos版本4和版本5的参考实现都是公开的，商业实现已经开发并广泛使用。有关版本4和版本5之间差异的详细信息，请参见[KNT94]。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Kerberos provides a means of verifying the identities of principals, (e.g., a workstation user or a network server) on an open (unprotected) network. This is accomplished without relying on assertions by the host operating system, without basing trust on host addresses, without requiring physical security of all the hosts on the network, and under the assumption that packets traveling along the network can be read, modified, and inserted at will. Kerberos performs authentication under these conditions as a trusted third-party authentication service by using conventional (shared secret key) cryptography. Extensions to Kerberos (outside the scope of this document) can provide for the use of public key cryptography during certain phases of the authentication protocol. Such extensions support Kerberos authentication for users registered with public key certification authorities and provide certain benefits of public key cryptography in situations where they are needed.
Kerberos提供了一种在开放（不受保护）网络上验证主体（例如工作站用户或网络服务器）身份的方法。这是在不依赖主机操作系统的断言、不基于主机地址的信任、不需要网络上所有主机的物理安全以及可以随意读取、修改和插入沿网络传输的数据包的假设下实现的。Kerberos通过使用传统（共享密钥）加密技术，在这些条件下作为受信任的第三方身份验证服务执行身份验证。Kerberos扩展（不在本文档范围内）可以在身份验证协议的某些阶段提供公钥加密的使用。此类扩展支持向公钥证书颁发机构注册的用户进行Kerberos身份验证，并在需要公钥加密的情况下提供公钥加密的某些好处。
The basic Kerberos authentication process proceeds as follows: A client sends a request to the authentication server (AS) for "credentials" for a given server. The AS responds with these credentials, encrypted in the client's key. The credentials consist of a "ticket" for the server and a temporary encryption key (often called a "session key"). The client transmits the ticket (which contains the client's identity and a copy of the session key, all encrypted in the server's key) to the server. The session key (now shared by the client and server) is used to authenticate the client and may optionally be used to authenticate the server. It may also be used to encrypt further communication between the two parties or to exchange a separate sub-session key to be used to encrypt further communication. Note that many applications use Kerberos' functions only upon the initiation of a stream-based network connection. Unless an application performs encryption or integrity protection for the data stream, the identity verification applies only to the initiation of the connection, and it does not guarantee that subsequent messages on the connection originate from the same principal.
基本的Kerberos身份验证过程如下：客户端向身份验证服务器（as）发送请求，以获取给定服务器的“凭据”。AS使用这些凭据进行响应，这些凭据在客户端密钥中加密。凭据由服务器的“票证”和临时加密密钥（通常称为“会话密钥”）组成。客户机将票据（包含客户机的身份和会话密钥的副本，均在服务器密钥中加密）传输到服务器。会话密钥（现在由客户机和服务器共享）用于对客户机进行身份验证，也可以选择性地用于对服务器进行身份验证。它还可用于加密双方之间的进一步通信，或交换用于加密进一步通信的单独子会话密钥。请注意，许多应用程序仅在启动基于流的网络连接时才使用Kerberos函数。除非应用程序对数据流执行加密或完整性保护，否则身份验证仅适用于连接的启动，并且不能保证连接上的后续消息来自同一主体。
Implementation of the basic protocol consists of one or more authentication servers running on physically secure hosts. The authentication servers maintain a database of principals (i.e., users and servers) and their secret keys. Code libraries provide encryption and implement the Kerberos protocol. In order to add authentication to its transactions, a typical network application adds calls to the Kerberos library directly or through the Generic Security Services Application Programming Interface (GSS-API) described in a separate document [RFC4121]. These calls result in the transmission of the messages necessary to achieve authentication.
基本协议的实现包括在物理安全主机上运行的一个或多个身份验证服务器。身份验证服务器维护主体（即用户和服务器）及其密钥的数据库。代码库提供加密并实现Kerberos协议。为了向其事务添加身份验证，典型的网络应用程序直接或通过通用安全服务应用程序编程接口（GSS-API）向Kerberos库添加调用，如单独的文档[RFC4121]中所述。这些调用导致传输实现身份验证所需的消息。
The Kerberos protocol consists of several sub-protocols (or exchanges). There are two basic methods by which a client can ask a Kerberos server for credentials. In the first approach, the client sends a cleartext request for a ticket for the desired server to the AS. The reply is sent encrypted in the client's secret key. Usually this request is for a ticket-granting ticket (TGT), which can later be used with the ticket-granting server (TGS). In the second method, the client sends a request to the TGS. The client uses the TGT to authenticate itself to the TGS in the same manner as if it were contacting any other application server that requires Kerberos authentication. The reply is encrypted in the session key from the TGT. Though the protocol specification describes the AS and the TGS as separate servers, in practice they are implemented as different protocol entry points within a single Kerberos server.
Kerberos协议由若干子协议（或交换）组成。客户机可以通过两种基本方法向Kerberos服务器请求凭据。在第一种方法中，客户机向AS发送一个针对所需服务器的票据的明文请求。回复在客户端的密钥中加密发送。通常，此请求是针对票证授予票证（TGT），该票证授予票证可稍后与票证授予服务器（TGS）一起使用。在第二种方法中，客户机向TGS发送请求。客户机使用TGT向TGS进行身份验证，方式与联系任何其他需要Kerberos身份验证的应用程序服务器相同。应答在来自TGT的会话密钥中加密。尽管协议规范将AS和TGS描述为单独的服务器，但实际上它们是作为单个Kerberos服务器中的不同协议入口点实现的。
Once obtained, credentials may be used to verify the identity of the principals in a transaction, to ensure the integrity of messages exchanged between them, or to preserve privacy of the messages. The application is free to choose whatever protection may be necessary.
一旦获得凭证，凭证可用于验证事务中主体的身份，以确保它们之间交换的消息的完整性，或保护消息的隐私。应用程序可以自由选择任何必要的保护。
To verify the identities of the principals in a transaction, the client transmits the ticket to the application server. Because the ticket is sent "in the clear" (parts of it are encrypted, but this encryption doesn't thwart replay) and might be intercepted and reused by an attacker, additional information is sent to prove that the message originated with the principal to whom the ticket was issued. This information (called the authenticator) is encrypted in the session key and includes a timestamp. The timestamp proves that the message was recently generated and is not a replay. Encrypting the authenticator in the session key proves that it was generated by a party possessing the session key. Since no one except the requesting principal and the server know the session key (it is never sent over the network in the clear), this guarantees the identity of the client.
为了验证事务中主体的身份，客户端将票据传输到应用程序服务器。由于票据是“以明文形式”发送的（部分票据是加密的，但这种加密不会阻止重播），并且可能被攻击者截获和重新使用，因此会发送额外的信息来证明该消息是由向其发出票据的主体发出的。该信息（称为验证器）在会话密钥中加密，并包含时间戳。时间戳证明消息是最近生成的，不是重播。对会话密钥中的身份验证器进行加密可以证明它是由拥有会话密钥的一方生成的。由于除了请求主体和服务器之外，没有人知道会话密钥（它永远不会通过网络发送），这就保证了客户端的身份。
The integrity of the messages exchanged between principals can also be guaranteed by using the session key (passed in the ticket and contained in the credentials). This approach provides detection of both replay attacks and message stream modification attacks. It is accomplished by generating and transmitting a collision-proof checksum (elsewhere called a hash or digest function) of the client's message, keyed with the session key. Privacy and integrity of the messages exchanged between principals can be secured by encrypting the data to be passed by using the session key contained in the ticket or the sub-session key found in the authenticator.
主体之间交换的消息的完整性也可以通过使用会话密钥（在票据中传递并包含在凭证中）来保证。这种方法可以检测重播攻击和消息流修改攻击。它是通过生成和传输客户端消息的防冲突校验和（在别处称为散列或摘要函数）来完成的，并使用会话密钥进行键控。主体之间交换的消息的隐私性和完整性可以通过使用票据中包含的会话密钥或验证器中找到的子会话密钥加密要传递的数据来保护。
The authentication exchanges mentioned above require read-only access to the Kerberos database. Sometimes, however, the entries in the database must be modified, such as when adding new principals or changing a principal's key. This is done using a protocol between a client and a third Kerberos server, the Kerberos Administration Server (KADM). There is also a protocol for maintaining multiple copies of the Kerberos database. Neither of these protocols are described in this document.
上面提到的身份验证交换要求对Kerberos数据库进行只读访问。但是，有时必须修改数据库中的条目，例如在添加新主体或更改主体的密钥时。这是使用客户机和第三个Kerberos服务器（Kerberos管理服务器（KADM））之间的协议完成的。还有一个协议用于维护Kerberos数据库的多个副本。这两种协议均未在本文档中描述。
The Kerberos protocol is designed to operate across organizational boundaries. A client in one organization can be authenticated to a server in another. Each organization wishing to run a Kerberos server establishes its own "realm". The name of the realm in which a client is registered is part of the client's name and can be used by the end-service to decide whether to honor a request.
Kerberos协议旨在跨组织边界运行。一个组织中的客户端可以通过另一个组织中的服务器的身份验证。希望运行Kerberos服务器的每个组织都建立自己的“领域”。注册客户机的域的名称是客户机名称的一部分，终端服务可以使用该名称来决定是否接受请求。
By establishing "inter-realm" keys, the administrators of two realms can allow a client authenticated in the local realm to prove its identity to servers in other realms. The exchange of inter-realm keys (a separate key may be used for each direction) registers the ticket-granting service of each realm as a principal in the other realm. A client is then able to obtain a TGT for the remote realm's ticket-granting service from its local realm. When that TGT is used, the remote ticket-granting service uses the inter-realm key (which usually differs from its own normal TGS key) to decrypt the TGT; thus it is certain that the ticket was issued by the client's own TGS. Tickets issued by the remote ticket-granting service will indicate to the end-service that the client was authenticated from another realm.
通过建立“域间”密钥，两个域的管理员可以允许在本地域中经过身份验证的客户端向其他域中的服务器证明其身份。域间密钥的交换（每个方向可以使用单独的密钥）将每个域的票证授予服务注册为另一个域中的主体。然后，客户端可以从其本地域获取远程域的票证授予服务的TGT。当使用该TGT时，远程票证授予服务使用域间密钥（通常不同于其自身的正常TGS密钥）来解密TGT；因此，可以确定票据是由客户自己的TGS发行的。远程票证授予服务发出的票证将向终端服务指示客户端已从另一个域进行身份验证。
Without cross-realm operation, and with appropriate permission, the client can arrange registration of a separately-named principal in a remote realm and engage in normal exchanges with that realm's services. However, for even small numbers of clients this becomes cumbersome, and more automatic methods as described here are necessary.
在没有跨领域操作的情况下，在适当的许可下，客户端可以安排在远程领域中注册单独命名的主体，并与该领域的服务进行正常交换。然而，对于少量的客户机来说，这也会变得很麻烦，需要使用这里描述的更自动化的方法。
A realm is said to communicate with another realm if the two realms share an inter-realm key, or if the local realm shares an inter-realm key with an intermediate realm that communicates with the remote realm. An authentication path is the sequence of intermediate realms that are transited in communicating from one realm to another.
如果两个域共享域间密钥，或者如果本地域与与远程域通信的中间域共享域间密钥，则称域与另一个域通信。身份验证路径是在从一个域到另一个域的通信中传输的中间域序列。
Realms may be organized hierarchically. Each realm shares a key with its parent and a different key with each child. If an inter-realm key is not directly shared by two realms, the hierarchical organization allows an authentication path to be easily constructed.
领域可以分层组织。每个域与其父域共享一个密钥，与每个子域共享一个不同的密钥。如果域间密钥不是由两个域直接共享的，则分层组织允许轻松构建身份验证路径。
If a hierarchical organization is not used, it may be necessary to consult a database in order to construct an authentication path between realms.
如果不使用分层组织，则可能需要查阅数据库，以便在域之间构建身份验证路径。
Although realms are typically hierarchical, intermediate realms may be bypassed to achieve cross-realm authentication through alternate authentication paths. (These might be established to make communication between two realms more efficient.) It is important for the end-service to know which realms were transited when deciding how much faith to place in the authentication process. To facilitate this decision, a field in each ticket contains the names of the realms that were involved in authenticating the client.
尽管域通常是分层的，但可以绕过中间域，通过备用身份验证路径实现跨域身份验证。（可以建立这些域来提高两个域之间的通信效率。）对于终端服务来说，在决定对身份验证过程的信任程度时，了解哪些域被转移是很重要的。为了便于做出这一决定，每个票据中的一个字段包含验证客户机所涉及的领域的名称。
The application server is ultimately responsible for accepting or rejecting authentication and SHOULD check the transited field. The application server may choose to rely on the Key Distribution Center (KDC) for the application server's realm to check the transited field. The application server's KDC will set the TRANSITED-POLICY-CHECKED flag in this case. The KDCs for intermediate realms may also check the transited field as they issue TGTs for other realms, but they are encouraged not to do so. A client may request that the KDCs not check the transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs SHOULD honor this flag.
应用服务器最终负责接受或拒绝身份验证，并应检查传输字段。应用服务器可以选择依赖应用服务器领域的密钥分发中心（KDC）来检查传输字段。在这种情况下，应用服务器的KDC将设置TRANSITED-POLICY-CHECKED标志。中间领域的KDC也可以在为其他领域发布TGT时检查transited字段，但鼓励他们不要这样做。客户端可以通过设置DISABLE-TRANSTED-check标志请求KDCs不检查传输字段。KDC应该尊重这面旗帜。
The Kerberos protocol provides the means for verifying (subject to the assumptions in Section 1.6) that the entity with which one communicates is the same entity that was registered with the KDC using the claimed identity (principal name). It is still necessary to determine whether that identity corresponds to the entity with which one intends to communicate.
Kerberos协议提供了验证（根据第1.6节中的假设）与之通信的实体是使用声明的身份（主体名称）向KDC注册的同一实体的方法。仍然有必要确定该身份是否对应于要与之通信的实体。
When appropriate data has been exchanged in advance, the application may perform this determination syntactically based on the application protocol specification, information provided by the user, and configuration files. For example, the server principal name (including realm) for a telnet server might be derived from the user-specified host name (from the telnet command line), the "host/" prefix specified in the application protocol specification, and a mapping to a Kerberos realm derived syntactically from the domain part of the specified hostname and information from the local Kerberos realms database.
当预先交换了适当的数据时，应用可以基于应用协议规范、用户提供的信息和配置文件以语法方式执行该确定。例如，telnet服务器的服务器主体名称（包括领域）可能来自用户指定的主机名（来自telnet命令行）、应用程序协议规范中指定的“主机/”前缀，以及到Kerberos领域的映射，该领域从指定主机名的域部分语法派生，并从本地Kerberos领域数据库获取信息。
One can also rely on trusted third parties to make this determination, but only when the data obtained from the third party is suitably integrity-protected while resident on the third-party
人们也可以依靠可信的第三方来做出这一决定，但只有当从第三方获得的数据在驻留在第三方上时受到适当的完整性保护时
server and when transmitted. Thus, for example, one should not rely on an unprotected DNS record to map a host alias to the primary name of a server, accepting the primary name as the party that one intends to contact, since an attacker can modify the mapping and impersonate the party.
服务器和传输时。因此，例如，不应依赖未受保护的DNS记录将主机别名映射到服务器的主名称，接受主名称作为要联系的一方，因为攻击者可以修改映射并模拟该方。
Implementations of Kerberos and protocols based on Kerberos MUST NOT use insecure DNS queries to canonicalize the hostname components of the service principal names (i.e., they MUST NOT use insecure DNS queries to map one name to another to determine the host part of the principal name with which one is to communicate). In an environment without secure name service, application authors MAY append a statically configured domain name to unqualified hostnames before passing the name to the security mechanisms, but they should do no more than that. Secure name service facilities, if available, might be trusted for hostname canonicalization, but such canonicalization by the client SHOULD NOT be required by KDC implementations.
Kerberos和基于Kerberos的协议的实现不得使用不安全DNS查询来规范化服务主体名称的主机名组件（即，它们不得使用不安全DNS查询来将一个名称映射到另一个名称，以确定主体名称中要与之通信的主机部分）。在没有安全名称服务的环境中，应用程序作者可以在将名称传递给安全机制之前，将静态配置的域名附加到非限定主机名，但他们不应该做更多的事情。安全名称服务设施（如果可用）可能被信任用于主机名规范化，但KDC实现不需要客户端的此类规范化。
Implementation note: Many current implementations do some degree of canonicalization of the provided service name, often using DNS even though it creates security problems. However, there is no consistency among implementations as to whether the service name is case folded to lowercase or whether reverse resolution is used. To maximize interoperability and security, applications SHOULD provide security mechanisms with names that result from folding the user-entered name to lowercase without performing any other modifications or canonicalization.
实现说明：当前的许多实现都对所提供的服务名称进行了一定程度的规范化，通常使用DNS，尽管这会造成安全问题。但是，对于服务名称是按大小写折叠成小写还是使用反向解析，实现之间没有一致性。为了最大限度地提高互操作性和安全性，应用程序应提供安全机制，这些机制的名称是将用户输入的名称折叠为小写，而无需执行任何其他修改或规范化。
As an authentication service, Kerberos provides a means of verifying the identity of principals on a network. Authentication is usually useful primarily as a first step in the process of authorization, determining whether a client may use a service, which objects the client is allowed to access, and the type of access allowed for each. Kerberos does not, by itself, provide authorization. Possession of a client ticket for a service provides only for authentication of the client to that service, and in the absence of a separate authorization procedure, an application should not consider it to authorize the use of that service.
作为一种身份验证服务，Kerberos提供了一种验证网络上主体身份的方法。身份验证通常是有用的，主要是作为授权过程中的第一步，确定客户端是否可以使用服务、允许客户端访问哪些对象以及每个对象允许的访问类型。Kerberos本身并不提供授权。拥有服务的客户票只提供客户端对该服务的认证，并且在没有单独的授权过程的情况下，应用程序不应考虑它授权使用该服务。
Separate authorization methods MAY be implemented as application-specific access control functions and may utilize files on the application server, on separately issued authorization credentials such as those based on proxies [Neu93], or on other authorization services. Separately authenticated authorization credentials MAY be embedded in a ticket's authorization data when encapsulated by the KDC-issued authorization data element.
单独的授权方法可以实现为特定于应用的访问控制功能，并且可以利用应用服务器上的文件、单独颁发的授权凭证（例如基于代理[Neu93]的凭证）或其他授权服务上的文件。当由KDC颁发的授权数据元素封装时，单独认证的授权凭证可以嵌入到票据的授权数据中。
Applications should not accept the mere issuance of a service ticket by the Kerberos server (even by a modified Kerberos server) as granting authority to use the service, since such applications may become vulnerable to the bypass of this authorization check in an environment where other options for application authentication are provided, or if they interoperate with other KDCs.
应用程序不应接受Kerberos服务器（即使是经过修改的Kerberos服务器）仅颁发服务票证作为使用该服务的授权，因为在提供了其他应用程序身份验证选项的环境中，此类应用程序可能容易绕过此授权检查，或者如果它们与其他KDC互操作。
As the deployed base of Kerberos implementations grows, extending Kerberos becomes more important. Unfortunately, some extensions to the existing Kerberos protocol create interoperability issues because of uncertainty regarding the treatment of certain extensibility options by some implementations. This section includes guidelines that will enable future implementations to maintain interoperability.
随着Kerberos实现部署基础的增长，扩展Kerberos变得更加重要。不幸的是，现有Kerberos协议的某些扩展会产生互操作性问题，因为某些实现对某些扩展性选项的处理存在不确定性。本节包括一些指导原则，这些指导原则将使未来的实现能够维护互操作性。
Kerberos provides a general mechanism for protocol extensibility. Some protocol messages contain typed holes -- sub-messages that contain an octet-string along with an integer that defines how to interpret the octet-string. The integer types are registered centrally, but they can be used both for vendor extensions and for extensions standardized through the IETF.
Kerberos为协议扩展提供了一种通用机制。一些协议消息包含类型化的孔——包含八位字节字符串和定义如何解释八位字节字符串的整数的子消息。整数类型集中注册，但它们既可用于供应商扩展，也可用于通过IETF标准化的扩展。
In this document, the word "extension" refers to extension by defining a new type to insert into an existing typed hole in a protocol message. It does not refer to extension by addition of new fields to ASN.1 types, unless the text explicitly indicates otherwise.
在本文档中，“扩展”一词指的是通过定义一个新类型插入协议消息中现有类型的孔中进行扩展。除非文本中明确指出，否则它不会通过向ASN.1类型添加新字段来引用扩展。
Note that existing Kerberos message formats cannot readily be extended by adding fields to the ASN.1 types. Sending additional fields often results in the entire message being discarded without an error indication. Future versions of this specification will provide guidelines to ensure that ASN.1 fields can be added without creating an interoperability problem.
请注意，现有的Kerberos消息格式无法通过向ASN.1类型添加字段来轻松扩展。发送其他字段通常会导致丢弃整个消息，而不会显示错误。本规范的未来版本将提供指南，以确保可以添加ASN.1字段，而不会产生互操作性问题。
In the meantime, all new or modified implementations of Kerberos that receive an unknown message extension SHOULD preserve the encoding of the extension but otherwise ignore its presence. Recipients MUST NOT decline a request simply because an extension is present.
同时，接收未知消息扩展的所有新的或修改过的Kerberos实现都应该保留扩展的编码，但是忽略它的存在。收件人不得仅因为存在扩展而拒绝请求。
There is one exception to this rule. If an unknown authorization data element type is received by a server other than the ticket-granting service either in an AP-REQ or in a ticket contained in an AP-REQ, then authentication MUST fail. One of the primary uses of authorization data is to restrict the use of the ticket. If the
这条规则有一个例外。如果AP-REQ或AP-REQ中包含的票证中的票证授予服务以外的服务器接收到未知授权数据元素类型，则身份验证必须失败。授权数据的主要用途之一是限制票据的使用。如果
service cannot determine whether the restriction applies to that service, then a security weakness may result if the ticket can be used for that service. Authorization elements that are optional SHOULD be enclosed in the AD-IF-RELEVANT element.
服务无法确定该限制是否适用于该服务，如果该票证可用于该服务，则可能会导致安全漏洞。可选的授权元素应包含在AD-IF相关元素中。
The ticket-granting service MUST ignore but propagate to derivative tickets any unknown authorization data types, unless those data types are embedded in a MANDATORY-FOR-KDC element, in which case the request will be rejected. This behavior is appropriate because requiring that the ticket-granting service understand unknown authorization data types would require that KDC software be upgraded to understand new application-level restrictions before applications used these restrictions, decreasing the utility of authorization data as a mechanism for restricting the use of tickets. No security problem is created because services to which the tickets are issued will verify the authorization data.
票证授予服务必须忽略任何未知的授权数据类型，但将其传播到衍生票证，除非这些数据类型嵌入到强制的FOR-KDC元素中，在这种情况下，请求将被拒绝。此行为是适当的，因为要求票证授予服务了解未知授权数据类型将要求在应用程序使用这些限制之前升级KDC软件以了解新的应用程序级别限制，降低授权数据作为限制票据使用的机制的效用。不会产生任何安全问题，因为向其发出票据的服务将验证授权数据。
Implementation note: Many RFC 1510 implementations ignore unknown authorization data elements. Depending on these implementations to honor authorization data restrictions may create a security weakness.
实现说明：许多RFC1510实现忽略未知的授权数据元素。依靠这些实现来遵守授权数据限制可能会造成安全弱点。
Care must be taken to ensure that old implementations can understand messages sent to them, even if they do not understand an extension that is used. Unless the sender knows that an extension is supported, the extension cannot change the semantics of the core message or previously defined extensions.
必须注意确保旧的实现能够理解发送给它们的消息，即使它们不理解所使用的扩展。除非发送方知道支持扩展，否则扩展无法更改核心消息或以前定义的扩展的语义。
For example, an extension including key information necessary to decrypt the encrypted part of a KDC-REP could only be used in situations where the recipient was known to support the extension. Thus when designing such extensions it is important to provide a way for the recipient to notify the sender of support for the extension. For example in the case of an extension that changes the KDC-REP reply key, the client could indicate support for the extension by including a padata element in the AS-REQ sequence. The KDC should only use the extension if this padata element is present in the AS-REQ. Even if policy requires the use of the extension, it is better to return an error indicating that the extension is required than to use the extension when the recipient may not support it. Debugging implementations that do not interoperate is easier when errors are returned.
例如，包含解密KDC-REP加密部分所需的密钥信息的扩展只能在已知收件人支持该扩展的情况下使用。因此，在设计此类扩展时，重要的是为接收方提供一种通知发送方支持扩展的方式。例如，对于更改KDC-REP应答密钥的扩展，客户机可以通过在AS-REQ序列中包含padata元素来指示对扩展的支持。只有当AS-REQ中存在此padata元素时，KDC才应使用扩展名。即使策略要求使用扩展，也最好返回一个错误，指示需要扩展，而不是在收件人可能不支持扩展时使用扩展。当返回错误时，调试不互操作的实现更容易。
Kerberos imposes a few assumptions on the environment in which it can properly function, including the following:
Kerberos对其能够正常工作的环境施加了一些假设，包括以下内容：
* "Denial of service" attacks are not solved with Kerberos. There are places in the protocols where an intruder can prevent an application from participating in the proper authentication steps. Detection and solution of such attacks (some of which can appear to be not-uncommon "normal" failure modes for the system) are usually best left to the human administrators and users.
* Kerberos无法解决“拒绝服务”攻击。在协议中，入侵者可能会阻止应用程序参与正确的身份验证步骤。此类攻击的检测和解决方案（其中一些攻击可能是系统常见的“正常”故障模式）通常最好留给人工管理员和用户。
* Principals MUST keep their secret keys secret. If an intruder somehow steals a principal's key, it will be able to masquerade as that principal or to impersonate any server to the legitimate principal.
* 委托人必须对其密钥保密。如果入侵者以某种方式窃取了主体的密钥，它将能够伪装成该主体，或者向合法主体模拟任何服务器。
* "Password guessing" attacks are not solved by Kerberos. If a user chooses a poor password, it is possible for an attacker to successfully mount an offline dictionary attack by repeatedly attempting to decrypt, with successive entries from a dictionary, messages obtained which are encrypted under a key derived from the user's password.
* Kerberos无法解决“密码猜测”攻击。如果用户选择的密码不正确，则攻击者有可能通过重复尝试使用字典中的连续条目解密根据用户密码派生的密钥加密的消息，从而成功发起脱机字典攻击。
* Each host on the network MUST have a clock which is "loosely synchronized" to the time of the other hosts; this synchronization is used to reduce the bookkeeping needs of application servers when they do replay detection. The degree of "looseness" can be configured on a per-server basis, but it is typically on the order of 5 minutes. If the clocks are synchronized over the network, the clock synchronization protocol MUST itself be secured from network attackers.
* 网络上的每台主机必须有一个与其他主机的时间“松散同步”的时钟；此同步用于减少应用程序服务器执行重播检测时的簿记需求。“松散”的程度可以根据每台服务器进行配置，但通常为5分钟左右。如果时钟通过网络同步，则时钟同步协议本身必须受到网络攻击者的保护。
* Principal identifiers are not recycled on a short-term basis. A typical mode of access control will use access control lists (ACLs) to grant permissions to particular principals. If a stale ACL entry remains for a deleted principal and the principal identifier is reused, the new principal will inherit rights specified in the stale ACL entry. By not re-using principal identifiers, the danger of inadvertent access is removed.
* 主要标识符不会在短期内循环使用。访问控制的典型模式将使用访问控制列表（ACL）向特定主体授予权限。如果已删除主体的旧ACL条目仍然存在，并且主体标识符被重用，则新主体将继承旧ACL条目中指定的权限。通过不重复使用主要标识符，消除了无意访问的危险。
Below is a list of terms used throughout this document.
以下是本文件中使用的术语列表。
Authentication Verifying the claimed identity of a principal.
验证主体的声明标识的身份验证。
Authentication header A record containing a Ticket and an Authenticator to be presented to a server as part of the authentication process.
身份验证头包含票证和身份验证符的记录，作为身份验证过程的一部分提供给服务器。
Authentication path A sequence of intermediate realms transited in the authentication process when communicating from one realm to another.
身份验证路径在从一个域到另一个域进行通信时，在身份验证过程中传输的一系列中间域。
Authenticator A record containing information that can be shown to have been recently generated using the session key known only by the client and server.
Authenticator一条记录，其中包含的信息可以显示为最近使用仅由客户端和服务器知道的会话密钥生成的。
Authorization The process of determining whether a client may use a service, which objects the client is allowed to access, and the type of access allowed for each.
授权—确定客户端是否可以使用服务的过程，允许客户端访问哪些对象，以及每个对象允许的访问类型。
Capability A token that grants the bearer permission to access an object or service. In Kerberos, this might be a ticket whose use is restricted by the contents of the authorization data field, but which lists no network addresses, together with the session key necessary to use the ticket.
授予承载者访问对象或服务的权限的令牌。在Kerberos中，这可能是一个票证，其使用受到授权数据字段内容的限制，但没有列出网络地址以及使用票证所需的会话密钥。
Ciphertext The output of an encryption function. Encryption transforms plaintext into ciphertext.
加密函数的输出。加密将明文转换为密文。
Client A process that makes use of a network service on behalf of a user. Note that in some cases a Server may itself be a client of some other server (e.g., a print server may be a client of a file server).
客户端代表用户使用网络服务的进程。注意，在某些情况下，服务器本身可能是其他服务器的客户端（例如，打印服务器可能是文件服务器的客户端）。
Credentials A ticket plus the secret session key necessary to use that ticket successfully in an authentication exchange.
凭证一个票证加上在身份验证交换中成功使用该票证所需的秘密会话密钥。
Encryption Type (etype) When associated with encrypted data, an encryption type identifies the algorithm used to encrypt the data and is used to select the appropriate algorithm for decrypting the data. Encryption type tags are communicated in other messages to enumerate algorithms that are desired, supported, preferred, or allowed to be used for encryption of data between parties. This preference is combined with local information and policy to select an algorithm to be used.
加密类型（etype）与加密数据关联时，加密类型标识用于加密数据的算法，并用于选择用于解密数据的适当算法。加密类型标记在其他消息中进行通信，以枚举所需、支持、首选或允许用于各方之间数据加密的算法。此首选项与本地信息和策略相结合，以选择要使用的算法。
KDC Key Distribution Center. A network service that supplies tickets and temporary session keys; or an instance of that service or the
KDC密钥分发中心。提供票证和临时会话密钥的网络服务；或该服务的实例或
host on which it runs. The KDC services both initial ticket and ticket-granting ticket requests. The initial ticket portion is sometimes referred to as the Authentication Server (or service). The ticket-granting ticket portion is sometimes referred to as the ticket-granting server (or service).
运行它的主机。KDC为初始票证和票证授予票证请求提供服务。初始票证部分有时称为身份验证服务器（或服务）。票证授予票证部分有时被称为票证授予服务器（或服务）。
Kerberos The name given to the Project Athena's authentication service, the protocol used by that service, or the code used to implement the authentication service. The name is adopted from the three-headed dog that guards Hades.
Kerberos项目Athena的身份验证服务的名称、该服务使用的协议或用于实现身份验证服务的代码。这个名字是从守护地狱的三头狗中取出来的。
Key Version Number (kvno) A tag associated with encrypted data identifies which key was used for encryption when a long-lived key associated with a principal changes over time. It is used during the transition to a new key so that the party decrypting a message can tell whether the data was encrypted with the old or the new key.
密钥版本号（kvno）与加密数据相关联的标记标识了当与主体相关联的长寿命密钥随时间变化时用于加密的密钥。它在转换到新密钥的过程中使用，这样解密消息的一方就可以知道数据是用旧密钥还是新密钥加密的。
Plaintext The input to an encryption function or the output of a decryption function. Decryption transforms ciphertext into plaintext.
明文加密函数的输入或解密函数的输出。解密将密文转换为明文。
Principal A named client or server entity that participates in a network communication, with one name that is considered canonical.
主体参与网络通信的命名客户端或服务器实体，其中一个名称被认为是规范的。
Principal identifier The canonical name used to identify each different principal uniquely.
主体标识符用于唯一标识每个不同主体的规范名称。
Seal To encipher a record containing several fields in such a way that the fields cannot be individually replaced without knowledge of the encryption key or leaving evidence of tampering.
密封对包含多个字段的记录进行加密，在不知道加密密钥或留下篡改证据的情况下，字段不能单独替换。
Secret key An encryption key shared by a principal and the KDC, distributed outside the bounds of the system, with a long lifetime. In the case of a human user's principal, the secret key MAY be derived from a password.
密钥由主体和KDC共享的加密密钥，分布在系统边界之外，具有较长的生命周期。在人类用户主体的情况下，密钥可以从密码派生。
Server A particular Principal that provides a resource to network clients. The server is sometimes referred to as the Application Server.
服务器为网络客户端提供资源的特定主体。服务器有时被称为应用服务器。
Service A resource provided to network clients; often provided by more than one server (for example, remote file service).
向网络客户端提供的服务资源；通常由多个服务器提供（例如，远程文件服务）。
Session key A temporary encryption key used between two principals, with a lifetime limited to the duration of a single login "session". In the Kerberos system, a session key is generated by the KDC. The session key is distinct from the sub-session key, described next.
会话密钥在两个主体之间使用的临时加密密钥，其生存期限制为单个登录“会话”的持续时间。在Kerberos系统中，会话密钥由KDC生成。会话密钥不同于子会话密钥，如下所述。
Sub-session key A temporary encryption key used between two principals, selected and exchanged by the principals using the session key, and with a lifetime limited to the duration of a single association. The sub-session key is also referred to as the subkey.
子会话密钥在两个主体之间使用的临时加密密钥，由主体使用会话密钥选择和交换，其生存期限制为单个关联的持续时间。子会话密钥也称为子密钥。
Ticket A record that helps a client authenticate itself to a server; it contains the client's identity, a session key, a timestamp, and other information, all sealed using the server's secret key. It only serves to authenticate a client when presented along with a fresh Authenticator.
票证：帮助客户机向服务器验证自身身份的记录；它包含客户端的身份、会话密钥、时间戳和其他信息，所有这些信息都使用服务器的密钥密封。它仅在与新的验证器一起出现时用于对客户端进行身份验证。
Each Kerberos ticket contains a set of flags that are used to indicate attributes of that ticket. Most flags may be requested by a client when the ticket is obtained; some are automatically turned on and off by a Kerberos server as required. The following sections explain what the various flags mean and give examples of reasons to use them. With the exception of the INVALID flag, clients MUST ignore ticket flags that are not recognized. KDCs MUST ignore KDC options that are not recognized. Some implementations of RFC 1510 are known to reject unknown KDC options, so clients may need to resend a request without new KDC options if the request was rejected when sent with options added since RFC 1510. Because new KDCs will ignore unknown options, clients MUST confirm that the ticket returned by the KDC meets their needs.
每个Kerberos票证都包含一组用于指示该票证属性的标志。当获得票证时，客户端可能会请求大多数标志；有些是由Kerberos服务器根据需要自动打开和关闭的。以下各节解释各种标志的含义，并举例说明使用它们的原因。除了无效标志外，客户端必须忽略无法识别的票证标志。KDC必须忽略无法识别的KDC选项。已知RFC 1510的某些实现会拒绝未知的KDC选项，因此，如果在发送请求时添加了自RFC 1510以来添加的选项，则客户端可能需要在没有新的KDC选项的情况下重新发送请求。因为新的KDC将忽略未知选项，所以客户端必须确认KDC返回的票证满足其需要。
Note that it is not, in general, possible to determine whether an option was not honored because it was not understood or because it was rejected through either configuration or policy. When adding a new option to the Kerberos protocol, designers should consider whether the distinction is important for their option. If it is, a mechanism for the KDC to return an indication that the option was understood but rejected needs to be provided in the specification of the option. Often in such cases, the mechanism needs to be broad enough to permit an error or reason to be returned.
请注意，一般来说，无法确定某个选项是否因为未理解而未被接受，或者是因为它通过配置或策略被拒绝。当向Kerberos协议添加一个新的选项时，设计者应该考虑区分对于它们的选择是否重要。如果是，则需要在选项规范中提供KDC返回选项已被理解但被拒绝的指示的机制。通常在这种情况下，机制需要足够广泛，以允许返回错误或原因。
The INITIAL flag indicates that a ticket was issued using the AS protocol, rather than issued based on a TGT. Application servers that want to require the demonstrated knowledge of a client's secret key (e.g., a password-changing program) can insist that this flag be set in any tickets they accept, and can thus be assured that the client's key was recently presented to the authentication server.
初始标志表示票证是使用AS协议发出的，而不是基于TGT发出的。如果应用服务器希望获得客户机密钥（例如，密码更改程序）的证明知识，则可以坚持在其接受的任何票据中设置此标志，从而可以确保客户机密钥最近已提交给身份验证服务器。
The PRE-AUTHENT and HW-AUTHENT flags provide additional information about the initial authentication, regardless of whether the current ticket was issued directly (in which case INITIAL will also be set) or issued on the basis of a TGT (in which case the INITIAL flag is clear, but the PRE-AUTHENT and HW-AUTHENT flags are carried forward from the TGT).
PRE-AUTHENT和HW-AUTHENT标志提供了有关初始身份验证的附加信息，而不管当前票证是直接颁发的（在这种情况下，也将设置初始票证）还是基于TGT颁发的（在这种情况下，初始标志是清晰的，但预授权和HW授权标志从TGT向前推进）。
The INVALID flag indicates that a ticket is invalid. Application servers MUST reject tickets that have this flag set. A postdated ticket will be issued in this form. Invalid tickets MUST be validated by the KDC before use, by being presented to the KDC in a TGS request with the VALIDATE option specified. The KDC will only validate tickets after their starttime has passed. The validation is required so that postdated tickets that have been stolen before their starttime can be rendered permanently invalid (through a hot-list mechanism) (see Section 3.3.3.1).
无效标志表示票证无效。应用程序服务器必须拒绝设置了此标志的票证。本表将签发过期票。无效票证必须在使用前由KDC验证，方法是在TGS请求中向KDC提供指定了验证选项的票证。KDC将仅在票证的开始时间过后验证票证。需要进行验证，以便在开始时间之前被盗的过期票据可以永久失效（通过热名单机制）（见第3.3.3.1节）。
Applications may desire to hold tickets that can be valid for long periods of time. However, this can expose their credentials to potential theft for equally long periods, and those stolen credentials would be valid until the expiration time of the ticket(s). Simply using short-lived tickets and obtaining new ones periodically would require the client to have long-term access to its secret key, an even greater risk. Renewable tickets can be used to mitigate the consequences of theft. Renewable tickets have two "expiration times": the first is when the current instance of the ticket expires, and the second is the latest permissible value for an individual expiration time. An application client must periodically (i.e., before it expires) present a renewable ticket to the KDC, with the RENEW option set in the KDC request. The KDC will issue a new ticket with a new session key and a later expiration time. All other fields of the ticket are left unmodified by the renewal process. When the latest permissible expiration time arrives, the ticket expires permanently. At each renewal, the KDC MAY consult a hot-list to determine whether the ticket had been reported stolen since its
申请者可能希望持有长期有效的机票。但是，这会使他们的凭据在同样长的时间内面临潜在的盗窃，并且这些被盗的凭据将一直有效，直到票证过期为止。简单地使用短期票据并定期获取新票据将要求客户长期访问其密钥，这将带来更大的风险。可更新的门票可用于减轻盗窃的后果。可更新票证有两个“到期时间”：第一个是票证的当前实例到期时，第二个是单个到期时间的最新允许值。应用程序客户端必须定期（即，在到期之前）向KDC提交可续签票证，并在KDC请求中设置续签选项。KDC将发布一个新的票证，其中包含一个新的会话密钥和一个更晚的过期时间。票据的所有其他字段在续订过程中保持不变。当最新允许的过期时间到达时，票证将永久过期。在每次续签时，KDC可能会查阅一份热门名单，以确定自续签以来是否有人报告该票据被盗
last renewal; it will refuse to renew stolen tickets, and thus the usable lifetime of stolen tickets is reduced.
最后更新；将拒绝更新被盗车票，从而缩短被盗车票的使用寿命。
The RENEWABLE flag in a ticket is normally only interpreted by the ticket-granting service (discussed below in Section 3.3). It can usually be ignored by application servers. However, some particularly careful application servers MAY disallow renewable tickets.
票证中的可续期标志通常仅由票证授予服务解释（下文第3.3节讨论）。应用服务器通常可以忽略它。但是，一些特别小心的应用程序服务器可能不允许使用可更新的票证。
If a renewable ticket is not renewed by its expiration time, the KDC will not renew the ticket. The RENEWABLE flag is reset by default, but a client MAY request it be set by setting the RENEWABLE option in the KRB_AS_REQ message. If it is set, then the renew-till field in the ticket contains the time after which the ticket may not be renewed.
如果可续签票证在到期前未续签，KDC将不续签票证。默认情况下，RENERABLE标志被重置，但客户端可以通过在KRB_AS_REQ消息中设置RENERABLE选项来请求设置RENERABLE标志。如果已设置，则票证中的“续订至”字段包含票证不可续订的时间。
Applications may occasionally need to obtain tickets for use much later; e.g., a batch submission system would need tickets to be valid at the time the batch job is serviced. However, it is dangerous to hold valid tickets in a batch queue, since they will be on-line longer and more prone to theft. Postdated tickets provide a way to obtain these tickets from the KDC at job submission time, but to leave them "dormant" until they are activated and validated by a further request of the KDC. If a ticket theft were reported in the interim, the KDC would refuse to validate the ticket, and the thief would be foiled.
申请者可能偶尔需要获得门票，以便以后使用；e、 例如，批提交系统需要在批处理作业提供服务时票据有效。然而，在批处理队列中持有有效票证是危险的，因为它们在线时间更长，更容易被盗。过期票据提供了一种在提交作业时从KDC获取这些票据的方法，但在KDC的进一步请求激活和验证之前，将其保持“休眠”。如果在此期间报告了罚单被盗，KDC将拒绝验证罚单，小偷将被挫败。
The MAY-POSTDATE flag in a ticket is normally only interpreted by the ticket-granting service. It can be ignored by application servers. This flag MUST be set in a TGT in order to issue a postdated ticket based on the presented ticket. It is reset by default; a client MAY request it by setting the ALLOW-POSTDATE option in the KRB_AS_REQ message. This flag does not allow a client to obtain a postdated TGT; postdated TGTs can only be obtained by requesting the postdating in the KRB_AS_REQ message. The life (endtime-starttime) of a postdated ticket will be the remaining life of the TGT at the time of the request, unless the RENEWABLE option is also set, in which case it can be the full life (endtime-starttime) of the TGT. The KDC MAY limit how far in the future a ticket may be postdated.
票证中的MAY-POSTDATE标志通常仅由票证授予服务解释。应用服务器可以忽略它。必须在TGT中设置此标志，以便根据出示的票证签发过期票证。默认重置；客户端可以通过在KRB_AS_REQ消息中设置ALLOW-POSTDATE选项来请求它。此标志不允许客户机获取过期的TGT；只能通过请求KRB_AS_REQ消息中的后日期来获得后日期TGT。过期票据的寿命（endtime starttime）将是请求时TGT的剩余寿命，除非还设置了可续期选项，在这种情况下，它可以是TGT的完整寿命（endtime starttime）。KDC可能会限制票证的过期时间。
The POSTDATED flag indicates that a ticket has been postdated. The application server can check the authtime field in the ticket to see when the original authentication occurred. Some services MAY choose to reject postdated tickets, or they may only accept them within a certain period after the original authentication. When the KDC issues a POSTDATED ticket, it will also be marked as INVALID, so that
POSTDATED标志表示票证已过期。应用程序服务器可以检查票据中的authtime字段，以查看原始身份验证是何时发生的。某些服务可能会选择拒绝过期票据，或者可能只在原始身份验证后的特定时间内接受这些票据。当KDC发布过期票据时，它也将被标记为无效，以便
the application client MUST present the ticket to the KDC to be validated before use.
应用程序客户端必须在使用前向KDC出示票据以进行验证。
At times it may be necessary for a principal to allow a service to perform an operation on its behalf. The service must be able to take on the identity of the client, but only for a particular purpose. A principal can allow a service to do this by granting it a proxy.
有时，主体可能需要允许服务代表其执行操作。服务必须能够接受客户机的身份，但只能用于特定目的。主体可以通过向服务授予代理来允许服务执行此操作。
The process of granting a proxy by using the proxy and proxiable flags is used to provide credentials for use with specific services. Though conceptually also a proxy, users wishing to delegate their identity in a form usable for all purposes MUST use the ticket forwarding mechanism described in the next section to forward a TGT.
通过使用proxy和proxiable标志授予代理的过程用于提供用于特定服务的凭据。虽然在概念上也是一个代理，但希望以可用于所有目的的形式委托其身份的用户必须使用下一节中描述的票证转发机制来转发TGT。
The PROXIABLE flag in a ticket is normally only interpreted by the ticket-granting service. It can be ignored by application servers. When set, this flag tells the ticket-granting server that it is OK to issue a new ticket (but not a TGT) with a different network address based on this ticket. This flag is set if requested by the client on initial authentication. By default, the client will request that it be set when requesting a TGT, and that it be reset when requesting any other ticket.
票证中的可代理标志通常仅由票证授予服务解释。应用服务器可以忽略它。设置后，此标志告知票证授予服务器可以基于此票证颁发具有不同网络地址的新票证（但不是TGT）。如果客户端在初始身份验证时请求，则设置此标志。默认情况下，客户端将请求在请求TGT时设置它，并在请求任何其他票证时重置它。
This flag allows a client to pass a proxy to a server to perform a remote request on its behalf (e.g., a print service client can give the print server a proxy to access the client's files on a particular file server in order to satisfy a print request).
此标志允许客户端向服务器传递代理以代表其执行远程请求（例如，打印服务客户端可以向打印服务器提供代理以访问特定文件服务器上的客户端文件，以满足打印请求）。
In order to complicate the use of stolen credentials, Kerberos tickets are often valid only from those network addresses specifically included in the ticket, but it is permissible as a policy option to allow requests and to issue tickets with no network addresses specified. When granting a proxy, the client MUST specify the new network address from which the proxy is to be used or indicate that the proxy is to be issued for use from any address.
为了使被盗凭证的使用复杂化，Kerberos票证通常仅在票证中具体包含的网络地址中有效，但作为一种策略选项，允许在未指定网络地址的情况下允许请求和颁发票证。授予代理时，客户端必须指定要使用代理的新网络地址，或指示要从任何地址发出代理以供使用。
The PROXY flag is set in a ticket by the TGS when it issues a proxy ticket. Application servers MAY check this flag; and at their option they MAY require additional authentication from the agent presenting the proxy in order to provide an audit trail.
TGS在发出代理票证时在票证中设置代理标志。应用服务器可以检查此标志；他们可以选择要求代理提供额外的身份验证，以便提供审计跟踪。
Authentication forwarding is an instance of a proxy where the service that is granted is complete use of the client's identity. An example of where it might be used is when a user logs in to a remote system
身份验证转发是代理的一个实例，在该实例中，所授予的服务完全使用了客户端的身份。当用户登录到远程系统时，可以使用它
and wants authentication to work from that system as if the login were local.
并希望从该系统进行身份验证，就像登录是本地的一样。
The FORWARDABLE flag in a ticket is normally only interpreted by the ticket-granting service. It can be ignored by application servers. The FORWARDABLE flag has an interpretation similar to that of the PROXIABLE flag, except TGTs may also be issued with different network addresses. This flag is reset by default, but users MAY request that it be set by setting the FORWARDABLE option in the AS request when they request their initial TGT.
票证中的可转发标志通常仅由票证授予服务解释。应用服务器可以忽略它。可转发标志具有与可代理标志类似的解释，除了TGT也可以用不同的网络地址发出。默认情况下会重置此标志，但当用户请求其初始TGT时，可以通过在AS请求中设置FORWARDABLE选项来请求设置此标志。
This flag allows for authentication forwarding without requiring the user to enter a password again. If the flag is not set, then authentication forwarding is not permitted, but the same result can still be achieved if the user engages in the AS exchange, specifies the requested network addresses, and supplies a password.
此标志允许身份验证转发，而无需用户再次输入密码。如果未设置该标志，则不允许进行身份验证转发，但如果用户参与AS交换、指定请求的网络地址并提供密码，仍然可以实现相同的结果。
The FORWARDED flag is set by the TGS when a client presents a ticket with the FORWARDABLE flag set and requests a forwarded ticket by specifying the FORWARDED KDC option and supplying a set of addresses for the new ticket. It is also set in all tickets issued based on tickets with the FORWARDED flag set. Application servers may choose to process FORWARDED tickets differently than non-FORWARDED tickets.
当客户端提供具有可转发标志集的票证，并通过指定转发KDC选项并为新票证提供一组地址来请求转发票证时，TGS将设置转发标志。在基于设置了转发标志的票证发行的所有票证中也设置了转发标志。应用程序服务器可以选择以不同于未转发票证的方式处理转发票证。
If addressless tickets are forwarded from one system to another, clients SHOULD still use this option to obtain a new TGT in order to have different session keys on the different systems.
如果无地址票证从一个系统转发到另一个系统，客户端仍应使用此选项获取新的TGT，以便在不同的系统上具有不同的会话密钥。
In Kerberos, the application server is ultimately responsible for accepting or rejecting authentication, and it SHOULD check that only suitably trusted KDCs are relied upon to authenticate a principal. The transited field in the ticket identifies which realms (and thus which KDCs) were involved in the authentication process, and an application server would normally check this field. If any of these are untrusted to authenticate the indicated client principal (probably determined by a realm-based policy), the authentication attempt MUST be rejected. The presence of trusted KDCs in this list does not provide any guarantee; an untrusted KDC may have fabricated the list.
在Kerberos中，应用程序服务器最终负责接受或拒绝身份验证，并且它应该检查是否仅依赖适当信任的KDC来对主体进行身份验证。票证中的transited字段标识身份验证过程中涉及哪些领域（以及哪些KDC），应用程序服务器通常会检查该字段。如果其中任何一个不受信任，无法对指定的客户端主体进行身份验证（可能由基于领域的策略确定），则必须拒绝身份验证尝试。此列表中存在受信任的KDC不提供任何保证；不受信任的KDC可能伪造了该列表。
Although the end server ultimately decides whether authentication is valid, the KDC for the end server's realm MAY apply a realm-specific policy for validating the transited field and accepting credentials for cross-realm authentication. When the KDC applies such checks and accepts such cross-realm authentication, it will set the TRANSITED-POLICY-CHECKED flag in the service tickets it issues based
尽管最终由终端服务器决定身份验证是否有效，但终端服务器领域的KDC可以应用领域特定的策略来验证传输的字段并接受跨领域身份验证的凭据。当KDC应用这样的检查并接受这样的跨领域身份验证时，它将在它基于的服务票证中设置TRANSITED-POLICY-CHECKED标志
on the cross-realm TGT. A client MAY request that the KDCs not check the transited field by setting the DISABLE-TRANSITED-CHECK flag. KDCs are encouraged but not required to honor this flag.
在跨领域TGT上。客户端可以通过设置DISABLE-TRANSTED-check标志请求KDCs不检查传输字段。鼓励KDC，但不要求KDC遵守此标志。
Application servers MUST either do the transited-realm checks themselves or reject cross-realm tickets without TRANSITED-POLICY-CHECKED set.
应用程序服务器必须自己执行transited-realm检查，或者拒绝未设置transited-POLICY-CHECKED的跨域票证。
For some applications, a client may need to delegate authority to a server to act on its behalf in contacting other services. This requires that the client forward credentials to an intermediate server. The ability for a client to obtain a service ticket to a server conveys no information to the client about whether the server should be trusted to accept delegated credentials. The OK-AS-DELEGATE provides a way for a KDC to communicate local realm policy to a client regarding whether an intermediate server is trusted to accept such credentials.
对于某些应用程序，客户端可能需要将权限委托给服务器，以代表其联系其他服务。这要求客户端将凭据转发到中间服务器。客户机向服务器获取服务票证的能力不会向客户机传递有关是否应信任服务器以接受委派凭据的信息。OK-AS-DELEGATE为KDC提供了一种将本地域策略与客户端进行通信的方法，该策略涉及是否信任中间服务器来接受此类凭据。
The copy of the ticket flags in the encrypted part of the KDC reply may have the OK-AS-DELEGATE flag set to indicate to the client that the server specified in the ticket has been determined by the policy of the realm to be a suitable recipient of delegation. A client can use the presence of this flag to help it decide whether to delegate credentials (grant either a proxy or a forwarded TGT) to this server. It is acceptable to ignore the value of this flag. When setting this flag, an administrator should consider the security and placement of the server on which the service will run, as well as whether the service requires the use of delegated credentials.
KDC应答的加密部分中的票证标志副本可以设置OK-AS-DELEGATE标志，以向客户端指示票证中指定的服务器已由域的策略确定为合适的委托接收者。客户端可以使用此标志的存在来帮助它决定是否将凭据（授予代理或转发的TGT）委派到此服务器。可以忽略此标志的值。在设置此标志时，管理员应考虑服务运行的服务器的安全性和位置，以及服务是否需要使用委托凭据。
There are three additional options that MAY be set in a client's request of the KDC.
在客户机对KDC的请求中可以设置三个附加选项。
The RENEWABLE-OK option indicates that the client will accept a renewable ticket if a ticket with the requested life cannot otherwise be provided. If a ticket with the requested life cannot be provided, then the KDC MAY issue a renewable ticket with a renew-till equal to the requested endtime. The value of the renew-till field MAY still be adjusted by site-determined limits or limits imposed by the individual principal or server.
RENERABLE-OK选项表示如果无法提供具有请求寿命的票证，则客户端将接受可更新票证。如果无法提供具有所请求寿命的票证，则KDC可签发续签票证，续签时间等于所请求的结束时间。“续费至”字段的值仍可根据站点确定的限制或单个主体或服务器施加的限制进行调整。
In its basic form, the Kerberos protocol supports authentication in a client-server setting and is not well suited to authentication in a peer-to-peer environment because the long-term key of the user does not remain on the workstation after initial login. Authentication of such peers may be supported by Kerberos in its user-to-user variant. The ENC-TKT-IN-SKEY option supports user-to-user authentication by allowing the KDC to issue a service ticket encrypted using the session key from another TGT issued to another user. The ENC-TKT-IN-SKEY option is honored only by the ticket-granting service. It indicates that the ticket to be issued for the end server is to be encrypted in the session key from the additional second TGT provided with the request. See Section 3.3.3 for specific details.
在其基本形式中，Kerberos协议支持客户机-服务器设置中的身份验证，并且不适合在对等环境中进行身份验证，因为用户的长期密钥在初次登录后不会保留在工作站上。Kerberos在其用户对用户的变体中可能支持对此类对等点的身份验证。ENC-TKT-IN-SKEY选项通过允许KDC从另一个TGT向另一个用户发出使用会话密钥加密的服务票证来支持用户对用户身份验证。ENC-TKT-IN-SKEY选项仅由票证授予服务授予。它表示要为终端服务器颁发的票证将在来自随请求提供的附加第二个TGT的会话密钥中加密。具体细节见第3.3.3节。
The OPT-HARDWARE-AUTH option indicates that the client wishes to use some form of hardware authentication instead of or in addition to the client's password or other long-lived encryption key. OPT-HARDWARE-AUTH is honored only by the authentication service. If supported and allowed by policy, the KDC will return an error code of KDC_ERR_PREAUTH_REQUIRED and include the required METHOD-DATA to perform such authentication.
OPT-HARDWARE-AUTH选项表示客户端希望使用某种形式的硬件身份验证来代替或补充客户端的密码或其他长寿命加密密钥。OPT-HARDWARE-AUTH仅由身份验证服务提供。如果策略支持并允许，KDC将返回KDC_ERR_PREAUTH_REQUIRED的错误代码，并包含执行此类身份验证所需的方法数据。
The following sections describe the interactions between network clients and servers and the messages involved in those exchanges.
以下各节描述网络客户端和服务器之间的交互以及这些交换中涉及的消息。
Summary
总结
Message direction Message type Section 1. Client to Kerberos KRB_AS_REQ 5.4.1 2. Kerberos to client KRB_AS_REP or 5.4.2 KRB_ERROR 5.9.1
消息方向消息类型第1节。Kerberos KRB_AS_REQ 5.4.1 2的客户端。Kerberos到客户端KRB_AS_REP或5.4.2 KRB_错误5.9.1
The Authentication Service (AS) Exchange between the client and the Kerberos Authentication Server is initiated by a client when it wishes to obtain authentication credentials for a given server but currently holds no credentials. In its basic form, the client's secret key is used for encryption and decryption. This exchange is typically used at the initiation of a login session to obtain credentials for a Ticket-Granting Server, which will subsequently be used to obtain credentials for other servers (see Section 3.3)
客户端和Kerberos身份验证服务器之间的身份验证服务（AS）交换由客户端在希望获取给定服务器的身份验证凭据但当前不持有凭据时启动。在其基本形式中，客户端的密钥用于加密和解密。此交换通常在登录会话启动时用于获取票证授予服务器的凭据，随后将用于获取其他服务器的凭据（参见第3.3节）
without requiring further use of the client's secret key. This exchange is also used to request credentials for services that must not be mediated through the Ticket-Granting Service, but rather require knowledge of a principal's secret key, such as the password-changing service (the password-changing service denies requests unless the requester can demonstrate knowledge of the user's old password; requiring this knowledge prevents unauthorized password changes by someone walking up to an unattended session).
无需进一步使用客户端的密钥。此交换还用于请求服务的凭据，这些服务不能通过票证授予服务进行中介，而是需要知道主体的密钥，例如密码更改服务（密码更改服务拒绝请求，除非请求者能够证明知道用户的旧密码；需要此知识可防止有人进入无人参与的会话进行未经授权的密码更改）。
This exchange does not by itself provide any assurance of the identity of the user. To authenticate a user logging on to a local system, the credentials obtained in the AS exchange may first be used in a TGS exchange to obtain credentials for a local server; those credentials must then be verified by a local server through successful completion of the Client/Server exchange.
此交换本身并不保证用户的身份。为了认证登录到本地系统的用户，可以首先在TGS交换中使用在AS交换中获得的凭据来获得本地服务器的凭据；然后，本地服务器必须通过成功完成客户机/服务器交换来验证这些凭据。
The AS exchange consists of two messages: KRB_AS_REQ from the client to Kerberos, and KRB_AS_REP or KRB_ERROR in reply. The formats for these messages are described in Sections 5.4.1, 5.4.2, and 5.9.1.
AS交换包含两条消息：从客户端到Kerberos的KRB_AS_REQ，以及应答中的KRB_AS_REP或KRB_ERROR。第5.4.1节、第5.4.2节和第5.9.1节描述了这些信息的格式。
In the request, the client sends (in cleartext) its own identity and the identity of the server for which it is requesting credentials, other information about the credentials it is requesting, and a randomly generated nonce, which can be used to detect replays and to associate replies with the matching requests. This nonce MUST be generated randomly by the client and remembered for checking against the nonce in the expected reply. The response, KRB_AS_REP, contains a ticket for the client to present to the server, and a session key that will be shared by the client and the server. The session key and additional information are encrypted in the client's secret key. The encrypted part of the KRB_AS_REP message also contains the nonce that MUST be matched with the nonce from the KRB_AS_REQ message.
在请求中，客户机发送（以明文形式）自己的标识和请求凭据的服务器的标识、关于请求凭据的其他信息，以及随机生成的nonce，该nonce可用于检测重播并将应答与匹配的请求相关联。此nonce必须由客户端随机生成，并记住，以便与预期回复中的nonce进行检查。响应KRB_AS_REP包含客户机提交给服务器的票据，以及客户机和服务器共享的会话密钥。会话密钥和附加信息在客户端的密钥中加密。KRB_AS_REP消息的加密部分还包含必须与KRB_AS_REQ消息中的nonce匹配的nonce。
Without pre-authentication, the authentication server does not know whether the client is actually the principal named in the request. It simply sends a reply without knowing or caring whether they are the same. This is acceptable because nobody but the principal whose identity was given in the request will be able to use the reply. Its critical information is encrypted in that principal's key. However, an attacker can send a KRB_AS_REQ message to get known plaintext in order to attack the principal's key. Especially if the key is based on a password, this may create a security exposure. So the initial request supports an optional field that can be used to pass additional information that might be needed for the initial exchange. This field SHOULD be used for pre-authentication as described in sections 3.1.1 and 5.2.7.
如果没有预身份验证，身份验证服务器就不知道客户机是否实际上是请求中指定的主体。它只是发送一个回复，而不知道或关心它们是否相同。这是可以接受的，因为除了在请求中提供身份的主体之外，没有人能够使用回复。它的关键信息在主体的密钥中加密。但是，攻击者可以发送KRB_AS_REQ消息以获取已知的明文，从而攻击主体的密钥。特别是如果密钥基于密码，这可能会造成安全隐患。因此，初始请求支持一个可选字段，可用于传递初始交换可能需要的其他信息。该字段应用于第3.1.1节和第5.2.7节所述的预认证。
Various errors can occur; these are indicated by an error response (KRB_ERROR) instead of the KRB_AS_REP response. The error message is not encrypted. The KRB_ERROR message contains information that can be used to associate it with the message to which it replies. The contents of the KRB_ERROR message are not integrity-protected. As such, the client cannot detect replays, fabrications, or modifications. A solution to this problem will be included in a future version of the protocol.
可能发生各种错误；这些由错误响应（KRB_error）而不是KRB_AS_REP响应指示。错误消息未加密。KRB_错误消息包含可用于将其与所回复的消息关联的信息。KRB_错误消息的内容不受完整性保护。因此，客户无法检测回放、制作或修改。此问题的解决方案将包含在协议的未来版本中。
The client may specify a number of options in the initial request. Among these options are whether pre-authentication is to be performed; whether the requested ticket is to be renewable, proxiable, or forwardable; whether it should be postdated or allow postdating of derivative tickets; and whether a renewable ticket will be accepted in lieu of a non-renewable ticket if the requested ticket expiration date cannot be satisfied by a non-renewable ticket (due to configuration constraints).
客户端可以在初始请求中指定许多选项。这些选项包括是否执行预认证；请求的票证是否可续签、可代理或可转发；是否应延期或允许衍生票据延期；以及如果不可续签票证无法满足请求的票证到期日期（由于配置限制），是否接受可续签票证代替不可续签票证。
The client prepares the KRB_AS_REQ message and sends it to the KDC.
客户机准备KRB_AS_REQ消息并将其发送给KDC。
If all goes well, processing the KRB_AS_REQ message will result in the creation of a ticket for the client to present to the server. The format for the ticket is described in Section 5.3.
如果一切顺利，处理KRB_AS_REQ消息将导致创建一个票据，供客户机呈现给服务器。票证格式见第5.3节。
Because Kerberos can run over unreliable transports such as UDP, the KDC MUST be prepared to retransmit responses in case they are lost. If a KDC receives a request identical to one it has recently processed successfully, the KDC MUST respond with a KRB_AS_REP message rather than a replay error. In order to reduce ciphertext given to a potential attacker, KDCs MAY send the same response generated when the request was first handled. KDCs MUST obey this replay behavior even if the actual transport in use is reliable.
由于Kerberos可以在不可靠的传输（如UDP）上运行，因此KDC必须准备好在响应丢失时重新传输响应。如果KDC收到与其最近成功处理的请求相同的请求，KDC必须使用KRB_AS_REP消息而不是重播错误进行响应。为了减少提供给潜在攻击者的密文，KDCs可能会发送第一次处理请求时生成的相同响应。即使实际使用的传输是可靠的，KDC也必须遵守这种重播行为。
The authentication server looks up the client and server principals named in the KRB_AS_REQ in its database, extracting their respective keys. If the requested client principal named in the request is unknown because it doesn't exist in the KDC's principal database, then an error message with a KDC_ERR_C_PRINCIPAL_UNKNOWN is returned.
身份验证服务器在其数据库中查找KRB_AS_REQ中命名的客户端和服务器主体，提取它们各自的密钥。如果请求中命名的请求客户端主体未知，因为它不存在于KDC的主体数据库中，则返回带有KDC_ERR_C_principal_unknown的错误消息。
If required to do so, the server pre-authenticates the request, and if the pre-authentication check fails, an error message with the code KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is
如果需要这样做，服务器将对请求进行预身份验证，如果预身份验证检查失败，则返回代码为KDC_ERR_PREAUTH_FAILED的错误消息。如果需要预认证
required, but was not present in the request, an error message with the code KDC_ERR_PREAUTH_REQUIRED is returned, and a METHOD-DATA object will be stored in the e-data field of the KRB-ERROR message to specify which pre-authentication mechanisms are acceptable. Usually this will include PA-ETYPE-INFO and/or PA-ETYPE-INFO2 elements as described below. If the server cannot accommodate any encryption type requested by the client, an error message with code KDC_ERR_ETYPE_NOSUPP is returned. Otherwise, the KDC generates a 'random' session key, meaning that, among other things, it should be impossible to guess the next session key based on knowledge of past session keys. Although this can be achieved in a pseudo-random number generator if it is based on cryptographic principles, it is more desirable to use a truly random number generator, such as one based on measurements of random physical phenomena. See [RFC4086] for an in-depth discussion of randomness.
必需，但请求中不存在，返回代码为KDC_ERR_PREAUTH_required的错误消息，并且方法数据对象将存储在KRB-error消息的e-DATA字段中，以指定可接受的预身份验证机制。通常包括PA-ETYPE-INFO和/或PA-ETYPE-INFO2元素，如下所述。如果服务器无法容纳客户端请求的任何加密类型，则返回代码为KDC_ERR_ETYPE_NOSUPP的错误消息。否则，KDC将生成一个“随机”会话密钥，这意味着，除其他外，不可能根据对过去会话密钥的了解来猜测下一个会话密钥。虽然如果伪随机数生成器基于密码学原理，则可以在伪随机数生成器中实现这一点，但更希望使用真正的随机数生成器，例如基于随机物理现象测量的随机数生成器。有关随机性的深入讨论，请参见[RFC4086]。
In response to an AS request, if there are multiple encryption keys registered for a client in the Kerberos database, then the etype field from the AS request is used by the KDC to select the encryption method to be used to protect the encrypted part of the KRB_AS_REP message that is sent to the client. If there is more than one supported strong encryption type in the etype list, the KDC SHOULD use the first valid strong etype for which an encryption key is available.
作为对AS请求的响应，如果Kerberos数据库中为客户端注册了多个加密密钥，那么KDC将使用AS请求中的etype字段来选择加密方法，以保护发送到客户端的KRB_AS_REP消息的加密部分。如果在etype列表中有多个受支持的强加密类型，KDC应该使用第一个有效的强etype，其中有一个加密密钥可用。
When the user's key is generated from a password or pass phrase, the string-to-key function for the particular encryption key type is used, as specified in [RFC3961]. The salt value and additional parameters for the string-to-key function have default values (specified by Section 4 and by the encryption mechanism specification, respectively) that may be overridden by pre-authentication data (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA-ETYPE-INFO2, etc). Since the KDC is presumed to store a copy of the resulting key only, these values should not be changed for password-based keys except when changing the principal's key.
根据密码或密码短语生成用户密钥时，将使用特定加密密钥类型的字符串到密钥函数，如[RFC3961]中所述。string-to-key函数的salt值和附加参数具有默认值（分别由第4节和加密机制规范指定），可由预认证数据（PA-PW-salt、PA-AFS3-salt、PA-ETYPE-INFO、PA-ETYPE-INFO2等）覆盖。由于KDC被假定只存储结果密钥的副本，因此不应为基于密码的密钥更改这些值，除非更改主体的密钥。
When the AS server is to include pre-authentication data in a KRB-ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-INFO, if the etype field of the client's AS-REQ lists at least one "newer" encryption type. Otherwise (when the etype field of the client's AS-REQ does not list any "newer" encryption types), it MUST send both PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for each enctype). A "newer" enctype is any enctype first officially specified concurrently with or subsequent to the issue of this RFC. The enctypes DES, 3DES, or RC4 and any defined in [RFC1510] are not "newer" enctypes.
当AS服务器要在KRB-ERROR或AS-REP中包含预认证数据时，如果客户端AS-REQ的ETYPE字段列出了至少一种“较新”的加密类型，则必须使用PA-ETYPE-INFO2，而不是PA-ETYPE-INFO。否则（当客户端AS-REQ的etype字段未列出任何“较新”的加密类型时），它必须同时发送PA-etype-INFO2和PA-etype-INFO（两种类型都有一个条目）。“较新”的enctype是在发布本RFC的同时或之后首次正式指定的任何enctype。DES、3DES或RC4以及[RFC1510]中定义的任何EncType不是“较新”的EncType。
It is not possible to generate a user's key reliably given a pass phrase without contacting the KDC, since it will not be known whether alternate salt or parameter values are required.
如果不联系KDC，就不可能在给定密码短语的情况下可靠地生成用户密钥，因为不知道是否需要备用salt或参数值。
The KDC will attempt to assign the type of the random session key from the list of methods in the etype field. The KDC will select the appropriate type using the list of methods provided and information from the Kerberos database indicating acceptable encryption methods for the application server. The KDC will not issue tickets with a weak session key encryption type.
KDC将尝试从etype字段中的方法列表中分配随机会话键的类型。KDC将使用提供的方法列表和Kerberos数据库中指示应用服务器可接受加密方法的信息选择适当的类型。KDC不会发出弱会话密钥加密类型的票据。
If the requested starttime is absent, indicates a time in the past, or is within the window of acceptable clock skew for the KDC and the POSTDATE option has not been specified, then the starttime of the ticket is set to the authentication server's current time. If it indicates a time in the future beyond the acceptable clock skew, but the POSTDATED option has not been specified, then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested starttime is checked against the policy of the local realm (the administrator might decide to prohibit certain types or ranges of postdated tickets), and if the ticket's starttime is acceptable, it is set as requested, and the INVALID flag is set in the new ticket. The postdated ticket MUST be validated before use by presenting it to the KDC after the starttime has been reached.
如果请求的starttime不存在，表示过去的时间，或者在KDC可接受的时钟偏移窗口内，并且尚未指定POSTDATE选项，则票证的starttime设置为身份验证服务器的当前时间。如果它指示未来某个时间超出可接受的时钟偏差，但尚未指定POSTDATED选项，则返回错误KDC_ERR_CANNOT_POSTDATE。否则，将根据本地域的策略检查请求的starttime（管理员可能决定禁止某些类型或范围的过期票证），如果票证的starttime是可接受的，则将其设置为请求的starttime，并在新票证中设置无效标志。过期票据必须在到达起始时间后通过向KDC出示的方式在使用前进行验证。
The expiration time of the ticket will be set to the earlier of the requested endtime and a time determined by local policy, possibly by using realm- or principal-specific factors. For example, the expiration time MAY be set to the earliest of the following:
票证的过期时间将设置为请求的endtime中较早的一个，时间由本地策略确定，可能使用领域或主要特定因素。例如，到期时间可以设置为以下最早的时间：
* The expiration time (endtime) requested in the KRB_AS_REQ message.
* KRB_AS_REQ消息中请求的过期时间（endtime）。
* The ticket's starttime plus the maximum allowable lifetime associated with the client principal from the authentication server's database.
* 票证的开始时间加上与身份验证服务器数据库中的客户端主体关联的最大允许生存期。
* The ticket's starttime plus the maximum allowable lifetime associated with the server principal.
* 票证的开始时间加上与服务器主体关联的最大允许生存期。
* The ticket's starttime plus the maximum lifetime set by the policy of the local realm.
* 票证的开始时间加上本地域策略设置的最大生存期。
If the requested expiration time minus the starttime (as determined above) is less than a site-determined minimum lifetime, an error message with code KDC_ERR_NEVER_VALID is returned. If the requested expiration time for the ticket exceeds what was determined as above, and if the 'RENEWABLE-OK' option was requested, then the 'RENEWABLE'
如果请求的过期时间减去开始时间（如上所述）小于站点确定的最小生存期，则返回代码为KDC_ERR_NEVER_VALID的错误消息。如果请求的票证过期时间超过上述确定的时间，并且如果请求了“RENERABLE-OK”选项，则“RENERABLE”
flag is set in the new ticket, and the renew-till value is set as if the 'RENEWABLE' option were requested (the field and option names are described fully in Section 5.4.1).
在新票据中设置标志，并将“续费至”值设置为请求“续费”选项（字段和选项名称在第5.4.1节中有详细说明）。
If the RENEWABLE option has been requested or if the RENEWABLE-OK option has been set and a renewable ticket is to be issued, then the renew-till field MAY be set to the earliest of:
如果已请求可续期选项，或者已设置可续期-OK选项，且将发行可续期票据，则可将“续期至”字段设置为以下最早的选项：
* Its requested value.
* 它的请求值。
* The starttime of the ticket plus the minimum of the two maximum renewable lifetimes associated with the principals' database entries.
* 票证的开始时间加上与主体数据库条目相关联的两个最大可更新生存期中的最小值。
* The starttime of the ticket plus the maximum renewable lifetime set by the policy of the local realm.
* 票证的开始时间加上本地域策略设置的最大可更新生存期。
The flags field of the new ticket will have the following options set if they have been requested and if the policy of the local realm allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE. If the new ticket is postdated (the starttime is in the future), its INVALID flag will also be set.
如果已请求新票证的标志字段，并且本地域的策略允许，则新票证的标志字段将设置以下选项：可转发、可过期、可代理、可续订。如果新票证是过期的（起始时间在将来），则也将设置其无效标志。
If all of the above succeed, the server will encrypt the ciphertext part of the ticket using the encryption key extracted from the server principal's record in the Kerberos database using the encryption type associated with the server principal's key. (This choice is NOT affected by the etype field in the request.) It then formats a KRB_AS_REP message (see Section 5.4.2), copying the addresses in the request into the caddr of the response, placing any required pre-authentication data into the padata of the response, and encrypts the ciphertext part in the client's key using an acceptable encryption method requested in the etype field of the request, or in some key specified by pre-authentication mechanisms being used.
如果上述所有操作都成功，服务器将使用从Kerberos数据库中的服务器主体记录中提取的加密密钥，使用与服务器主体密钥关联的加密类型，对票据的密文部分进行加密。（此选择不受请求中的etype字段的影响。）然后格式化KRB_AS_REP消息（参见第5.4.2节），将请求中的地址复制到响应的caddr中，将任何所需的预验证数据放入响应的padata中，以及使用在请求的etype字段中请求的可接受的加密方法，或者在所使用的预认证机制指定的某些密钥中，对客户端密钥中的密文部分进行加密。
Several errors can occur, and the Authentication Server responds by returning an error message, KRB_ERROR, to the client, with the error-code and e-text fields set to appropriate values. The error message contents and details are described in Section 5.9.1.
可能会发生多个错误，身份验证服务器通过向客户端返回错误消息KRB_error作出响应，并将错误代码和电子文本字段设置为适当的值。第5.9.1节描述了错误消息的内容和详细信息。
If the reply message type is KRB_AS_REP, then the client verifies that the cname and crealm fields in the cleartext portion of the reply match what it requested. If any padata fields are present, they may be used to derive the proper secret key to decrypt the
如果回复消息类型为KRB_AS_REP，那么客户端将验证回复的明文部分中的cname和crealm字段是否与它所请求的匹配。如果存在任何padata字段，则可以使用这些字段派生正确的密钥来解密数据
message. The client decrypts the encrypted part of the response using its secret key and verifies that the nonce in the encrypted part matches the nonce it supplied in its request (to detect replays). It also verifies that the sname and srealm in the response match those in the request (or are otherwise expected values), and that the host address field is also correct. It then stores the ticket, session key, start and expiration times, and other information for later use. The last-req field (and the deprecated key-expiration field) from the encrypted part of the response MAY be checked to notify the user of impending key expiration. This enables the client program to suggest remedial action, such as a password change.
消息客户端使用其密钥对响应的加密部分进行解密，并验证加密部分中的nonce是否与其请求中提供的nonce匹配（以检测重播）。它还验证响应中的sname和srealm是否与请求中的sname和srealm匹配（或者是预期值），以及主机地址字段是否正确。然后，它存储票据、会话密钥、开始和过期时间以及其他信息以供以后使用。可以检查响应的加密部分的最后一个req字段（以及不推荐使用的密钥过期字段），以通知用户密钥即将过期。这使客户端程序能够建议补救措施，例如更改密码。
Upon validation of the KRB_AS_REP message (by checking the returned nonce against that sent in the KRB_AS_REQ message), the client knows that the current time on the KDC is that read from the authtime field of the encrypted part of the reply. The client can optionally use this value for clock synchronization in subsequent messages by recording with the ticket the difference (offset) between the authtime value and the local clock. This offset can then be used by the same user to adjust the time read from the system clock when generating messages [DGT96].
验证KRB_AS_REP消息后（通过检查返回的nonce与KRB_AS_REQ消息中发送的nonce），客户机知道KDC上的当前时间是从应答加密部分的authtime字段读取的时间。客户端可以选择在后续消息中使用此值进行时钟同步，方法是使用票证记录authtime值和本地时钟之间的差值（偏移量）。然后，该偏移量可由同一用户用于调整生成消息时从系统时钟读取的时间[DGT96]。
This technique MUST be used when adjusting for clock skew instead of directly changing the system clock, because the KDC reply is only authenticated to the user whose secret key was used, but not to the system or workstation. If the clock were adjusted, an attacker colluding with a user logging into a workstation could agree on a password, resulting in a KDC reply that would be correctly validated even though it did not originate from a KDC trusted by the workstation.
在调整时钟偏移时必须使用此技术，而不是直接更改系统时钟，因为KDC应答只对使用密钥的用户进行身份验证，而不对系统或工作站进行身份验证。如果调整了时钟，攻击者与登录到工作站的用户勾结，可能会同意密码，从而导致KDC回复得到正确验证，即使它不是来自工作站信任的KDC。
Proper decryption of the KRB_AS_REP message is not sufficient for the host to verify the identity of the user; the user and an attacker could cooperate to generate a KRB_AS_REP format message that decrypts properly but is not from the proper KDC. If the host wishes to verify the identity of the user, it MUST require the user to present application credentials that can be verified using a securely-stored secret key for the host. If those credentials can be verified, then the identity of the user can be assured.
对KRB_AS_REP消息的正确解密不足以让主机验证用户的身份；用户和攻击者可以合作生成KRB_AS_REP格式的消息，该消息可以正确解密，但不是来自正确的KDC。如果主机希望验证用户的身份，则必须要求用户提供可使用安全存储的主机密钥验证的应用程序凭据。如果可以验证这些凭据，则可以确保用户的身份。
If the reply message type is KRB_ERROR, then the client interprets it as an error and performs whatever application-specific tasks are necessary for recovery.
如果回复消息类型为KRB_ERROR，则客户端将其解释为错误，并执行恢复所需的任何特定于应用程序的任务。
Summary
总结
Message direction Message type Section Client to Application server KRB_AP_REQ 5.5.1 [optional] Application server to client KRB_AP_REP or 5.5.2 KRB_ERROR 5.9.1
消息方向消息类型部分客户端到应用服务器KRB_AP_REQ 5.5.1[可选]应用服务器到客户端KRB_AP_REP或5.5.2 KRB_错误5.9.1
The client/server authentication (CS) exchange is used by network applications to authenticate the client to the server and vice versa. The client MUST have already acquired credentials for the server using the AS or TGS exchange.
网络应用程序使用客户机/服务器身份验证（CS）交换来向服务器验证客户机，反之亦然。客户端必须已经使用AS或TGS exchange获取了服务器的凭据。
The KRB_AP_REQ contains authentication information that SHOULD be part of the first message in an authenticated transaction. It contains a ticket, an authenticator, and some additional bookkeeping information (see Section 5.5.1 for the exact format). The ticket by itself is insufficient to authenticate a client, since tickets are passed across the network in cleartext (tickets contain both an encrypted and unencrypted portion, so cleartext here refers to the entire unit, which can be copied from one message and replayed in another without any cryptographic skill). The authenticator is used to prevent invalid replay of tickets by proving to the server that the client knows the session key of the ticket and thus is entitled to use the ticket. The KRB_AP_REQ message is referred to elsewhere as the 'authentication header'.
KRB_AP_REQ包含身份验证信息，该信息应该是经过身份验证的事务中第一条消息的一部分。它包含一张票据、一个验证器和一些额外的簿记信息（具体格式见第5.5.1节）。票据本身不足以对客户机进行身份验证，因为票据是以明文形式通过网络传递的（票据包含加密和未加密的部分，因此这里的明文指的是整个单元，它可以从一条消息复制并在另一条消息中重播，而无需任何加密技巧）。身份验证器用于通过向服务器证明客户端知道票据的会话密钥，从而有权使用票据，从而防止票据的无效重放。KRB_AP_REQ消息在别处称为“身份验证头”。
When a client wishes to initiate authentication to a server, it obtains (either through a credentials cache, the AS exchange, or the TGS exchange) a ticket and session key for the desired service. The client MAY re-use any tickets it holds until they expire. To use a ticket, the client constructs a new Authenticator from the system time and its name, and optionally from an application-specific checksum, an initial sequence number to be used in KRB_SAFE or KRB_PRIV messages, and/or a session subkey to be used in negotiations for a session key unique to this particular session. Authenticators MUST NOT be re-used and SHOULD be rejected if replayed to a server. Note that this can make applications based on unreliable transports difficult to code correctly. If the transport might deliver duplicated messages, either a new authenticator MUST be generated for each retry, or the application server MUST match requests and replies and replay the first reply in response to a detected duplicate.
当客户端希望启动对服务器的身份验证时，它会（通过凭据缓存、AS exchange或TGS exchange）获取所需服务的票证和会话密钥。客户可以重复使用其持有的任何票据，直至其到期。要使用票据，客户机根据系统时间及其名称，以及可选地根据特定于应用程序的校验和、在KRB_安全或KRB_PRIV消息中使用的初始序列号和/或在协商该特定会话唯一的会话密钥时使用的会话子密钥来构造新的验证器。验证器不得重复使用，如果重播到服务器，则应拒绝使用。请注意，这会使基于不可靠传输的应用程序难以正确编码。如果传输可能传递重复的消息，则必须为每次重试生成新的身份验证程序，或者应用程序服务器必须匹配请求和回复，并重播第一个回复以响应检测到的重复。
If a sequence number is to be included, it SHOULD be randomly chosen so that even after many messages have been exchanged it is not likely to collide with other sequence numbers in use.
如果要包括一个序列号，则应随机选择该序列号，以便即使在交换了许多消息之后，它也不可能与正在使用的其他序列号发生冲突。
The client MAY indicate a requirement of mutual authentication or the use of a session-key based ticket (for user-to-user authentication, see section 3.7) by setting the appropriate flag(s) in the ap-options field of the message.
客户端可以通过在消息的ap选项字段中设置适当的标志来指示相互认证的要求或使用基于会话密钥的票据（对于用户对用户的认证，请参见第3.7节）。
The Authenticator is encrypted in the session key and combined with the ticket to form the KRB_AP_REQ message, which is then sent to the end server along with any additional application-specific information.
验证器在会话密钥中加密，并与票据组合以形成KRB_AP_REQ消息，然后将该消息与任何附加的特定于应用程序的信息一起发送到终端服务器。
Authentication is based on the server's current time of day (clocks MUST be loosely synchronized), the authenticator, and the ticket. Several errors are possible. If an error occurs, the server is expected to reply to the client with a KRB_ERROR message. This message MAY be encapsulated in the application protocol if its raw form is not acceptable to the protocol. The format of error messages is described in Section 5.9.1.
身份验证基于服务器的当前时间（时钟必须松散同步）、身份验证程序和票据。可能有几个错误。如果发生错误，服务器将向客户端回复KRB_错误消息。如果协议不接受此消息的原始形式，则可以将其封装在应用程序协议中。第5.9.1节描述了错误消息的格式。
The algorithm for verifying authentication information is as follows. If the message type is not KRB_AP_REQ, the server returns the KRB_AP_ERR_MSG_TYPE error. If the key version indicated by the Ticket in the KRB_AP_REQ is not one the server can use (e.g., it indicates an old key, and the server no longer possesses a copy of the old key), the KRB_AP_ERR_BADKEYVER error is returned. If the USE-SESSION-KEY flag is set in the ap-options field, it indicates to the server that user-to-user authentication is in use, and that the ticket is encrypted in the session key from the server's TGT rather than in the server's secret key. See Section 3.7 for a more complete description of the effect of user-to-user authentication on all messages in the Kerberos protocol.
验证身份验证信息的算法如下所示。如果消息类型不是KRB_AP_REQ，服务器将返回KRB_AP_ERR_MSG_type错误。如果KRB_AP_REQ中票证指示的密钥版本不是服务器可以使用的版本（例如，它指示旧密钥，并且服务器不再拥有旧密钥的副本），则返回KRB_AP_ERR_BADKEYVER错误。如果在ap选项字段中设置了USE-SESSION-KEY标志，则它向服务器指示正在使用用户对用户的身份验证，并且票据在来自服务器TGT的会话密钥中加密，而不是在服务器的密钥中加密。有关用户对用户身份验证对Kerberos协议中所有消息的影响的更完整描述，请参见第3.7节。
Because it is possible for the server to be registered in multiple realms, with different keys in each, the srealm field in the unencrypted portion of the ticket in the KRB_AP_REQ is used to specify which secret key the server should use to decrypt that ticket. The KRB_AP_ERR_NOKEY error code is returned if the server doesn't have the proper key to decipher the ticket.
由于服务器可以在多个域中注册，每个域中都有不同的密钥，因此KRB_AP_REQ中票据未加密部分的srealm字段用于指定服务器应使用哪个密钥解密票据。如果服务器没有正确的密钥来解密票据，则返回KRB_AP_ERR_NOKEY错误代码。
The ticket is decrypted using the version of the server's key specified by the ticket. If the decryption routines detect a modification of the ticket (each encryption system MUST provide safeguards to detect modified ciphertext), the
使用票证指定的服务器密钥版本对票证进行解密。如果解密例程检测到票据的修改（每个加密系统必须提供保护以检测修改的密文），则
KRB_AP_ERR_BAD_INTEGRITY error is returned (chances are good that different keys were used to encrypt and decrypt).
返回KRB_AP_ERR_BAD_完整性错误（很可能使用不同的密钥进行加密和解密）。
The authenticator is decrypted using the session key extracted from the decrypted ticket. If decryption shows that is has been modified, the KRB_AP_ERR_BAD_INTEGRITY error is returned. The name and realm of the client from the ticket are compared against the same fields in the authenticator. If they don't match, the KRB_AP_ERR_BADMATCH error is returned; normally this is caused by a client error or an attempted attack. The addresses in the ticket (if any) are then searched for an address matching the operating-system reported address of the client. If no match is found or the server insists on ticket addresses but none are present in the ticket, the KRB_AP_ERR_BADADDR error is returned. If the local (server) time and the client time in the authenticator differ by more than the allowable clock skew (e.g., 5 minutes), the KRB_AP_ERR_SKEW error is returned.
使用从解密的票证中提取的会话密钥对验证器进行解密。如果解密显示is已被修改，则返回KRB_AP_ERR_BAD_完整性错误。将票据中客户端的名称和域与验证器中的相同字段进行比较。如果不匹配，则返回KRB_AP_ERR_BADMATCH错误；通常，这是由客户端错误或尝试的攻击引起的。然后搜索票证中的地址（如果有），以查找与操作系统报告的客户端地址匹配的地址。如果未找到匹配项，或者服务器坚持使用票证地址，但票证中不存在任何地址，则返回KRB_AP_ERR_BADADDR错误。如果验证器中的本地（服务器）时间和客户端时间相差超过允许的时钟偏差（例如，5分钟），则返回KRB_AP_ERR_skew错误。
Unless the application server provides its own suitable means to protect against replay (for example, a challenge-response sequence initiated by the server after authentication, or use of a server-generated encryption subkey), the server MUST utilize a replay cache to remember any authenticator presented within the allowable clock skew. Careful analysis of the application protocol and implementation is recommended before eliminating this cache. The replay cache will store at least the server name, along with the client name, time, and microsecond fields from the recently-seen authenticators, and if a matching tuple is found, the KRB_AP_ERR_REPEAT error is returned. Note that the rejection here is restricted to authenticators from the same principal to the same server. Other client principals communicating with the same server principal should not have their authenticators rejected if the time and microsecond fields happen to match some other client's authenticator.
除非应用服务器提供其自己的适当方法来防止重播（例如，在认证后由服务器启动的质询响应序列，或使用服务器生成的加密子密钥），否则服务器必须利用重播缓存来记住在允许的时钟偏差内出现的任何验证器。建议在消除此缓存之前仔细分析应用程序协议和实现。replay缓存将至少存储服务器名称，以及最近看到的验证器中的客户端名称、时间和微秒字段，如果找到匹配的元组，则返回KRB_AP_ERR_REPEAT错误。请注意，此处的拒绝仅限于来自同一主体到同一服务器的身份验证程序。如果时间和微秒字段恰好与其他客户端的验证器匹配，则与同一服务器主体通信的其他客户端主体不应拒绝其验证器。
If a server loses track of authenticators presented within the allowable clock skew, it MUST reject all requests until the clock skew interval has passed, providing assurance that any lost or replayed authenticators will fall outside the allowable clock skew and can no longer be successfully replayed. If this were not done, an attacker could subvert the authentication by recording the ticket and authenticator sent over the network to a server and replaying them following an event that caused the server to lose track of recently seen authenticators.
如果服务器无法跟踪在允许的时钟偏移范围内显示的验证器，则必须拒绝所有请求，直到超过时钟偏移间隔，从而确保任何丢失或重放的验证器都将超出允许的时钟偏移范围，并且无法再成功重放。如果不这样做，攻击者可以通过记录通过网络发送到服务器的票据和验证器，并在导致服务器无法跟踪最近看到的验证器的事件发生后重新播放这些票据和验证器来破坏身份验证。
Implementation note: If a client generates multiple requests to the KDC with the same timestamp, including the microsecond field, all but the first of the requests received will be rejected as replays. This
实现说明：如果客户机向KDC生成具有相同时间戳的多个请求，包括微秒字段，则除了第一个请求外，所有接收到的请求都将作为重播被拒绝。这
might happen, for example, if the resolution of the client's clock is too coarse. Client implementations SHOULD ensure that the timestamps are not reused, possibly by incrementing the microseconds field in the time stamp when the clock returns the same time for multiple requests.
例如，如果客户端时钟的分辨率太粗，可能会发生这种情况。客户端实现应确保时间戳不被重用，可能是在时钟返回多个请求的相同时间时，通过增加时间戳中的微秒字段来实现。
If multiple servers (for example, different services on one machine, or a single service implemented on multiple machines) share a service principal (a practice that we do not recommend in general, but that we acknowledge will be used in some cases), either they MUST share this replay cache, or the application protocol MUST be designed so as to eliminate the need for it. Note that this applies to all of the services. If any of the application protocols does not have replay protection built in, an authenticator used with such a service could later be replayed to a different service with the same service principal but no replay protection, if the former doesn't record the authenticator information in the common replay cache.
如果多台服务器（例如，一台机器上的不同服务，或在多台机器上实现的单个服务）共享一个服务主体（我们一般不推荐这种做法，但我们承认在某些情况下会使用这种做法），则它们必须共享此重播缓存，或者，必须设计应用程序协议以消除对它的需求。请注意，这适用于所有服务。如果任何应用程序协议没有内置重播保护，则与此类服务一起使用的验证器稍后可以重播到具有相同服务主体但没有重播保护的不同服务，前提是前者没有在公共重播缓存中记录验证器信息。
If a sequence number is provided in the authenticator, the server saves it for later use in processing KRB_SAFE and/or KRB_PRIV messages. If a subkey is present, the server either saves it for later use or uses it to help generate its own choice for a subkey to be returned in a KRB_AP_REP message.
如果验证器中提供了序列号，服务器将保存该序列号以供以后处理KRB_安全和/或KRB_PRIV消息时使用。如果存在子项，服务器会将其保存以供以后使用，或者使用它来帮助生成自己的子项选择，以便在KRB_AP_REP消息中返回。
The server computes the age of the ticket: local (server) time minus the starttime inside the Ticket. If the starttime is later than the current time by more than the allowable clock skew, or if the INVALID flag is set in the ticket, the KRB_AP_ERR_TKT_NYV error is returned. Otherwise, if the current time is later than end time by more than the allowable clock skew, the KRB_AP_ERR_TKT_EXPIRED error is returned.
服务器计算票证的有效期：本地（服务器）时间减去票证内的开始时间。如果开始时间晚于当前时间超过允许的时钟偏差，或者如果在记录单中设置了无效标志，则返回KRB_AP_ERR_TKT_NYV错误。否则，如果当前时间晚于结束时间超过允许的时钟偏差，则返回KRB_AP_ERR_TKT_EXPIRED错误。
If all these checks succeed without an error, the server is assured that the client possesses the credentials of the principal named in the ticket, and thus, that the client has been authenticated to the server.
如果所有这些检查都成功且没有错误，则服务器将确保客户端拥有票据中指定的主体的凭据，从而确保客户端已通过服务器的身份验证。
Passing these checks provides only authentication of the named principal; it does not imply authorization to use the named service. Applications MUST make a separate authorization decision based upon the authenticated name of the user, the requested operation, local access control information such as that contained in a .k5login or .k5users file, and possibly a separate distributed authorization service.
通过这些检查只提供命名主体的身份验证；这并不意味着授权使用命名服务。应用程序必须根据经过身份验证的用户名称、请求的操作、本地访问控制信息（如.k5login或.k5users文件中包含的信息）以及可能的单独分布式授权服务做出单独的授权决定。
Typically, a client's request will include both the authentication information and its initial request in the same message, and the server need not explicitly reply to the KRB_AP_REQ. However, if mutual authentication (authenticating not only the client to the server, but also the server to the client) is being performed, the KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message is required in response. As with the error message, this message MAY be encapsulated in the application protocol if its "raw" form is not acceptable to the application's protocol. The timestamp and microsecond field used in the reply MUST be the client's timestamp and microsecond field (as provided in the authenticator). If a sequence number is to be included, it SHOULD be randomly chosen as described above for the authenticator. A subkey MAY be included if the server desires to negotiate a different subkey. The KRB_AP_REP message is encrypted in the session key extracted from the ticket.
通常，客户机的请求将在同一消息中包括身份验证信息及其初始请求，并且服务器不需要显式地回复KRB_AP_REQ。但是，如果正在执行相互身份验证（不仅验证客户端到服务器的身份，还验证服务器到客户端的身份），则KRB_AP_REQ消息将在其AP选项字段中设置相互要求，并且需要KRB_AP_REP消息作为响应。与错误消息一样，如果应用程序协议不接受此消息的“原始”形式，则可以将其封装在应用程序协议中。回复中使用的时间戳和微秒字段必须是客户端的时间戳和微秒字段（如验证器中提供的）。如果要包括序列号，则应如上所述为验证器随机选择序列号。如果服务器希望协商不同的子密钥，则可以包括子密钥。KRB_AP_REP消息在从票据中提取的会话密钥中加密。
Note that in the Kerberos Version 4 protocol, the timestamp in the reply was the client's timestamp plus one. This is not necessary in Version 5 because Version 5 messages are formatted in such a way that it is not possible to create the reply by judicious message surgery (even in encrypted form) without knowledge of the appropriate encryption keys.
注意，在Kerberos版本4协议中，回复中的时间戳是客户机的时间戳加上一。这在版本5中是不必要的，因为版本5消息的格式使得在不知道适当的加密密钥的情况下，不可能通过明智的消息操作（即使是加密形式）创建回复。
If a KRB_AP_REP message is returned, the client uses the session key from the credentials obtained for the server to decrypt the message and verifies that the timestamp and microsecond fields match those in the Authenticator it sent to the server. If they match, then the client is assured that the server is genuine. The sequence number and subkey (if present) are retained for later use. (Note that for encrypting the KRB_AP_REP message, the sub-session key is not used, even if it is present in the Authentication.)
如果返回KRB_AP_REP消息，客户端将使用从服务器获取的凭据中获取的会话密钥对消息进行解密，并验证时间戳和微秒字段是否与发送到服务器的身份验证程序中的字段匹配。如果它们匹配，则客户机可以确保服务器是真实的。序列号和子键（如果存在）将保留以供以后使用。（请注意，对于加密KRB_AP_REP消息，不使用子会话密钥，即使它存在于身份验证中。）
After the KRB_AP_REQ/KRB_AP_REP exchange has occurred, the client and server share an encryption key that can be used by the application. In some cases, the use of this session key will be implicit in the protocol; in others the method of use must be chosen from several alternatives. The application MAY choose the actual encryption key to be used for KRB_PRIV, KRB_SAFE, or other application-specific uses based on the session key from the ticket and subkeys in the KRB_AP_REP message and the authenticator. Implementations of the protocol MAY provide routines to choose subkeys based on session keys
在KRB_AP_REQ/KRB_AP_REP交换发生后，客户端和服务器共享一个可由应用程序使用的加密密钥。在某些情况下，该会话密钥的使用将隐含在协议中；在其他情况下，使用方法必须从几个备选方案中选择。应用程序可以根据KRB_AP_REP消息和验证器中的票据和子密钥中的会话密钥，选择用于KRB_PRIV、KRB_SAFE或其他应用程序特定用途的实际加密密钥。协议的实现可以提供基于会话密钥选择子密钥的例程
and random numbers and to generate a negotiated key to be returned in the KRB_AP_REP message.
和随机数，并生成要在KRB_AP_REP消息中返回的协商密钥。
To mitigate the effect of failures in random number generation on the client, it is strongly encouraged that any key derived by an application for subsequent use include the full key entropy derived from the KDC-generated session key carried in the ticket. We leave the protocol negotiations of how to use the key (e.g., for selecting an encryption or checksum type) to the application programmer. The Kerberos protocol does not constrain the implementation options, but an example of how this might be done follows.
为了减轻随机数生成失败对客户端的影响，强烈建议应用程序派生的用于后续使用的任何密钥包括从票据中携带的KDC生成的会话密钥派生的完整密钥熵。我们将如何使用密钥（例如，选择加密或校验和类型）的协议协商留给应用程序程序员。Kerberos协议不限制实现选项，但下面是一个如何实现的示例。
One way that an application may choose to negotiate a key to be used for subsequent integrity and privacy protection is for the client to propose a key in the subkey field of the authenticator. The server can then choose a key using the key proposed by the client as input, returning the new subkey in the subkey field of the application reply. This key could then be used for subsequent communication.
应用程序可能选择协商用于后续完整性和隐私保护的密钥的一种方式是，客户端在验证器的子密钥字段中提出密钥。然后，服务器可以使用客户端建议的密钥作为输入来选择密钥，并在应用程序应答的子密钥字段中返回新的子密钥。然后，该键可用于后续通信。
With both the one-way and mutual authentication exchanges, the peers should take care not to send sensitive information to each other without proper assurances. In particular, applications that require privacy or integrity SHOULD use the KRB_AP_REP response from the server to the client to assure both client and server of their peer's identity. If an application protocol requires privacy of its messages, it can use the KRB_PRIV message (section 3.5). The KRB_SAFE message (Section 3.4) can be used to ensure integrity.
对于单向和相互身份验证交换，对等方应注意在没有适当保证的情况下不要相互发送敏感信息。特别是，需要隐私或完整性的应用程序应该使用从服务器到客户端的KRB_AP_REP响应来确保客户端和服务器的对等身份。如果应用程序协议要求其消息的隐私，它可以使用KRB_PRIV消息（第3.5节）。KRB_安全信息（第3.4节）可用于确保完整性。
Summary
总结
Message direction Message type Section 1. Client to Kerberos KRB_TGS_REQ 5.4.1 2. Kerberos to client KRB_TGS_REP or 5.4.2 KRB_ERROR 5.9.1
消息方向消息类型第1节。Kerberos KRB_TGS_REQ 5.4.1 2的客户端。Kerberos到客户端KRB_TGS_REP或5.4.2 KRB_错误5.9.1
The TGS exchange between a client and the Kerberos TGS is initiated by a client when it seeks to obtain authentication credentials for a given server (which might be registered in a remote realm), when it seeks to renew or validate an existing ticket, or when it seeks to obtain a proxy ticket. In the first case, the client must already have acquired a ticket for the Ticket-Granting Service using the AS exchange (the TGT is usually obtained when a client initially authenticates to the system, such as when a user logs in). The message format for the TGS exchange is almost identical to that for the AS exchange. The primary difference is that encryption and decryption in the TGS exchange does not take place under the client's
当客户端试图获取给定服务器（可能在远程领域中注册）的身份验证凭据时，当客户端试图续订或验证现有票证时，或者当客户端试图获取代理票证时，客户端将启动客户端和Kerberos TGS之间的TGS交换。在第一种情况下，客户机必须已经使用AS exchange获得了票证授予服务的票证（TGT通常在客户机最初向系统进行身份验证时获得，例如当用户登录时）。TGS交换的消息格式与AS交换的消息格式几乎相同。主要区别在于TGS交换中的加密和解密不是在客户端的
key. Instead, the session key from the TGT or renewable ticket, or sub-session key from an Authenticator is used. As is the case for all application servers, expired tickets are not accepted by the TGS, so once a renewable or TGT expires, the client must use a separate exchange to obtain valid tickets.
钥匙相反，使用来自TGT或可更新票证的会话密钥，或来自验证器的子会话密钥。与所有应用程序服务器一样，TGS不接受过期的票据，因此，一旦可续期或TGT过期，客户端必须使用单独的exchange来获取有效票据。
The TGS exchange consists of two messages: a request (KRB_TGS_REQ) from the client to the Kerberos Ticket-Granting Server, and a reply (KRB_TGS_REP or KRB_ERROR). The KRB_TGS_REQ message includes information authenticating the client plus a request for credentials. The authentication information consists of the authentication header (KRB_AP_REQ), which includes the client's previously obtained ticket-granting, renewable, or invalid ticket. In the TGT and proxy cases, the request MAY include one or more of the following: a list of network addresses, a collection of typed authorization data to be sealed in the ticket for authorization use by the application server, or additional tickets (the use of which are described later). The TGS reply (KRB_TGS_REP) contains the requested credentials, encrypted in the session key from the TGT or renewable ticket, or, if present, in the sub-session key from the Authenticator (part of the authentication header). The KRB_ERROR message contains an error code and text explaining what went wrong. The KRB_ERROR message is not encrypted. The KRB_TGS_REP message contains information that can be used to detect replays, and to associate it with the message to which it replies. The KRB_ERROR message also contains information that can be used to associate it with the message to which it replies. The same comments about integrity protection of KRB_ERROR messages mentioned in Section 3.1 apply to the TGS exchange.
TGS交换包含两条消息：从客户端到Kerberos票证授予服务器的请求（KRB_TGS_REQ）和回复（KRB_TGS_REP或KRB_ERROR）。KRB_TGS_REQ消息包括验证客户端的信息以及凭证请求。身份验证信息由身份验证头（KRB_AP_REQ）组成，其中包括客户端先前获得的票据授予、可更新或无效票据。在TGT和代理情况下，请求可以包括以下一个或多个：网络地址列表、要密封在票据中以供应用服务器使用的授权的键入授权数据集合，或者附加票据（其使用将在后面描述）。TGS回复（KRB_TGS_REP）包含请求的凭据，这些凭据在TGT或可更新票证的会话密钥中加密，或者，如果存在，在验证器（身份验证头的一部分）的子会话密钥中加密。KRB_错误消息包含错误代码和解释出错原因的文本。KRB_错误消息未加密。KRB_TGS_REP消息包含可用于检测重播的信息，并将其与它所回复的消息相关联。KRB_错误消息还包含可用于将其与所回复的消息关联的信息。第3.1节中提到的关于KRB_错误消息完整性保护的评论同样适用于TGS交换。
Before sending a request to the ticket-granting service, the client MUST determine in which realm the application server is believed to be registered. This can be accomplished in several ways. It might be known beforehand (since the realm is part of the principal identifier), it might be stored in a nameserver, or it might be obtained from a configuration file. If the realm to be used is obtained from a nameserver, there is a danger of being spoofed if the nameservice providing the realm name is not authenticated. This might result in the use of a realm that has been compromised, which would result in an attacker's ability to compromise the authentication of the application server to the client.
在向票证授予服务发送请求之前，客户端必须确定应用程序服务器被认为是在哪个领域注册的。这可以通过几种方式实现。它可能是预先知道的（因为领域是主体标识符的一部分），它可能存储在名称服务器中，或者可以从配置文件中获取。如果要使用的领域是从名称服务器获取的，则如果提供领域名称的名称服务未经过身份验证，则存在被欺骗的危险。这可能会导致使用已被破坏的领域，这将导致攻击者破坏应用程序服务器对客户端的身份验证。
If the client knows the service principal name and realm and it does not already possess a TGT for the appropriate realm, then one must be obtained. This is first attempted by requesting a TGT for the destination realm from a Kerberos server for which the client possesses a TGT (by using the KRB_TGS_REQ message recursively). The
如果客户机知道服务主体名称和领域，但它还没有相应领域的TGT，那么必须获得一个TGT。首先尝试从客户机拥有TGT的Kerberos服务器请求目标域的TGT（通过递归使用KRB_TGS_REQ消息）。这个
Kerberos server MAY return a TGT for the desired realm, in which case one can proceed. Alternatively, the Kerberos server MAY return a TGT for a realm that is 'closer' to the desired realm (further along the standard hierarchical path between the client's realm and the requested realm server's realm). Note that in this case misconfiguration of the Kerberos servers may cause loops in the resulting authentication path, which the client should be careful to detect and avoid.
Kerberos服务器可能会返回所需领域的TGT，在这种情况下可以继续。或者，Kerberos服务器可以返回与所需领域“更接近”的领域的TGT（沿着客户机领域和请求的领域服务器领域之间的标准分层路径）。请注意，在这种情况下，Kerberos服务器的错误配置可能会导致生成的身份验证路径中出现循环，客户端应小心检测并避免这种情况。
If the Kerberos server returns a TGT for a realm 'closer' than the desired realm, the client MAY use local policy configuration to verify that the authentication path used is an acceptable one. Alternatively, a client MAY choose its own authentication path, rather than rely on the Kerberos server to select one. In either case, any policy or configuration information used to choose or validate authentication paths, whether by the Kerberos server or by the client, MUST be obtained from a trusted source.
如果Kerberos服务器返回一个比所需域“更近”的域的TGT，则客户端可以使用本地策略配置来验证所使用的身份验证路径是否是可接受的路径。或者，客户机可以选择自己的身份验证路径，而不是依赖Kerberos服务器来选择。在任何一种情况下，用于选择或验证身份验证路径的任何策略或配置信息（无论是由Kerberos服务器还是由客户端）都必须从可信源获取。
When a client obtains a TGT that is 'closer' to the destination realm, the client MAY cache this ticket and reuse it in future KRB-TGS exchanges with services in the 'closer' realm. However, if the client were to obtain a TGT for the 'closer' realm by starting at the initial KDC rather than as part of obtaining another ticket, then a shorter path to the 'closer' realm might be used. This shorter path may be desirable because fewer intermediate KDCs would know the session key of the ticket involved. For this reason, clients SHOULD evaluate whether they trust the realms transited in obtaining the 'closer' ticket when making a decision to use the ticket in future.
当客户端获得一个距离目标域“更近”的TGT时，客户端可能会缓存该票证，并在将来与“更近”域中的服务进行KRB-TGS交换时重用它。但是，如果客户机要通过从初始KDC开始而不是作为获取另一个票证的一部分来获取“closer”领域的TGT，则可能会使用到“closer”领域的较短路径。这种较短的路径可能是可取的，因为知道所涉及票据的会话密钥的中间KDC更少。因此，客户在做出将来使用票据的决定时，应评估他们是否信任在获得“更接近”票据时转移的领域。
Once the client obtains a TGT for the appropriate realm, it determines which Kerberos servers serve that realm and contacts one of them. The list might be obtained through a configuration file or network service, or it MAY be generated from the name of the realm. As long as the secret keys exchanged by realms are kept secret, only denial of service results from using a false Kerberos server.
一旦客户机获得相应领域的TGT，它将确定哪些Kerberos服务器为该领域服务，并与其中一个服务器联系。该列表可以通过配置文件或网络服务获得，也可以从领域名称生成。只要域交换的密钥是保密的，使用错误的Kerberos服务器只会导致拒绝服务。
As in the AS exchange, the client MAY specify a number of options in the KRB_TGS_REQ message. One of these options is the ENC-TKT-IN-SKEY option used for user-to-user authentication. An overview of user-to-user authentication can be found in Section 3.7. When generating the KRB_TGS_REQ message, this option indicates that the client is including a TGT obtained from the application server in the additional tickets field of the request and that the KDC SHOULD encrypt the ticket for the application server using the session key from this additional ticket, instead of a server key from the principal database.
在As交换中，客户机可以在KRB_TGS_REQ消息中指定许多选项。其中一个选项是用于用户对用户身份验证的ENC-TKT-IN-SKEY选项。用户对用户身份验证的概述见第3.7节。生成KRB_TGS_REQ消息时，此选项表示客户端在请求的附加票证字段中包含从应用服务器获得的TGT，并且KDC应使用此附加票证中的会话密钥加密应用服务器的票证，而不是主体数据库中的服务器密钥。
The client prepares the KRB_TGS_REQ message, providing an authentication header as an element of the padata field, and including the same fields as used in the KRB_AS_REQ message along with several optional fields: the enc-authorizatfion-data field for application server use and additional tickets required by some options.
客户端准备KRB_TGS_REQ消息，提供身份验证标头作为padata字段的一个元素，并包括与KRB_as_REQ消息中使用的字段相同的字段以及几个可选字段：用于应用程序服务器使用的enc authorizatfion数据字段和某些选项所需的附加票证。
In preparing the authentication header, the client can select a sub-session key under which the response from the Kerberos server will be encrypted. If the client selects a sub-session key, care must be taken to ensure the randomness of the selected sub-session key.
在准备身份验证标头时，客户端可以选择一个子会话密钥，在该密钥下，来自Kerberos服务器的响应将被加密。如果客户端选择子会话密钥，则必须注意确保所选子会话密钥的随机性。
If the sub-session key is not specified, the session key from the TGT will be used. If the enc-authorization-data is present, it MUST be encrypted in the sub-session key, if present, from the authenticator portion of the authentication header, or, if not present, by using the session key from the TGT.
如果未指定子会话密钥，则将使用来自TGT的会话密钥。如果存在enc授权数据，则必须使用子会话密钥（如果存在）对其进行加密，该密钥来自身份验证标头的验证器部分，如果不存在，则使用TGT的会话密钥。
Once prepared, the message is sent to a Kerberos server for the destination realm.
准备好后，将消息发送到目标域的Kerberos服务器。
The KRB_TGS_REQ message is processed in a manner similar to the KRB_AS_REQ message, but there are many additional checks to be performed. First, the Kerberos server MUST determine which server the accompanying ticket is for, and it MUST select the appropriate key to decrypt it. For a normal KRB_TGS_REQ message, it will be for the ticket-granting service, and the TGS's key will be used. If the TGT was issued by another realm, then the appropriate inter-realm key MUST be used. If (a) the accompanying ticket is not a TGT for the current realm, but is for an application server in the current realm, (b) the RENEW, VALIDATE, or PROXY options are specified in the request, and (c) the server for which a ticket is requested is the server named in the accompanying ticket, then the KDC will decrypt the ticket in the authentication header using the key of the server for which it was issued. If no ticket can be found in the padata field, the KDC_ERR_PADATA_TYPE_NOSUPP error is returned.
KRB_TGS_REQ消息的处理方式与KRB_AS_REQ消息类似，但还有许多其他检查需要执行。首先，Kerberos服务器必须确定附带的票证用于哪个服务器，并且必须选择适当的密钥对其进行解密。对于正常的KRB_TGS_REQ消息，它将用于票据授予服务，并且将使用TGS的密钥。如果TGT是由另一个域发出的，则必须使用适当的域间密钥。如果（a）随附票证不是当前领域的TGT，而是当前领域中的应用程序服务器的TGT，（b）在请求中指定了续订、验证或代理选项，以及（c）为其请求票证的服务器是随附票证中指定的服务器，然后KDC将使用为其颁发票据的服务器的密钥对身份验证头中的票据进行解密。如果在padata字段中找不到票证，则返回KDC_ERR_padata_TYPE_NOSUPP错误。
Once the accompanying ticket has been decrypted, the user-supplied checksum in the Authenticator MUST be verified against the contents of the request, and the message MUST be rejected if the checksums do not match (with an error code of KRB_AP_ERR_MODIFIED) or if the checksum is not collision-proof (with an error code of KRB_AP_ERR_INAPP_CKSUM). If the checksum type is not supported, the KDC_ERR_SUMTYPE_NOSUPP error is returned. If the authorization-data are present, they are decrypted using the sub-session key from the Authenticator.
解密随附票据后，必须根据请求内容验证验证器中用户提供的校验和，如果校验和不匹配（错误代码为KRB_AP_ERR_MODIFIED）或校验和不防冲突（错误代码为KRB_AP_ERR_INAPP_CKSUM），则必须拒绝消息。如果不支持校验和类型，则返回KDC_ERR_SUMTYPE_NOSUPP错误。如果存在授权数据，则使用来自验证器的子会话密钥对其进行解密。
If any of the decryptions indicate failed integrity checks, the KRB_AP_ERR_BAD_INTEGRITY error is returned.
如果任何解密指示完整性检查失败，则返回KRB_AP_ERR_BAD_完整性错误。
As discussed in Section 3.1.2, the KDC MUST send a valid KRB_TGS_REP message if it receives a KRB_TGS_REQ message identical to one it has recently processed. However, if the authenticator is a replay, but the rest of the request is not identical, then the KDC SHOULD return KRB_AP_ERR_REPEAT.
如第3.1.2节所述，如果KDC收到与其最近处理的KRB_TGS_REQ消息相同的KRB_TGS_REP消息，则必须发送有效的KRB_TGS_REP消息。但是，如果验证器是重播，但请求的其余部分不相同，那么KDC应该返回KRB_AP_ERR_REPEAT。
The KRB_TGS_REP message shares its format with the KRB_AS_REP (KRB_KDC_REP), but with its type field set to KRB_TGS_REP. The detailed specification is in Section 5.4.2.
KRB_TGS_REP消息与KRB_AS_REP（KRB_KDC_REP）共享其格式，但其类型字段设置为KRB_TGS_REP。详细规范见第5.4.2节。
The response will include a ticket for the requested server or for a ticket granting server of an intermediate KDC to be contacted to obtain the requested ticket. The Kerberos database is queried to retrieve the record for the appropriate server (including the key with which the ticket will be encrypted). If the request is for a TGT for a remote realm, and if no key is shared with the requested realm, then the Kerberos server will select the realm 'closest' to the requested realm with which it does share a key and use that realm instead. This is the only case where the response for the KDC will be for a different server than that requested by the client.
响应将包括请求的服务器或中间KDC的票证授予服务器的票证，以获得请求的票证。查询Kerberos数据库以检索相应服务器的记录（包括票据将使用的密钥）。如果请求是针对远程领域的TGT，并且如果没有与请求的领域共享密钥，则Kerberos服务器将选择与请求的领域“最近”的领域，该领域与Kerberos服务器共享密钥，并改用该领域。这是唯一一种KDC响应将针对不同于客户端请求的服务器的情况。
By default, the address field, the client's name and realm, the list of transited realms, the time of initial authentication, the expiration time, and the authorization data of the newly-issued ticket will be copied from the TGT or renewable ticket. If the transited field needs to be updated, but the transited type is not supported, the KDC_ERR_TRTYPE_NOSUPP error is returned.
默认情况下，新发行票据的地址字段、客户端名称和领域、过渡领域列表、初始身份验证时间、过期时间和授权数据将从TGT或可更新票据中复制。如果需要更新transited字段，但不支持transited类型，则返回KDC_ERR_TRTYPE_NOSUPP错误。
If the request specifies an endtime, then the endtime of the new ticket is set to the minimum of (a) that request, (b) the endtime from the TGT, and (c) the starttime of the TGT plus the minimum of the maximum life for the application server and the maximum life for the local realm (the maximum life for the requesting principal was already applied when the TGT was issued). If the new ticket is to be a renewal, then the endtime above is replaced by the minimum of (a) the value of the renew_till field of the ticket and (b) the starttime for the new ticket plus the life (endtime-starttime) of the old ticket.
如果请求指定了一个endtime，那么新票证的endtime将设置为（a）该请求的最小值，（b）来自TGT的endtime，以及（c）TGT的开始时间加上应用服务器的最大生存期的最小值和本地域的最大生存期的最小值（发出TGT时，已应用请求主体的最长使用期限）。如果新票证是续签，则上述结束时间将替换为（a）票证的续签时间字段的值和（b）新票证的开始时间加上旧票证的使用期限（结束时间开始时间）中的最小值。
If the FORWARDED option has been requested, then the resulting ticket will contain the addresses specified by the client. This option will only be honored if the FORWARDABLE flag is set in the TGT. The PROXY option is similar; the resulting ticket will contain the addresses
如果已请求转发选项，则生成的票证将包含客户端指定的地址。只有在TGT中设置了FORWARDABLE标志时，才会使用此选项。代理选择权类似；生成的票证将包含地址
specified by the client. It will be honored only if the PROXIABLE flag in the TGT is set. The PROXY option will not be honored on requests for additional TGTs.
由客户端指定。只有在TGT中设置了PROXIABLE标志时，才会使用它。对于额外TGT的请求，代理选项将不受尊重。
If the requested starttime is absent, indicates a time in the past, or is within the window of acceptable clock skew for the KDC and the POSTDATE option has not been specified, then the starttime of the ticket is set to the authentication server's current time. If it indicates a time in the future beyond the acceptable clock skew, but the POSTDATED option has not been specified or the MAY-POSTDATE flag is not set in the TGT, then the error KDC_ERR_CANNOT_POSTDATE is returned. Otherwise, if the TGT has the MAY-POSTDATE flag set, then the resulting ticket will be postdated, and the requested starttime is checked against the policy of the local realm. If acceptable, the ticket's starttime is set as requested, and the INVALID flag is set. The postdated ticket MUST be validated before use by presenting it to the KDC after the starttime has been reached. However, in no case may the starttime, endtime, or renew-till time of a newly-issued postdated ticket extend beyond the renew-till time of the TGT.
如果请求的starttime不存在，表示过去的时间，或者在KDC可接受的时钟偏移窗口内，并且尚未指定POSTDATE选项，则票证的starttime设置为身份验证服务器的当前时间。如果它指示未来某个时间超出可接受的时钟偏差，但尚未指定POSTDATED选项或TGT中未设置MAY-POSTDATE标志，则返回错误KDC_ERR_CANNOT_POSTDATE。否则，如果TGT设置了MAY-POSTDATE标志，则结果票证将被延迟，并且根据本地域的策略检查请求的starttime。如果可以接受，则根据请求设置票证的开始时间，并设置无效标志。过期票据必须在到达起始时间后通过向KDC出示的方式在使用前进行验证。但是，在任何情况下，新发行的过期车票的开始时间、结束时间或续签至时间不得超过TGT的续签至时间。
If the ENC-TKT-IN-SKEY option has been specified and an additional ticket has been included in the request, it indicates that the client is using user-to-user authentication to prove its identity to a server that does not have access to a persistent key. Section 3.7 describes the effect of this option on the entire Kerberos protocol. When generating the KRB_TGS_REP message, this option in the KRB_TGS_REQ message tells the KDC to decrypt the additional ticket using the key for the server to which the additional ticket was issued and to verify that it is a TGT. If the name of the requested server is missing from the request, the name of the client in the additional ticket will be used. Otherwise, the name of the requested server will be compared to the name of the client in the additional ticket. If it is different, the request will be rejected. If the request succeeds, the session key from the additional ticket will be used to encrypt the new ticket that is issued instead of using the key of the server for which the new ticket will be used.
如果指定了ENC-TKT-IN-SKEY选项，并且请求中包含了额外的票证，则表示客户端正在使用用户对用户身份验证向无法访问持久密钥的服务器证明其身份。第3.7节描述了此选项对整个Kerberos协议的影响。生成KRB_TGS_REP消息时，KRB_TGS_REQ消息中的此选项告诉KDC使用向其发出附加票证的服务器的密钥解密附加票证，并验证它是否为TGT。如果请求中缺少所请求服务器的名称，则将使用附加票证中的客户端名称。否则，请求的服务器名称将与附加票证中的客户端名称进行比较。如果不同，请求将被拒绝。如果请求成功，则来自附加票证的会话密钥将用于加密已发布的新票证，而不是使用将使用新票证的服务器的密钥。
If (a) the name of the server in the ticket that is presented to the KDC as part of the authentication header is not that of the TGS itself, (b) the server is registered in the realm of the KDC, and (c) the RENEW option is requested, then the KDC will verify that the RENEWABLE flag is set in the ticket, that the INVALID flag is not set in the ticket, and that the renew_till time is still in the future. If the VALIDATE option is requested, the KDC will check that the starttime has passed and that the INVALID flag is set. If the PROXY option is requested, then the KDC will check that the PROXIABLE flag
如果（a）作为身份验证标头的一部分呈现给KDC的票证中的服务器名称不是TGS本身的名称，（b）服务器在KDC领域中注册，并且（c）请求续订选项，则KDC将验证票证中是否设置了可续订标志，票证中未设置无效标志，续费时间仍在未来。如果请求VALIDATE选项，KDC将检查starttime是否已过，以及是否设置了无效标志。如果请求了PROXY选项，那么KDC将检查PROXIABLE标志
is set in the ticket. If the tests succeed and the ticket passes the hotlist check described in the next section, the KDC will issue the appropriate new ticket.
票上写着。如果测试成功并且票证通过了下一节中描述的热列表检查，KDC将发布相应的新票证。
The ciphertext part of the response in the KRB_TGS_REP message is encrypted in the sub-session key from the Authenticator, if present, or in the session key from the TGT. It is not encrypted using the client's secret key. Furthermore, the client's key's expiration date and the key version number fields are left out since these values are stored along with the client's database record, and that record is not needed to satisfy a request based on a TGT.
KRB_TGS_REP消息中响应的密文部分在验证器（如果存在）的子会话密钥中加密，或者在TGT的会话密钥中加密。它不是使用客户端的密钥加密的。此外，客户机密钥的过期日期和密钥版本号字段被省略，因为这些值与客户机的数据库记录一起存储，并且不需要该记录来满足基于TGT的请求。
Whenever a request is made to the ticket-granting server, the presented ticket(s) is (are) checked against a hot-list of tickets that have been canceled. This hot-list might be implemented by storing a range of issue timestamps for 'suspect tickets'; if a presented ticket had an authtime in that range, it would be rejected. In this way, a stolen TGT or renewable ticket cannot be used to gain additional tickets (renewals or otherwise) once the theft has been reported to the KDC for the realm in which the server resides. Any normal ticket obtained before it was reported stolen will still be valid (because tickets require no interaction with the KDC), but only until its normal expiration time. If TGTs have been issued for cross-realm authentication, use of the cross-realm TGT will not be affected unless the hot-list is propagated to the KDCs for the realms for which such cross-realm tickets were issued.
无论何时向票证授予服务器发出请求，都会根据已取消的票证热列表检查所提供的票证。可通过存储“可疑票据”的一系列发行时间戳来实现此热列表；如果提交的票证的authtime在该范围内，则该票证将被拒绝。这样，一旦服务器所在领域的KDC收到盗窃报告，被盗TGT或可续签票证就不能用于获取额外票证（续签或其他）。在报告被盗之前获得的任何正常票证仍然有效（因为票证不需要与KDC交互），但只有在其正常到期时间之前有效。如果已为跨域身份验证颁发了TGT，则跨域TGT的使用将不会受到影响，除非已为其颁发此类跨域票证的域将热列表传播到KDC。
If the identity of the server in the TGT that is presented to the KDC as part of the authentication header is that of the ticket-granting service, but the TGT was issued from another realm, the KDC will look up the inter-realm key shared with that realm and use that key to decrypt the ticket. If the ticket is valid, then the KDC will honor the request, subject to the constraints outlined above in the section describing the AS exchange. The realm part of the client's identity will be taken from the TGT. The name of the realm that issued the TGT, if it is not the realm of the client principal, will be added to the transited field of the ticket to be issued. This is accomplished by reading the transited field from the TGT (which is treated as an unordered set of realm names), adding the new realm to the set, and then constructing and writing out its encoded (shorthand) form (this may involve a rearrangement of the existing encoding).
如果TGT中作为身份验证头的一部分呈现给KDC的服务器的标识是票证授予服务的标识，但TGT是从另一个域发出的，KDC将查找与该域共享的域间密钥，并使用该密钥解密票证。如果票证有效，KDC将根据上述描述AS交换的部分中概述的约束条件，接受该请求。客户端标识的领域部分将从TGT中获取。发出TGT的域的名称（如果它不是客户端主体的域）将添加到要发出的票证的transited字段中。这是通过从TGT（被视为一组无序的领域名称）读取传输字段来实现的，将新领域添加到该集合中，然后构造并写出其编码（速记）形式（这可能涉及对现有编码的重新排列）。
Note that the ticket-granting service does not add the name of its own realm. Instead, its responsibility is to add the name of the
请注意，票证授予服务不会添加其自己领域的名称。相反，它的责任是添加
previous realm. This prevents a malicious Kerberos server from intentionally leaving out its own name (it could, however, omit other realms' names).
以前的领域。这可以防止恶意Kerberos服务器故意省略自己的名称（但是，它可以省略其他领域的名称）。
The names of neither the local realm nor the principal's realm are to be included in the transited field. They appear elsewhere in the ticket and both are known to have taken part in authenticating the principal. Because the endpoints are not included, both local and single-hop inter-realm authentication result in a transited field that is empty.
本地域和主体域的名称都不包括在transited字段中。他们出现在罚单的其他地方，并且都参与了对委托人的认证。由于不包括端点，本地和单跳域间身份验证都会导致传输字段为空。
Because this field has the name of each transited realm added to it, it might potentially be very long. To decrease the length of this field, its contents are encoded. The initially supported encoding is optimized for the normal case of inter-realm communication: a hierarchical arrangement of realms using either domain or X.500 style realm names. This encoding (called DOMAIN-X500-COMPRESS) is now described.
由于此字段中添加了每个过渡域的名称，因此它可能非常长。要减少此字段的长度，请对其内容进行编码。最初支持的编码针对域间通信的正常情况进行了优化：使用域名或X.500样式的域名对域进行分层排列。现在描述这种编码（称为DOMAIN-X500-COMPRESS）。
Realm names in the transited field are separated by a ",". The ",", "\", trailing "."s, and leading spaces (" ") are special characters, and if they are part of a realm name, they MUST be quoted in the transited field by preceding them with a "\".
传输字段中的域名用“，”分隔。“、”、“\”、尾随“.s”和前导空格（“”）是特殊字符，如果它们是领域名称的一部分，则必须在过渡字段中引用它们，方法是在它们前面加上“\”。
A realm name ending with a "." is interpreted as being prepended to the previous realm. For example, we can encode traversal of EDU, MIT.EDU, ATHENA.MIT.EDU, WASHINGTON.EDU, and CS.WASHINGTON.EDU as:
以“.”结尾的域名称被解释为前一个域的前缀。例如，我们可以将EDU、MIT.EDU、ATHENA.MIT.EDU、WASHINGTON.EDU和CS.WASHINGTON.EDU的遍历编码为：
"EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
“麻省理工学院，雅典娜，华盛顿，哥伦比亚教育大学。”。
Note that if either ATHENA.MIT.EDU, or CS.WASHINGTON.EDU were endpoints, they would not be included in this field, and we would have:
请注意，如果ATHENA.MIT.EDU或CS.WASHINGTON.EDU是端点，它们将不包括在该字段中，我们将：
"EDU,MIT.,WASHINGTON.EDU"
“麻省理工学院，华盛顿，教育大学”
A realm name beginning with a "/" is interpreted as being appended to the previous realm. For the purpose of appending, the realm preceding the first listed realm is considered the null realm (""). If a realm name beginning with a "/" is to stand by itself, then it SHOULD be preceded by a space (" "). For example, we can encode traversal of /COM/HP/APOLLO, /COM/HP, /COM, and /COM/DEC as:
以“/”开头的领域名称被解释为附加到上一个领域。为了追加，第一个列出的领域之前的领域被视为空领域（“”）。如果以“/”开头的领域名称是独立的，那么它前面应该有一个空格（“”）。例如，我们可以将/COM/HP/APOLLO、/COM/HP、/COM和/COM/DEC的遍历编码为：
"/COM,/HP,/APOLLO, /COM/DEC".
“/COM，/HP，/APOLLO，/COM/DEC”。
As in the example above, if /COM/HP/APOLLO and /COM/DEC were endpoints, they would not be included in this field, and we would have:
如上面的示例所示，如果/COM/HP/APOLLO和/COM/DEC是端点，它们将不包括在该字段中，我们将：
"/COM,/HP"
“/COM，/HP”
A null subfield preceding or following a "," indicates that all realms between the previous realm and the next realm have been traversed. For the purpose of interpreting null subfields, the client's realm is considered to precede those in the transited field, and the server's realm is considered to follow them. Thus, "," means that all realms along the path between the client and the server have been traversed. ",EDU, /COM," means that all realms from the client's realm up to EDU (in a domain style hierarchy) have been traversed, and that everything from /COM down to the server's realm in an X.500 style has also been traversed. This could occur if the EDU realm in one hierarchy shares an inter-realm key directly with the /COM realm in another hierarchy.
“，”前面或后面的空子字段表示已遍历上一个域和下一个域之间的所有域。为了解释空子字段，客户机的领域被认为在传输字段中的领域之前，服务器的领域被认为在它们之后。因此，“，”意味着客户机和服务器之间的路径上的所有领域都已被遍历。“，EDU，/COM”表示从客户机领域到EDU（在域样式层次结构中）的所有领域都已被遍历，并且从/COM到X.500样式的服务器领域的所有领域都已被遍历。如果一个层次结构中的EDU域与另一个层次结构中的/COM域直接共享域间密钥，则可能发生这种情况。
When the KRB_TGS_REP is received by the client, it is processed in the same manner as the KRB_AS_REP processing described above. The primary difference is that the ciphertext part of the response must be decrypted using the sub-session key from the Authenticator, if it was specified in the request, or the session key from the TGT, rather than the client's secret key. The server name returned in the reply is the true principal name of the service.
当客户机接收到KRB_TGS_REP时，其处理方式与上述KRB_as_REP处理相同。主要区别在于，如果在请求中指定了子会话密钥，则响应的密文部分必须使用来自身份验证器的子会话密钥解密，或者使用来自TGT的会话密钥解密，而不是使用客户端的密钥。回复中返回的服务器名称是服务的真实主体名称。
The KRB_SAFE message MAY be used by clients requiring the ability to detect modifications of messages they exchange. It achieves this by including a keyed collision-proof checksum of the user data and some control information. The checksum is keyed with an encryption key (usually the last key negotiated via subkeys, or the session key if no negotiation has occurred).
KRB_安全消息可由需要能够检测其交换的消息修改的客户端使用。它通过包含用户数据和一些控制信息的键控防冲突校验和来实现这一点。校验和使用加密密钥（通常是通过子密钥协商的最后一个密钥，或者如果没有协商，则使用会话密钥）设置密钥。
When an application wishes to send a KRB_SAFE message, it collects its data and the appropriate control information and computes a checksum over them. The checksum algorithm should be the keyed checksum mandated to be implemented along with the crypto system used for the sub-session or session key. The checksum is generated using the sub-session key, if present, or the session key. Some implementations use a different checksum algorithm for the KRB_SAFE messages, but doing so in an interoperable manner is not always possible.
当应用程序希望发送KRB_安全消息时，它会收集其数据和适当的控制信息，并对其计算校验和。校验和算法应该是密钥校验和，强制与用于子会话或会话密钥的加密系统一起实现。使用子会话密钥（如果存在）或会话密钥生成校验和。一些实现对KRB_安全消息使用不同的校验和算法，但是以互操作的方式这样做并不总是可能的。
The control information for the KRB_SAFE message includes both a timestamp and a sequence number. The designer of an application
KRB_安全消息的控制信息包括时间戳和序列号。应用程序的设计者
using the KRB_SAFE message MUST choose at least one of the two mechanisms. This choice SHOULD be based on the needs of the application protocol.
使用KRB_安全消息必须至少选择两种机制中的一种。此选择应基于应用程序协议的需要。
Sequence numbers are useful when all messages sent will be received by one's peer. Connection state is presently required to maintain the session key, so maintaining the next sequence number should not present an additional problem.
当发送的所有消息都将由对等方接收时，序列号非常有用。目前需要连接状态来维护会话密钥，因此维护下一个序列号不应带来额外的问题。
If the application protocol is expected to tolerate lost messages without their being resent, the use of the timestamp is the appropriate replay detection mechanism. Using timestamps is also the appropriate mechanism for multi-cast protocols in which all of one's peers share a common sub-session key, but some messages will be sent to a subset of one's peers.
如果预期应用程序协议能够容忍丢失的消息而不重新发送，则使用时间戳是合适的重播检测机制。使用时间戳也是多播协议的适当机制，在多播协议中，所有对等方共享一个公共子会话密钥，但一些消息将被发送到对等方的子集。
After computing the checksum, the client then transmits the information and checksum to the recipient in the message format specified in Section 5.6.1.
在计算校验和后，客户机然后以第5.6.1节规定的消息格式将信息和校验和发送给收件人。
When an application receives a KRB_SAFE message, it verifies it as follows. If any error occurs, an error code is reported for use by the application.
当应用程序接收到KRB_安全消息时，它将按如下方式进行验证。如果发生任何错误，将报告一个错误代码供应用程序使用。
The message is first checked by verifying that the protocol version and type fields match the current version and KRB_SAFE, respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application verifies that the checksum used is a collision-proof keyed checksum that uses keys compatible with the sub-session or session key as appropriate (or with the application key derived from the session or sub-session keys). If it is not, a KRB_AP_ERR_INAPP_CKSUM error is generated. The sender's address MUST be included in the control information; the recipient verifies that the operating system's report of the sender's address matches the sender's address in the message, and (if a recipient address is specified or the recipient requires an address) that one of the recipient's addresses appears as the recipient's address in the message. To work with network address translation, senders MAY use the directional address type specified in Section 8.1 for the sender address and not include recipient addresses. A failed match for either case generates a KRB_AP_ERR_BADADDR error. Then the timestamp and usec and/or the sequence number fields are checked. If timestamp and usec are expected and not present, or if they are present but not current, the KRB_AP_ERR_SKEW error is generated. Timestamps are not required to be strictly ordered; they are only required to be in the skew window. If the server name, along with the client name, time,
首先通过验证协议版本和类型字段分别与当前版本和KRB_-SAFE匹配来检查消息。不匹配会生成KRB_AP_ERR_BADVERSION或KRB_AP_ERR_MSG_类型错误。应用程序验证使用的校验和是否为防冲突键控校验和，该校验和使用与子会话或会话密钥（或与从会话或子会话密钥派生的应用程序密钥）兼容的密钥（视情况而定）。如果不是，则生成KRB_AP_ERR_INAPP_校验和错误。控制信息中必须包含发件人地址；收件人验证操作系统对发件人地址的报告是否与邮件中的发件人地址匹配，以及（如果指定了收件人地址或收件人需要地址）其中一个收件人地址是否显示为邮件中的收件人地址。要使用网络地址转换，发件人可以使用第8.1节中为发件人地址指定的定向地址类型，而不包括收件人地址。任何一种情况的匹配失败都会生成KRB_AP_ERR_BADADDR错误。然后检查时间戳、usec和/或序列号字段。如果timestamp和usec是预期的但不存在，或者如果它们存在但不是当前的，则生成KRB_AP_ERR_SKEW错误。无需严格订购时间戳；它们只需要位于“倾斜”窗口中。如果服务器名称与客户端名称、时间、，
and microsecond fields from the Authenticator match any recently-seen (sent or received) such tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence number is included, or if a sequence number is expected but not present, the KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec nor a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated. Finally, the checksum is computed over the data and control information, and if it doesn't match the received checksum, a KRB_AP_ERR_MODIFIED error is generated.
来自验证器的微秒字段匹配任何最近看到（发送或接收）的元组，就会生成KRB_AP_ERR_REPEAT错误。如果包含不正确的序列号，或者序列号是预期的但不存在，则会生成KRB_AP_ERR_BADORDER错误。如果既不存在时间戳和usec，也不存在序列号，则会生成KRB_AP_ERR_修改错误。最后，根据数据和控制信息计算校验和，如果它与接收到的校验和不匹配，则生成KRB_AP_ERR_MODIFIED错误。
If all the checks succeed, the application is assured that the message was generated by its peer and was not modified in transit.
如果所有检查都成功，应用程序将确保消息是由其对等方生成的，并且在传输过程中未被修改。
Implementations SHOULD accept any checksum algorithm they implement that has both adequate security and keys compatible with the sub-session or session key. Unkeyed or non-collision-proof checksums are not suitable for this use.
实现应该接受他们实现的任何校验和算法，该算法具有足够的安全性和与子会话或会话密钥兼容的密钥。未加密或无冲突校验和不适用于此用途。
The KRB_PRIV message MAY be used by clients requiring confidentiality and the ability to detect modifications of exchanged messages. It achieves this by encrypting the messages and adding control information.
KRB_PRIV消息可由需要保密性和检测交换消息修改能力的客户端使用。它通过加密消息和添加控制信息来实现这一点。
When an application wishes to send a KRB_PRIV message, it collects its data and the appropriate control information (specified in Section 5.7.1) and encrypts them under an encryption key (usually the last key negotiated via subkeys, or the session key if no negotiation has occurred). As part of the control information, the client MUST choose to use either a timestamp or a sequence number (or both); see the discussion in Section 3.4.1 for guidelines on which to use. After the user data and control information are encrypted, the client transmits the ciphertext and some 'envelope' information to the recipient.
当应用程序希望发送KRB_PRIV消息时，它收集其数据和适当的控制信息（在第5.7.1节中指定），并使用加密密钥（通常是通过子密钥协商的最后一个密钥，或者如果没有协商，则使用会话密钥）对其进行加密。作为控制信息的一部分，客户机必须选择使用时间戳或序列号（或两者都使用）；有关使用指南，请参见第3.4.1节中的讨论。用户数据和控制信息加密后，客户端将密文和一些“信封”信息发送给收件人。
When an application receives a KRB_PRIV message, it verifies it as follows. If any error occurs, an error code is reported for use by the application.
当应用程序收到KRB_PRIV消息时，它将按如下方式进行验证。如果发生任何错误，将报告一个错误代码供应用程序使用。
The message is first checked by verifying that the protocol version and type fields match the current version and KRB_PRIV, respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then decrypts the ciphertext and processes
首先通过验证协议版本和类型字段分别与当前版本和KRB_PRIV匹配来检查消息。不匹配会生成KRB_AP_ERR_BADVERSION或KRB_AP_ERR_MSG_类型错误。然后应用程序对密文进行解密并处理
the resultant plaintext. If decryption shows that the data has been modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated.
生成的明文。如果解密显示数据已被修改，则会生成KRB_AP_ERR_BAD_完整性错误。
The sender's address MUST be included in the control information; the recipient verifies that the operating system's report of the sender's address matches the sender's address in the message. If a recipient address is specified or the recipient requires an address, then one of the recipient's addresses MUST also appear as the recipient's address in the message. Where a sender's or receiver's address might not otherwise match the address in a message because of network address translation, an application MAY be written to use addresses of the directional address type in place of the actual network address.
控制信息中必须包含发件人地址；收件人验证操作系统的发件人地址报告是否与邮件中的发件人地址匹配。如果指定了收件人地址或收件人需要地址，则其中一个收件人地址也必须作为收件人地址出现在邮件中。如果发送方或接收方的地址可能因网络地址转换而与消息中的地址不匹配，则可以编写应用程序以使用定向地址类型的地址代替实际网络地址。
A failed match for either case generates a KRB_AP_ERR_BADADDR error. To work with network address translation, implementations MAY use the directional address type defined in Section 7.1 for the sender address and include no recipient address.
任何一种情况的匹配失败都会生成KRB_AP_ERR_BADADDR错误。要使用网络地址转换，实现可能会使用第7.1节中为发送方地址定义的定向地址类型，并且不包括接收方地址。
Next the timestamp and usec and/or the sequence number fields are checked. If timestamp and usec are expected and not present, or if they are present but not current, the KRB_AP_ERR_SKEW error is generated. If the server name, along with the client name, time, and microsecond fields from the Authenticator match any such recently-seen tuples, the KRB_AP_ERR_REPEAT error is generated. If an incorrect sequence number is included, or if a sequence number is expected but not present, the KRB_AP_ERR_BADORDER error is generated. If neither a time-stamp and usec nor a sequence number is present, a KRB_AP_ERR_MODIFIED error is generated.
接下来检查时间戳和usec和/或序列号字段。如果timestamp和usec是预期的但不存在，或者如果它们存在但不是当前的，则生成KRB_AP_ERR_SKEW错误。如果服务器名称以及验证器中的客户端名称、时间和微秒字段与最近看到的任何此类元组匹配，则会生成KRB_AP_ERR_REPEAT错误。如果包含不正确的序列号，或者序列号是预期的但不存在，则会生成KRB_AP_ERR_BADORDER错误。如果既不存在时间戳和usec，也不存在序列号，则会生成KRB_AP_ERR_修改错误。
If all the checks succeed, the application can assume the message was generated by its peer and was securely transmitted (without intruders seeing the unencrypted contents).
如果所有检查都成功，应用程序可以假定消息是由对等方生成的，并且是安全传输的（入侵者不会看到未加密的内容）。
The KRB_CRED message MAY be used by clients requiring the ability to send Kerberos credentials from one host to another. It achieves this by sending the tickets together with encrypted data containing the session keys and other information associated with the tickets.
KRB_CRED消息可由需要能够从一台主机向另一台主机发送Kerberos凭据的客户端使用。它通过发送票据以及包含会话密钥和与票据相关的其他信息的加密数据来实现这一点。
When an application wishes to send a KRB_CRED message, it first (using the KRB_TGS exchange) obtains credentials to be sent to the remote host. It then constructs a KRB_CRED message using the ticket or tickets so obtained, placing the session key needed to use each
当应用程序希望发送KRB_CRED消息时，它首先（使用KRB_TGS交换）获取要发送到远程主机的凭据。然后，它使用这样获得的一张或多张票证构造KRB_CRED消息，并放置使用每一张票证所需的会话密钥
ticket in the key field of the corresponding KrbCredInfo sequence of the encrypted part of the KRB_CRED message.
KRB_CRED消息加密部分对应KrbCredInfo序列的密钥字段中的票证。
Other information associated with each ticket and obtained during the KRB_TGS exchange is also placed in the corresponding KrbCredInfo sequence in the encrypted part of the KRB_CRED message. The current time and, if they are specifically required by the application, the nonce, s-address, and r-address fields are placed in the encrypted part of the KRB_CRED message, which is then encrypted under an encryption key previously exchanged in the KRB_AP exchange (usually the last key negotiated via subkeys, or the session key if no negotiation has occurred).
在KRB_TGS交换期间获得的与每张票据相关联的其他信息也被放置在KRB_CRED消息加密部分的相应KRBCreInfo序列中。当前时间以及（如果应用程序特别需要）nonce、s-address和r-address字段被放置在KRB_CRED消息的加密部分，然后根据先前在KRB_AP交换中交换的加密密钥对其进行加密（通常是通过子密钥协商的最后一个密钥，如果没有协商，则为会话密钥）。
Implementation note: When constructing a KRB_CRED message for inclusion in a GSSAPI initial context token, the MIT implementation of Kerberos will not encrypt the KRB_CRED message if the session key is a DES or triple DES key. For interoperability with MIT, the Microsoft implementation will not encrypt the KRB_CRED in a GSSAPI token if it is using a DES session key. Starting at version 1.2.5, MIT Kerberos can receive and decode either encrypted or unencrypted KRB_CRED tokens in the GSSAPI exchange. The Heimdal implementation of Kerberos can also accept either encrypted or unencrypted KRB_CRED messages. Since the KRB_CRED message in a GSSAPI token is encrypted in the authenticator, the MIT behavior does not present a security problem, although it is a violation of the Kerberos specification.
实现说明：当构造KRB_CRED消息以包含在GSSAPI初始上下文令牌中时，如果会话密钥是DES或triple DES密钥，则Kerberos的MIT实现不会加密KRB_CRED消息。为了与MIT的互操作性，如果使用DES会话密钥，则Microsoft实现不会加密GSSAPI令牌中的KRB_CRED。从版本1.2.5开始，MIT Kerberos可以在GSSAPI交换中接收和解码加密或未加密的KRB_CRED令牌。Kerberos的Heimdal实现还可以接受加密或未加密的KRB_CRED消息。由于GSSAPI令牌中的KRB_CRED消息在身份验证器中加密，因此MIT行为不存在安全问题，尽管它违反了Kerberos规范。
When an application receives a KRB_CRED message, it verifies it. If any error occurs, an error code is reported for use by the application. The message is verified by checking that the protocol version and type fields match the current version and KRB_CRED, respectively. A mismatch generates a KRB_AP_ERR_BADVERSION or KRB_AP_ERR_MSG_TYPE error. The application then decrypts the ciphertext and processes the resultant plaintext. If decryption shows the data to have been modified, a KRB_AP_ERR_BAD_INTEGRITY error is generated.
当应用程序收到KRB_CRED消息时，它会对其进行验证。如果发生任何错误，将报告一个错误代码供应用程序使用。通过检查协议版本和类型字段是否分别与当前版本和KRB_CRED匹配来验证消息。不匹配会生成KRB_AP_ERR_BADVERSION或KRB_AP_ERR_MSG_类型错误。然后应用程序解密密文并处理生成的明文。如果解密显示数据已被修改，则会生成KRB_AP_ERR_BAD_完整性错误。
If present or required, the recipient MAY verify that the operating system's report of the sender's address matches the sender's address in the message, and that one of the recipient's addresses appears as the recipient's address in the message. The address check does not provide any added security, since the address, if present, has already been checked in the KRB_AP_REQ message and there is not any benefit to be gained by an attacker in reflecting a KRB_CRED message back to its originator. Thus, the recipient MAY ignore the address even if it is present in order to work better in Network Address Translation (NAT) environments. A failed match for either case
如果存在或需要，收件人可以验证操作系统对发件人地址的报告是否与邮件中的发件人地址匹配，以及其中一个收件人地址是否在邮件中显示为收件人地址。地址检查不提供任何额外的安全性，因为地址（如果存在）已在KRB_AP_REQ消息中检查过，并且攻击者在将KRB_CRED消息反射回其原始发件人时不会获得任何好处。因此，为了在网络地址转换（NAT）环境中更好地工作，即使地址存在，接收者也可能忽略该地址。两种情况下的失败匹配
generates a KRB_AP_ERR_BADADDR error. Recipients MAY skip the address check, as the KRB_CRED message cannot generally be reflected back to the originator. The timestamp and usec fields (and the nonce field, if required) are checked next. If the timestamp and usec are not present, or if they are present but not current, the KRB_AP_ERR_SKEW error is generated.
生成KRB_AP_ERR_BADADDR错误。收件人可能会跳过地址检查，因为KRB_CRED消息通常无法反映回原始发件人。接下来检查timestamp和usec字段（以及nonce字段，如果需要）。如果时间戳和usec不存在，或者如果它们存在但不是当前的，则生成KRB_AP_ERR_SKEW错误。
If all the checks succeed, the application stores each of the new tickets in its credentials cache together with the session key and other information in the corresponding KrbCredInfo sequence from the encrypted part of the KRB_CRED message.
如果所有检查都成功，应用程序将在其凭据缓存中存储每个新票据，以及会话密钥和来自KRB_CRED消息加密部分的相应KrbCredInfo序列中的其他信息。
User-to-User authentication provides a method to perform authentication when the verifier does not have a access to long-term service key. This might be the case when running a server (for example, a window server) as a user on a workstation. In such cases, the server may have access to the TGT obtained when the user logged in to the workstation, but because the server is running as an unprivileged user, it might not have access to system keys. Similar situations may arise when running peer-to-peer applications.
用户对用户身份验证提供了一种在验证器无法访问长期服务密钥时执行身份验证的方法。在工作站上以用户身份运行服务器（例如，窗口服务器）时可能会出现这种情况。在这种情况下，服务器可能有权访问用户登录到工作站时获得的TGT，但由于服务器是作为非特权用户运行的，因此可能无法访问系统密钥。运行对等应用程序时可能会出现类似情况。
Summary
总结
Message direction Message type Sections 0. Message from application server Not specified 1. Client to Kerberos KRB_TGS_REQ 3.3 & 5.4.1 2. Kerberos to client KRB_TGS_REP or 3.3 & 5.4.2 KRB_ERROR 5.9.1 3. Client to application server KRB_AP_REQ 3.2 & 5.5.1
消息方向消息类型节0。未指定来自应用程序服务器的消息1。Kerberos KRB_TGS_REQ 3.3和5.4.1 2的客户端。Kerberos到客户端KRB_TGS_REP或3.3和5.4.2 KRB_错误5.9.1 3。客户端到应用服务器KRB_AP_请求3.2和5.5.1
To address this problem, the Kerberos protocol allows the client to request that the ticket issued by the KDC be encrypted using a session key from a TGT issued to the party that will verify the authentication. This TGT must be obtained from the verifier by means of an exchange external to the Kerberos protocol, usually as part of the application protocol. This message is shown in the summary above as message 0. Note that because the TGT is encrypted in the KDC's secret key, it cannot be used for authentication without possession of the corresponding secret key. Furthermore, because the verifier does not reveal the corresponding secret key, providing a copy of the verifier's TGT does not allow impersonation of the verifier.
为了解决这个问题，Kerberos协议允许客户机请求使用来自TGT的会话密钥对KDC颁发的票据进行加密，TGT将颁发给验证身份验证的一方。此TGT必须通过Kerberos协议外部的交换从验证器获得，通常作为应用程序协议的一部分。此消息在上面的摘要中显示为消息0。请注意，由于TGT是在KDC的密钥中加密的，因此在没有相应密钥的情况下，它不能用于身份验证。此外，由于验证器不公开相应的密钥，因此提供验证器的TGT的副本不允许模拟验证器。
Message 0 in the table above represents an application-specific negotiation between the client and server, at the end of which both have determined that they will use user-to-user authentication, and the client has obtained the server's TGT.
上表中的消息0表示客户端和服务器之间的特定于应用程序的协商，在协商结束时，双方都已确定将使用用户对用户身份验证，并且客户端已获得服务器的TGT。
Next, the client includes the server's TGT as an additional ticket in its KRB_TGS_REQ request to the KDC (message 1 in the table above) and specifies the ENC-TKT-IN-SKEY option in its request.
接下来，客户端将服务器的TGT作为附加票证包含在对KDC的KRB_TGS_REQ请求中（上表中的消息1），并在其请求中指定ENC-TKT-in-SKEY选项。
If validated according to the instructions in Section 3.3.3, the application ticket returned to the client (message 2 in the table above) will be encrypted using the session key from the additional ticket and the client will note this when it uses or stores the application ticket.
如果根据第3.3.3节中的说明进行验证，则返回给客户端的应用程序票证（上表中的消息2）将使用附加票证中的会话密钥进行加密，客户端在使用或存储应用程序票证时会注意到这一点。
When contacting the server using a ticket obtained for user-to-user authentication (message 3 in the table above), the client MUST specify the USE-SESSION-KEY flag in the ap-options field. This tells the application server to use the session key associated with its TGT to decrypt the server ticket provided in the application request.
当使用用户对用户身份验证（上表中的消息3）获得的票证联系服务器时，客户端必须在ap选项字段中指定USE-SESSION-KEY标志。这告诉应用程序服务器使用与其TGT关联的会话密钥来解密应用程序请求中提供的服务器票证。
The Kerberos protocols described in this document are designed to encrypt messages of arbitrary sizes, using stream or block encryption ciphers. Encryption is used to prove the identities of the network entities participating in message exchanges. The Key Distribution Center for each realm is trusted by all principals registered in that realm to store a secret key in confidence. Proof of knowledge of this secret key is used to verify the authenticity of a principal.
本文档中描述的Kerberos协议旨在使用流或块加密密码对任意大小的消息进行加密。加密用于证明参与消息交换的网络实体的身份。每个域的密钥分发中心都受该域中注册的所有主体的信任，可以秘密存储密钥。此密钥的知识证明用于验证主体的真实性。
The KDC uses the principal's secret key (in the AS exchange) or a shared session key (in the TGS exchange) to encrypt responses to ticket requests; the ability to obtain the secret key or session key implies the knowledge of the appropriate keys and the identity of the KDC. The ability of a principal to decrypt the KDC response and to present a Ticket and a properly formed Authenticator (generated with the session key from the KDC response) to a service verifies the identity of the principal; likewise the ability of the service to extract the session key from the Ticket and to prove its knowledge thereof in a response verifies the identity of the service.
KDC使用主体的密钥（在AS交换中）或共享会话密钥（在TGS交换中）来加密对票证请求的响应；获取密钥或会话密钥的能力意味着了解适当的密钥和KDC的身份。主体解密KDC响应并向服务提供票证和正确格式的验证器（使用来自KDC响应的会话密钥生成）的能力验证主体的身份；同样，服务从票据中提取会话密钥并在响应中证明其知道会话密钥的能力验证了服务的身份。
[RFC3961] defines a framework for defining encryption and checksum mechanisms for use with Kerberos. It also defines several such mechanisms, and more may be added in future updates to that document.
[RFC3961]定义了一个框架，用于定义用于Kerberos的加密和校验和机制。它还定义了几个这样的机制，将来可能会在该文档的更新中添加更多机制。
The string-to-key operation provided by [RFC3961] is used to produce a long-term key for a principal (generally for a user). The default salt string, if none is provided via pre-authentication data, is the concatenation of the principal's realm and name components, in order, with no separators. Unless it is indicated otherwise, the default string-to-key opaque parameter set as defined in [RFC3961] is used.
[RFC3961]提供的字符串到键操作用于为主体（通常为用户）生成长期键。默认的salt字符串（如果没有通过预身份验证数据提供）是主体的领域和名称组件按顺序连接，没有分隔符。除非另有说明，否则将使用[RFC3961]中定义的默认字符串设置不透明参数。
Encrypted data, keys, and checksums are transmitted using the EncryptedData, EncryptionKey, and Checksum data objects defined in Section 5.2.9. The encryption, decryption, and checksum operations described in this document use the corresponding encryption, decryption, and get_mic operations described in [RFC3961], with implicit "specific key" generation using the "key usage" values specified in the description of each EncryptedData or Checksum object to vary the key for each operation. Note that in some cases, the value to be used is dependent on the method of choosing the key or the context of the message.
使用第5.2.9节中定义的EncryptedData、EncryptionKey和Checksum数据对象传输加密数据、密钥和校验和。本文档中描述的加密、解密和校验和操作使用[RFC3961]中描述的相应加密、解密和获取操作，使用每个EncryptedData或校验和对象描述中指定的“key usage”（密钥使用）值隐式生成“specific key”（特定密钥），以改变每个操作的密钥。请注意，在某些情况下，要使用的值取决于选择键的方法或消息的上下文。
Key usages are unsigned 32-bit integers; zero is not permitted. The key usage values for encrypting or checksumming Kerberos messages are indicated in Section 5 along with the message definitions. The key usage values 512-1023 are reserved for uses internal to a Kerberos implementation. (For example, seeding a pseudo-random number generator with a value produced by encrypting something with a session key and a key usage value not used for any other purpose.) Key usage values between 1024 and 2047 (inclusive) are reserved for application use; applications SHOULD use even values for encryption and odd values for checksums within this range. Key usage values are also summarized in a table in Section 7.5.1.
密钥用法是无符号32位整数；零是不允许的。加密或校验和Kerberos消息的密钥使用值与消息定义一起在第5节中指出。密钥使用值512-1023保留用于Kerberos实现的内部使用。（例如，使用通过使用会话密钥加密某物而产生的值和不用于任何其他目的的密钥使用值对伪随机数生成器进行种子设定。）1024和2047（含）之间的密钥使用值保留供应用程序使用；应用程序应在此范围内使用偶数值进行加密，奇数值用于校验和。第7.5.1节的表格中也总结了关键使用值。
There might exist other documents that define protocols in terms of the RFC 1510 encryption types or checksum types. These documents would not know about key usages. In order that these specifications continue to be meaningful until they are updated, if no key usage values are specified, then key usages 1024 and 1025 must be used to derive keys for encryption and checksums, respectively. (This does not apply to protocols that do their own encryption independent of this framework, by directly using the key resulting from the Kerberos authentication exchange.) New protocols defined in terms of the Kerberos encryption and checksum types SHOULD use their own key usage values.
可能还有其他文档根据RFC1510加密类型或校验和类型定义协议。这些文档不知道关键用法。为了使这些规范在更新之前继续有效，如果未指定密钥使用值，则必须使用密钥使用1024和1025分别派生加密和校验和密钥。（这不适用于通过直接使用Kerberos身份验证交换产生的密钥而独立于此框架进行加密的协议。）根据Kerberos加密和校验和类型定义的新协议应使用其自己的密钥使用值。
Unless it is indicated otherwise, no cipher state chaining is done from one encryption operation to another.
除非另有说明，否则不会从一个加密操作到另一个加密操作进行密码状态链接。
Implementation note: Although it is not recommended, some application protocols will continue to use the key data directly, even if only in currently existing protocol specifications. An implementation intended to support general Kerberos applications may therefore need to make key data available, as well as the attributes and operations described in [RFC3961]. One of the more common reasons for directly performing encryption is direct control over negotiation and selection of a "sufficiently strong" encryption algorithm (in the context of a given application). Although Kerberos does not directly provide a facility for negotiating encryption types between the
实施说明：尽管不建议这样做，但某些应用程序协议将继续直接使用密钥数据，即使只是在当前现有的协议规范中。因此，旨在支持通用Kerberos应用程序的实现可能需要使关键数据以及[RFC3961]中描述的属性和操作可用。直接执行加密的一个更常见的原因是直接控制协商和选择“足够强”的加密算法（在给定应用程序的上下文中）。尽管Kerberos没有直接提供在
application client and server, there are approaches for using Kerberos to facilitate this negotiation. For example, a client may request only "sufficiently strong" session key types from the KDC and expect that any type returned by the KDC will be understood and supported by the application server.
在应用程序客户端和服务器端，有一些方法可以使用Kerberos来促进这种协商。例如，客户机可能只从KDC请求“足够强”的会话密钥类型，并期望KDC返回的任何类型都能被应用服务器理解和支持。
The ASN.1 collected here should be identical to the contents of Appendix A. In the case of a conflict, the contents of Appendix A shall take precedence.
此处收集的ASN.1应与附录A的内容相同。如有冲突，应以附录A的内容为准。
The Kerberos protocol is defined here in terms of Abstract Syntax Notation One (ASN.1) [X680], which provides a syntax for specifying both the abstract layout of protocol messages as well as their encodings. Implementors not utilizing an existing ASN.1 compiler or support library are cautioned to understand the actual ASN.1 specification thoroughly in order to ensure correct implementation behavior. There is more complexity in the notation than is immediately obvious, and some tutorials and guides to ASN.1 are misleading or erroneous.
Kerberos协议在这里是根据抽象语法符号1（ASN.1）[X680]定义的，它提供了一种语法来指定协议消息的抽象布局及其编码。提醒未使用现有ASN.1编译器或支持库的实现者彻底理解实际ASN.1规范，以确保正确的实现行为。符号的复杂性比显而易见的要大，而且ASN.1的一些教程和指南具有误导性或错误性。
Note that in several places, changes to abstract types from RFC 1510 have been made. This is in part to address widespread assumptions that various implementors have made, in some cases resulting in unintentional violations of the ASN.1 standard. These are clearly flagged where they occur. The differences between the abstract types in RFC 1510 and abstract types in this document can cause incompatible encodings to be emitted when certain encoding rules, e.g., the Packed Encoding Rules (PER), are used. This theoretical incompatibility should not be relevant for Kerberos, since Kerberos explicitly specifies the use of the Distinguished Encoding Rules (DER). It might be an issue for protocols seeking to use Kerberos types with other encoding rules. (This practice is not recommended.) With very few exceptions (most notably the usages of BIT STRING), the encodings resulting from using the DER remain identical between the types defined in RFC 1510 and the types defined in this document.
注意，在一些地方，对RFC1510中的抽象类型进行了更改。这在一定程度上是为了解决各种实施者所做的广泛假设，在某些情况下会导致无意违反ASN.1标准。这些都清楚地标记在它们发生的地方。RFC 1510中的抽象类型与本文档中的抽象类型之间的差异可能导致在使用某些编码规则（例如压缩编码规则（PER））时发出不兼容的编码。这种理论上的不兼容性与Kerberos无关，因为Kerberos明确指定使用可分辨编码规则（DER）。对于寻求将Kerberos类型与其他编码规则一起使用的协议来说，这可能是一个问题。（不建议采用这种做法。）除了极少数例外（最明显的是位字符串的用法），使用DER产生的编码在RFC 1510中定义的类型和本文档中定义的类型之间保持相同。
The type definitions in this section assume an ASN.1 module definition of the following form:
本节中的类型定义采用以下形式的ASN.1模块定义：
KerberosV5Spec2 {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) krb5spec2(2)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
KerberosV5Spec2 {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) krb5spec2(2)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
-- rest of definitions here
--其余的定义在这里
END
终止
This specifies that the tagging context for the module will be explicit and non-automatic.
这指定模块的标记上下文将是显式和非自动的。
Note that in some other publications (such as [RFC1510] and [RFC1964]), the "dod" portion of the object identifier is erroneously specified as having the value "5". In the case of RFC 1964, use of the "correct" OID value would result in a change in the wire protocol; therefore, it remains unchanged for now.
注意，在一些其他出版物（例如[RFC1510]和[RFC1964]）中，对象标识符的“dod”部分被错误地指定为具有值“5”。在RFC 1964的情况下，使用“正确的”OID值将导致有线协议的更改；因此，它目前保持不变。
Note that elsewhere in this document, nomenclature for various message types is inconsistent, but it largely follows C language conventions, including use of underscore (_) characters and all-caps spelling of names intended to be numeric constants. Also, in some places, identifiers (especially those referring to constants) are written in all-caps in order to distinguish them from surrounding explanatory text.
请注意，在本文档的其他地方，各种消息类型的术语不一致，但主要遵循C语言的约定，包括使用下划线（u）字符和所有大写字母拼写的名称都是数字常量。此外，在某些地方，标识符（特别是指常量的标识符）写在所有大写字母中，以便与周围的解释性文本区分开来。
The ASN.1 notation does not permit underscores in identifiers, so in actual ASN.1 definitions, underscores are replaced with hyphens (-). Additionally, structure member names and defined values in ASN.1 MUST begin with a lowercase letter, whereas type names MUST begin with an uppercase letter.
ASN.1表示法不允许在标识符中使用下划线，因此在实际的ASN.1定义中，下划线将替换为连字符（-）。此外，ASN.1中的结构成员名称和定义值必须以小写字母开头，而类型名称必须以大写字母开头。
For compatibility purposes, implementors should heed the following specific notes regarding the use of ASN.1 in Kerberos. These notes do not describe deviations from standard usage of ASN.1. The purpose of these notes is instead to describe some historical quirks and non-compliance of various implementations, as well as historical ambiguities, which, although they are valid ASN.1, can lead to confusion during implementation.
出于兼容性目的，实现者应该注意以下关于在Kerberos中使用ASN.1的具体说明。这些注释未描述与ASN.1标准用法的偏差。这些注释的目的是描述各种实现的一些历史怪癖和不合规性，以及历史上的模糊性，尽管它们在ASN.1中是有效的，但在实现过程中可能会导致混淆。
The encoding of Kerberos protocol messages shall obey the Distinguished Encoding Rules (DER) of ASN.1 as described in [X690]. Some implementations (believed primarily to be those derived from DCE 1.1 and earlier) are known to use the more general Basic Encoding
Kerberos协议消息的编码应遵守[X690]中所述ASN.1的可分辨编码规则（DER）。已知一些实现（主要被认为是从DCE 1.1和更早版本派生的实现）使用更通用的基本编码
Rules (BER); in particular, these implementations send indefinite encodings of lengths. Implementations MAY accept such encodings in the interest of backward compatibility, though implementors are warned that decoding fully-general BER is fraught with peril.
规则（BER）；特别是，这些实现发送长度不确定的编码。为了向后兼容，实现可能会接受这样的编码，尽管实现者被警告，完全解码一般的误码率充满危险。
Some implementations do not internally distinguish between an omitted optional integer value and a transmitted value of zero. The places in the protocol where this is relevant include various microseconds fields, nonces, and sequence numbers. Implementations SHOULD treat omitted optional integer values as having been transmitted with a value of zero, if the application is expecting this.
一些实现在内部不区分省略的可选整数值和传输的零值。协议中与此相关的位置包括各种微秒字段、nonce和序列号。如果应用程序需要，则实现应将省略的可选整数值视为已使用零值传输。
There are places in the protocol where a message contains a SEQUENCE OF type as an optional member. This can result in an encoding that contains an empty SEQUENCE OF encoding. The Kerberos protocol does not semantically distinguish between an absent optional SEQUENCE OF type and a present optional but empty SEQUENCE OF type. Implementations SHOULD NOT send empty SEQUENCE OF encodings that are marked OPTIONAL, but SHOULD accept them as being equivalent to an omitted OPTIONAL type. In the ASN.1 syntax describing Kerberos messages, instances of these problematic optional SEQUENCE OF types are indicated with a comment.
协议中有些地方的消息包含一个类型为可选成员的序列。这可能导致编码包含空编码序列。Kerberos协议在语义上不区分缺失的可选类型序列和当前可选但为空的类型序列。实现不应发送标记为可选的空编码序列，但应接受它们，将其视为等效于省略的可选类型。在描述Kerberos消息的ASN.1语法中，这些有问题的可选类型序列的实例用注释表示。
Future revisions to this protocol may include new message types with different APPLICATION class tag numbers. Such revisions should protect older implementations by only sending the message types to parties that are known to understand them; e.g., by means of a flag bit set by the receiver in a preceding request. In the interest of robust error handling, implementations SHOULD gracefully handle receiving a message with an unrecognized tag anyway, and return an error message, if appropriate.
此协议的未来版本可能包括具有不同应用程序类标记号的新消息类型。这样的修订应该通过只将消息类型发送给已知理解它们的各方来保护旧的实现；e、 例如，通过接收器在先前请求中设置的标志位。为了实现健壮的错误处理，实现应该优雅地处理接收带有无法识别标记的消息，并在适当的情况下返回错误消息。
In particular, KDCs SHOULD return KRB_AP_ERR_MSG_TYPE if the incorrect tag is sent over a TCP transport. The KDCs SHOULD NOT respond to messages received with an unknown tag over UDP transport in order to avoid denial of service attacks. For non-KDC applications, the Kerberos implementation typically indicates an error to the application which takes appropriate steps based on the application protocol.
特别是，如果通过TCP传输发送不正确的标记，KDCs应该返回KRB_AP_ERR_MSG_TYPE。KDC不应响应通过UDP传输接收的带有未知标记的消息，以避免拒绝服务攻击。对于非KDC应用程序，Kerberos实现通常会向应用程序指示错误，该应用程序会根据应用程序协议采取适当的步骤。
A naive implementation of a DER ASN.1 decoder may experience problems with ASN.1 tag numbers greater than 30, due to such tag numbers being encoded using more than one byte. Future revisions of this protocol may utilize tag numbers greater than 30, and implementations SHOULD be prepared to gracefully return an error, if appropriate, when they do not recognize the tag.
DER ASN.1解码器的简单实现可能会遇到ASN.1标签号大于30的问题，因为此类标签号使用多个字节进行编码。该协议的未来版本可能会使用大于30的标签号，如果合适的话，实现应该准备在不识别标签时优雅地返回错误。
This section defines a number of basic types that are potentially used in multiple Kerberos protocol messages.
本节定义了多个Kerberos协议消息中可能使用的一些基本类型。
The original specification of the Kerberos protocol in RFC 1510 uses GeneralString in numerous places for human-readable string data. Historical implementations of Kerberos cannot utilize the full power of GeneralString. This ASN.1 type requires the use of designation and invocation escape sequences as specified in ISO-2022/ECMA-35 [ISO-2022/ECMA-35] to switch character sets, and the default character set that is designated as G0 is the ISO-646/ECMA-6 [ISO-646/ECMA-6] International Reference Version (IRV) (a.k.a. U.S. ASCII), which mostly works.
RFC1510中Kerberos协议的原始规范在许多地方使用GeneralString来表示人类可读的字符串数据。Kerberos的历史实现无法充分利用GeneralString的功能。这种ASN.1类型需要使用ISO-2022/ECMA-35[ISO-2022/ECMA-35]中规定的指定和调用转义序列来切换字符集，而指定为G0的默认字符集是ISO-646/ECMA-6[ISO-646/ECMA-6]国际参考版本（IRV）（又称美国ASCII），它主要起作用。
ISO-2022/ECMA-35 defines four character-set code elements (G0..G3) and two Control-function code elements (C0..C1). DER prohibits the designation of character sets as any but the G0 and C0 sets. Unfortunately, this seems to have the side effect of prohibiting the use of ISO-8859 (ISO Latin) [ISO-8859] character sets or any other character sets that utilize a 96-character set, as ISO-2022/ECMA-35 prohibits designating them as the G0 code element. This side effect is being investigated in the ASN.1 standards community.
ISO-2022/ECMA-35定义了四个字符集代码元素（G0..G3）和两个控制功能代码元素（C0..C1）。DER禁止将字符集指定为除G0和C0集以外的任何字符集。不幸的是，这似乎具有禁止使用ISO-8859（ISO拉丁语）[ISO-8859]字符集或任何其他使用96字符集的字符集的副作用，因为ISO-2022/ECMA-35禁止将它们指定为G0代码元素。ASN.1标准社区正在调查这种副作用。
In practice, many implementations treat GeneralStrings as if they were 8-bit strings of whichever character set the implementation defaults to, without regard to correct usage of character-set designation escape sequences. The default character set is often determined by the current user's operating system-dependent locale. At least one major implementation places unescaped UTF-8 encoded Unicode characters in the GeneralString. This failure to adhere to the GeneralString specifications results in interoperability issues when conflicting character encodings are utilized by the Kerberos clients, services, and KDC.
实际上，许多实现将GeneralString视为实现默认的字符集的8位字符串，而不考虑字符集指定转义序列的正确用法。默认字符集通常由当前用户的操作系统相关区域设置确定。至少有一个主要实现将未转义的UTF-8编码的Unicode字符放置在GeneralString中。当Kerberos客户端、服务和KDC使用冲突的字符编码时，不遵守GeneralString规范会导致互操作性问题。
This unfortunate situation is the result of improper documentation of the restrictions of the ASN.1 GeneralString type in prior Kerberos specifications.
这种不幸的情况是由于在以前的Kerberos规范中对ASN.1 GeneralString类型的限制进行了不正确的文档记录。
The new (post-RFC 1510) type KerberosString, defined below, is a GeneralString that is constrained to contain only characters in IA5String.
下面定义的新（RFC 1510之后）类型KerberosString是一个GeneralString，它被限制为仅包含IA5String中的字符。
KerberosString ::= GeneralString (IA5String)
KerberosString ::= GeneralString (IA5String)
In general, US-ASCII control characters should not be used in KerberosString. Control characters SHOULD NOT be used in principal names or realm names.
通常，KerberosString中不应使用US-ASCII控制字符。主名称或领域名称中不应使用控制字符。
For compatibility, implementations MAY choose to accept GeneralString values that contain characters other than those permitted by IA5String, but they should be aware that character set designation codes will likely be absent, and that the encoding should probably be treated as locale-specific in almost every way. Implementations MAY also choose to emit GeneralString values that are beyond those permitted by IA5String, but they should be aware that doing so is extraordinarily risky from an interoperability perspective.
为了兼容性，实现可能会选择接受包含IA5String允许的字符以外的字符的GeneralString值，但它们应该注意，可能会缺少字符集指定代码，并且编码可能在几乎所有方面都应视为特定于语言环境。实现也可以选择发出超出IA5String允许范围的GeneralString值，但它们应该意识到，从互操作性的角度来看，这样做是非常危险的。
Some existing implementations use GeneralString to encode unescaped locale-specific characters. This is a violation of the ASN.1 standard. Most of these implementations encode US-ASCII in the left-hand half, so as long as the implementation transmits only US-ASCII, the ASN.1 standard is not violated in this regard. As soon as such an implementation encodes unescaped locale-specific characters with the high bit set, it violates the ASN.1 standard.
一些现有的实现使用GeneralString来编码未经转换的特定于区域设置的字符。这违反了ASN.1标准。这些实现中的大多数在左半部分编码US-ASCII，因此只要实现只传输US-ASCII，就不会违反ASN.1标准。一旦这样的实现使用高位集对未替换的特定于区域设置的字符进行编码，它就违反了ASN.1标准。
Other implementations have been known to use GeneralString to contain a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8 is a different encoding, not a 94 or 96 character "G" set as defined by ISO 2022. It is believed that these implementations do not even use the ISO 2022 escape sequence to change the character encoding. Even if implementations were to announce the encoding change by using that escape sequence, the ASN.1 standard prohibits the use of any escape sequences other than those used to designate/invoke "G" or "C" sets allowed by GeneralString.
已知其他实现使用GeneralString来包含UTF-8编码。这也违反了ASN.1标准，因为UTF-8是一种不同的编码，而不是ISO 2022定义的94或96字符“G”集。据信，这些实现甚至不使用ISO 2022转义序列来更改字符编码。即使实现通过使用该转义序列来宣布编码更改，ASN.1标准也禁止使用任何转义序列，而不是用于指定/调用GeneralString允许的“G”或“C”集的转义序列。
Future revisions to this protocol will almost certainly allow for a more interoperable representation of principal names, probably including UTF8String.
该协议的未来版本几乎肯定会允许主体名称的更具互操作性的表示，可能包括UTF8String。
Note that applying a new constraint to a previously unconstrained type constitutes creation of a new ASN.1 type. In this particular case, the change does not result in a changed encoding under DER.
请注意，对以前未受约束的类型应用新约束将构成新ASN.1类型的创建。在这种特殊情况下，更改不会导致DER下的编码更改。
Realm ::= KerberosString
Realm ::= KerberosString
PrincipalName ::= SEQUENCE {
name-type [0] Int32,
name-string [1] SEQUENCE OF KerberosString
}
PrincipalName ::= SEQUENCE {
name-type [0] Int32,
name-string [1] SEQUENCE OF KerberosString
}
Kerberos realm names are encoded as KerberosStrings. Realms shall not contain a character with the code 0 (the US-ASCII NUL). Most realms will usually consist of several components separated by periods (.), in the style of Internet Domain Names, or separated by slashes (/), in the style of X.500 names. Acceptable forms for realm names are specified in Section 6.1. A PrincipalName is a typed sequence of components consisting of the following subfields:
Kerberos领域名称编码为KerberosString。域不得包含代码为0（US-ASCII NUL）的字符。大多数领域通常由几个以句点（.）分隔的组件组成，采用互联网域名的样式，或以斜杠（/）分隔，采用X.500名称的样式。第6.1节规定了可接受的域名形式。PrincipalName是由以下子字段组成的组件类型化序列：
name-type This field specifies the type of name that follows. Pre-defined values for this field are specified in Section 6.2. The name-type SHOULD be treated as a hint. Ignoring the name type, no two names can be the same (i.e., at least one of the components, or the realm, must be different).
名称类型此字段指定后面的名称类型。第6.2节规定了该字段的预定义值。名称类型应视为提示。忽略名称类型，任何两个名称都不能相同（即，至少一个组件或领域必须不同）。
name-string This field encodes a sequence of components that form a name, each component encoded as a KerberosString. Taken together, a PrincipalName and a Realm form a principal identifier. Most PrincipalNames will have only a few components (typically one or two).
名称字符串此字段对组成名称的组件序列进行编码，每个组件编码为KerberosString。总的来说，PrincipalName和Realm构成了一个主要标识符。大多数PrincipalName只有几个组件（通常是一个或两个）。
KerberosTime ::= GeneralizedTime -- with no fractional seconds
KerberosTime ::= GeneralizedTime -- with no fractional seconds
The timestamps used in Kerberos are encoded as GeneralizedTimes. A KerberosTime value shall not include any fractional portions of the seconds. As required by the DER, it further shall not include any separators, and it shall specify the UTC time zone (Z). Example: The only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6 November 1985 is 19851106210627Z.
Kerberos中使用的时间戳被编码为一般化时间。KerberosTime值不应包括秒的任何小数部分。根据DER的要求，其进一步不得包括任何分隔符，并应规定UTC时区（Z）。示例：UTC时间1985年11月6日晚上9点后6分27秒的唯一有效格式是19851106210627Z。
Some integer members of types SHOULD be constrained to values representable in 32 bits, for compatibility with reasonable implementation limits.
某些类型的整数成员应限制为32位可表示的值，以便与合理的实现限制兼容。
Int32 ::= INTEGER (-2147483648..2147483647)
-- signed values representable in 32 bits
Int32 ::= INTEGER (-2147483648..2147483647)
-- signed values representable in 32 bits
UInt32 ::= INTEGER (0..4294967295)
-- unsigned 32 bit values
UInt32 ::= INTEGER (0..4294967295)
-- unsigned 32 bit values
Microseconds ::= INTEGER (0..999999)
-- microseconds
Microseconds ::= INTEGER (0..999999)
-- microseconds
Although this results in changes to the abstract types from the RFC 1510 version, the encoding in DER should be unaltered. Historical implementations were typically limited to 32-bit integer values anyway, and assigned numbers SHOULD fall in the space of integer values representable in 32 bits in order to promote interoperability anyway.
虽然这会导致RFC1510版本中的抽象类型发生更改，但DER中的编码应该保持不变。历史实现通常仅限于32位整数值，分配的数字应位于32位可表示的整数值空间中，以促进互操作性。
Several integer fields in messages are constrained to fixed values.
消息中的几个整数字段被约束为固定值。
pvno also TKT-VNO or AUTHENTICATOR-VNO, this recurring field is always the constant integer 5. There is no easy way to make this field into a useful protocol version number, so its value is fixed.
pvno也可以是TKT-VNO或AUTHENTICATOR-VNO，此重复字段始终为常量整数5。没有简单的方法将此字段转换为有用的协议版本号，因此其值是固定的。
msg-type this integer field is usually identical to the application tag number of the containing message type.
msg type此整数字段通常与包含消息类型的应用程序标记号相同。
HostAddress ::= SEQUENCE {
addr-type [0] Int32,
address [1] OCTET STRING
}
HostAddress ::= SEQUENCE {
addr-type [0] Int32,
address [1] OCTET STRING
}
-- NOTE: HostAddresses is always used as an OPTIONAL field and
-- should not be empty.
HostAddresses -- NOTE: subtly different from rfc1510,
-- but has a value mapping and encodes the same
::= SEQUENCE OF HostAddress
-- NOTE: HostAddresses is always used as an OPTIONAL field and
-- should not be empty.
HostAddresses -- NOTE: subtly different from rfc1510,
-- but has a value mapping and encodes the same
::= SEQUENCE OF HostAddress
The host address encodings consist of two fields:
主机地址编码由两个字段组成：
addr-type This field specifies the type of address that follows. Pre-defined values for this field are specified in Section 7.5.3.
addr type此字段指定后面的地址类型。第7.5.3节规定了该字段的预定义值。
address This field encodes a single address of type addr-type.
地址此字段编码addr类型的单个地址。
-- NOTE: AuthorizationData is always used as an OPTIONAL field and
-- should not be empty.
AuthorizationData ::= SEQUENCE OF SEQUENCE {
ad-type [0] Int32,
ad-data [1] OCTET STRING
}
-- NOTE: AuthorizationData is always used as an OPTIONAL field and
-- should not be empty.
AuthorizationData ::= SEQUENCE OF SEQUENCE {
ad-type [0] Int32,
ad-data [1] OCTET STRING
}
ad-data This field contains authorization data to be interpreted according to the value of the corresponding ad-type field.
ad数据此字段包含根据相应ad类型字段的值解释的授权数据。
ad-type This field specifies the format for the ad-data subfield. All negative values are reserved for local use. Non-negative values are reserved for registered use.
ad类型此字段指定ad数据子字段的格式。所有负值保留供本地使用。非负值保留供注册使用。
Each sequence of type and data is referred to as an authorization element. Elements MAY be application specific; however, there is a common set of recursive elements that should be understood by all implementations. These elements contain other elements embedded within them, and the interpretation of the encapsulating element determines which of the embedded elements must be interpreted, and which may be ignored.
类型和数据的每个序列都称为授权元素。元素可能是特定于应用的；但是，所有实现都应该理解一组通用的递归元素。这些元素包含嵌入其中的其他元素，封装元素的解释决定了哪些嵌入元素必须解释，哪些可以忽略。
These common authorization data elements are recursively defined, meaning that the ad-data for these types will itself contain a sequence of authorization data whose interpretation is affected by the encapsulating element. Depending on the meaning of the encapsulating element, the encapsulated elements may be ignored, might be interpreted as issued directly by the KDC, or might be stored in a separate plaintext part of the ticket. The types of the encapsulating elements are specified as part of the Kerberos specification because the behavior based on these values should be understood across implementations, whereas other elements need only be understood by the applications that they affect.
这些公共授权数据元素是递归定义的，这意味着这些类型的ad数据本身将包含一系列授权数据，其解释受封装元素的影响。根据封装元素的含义，封装元素可能被忽略，可能被解释为直接由KDC发布，或者可能存储在票据的单独明文部分中。封装元素的类型被指定为Kerberos规范的一部分，因为基于这些值的行为应该在不同的实现中被理解，而其他元素只需要被它们影响的应用程序理解。
Authorization data elements are considered critical if present in a ticket or authenticator. If an unknown authorization data element type is received by a server either in an AP-REQ or in a ticket contained in an AP-REQ, then, unless it is encapsulated in a known authorization data element amending the criticality of the elements it contains, authentication MUST fail. Authorization data is intended to restrict the use of a ticket. If the service cannot determine whether the restriction applies to that service, then a
授权数据元素如果存在于票据或验证器中，则被认为是关键的。如果服务器在AP-REQ或AP-REQ中包含的票证中接收到未知授权数据元素类型，则除非将其封装在修改其所包含元素的关键性的已知授权数据元素中，否则身份验证必须失败。授权数据旨在限制票据的使用。如果服务无法确定限制是否适用于该服务，则
security weakness may result if the ticket can be used for that service. Authorization elements that are optional can be enclosed in an AD-IF-RELEVANT element.
如果票据可用于该服务，则可能导致安全漏洞。可选的授权元素可以包含在AD-IF相关元素中。
In the definitions that follow, the value of the ad-type for the element will be specified as the least significant part of the subsection number, and the value of the ad-data will be as shown in the ASN.1 structure that follows the subsection heading.
在随后的定义中，元素的ad类型值将指定为子节编号的最低有效部分，ad数据的值将如子节标题后的ASN.1结构所示。
Contents of ad-data ad-type
广告数据内容广告类型
DER encoding of AD-IF-RELEVANT 1
AD-IF相关1的DER编码
DER encoding of AD-KDCIssued 4
AD KD4的DER编码
DER encoding of AD-AND-OR 5
AD-AND-OR 5的DER编码
DER encoding of AD-MANDATORY-FOR-KDC 8
AD-FOR-KDC 8的DER编码
AD-IF-RELEVANT ::= AuthorizationData
AD-IF-RELEVANT ::= AuthorizationData
AD elements encapsulated within the if-relevant element are intended for interpretation only by application servers that understand the particular ad-type of the embedded element. Application servers that do not understand the type of an element embedded within the if-relevant element MAY ignore the uninterpretable element. This element promotes interoperability across implementations that may have local extensions for authorization. The ad-type for AD-IF-RELEVANT is (1).
封装在if相关元素中的AD元素仅用于理解嵌入元素的特定AD类型的应用程序服务器的解释。如果应用程序服务器不了解嵌入在if相关元素中的元素的类型，则可能会忽略不可解释的元素。此元素促进了可能具有本地授权扩展的实现之间的互操作性。ad-IF相关的ad类型为（1）。
AD-KDCIssued ::= SEQUENCE {
ad-checksum [0] Checksum,
i-realm [1] Realm OPTIONAL,
i-sname [2] PrincipalName OPTIONAL,
elements [3] AuthorizationData
}
AD-KDCIssued ::= SEQUENCE {
ad-checksum [0] Checksum,
i-realm [1] Realm OPTIONAL,
i-sname [2] PrincipalName OPTIONAL,
elements [3] AuthorizationData
}
ad-checksum A cryptographic checksum computed over the DER encoding of the AuthorizationData in the "elements" field, keyed with the session key. Its checksumtype is the mandatory checksum type for the encryption type of the session key, and its key usage value is 19.
ad校验和通过“元素”字段中授权数据的DER编码计算的加密校验和，用会话密钥键入。其checksumtype是会话密钥加密类型的强制校验和类型，其密钥使用值为19。
i-realm, i-sname The name of the issuing principal if different from that of the KDC itself. This field would be used when the KDC can verify the authenticity of elements signed by the issuing principal, and it allows this KDC to notify the application server of the validity of those elements.
i-realm，i-sname发布主体的名称（如果与KDC本身的名称不同）。当KDC可以验证由发布主体签名的元素的真实性，并且允许此KDC将这些元素的有效性通知应用程序服务器时，将使用此字段。
elements A sequence of authorization data elements issued by the KDC.
元素由KDC发布的一系列授权数据元素。
The KDC-issued ad-data field is intended to provide a means for Kerberos principal credentials to embed within themselves privilege attributes and other mechanisms for positive authorization, amplifying the privileges of the principal beyond what can be done using credentials without such an a-data element.
KDC发布的ad数据字段旨在为Kerberos主体凭据提供一种将特权属性和其他积极授权机制嵌入其自身的方法，从而扩大主体的特权，使其超出使用凭据而不使用此类a-data元素所能做到的范围。
The above means cannot be provided without this element because the definition of the authorization-data field allows elements to be added at will by the bearer of a TGT at the time when they request service tickets, and elements may also be added to a delegated ticket by inclusion in the authenticator.
没有该元素就不能提供上述手段，因为授权数据字段的定义允许TGT的承载人在请求服务票证时随意添加元素，并且元素还可以通过包含在认证器中而添加到委托票证。
For KDC-issued elements, this is prevented because the elements are signed by the KDC by including a checksum encrypted using the server's key (the same key used to encrypt the ticket or a key derived from that key). Elements encapsulated with in the KDC-issued element MUST be ignored by the application server if this "signature" is not present. Further, elements encapsulated within this element from a TGT MAY be interpreted by the KDC, and used as a basis according to policy for including new signed elements within derivative tickets, but they will not be copied to a derivative ticket directly. If they are copied directly to a derivative ticket by a KDC that is not aware of this element, the signature will not be correct for the application ticket elements, and the field will be ignored by the application server.
对于KDC发布的元素，这是被阻止的，因为KDC通过包含使用服务器密钥加密的校验和（用于加密票据的同一密钥或从该密钥派生的密钥）对元素进行签名。如果不存在此“签名”，则应用程序服务器必须忽略KDC发布元素中封装的元素。此外，来自TGT的封装在该元素内的元素可由KDC解释，并根据在衍生票据内包括新签名元素的策略用作基础，但它们不会被直接复制到衍生票据。如果KDC不知道该元素，将它们直接复制到衍生票据中，则应用程序票据元素的签名将不正确，应用程序服务器将忽略该字段。
This element and the elements it encapsulates MAY safely be ignored by applications, application servers, and KDCs that do not implement this element.
不实现此元素的应用程序、应用程序服务器和KDC可以安全地忽略此元素及其封装的元素。
The ad-type for AD-KDC-ISSUED is (4).
ad-KDC-ISSUED的ad类型为（4）。
AD-AND-OR ::= SEQUENCE {
condition-count [0] Int32,
elements [1] AuthorizationData
}
AD-AND-OR ::= SEQUENCE {
condition-count [0] Int32,
elements [1] AuthorizationData
}
When restrictive AD elements are encapsulated within the and-or element, the and-or element is considered satisfied if and only if at least the number of encapsulated elements specified in condition-count are satisfied. Therefore, this element MAY be used to implement an "or" operation by setting the condition-count field to 1, and it MAY specify an "and" operation by setting the condition count to the number of embedded elements. Application servers that do not implement this element MUST reject tickets that contain authorization data elements of this type.
当限制性AD元素封装在and或元素中时，当且仅当至少满足条件计数中指定的封装元素数时，and或元素才被视为满足。因此，该元素可以通过将条件计数字段设置为1来实现“或”操作，并且可以通过将条件计数设置为嵌入元素的数量来指定“和”操作。未实现此元素的应用程序服务器必须拒绝包含此类型的授权数据元素的票证。
The ad-type for AD-AND-OR is (5).
ad-AND-OR的ad类型为（5）。
AD-MANDATORY-FOR-KDC ::= AuthorizationData
AD-MANDATORY-FOR-KDC ::= AuthorizationData
AD elements encapsulated within the mandatory-for-kdc element are to be interpreted by the KDC. KDCs that do not understand the type of an element embedded within the mandatory-for-kdc element MUST reject the request.
封装在mandatory for kdc元素中的AD元素将由kdc解释。如果kdc不了解嵌入在强制for kdc元素中的元素类型，则必须拒绝该请求。
The ad-type for AD-MANDATORY-FOR-KDC is (8).
ad-MANDATORY-for-KDC的广告类型为（8）。
Historically, PA-DATA have been known as "pre-authentication data", meaning that they were used to augment the initial authentication with the KDC. Since that time, they have also been used as a typed hole with which to extend protocol exchanges with the KDC.
从历史上看，PA-DATA被称为“预认证数据”，这意味着它们用于增强KDC的初始认证。从那个时起，它们也被用作一个类型化的孔，用来扩展和KDC的协议交换。
PA-DATA ::= SEQUENCE {
-- NOTE: first tag is [1], not [0]
padata-type [1] Int32,
padata-value [2] OCTET STRING -- might be encoded AP-REQ
}
PA-DATA ::= SEQUENCE {
-- NOTE: first tag is [1], not [0]
padata-type [1] Int32,
padata-value [2] OCTET STRING -- might be encoded AP-REQ
}
padata-type Indicates the way that the padata-value element is to be interpreted. Negative values of padata-type are reserved for unregistered use; non-negative values are used for a registered interpretation of the element type.
padata类型指示解释padata value元素的方式。padata类型的负值保留供未注册使用；非负值用于元素类型的注册解释。
padata-value Usually contains the DER encoding of another type; the padata-type field identifies which type is encoded here.
padata值通常包含另一种类型的DER编码；padata type字段标识此处编码的类型。
padata-type Name Contents of padata-value
padata类型名称padata值的内容
1 pa-tgs-req DER encoding of AP-REQ
AP-req的1 pa tgs req DER编码
2 pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP
2 pa enc时间戳对pa-enc-timestamp进行编码
3 pa-pw-salt salt (not ASN.1 encoded)
3帕pw盐（非ASN.1编码）
11 pa-etype-info DER encoding of ETYPE-INFO
11 pETYPE-info的etype-info编码
19 pa-etype-info2 DER encoding of ETYPE-INFO2
19 pa-etype-info2对etype-info2的编码
This field MAY also contain information needed by certain extensions to the Kerberos protocol. For example, it might be used to verify the identity of a client initially before any response is returned.
此字段还可能包含Kerberos协议的某些扩展所需的信息。例如，在返回任何响应之前，它可能用于最初验证客户机的身份。
The padata field can also contain information needed to help the KDC or the client select the key needed for generating or decrypting the response. This form of the padata is useful for supporting the use of certain token cards with Kerberos. The details of such extensions are specified in separate documents. See [Pat92] for additional uses of this field.
padata字段还可以包含帮助KDC或客户端选择生成或解密响应所需的密钥所需的信息。这种形式的padata对于支持使用Kerberos的某些令牌卡非常有用。此类扩展的详细信息在单独的文件中规定。有关此字段的其他用途，请参见[Pat92]。
In the case of requests for additional tickets (KRB_TGS_REQ), padata-value will contain an encoded AP-REQ. The checksum in the authenticator (which MUST be collision-proof) is to be computed over the KDC-REQ-BODY encoding.
在请求附加票据（KRB_TGS_REQ）的情况下，padata值将包含编码的AP-REQ。验证器中的校验和（必须是防冲突的）将通过KDC-REQ-BODY编码进行计算。
There are pre-authentication types that may be used to pre-authenticate a client by means of an encrypted timestamp.
有一些预认证类型可用于通过加密时间戳对客户端进行预认证。
PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC
PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC
PA-ENC-TS-ENC ::= SEQUENCE {
patimestamp [0] KerberosTime -- client's time --,
pausec [1] Microseconds OPTIONAL
}
PA-ENC-TS-ENC ::= SEQUENCE {
patimestamp [0] KerberosTime -- client's time --,
pausec [1] Microseconds OPTIONAL
}
Patimestamp contains the client's time, and pausec contains the microseconds, which MAY be omitted if a client will not generate more than one request per second. The ciphertext (padata-value) consists of the PA-ENC-TS-ENC encoding, encrypted using the client's secret key and a key usage value of 1.
Patimestamp包含客户端的时间，pausec包含微秒，如果客户端每秒生成的请求不超过一个，则可以忽略微秒。密文（padata值）由PA-ENC-TS-ENC编码组成，使用客户端的密钥加密，密钥使用值为1。
This pre-authentication type was not present in RFC 1510, but many implementations support it.
这种预认证类型在RFC 1510中不存在，但许多实现都支持它。
The padata-value for this pre-authentication type contains the salt for the string-to-key to be used by the client to obtain the key for decrypting the encrypted part of an AS-REP message. Unfortunately, for historical reasons, the character set to be used is unspecified and probably locale-specific.
此预身份验证类型的padata值包含字符串到密钥的salt，客户端将使用该字符串获取用于解密AS-REP消息加密部分的密钥。不幸的是，由于历史原因，要使用的字符集是未指定的，可能是特定于语言环境的。
This pre-authentication type was not present in RFC 1510, but many implementations support it. It is necessary in any case where the salt for the string-to-key algorithm is not the default.
这种预认证类型在RFC 1510中不存在，但许多实现都支持它。在字符串到键算法的salt不是默认值的任何情况下，这都是必要的。
In the trivial example, a zero-length salt string is very commonplace for realms that have converted their principal databases from Kerberos Version 4.
在这个简单的示例中，对于从Kerberos版本4转换其主要数据库的领域，零长度的salt字符串非常常见。
A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message that requests additional pre-authentication. Implementation note: Some KDC implementations issue an erroneous PA-PW-SALT when issuing a KRB-ERROR message that requests additional pre-authentication. Therefore, clients SHOULD ignore a PA-PW-SALT accompanying a KRB-ERROR message that requests additional pre-authentication. As noted in section 3.1.3, a KDC MUST NOT send PA-PW-SALT when the client's AS-REQ includes at least one "newer" etype.
KDC在发出请求额外预认证的KRB-ERROR消息时不应发送PA-PW-SALT。实现说明：一些KDC实现在发出请求额外预认证的KRB-ERROR消息时发出错误的PA-PW-SALT。因此，客户端应该忽略请求额外预验证的KRB错误消息附带的PA-PW-SALT。如第3.1.3节所述，当客户机的As-REQ至少包含一个“较新”的etype时，KDC不得发送PA-PW-SALT。
The ETYPE-INFO pre-authentication type is sent by the KDC in a KRB-ERROR indicating a requirement for additional pre-authentication. It is usually used to notify a client of which key to use for the encryption of an encrypted timestamp for the purposes of sending a PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an AS-REP to provide information to the client about which key salt to use for the string-to-key to be used by the client to obtain the key for decrypting the encrypted part the AS-REP.
KDC以KRB-ERROR的形式发送ETYPE-INFO预身份验证类型，表示需要额外的预身份验证。为了发送PA-ENC-timestamp预认证值，它通常用于通知客户机加密加密时间戳所使用的密钥。它还可以在AS-REP中发送，以向客户端提供关于将哪个密钥salt用于由客户端用于获取用于解密AS-REP的加密部分的密钥的字符串的密钥的信息。
ETYPE-INFO-ENTRY ::= SEQUENCE {
etype [0] Int32,
salt [1] OCTET STRING OPTIONAL
}
ETYPE-INFO-ENTRY ::= SEQUENCE {
etype [0] Int32,
salt [1] OCTET STRING OPTIONAL
}
ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY
ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY
The salt, like that of PA-PW-SALT, is also completely unspecified with respect to character set and is probably locale-specific.
salt和PA-PW-salt一样，对于字符集也是完全未指定的，并且可能是特定于语言环境的。
If ETYPE-INFO is sent in an AS-REP, there shall be exactly one ETYPE-INFO-ENTRY, and its etype shall match that of the enc-part in the AS-REP.
如果在AS-REP中发送ETYPE-INFO，则应恰好有一个ETYPE-INFO-ENTRY，且其ETYPE应与AS-REP中enc部件的ETYPE匹配。
This pre-authentication type was not present in RFC 1510, but many implementations that support encrypted timestamps for pre-authentication need to support ETYPE-INFO as well. As noted in Section 3.1.3, a KDC MUST NOT send PA-ETYPE-INFO when the client's AS-REQ includes at least one "newer" etype.
这种预认证类型在RFC1510中不存在，但许多支持预认证加密时间戳的实现也需要支持ETYPE-INFO。如第3.1.3节所述，当客户端的As-REQ至少包含一个“较新”的ETYPE时，KDC不得发送PA-ETYPE-INFO。
The ETYPE-INFO2 pre-authentication type is sent by the KDC in a KRB-ERROR indicating a requirement for additional pre-authentication. It is usually used to notify a client of which key to use for the encryption of an encrypted timestamp for the purposes of sending a PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an AS-REP to provide information to the client about which key salt to use for the string-to-key to be used by the client to obtain the key for decrypting the encrypted part the AS-REP.
KDC以KRB-ERROR的形式发送ETYPE-INFO2预身份验证类型，表示需要额外的预身份验证。为了发送PA-ENC-timestamp预认证值，它通常用于通知客户机加密加密时间戳所使用的密钥。它还可以在AS-REP中发送，以向客户端提供关于将哪个密钥salt用于由客户端用于获取用于解密AS-REP的加密部分的密钥的字符串的密钥的信息。
ETYPE-INFO2-ENTRY ::= SEQUENCE {
etype [0] Int32,
salt [1] KerberosString OPTIONAL,
s2kparams [2] OCTET STRING OPTIONAL
}
ETYPE-INFO2-ENTRY ::= SEQUENCE {
etype [0] Int32,
salt [1] KerberosString OPTIONAL,
s2kparams [2] OCTET STRING OPTIONAL
}
ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY
ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY
The type of the salt is KerberosString, but existing installations might have locale-specific characters stored in salt strings, and implementors MAY choose to handle them.
salt的类型是KerberosString，但现有安装可能在salt字符串中存储了特定于语言环境的字符，实现者可以选择处理它们。
The interpretation of s2kparams is specified in the cryptosystem description associated with the etype. Each cryptosystem has a default interpretation of s2kparams that will hold if that element is omitted from the encoding of ETYPE-INFO2-ENTRY.
s2kparams的解释在与该词组相关的密码系统描述中指定。每个密码系统都有一个s2kparams的默认解释，如果在ETYPE-INFO2-ENTRY的编码中省略该元素，该解释将保持不变。
If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in the AS-REP.
如果在AS-REP中发送ETYPE-INFO2，则应恰好有一个ETYPE-INFO2条目，且其ETYPE应与AS-REP中enc部分的ETYPE匹配。
The preferred ordering of the "hint" pre-authentication data that affect client key selection is: ETYPE-INFO2, followed by ETYPE-INFO, followed by PW-SALT. As noted in Section 3.1.3, a KDC MUST NOT send ETYPE-INFO or PW-SALT when the client's AS-REQ includes at least one "newer" etype.
影响客户端密钥选择的“提示”预验证数据的首选顺序是：ETYPE-INFO2，后跟ETYPE-INFO，后跟PW-SALT。如第3.1.3节所述，当客户的As-REQ至少包含一个“较新”的ETYPE时，KDC不得发送ETYPE-INFO或PW-SALT。
The ETYPE-INFO2 pre-authentication type was not present in RFC 1510.
RFC 1510中不存在ETYPE-INFO2预身份验证类型。
For several message types, a specific constrained bit string type, KerberosFlags, is used.
对于几种消息类型，使用特定的受约束位字符串类型KerberosFlags。
KerberosFlags ::= BIT STRING (SIZE (32..MAX))
-- minimum number of bits shall be sent,
-- but no fewer than 32
KerberosFlags ::= BIT STRING (SIZE (32..MAX))
-- minimum number of bits shall be sent,
-- but no fewer than 32
Compatibility note: The following paragraphs describe a change from the RFC 1510 description of bit strings that would result in incompatility in the case of an implementation that strictly conformed to ASN.1 DER and RFC 1510.
兼容性说明：以下段落描述了对RFC 1510位字符串描述的更改，如果实现严格遵守ASN.1 DER和RFC 1510，则会导致不兼容性。
ASN.1 bit strings have multiple uses. The simplest use of a bit string is to contain a vector of bits, with no particular meaning attached to individual bits. This vector of bits is not necessarily a multiple of eight bits long. The use in Kerberos of a bit string as a compact boolean vector wherein each element has a distinct meaning poses some problems. The natural notation for a compact boolean vector is the ASN.1 "NamedBit" notation, and the DER require that encodings of a bit string using "NamedBit" notation exclude any trailing zero bits. This truncation is easy to neglect, especially given C language implementations that naturally choose to store boolean vectors as 32-bit integers.
ASN.1位字符串有多种用途。位字符串最简单的用法是包含一个位向量，单个位没有特殊意义。该位向量不一定是八位长度的倍数。在Kerberos中使用位字符串作为紧凑的布尔向量，其中每个元素都有不同的含义，这会带来一些问题。紧凑布尔向量的自然表示法是ASN.1“NamedBit”表示法，DER要求使用“NamedBit”表示法对位字符串进行编码时排除任何尾随的零位。这种截断很容易被忽略，特别是考虑到自然选择将布尔向量存储为32位整数的C语言实现。
For example, if the notation for KDCOptions were to include the "NamedBit" notation, as in RFC 1510, and a KDCOptions value to be encoded had only the "forwardable" (bit number one) bit set, the DER encoding MUST include only two bits: the first reserved bit ("reserved", bit number zero, value zero) and the one-valued bit (bit number one) for "forwardable".
例如，如果kdcopions的表示法包括“NamedBit”表示法，如RFC 1510中所述，并且要编码的kdcopions值仅设置了“可转发”（位号1）位，则DER编码必须仅包括两位：第一个保留位（“保留”，位号0，值0）和一个值位（位号1）“可转发”。
Most existing implementations of Kerberos unconditionally send 32 bits on the wire when encoding bit strings used as boolean vectors. This behavior violates the ASN.1 syntax used for flag values in RFC 1510, but it occurs on such a widely installed base that the protocol description is being modified to accommodate it.
当编码用作布尔向量的位字符串时，大多数现有的Kerberos实现在线路上无条件地发送32位。这种行为违反了RFC1510中用于标志值的ASN.1语法，但它发生在广泛安装的基础上，因此正在修改协议描述以适应它。
Consequently, this document removes the "NamedBit" notations for individual bits, relegating them to comments. The size constraint on the KerberosFlags type requires that at least 32 bits be encoded at all times, though a lenient implementation MAY choose to accept fewer than 32 bits and to treat the missing bits as set to zero.
因此，本文档删除了单个位的“NamedBit”符号，将它们归为注释。KerberosFlags类型的大小约束要求始终至少编码32位，尽管宽松的实现可能会选择接受少于32位，并将缺少的位视为设置为零。
Currently, no uses of KerberosFlags specify more than 32 bits' worth of flags, although future revisions of this document may do so. When more than 32 bits are to be transmitted in a KerberosFlags value, future revisions to this document will likely specify that the smallest number of bits needed to encode the highest-numbered one-valued bit should be sent. This is somewhat similar to the DER encoding of a bit string that is declared with the "NamedBit" notation.
目前，没有使用KerberosFlags指定超过32位的标志，尽管本文档的未来版本可能会这样做。当在KerberosFlags值中传输超过32位时，本文件的未来修订版可能会规定应发送编码编号最高的一值位所需的最小位数。这有点类似于用“NamedBit”表示法声明的位字符串的DER编码。
Many Kerberos protocol messages contain an EncryptedData as a container for arbitrary encrypted data, which is often the encrypted encoding of another data type. Fields within EncryptedData assist the recipient in selecting a key with which to decrypt the enclosed data.
许多Kerberos协议消息包含EncryptedData作为任意加密数据的容器，这通常是另一种数据类型的加密编码。EncryptedData中的字段有助于收件人选择一个密钥来解密所包含的数据。
EncryptedData ::= SEQUENCE {
etype [0] Int32 -- EncryptionType --,
kvno [1] UInt32 OPTIONAL,
cipher [2] OCTET STRING -- ciphertext
}
EncryptedData ::= SEQUENCE {
etype [0] Int32 -- EncryptionType --,
kvno [1] UInt32 OPTIONAL,
cipher [2] OCTET STRING -- ciphertext
}
etype This field identifies which encryption algorithm was used to encipher the cipher.
etype此字段标识用于加密密码的加密算法。
kvno This field contains the version number of the key under which data is encrypted. It is only present in messages encrypted under long lasting keys, such as principals' secret keys.
kvno此字段包含加密数据的密钥的版本号。它只存在于使用持久密钥（如主体的密钥）加密的消息中。
cipher This field contains the enciphered text, encoded as an OCTET STRING. (Note that the encryption mechanisms defined in [RFC3961] MUST incorporate integrity protection as well, so no additional checksum is required.)
密码此字段包含加密文本，编码为八位字节字符串。（请注意，[RFC3961]中定义的加密机制也必须包含完整性保护，因此不需要额外的校验和。）
The EncryptionKey type is the means by which cryptographic keys used for encryption are transferred.
EncryptionKey类型是用于传输加密的加密密钥的方式。
EncryptionKey ::= SEQUENCE {
keytype [0] Int32 -- actually encryption type --,
keyvalue [1] OCTET STRING
}
EncryptionKey ::= SEQUENCE {
keytype [0] Int32 -- actually encryption type --,
keyvalue [1] OCTET STRING
}
keytype This field specifies the encryption type of the encryption key that follows in the keyvalue field. Although its name is "keytype", it actually specifies an encryption type. Previously, multiple cryptosystems that performed encryption differently but were capable of using keys with the same characteristics were permitted to share an assigned number to designate the type of key; this usage is now deprecated.
keytype此字段指定keyvalue字段中紧跟的加密密钥的加密类型。虽然它的名称是“keytype”，但它实际上指定了一种加密类型。以前，允许以不同方式执行加密但能够使用具有相同特征的密钥的多个密码系统共享指定的号码以指定密钥类型；这种用法现在已被弃用。
keyvalue This field contains the key itself, encoded as an octet string.
keyvalue此字段包含密钥本身，编码为八位字节字符串。
Messages containing cleartext data to be authenticated will usually do so by using a member of type Checksum. Most instances of Checksum use a keyed hash, though exceptions will be noted.
包含要验证的明文数据的消息通常使用Checksum类型的成员来验证。大多数校验和实例使用键控散列，但会注意到例外情况。
Checksum ::= SEQUENCE {
cksumtype [0] Int32,
checksum [1] OCTET STRING
}
Checksum ::= SEQUENCE {
cksumtype [0] Int32,
checksum [1] OCTET STRING
}
cksumtype This field indicates the algorithm used to generate the accompanying checksum.
cksumtype此字段指示用于生成伴随校验和的算法。
checksum This field contains the checksum itself, encoded as an octet string.
校验和此字段包含校验和本身，编码为八位字节字符串。
See Section 4 for a brief description of the use of encryption and checksums in Kerberos.
有关在Kerberos中使用加密和校验和的简要说明，请参见第4节。
This section describes the format and encryption parameters for tickets and authenticators. When a ticket or authenticator is included in a protocol message, it is treated as an opaque object. A ticket is a record that helps a client authenticate to a service. A Ticket contains the following information:
本节介绍票证和身份验证程序的格式和加密参数。当票证或身份验证符包含在协议消息中时，它将被视为不透明对象。票证是帮助客户端对服务进行身份验证的记录。票证包含以下信息：
Ticket ::= [APPLICATION 1] SEQUENCE {
tkt-vno [0] INTEGER (5),
realm [1] Realm,
sname [2] PrincipalName,
enc-part [3] EncryptedData -- EncTicketPart
}
Ticket ::= [APPLICATION 1] SEQUENCE {
tkt-vno [0] INTEGER (5),
realm [1] Realm,
sname [2] PrincipalName,
enc-part [3] EncryptedData -- EncTicketPart
}
-- Encrypted part of ticket
--票据的加密部分
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
flags [0] TicketFlags,
key [1] EncryptionKey,
crealm [2] Realm,
cname [3] PrincipalName,
transited [4] TransitedEncoding,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
caddr [9] HostAddresses OPTIONAL,
authorization-data [10] AuthorizationData OPTIONAL
}
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
flags [0] TicketFlags,
key [1] EncryptionKey,
crealm [2] Realm,
cname [3] PrincipalName,
transited [4] TransitedEncoding,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
caddr [9] HostAddresses OPTIONAL,
authorization-data [10] AuthorizationData OPTIONAL
}
-- encoded Transited field
TransitedEncoding ::= SEQUENCE {
tr-type [0] Int32 -- must be registered --,
contents [1] OCTET STRING
}
-- encoded Transited field
TransitedEncoding ::= SEQUENCE {
tr-type [0] Int32 -- must be registered --,
contents [1] OCTET STRING
}
TicketFlags ::= KerberosFlags
-- reserved(0),
-- forwardable(1),
-- forwarded(2),
-- proxiable(3),
-- proxy(4),
-- may-postdate(5),
-- postdated(6),
-- invalid(7),
-- renewable(8),
-- initial(9),
-- pre-authent(10),
-- hw-authent(11),
-- the following are new since 1510
-- transited-policy-checked(12),
-- ok-as-delegate(13)
TicketFlags ::= KerberosFlags
-- reserved(0),
-- forwardable(1),
-- forwarded(2),
-- proxiable(3),
-- proxy(4),
-- may-postdate(5),
-- postdated(6),
-- invalid(7),
-- renewable(8),
-- initial(9),
-- pre-authent(10),
-- hw-authent(11),
-- the following are new since 1510
-- transited-policy-checked(12),
-- ok-as-delegate(13)
tkt-vno This field specifies the version number for the ticket format. This document describes version number 5.
tkt vno此字段指定票证格式的版本号。本文档描述了版本号5。
realm This field specifies the realm that issued a ticket. It also serves to identify the realm part of the server's principal identifier. Since a Kerberos server can only issue tickets for servers within its realm, the two will always be identical.
领域此字段指定颁发票证的领域。它还用于标识服务器主体标识符的领域部分。由于Kerberos服务器只能为其领域内的服务器颁发票证，因此两者总是相同的。
sname This field specifies all components of the name part of the server's identity, including those parts that identify a specific instance of a service.
sname此字段指定服务器标识的名称部分的所有组件，包括标识特定服务实例的部分。
enc-part This field holds the encrypted encoding of the EncTicketPart sequence. It is encrypted in the key shared by Kerberos and the end server (the server's secret key), using a key usage value of 2.
enc部分此字段保存EncTicketPart序列的加密编码。它使用Kerberos和终端服务器共享的密钥（服务器的密钥）进行加密，密钥使用值为2。
flags This field indicates which of various options were used or requested when the ticket was issued. The meanings of the flags are as follows:
标志此字段指示在发出票据时使用或请求了各种选项中的哪些。这些旗帜的含义如下：
Bit(s) Name Description
位名称描述
0 reserved Reserved for future expansion of this field.
0已保留，以便将来扩展此字段。
1 forwardable The FORWARDABLE flag is normally only interpreted by the TGS, and can be ignored by end servers. When set, this flag tells the ticket-granting server that it is OK to issue a new TGT with a different network address based on the presented ticket.
1可转发通常仅由TGS解释可转发标志，终端服务器可以忽略该标志。设置后，此标志告知票证授予服务器可以根据提供的票证发出具有不同网络地址的新TGT。
2 forwarded When set, this flag indicates that the ticket has either been forwarded or was issued based on authentication involving a forwarded TGT.
2转发设置后，此标志表示票据已转发或已根据涉及转发TGT的身份验证发出。
3 proxiable The PROXIABLE flag is normally only interpreted by the TGS, and can be ignored by end servers. The PROXIABLE flag has an interpretation identical to that of the FORWARDABLE flag, except that the PROXIABLE flag tells the ticket-granting server that only non-TGTs may be issued with different network addresses.
3可代理通常仅由TGS解释可代理标志，终端服务器可以忽略该标志。可代理标志的解释与可转发标志的解释相同，只是可代理标志告诉票证授予服务器，只有非TGT可以使用不同的网络地址发出。
4 proxy When set, this flag indicates that a ticket is a proxy.
4代理设置时，此标志表示票据是代理。
5 may-postdate The MAY-POSTDATE flag is normally only interpreted by the TGS, and can be ignored by end servers. This flag tells the
5 may-postdate通常仅由TGS解释may-postdate标志，终端服务器可以忽略该标志。这面旗告诉我们
ticket-granting server that a post-dated ticket MAY be issued based on this TGT.
票证授予服务器，可基于此TGT发布过期票证。
6 postdated This flag indicates that this ticket has been postdated. The end-service can check the authtime field to see when the original authentication occurred.
6过期此标志表示此票据已过期。终端服务可以检查authtime字段以查看原始身份验证是何时发生的。
7 invalid This flag indicates that a ticket is invalid, and it must be validated by the KDC before use. Application servers must reject tickets which have this flag set.
7无效此标志表示票证无效，必须在使用前由KDC验证。应用程序服务器必须拒绝设置了此标志的票证。
8 renewable The RENEWABLE flag is normally only interpreted by the TGS, and can usually be ignored by end servers (some particularly careful servers MAY disallow renewable tickets). A renewable ticket can be used to obtain a replacement ticket that expires at a later date.
8可更新可更新标志通常仅由TGS解释，并且通常可被终端服务器忽略（一些特别小心的服务器可能不允许可更新票证）。可续期票证可用于获得在以后到期的补发票证。
9 initial This flag indicates that this ticket was issued using the AS protocol, and not issued based on a TGT.
9初始此标志表示此票证是使用AS协议发出的，而不是基于TGT发出的。
10 pre-authent This flag indicates that during initial authentication, the client was authenticated by the KDC before a ticket was issued. The strength of the pre-authentication method is not indicated, but is acceptable to the KDC.
10 pre-authent此标志表示在初始身份验证期间，客户机在发出票据之前已通过KDC的身份验证。未说明预认证方法的强度，但KDC可以接受。
11 hw-authent This flag indicates that the protocol employed for initial authentication required the use of hardware expected to be possessed solely by the named client. The hardware authentication method is selected by the KDC and the strength of the method is not indicated.
11 hw authent此标志表示用于初始身份验证的协议要求使用预期仅由指定客户端拥有的硬件。硬件认证方法由KDC选择，且未显示该方法的强度。
12 transited- This flag indicates that the KDC for policy-checked the realm has checked the transited field against a realm-defined policy for trusted certifiers. If this flag is reset (0), then the application server must check the transited field itself, and if unable to do so, it must reject the authentication. If the flag is set (1), then the application server MAY skip its own validation of the
12 transited-此标志表示域的策略检查KDC已根据域定义的受信任认证器策略检查transited字段。如果重置此标志（0），则应用程序服务器必须检查传输字段本身，如果无法检查，则必须拒绝身份验证。如果设置了该标志（1），则应用程序服务器可能会跳过其自身对该标志的验证
transited field, relying on the validation performed by the KDC. At its option the application server MAY still apply its own validation based on a separate policy for acceptance.
过渡字段，取决于KDC执行的验证。应用服务器仍可以根据单独的接受策略应用自己的验证。
This flag is new since RFC 1510.
此标志自RFC 1510以来是新的。
13 ok-as-delegate This flag indicates that the server (not the client) specified in the ticket has been determined by policy of the realm to be a suitable recipient of delegation. A client can use the presence of this flag to help it decide whether to delegate credentials (either grant a proxy or a forwarded TGT) to this server. The client is free to ignore the value of this flag. When setting this flag, an administrator should consider the security and placement of the server on which the service will run, as well as whether the service requires the use of delegated credentials.
13 ok as delegate此标志表示票证中指定的服务器（而不是客户端）已由域的策略确定为合适的委托接收者。客户端可以使用此标志的存在来帮助它决定是否将凭据（授予代理或转发的TGT）委派到此服务器。客户端可以随意忽略此标志的值。在设置此标志时，管理员应考虑服务运行的服务器的安全性和位置，以及服务是否需要使用委托凭据。
This flag is new since RFC 1510.
此标志自RFC 1510以来是新的。
14-31 reserved Reserved for future use.
14-31保留供将来使用。
key This field exists in the ticket and the KDC response and is used to pass the session key from Kerberos to the application server and the client.
key此字段存在于票据和KDC响应中，用于将会话密钥从Kerberos传递到应用程序服务器和客户端。
crealm This field contains the name of the realm in which the client is registered and in which initial authentication took place.
crealm此字段包含注册客户端和进行初始身份验证的领域的名称。
cname This field contains the name part of the client's principal identifier.
cname此字段包含客户端主体标识符的名称部分。
transited This field lists the names of the Kerberos realms that took part in authenticating the user to whom this ticket was issued. It does not specify the order in which the realms were transited. See Section 3.3.3.2 for details on how this field encodes the traversed realms. When the names of CAs are to be embedded in the transited field (as specified for some extensions to the
transited此字段列出参与验证向其颁发此票证的用户的Kerberos领域的名称。它没有指定领域被转移的顺序。请参阅第3.3.3.2节，了解该字段如何对遍历的领域进行编码的详细信息。将CA的名称嵌入transited字段中时（如某些扩展名的指定）
protocol), the X.500 names of the CAs SHOULD be mapped into items in the transited field using the mapping defined by RFC 2253.
协议），CA的X.500名称应使用RFC 2253定义的映射映射到传输字段中的项目中。
authtime This field indicates the time of initial authentication for the named principal. It is the time of issue for the original ticket on which this ticket is based. It is included in the ticket to provide additional information to the end service, and to provide the necessary information for implementation of a "hot list" service at the KDC. An end service that is particularly paranoid could refuse to accept tickets for which the initial authentication occurred "too far" in the past. This field is also returned as part of the response from the KDC. When it is returned as part of the response to initial authentication (KRB_AS_REP), this is the current time on the Kerberos server. It is NOT recommended that this time value be used to adjust the workstation's clock, as the workstation cannot reliably determine that such a KRB_AS_REP actually came from the proper KDC in a timely manner.
authtime此字段指示命名主体的初始身份验证时间。这是本票所依据的原始票的发行时间。它包含在票据中，用于向终端服务提供附加信息，并提供在KDC实现“热名单”服务所需的信息。一个特别偏执的终端服务可能会拒绝接受过去初始身份验证“太远”的票证。此字段也作为KDC响应的一部分返回。当它作为初始身份验证响应（KRB_as_REP）的一部分返回时，这是Kerberos服务器上的当前时间。不建议使用此时间值来调整工作站的时钟，因为工作站无法及时可靠地确定此类KRB_as_REP实际上来自适当的KDC。
starttime This field in the ticket specifies the time after which the ticket is valid. Together with endtime, this field specifies the life of the ticket. If the starttime field is absent from the ticket, then the authtime field SHOULD be used in its place to determine the life of the ticket.
starttime票证中的此字段指定票证有效的时间。此字段与endtime一起指定票证的有效期。如果票证中没有starttime字段，则应在其位置使用authtime字段来确定票证的有效期。
endtime This field contains the time after which the ticket will not be honored (its expiration time). Note that individual services MAY place their own limits on the life of a ticket and MAY reject tickets which have not yet expired. As such, this is really an upper bound on the expiration time for the ticket.
endtime此字段包含票证将不被兑现的时间（其到期时间）。请注意，个别服务可能会对票证的有效期设置自己的限制，并可能拒绝尚未过期的票证。因此，这实际上是门票到期时间的上限。
renew-till This field is only present in tickets that have the RENEWABLE flag set in the flags field. It indicates the maximum endtime that may be included in a renewal. It can be thought of as the absolute expiration time for the ticket, including all renewals.
续订，直到此字段仅出现在“标志”字段中设置了“可续订”标志的票证中。它表示续订中可能包含的最大结束时间。它可以被认为是机票的绝对过期时间，包括所有续签。
caddr This field in a ticket contains zero (if omitted) or more (if present) host addresses. These are the addresses from which the ticket can be used. If there are no addresses, the ticket can be used from any location. The decision by the KDC to issue or by the end server to accept addressless tickets is a policy decision and is left to the Kerberos and end-service administrators; they MAY refuse to issue or accept such tickets. Because of the wide
caddr票证中的此字段包含零个（如果省略）或多个（如果存在）主机地址。这些是可以使用票证的地址。如果没有地址，可以从任何位置使用票据。KDC发出或终端服务器接受无地址票证的决定是一个策略决定，由Kerberos和终端服务管理员决定；他们可以拒绝签发或接受此类门票。因为宽
deployment of network address translation, it is recommended that policy allow the issue and acceptance of such tickets.
部署网络地址转换时，建议政策允许签发和接受此类票据。
Network addresses are included in the ticket to make it harder for an attacker to use stolen credentials. Because the session key is not sent over the network in cleartext, credentials can't be stolen simply by listening to the network; an attacker has to gain access to the session key (perhaps through operating system security breaches or a careless user's unattended session) to make use of stolen tickets.
票证中包含网络地址，使攻击者更难使用被盗的凭据。由于会话密钥不是以明文形式通过网络发送的，因此不能通过简单的网络监听来窃取凭据；攻击者必须获得对会话密钥的访问权（可能是通过操作系统安全漏洞或粗心用户的无人参与会话）才能使用被盗的票据。
Note that the network address from which a connection is received cannot be reliably determined. Even if it could be, an attacker who has compromised the client's workstation could use the credentials from there. Including the network addresses only makes it more difficult, not impossible, for an attacker to walk off with stolen credentials and then to use them from a "safe" location.
请注意，无法可靠地确定从中接收连接的网络地址。即使可能，已破坏客户端工作站的攻击者也可以从那里使用凭据。包括网络地址只会使攻击者更难（而不是不可能）带走被盗的凭据，然后从“安全”位置使用它们。
authorization-data The authorization-data field is used to pass authorization data from the principal on whose behalf a ticket was issued to the application service. If no authorization data is included, this field will be left out. Experience has shown that the name of this field is confusing, and that a better name would be "restrictions". Unfortunately, it is not possible to change the name at this time.
授权数据授权数据字段用于向应用程序服务发送票证的委托人传递授权数据。如果未包含授权数据，则此字段将被忽略。经验表明，这一领域的名称令人困惑，更好的名称应该是“限制”。不幸的是，此时无法更改名称。
This field contains restrictions on any authority obtained on the basis of authentication using the ticket. It is possible for any principal in possession of credentials to add entries to the authorization data field since these entries further restrict what can be done with the ticket. Such additions can be made by specifying the additional entries when a new ticket is obtained during the TGS exchange, or they MAY be added during chained delegation using the authorization data field of the authenticator.
此字段包含对通过使用票据进行身份验证而获得的任何权限的限制。拥有凭证的任何主体都可以向授权数据字段添加条目，因为这些条目进一步限制了可以对票据执行的操作。当在TGS交换期间获得新票证时，可以通过指定附加条目来进行此类添加，或者可以在使用验证器的授权数据字段的链式委托期间添加这些条目。
Because entries may be added to this field by the holder of credentials, except when an entry is separately authenticated by encapsulation in the KDC-issued element, it is not allowable for the presence of an entry in the authorization data field of a ticket to amplify the privileges one would obtain from using a ticket.
由于凭证持有人可将条目添加到此字段，除非通过KDC发布元素中的封装对条目进行单独身份验证，否则不允许在票证的授权数据字段中存在条目来扩大使用票证将获得的特权。
The data in this field may be specific to the end service; the field will contain the names of service specific objects, and the rights to those objects. The format for this field is described
此字段中的数据可能特定于终端服务；该字段将包含特定于服务的对象的名称以及对这些对象的权限。此字段的格式如下所述
in Section 5.2.6. Although Kerberos is not concerned with the format of the contents of the subfields, it does carry type information (ad-type).
在第5.2.6节中。尽管Kerberos不关心子字段内容的格式，但它确实携带类型信息（ad类型）。
By using the authorization_data field, a principal is able to issue a proxy that is valid for a specific purpose. For example, a client wishing to print a file can obtain a file server proxy to be passed to the print server. By specifying the name of the file in the authorization_data field, the file server knows that the print server can only use the client's rights when accessing the particular file to be printed.
通过使用authorization_数据字段，委托人可以发布针对特定目的有效的代理。例如，希望打印文件的客户端可以获得要传递给打印服务器的文件服务器代理。通过在authorization_数据字段中指定文件名，文件服务器知道打印服务器只能在访问要打印的特定文件时使用客户端的权限。
A separate service providing authorization or certifying group membership may be built using the authorization-data field. In this case, the entity granting authorization (not the authorized entity) may obtain a ticket in its own name (e.g., the ticket is issued in the name of a privilege server), and this entity adds restrictions on its own authority and delegates the restricted authority through a proxy to the client. The client would then present this authorization credential to the application server separately from the authentication exchange. Alternatively, such authorization credentials MAY be embedded in the ticket authenticating the authorized entity, when the authorization is separately authenticated using the KDC-issued authorization data element (see 5.2.6.2).
可以使用授权数据字段构建提供授权或认证组成员资格的单独服务。在这种情况下，授予授权的实体（而非授权实体）可以以自己的名义获得票证（例如，票证以特权服务器的名义发行），该实体增加了对自身权限的限制，并通过代理将受限制的权限委托给客户端。然后，客户端会将此授权凭据与身份验证交换分开提供给应用程序服务器。或者，当使用KDC颁发的授权数据元素对授权进行单独认证时，可将此类授权凭证嵌入认证授权实体的票据中（见5.2.6.2）。
Similarly, if one specifies the authorization-data field of a proxy and leaves the host addresses blank, the resulting ticket and session key can be treated as a capability. See [Neu93] for some suggested uses of this field.
类似地，如果指定代理的授权数据字段并将主机地址留空，则生成的票据和会话密钥可以视为一种功能。有关此字段的一些建议用途，请参见[Neu93]。
The authorization-data field is optional and does not have to be included in a ticket.
授权数据字段是可选的，不必包含在票据中。
This section specifies the format of the messages used in the exchange between the client and the Kerberos server. The format of possible error messages appears in Section 5.9.1.
本节指定在客户端和Kerberos服务器之间的交换中使用的消息格式。可能错误消息的格式见第5.9.1节。
The KRB_KDC_REQ message has no application tag number of its own. Instead, it is incorporated into either KRB_AS_REQ or KRB_TGS_REQ, each of which has an application tag, depending on whether the request is for an initial ticket or an additional ticket. In either case, the message is sent from the client to the KDC to request credentials for a service.
KRB_KDC_REQ消息本身没有应用程序标签号。相反，它被合并到KRB_AS_REQ或KRB_TGS_REQ中，每个KRB_TGS_REQ都有一个应用程序标签，这取决于请求是初始票据还是附加票据。在这两种情况下，消息都从客户端发送到KDC，以请求服务的凭据。
The message fields are as follows:
消息字段如下所示：
AS-REQ ::= [APPLICATION 10] KDC-REQ
AS-REQ ::= [APPLICATION 10] KDC-REQ
TGS-REQ ::= [APPLICATION 12] KDC-REQ
TGS-REQ ::= [APPLICATION 12] KDC-REQ
KDC-REQ ::= SEQUENCE {
-- NOTE: first tag is [1], not [0]
pvno [1] INTEGER (5) ,
msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --),
padata [3] SEQUENCE OF PA-DATA OPTIONAL
-- NOTE: not empty --,
req-body [4] KDC-REQ-BODY
}
KDC-REQ ::= SEQUENCE {
-- NOTE: first tag is [1], not [0]
pvno [1] INTEGER (5) ,
msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --),
padata [3] SEQUENCE OF PA-DATA OPTIONAL
-- NOTE: not empty --,
req-body [4] KDC-REQ-BODY
}
KDC-REQ-BODY ::= SEQUENCE {
kdc-options [0] KDCOptions,
cname [1] PrincipalName OPTIONAL
-- Used only in AS-REQ --,
realm [2] Realm
-- Server's realm
-- Also client's in AS-REQ --,
sname [3] PrincipalName OPTIONAL,
from [4] KerberosTime OPTIONAL,
till [5] KerberosTime,
rtime [6] KerberosTime OPTIONAL,
nonce [7] UInt32,
etype [8] SEQUENCE OF Int32 -- EncryptionType
-- in preference order --,
addresses [9] HostAddresses OPTIONAL,
enc-authorization-data [10] EncryptedData OPTIONAL
-- AuthorizationData --,
additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
-- NOTE: not empty
}
KDC-REQ-BODY ::= SEQUENCE {
kdc-options [0] KDCOptions,
cname [1] PrincipalName OPTIONAL
-- Used only in AS-REQ --,
realm [2] Realm
-- Server's realm
-- Also client's in AS-REQ --,
sname [3] PrincipalName OPTIONAL,
from [4] KerberosTime OPTIONAL,
till [5] KerberosTime,
rtime [6] KerberosTime OPTIONAL,
nonce [7] UInt32,
etype [8] SEQUENCE OF Int32 -- EncryptionType
-- in preference order --,
addresses [9] HostAddresses OPTIONAL,
enc-authorization-data [10] EncryptedData OPTIONAL
-- AuthorizationData --,
additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
-- NOTE: not empty
}
KDCOptions ::= KerberosFlags
-- reserved(0),
-- forwardable(1),
-- forwarded(2),
-- proxiable(3),
-- proxy(4),
-- allow-postdate(5),
-- postdated(6),
-- unused7(7),
-- renewable(8),
-- unused9(9),
-- unused10(10),
KDCOptions ::= KerberosFlags
-- reserved(0),
-- forwardable(1),
-- forwarded(2),
-- proxiable(3),
-- proxy(4),
-- allow-postdate(5),
-- postdated(6),
-- unused7(7),
-- renewable(8),
-- unused9(9),
-- unused10(10),
-- opt-hardware-auth(11),
-- unused12(12),
-- unused13(13),
-- 15 is reserved for canonicalize
-- unused15(15),
-- 26 was unused in 1510
-- disable-transited-check(26),
--
-- renewable-ok(27),
-- enc-tkt-in-skey(28),
-- renew(30),
-- validate(31)
-- opt-hardware-auth(11),
-- unused12(12),
-- unused13(13),
-- 15 is reserved for canonicalize
-- unused15(15),
-- 26 was unused in 1510
-- disable-transited-check(26),
--
-- renewable-ok(27),
-- enc-tkt-in-skey(28),
-- renew(30),
-- validate(31)
The fields in this message are as follows:
此消息中的字段如下所示：
pvno This field is included in each message, and specifies the protocol version number. This document specifies protocol version 5.
pvno此字段包含在每条消息中，并指定协议版本号。本文件规定了协议版本5。
msg-type This field indicates the type of a protocol message. It will almost always be the same as the application identifier associated with a message. It is included to make the identifier more readily accessible to the application. For the KDC-REQ message, this type will be KRB_AS_REQ or KRB_TGS_REQ.
msg type此字段指示协议消息的类型。它几乎总是与消息关联的应用程序标识符相同。包括它是为了使应用程序更容易访问标识符。对于KDC-REQ消息，此类型将为KRB_AS_REQ或KRB_TGS_REQ。
padata Contains pre-authentication data. Requests for additional tickets (KRB_TGS_REQ) MUST contain a padata of PA-TGS-REQ.
padata包含预验证数据。额外票证请求（KRB_TGS_REQ）必须包含PA-TGS-REQ的padata。
The padata (pre-authentication data) field contains a sequence of authentication information that may be needed before credentials can be issued or decrypted.
padata（预认证数据）字段包含在颁发或解密凭据之前可能需要的认证信息序列。
req-body This field is a placeholder delimiting the extent of the remaining fields. If a checksum is to be calculated over the request, it is calculated over an encoding of the KDC-REQ-BODY sequence which is enclosed within the req-body field.
req body此字段是一个占位符，用于分隔其余字段的范围。如果要对请求计算校验和，则通过包含在REQ BODY字段中的KDC-REQ-BODY序列编码计算校验和。
kdc-options This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the KDC and indicates the flags that the client wants set on the tickets as well as other information that is to modify the behavior of the KDC. Where appropriate, the name of an option may be the same as the flag that is set by that option. Although in most cases, the bit in the options field will be the same as that in the flags field, this is not guaranteed, so it is not
kdc选项此字段出现在KRB_AS_REQ和KRB_TGS_REQ对kdc的请求中，指示客户端希望在票据上设置的标志以及修改kdc行为的其他信息。在适当的情况下，选项的名称可以与该选项设置的标志相同。虽然在大多数情况下，选项字段中的位将与标志字段中的位相同，但这并不能保证，因此不能保证
acceptable simply to copy the options field to the flags field. There are various checks that must be made before an option is honored anyway.
只需将选项字段复制到标志字段即可。无论如何，在兑现期权之前，必须进行各种检查。
The kdc_options field is a bit-field, where the selected options are indicated by the bit being set (1), and the unselected options and reserved fields being reset (0). The encoding of the bits is specified in Section 5.2. The options are described in more detail above in Section 2. The meanings of the options are as follows:
kdc_选项字段是位字段，其中所选选项由设置的位（1）指示，未选择的选项和保留字段被重置（0）。第5.2节规定了位的编码。以上第2节对选项进行了更详细的描述。期权的含义如下：
Bits Name Description
位名称描述
0 RESERVED Reserved for future expansion of this field.
0已保留，以便将来扩展此字段。
1 FORWARDABLE The FORWARDABLE option indicates that the ticket to be issued is to have its forwardable flag set. It may only be set on the initial request, or in a subsequent request if the TGT on which it is based is also forwardable.
1可转发可转发选项表示要发布的票证将设置其可转发标志。它只能在初始请求上设置，如果它所基于的TGT也是可转发的，则可以在后续请求中设置。
2 FORWARDED The FORWARDED option is only specified in a request to the ticket-granting server and will only be honored if the TGT in the request has its FORWARDABLE bit set. This option indicates that this is a request for forwarding. The address(es) of the host from which the resulting ticket is to be valid are included in the addresses field of the request.
2转发转发选项仅在对票证授予服务器的请求中指定，并且只有在请求中的TGT设置了其可转发位时才会被接受。此选项表示这是一个转发请求。请求的addresses字段中包含生成的票证有效的主机地址。
3 PROXIABLE The PROXIABLE option indicates that the ticket to be issued is to have its proxiable flag set. It may only be set on the initial request, or a subsequent request if the TGT on which it is based is also proxiable.
3可代理可代理选项表示要发布的票证将设置其可代理标志。它只能在初始请求上设置，如果它所基于的TGT也是可代理的，则可以在后续请求上设置。
4 PROXY The PROXY option indicates that this is a request for a proxy. This option will only be honored if the TGT in the request has its PROXIABLE bit set. The address(es) of the
4代理代理选项表示这是一个代理请求。只有当请求中的TGT设置了其可代理位时，才会使用此选项。申请人的地址
host from which the resulting ticket is to be valid are included in the addresses field of the request.
请求的地址字段中包括生成的票证有效的主机。
5 ALLOW-POSTDATE The ALLOW-POSTDATE option indicates that the ticket to be issued is to have its MAY-POSTDATE flag set. It may only be set on the initial request, or in a subsequent request if the TGT on which it is based also has its MAY-POSTDATE flag set.
5 ALLOW-POSTDATE ALLOW-POSTDATE选项表示要发行的票据将设置其MAY-POSTDATE标志。它只能在初始请求上设置，如果它所基于的TGT也设置了may-POSTDATE标志，则可以在后续请求中设置。
6 POSTDATED The POSTDATED option indicates that this is a request for a postdated ticket. This option will only be honored if the TGT on which it is based has its MAY-POSTDATE flag set. The resulting ticket will also have its INVALID flag set, and that flag may be reset by a subsequent request to the KDC after the starttime in the ticket has been reached.
6过期过期选项表示这是对过期票据的请求。只有当它所基于的TGT设置了MAY-POSTDATE标志时，才会使用此选项。生成的票证也将设置其无效标志，并且在达到票证中的起始时间后，该标志可能会通过随后向KDC发出的请求而重置。
7 RESERVED This option is presently unused.
7保留此选项目前未使用。
8 RENEWABLE The RENEWABLE option indicates that the ticket to be issued is to have its RENEWABLE flag set. It may only be set on the initial request, or when the TGT on which the request is based is also renewable. If this option is requested, then the rtime field in the request contains the desired absolute expiration time for the ticket.
8可续期可续期选项表示要发行的票证将设置其可续期标志。它只能在初始请求上设置，或者当请求所基于的TGT也是可更新的时设置。如果请求此选项，则请求中的rtime字段包含票证所需的绝对过期时间。
9 RESERVED Reserved for PK-Cross.
9为PK交叉预留。
10 RESERVED Reserved for future use.
10保留供将来使用。
11 RESERVED Reserved for opt-hardware-auth.
11为opt硬件验证保留。
12-25 RESERVED Reserved for future use.
12-25保留供将来使用。
26 DISABLE-TRANSITED-CHECK By default the KDC will check the transited field of a TGT against the policy of the local realm before it will issue derivative tickets based
26 DISABLE-TRANSITED-CHECK默认情况下，KDC将根据本地域的策略检查TGT的TRANSITED字段，然后再根据本地域的策略发出派生票据
on the TGT. If this flag is set in the request, checking of the transited field is disabled. Tickets issued without the performance of this check will be noted by the reset (0) value of the TRANSITED-POLICY-CHECKED flag, indicating to the application server that the transited field must be checked locally. KDCs are encouraged but not required to honor the DISABLE-TRANSITED-CHECK option.
在TGT上。如果在请求中设置了此标志，则禁用对传输字段的检查。未执行此检查而发出的票证将通过TRANSITED-POLICY-CHECKED标志的重置（0）值进行记录，向应用程序服务器指示必须在本地检查TRANSITED字段。鼓励KDC，但不要求KDC遵守DISABLE-TRANSTED-CHECK选项。
This flag is new since RFC 1510.
此标志自RFC 1510以来是新的。
27 RENEWABLE-OK The RENEWABLE-OK option indicates that a renewable ticket will be acceptable if a ticket with the requested life cannot otherwise be provided, in which case a renewable ticket may be issued with a renew-till equal to the requested endtime. The value of the renew-till field may still be limited by local limits, or limits selected by the individual principal or server.
27 RENERABLE-OK RENERABLE-OK选项表示，如果无法提供具有所请求寿命的票证，则可接受可续期票证，在这种情况下，可续期票证可在与所请求的结束时间相等的时间内发行。续订至字段的值仍可能受到本地限制或单个主体或服务器选择的限制。
28 ENC-TKT-IN-SKEY This option is used only by the ticket-granting service. The ENC-TKT-IN-SKEY option indicates that the ticket for the end server is to be encrypted in the session key from the additional TGT provided.
28 ENC-TKT-IN-SKEY此选项仅由票证授予服务使用。ENC-TKT-IN-SKEY选项表示终端服务器的票据将在提供的附加TGT的会话密钥中加密。
29 RESERVED Reserved for future use.
29保留供将来使用。
30 RENEW This option is used only by the ticket-granting service. The RENEW option indicates that the present request is for a renewal. The ticket provided is encrypted in the secret key for the server on which it is valid. This option will only be honored if the ticket to be renewed has its RENEWABLE flag set and if the time in its renew-till field has not passed. The ticket to be renewed is passed in the padata
30续订此选项仅由票证授予服务使用。“续订”选项表示当前请求是续订。提供的票证在其有效的服务器的密钥中加密。仅当要续订的票证设置了“可续订”标志且“续订至”字段中的时间未过时，才会使用此选项。待更新的车票在padata中通过
field as part of the authentication header.
字段作为身份验证标头的一部分。
31 VALIDATE This option is used only by the ticket-granting service. The VALIDATE option indicates that the request is to validate a postdated ticket. It will only be honored if the ticket presented is postdated, presently has its INVALID flag set, and would otherwise be usable at this time. A ticket cannot be validated before its starttime. The ticket presented for validation is encrypted in the key of the server for which it is valid and is passed in the padata field as part of the authentication header.
31验证此选项仅由票证授予服务使用。VALIDATE选项表示请求是验证过期票据。仅当出示的票证过期，当前设置了无效标志，并且此时可用时，才会予以兑现。票证在其开始时间之前无法验证。提供用于验证的票证在其有效的服务器密钥中加密，并作为身份验证标头的一部分在padata字段中传递。
cname and sname These fields are the same as those described for the ticket in section 5.3. The sname may only be absent when the ENC-TKT-IN-SKEY option is specified. If the sname is absent, the name of the server is taken from the name of the client in the ticket passed as additional-tickets.
cname和sname这些字段与第5.3节中描述的票证字段相同。只有在指定ENC-TKT-IN-SKEY选项时，sname才可能不存在。如果sname不存在，则服务器的名称取自作为附加票证传递的票证中的客户机名称。
enc-authorization-data The enc-authorization-data, if present (and it can only be present in the TGS_REQ form), is an encoding of the desired authorization-data encrypted under the sub-session key if present in the Authenticator, or alternatively from the session key in the TGT (both the Authenticator and TGT come from the padata field in the KRB_TGS_REQ). The key usage value used when encrypting is 5 if a sub-session key is used, or 4 if the session key is used.
enc授权数据enc授权数据（如果存在）（并且只能以TGS_REQ形式存在）是在子会话密钥（如果存在于验证器中）下加密的所需授权数据的编码，或者是从TGT中的会话密钥加密的所需授权数据的编码（Authenticator和TGT都来自KRB_TGS_REQ中的padata字段）。加密时使用的密钥使用值为5（如果使用子会话密钥），或4（如果使用会话密钥）。
realm This field specifies the realm part of the server's principal identifier. In the AS exchange, this is also the realm part of the client's principal identifier.
领域此字段指定服务器主体标识符的领域部分。在AS交换中，这也是客户端主体标识符的领域部分。
from This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket requests when the requested ticket is to be postdated. It specifies the desired starttime for the requested ticket. If this field is omitted, then the KDC SHOULD use the current time instead.
当请求的票证要延期时，此字段包含在KRB_AS_REQ和KRB_TGS_REQ票证请求中。它为请求的票证指定所需的开始时间。如果省略此字段，则KDC应使用当前时间。
till This field contains the expiration date requested by the client in a ticket request. It is not optional, but if the requested endtime is "19700101000000Z", the requested ticket is to have the maximum endtime permitted according to KDC policy. Implementation note: This special timestamp corresponds to a UNIX time_t value of zero on most systems.
直到此字段包含客户机在票据请求中请求的到期日期。它不是可选的，但如果请求的结束时间是“19700101000000Z”，则请求的票证将具有KDC策略允许的最大结束时间。实现说明：这个特殊的时间戳对应于大多数系统上的UNIX时间值为零。
rtime This field is the requested renew-till time sent from a client to the KDC in a ticket request. It is optional.
rtime此字段是在票证请求中从客户端发送到KDC的请求续订时间。它是可选的。
nonce This field is part of the KDC request and response. It is intended to hold a random number generated by the client. If the same number is included in the encrypted response from the KDC, it provides evidence that the response is fresh and has not been replayed by an attacker. Nonces MUST NEVER be reused.
nonce此字段是KDC请求和响应的一部分。它用于保存客户端生成的随机数。如果来自KDC的加密响应中包含相同的数字，则会提供证据证明响应是新的，并且未被攻击者重放。不得重复使用nonce。
etype This field specifies the desired encryption algorithm to be used in the response.
etype此字段指定要在响应中使用的所需加密算法。
addresses This field is included in the initial request for tickets, and it is optionally included in requests for additional tickets from the ticket-granting server. It specifies the addresses from which the requested ticket is to be valid. Normally it includes the addresses for the client's host. If a proxy is requested, this field will contain other addresses. The contents of this field are usually copied by the KDC into the caddr field of the resulting ticket.
地址此字段包含在初始票证请求中，并且可以选择包含在来自票证授予服务器的附加票证请求中。它指定请求的票证的有效地址。通常它包括客户端主机的地址。如果请求代理，此字段将包含其他地址。此字段的内容通常由KDC复制到生成票据的caddr字段中。
additional-tickets Additional tickets MAY be optionally included in a request to the ticket-granting server. If the ENC-TKT-IN-SKEY option has been specified, then the session key from the additional ticket will be used in place of the server's key to encrypt the new ticket. When the ENC-TKT-IN-SKEY option is used for user-to-user authentication, this additional ticket MAY be a TGT issued by the local realm or an inter-realm TGT issued for the current KDC's realm by a remote KDC. If more than one option that requires additional tickets has been specified, then the additional tickets are used in the order specified by the ordering of the options bits (see kdc-options, above).
附加票证附加票证可选择性地包括在对票证授予服务器的请求中。如果已指定ENC-TKT-IN-SKEY选项，则将使用附加票据中的会话密钥代替服务器密钥来加密新票据。当ENC-TKT-IN-SKEY选项用于用户对用户身份验证时，此附加票证可以是本地域颁发的TGT，也可以是远程KDC为当前KDC域颁发的域间TGT。如果指定了多个需要附加票证的选项，则附加票证将按照选项位顺序指定的顺序使用（请参阅上面的kdc选项）。
The application tag number will be either ten (10) or twelve (12) depending on whether the request is for an initial ticket (AS-REQ) or for an additional ticket (TGS-REQ).
应用程序标签号为十（10）或十二（12），具体取决于请求是针对初始票据（AS-REQ）还是针对附加票据（TGS-REQ）。
The optional fields (addresses, authorization-data, and additional-tickets) are only included if necessary to perform the operation specified in the kdc-options field.
只有在执行kdc选项字段中指定的操作需要时，才包括可选字段（地址、授权数据和附加票据）。
Note that in KRB_TGS_REQ, the protocol version number appears twice and two different message types appear: the KRB_TGS_REQ message contains these fields as does the authentication header (KRB_AP_REQ) that is passed in the padata field.
请注意，在KRB_TGS_REQ中，协议版本号显示两次，并显示两种不同的消息类型：KRB_TGS_REQ消息包含这些字段，padata字段中传递的身份验证标头（KRB_AP_REQ）也包含这些字段。
The KRB_KDC_REP message format is used for the reply from the KDC for either an initial (AS) request or a subsequent (TGS) request. There is no message type for KRB_KDC_REP. Instead, the type will be either KRB_AS_REP or KRB_TGS_REP. The key used to encrypt the ciphertext part of the reply depends on the message type. For KRB_AS_REP, the ciphertext is encrypted in the client's secret key, and the client's key version number is included in the key version number for the encrypted data. For KRB_TGS_REP, the ciphertext is encrypted in the sub-session key from the Authenticator; if it is absent, the ciphertext is encrypted in the session key from the TGT used in the request. In that case, no version number will be present in the EncryptedData sequence.
KRB_KDC_REP消息格式用于KDC对初始（AS）请求或后续（TGS）请求的回复。KRB_KDC_REP没有消息类型。相反，该类型将是KRB_AS_REP或KRB_TGS_REP。用于加密回复的密文部分的密钥取决于消息类型。对于KRB_AS_REP，密文在客户端的密钥中加密，客户端的密钥版本号包含在加密数据的密钥版本号中。对于KRB_TGS_REP，密文在来自认证器的子会话密钥中加密；如果不存在，则在请求中使用的TGT会话密钥中加密密文。在这种情况下，EncryptedData序列中将不存在版本号。
The KRB_KDC_REP message contains the following fields:
KRB_KDC_REP消息包含以下字段：
AS-REP ::= [APPLICATION 11] KDC-REP
AS-REP ::= [APPLICATION 11] KDC-REP
TGS-REP ::= [APPLICATION 13] KDC-REP
TGS-REP ::= [APPLICATION 13] KDC-REP
KDC-REP ::= SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --),
padata [2] SEQUENCE OF PA-DATA OPTIONAL
-- NOTE: not empty --,
crealm [3] Realm,
cname [4] PrincipalName,
ticket [5] Ticket,
enc-part [6] EncryptedData
-- EncASRepPart or EncTGSRepPart,
-- as appropriate
}
KDC-REP ::= SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --),
padata [2] SEQUENCE OF PA-DATA OPTIONAL
-- NOTE: not empty --,
crealm [3] Realm,
cname [4] PrincipalName,
ticket [5] Ticket,
enc-part [6] EncryptedData
-- EncASRepPart or EncTGSRepPart,
-- as appropriate
}
EncASRepPart ::= [APPLICATION 25] EncKDCRepPart
EncASRepPart ::= [APPLICATION 25] EncKDCRepPart
EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
EncKDCRepPart ::= SEQUENCE {
key [0] EncryptionKey,
last-req [1] LastReq,
nonce [2] UInt32,
key-expiration [3] KerberosTime OPTIONAL,
flags [4] TicketFlags,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
srealm [9] Realm,
sname [10] PrincipalName,
caddr [11] HostAddresses OPTIONAL
}
EncKDCRepPart ::= SEQUENCE {
key [0] EncryptionKey,
last-req [1] LastReq,
nonce [2] UInt32,
key-expiration [3] KerberosTime OPTIONAL,
flags [4] TicketFlags,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
srealm [9] Realm,
sname [10] PrincipalName,
caddr [11] HostAddresses OPTIONAL
}
LastReq ::= SEQUENCE OF SEQUENCE {
lr-type [0] Int32,
lr-value [1] KerberosTime
}
LastReq ::= SEQUENCE OF SEQUENCE {
lr-type [0] Int32,
lr-value [1] KerberosTime
}
pvno and msg-type These fields are described above in Section 5.4.1. msg-type is either KRB_AS_REP or KRB_TGS_REP.
pvno和msg类型这些字段如上文第5.4.1节所述。消息类型为KRB_AS_REP或KRB_TGS_REP。
padata This field is described in detail in Section 5.4.1. One possible use for it is to encode an alternate "salt" string to be used with a string-to-key algorithm. This ability is useful for easing transitions if a realm name needs to change (e.g., when a company is acquired); in such a case all existing password-derived entries in the KDC database would be flagged as needing a special salt string until the next password change.
padata第5.4.1节详细描述了该字段。它的一个可能用途是对备用“salt”字符串进行编码，以便与字符串到键算法一起使用。如果域名需要更改（例如，当一家公司被收购时），此功能有助于简化转换；在这种情况下，KDC数据库中所有现有的密码派生条目都将被标记为需要特殊的salt字符串，直到下一次密码更改。
crealm, cname, srealm, and sname These fields are the same as those described for the ticket in section 5.3.
crealm、cname、srealm和sname这些字段与第5.3节中描述的票证字段相同。
ticket The newly-issued ticket, from Section 5.3.
根据第5.3节的规定，为新发行的车票开具车票。
enc-part This field is a place holder for the ciphertext and related information that forms the encrypted part of a message. The description of the encrypted part of the message follows each appearance of this field.
enc part此字段是构成邮件加密部分的密文和相关信息的占位符。消息加密部分的描述在该字段的每个外观后面。
The key usage value for encrypting this field is 3 in an AS-REP message, using the client's long-term key or another key selected via pre-authentication mechanisms. In a TGS-REP message, the key usage value is 8 if the TGS session key is used, or 9 if a TGS authenticator subkey is used.
在AS-REP消息中，使用客户端的长期密钥或通过预身份验证机制选择的另一个密钥加密此字段的密钥使用值为3。在TGS-REP消息中，如果使用TGS会话密钥，则密钥使用值为8；如果使用TGS验证器子密钥，则密钥使用值为9。
Compatibility note: Some implementations unconditionally send an encrypted EncTGSRepPart (application tag number 26) in this field regardless of whether the reply is a AS-REP or a TGS-REP. In the interest of compatibility, implementors MAY relax the check on the tag number of the decrypted ENC-PART.
兼容性说明：一些实现无条件地在该字段中发送加密的EncTgsReport（应用程序标签号26），无论回复是AS-REP还是TGS-REP。为了兼容性，实现者可以放松对解密的ENC-PART的标签号的检查。
key This field is the same as described for the ticket in Section 5.3.
密钥此字段与第5.3节中描述的票据相同。
last-req This field is returned by the KDC and specifies the time(s) of the last request by a principal. Depending on what information is available, this might be the last time that a request for a TGT was made, or the last time that a request based on a TGT was successful. It also might cover all servers for a realm, or just the particular server. Some implementations MAY display this information to the user to aid in discovering unauthorized use of one's identity. It is similar in spirit to the last login time displayed when logging in to timesharing systems.
last req此字段由KDC返回，并指定主体上次请求的时间。根据可用的信息，这可能是最后一次请求TGT，或者基于TGT的请求最后一次成功。它还可能覆盖一个领域的所有服务器，或者只覆盖特定的服务器。一些实现可能会向用户显示此信息，以帮助发现未经授权的身份使用。它与登录分时系统时显示的上次登录时间在精神上类似。
lr-type This field indicates how the following lr-value field is to be interpreted. Negative values indicate that the information pertains only to the responding server. Non-negative values pertain to all servers for the realm.
lr类型此字段指示如何解释以下lr值字段。负值表示信息仅与响应服务器相关。非负值适用于域的所有服务器。
If the lr-type field is zero (0), then no information is conveyed by the lr-value subfield. If the absolute value of the lr-type field is one (1), then the lr-value subfield is the time of last initial request for a TGT. If it is two (2), then the lr-value subfield is the time of last initial request. If it is three (3), then the lr-value subfield is the time of issue for the newest TGT used. If it is four (4), then the lr-value subfield is the time of the last renewal. If it is five (5), then the lr-value subfield is the time of last request (of any type). If it is (6), then the lr-value subfield is the time when the password will expire. If it is (7), then the lr-value subfield is the time when the account will expire.
如果lr type字段为零（0），则lr value子字段不会传递任何信息。如果lr type字段的绝对值为一（1），则lr value子字段是最后一次初始请求TGT的时间。如果是两（2），则lr value子字段是最后一次初始请求的时间。如果是三（3），则lr value子字段是所用最新TGT的发布时间。如果为四（4），则lr value子字段为上次续订的时间。如果是五（5），则lr value子字段是最后一次请求（任何类型）的时间。如果是（6），则lr value子字段是密码过期的时间。如果是（7），则lr value子字段是帐户到期的时间。
lr-value This field contains the time of the last request. The time MUST be interpreted according to the contents of the accompanying lr-type subfield.
lr值此字段包含上次请求的时间。必须根据随附的lr类型子字段的内容解释时间。
nonce This field is described above in Section 5.4.1.
此字段如上文第5.4.1节所述。
key-expiration The key-expiration field is part of the response from the KDC and specifies the time that the client's secret key is due to expire. The expiration might be the result of password aging or an account expiration. If present, it SHOULD be set to the earlier of the user's key expiration and account expiration. The use of this field is deprecated, and the last-req field SHOULD be used to convey this information instead. This field will usually be left out of the TGS reply since the response to the TGS request is encrypted in a session key and no client information has to be retrieved from the KDC database. It is up to the application client (usually the login program) to take appropriate action (such as notifying the user) if the expiration time is imminent.
密钥过期密钥过期字段是KDC响应的一部分，并指定客户端密钥到期的时间。过期可能是密码过期或帐户过期的结果。如果存在，则应将其设置为用户密钥过期和帐户过期中的较早者。不推荐使用此字段，而应使用最后一个req字段来传递此信息。由于TGS请求的响应在会话密钥中加密，并且不必从KDC数据库检索客户机信息，因此TGS回复中通常不包含此字段。如果到期时间即将到来，则应由应用程序客户端（通常是登录程序）采取适当的操作（例如通知用户）。
flags, authtime, starttime, endtime, renew-till and caddr These fields are duplicates of those found in the encrypted portion of the attached ticket (see Section 5.3), provided so the client MAY verify that they match the intended request and in order to assist in proper ticket caching. If the message is of type KRB_TGS_REP, the caddr field will only be filled in if the request was for a proxy or forwarded ticket, or if the user is substituting a subset of the addresses from the TGT. If the client-requested addresses are not present or not used, then the addresses contained in the ticket will be the same as those included in the TGT.
标志、authtime、starttime、endtime、renew-till和caddr这些字段与所附票据加密部分中的字段重复（参见第5.3节），以便客户可以验证它们是否符合预期的请求，并帮助正确的票据缓存。如果消息类型为KRB_TGS_REP，则只有在请求代理或转发票证，或者用户正在替换来自TGT的地址子集时，才会填写caddr字段。如果客户端请求的地址不存在或未使用，则票证中包含的地址将与TGT中包含的地址相同。
This section specifies the format of the messages used for the authentication of the client to the application server.
本节指定用于将客户端身份验证到应用程序服务器的消息格式。
The KRB_AP_REQ message contains the Kerberos protocol version number, the message type KRB_AP_REQ, an options field to indicate any options in use, and the ticket and authenticator themselves. The KRB_AP_REQ message is often referred to as the "authentication header".
KRB_AP_REQ消息包含Kerberos协议版本号、消息类型KRB_AP_REQ、指示正在使用的任何选项的选项字段，以及票据和身份验证程序本身。KRB_AP_REQ消息通常被称为“身份验证头”。
AP-REQ ::= [APPLICATION 14] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (14),
ap-options [2] APOptions,
ticket [3] Ticket,
authenticator [4] EncryptedData -- Authenticator
}
AP-REQ ::= [APPLICATION 14] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (14),
ap-options [2] APOptions,
ticket [3] Ticket,
authenticator [4] EncryptedData -- Authenticator
}
APOptions ::= KerberosFlags
-- reserved(0),
-- use-session-key(1),
-- mutual-required(2)
APOptions ::= KerberosFlags
-- reserved(0),
-- use-session-key(1),
-- mutual-required(2)
pvno and msg-type These fields are described above in Section 5.4.1. msg-type is KRB_AP_REQ.
pvno和msg类型这些字段如上文第5.4.1节所述。消息类型为KRB_AP_REQ。
ap-options This field appears in the application request (KRB_AP_REQ) and affects the way the request is processed. It is a bit-field, where the selected options are indicated by the bit being set (1), and the unselected options and reserved fields by being reset (0). The encoding of the bits is specified in Section 5.2. The meanings of the options are as follows:
ap options此字段出现在应用程序请求（KRB_ap_REQ）中，并影响处理请求的方式。它是一个位字段，其中所选选项由设置的位（1）指示，未选选项和保留字段由重置（0）指示。第5.2节规定了位的编码。期权的含义如下：
Bit(s) Name Description
位名称描述
0 reserved Reserved for future expansion of this field.
0已保留，以便将来扩展此字段。
1 use-session-key The USE-SESSION-KEY option indicates that the ticket the client is presenting to a server is encrypted in the session key from the server's TGT. When this option is not specified, the ticket is encrypted in the server's secret key.
1使用会话密钥use-session-key选项表示客户端呈现给服务器的票据在来自服务器TGT的会话密钥中加密。如果未指定此选项，则将在服务器的密钥中对票据进行加密。
2 mutual-required The MUTUAL-REQUIRED option tells the server that the client requires mutual authentication, and that it must respond with a KRB_AP_REP message.
2 mutual required mutual-required选项告诉服务器客户端需要相互身份验证，并且它必须使用KRB_AP_REP消息进行响应。
3-31 reserved Reserved for future use.
3-31保留供将来使用。
ticket This field is a ticket authenticating the client to the server.
票证此字段是向服务器验证客户端的票证。
authenticator This contains the encrypted authenticator, which includes the client's choice of a subkey.
authenticator包含加密的authenticator，其中包括客户端对子密钥的选择。
The encrypted authenticator is included in the AP-REQ; it certifies to a server that the sender has recent knowledge of the encryption key in the accompanying ticket, to help the server detect replays. It also assists in the selection of a "true session key" to use with the particular session. The DER encoding of the following is encrypted in the ticket's session key, with a key usage value of 11 in normal application exchanges, or 7 when used as the PA-TGS-REQ PA-DATA field of a TGS-REQ exchange (see Section 5.4.1):
加密认证器包括在AP-REQ中；它向服务器证明发送方最近知道随附票据中的加密密钥，以帮助服务器检测重播。它还帮助选择用于特定会话的“真正会话密钥”。以下的DER编码在票据的会话密钥中加密，在正常应用程序交换中密钥使用值为11，或在用作TGS-REQ交换的PA-TGS-REQ PA-DATA字段时为7（见第5.4.1节）：
-- Unencrypted authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno [0] INTEGER (5),
crealm [1] Realm,
cname [2] PrincipalName,
cksum [3] Checksum OPTIONAL,
cusec [4] Microseconds,
ctime [5] KerberosTime,
subkey [6] EncryptionKey OPTIONAL,
seq-number [7] UInt32 OPTIONAL,
authorization-data [8] AuthorizationData OPTIONAL
}
-- Unencrypted authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno [0] INTEGER (5),
crealm [1] Realm,
cname [2] PrincipalName,
cksum [3] Checksum OPTIONAL,
cusec [4] Microseconds,
ctime [5] KerberosTime,
subkey [6] EncryptionKey OPTIONAL,
seq-number [7] UInt32 OPTIONAL,
authorization-data [8] AuthorizationData OPTIONAL
}
authenticator-vno This field specifies the version number for the format of the authenticator. This document specifies version 5.
authenticator vno此字段指定验证器格式的版本号。本文件规定了第5版。
crealm and cname These fields are the same as those described for the ticket in section 5.3.
crealm和cname这些字段与第5.3节中描述的票证字段相同。
cksum This field contains a checksum of the application data that accompanies the KRB_AP_REQ, computed using a key usage value of 10 in normal application exchanges, or 6 when used in the TGS-REQ PA-TGS-REQ AP-DATA field.
cksum此字段包含KRB_AP_REQ附带的应用程序数据校验和，在正常应用程序交换中使用密钥使用值10计算，或在TGS-REQ PA-TGS-REQ AP-data字段中使用密钥使用值6计算。
cusec This field contains the microsecond part of the client's timestamp. Its value (before encryption) ranges from 0 to 999999. It often appears along with ctime. The two fields are used together to specify a reasonably accurate timestamp.
cusec此字段包含客户端时间戳的微秒部分。其值（加密前）范围为0到999999。它经常与ctime一起出现。这两个字段一起用于指定合理准确的时间戳。
ctime This field contains the current time on the client's host.
ctime此字段包含客户端主机上的当前时间。
subkey This field contains the client's choice for an encryption key to be used to protect this specific application session. Unless an application specifies otherwise, if this field is left out, the session key from the ticket will be used.
子密钥此字段包含客户端选择用于保护此特定应用程序会话的加密密钥。除非应用程序另有规定，否则如果省略此字段，将使用票据中的会话密钥。
seq-number This optional field includes the initial sequence number to be used by the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to detect replays. (It may also be used by application specific messages.) When included in the authenticator, this field specifies the initial sequence number for messages from the client to the server. When included in the AP-REP message, the initial sequence number is that for messages from the server to the client. When used in KRB_PRIV or KRB_SAFE messages, it is incremented by one after each message is sent. Sequence numbers fall in the range 0 through 2^32 - 1 and wrap to zero following the value 2^32 - 1.
seq number此可选字段包括当序列号用于检测重播时，KRB_PRIV或KRB_SAFE消息将使用的初始序列号。（也可由特定于应用程序的消息使用。）当包含在身份验证程序中时，此字段指定从客户端到服务器的消息的初始序列号。当包含在AP-REP消息中时，初始序列号为从服务器到客户端的消息的序列号。在KRB_PRIV或KRB_SAFE消息中使用时，在发送每条消息后，它将递增1。序列号在0到2^32-1的范围内，并在值2^32-1后换行为零。
For sequence numbers to support the detection of replays adequately, they SHOULD be non-repeating, even across connection boundaries. The initial sequence number SHOULD be random and uniformly distributed across the full space of possible sequence numbers, so that it cannot be guessed by an attacker and so that it and the successive sequence numbers do not repeat other sequences. In the event that more than 2^32 messages are to be generated in a series of KRB_PRIV or KRB_SAFE messages, rekeying SHOULD be performed before sequence numbers are reused with the same encryption key.
为了使序列号能够充分支持重播的检测，它们应该是非重复的，即使跨越连接边界。初始序列号应该是随机的，并且均匀分布在可能序列号的整个空间中，这样攻击者就不会猜到它，并且它和后续序列号不会重复其他序列。如果在一系列KRB_PRIV或KRB_SAFE消息中生成超过2^32条消息，则应在使用相同的加密密钥重新使用序列号之前执行密钥更新。
Implmentation note: Historically, some implementations transmit signed twos-complement numbers for sequence numbers. In the interests of compatibility, implementations MAY accept the equivalent negative number where a positive number greater than 2^31 - 1 is expected.
实现说明：历史上，一些实现传输序列号的有符号二补数。出于兼容性的考虑，在预期正数大于2^31-1的情况下，实现可以接受等效的负数。
Implementation note: As noted before, some implementations omit the optional sequence number when its value would be zero. Implementations MAY accept an omitted sequence number when expecting a value of zero, and SHOULD NOT transmit an Authenticator with a initial sequence number of zero.
实现说明：如前所述，当可选序列号的值为零时，一些实现会忽略该序列号。当期望值为零时，实现可以接受省略的序列号，并且不应传输初始序列号为零的验证器。
authorization-data This field is the same as described for the ticket in Section 5.3. It is optional and will only appear when additional restrictions are to be placed on the use of a ticket, beyond those carried in the ticket itself.
授权数据此字段与第5.3节中描述的票据相同。它是可选的，仅当对票据的使用施加额外限制时才会出现，而不是票据本身所携带的限制。
The KRB_AP_REP message contains the Kerberos protocol version number, the message type, and an encrypted time-stamp. The message is sent in response to an application request (KRB_AP_REQ) for which the mutual authentication option has been selected in the ap-options field.
KRB_AP_REP消息包含Kerberos协议版本号、消息类型和加密的时间戳。发送该消息是为了响应应用程序请求（KRB_AP_REQ），在AP选项字段中为该请求选择了相互认证选项。
AP-REP ::= [APPLICATION 15] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (15),
enc-part [2] EncryptedData -- EncAPRepPart
}
AP-REP ::= [APPLICATION 15] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (15),
enc-part [2] EncryptedData -- EncAPRepPart
}
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
ctime [0] KerberosTime,
cusec [1] Microseconds,
subkey [2] EncryptionKey OPTIONAL,
seq-number [3] UInt32 OPTIONAL
}
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
ctime [0] KerberosTime,
cusec [1] Microseconds,
subkey [2] EncryptionKey OPTIONAL,
seq-number [3] UInt32 OPTIONAL
}
The encoded EncAPRepPart is encrypted in the shared session key of the ticket. The optional subkey field can be used in an application-arranged negotiation to choose a per association session key.
编码部分在票据的共享会话密钥中加密。可选子密钥字段可用于应用程序安排的协商，以选择每个关联会话密钥。
pvno and msg-type These fields are described above in Section 5.4.1. msg-type is KRB_AP_REP.
pvno和msg类型这些字段如上文第5.4.1节所述。消息类型为KRB_AP_REP。
enc-part This field is described above in Section 5.4.2. It is computed with a key usage value of 12.
第5.4.2节中描述了该字段的enc部分。它是使用键使用值12计算的。
ctime This field contains the current time on the client's host.
ctime此字段包含客户端主机上的当前时间。
cusec This field contains the microsecond part of the client's timestamp.
cusec此字段包含客户端时间戳的微秒部分。
subkey This field contains an encryption key that is to be used to protect this specific application session. See Section 3.2.6 for specifics on how this field is used to negotiate a key. Unless an application specifies otherwise, if this field is left out, the sub-session key from the authenticator or if the latter is also left out, the session key from the ticket will be used.
子密钥此字段包含用于保护此特定应用程序会话的加密密钥。有关如何使用此字段协商密钥的详细信息，请参见第3.2.6节。除非应用程序另有规定，否则如果省略此字段，则将使用验证器的子会话密钥，或者如果也省略了验证器的子会话密钥，则将使用票据中的会话密钥。
seq-number This field is described above in Section 5.3.2.
序号该字段如上文第5.3.2节所述。
If an error occurs while processing the application request, the KRB_ERROR message will be sent in response. See Section 5.9.1 for the format of the error message. The cname and crealm fields MAY be left out if the server cannot determine their appropriate values from the corresponding KRB_AP_REQ message. If the authenticator was decipherable, the ctime and cusec fields will contain the values from it.
如果在处理应用程序请求时发生错误，将发送KRB_错误消息作为响应。有关错误消息的格式，请参见第5.9.1节。如果服务器无法从相应的KRB_AP_REQ消息中确定其适当的值，则可以省略cname和crealm字段。如果验证器是可破译的，那么ctime和cusec字段将包含来自它的值。
This section specifies the format of a message that can be used by either side (client or server) of an application to send a tamper-proof message to its peer. It presumes that a session key has previously been exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages).
本节指定应用程序的任意一方（客户端或服务器）可用于向其对等方发送防篡改消息的消息格式。它假定会话密钥先前已交换（例如，通过使用KRB_AP_REQ/KRB_AP_REP消息）。
The KRB_SAFE message contains user data along with a collision-proof checksum keyed with the last encryption key negotiated via subkeys, or with the session key if no negotiation has occurred. The message fields are as follows:
KRB_SAFE消息包含用户数据以及防冲突校验和，校验和使用通过子密钥协商的最后一个加密密钥，或者如果未发生协商，则使用会话密钥。消息字段如下所示：
KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (20),
safe-body [2] KRB-SAFE-BODY,
cksum [3] Checksum
}
KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (20),
safe-body [2] KRB-SAFE-BODY,
cksum [3] Checksum
}
KRB-SAFE-BODY ::= SEQUENCE {
user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL,
seq-number [3] UInt32 OPTIONAL,
s-address [4] HostAddress,
r-address [5] HostAddress OPTIONAL
}
KRB-SAFE-BODY ::= SEQUENCE {
user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL,
seq-number [3] UInt32 OPTIONAL,
s-address [4] HostAddress,
r-address [5] HostAddress OPTIONAL
}
pvno and msg-type These fields are described above in Section 5.4.1. msg-type is KRB_SAFE.
pvno和msg类型这些字段如上文第5.4.1节所述。msg类型是KRB_安全的。
safe-body This field is a placeholder for the body of the KRB-SAFE message.
安全正文此字段是KRB-safe消息正文的占位符。
cksum This field contains the checksum of the application data, computed with a key usage value of 15.
cksum此字段包含应用程序数据的校验和，使用密钥使用值15计算。
The checksum is computed over the encoding of the KRB-SAFE sequence. First, the cksum is set to a type zero, zero-length value, and the checksum is computed over the encoding of the KRB-SAFE sequence. Then the checksum is set to the result of that computation. Finally, the KRB-SAFE sequence is encoded again. This method, although different than the one specified in RFC 1510, corresponds to existing practice.
校验和是在KRB-SAFE序列的编码上计算的。首先，将校验和设置为零类型，零长度值，并在KRB-SAFE序列的编码上计算校验和。然后将校验和设置为该计算的结果。最后，再次对KRB-SAFE序列进行编码。该方法虽然不同于RFC 1510中规定的方法，但符合现有实践。
user-data This field is part of the KRB_SAFE and KRB_PRIV messages, and contains the application-specific data that is being passed from the sender to the recipient.
用户数据此字段是KRB_SAFE和KRB_PRIV消息的一部分，包含从发送方传递给接收方的特定于应用程序的数据。
timestamp This field is part of the KRB_SAFE and KRB_PRIV messages. Its contents are the current time as known by the sender of the message. By checking the timestamp, the recipient of the message is able to make sure that it was recently generated, and is not a replay.
时间戳此字段是KRB_安全和KRB_PRIV消息的一部分。其内容是消息发送者已知的当前时间。通过检查时间戳，消息的接收者能够确保它是最近生成的，而不是重播。
usec This field is part of the KRB_SAFE and KRB_PRIV headers. It contains the microsecond part of the timestamp.
usec此字段是KRB_SAFE和KRB_PRIV头文件的一部分。它包含时间戳的微秒部分。
seq-number This field is described above in Section 5.3.2.
序号该字段如上文第5.3.2节所述。
s-address Sender's address.
s地址发送者的地址。
This field specifies the address in use by the sender of the message.
此字段指定邮件发件人正在使用的地址。
r-address This field specifies the address in use by the recipient of the message. It MAY be omitted for some uses (such as broadcast protocols), but the recipient MAY arbitrarily reject such messages. This field, along with s-address, can be used to help detect messages that have been incorrectly or maliciously delivered to the wrong recipient.
r-address此字段指定邮件收件人正在使用的地址。对于某些用途（例如广播协议），可以省略该消息，但是接收方可以任意拒绝此类消息。此字段以及s地址可用于帮助检测错误或恶意传递给错误收件人的邮件。
This section specifies the format of a message that can be used by either side (client or server) of an application to send a message to its peer securely and privately. It presumes that a session key has previously been exchanged (for example, by using the KRB_AP_REQ/KRB_AP_REP messages).
本节指定消息的格式，应用程序的任何一方（客户端或服务器）都可以使用该格式安全、私密地向其对等方发送消息。它假定会话密钥先前已交换（例如，通过使用KRB_AP_REQ/KRB_AP_REP消息）。
The KRB_PRIV message contains user data encrypted in the Session Key. The message fields are as follows:
KRB_PRIV消息包含在会话密钥中加密的用户数据。消息字段如下所示：
KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (21),
-- NOTE: there is no [2] tag
enc-part [3] EncryptedData -- EncKrbPrivPart
}
KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (21),
-- NOTE: there is no [2] tag
enc-part [3] EncryptedData -- EncKrbPrivPart
}
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL,
seq-number [3] UInt32 OPTIONAL,
s-address [4] HostAddress -- sender's addr --,
r-address [5] HostAddress OPTIONAL -- recip's addr
}
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL,
seq-number [3] UInt32 OPTIONAL,
s-address [4] HostAddress -- sender's addr --,
r-address [5] HostAddress OPTIONAL -- recip's addr
}
pvno and msg-type These fields are described above in Section 5.4.1. msg-type is KRB_PRIV.
pvno和msg类型这些字段如上文第5.4.1节所述。消息类型为KRB_PRIV。
enc-part This field holds an encoding of the EncKrbPrivPart sequence encrypted under the session key, with a key usage value of 13. This encrypted encoding is used for the enc-part field of the KRB-PRIV message.
enc part此字段保存在会话密钥下加密的EncKrbPrivPart序列的编码，密钥使用值为13。此加密编码用于KRB-PRIV消息的enc部分字段。
user-data, timestamp, usec, s-address, and r-address These fields are described above in Section 5.6.1.
用户数据、时间戳、usec、s地址和r地址这些字段在上文第5.6.1节中进行了描述。
seq-number This field is described above in Section 5.3.2.
序号该字段如上文第5.3.2节所述。
This section specifies the format of a message that can be used to send Kerberos credentials from one principal to another. It is presented here to encourage a common mechanism to be used by applications when forwarding tickets or providing proxies to subordinate servers. It presumes that a session key has already been exchanged, perhaps by using the KRB_AP_REQ/KRB_AP_REP messages.
本节指定可用于将Kerberos凭据从一个主体发送到另一个主体的消息格式。本文介绍的目的是鼓励应用程序在向下级服务器转发票证或提供代理时使用通用机制。它假定已经交换了会话密钥，可能是通过使用KRB_AP_REQ/KRB_AP_REP消息。
The KRB_CRED message contains a sequence of tickets to be sent and information needed to use the tickets, including the session key from each. The information needed to use the tickets is encrypted under an encryption key previously exchanged or transferred alongside the KRB_CRED message. The message fields are as follows:
KRB_CRED消息包含要发送的票证序列和使用票证所需的信息，包括来自每个票证的会话密钥。使用票据所需的信息在之前与KRB_CRED消息交换或传输的加密密钥下进行加密。消息字段如下所示：
KRB-CRED ::= [APPLICATION 22] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (22),
tickets [2] SEQUENCE OF Ticket,
enc-part [3] EncryptedData -- EncKrbCredPart
}
KRB-CRED ::= [APPLICATION 22] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (22),
tickets [2] SEQUENCE OF Ticket,
enc-part [3] EncryptedData -- EncKrbCredPart
}
EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
ticket-info [0] SEQUENCE OF KrbCredInfo,
nonce [1] UInt32 OPTIONAL,
timestamp [2] KerberosTime OPTIONAL,
usec [3] Microseconds OPTIONAL,
s-address [4] HostAddress OPTIONAL,
r-address [5] HostAddress OPTIONAL
}
EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
ticket-info [0] SEQUENCE OF KrbCredInfo,
nonce [1] UInt32 OPTIONAL,
timestamp [2] KerberosTime OPTIONAL,
usec [3] Microseconds OPTIONAL,
s-address [4] HostAddress OPTIONAL,
r-address [5] HostAddress OPTIONAL
}
KrbCredInfo ::= SEQUENCE {
key [0] EncryptionKey,
prealm [1] Realm OPTIONAL,
pname [2] PrincipalName OPTIONAL,
flags [3] TicketFlags OPTIONAL,
authtime [4] KerberosTime OPTIONAL,
starttime [5] KerberosTime OPTIONAL,
endtime [6] KerberosTime OPTIONAL,
renew-till [7] KerberosTime OPTIONAL,
srealm [8] Realm OPTIONAL,
sname [9] PrincipalName OPTIONAL,
caddr [10] HostAddresses OPTIONAL
}
KrbCredInfo ::= SEQUENCE {
key [0] EncryptionKey,
prealm [1] Realm OPTIONAL,
pname [2] PrincipalName OPTIONAL,
flags [3] TicketFlags OPTIONAL,
authtime [4] KerberosTime OPTIONAL,
starttime [5] KerberosTime OPTIONAL,
endtime [6] KerberosTime OPTIONAL,
renew-till [7] KerberosTime OPTIONAL,
srealm [8] Realm OPTIONAL,
sname [9] PrincipalName OPTIONAL,
caddr [10] HostAddresses OPTIONAL
}
pvno and msg-type These fields are described above in Section 5.4.1. msg-type is KRB_CRED.
pvno和msg类型这些字段如上文第5.4.1节所述。msg类型为KRB_CRED。
tickets These are the tickets obtained from the KDC specifically for use by the intended recipient. Successive tickets are paired with the corresponding KrbCredInfo sequence from the enc-part of the KRB-CRED message.
票证这些票证是从KDC处获得的，专门供预期接收人使用的票证。连续票据与来自KRB-CRED消息enc部分的相应KrbCredInfo序列配对。
enc-part This field holds an encoding of the EncKrbCredPart sequence encrypted under the session key shared by the sender and the intended recipient, with a key usage value of 14. This encrypted encoding is used for the enc-part field of the KRB-CRED message.
enc part此字段保存根据发送方和预期接收方共享的会话密钥加密的EncKrbCredPart序列的编码，密钥使用值为14。此加密编码用于KRB-CRED消息的enc部分字段。
Implementation note: Implementations of certain applications, most notably certain implementations of the Kerberos GSS-API mechanism, do not separately encrypt the contents of the EncKrbCredPart of the KRB-CRED message when sending it. In the case of those GSS-API mechanisms, this is not a security vulnerability, as the entire KRB-CRED message is itself embedded in an encrypted message.
实现说明：某些应用程序的实现，尤其是Kerberos GSS-API机制的某些实现，在发送KRB-CRED消息时不会单独加密该消息的EncKrbCredPart的内容。对于这些GSS-API机制，这不是一个安全漏洞，因为整个KRB-CRED消息本身嵌入到加密消息中。
nonce If practical, an application MAY require the inclusion of a nonce generated by the recipient of the message. If the same value is included as the nonce in the message, it provides evidence that the message is fresh and has not been replayed by an attacker. A nonce MUST NEVER be reused.
nonce如果可行，应用程序可能需要包含由消息接收方生成的nonce。如果消息中包含与nonce相同的值，则表明该消息是新的且未被攻击者重放。不得重复使用nonce。
timestamp and usec These fields specify the time that the KRB-CRED message was generated. The time is used to provide assurance that the message is fresh.
timestamp和usec这些字段指定生成KRB-CRED消息的时间。时间用于确保消息是新的。
s-address and r-address These fields are described above in Section 5.6.1. They are used optionally to provide additional assurance of the integrity of the KRB-CRED message.
上述第5.6.1节描述了这些字段的s地址和r地址。它们可选地用于提供对KRB-CRED消息完整性的额外保证。
key This field exists in the corresponding ticket passed by the KRB-CRED message and is used to pass the session key from the sender to the intended recipient. The field's encoding is described in Section 5.2.9.
密钥此字段存在于KRB-CRED消息传递的相应票证中，用于将会话密钥从发送方传递给预期的接收方。第5.2.9节描述了字段的编码。
The following fields are optional. If present, they can be associated with the credentials in the remote ticket file. If left out, then it is assumed that the recipient of the credentials already knows their values.
以下字段是可选的。如果存在，它们可以与远程票证文件中的凭据相关联。如果省略，则假定凭据的收件人已经知道其值。
prealm and pname The name and realm of the delegated principal identity.
prealm和pname委托主体标识的名称和域。
flags, authtime, starttime, endtime, renew-till, srealm, sname, and caddr These fields contain the values of the corresponding fields from the ticket found in the ticket field. Descriptions of the fields are identical to the descriptions in the KDC-REP message.
标志、authtime、starttime、endtime、续订至、srealm、sname和caddr这些字段包含在票证字段中找到的票证中相应字段的值。字段的描述与KDC-REP消息中的描述相同。
This section specifies the format for the KRB_ERROR message. The fields included in the message are intended to return as much information as possible about an error. It is not expected that all the information required by the fields will be available for all types of errors. If the appropriate information is not available when the message is composed, the corresponding field will be left out of the message.
本节指定KRB_错误消息的格式。消息中包含的字段旨在返回有关错误的尽可能多的信息。预计字段所需的所有信息不会适用于所有类型的错误。如果在编写消息时没有适当的信息，则消息中将不包含相应的字段。
Note that because the KRB_ERROR message is not integrity protected, it is quite possible for an intruder to synthesize or modify it. In particular, this means that the client SHOULD NOT use any fields in this message for security-critical purposes, such as setting a system clock or generating a fresh authenticator. The message can be useful, however, for advising a user on the reason for some failure.
请注意，由于KRB_错误消息没有完整性保护，入侵者很可能合成或修改它。特别是，这意味着客户端不应将此消息中的任何字段用于安全关键目的，例如设置系统时钟或生成新的验证器。然而，该消息对于向用户建议某些故障的原因是有用的。
The KRB_ERROR message consists of the following fields:
KRB_错误消息由以下字段组成：
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (30),
ctime [2] KerberosTime OPTIONAL,
cusec [3] Microseconds OPTIONAL,
stime [4] KerberosTime,
susec [5] Microseconds,
error-code [6] Int32,
crealm [7] Realm OPTIONAL,
cname [8] PrincipalName OPTIONAL,
realm [9] Realm -- service realm --,
sname [10] PrincipalName -- service name --,
e-text [11] KerberosString OPTIONAL,
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (30),
ctime [2] KerberosTime OPTIONAL,
cusec [3] Microseconds OPTIONAL,
stime [4] KerberosTime,
susec [5] Microseconds,
error-code [6] Int32,
crealm [7] Realm OPTIONAL,
cname [8] PrincipalName OPTIONAL,
realm [9] Realm -- service realm --,
sname [10] PrincipalName -- service name --,
e-text [11] KerberosString OPTIONAL,
e-data [12] OCTET STRING OPTIONAL }
e-data[12]八位字节字符串可选}
pvno and msg-type These fields are described above in Section 5.4.1. msg-type is KRB_ERROR.
pvno和msg类型这些字段如上文第5.4.1节所述。消息类型为KRB_错误。
ctime and cusec These fields are described above in Section 5.5.2. If the values for these fields are known to the entity generating the error (as they would be if the KRB-ERROR is generated in reply to, e.g., a failed authentication service request), they should be populated in the KRB-ERROR. If the values are not available, these fields can be omitted.
ctime和cusec上述字段在第5.5.2节中进行了描述。如果生成错误的实体知道这些字段的值（如果KRB-error是响应失败的身份验证服务请求而生成的，则应该在KRB-error中填充这些字段的值）。如果这些值不可用，则可以忽略这些字段。
stime This field contains the current time on the server. It is of type KerberosTime.
时间此字段包含服务器上的当前时间。它属于KerberosTime类型。
susec This field contains the microsecond part of the server's timestamp. Its value ranges from 0 to 999999. It appears along with stime. The two fields are used in conjunction to specify a reasonably accurate timestamp.
susec此字段包含服务器时间戳的微秒部分。其值范围为0到999999。它与stime一起出现。这两个字段结合使用以指定合理准确的时间戳。
error-code This field contains the error code returned by Kerberos or the server when a request fails. To interpret the value of this field see the list of error codes in Section 7.5.9. Implementations are encouraged to provide for national language support in the display of error messages.
错误代码此字段包含请求失败时Kerberos或服务器返回的错误代码。要解释该字段的值，请参见第7.5.9节中的错误代码列表。鼓励实现在显示错误消息时提供国家语言支持。
crealm, and cname These fields are described above in Section 5.3. When the entity generating the error knows these values, they should be populated in the KRB-ERROR. If the values are not known, the crealm and cname fields SHOULD be omitted.
crealm和cname这些字段在上述第5.3节中进行了描述。当生成错误的实体知道这些值时，应该在KRB-error中填充这些值。如果值未知，则应省略crealm和cname字段。
realm and sname These fields are described above in Section 5.3.
领域和sname这些字段在上文第5.3节中进行了描述。
e-text This field contains additional text to help explain the error code associated with the failed request (for example, it might include a principal name which was unknown).
e-text此字段包含其他文本，以帮助解释与失败请求相关联的错误代码（例如，它可能包括未知的主体名称）。
e-data This field contains additional data about the error for use by the application to help it recover from or handle the error. If the errorcode is KDC_ERR_PREAUTH_REQUIRED, then the e-data field will contain an encoding of a sequence of padata fields, each corresponding to an acceptable pre-authentication method and optionally containing data for the method:
e-data此字段包含有关错误的其他数据，供应用程序使用，以帮助其从错误中恢复或处理错误。如果错误代码为KDC_ERR_PREAUTH_REQUIRED，则电子数据字段将包含padata字段序列的编码，每个padata字段对应于可接受的预认证方法，并且可选地包含该方法的数据：
METHOD-DATA ::= SEQUENCE OF PA-DATA
METHOD-DATA ::= SEQUENCE OF PA-DATA
For error codes defined in this document other than KDC_ERR_PREAUTH_REQUIRED, the format and contents of the e-data field are implementation-defined. Similarly, for future error codes, the format and contents of the e-data field are implementation-defined unless specified otherwise. Whether defined by the implementation or in a future document, the e-data field MAY take the form of TYPED-DATA:
对于本文档中定义的错误代码（KDC_ERR_PREAUTH_除外），电子数据字段的格式和内容由实现定义。同样，对于未来的错误代码，除非另有规定，否则电子数据字段的格式和内容由实现定义。无论是由实施还是在未来的文档中定义，电子数据字段都可以采用类型化数据的形式：
TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
data-type [0] Int32,
data-value [1] OCTET STRING OPTIONAL
}
TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
data-type [0] Int32,
data-value [1] OCTET STRING OPTIONAL
}
The following table lists the application class tag numbers used by various data types defined in this section.
下表列出了本节中定义的各种数据类型使用的应用程序类标记号。
Tag Number(s) Type Name Comments
位号类型名称注释
0 unused
0未使用
1 Ticket PDU
1票PDU
2 Authenticator non-PDU
2认证器非PDU
3 EncTicketPart non-PDU
3附件部分非PDU
4-9 unused
4-9未使用
10 AS-REQ PDU
10 AS-REQ PDU
11 AS-REP PDU
11 AS-REP PDU
12 TGS-REQ PDU
12 TGS-REQ PDU
13 TGS-REP PDU
13 TGS-REP PDU
14 AP-REQ PDU
14 AP-REQ PDU
15 AP-REP PDU
15 AP-REP PDU
16 RESERVED16 TGT-REQ (for user-to-user)
16预留16 TGT-REQ（用户对用户）
17 RESERVED17 TGT-REP (for user-to-user)
17预留17 TGT-REP（用户对用户）
18-19 unused
18-19未使用
20 KRB-SAFE PDU
20 KRB-SAFE PDU
21 KRB-PRIV PDU
21 KRB-PRV PDU
22 KRB-CRED PDU
22 KRB-CRED PDU
23-24 unused
23-24未使用
25 EncASRepPart non-PDU
25包装件非PDU
26 EncTGSRepPart non-PDU
26 Enctgsrepart非PDU
27 EncApRepPart non-PDU
27部分非PDU
28 EncKrbPrivPart non-PDU
28 EncKrbPrivPart非PDU
29 EncKrbCredPart non-PDU
29 EncKrbCredPart非PDU
30 KRB-ERROR PDU
30 KRB错误PDU
The ASN.1 types marked above as "PDU" (Protocol Data Unit) are the only ASN.1 types intended as top-level types of the Kerberos protocol, and are the only types that may be used as elements in another protocol that makes use of Kerberos.
上面标记为“PDU”（协议数据单元）的ASN.1类型是唯一打算作为Kerberos协议顶级类型的ASN.1类型，并且是唯一可以在使用Kerberos的另一个协议中用作元素的类型。
Although realm names are encoded as GeneralStrings and technically a realm can select any name it chooses, interoperability across realm boundaries requires agreement on how realm names are to be assigned, and what information they imply.
尽管领域名称编码为GeneralString，从技术上讲，一个领域可以选择它选择的任何名称，但跨领域边界的互操作性需要就如何分配领域名称以及它们意味着什么信息达成一致。
To enforce these conventions, each realm MUST conform to the conventions itself, and it MUST require that any realms with which inter-realm keys are shared also conform to the conventions and require the same from its neighbors.
为了实施这些约定，每个领域本身必须符合约定，并且必须要求与之共享领域间密钥的任何领域也符合约定，并要求其邻居遵守相同的约定。
Kerberos realm names are case sensitive. Realm names that differ only in the case of the characters are not equivalent. There are presently three styles of realm names: domain, X500, and other. Examples of each style follow:
Kerberos域名区分大小写。仅在字符大小写上不同的域名是不等价的。目前有三种类型的域名：domain、X500和other。每种样式的示例如下：
domain: ATHENA.MIT.EDU
X500: C=US/O=OSF
other: NAMETYPE:rest/of.name=without-restrictions
domain: ATHENA.MIT.EDU
X500: C=US/O=OSF
other: NAMETYPE:rest/of.name=without-restrictions
Domain style realm names MUST look like domain names: they consist of components separated by periods (.) and they contain neither colons (:) nor slashes (/). Though domain names themselves are case insensitive, in order for realms to match, the case must match as well. When establishing a new realm name based on an internet domain name it is recommended by convention that the characters be converted to uppercase.
域名样式的域名必须看起来像域名：它们由句点（.）分隔的组件组成，既不包含冒号（：）也不包含斜杠（/）。虽然域名本身是不区分大小写的，但为了让域名匹配，大小写也必须匹配。在基于internet域名建立新域名时，按照惯例建议将字符转换为大写。
X.500 names contain an equals sign (=) and cannot contain a colon (:) before the equals sign. The realm names for X.500 names will be string representations of the names with components separated by slashes. Leading and trailing slashes will not be included. Note that the slash separator is consistent with Kerberos implementations based on RFC 1510, but it is different from the separator recommended in RFC 2253.
X.500名称包含等号（=），并且在等号之前不能包含冒号（：）。X.500名称的领域名称将是名称的字符串表示形式，其中的组件由斜杠分隔。不包括前导斜杠和尾随斜杠。请注意，斜杠分隔符与基于RFC 1510的Kerberos实现一致，但与RFC 2253中建议的分隔符不同。
Names that fall into the other category MUST begin with a prefix that contains no equals sign (=) or period (.), and the prefix MUST be followed by a colon (:) and the rest of the name. All prefixes expect those beginning with used. Presently none are assigned.
属于其他类别的名称必须以不包含等号（=）或句点（.）的前缀开头，前缀后面必须跟一个冒号（：）和名称的其余部分。所有前缀都应以used开头。目前没有分配。
The reserved category includes strings that do not fall into the first three categories. All names in this category are reserved. It is unlikely that names will be assigned to this category unless there is a very strong argument for not using the 'other' category.
保留类别包括不属于前三个类别的字符串。此类别中的所有名称均保留。除非有非常有力的理由不使用“其他”类别，否则不太可能将名称指定给该类别。
These rules guarantee that there will be no conflicts between the various name styles. The following additional constraints apply to the assignment of realm names in the domain and X.500 categories: either the name of a realm for the domain or X.500 formats must be used by the organization owning (to whom it was assigned) an Internet domain name or X.500 name, or, in the case that no such names are registered, authority to use a realm name MAY be derived from the authority of the parent realm. For example, if there is no domain name for E40.MIT.EDU, then the administrator of the MIT.EDU realm can authorize the creation of a realm with that name.
这些规则保证各种名称样式之间不会有冲突。以下附加约束适用于域和X.500类别中的域名分配：域的域名或X.500格式必须由拥有（分配给它的）Internet域名或X.500名称的组织使用，或者，如果没有注册此类名称，使用领域名称的权限可能来自父领域的权限。例如，如果E40.MIT.EDU没有域名，那么MIT.EDU领域的管理员可以授权创建具有该名称的领域。
This is acceptable because the organization to which the parent is assigned is presumably the organization authorized to assign names to
这是可以接受的，因为向其分配父级的组织可能是有权向其分配名称的组织
its children in the X.500 and domain name systems as well. If the parent assigns a realm name without also registering it in the domain name or X.500 hierarchy, it is the parent's responsibility to make sure that in the future there will not exist a name identical to the realm name of the child unless it is assigned to the same entity as the realm name.
它的孩子也在X.500和域名系统中。如果父级分配了一个域名，但未在域名或X.500层次结构中注册，则父级有责任确保将来不会存在与子级域名相同的名称，除非将其分配给与域名相同的实体。
As was the case for realm names, conventions are needed to ensure that all agree on what information is implied by a principal name. The name-type field that is part of the principal name indicates the kind of information implied by the name. The name-type SHOULD be treated only as a hint to interpreting the meaning of a name. It is not significant when checking for equivalence. Principal names that differ only in the name-type identify the same principal. The name type does not partition the name space. Ignoring the name type, no two names can be the same (i.e., at least one of the components, or the realm, MUST be different). The following name types are defined:
与域名一样，需要约定以确保所有人都同意主体名称所隐含的信息。作为主体名称一部分的名称类型字段指示名称隐含的信息类型。名称类型应仅作为解释名称含义的提示。在检查等价性时，这并不重要。仅在名称类型上不同的主体名称标识相同的主体。名称类型不划分名称空间。忽略名称类型，任何两个名称都不能相同（即，至少一个组件或领域必须不同）。定义了以下名称类型：
Name Type Value Meaning
名称类型值含义
NT-UNKNOWN 0 Name type not known NT-PRINCIPAL 1 Just the name of the principal as in DCE, or for users NT-SRV-INST 2 Service and other unique instance (krbtgt) NT-SRV-HST 3 Service with host name as instance (telnet, rcommands) NT-SRV-XHST 4 Service with host as remaining components NT-UID 5 Unique ID NT-X500-PRINCIPAL 6 Encoded X.509 Distinguished name [RFC2253] NT-SMTP-NAME 7 Name in form of SMTP email name (e.g., user@example.com) NT-ENTERPRISE 10 Enterprise name - may be mapped to principal name
NT-UNKNOWN 0 Name type not known NT-PRINCIPAL 1仅为DCE中的主体名称，或对于用户NT-SRV-INST 2服务和其他唯一实例（krbtgt）NT-SRV-HST 3服务，主机名为实例（telnet、rcommands）主机作为剩余组件的NT-SRV-XHST 4服务NT-UID 5唯一ID NT-X500-PRINCIPAL 6编码的X.509可分辨名称[RFC2253]NT-SMTP-name 7 SMTP电子邮件名称形式的名称（例如。，user@example.com)NT-ENTERPRISE 10企业名称-可以映射到主体名称
When a name implies no information other than its uniqueness at a particular time, the name type PRINCIPAL SHOULD be used. The principal name type SHOULD be used for users, and it might also be used for a unique server. If the name is a unique machine-generated ID that is guaranteed never to be reassigned, then the name type of UID SHOULD be used. (Note that it is generally a bad idea to reassign names of any type since stale entries might remain in access control lists.)
当名称在特定时间不表示除唯一性以外的任何信息时，应使用名称类型主体。主体名称类型应该用于用户，也可以用于唯一的服务器。如果名称是保证永远不会重新分配的唯一计算机生成的ID，则应使用UID的名称类型。（请注意，重新分配任何类型的名称通常都不是一个好主意，因为过时的条目可能会保留在访问控制列表中。）
If the first component of a name identifies a service and the remaining components identify an instance of the service in a server-specified manner, then the name type of SRV-INST SHOULD be
如果名称的第一个组件标识服务，其余组件以服务器指定的方式标识服务实例，则SRV-INST的名称类型应为
used. An example of this name type is the Kerberos ticket-granting service whose name has a first component of krbtgt and a second component identifying the realm for which the ticket is valid.
习惯于此名称类型的一个示例是Kerberos票证授予服务，其名称的第一个组件为krbtgt，第二个组件标识票证有效的领域。
If the first component of a name identifies a service and there is a single component following the service name identifying the instance as the host on which the server is running, then the name type SRV-HST SHOULD be used. This type is typically used for Internet services such as telnet and the Berkeley R commands. If the separate components of the host name appear as successive components following the name of the service, then the name type SRV-XHST SHOULD be used. This type might be used to identify servers on hosts with X.500 names, where the slash (/) might otherwise be ambiguous.
如果名称的第一个组件标识服务，并且在服务名称后面有一个组件标识实例作为服务器运行的主机，则应使用名称类型SRV-HST。这种类型通常用于Internet服务，如telnet和Berkeley R命令。如果主机名的单独组件显示为服务名称后面的连续组件，则应使用名称类型SRV-XHST。此类型可用于标识具有X.500名称的主机上的服务器，否则斜杠（/）可能不明确。
A name type of NT-X500-PRINCIPAL SHOULD be used when a name from an X.509 certificate is translated into a Kerberos name. The encoding of the X.509 name as a Kerberos principal shall conform to the encoding rules specified in RFC 2253.
当将X.509证书中的名称转换为Kerberos名称时，应使用NT-X500-PRINCIPAL的名称类型。X.509名称作为Kerberos主体的编码应符合RFC 2253中规定的编码规则。
A name type of SMTP allows a name to be of a form that resembles an SMTP email name. This name, including an "@" and a domain name, is used as the one component of the principal name.
SMTP的名称类型允许名称的形式类似于SMTP电子邮件名称。此名称（包括“@”和域名）用作主体名称的一个组成部分。
A name type of UNKNOWN SHOULD be used when the form of the name is not known. When comparing names, a name of type UNKNOWN will match principals authenticated with names of any type. A principal authenticated with a name of type UNKNOWN, however, will only match other names of type UNKNOWN.
当名称的形式未知时，应使用未知的名称类型。比较名称时，未知类型的名称将与任何类型的名称进行身份验证的主体相匹配。但是，使用未知类型名称进行身份验证的主体将仅与未知类型的其他名称匹配。
Names of any type with an initial component of 'krbtgt' are reserved for the Kerberos ticket-granting service. See Section 7.3 for the form of such names.
初始组件为“krbtgt”的任何类型的名称都保留给Kerberos票证授予服务。此类名称的形式见第7.3节。
The principal identifier for a server on a host will generally be composed of two parts: (1) the realm of the KDC with which the server is registered, and (2) a two-component name of type NT-SRV-HST, if the host name is an Internet domain name, or a multi-component name of type NT-SRV-XHST, if the name of the host is of a form (such as X.500) that allows slash (/) separators. The first component of the two- or multi-component name will identify the service, and the latter components will identify the host. Where the name of the host is not case sensitive (for example, with Internet domain names) the name of the host MUST be lowercase. If specified by the application protocol for services such as telnet and the Berkeley R commands that run with system privileges, the first component MAY be the string 'host' instead of a service-specific identifier.
主机上服务器的主要标识符通常由两部分组成：（1）服务器注册的KDC领域；（2）如果主机名为Internet域名，则为NT-SRV-HST类型的两个组件名；如果主机名为某种形式（如X.500），则为NT-SRV-XHST类型的多组件名这允许使用斜杠（/）分隔符。双组件或多组件名称的第一个组件将标识服务，后一个组件将标识主机。如果主机名不区分大小写（例如，对于Internet域名），则主机名必须为小写。如果由应用程序协议为使用系统权限运行的服务（如telnet和Berkeley R命令）指定，则第一个组件可能是字符串“主机”，而不是特定于服务的标识符。
All negative values for the host address type are reserved for local use. All non-negative values are reserved for officially assigned type fields and interpretations.
主机地址类型的所有负值保留供本地使用。所有非负值保留用于正式指定的类型字段和解释。
Internet (IPv4) Addresses
互联网（IPv4）地址
Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in MSB order (most significant byte first). The IPv4 loopback address SHOULD NOT appear in a Kerberos PDU. The type of IPv4 addresses is two (2).
Internet（IPv4）地址是32位（4位八位组）数量，按MSB顺序编码（最高有效字节优先）。IPv4环回地址不应出现在Kerberos PDU中。IPv4地址的类型为两（2）。
Internet (IPv6) Addresses
互联网（IPv6）地址
IPv6 addresses [RFC3513] are 128-bit (16-octet) quantities, encoded in MSB order (most significant byte first). The type of IPv6 addresses is twenty-four (24). The following addresses MUST NOT appear in any Kerberos PDU:
IPv6地址[RFC3513]是128位（16个八位字节）的数量，按MSB顺序编码（最高有效字节优先）。IPv6地址的类型为二十四（24）。以下地址不得出现在任何Kerberos PDU中：
* the Unspecified Address * the Loopback Address * Link-Local addresses
* 未指定的地址*环回地址*链路本地地址
This restriction applies to the inclusion in the address fields of Kerberos PDUs, but not to the address fields of packets that might carry such PDUs. The restriction is necessary because the use of an address with non-global scope could allow the acceptance of a message sent from a node that may have the same address, but which is not the host intended by the entity that added the restriction. If the link-local address type needs to be used for communication, then the address restriction in tickets must not be used (i.e., addressless tickets must be used).
此限制适用于包含在Kerberos PDU的地址字段中，但不适用于可能携带此类PDU的数据包的地址字段。该限制是必要的，因为使用具有非全局作用域的地址可能允许接受从可能具有相同地址但不是添加该限制的实体所期望的主机的节点发送的消息。如果链路本地地址类型需要用于通信，则不得使用票据中的地址限制（即，必须使用无地址票据）。
IPv4-mapped IPv6 addresses MUST be represented as addresses of type 2.
IPv4映射的IPv6地址必须表示为类型2的地址。
DECnet Phase IV Addresses
DECnet第四阶段地址
DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. The type of DECnet Phase IV addresses is twelve (12).
DECnet第四阶段地址是16位地址，按LSB顺序编码。DECnet第四阶段地址的类型为十二（12）。
Netbios Addresses
Netbios地址
Netbios addresses are 16-octet addresses typically composed of 1 to 15 alphanumeric characters and padded with the US-ASCII SPC character (code 32). The 16th octet MUST be the US-ASCII NUL character (code 0). The type of Netbios addresses is twenty (20).
Netbios地址是16个八位字节地址，通常由1到15个字母数字字符组成，并用US-ASCII SPC字符（代码32）填充。第16个八位字节必须是US-ASCII NUL字符（代码0）。Netbios地址的类型为二十（20）。
Directional Addresses
定向地址
Including the sender address in KRB_SAFE and KRB_PRIV messages is undesirable in many environments because the addresses may be changed in transport by network address translators. However, if these addresses are removed, the messages may be subject to a reflection attack in which a message is reflected back to its originator. The directional address type provides a way to avoid transport addresses and reflection attacks. Directional addresses are encoded as four-byte unsigned integers in network byte order. If the message is originated by the party sending the original KRB_AP_REQ message, then an address of 0 SHOULD be used. If the message is originated by the party to whom that KRB_AP_REQ was sent, then the address 1 SHOULD be used. Applications involving multiple parties can specify the use of other addresses.
在许多环境中，在KRB_-SAFE和KRB_-PRIV消息中包含发送方地址是不可取的，因为网络地址转换器可能会在传输过程中更改地址。但是，如果删除这些地址，则消息可能会受到反射攻击，其中消息会反射回其原始发件人。定向地址类型提供了一种避免传输地址和反射攻击的方法。定向地址按网络字节顺序编码为四字节无符号整数。如果消息由发送原始KRB_AP_REQ消息的一方发起，则应使用地址0。如果消息由发送KRB_AP_请求的一方发起，则应使用地址1。涉及多方的应用程序可以指定其他地址的使用。
Directional addresses MUST only be used for the sender address field in the KRB_SAFE or KRB_PRIV messages. They MUST NOT be used as a ticket address or in a KRB_AP_REQ message. This address type SHOULD only be used in situations where the sending party knows that the receiving party supports the address type. This generally means that directional addresses may only be used when the application protocol requires their support. Directional addresses are type (3).
定向地址只能用于KRB_SAFE或KRB_PRIV消息中的发件人地址字段。它们不得用作票证地址或KRB_AP_REQ消息。此地址类型只能在发送方知道接收方支持该地址类型的情况下使用。这通常意味着只有在应用协议需要支持时才可以使用定向地址。定向地址类型为（3）。
Kerberos defines two IP transport mechanisms for communication between clients and servers: UDP/IP and TCP/IP.
Kerberos为客户端和服务器之间的通信定义了两种IP传输机制：UDP/IP和TCP/IP。
Kerberos servers (KDCs) supporting IP transports MUST accept UDP requests and SHOULD listen for them on port 88 (decimal) unless specifically configured to listen on an alternative UDP port. Alternate ports MAY be used when running multiple KDCs for multiple realms on the same host.
支持IP传输的Kerberos服务器（KDC）必须接受UDP请求，并应在端口88（十进制）上侦听这些请求，除非专门配置为在备用UDP端口上侦听。在同一主机上为多个领域运行多个KDC时，可以使用备用端口。
Kerberos clients supporting IP transports SHOULD support the sending of UDP requests. Clients SHOULD use KDC discovery [7.2.3] to identify the IP address and port to which they will send their request.
支持IP传输的Kerberos客户端应支持UDP请求的发送。客户机应使用KDC发现[7.2.3]来标识他们将向其发送请求的IP地址和端口。
When contacting a KDC for a KRB_KDC_REQ request using UDP/IP transport, the client shall send a UDP datagram containing only an encoding of the request to the KDC. The KDC will respond with a reply datagram containing only an encoding of the reply message (either a KRB_ERROR or a KRB_KDC_REP) to the sending port at the sender's IP address. The response to a request made through UDP/IP transport MUST also use UDP/IP transport. If the response cannot be handled using UDP (for example, because it is too large), the KDC MUST return KRB_ERR_RESPONSE_TOO_BIG, forcing the client to retry the request using the TCP transport.
当使用UDP/IP传输联系KDC请求KRB_KDC_REQ时，客户端应向KDC发送仅包含请求编码的UDP数据报。KDC将使用只包含回复消息编码（KRB_错误或KRB_KDC_代表）的回复数据报对发送方IP地址的发送端口进行响应。对通过UDP/IP传输发出的请求的响应也必须使用UDP/IP传输。如果无法使用UDP处理响应（例如，因为响应太大），KDC必须返回KRB_ERR_response_too_BIG，迫使客户端使用TCP传输重试请求。
Kerberos servers (KDCs) supporting IP transports MUST accept TCP requests and SHOULD listen for them on port 88 (decimal) unless specifically configured to listen on an alternate TCP port. Alternate ports MAY be used when running multiple KDCs for multiple realms on the same host.
支持IP传输的Kerberos服务器（KDC）必须接受TCP请求，并应在端口88（十进制）上侦听这些请求，除非专门配置为在备用TCP端口上侦听。在同一主机上为多个领域运行多个KDC时，可以使用备用端口。
Clients MUST support the sending of TCP requests, but MAY choose to try a request initially using the UDP transport. Clients SHOULD use KDC discovery [7.2.3] to identify the IP address and port to which they will send their request.
客户端必须支持TCP请求的发送，但可以选择最初使用UDP传输尝试请求。客户机应使用KDC发现[7.2.3]来标识他们将向其发送请求的IP地址和端口。
Implementation note: Some extensions to the Kerberos protocol will not succeed if any client or KDC not supporting the TCP transport is involved. Implementations of RFC 1510 were not required to support TCP/IP transports.
实现说明：如果涉及任何不支持TCP传输的客户端或KDC，Kerberos协议的某些扩展将不会成功。RFC 1510的实现不需要支持TCP/IP传输。
When the KRB_KDC_REQ message is sent to the KDC over a TCP stream, the response (KRB_KDC_REP or KRB_ERROR message) MUST be returned to the client on the same TCP stream that was established for the request. The KDC MAY close the TCP stream after sending a response, but MAY leave the stream open for a reasonable period of time if it expects a follow-up. Care must be taken in managing TCP/IP connections on the KDC to prevent denial of service attacks based on the number of open TCP/IP connections.
当KRB_KDC_REQ消息通过TCP流发送到KDC时，响应（KRB_KDC_REP或KRB_错误消息）必须在为请求建立的相同TCP流上返回给客户端。KDC可以在发送响应后关闭TCP流，但是如果它期望后续操作，则可以在一段合理的时间内保持该流打开。在管理KDC上的TCP/IP连接时必须小心，以防止基于打开的TCP/IP连接数的拒绝服务攻击。
The client MUST be prepared to have the stream closed by the KDC at any time after the receipt of a response. A stream closure SHOULD NOT be treated as a fatal error. Instead, if multiple exchanges are required (e.g., certain forms of pre-authentication), the client may need to establish a new connection when it is ready to send
客户机必须准备好让KDC在收到响应后的任何时候关闭流。流关闭不应被视为致命错误。相反，如果需要多个交换（例如，某些形式的预认证），客户端可能需要在准备发送时建立新连接
subsequent messages. A client MAY close the stream after receiving a response, and SHOULD close the stream if it does not expect to send follow-up messages.
后续消息。客户端可以在收到响应后关闭流，如果不希望发送后续消息，则应关闭流。
A client MAY send multiple requests before receiving responses, though it must be prepared to handle the connection being closed after the first response.
客户机在收到响应之前可能会发送多个请求，但它必须准备好处理第一个响应之后关闭的连接。
Each request (KRB_KDC_REQ) and response (KRB_KDC_REP or KRB_ERROR) sent over the TCP stream is preceded by the length of the request as 4 octets in network byte order. The high bit of the length is reserved for future expansion and MUST currently be set to zero. If a KDC that does not understand how to interpret a set high bit of the length encoding receives a request with the high order bit of the length set, it MUST return a KRB-ERROR message with the error KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream.
通过TCP流发送的每个请求（KRB_KDC_REQ）和响应（KRB_KDC_REP或KRB_ERROR）前面都有请求的长度，按网络字节顺序为4个八位字节。长度的高位保留用于将来扩展，当前必须设置为零。如果不了解如何解释长度编码的高位集的KDC接收到具有长度集高位的请求，则它必须返回带有错误KRB_ERR_FIELD_TOOLONG的KRB-ERROR消息，并且必须关闭TCP流。
If multiple requests are sent over a single TCP connection and the KDC sends multiple responses, the KDC is not required to send the responses in the order of the corresponding requests. This may permit some implementations to send each response as soon as it is ready, even if earlier requests are still being processed (for example, waiting for a response from an external device or database).
如果通过单个TCP连接发送多个请求，并且KDC发送多个响应，则KDC不需要按照相应请求的顺序发送响应。这可能允许一些实现在每个响应就绪后立即发送，即使之前的请求仍在处理中（例如，等待来自外部设备或数据库的响应）。
Kerberos client implementations MUST provide a means for the client to determine the location of the Kerberos Key Distribution Centers (KDCs). Traditionally, Kerberos implementations have stored such configuration information in a file on each client machine. Experience has shown that this method of storing configuration information presents problems with out-of-date information and scaling, especially when using cross-realm authentication. This section describes a method for using the Domain Name System [RFC1035] for storing KDC location information.
Kerberos客户端实现必须为客户端提供确定Kerberos密钥分发中心（KDC）位置的方法。传统上，Kerberos实现将这些配置信息存储在每台客户机上的一个文件中。经验表明，这种存储配置信息的方法存在过时信息和扩展问题，特别是在使用跨领域身份验证时。本节介绍使用域名系统[RFC1035]存储KDC位置信息的方法。
In Kerberos, realm names are case sensitive. Although it is strongly encouraged that all realm names be all uppercase, this recommendation has not been adopted by all sites. Some sites use all lowercase names and other use mixed case. DNS, on the other hand, is case insensitive for queries. Because the realm names "MYREALM", "myrealm", and "MyRealm" are all different, but resolve the same in the domain name system, it is necessary that only one of the possible combinations of upper- and lowercase characters be used in realm names.
在Kerberos中，域名区分大小写。尽管强烈建议所有域名都使用大写，但这一建议并没有被所有网站采纳。有些站点使用全小写名称，而其他站点则使用大小写混合的名称。另一方面，DNS对查询不区分大小写。由于域名“MYREALM”、“MYREALM”和“MYREALM”都不同，但在域名系统中解析相同，因此有必要在域名中仅使用一种可能的大小写字符组合。
KDC location information is to be stored using the DNS SRV RR [RFC2782]. The format of this RR is as follows:
KDC位置信息将使用DNS SRV RR[RFC2782]存储。本RR的格式如下所示：
_Service._Proto.Realm TTL Class SRV Priority Weight Port Target
_服务._Proto.Realm TTL类SRV优先级权重端口目标
The Service name for Kerberos is always "kerberos".
Kerberos的服务名称始终为“Kerberos”。
The Proto can be either "udp" or "tcp". If these SRV records are to be used, both "udp" and "tcp" records MUST be specified for all KDC deployments.
协议可以是“udp”或“tcp”。如果要使用这些SRV记录，则必须为所有KDC部署指定“udp”和“tcp”记录。
The Realm is the Kerberos realm that this record corresponds to. The realm MUST be a domain-style realm name.
领域是此记录对应的Kerberos领域。领域必须是域样式的领域名称。
TTL, Class, SRV, Priority, Weight, and Target have the standard meaning as defined in RFC 2782.
TTL、等级、SRV、优先级、重量和目标具有RFC 2782中定义的标准含义。
As per RFC 2782, the Port number used for "_udp" and "_tcp" SRV records SHOULD be the value assigned to "kerberos" by the Internet Assigned Number Authority: 88 (decimal), unless the KDC is configured to listen on an alternate TCP port.
根据RFC 2782，用于“_udp”和“_tcp”SRV记录的端口号应为Internet分配号码授权机构分配给“kerberos”的值：88（十进制），除非KDC配置为在备用tcp端口上侦听。
Implementation note: Many existing client implementations do not support KDC Discovery and are configured to send requests to the IANA assigned port (88 decimal), so it is strongly recommended that KDCs be configured to listen on that port.
实现说明：许多现有的客户端实现不支持KDC发现，并且配置为向IANA分配的端口（88十进制）发送请求，因此强烈建议将KDC配置为在该端口上侦听。
These are DNS records for a Kerberos realm EXAMPLE.COM. It has two Kerberos servers, kdc1.example.com and kdc2.example.com. Queries should be directed to kdc1.example.com first as per the specified priority. Weights are not used in these sample records.
这些是Kerberos realm EXAMPLE.COM的DNS记录。它有两个Kerberos服务器，kdc1.example.com和kdc2.example.com。根据指定的优先级，应首先将查询定向到kdc1.example.com。这些样本记录中未使用权重。
_kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
_kerberos._udp.EXAMPLE.COM。在SRV 0 88 kdc1.example.com中_kerberos._udp.EXAMPLE.COM。在SRV 1 0 88 kdc2.example.com中_kerberos._tcp.EXAMPLE.COM。在SRV 0 88 kdc1.example.com中_kerberos._tcp.EXAMPLE.COM。在SRV 1 0 88 kdc2.example.com中。
The principal identifier of the ticket-granting service shall be composed of three parts: the realm of the KDC issuing the TGS ticket, and a two-part name of type NT-SRV-INST, with the first part "krbtgt" and the second part the name of the realm that will accept the TGT. For example, a TGT issued by the ATHENA.MIT.EDU realm to be used to
票证授予服务的主要标识符应由三部分组成：签发TGS票证的KDC领域，以及由两部分组成的NT-SRV-INST类型名称，第一部分为“krbtgt”，第二部分为接受TGT的领域名称。例如，ATHENA.MIT.EDU领域发布的TGT用于
get tickets from the ATHENA.MIT.EDU KDC has a principal identifier of "ATHENA.MIT.EDU" (realm), ("krbtgt", "ATHENA.MIT.EDU") (name). A TGT issued by the ATHENA.MIT.EDU realm to be used to get tickets from the MIT.EDU realm has a principal identifier of "ATHENA.MIT.EDU" (realm), ("krbtgt", "MIT.EDU") (name).
从ATHENA.MIT.EDU获取票证KDC的主要标识符为“ATHENA.MIT.EDU”（领域）（“krbtgt”，“ATHENA.MIT.EDU”）（名称）。ATHENA.MIT.EDU领域发行的TGT用于从MIT.EDU领域获取票证，其主要标识符为“ATHENA.MIT.EDU”（领域）（“krbtgt”，“MIT.EDU”）（名称）。
This OID MAY be used to identify Kerberos protocol messages encapsulated in other protocols. It also designates the OID arc for KerberosV5-related OIDs assigned by future IETF action. Implementation note: RFC 1510 had an incorrect value (5) for "dod" in its OID.
此OID可用于标识封装在其他协议中的Kerberos协议消息。它还为未来IETF行动分配的KerberosV5相关OID指定OID弧。实施说明：RFC 1510在其OID中的“dod”值（5）不正确。
id-krb5 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2)
}
id-krb5 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2)
}
Assignment of OIDs beneath the id-krb5 arc must be obtained by contacting the registrar for the id-krb5 arc, or its designee. At the time of the issuance of this RFC, such registrations can be obtained by contacting krb5-oid-registrar@mit.edu.
id-krb5弧下OID的分配必须通过联系id-krb5弧的注册人或其指定人员获得。在发布本RFC时，可通过联系krb5 oid获得此类注册-registrar@mit.edu.
The following tables list constants used in the protocol and define their meanings. In the "specification" section, ranges are specified that limit the values of constants for which values are defined here. This allows implementations to make assumptions about the maximum values that will be received for these constants. Implementations receiving values outside the range specified in the "specification" section MAY reject the request, but they MUST recover cleanly.
下表列出了协议中使用的常数并定义了它们的含义。在“规范”部分中，指定了限制此处定义值的常数值的范围。这允许实现对这些常量将接收到的最大值进行假设。接收超出“规范”部分中指定范围的值的实现可能会拒绝请求，但它们必须干净地恢复。
The encryption and checksum specifications in [RFC3961] require as input a "key usage number", to alter the encryption key used in any specific message in order to make certain types of cryptographic attack more difficult. These are the key usage values assigned in this document:
[RFC3961]中的加密和校验和规范要求输入“密钥使用编号”，以改变任何特定消息中使用的加密密钥，从而使某些类型的加密攻击更加困难。以下是本文档中分配的关键使用值：
1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the client key (Section 5.2.7.2)
1. AS-REQ PA-ENC-TIMESTAMP padata TIMESTAMP，使用客户端密钥加密（第5.2.7.2节）
2. AS-REP Ticket and TGS-REP Ticket (includes TGS session key or application session key), encrypted with the service key (Section 5.3) 3. AS-REP encrypted part (includes TGS session key or application session key), encrypted with the client key (Section 5.4.2) 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the TGS session key (Section 5.4.1) 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the TGS authenticator subkey (Section 5.4.1) 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed with the TGS session key (Section 5.5.1) 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes TGS authenticator subkey), encrypted with the TGS session key (Section 5.5.1) 8. TGS-REP encrypted part (includes application session key), encrypted with the TGS session key (Section 5.4.2) 9. TGS-REP encrypted part (includes application session key), encrypted with the TGS authenticator subkey (Section 5.4.2) 10. AP-REQ Authenticator cksum, keyed with the application session key (Section 5.5.1) 11. AP-REQ Authenticator (includes application authenticator subkey), encrypted with the application session key (Section 5.5.1) 12. AP-REP encrypted part (includes application session subkey), encrypted with the application session key (Section 5.5.2) 13. KRB-PRIV encrypted part, encrypted with a key chosen by the application (Section 5.7.1) 14. KRB-CRED encrypted part, encrypted with a key chosen by the application (Section 5.8.1) 15. KRB-SAFE cksum, keyed with a key chosen by the application (Section 5.6.1) 16-18. Reserved for future use in Kerberos and related protocols. 19. AD-KDC-ISSUED checksum (ad-checksum in 5.2.6.4) 20-21. Reserved for future use in Kerberos and related protocols. 22-25. Reserved for use in the Kerberos Version 5 GSS-API mechanisms [RFC4121]. 26-511. Reserved for future use in Kerberos and related protocols. 512-1023. Reserved for uses internal to a Kerberos implementation. 1024. Encryption for application use in protocols that do not specify key usage values
2.AS-REP票证和TGS-REP票证（包括TGS会话密钥或应用程序会话密钥），使用服务密钥加密（第5.3节）3。AS-REP加密部分（包括TGS会话密钥或应用程序会话密钥），使用客户端密钥加密（第5.4.2节）4。TGS-REQ KDC-REQ-BODY授权数据，使用TGS会话密钥加密（第5.4.1节）5。TGS-REQ KDC-REQ-BODY授权数据，使用TGS验证器子密钥加密（第5.4.1节）6。TGS-REQ PA-TGS-REQ padata AP-REQ验证器cksum，用TGS会话密钥键入（第5.5.1节）7。TGS-REQ PA-TGS-REQ padata AP-REQ验证器（包括TGS验证器子密钥），使用TGS会话密钥加密（第5.5.1节）8。TGS-REP加密部分（包括应用程序会话密钥），使用TGS会话密钥加密（第5.4.2节）9。TGS-REP加密部分（包括应用程序会话密钥），使用TGS验证器子密钥加密（第5.4.2节）10。AP-REQ验证器cksum，使用应用程序会话密钥（第5.5.1节）11键入。AP-REQ验证器（包括应用程序验证器子密钥），使用应用程序会话密钥加密（第5.5.1节）12。AP-REP加密部分（包括应用程序会话子密钥），使用应用程序会话密钥加密（第5.5.2节）13。KRB-PRIV加密部分，使用应用程序选择的密钥加密（第5.7.1节）14。KRB-CRED加密部分，使用应用程序选择的密钥加密（第5.8.1节）15。KRB-SAFE cksum，使用应用程序选择的键进行键控（第5.6.1节）16-18。保留供将来在Kerberos和相关协议中使用。19AD-KDC-发布的校验和（5.2.6.4中的AD校验和）20-21。保留供将来在Kerberos和相关协议中使用。22-25. 保留用于Kerberos版本5 GSS-API机制[RFC4121]。26-511. 保留供将来在Kerberos和相关协议中使用。512-1023. 保留用于Kerberos实现的内部使用。1024在不指定密钥使用值的协议中用于应用程序的加密
1025. Checksums for application use in protocols that do not specify key usage values 1026-2047. Reserved for application use.
1025在不指定密钥使用值1026-2047的协议中使用的应用程序校验和。保留供应用程序使用。
Padata and Data Type Padata-type Comment Value
Padata和数据类型Padata类型注释值
PA-TGS-REQ 1 PA-ENC-TIMESTAMP 2 PA-PW-SALT 3 [reserved] 4 PA-ENC-UNIX-TIME 5 (deprecated) PA-SANDIA-SECUREID 6 PA-SESAME 7 PA-OSF-DCE 8 PA-CYBERSAFE-SECUREID 9 PA-AFS3-SALT 10 PA-ETYPE-INFO 11 PA-SAM-CHALLENGE 12 (sam/otp) PA-SAM-RESPONSE 13 (sam/otp) PA-PK-AS-REQ_OLD 14 (pkinit) PA-PK-AS-REP_OLD 15 (pkinit) PA-PK-AS-REQ 16 (pkinit) PA-PK-AS-REP 17 (pkinit) PA-ETYPE-INFO2 19 (replaces pa-etype-info) PA-USE-SPECIFIED-KVNO 20 PA-SAM-REDIRECT 21 (sam/otp) PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) TD-PADATA 22 (embeds padata) PA-SAM-ETYPE-INFO 23 (sam/otp) PA-ALT-PRINC 24 (crawdad@fnal.gov) PA-SAM-CHALLENGE2 30 (kenh@pobox.com) PA-SAM-RESPONSE2 31 (kenh@pobox.com) PA-EXTRA-TGT 41 Reserved extra TGT TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS TD-KRB-PRINCIPAL 102 PrincipalName TD-KRB-REALM 103 Realm TD-TRUSTED-CERTIFIERS 104 from PKINIT TD-CERTIFICATE-INDEX 105 from PKINIT TD-APP-DEFINED-ERROR 106 application specific TD-REQ-NONCE 107 INTEGER TD-REQ-SEQ 108 INTEGER PA-PAC-REQUEST 128 (jbrezak@exchange.microsoft.com)
PA-TGS-REQ 1 PA-ENC-TIMESTAMP 2 PA-PW-SALT 3[保留]4 PA-ENC-UNIX-TIME 5（已弃用）PA-SANDIA-SECUREID 6 PA-SESAME 7 PA-OSF-DCE 8 PA-CYBERSAFE-SECUREID 9 PA-AFS3-SALT 10 PA-ETYPE-INFO 11 PA-SAM-CHALLENGE 12（SAM/otp）PA-SAM-RESPONSE 13（SAM/otp）PA-PK-AS-REQUEST 14（NIT）PA-PKI-PKI-PKI-PKI-AS-REP-REQ 16（NIT）PA-PK-AS-REP 17（pkinit）PA-ETYPE-INFO2 19（替换PA-ETYPE信息）PA-USE-SPECIFIED-KVNO 20 PA-SAM-REDIRECT 21（SAM/otp）PA-GET-FROM-TYPED-DATA 22（嵌入类型化数据）TD-PADATA 22（嵌入PADATA）PA-SAM-ETYPE-info 23（SAM/otp）PA-ALT-PRINC 24(crawdad@fnal.gov)PA-SAM-CHALLENGE2 30(kenh@pobox.com)PA-SAM-response231(kenh@pobox.com)PA-EXTRA-TGT 41保留额外TGT TD-PKINIT-CMS-CERTIFICATES 101来自CMS的证书集TD-KRB-PRINCIPAL 102 PrincipalName TD-KRB-REALM 103 REALM TD-TRUSTED-CERTIFICATE 104来自PKINIT TD-CERTIFICATE 105来自PKINIT TD-APP-DEFINED-ERROR 106特定于应用程序的TD-REQ-NONCE 107整数TD-REQ-SEQ 108整数PA-PAC-REQUEST 128(jbrezak@exchange.microsoft.com)
Address Type Value
地址类型值
IPv4 2 Directional 3 ChaosNet 5 XNS 6 ISO 7 DECNET Phase IV 12 AppleTalk DDP 16 NetBios 20 IPv6 24
IPv4 2定向3超网5 XNS 6 ISO 7 DECNET第四阶段12 AppleTalk DDP 16 NetBios 20 IPv6 24
Authorization Data Type Ad-type Value
授权数据类型Ad类型值
AD-IF-RELEVANT 1 AD-INTENDED-FOR-SERVER 2 AD-INTENDED-FOR-APPLICATION-CLASS 3 AD-KDC-ISSUED 4 AD-AND-OR 5 AD-MANDATORY-TICKET-EXTENSIONS 6 AD-IN-TICKET-EXTENSIONS 7 AD-MANDATORY-FOR-KDC 8 Reserved values 9-63 OSF-DCE 64 SESAME 65 AD-OSF-DCE-PKI-CERTID 66 (hemsath@us.ibm.com) AD-WIN2K-PAC 128 (jbrezak@exchange.microsoft.com) AD-ETYPE-NEGOTIATION 129 (lzhu@windows.microsoft.com)
AD-IF-related 1 AD-designed-FOR-SERVER 2 AD-designed-FOR-APPLICATION-CLASS 3 AD-KDC-ISSUED 4 AD-AND-OR 5 AD-MANDATORY-TICKET-EXTENSIONS 6 AD-IN-TICKET-EXTENSIONS 7 AD-MANDATORY-FOR-KDC 8保留值9-63 OSF-DCE 64芝麻65 AD-OSF-DCE-PKI-CERTID 66(hemsath@us.ibm.com)AD-WIN2K-PAC 128(jbrezak@exchange.microsoft.com)AD-ETYPE-129(lzhu@windows.microsoft.com)
Transited Encoding Type Tr-type Value
传输编码类型Tr类型值
DOMAIN-X500-COMPRESS 1 Reserved values All others
域-X500-COMPRESS 1保留值所有其他
Label Value Meaning or MIT Code
标签值含义或MIT代码
pvno 5 Current Kerberos protocol version number
pvno 5当前Kerberos协议版本号
Message Type Value Meaning
消息类型值含义
KRB_AS_REQ 10 Request for initial authentication KRB_AS_REP 11 Response to KRB_AS_REQ request KRB_TGS_REQ 12 Request for authentication based on TGT KRB_TGS_REP 13 Response to KRB_TGS_REQ request KRB_AP_REQ 14 Application request to server KRB_AP_REP 15 Response to KRB_AP_REQ_MUTUAL KRB_RESERVED16 16 Reserved for user-to-user krb_tgt_request KRB_RESERVED17 17 Reserved for user-to-user krb_tgt_reply KRB_SAFE 20 Safe (checksummed) application message KRB_PRIV 21 Private (encrypted) application message KRB_CRED 22 Private (encrypted) message to forward credentials KRB_ERROR 30 Error response
KRB_AS_请求10初始身份验证请求KRB_AS_请求11对KRB_AS_请求的响应KRB_TGS_请求12基于TGT的身份验证请求KRB_TGS_请求13对KRB_TGS_请求的响应KRB_AP_请求14对服务器的应用程序请求KRB_AP_请求15对KRB_AP_请求的响应相互KRBU保留16为用户对用户的KRB_TGT请求保留KRB_RESERVED17 17保留给用户对用户KRB_tgt_回复KRB_安全20安全（校验和）应用程序消息KRB_PRIV 21私有（加密）应用程序消息KRB_CRED 22私有（加密）消息转发凭据KRB_错误30错误响应
Name Type Value Meaning
名称类型值含义
KRB_NT_UNKNOWN 0 Name type not known KRB_NT_PRINCIPAL 1 Just the name of the principal as in DCE, or for users KRB_NT_SRV_INST 2 Service and other unique instance (krbtgt) KRB_NT_SRV_HST 3 Service with host name as instance (telnet, rcommands) KRB_NT_SRV_XHST 4 Service with host as remaining components KRB_NT_UID 5 Unique ID KRB_NT_X500_PRINCIPAL 6 Encoded X.509 Distinguished name [RFC2253] KRB_NT_SMTP_NAME 7 Name in form of SMTP email name (e.g., user@example.com) KRB_NT_ENTERPRISE 10 Enterprise name; may be mapped to principal name
KRB_NT_未知0名称类型未知KRB_NT_主体1仅为DCE中主体的名称，或对于用户KRB_NT_SRV_INST 2服务和其他唯一实例（krbtgt）KRB_NT_SRV_HST 3服务，主机名为实例（telnet、rcommands）KRB_NT_SRV_XHST 4服务，主机作为剩余组件KRB_NT_UID 5唯一ID KRB_NT_X500_主体6编码的X.509可分辨名称[RFC2253]KRB_NT_SMTP_名称7 SMTP电子邮件名称形式的名称（例如。，user@example.com)KRB_NT_ENTERPRISE 10企业名称；可以映射到主体名称
Error Code Value Meaning
错误代码值含义
KDC_ERR_NONE 0 No error KDC_ERR_NAME_EXP 1 Client's entry in database has expired KDC_ERR_SERVICE_EXP 2 Server's entry in database has expired KDC_ERR_BAD_PVNO 3 Requested protocol version number not supported
KDC_ERR_NONE 0无错误KDC_ERR_NAME_EXP 1数据库中的客户端条目已过期KDC_ERR_服务_EXP 2数据库中的服务器条目已过期KDC_ERR_BAD_PVNO 3请求的协议版本号不受支持
KDC_ERR_C_OLD_MAST_KVNO 4 Client's key encrypted in old master key KDC_ERR_S_OLD_MAST_KVNO 5 Server's key encrypted in old master key KDC_ERR_C_PRINCIPAL_UNKNOWN 6 Client not found in Kerberos database KDC_ERR_S_PRINCIPAL_UNKNOWN 7 Server not found in Kerberos database KDC_ERR_PRINCIPAL_NOT_UNIQUE 8 Multiple principal entries in database KDC_ERR_NULL_KEY 9 The client or server has a null key KDC_ERR_CANNOT_POSTDATE 10 Ticket not eligible for postdating KDC_ERR_NEVER_VALID 11 Requested starttime is later than end time KDC_ERR_POLICY 12 KDC policy rejects request KDC_ERR_BADOPTION 13 KDC cannot accommodate requested option KDC_ERR_ETYPE_NOSUPP 14 KDC has no support for encryption type KDC_ERR_SUMTYPE_NOSUPP 15 KDC has no support for checksum type KDC_ERR_PADATA_TYPE_NOSUPP 16 KDC has no support for padata type KDC_ERR_TRTYPE_NOSUPP 17 KDC has no support for transited type KDC_ERR_CLIENT_REVOKED 18 Clients credentials have been revoked KDC_ERR_SERVICE_REVOKED 19 Credentials for server have been revoked KDC_ERR_TGT_REVOKED 20 TGT has been revoked KDC_ERR_CLIENT_NOTYET 21 Client not yet valid; try again later KDC_ERR_SERVICE_NOTYET 22 Server not yet valid; try again later KDC_ERR_KEY_EXPIRED 23 Password has expired; change password to reset KDC_ERR_PREAUTH_FAILED 24 Pre-authentication information was invalid KDC_ERR_PREAUTH_REQUIRED 25 Additional pre-authentication required KDC_ERR_SERVER_NOMATCH 26 Requested server and ticket don't match KDC_ERR_MUST_USE_USER2USER 27 Server principal valid for user2user only KDC_ERR_PATH_NOT_ACCEPTED 28 KDC Policy rejects transited path
KDC_ERR_C_OLD_MAST_KVNO 4用旧主密钥加密的客户端密钥KDC_ERR_s_OLD_MAST_KVNO 5用旧主密钥加密的服务器密钥KDC_ERR_C_PRINCIPAL_未知6在Kerberos数据库中找不到客户端KDC_ERR_s_PRINCIPAL_未知7在Kerberos数据库中找不到服务器KDC_ERR_PRINCIPAL_非唯一8数据库中的多个主体条目KDC_ERR_NULL_KEY 9客户端或服务器有一个NULL KEY KDC_ERR_CANNOT_POSTDATE 10票证没有资格进行POSTDATE KDC_ERR_NEVER_VALID 11请求的开始时间晚于结束时间KDC_ERR_POLICY 12 KDC POLICY拒绝请求KDC_ERR_bad选项13 KDC无法容纳请求的选项KDC_ERR_ETYPE_NOSUPP 14 KDC不支持加密类型KDC_ERR_SUMTYPE_NOSUPP 15 KDC不支持校验和类型KDC_ERR_PADATA_type_NOSUPP 16 KDC不支持PADATA类型KDC_ERR_TRTYPE_NOSUPP 17 KDC不支持传输类型KDC_ERR_客户端已撤销18个客户端凭据已撤销KDC_ERR_服务已撤销19个服务器凭据已撤销KDC_ERR_TGT20 TGT已被撤销KDC_ERR_CLIENT_not 21 CLIENT尚未生效；稍后再试KDC_ERR_SERVICE_NOTYET 22服务器尚未生效；请稍后重试KDC_ERR_KEY_EXPIRED 23密码已过期；更改密码以重置KDC_ERR_PREAUTH_失败24预验证信息无效KDC_ERR_PREAUTH_需要25额外的预验证要求KDC_ERR_SERVER_NOMATCH 26请求的服务器和票证不匹配KDC_ERR_必须使用用户27服务器主体对用户有效KDC_ERR_路径不接受28 KDC策略拒绝过渡路径
KDC_ERR_SVC_UNAVAILABLE 29 A service is not available KRB_AP_ERR_BAD_INTEGRITY 31 Integrity check on decrypted field failed KRB_AP_ERR_TKT_EXPIRED 32 Ticket expired KRB_AP_ERR_TKT_NYV 33 Ticket not yet valid KRB_AP_ERR_REPEAT 34 Request is a replay KRB_AP_ERR_NOT_US 35 The ticket isn't for us KRB_AP_ERR_BADMATCH 36 Ticket and authenticator don't match KRB_AP_ERR_SKEW 37 Clock skew too great KRB_AP_ERR_BADADDR 38 Incorrect net address KRB_AP_ERR_BADVERSION 39 Protocol version mismatch KRB_AP_ERR_MSG_TYPE 40 Invalid msg type KRB_AP_ERR_MODIFIED 41 Message stream modified KRB_AP_ERR_BADORDER 42 Message out of order KRB_AP_ERR_BADKEYVER 44 Specified version of key is not available KRB_AP_ERR_NOKEY 45 Service key not available KRB_AP_ERR_MUT_FAIL 46 Mutual authentication failed KRB_AP_ERR_BADDIRECTION 47 Incorrect message direction KRB_AP_ERR_METHOD 48 Alternative authentication method required KRB_AP_ERR_BADSEQ 49 Incorrect sequence number in message KRB_AP_ERR_INAPP_CKSUM 50 Inappropriate type of checksum in message KRB_AP_PATH_NOT_ACCEPTED 51 Policy rejects transited path KRB_ERR_RESPONSE_TOO_BIG 52 Response too big for UDP; retry with TCP KRB_ERR_GENERIC 60 Generic error (description in e-text) KRB_ERR_FIELD_TOOLONG 61 Field is too long for this implementation KDC_ERROR_CLIENT_NOT_TRUSTED 62 Reserved for PKINIT KDC_ERROR_KDC_NOT_TRUSTED 63 Reserved for PKINIT KDC_ERROR_INVALID_SIG 64 Reserved for PKINIT KDC_ERR_KEY_TOO_WEAK 65 Reserved for PKINIT KDC_ERR_CERTIFICATE_MISMATCH 66 Reserved for PKINIT KRB_AP_ERR_NO_TGT 67 No TGT available to validate USER-TO-USER KDC_ERR_WRONG_REALM 68 Reserved for future use KRB_AP_ERR_USER_TO_USER_REQUIRED 69 Ticket must be for USER-TO-USER KDC_ERR_CANT_VERIFY_CERTIFICATE 70 Reserved for PKINIT KDC_ERR_INVALID_CERTIFICATE 71 Reserved for PKINIT KDC_ERR_REVOKED_CERTIFICATE 72 Reserved for PKINIT
KDC错误SVC不可用29服务不可用KRB_AP_错误BAD_完整性31解密字段完整性检查失败KRB_AP_错误TKT_过期32票证过期KRB_AP_错误TKT_NYV 33票证无效KRB_AP_错误重复34请求是重播KRB_AP_错误not_我们35票证不适合我们KRB_AP_ERR_错误36票证和验证者不匹配匹配KRB_AP_ERR_歪斜37时钟歪斜太大KRB_AP_ERR_baddr 38不正确的网络地址KRB_AP_ERR_baddr版本39协议版本不匹配KRB_AP_ERR_MSG_类型40无效消息类型KRB_AP_ERR_修改41消息流修改KRB_AP_ERR_badder 42消息无序KRB_AP_ERR badder 44指定的密钥版本不可用KRB_AP_ERR_NOKEY 45服务密钥不可用KRB_AP_ERR_MUT_失败46相互身份验证失败KRB_AP_ERR_BADDIRECTION 47错误的消息方向KRB_AP_ERR_方法48需要KRB_AP_ERR_BADSEQ 49消息KRB_AP_ERR_INAPP_校验和中不正确的校验和类型50KRB_AP_PATH_NOT_ACCEPTED 51策略拒绝传输路径KRB_ERR_RESPONSE_过大52响应对UDP过大；使用TCP KRB_ERR_GENERIC error 60重试一般错误（电子文本中的说明）KRB_ERROR_FIELD_TOOLONG 61字段太长，无法执行KDC_ERROR_CLIENT_NOT_TRUSTED 62保留用于PKINT KDC_ERROR_NOT_TRUSTED 63保留用于PKINT KDC_ERROR_无效标志64保留用于PKINT KDC_ERR_KEY_太弱65保留用于PKINT KDC_ERR_证书不匹配66保留用于PKINT KRB_AP_ERR_没有TGT 67可用要验证用户对用户KDC_ERR_Error_REALM 68保留供将来使用KRB_AP_ERR_USER_to_USER_所需69票证必须用于用户对用户KDC_ERR_Can_验证证书70保留给PKINIT KDC_ERR_无效证书71保留给PKINIT KDC_ERR_吊销证书72保留给PKINIT
KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 Reserved for PKINIT KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 Reserved for PKINIT KDC_ERR_CLIENT_NAME_MISMATCH 75 Reserved for PKINIT KDC_ERR_KDC_NAME_MISMATCH 76 Reserved for PKINIT
KDC_错误_撤销_状态_未知73为PKINIT保留KDC_错误_撤销_状态_不可用74为PKINIT保留KDC_错误_客户端_名称_不匹配75为PKINIT保留KDC_错误_KDC_名称_不匹配76为PKINIT保留
Version 5 of the Kerberos protocol supports a myriad of options.
Among these are multiple encryption and checksum types; alternative
encoding schemes for the transited field; optional mechanisms for
pre-authentication; the handling of tickets with no addresses;
options for mutual authentication; user-to-user authentication;
support for proxies; the format of realm names; the handling of
authorization data; and forwarding, postdating, and renewing tickets.
Version 5 of the Kerberos protocol supports a myriad of options.
Among these are multiple encryption and checksum types; alternative
encoding schemes for the transited field; optional mechanisms for
pre-authentication; the handling of tickets with no addresses;
options for mutual authentication; user-to-user authentication;
support for proxies; the format of realm names; the handling of
authorization data; and forwarding, postdating, and renewing tickets.
In order to ensure the interoperability of realms, it is necessary to define a minimal configuration that must be supported by all implementations. This minimal configuration is subject to change as technology does. For example, if at some later date it is discovered that one of the required encryption or checksum algorithms is not secure, it will be replaced.
为了确保领域的互操作性，有必要定义所有实现必须支持的最小配置。这种最小配置可能会随着技术的变化而变化。例如，如果在以后的某个日期发现所需的加密或校验和算法之一不安全，则将替换它。
This section defines the second specification of these options. Implementations which are configured in this way can be said to support Kerberos Version 5 Specification 2 (5.2). Specification 1 (deprecated) may be found in RFC 1510.
本节定义了这些选项的第二个规范。以这种方式配置的实现可以说支持Kerberos版本5规范2（5.2）。规范1（已弃用）可在RFC 1510中找到。
Transport
运输
TCP/IP and UDP/IP transport MUST be supported by clients and KDCs claiming conformance to specification 2.
声称符合规范2的客户端和KDC必须支持TCP/IP和UDP/IP传输。
Encryption and Checksum Methods
加密和校验和方法
The following encryption and checksum mechanisms MUST be supported:
必须支持以下加密和校验和机制：
Encryption: AES256-CTS-HMAC-SHA1-96 [RFC3962] Checksums: HMAC-SHA1-96-AES256 [RFC3962]
加密：AES256-CTS-HMAC-SHA1-96[RFC3962]校验和：HMAC-SHA1-96-AES256[RFC3962]
Implementations SHOULD support other mechanisms as well, but the additional mechanisms may only be used when communicating with principals known to also support them. The following mechanisms from [RFC3961] and [RFC3962] SHOULD be supported:
实现还应该支持其他机制，但只有在与已知也支持这些机制的主体通信时，才能使用其他机制。应支持[RFC3961]和[RFC3962]中的以下机制：
Encryption: AES128-CTS-HMAC-SHA1-96, DES-CBC-MD5, DES3-CBC-SHA1-KD Checksums: DES-MD5, HMAC-SHA1-DES3-KD, HMAC-SHA1-96-AES128
加密：AES128-CTS-HMAC-SHA1-96、DES-CBC-MD5、DES3-CBC-SHA1-KD校验和：DES-MD5、HMAC-SHA1-DES3-KD、HMAC-SHA1-96-AES128
Implementations MAY support other mechanisms as well, but the additional mechanisms may only be used when communicating with principals known to support them also.
实现也可以支持其他机制，但附加机制只能在与已知也支持它们的主体通信时使用。
Implementation note: Earlier implementations of Kerberos generate messages using the CRC-32 and RSA-MD5 checksum methods. For interoperability with these earlier releases, implementors MAY consider supporting these checksum methods but should carefully analyze the security implications to limit the situations within which these methods are accepted.
实现说明：Kerberos的早期实现使用CRC-32和RSA-MD5校验和方法生成消息。为了与这些较早版本的互操作性，实现者可以考虑支持这些校验和方法，但是应该仔细分析安全含义，以限制这些方法被接受的情况。
Realm Names
域名
All implementations MUST understand hierarchical realms in both the Internet Domain and the X.500 style. When a TGT for an unknown realm is requested, the KDC MUST be able to determine the names of the intermediate realms between the KDCs realm and the requested realm.
所有实现都必须理解Internet域和X.500样式中的层次结构。当请求未知领域的TGT时，KDC必须能够确定KDCs领域和请求领域之间的中间领域的名称。
Transited Field Encoding
瞬变场编码
DOMAIN-X500-COMPRESS (described in Section 3.3.3.2) MUST be supported. Alternative encodings MAY be supported, but they may only be used when that encoding is supported by ALL intermediate realms.
必须支持DOMAIN-X500-COMPRESS（如第3.3.3.2节所述）。可以支持替代编码，但只有当所有中间领域都支持该编码时，才可以使用替代编码。
Pre-authentication Methods
预认证方法
The TGS-REQ method MUST be supported. It is not used on the initial request. The PA-ENC-TIMESTAMP method MUST be supported by clients, but whether it is enabled by default MAY be determined on a realm-by-realm basis. If the method is not used in the initial request and the error KDC_ERR_PREAUTH_REQUIRED is returned specifying PA-ENC-TIMESTAMP as an acceptable method, the client SHOULD retry the initial request using the PA-ENC-TIMESTAMP pre-authentication method. Servers need not support the PA-ENC-TIMESTAMP method, but if it is not supported the server SHOULD ignore the presence of PA-ENC-TIMESTAMP pre-authentication in a request.
必须支持TGS-REQ方法。它不用于初始请求。客户端必须支持PA-ENC-TIMESTAMP方法，但默认情况下是否启用该方法可能取决于各个领域。如果初始请求中未使用该方法，并且返回错误KDC_ERR_PREAUTH_REQUIRED，指定PA-ENC-TIMESTAMP为可接受的方法，则客户端应使用PA-ENC-TIMESTAMP预身份验证方法重试初始请求。服务器不需要支持PA-ENC-TIMESTAMP方法，但如果不支持，则服务器应忽略请求中是否存在PA-ENC-TIMESTAMP预身份验证。
The ETYPE-INFO2 method MUST be supported; this method is used to communicate the set of supported encryption types, and corresponding salt and string to key parameters. The ETYPE-INFO method SHOULD be supported for interoperability with older implementation.
必须支持ETYPE-INFO2方法；此方法用于将支持的加密类型集以及相应的salt和字符串与密钥参数进行通信。应支持ETYPE-INFO方法，以实现与旧实现的互操作性。
Mutual Authentication
相互认证
Mutual authentication (via the KRB_AP_REP message) MUST be supported.
必须支持相互身份验证（通过KRB_AP_REP消息）。
Ticket Addresses and Flags
票务地址及旗帜
All KDCs MUST pass through tickets that carry no addresses (i.e., if a TGT contains no addresses, the KDC will return derivative tickets). Implementations SHOULD default to requesting addressless tickets, as this significantly increases interoperability with network address translation. In some cases, realms or application servers MAY require that tickets have an address.
所有KDC必须通过没有地址的票证（即，如果TGT不包含地址，KDC将返回衍生票证）。实现应该默认为请求无地址票证，因为这显著提高了与网络地址转换的互操作性。在某些情况下，领域或应用服务器可能要求票据具有地址。
Implementations SHOULD accept directional address type for the KRB_SAFE and KRB_PRIV message and SHOULD include directional addresses in these messages when other address types are not available.
实现应该接受KRB_SAFE和KRB_PRIV消息的定向地址类型，并且当其他地址类型不可用时，应该在这些消息中包含定向地址。
Proxies and forwarded tickets MUST be supported. Individual realms and application servers can set their own policy on when such tickets will be accepted.
必须支持代理和转发的票证。各个领域和应用服务器可以设置自己的策略，以确定何时接受此类票据。
All implementations MUST recognize renewable and postdated tickets, but they need not actually implement them. If these options are not supported, the starttime and endtime in the ticket SHALL specify a ticket's entire useful life. When a postdated ticket is decoded by a server, all implementations SHALL make the presence of the postdated flag visible to the calling server.
所有实现都必须识别可更新和过期的票据，但它们不需要实际实现它们。如果不支持这些选项，则记录单中的开始时间和结束时间应指定记录单的整个使用寿命。当服务器对过期票据进行解码时，所有实现都应使呼叫服务器能够看到过期标志的存在。
User-to-User Authentication
用户对用户身份验证
Support for user-to-user authentication (via the ENC-TKT-IN-SKEY KDC option) MUST be provided by implementations, but individual realms MAY decide as a matter of policy to reject such requests on a per-principal or realm-wide basis.
实现必须提供对用户到用户身份验证（通过ENC-TKT-IN-SKEY KDC选项）的支持，但作为一项政策，各个领域可能决定在每个主体或整个领域的基础上拒绝此类请求。
Authorization Data
授权数据
Implementations MUST pass all authorization data subfields from TGTs to any derivative tickets unless they are directed to suppress a subfield as part of the definition of that registered subfield type. (It is never incorrect to pass on a subfield, and no registered subfield types presently specify suppression at the KDC.)
实现必须将所有授权数据子字段从TGT传递到任何派生票据，除非它们被指示作为已注册子字段类型定义的一部分抑制子字段。（传递子场从来都是正确的，目前没有注册的子场类型指定KDC处的抑制。）
Implementations MUST make the contents of any authorization data subfields available to the server when a ticket is used. Implementations are not required to allow clients to specify the contents of the authorization data fields.
当使用票据时，实现必须使任何授权数据子字段的内容对服务器可用。允许客户端指定授权数据字段的内容不需要实现。
Constant Ranges
恒定范围
All protocol constants are constrained to 32-bit (signed) values unless further constrained by the protocol definition. This limit is provided to allow implementations to make assumptions about the maximum values that will be received for these constants. Implementations receiving values outside this range MAY reject the request, but they MUST recover cleanly.
除非协议定义进一步约束，否则所有协议常量都约束为32位（有符号）值。提供此限制是为了允许实现对这些常量将接收的最大值进行假设。接收超出此范围的值的实现可能会拒绝请求，但它们必须干净地恢复。
Following is a list of recommended values for a KDC configuration.
以下是KDC配置的建议值列表。
Minimum lifetime 5 minutes Maximum renewable lifetime 1 week Maximum ticket lifetime 1 day Acceptable clock skew 5 minutes Empty addresses Allowed Proxiable, etc. Allowed
最短生存期5分钟最长可更新生存期1周最长票证生存期1天可接受时钟偏差5分钟允许空地址可代理等允许
Section 7 of this document specifies protocol constants and other defined values required for the interoperability of multiple implementations. Until a subsequent RFC specifies otherwise, or the Kerberos working group is shut down, allocations of additional protocol constants and other defined values required for extensions to the Kerberos protocol will be administered by the Kerberos working group. Following the recommendations outlined in [RFC2434], guidance is provided to the IANA as follows:
本文件第7节规定了多个实现的互操作性所需的协议常数和其他定义值。在后续RFC另有规定或Kerberos工作组关闭之前，Kerberos工作组将管理Kerberos协议扩展所需的其他协议常数和其他定义值的分配。根据[RFC2434]中概述的建议，向IANA提供的指导如下：
"reserved" realm name types in Section 6.1 and "other" realm types except those beginning with "X-" or "x-" will not be registered without IETF standards action, at which point guidelines for further assignment will be specified. Realm name types beginning with "X-" or "x-" are for private use.
第6.1节中的“保留”领域名称类型和“其他”领域类型（以“X-”或“X-”开头的除外）在没有IETF标准行动的情况下将不会注册，届时将指定进一步分配的指南。以“X-”或“X-”开头的域名类型仅供私人使用。
For host address types described in Section 7.1, negative values are for private use. Assignment of additional positive numbers is subject to review by the Kerberos working group or other expert review.
对于第7.1节中描述的主机地址类型，负值仅供私人使用。其他正数的分配须经Kerberos工作组或其他专家审查。
Additional key usage numbers, as defined in Section 7.5.1, will be assigned subject to review by the Kerberos working group or other expert review.
第7.5.1节中定义的其他密钥使用编号将根据Kerberos工作组的审查或其他专家的审查进行分配。
Additional preauthentication data type values, as defined in section 7.5.2, will be assigned subject to review by the Kerberos working group or other expert review.
第7.5.2节中定义的其他预验证数据类型值将根据Kerberos工作组的审查或其他专家的审查进行分配。
Additional authorization data types as defined in Section 7.5.4, will be assigned subject to review by the Kerberos working group or other expert review. Although it is anticipated that there may be significant demand for private use types, provision is intentionally not made for a private use portion of the namespace because conflicts between privately assigned values could have detrimental security implications.
第7.5.4节中定义的其他授权数据类型将根据Kerberos工作组的审查或其他专家的审查进行分配。尽管预计可能会对私有使用类型有大量需求，但故意不为命名空间的私有使用部分作出规定，因为私有分配的值之间的冲突可能会产生有害的安全影响。
Additional transited encoding types, as defined in Section 7.5.5, present special concerns for interoperability with existing implementations. As such, such assignments will only be made by standards action, except that the Kerberos working group or another other working group with competent jurisdiction may make preliminary assignments for documents that are moving through the standards process.
第7.5.5节中定义的其他转换编码类型特别关注与现有实现的互操作性。因此，此类分配只能通过标准行动进行，除非Kerberos工作组或其他具有管辖权的工作组可以对通过标准流程的文件进行初步分配。
Additional Kerberos message types, as described in Section 7.5.7, will be assigned subject to review by the Kerberos working group or other expert review.
如第7.5.7节所述，其他Kerberos消息类型将根据Kerberos工作组的审查或其他专家的审查进行分配。
Additional name types, as described in Section 7.5.8, will be assigned subject to review by the Kerberos working group or other expert review.
如第7.5.8节所述，其他名称类型将根据Kerberos工作组的审查或其他专家的审查进行分配。
Additional error codes described in Section 7.5.9 will be assigned subject to review by the Kerberos working group or other expert review.
第7.5.9节中描述的其他错误代码将根据Kerberos工作组的审查或其他专家的审查进行分配。
As an authentication service, Kerberos provides a means of verifying the identity of principals on a network. By itself, Kerberos does not provide authorization. Applications should not accept the issuance of a service ticket by the Kerberos server as granting authority to use the service, since such applications may become vulnerable to the bypass of this authorization check in an environment where they inter-operate with other KDCs or where other options for application authentication are provided.
作为一种身份验证服务，Kerberos提供了一种验证网络上主体身份的方法。Kerberos本身不提供授权。应用程序不应接受Kerberos服务器颁发的服务票证作为使用该服务的授权，因为在与其他KDC交互操作或提供了其他应用程序身份验证选项的环境中，此类应用程序可能容易绕过此授权检查。
Denial of service attacks are not solved with Kerberos. There are places in the protocols where an intruder can prevent an application from participating in the proper authentication steps. Because authentication is a required step for the use of many services, successful denial of service attacks on a Kerberos server might result in the denial of other network services that rely on Kerberos for authentication. Kerberos is vulnerable to many kinds of denial of service attacks: those on the network, which would prevent clients from contacting the KDC; those on the domain name system, which could prevent a client from finding the IP address of the Kerberos server; and those by overloading the Kerberos KDC itself with repeated requests.
Kerberos无法解决拒绝服务攻击。在协议中，入侵者可能会阻止应用程序参与正确的身份验证步骤。由于身份验证是使用许多服务的必要步骤，因此对Kerberos服务器的成功拒绝服务攻击可能会导致拒绝依赖Kerberos进行身份验证的其他网络服务。Kerberos易受多种拒绝服务攻击的攻击：网络上的拒绝服务攻击会阻止客户端联系KDC；域名系统上的，这可能会阻止客户端查找Kerberos服务器的IP地址；以及通过重复请求重载Kerberos KDC本身来实现。
Interoperability conflicts caused by incompatible character-set usage (see 5.2.1) can result in denial of service for clients that utilize character-sets in Kerberos strings other than those stored in the KDC database.
由不兼容的字符集使用引起的互操作性冲突（请参见5.2.1）可能会导致拒绝服务，这些客户端使用Kerberos字符串中的字符集，而不是存储在KDC数据库中的字符集。
Authentication servers maintain a database of principals (i.e., users and servers) and their secret keys. The security of the authentication server machines is critical. The breach of security of an authentication server will compromise the security of all servers that rely upon the compromised KDC, and will compromise the authentication of any principals registered in the realm of the compromised KDC.
身份验证服务器维护主体（即用户和服务器）及其密钥的数据库。身份验证服务器机器的安全性至关重要。违反身份验证服务器的安全性将危及依赖受损KDC的所有服务器的安全性，并将危及在受损KDC领域中注册的任何主体的身份验证。
Principals must keep their secret keys secret. If an intruder somehow steals a principal's key, it will be able to masquerade as that principal or impersonate any server to the legitimate principal.
委托人必须对其密钥保密。如果入侵者以某种方式窃取了主体的密钥，它将能够伪装成该主体，或者向合法主体模拟任何服务器。
Password-guessing attacks are not solved by Kerberos. If a user chooses a poor password, it is possible for an attacker to successfully mount an off-line dictionary attack by repeatedly attempting to decrypt, with successive entries from a dictionary, messages obtained that are encrypted under a key derived from the user's password.
Kerberos无法解决密码猜测攻击。如果用户选择的密码不正确，攻击者有可能通过重复尝试使用字典中的连续条目解密根据用户密码派生的密钥加密的消息，从而成功发起脱机字典攻击。
Unless pre-authentication options are required by the policy of a realm, the KDC will not know whether a request for authentication succeeds. An attacker can request a reply with credentials for any principal. These credentials will likely not be of much use to the attacker unless it knows the client's secret key, but the availability of the response encrypted in the client's secret key provides the attacker with ciphertext that may be used to mount brute force or dictionary attacks to decrypt the credentials, by guessing the user's password. For this reason it is strongly encouraged that Kerberos realms require the use of pre-authentication. Even with
除非域的策略需要预身份验证选项，否则KDC将不知道身份验证请求是否成功。攻击者可以使用任何主体的凭据请求回复。除非攻击者知道客户机的密钥，否则这些凭据可能不会对其有多大用处，但在客户机密钥中加密的响应的可用性为攻击者提供了密文，可用于通过猜测用户密码来发起暴力或字典攻击以解密凭据。因此，强烈建议Kerberos领域需要使用预身份验证。即使
pre-authentication, attackers may try brute force or dictionary attacks against credentials that are observed by eavesdropping on the network.
在进行身份验证之前，攻击者可能会对通过网络窃听观察到的凭据尝试暴力或字典攻击。
Because a client can request a ticket for any server principal and can attempt a brute force or dictionary attack against the server principal's key using that ticket, it is strongly encouraged that keys be randomly generated (rather than generated from passwords) for any principals that are usable as the target principal for a KRB_TGS_REQ or KRB_AS_REQ messages. [RFC4086]
由于客户端可以请求任何服务器主体的票证，并可以使用该票证对服务器主体的密钥进行暴力或字典攻击，因此强烈建议随机生成密钥（而不是从密码生成）对于可用作KRB_TGS_REQ或KRB_as_REQ消息的目标主体的任何主体。[RFC4086]
Although the DES-CBC-MD5 encryption method and DES-MD5 checksum methods are listed as SHOULD be implemented for backward compatibility, the single DES encryption algorithm on which these are based is weak, and stronger algorithms should be used whenever possible.
尽管DES-CBC-MD5加密方法和DES-MD5校验和方法被列为应实现向后兼容性的方法，但它们所基于的单一DES加密算法较弱，应尽可能使用更强的算法。
Each host on the network must have a clock that is loosely synchronized to the time of the other hosts; this synchronization is used to reduce the bookkeeping needs of application servers when they do replay detection. The degree of "looseness" can be configured on a per-server basis, but it is typically on the order of 5 minutes. If the clocks are synchronized over the network, the clock synchronization protocol MUST itself be secured from network attackers.
网络上的每个主机必须有一个与其他主机的时间松散同步的时钟；此同步用于减少应用程序服务器执行重播检测时的簿记需求。“松散”的程度可以根据每台服务器进行配置，但通常为5分钟左右。如果时钟通过网络同步，则时钟同步协议本身必须受到网络攻击者的保护。
Principal identifiers must not recycled on a short-term basis. A typical mode of access control will use access control lists (ACLs) to grant permissions to particular principals. If a stale ACL entry remains for a deleted principal and the principal identifier is reused, the new principal will inherit rights specified in the stale ACL entry. By not reusing principal identifiers, the danger of inadvertent access is removed.
不得在短期内回收主要标识符。访问控制的典型模式将使用访问控制列表（ACL）向特定主体授予权限。如果已删除主体的旧ACL条目仍然存在，并且主体标识符被重用，则新主体将继承旧ACL条目中指定的权限。通过不重用主体标识符，消除了无意访问的危险。
Proper decryption of an KRB_AS_REP message from the KDC is not sufficient for the host to verify the identity of the user; the user and an attacker could cooperate to generate a KRB_AS_REP format message that decrypts properly but is not from the proper KDC. To authenticate a user logging on to a local system, the credentials obtained in the AS exchange may first be used in a TGS exchange to obtain credentials for a local server. Those credentials must then be verified by a local server through successful completion of the Client/Server exchange.
来自KDC的KRB_AS_REP消息的正确解密不足以让主机验证用户的身份；用户和攻击者可以合作生成KRB_AS_REP格式的消息，该消息可以正确解密，但不是来自正确的KDC。要对登录到本地系统的用户进行身份验证，可以首先在TGS exchange中使用在AS exchange中获得的凭据来获取本地服务器的凭据。然后，本地服务器必须通过成功完成客户机/服务器交换来验证这些凭据。
Many RFC 1510-compliant implementations ignore unknown authorization data elements. Depending on these implementations to honor authorization data restrictions may create a security weakness.
许多符合RFC 1510的实现忽略未知的授权数据元素。依靠这些实现来遵守授权数据限制可能会造成安全弱点。
Kerberos credentials contain clear-text information identifying the principals to which they apply. If privacy of this information is needed, this exchange should itself be encapsulated in a protocol providing for confidentiality on the exchange of these credentials.
Kerberos凭据包含标识其应用的主体的明文信息。如果需要此信息的隐私，则此交换本身应封装在协议中，以提供这些凭据交换的机密性。
Applications must take care to protect communications subsequent to authentication, either by using the KRB_PRIV or KRB_SAFE messages as appropriate, or by applying their own confidentiality or integrity mechanisms on such communications. Completion of the KRB_AP_REQ and KRB_AP_REP exchange without subsequent use of confidentiality and integrity mechanisms provides only for authentication of the parties to the communication and not confidentiality and integrity of the subsequent communication. Applications applying confidentiality and integrity protection mechanisms other than KRB_PRIV and KRB_SAFE must make sure that the authentication step is appropriately linked with the protected communication channel that is established by the application.
应用程序必须注意保护身份验证后的通信，可以酌情使用KRB_PRIV或KRB_SAFE消息，也可以在此类通信上应用自己的保密性或完整性机制。完成KRB_AP_REQ和KRB_AP_REP交换而不随后使用保密和完整性机制，仅提供通信各方的身份验证，而不提供后续通信的保密性和完整性。应用除KRB_PRIV和KRB_SAFE之外的机密性和完整性保护机制的应用程序必须确保身份验证步骤与应用程序建立的受保护通信通道适当链接。
Unless the application server provides its own suitable means to protect against replay (for example, a challenge-response sequence initiated by the server after authentication, or use of a server-generated encryption subkey), the server must utilize a replay cache to remember any authenticator presented within the allowable clock skew. All services sharing a key need to use the same replay cache. If separate replay caches are used, then an authenticator used with one such service could later be replayed to a different service with the same service principal.
除非应用服务器提供其自己的适当方法来防止重播（例如，在认证后由服务器启动的质询响应序列，或使用服务器生成的加密子密钥），否则服务器必须利用重播缓存来记住在允许的时钟偏差内出现的任何验证器。共享密钥的所有服务都需要使用相同的重播缓存。如果使用单独的重放缓存，那么与一个这样的服务一起使用的验证器稍后可以重放到具有相同服务主体的不同服务。
If a server loses track of authenticators presented within the allowable clock skew, it must reject all requests until the clock skew interval has passed, providing assurance that any lost or replayed authenticators will fall outside the allowable clock skew and can no longer be successfully replayed.
如果服务器无法跟踪在允许的时钟偏移范围内显示的验证器，则必须拒绝所有请求，直到超过时钟偏移间隔，从而确保任何丢失或重放的验证器都将超出允许的时钟偏移范围，并且无法再成功重放。
Implementations of Kerberos should not use untrusted directory servers to determine the realm of a host. To allow this would allow the compromise of the directory server to enable an attacker to direct the client to accept authentication with the wrong principal (i.e., one with a similar name, but in a realm with which the legitimate host was not registered).
Kerberos的实现不应使用不受信任的目录服务器来确定主机的领域。允许这样做会使目录服务器受损，从而使攻击者能够指示客户端接受错误主体的身份验证（即，具有类似名称的主体，但在未注册合法主机的域中）。
Implementations of Kerberos must not use DNS to map one name to another (canonicalize) in order to determine the host part of the principal name with which one is to communicate. To allow this canonicalization would allow a compromise of the DNS to result in a client obtaining credentials and correctly authenticating to the
Kerberos的实现不能使用DNS将一个名称映射到另一个名称（规范化），以确定要与之通信的主体名称的主机部分。允许此规范化将允许DNS的妥协，从而导致客户端获得凭据并正确地向服务器进行身份验证
wrong principal. Though the client will know who it is communicating with, it will not be the principal with which it intended to communicate.
错误的校长。虽然客户会知道与谁沟通，但不会是其打算与之沟通的负责人。
If the Kerberos server returns a TGT for a realm 'closer' than the desired realm, the client may use local policy configuration to verify that the authentication path used is an acceptable one. Alternatively, a client may choose its own authentication path rather than rely on the Kerberos server to select one. In either case, any policy or configuration information used to choose or validate authentication paths, whether by the Kerberos server or client, must be obtained from a trusted source.
如果Kerberos服务器返回一个比所需域“更近”的域的TGT，则客户端可以使用本地策略配置来验证所使用的身份验证路径是否是可接受的路径。或者，客户机可以选择自己的身份验证路径，而不是依赖Kerberos服务器来选择。在任何一种情况下，用于选择或验证身份验证路径的任何策略或配置信息（无论是由Kerberos服务器还是客户端提供的）都必须从受信任的源获取。
The Kerberos protocol in its basic form does not provide perfect forward secrecy for communications. If traffic has been recorded by an eavesdropper, then messages encrypted using the KRB_PRIV message, or messages encrypted using application-specific encryption under keys exchanged using Kerberos can be decrypted if the user's, application server's, or KDC's key is subsequently discovered. This is because the session key used to encrypt such messages, when transmitted over the network, is encrypted in the key of the application server. It is also encrypted under the session key from the user's TGT when it is returned to the user in the KRB_TGS_REP message. The session key from the TGT is sent to the user in the KRB_AS_REP message encrypted in the user's secret key and embedded in the TGT, which was encrypted in the key of the KDC. Applications requiring perfect forward secrecy must exchange keys through mechanisms that provide such assurance, but may use Kerberos for authentication of the encrypted channel established through such other means.
Kerberos协议的基本形式并没有为通信提供完美的前向保密性。如果窃听者记录了通信量，则如果随后发现了用户、应用程序服务器或KDC的密钥，则可以解密使用KRB_PRIV消息加密的消息，或使用Kerberos交换密钥下的应用程序特定加密加密加密的消息。这是因为当通过网络传输时，用于加密此类消息的会话密钥在应用服务器的密钥中加密。当它在KRB_TGS_REP消息中返回给用户时，它也会在用户的TGT会话密钥下进行加密。来自TGT的会话密钥在KRB_AS_REP消息中发送给用户，该消息在用户的密钥中加密，并嵌入在TGT中，TGT在KDC的密钥中加密。需要完全前向保密的应用程序必须通过提供此类保证的机制交换密钥，但也可以使用Kerberos对通过此类其他方式建立的加密通道进行身份验证。
This document is a revision to RFC 1510 which was co-authored with John Kohl. The specification of the Kerberos protocol described in this document is the result of many years of effort. Over this period, many individuals have contributed to the definition of the protocol and to the writing of the specification. Unfortunately, it is not possible to list all contributors as authors of this document, though there are many not listed who are authors in spirit, including those who contributed text for parts of some sections, who contributed to the design of parts of the protocol, and who contributed significantly to the discussion of the protocol in the IETF common authentication technology (CAT) and Kerberos working groups.
本文件是对与John Kohl合著的RFC 1510的修订。本文档中描述的Kerberos协议规范是多年努力的结果。在此期间，许多个人为协议的定义和规范的编写做出了贡献。不幸的是，不可能将所有撰稿人都列为本文件的作者，尽管还有许多人没有被列为精神上的作者，包括那些为某些章节的部分撰稿的人，他们为议定书部分的设计做出了贡献，世卫组织在IETF公共认证技术（CAT）和Kerberos工作组中对协议的讨论做出了重大贡献。
Among those contributing to the development and specification of Kerberos were Jeffrey Altman, John Brezak, Marc Colan, Johan Danielsson, Don Davis, Doug Engert, Dan Geer, Paul Hill, John Kohl, Marc Horowitz, Matt Hur, Jeffrey Hutzelman, Paul Leach, John Linn, Ari Medvinsky, Sasha Medvinsky, Steve Miller, Jon Rochlis, Jerome Saltzer, Jeffrey Schiller, Jennifer Steiner, Ralph Swick, Mike Swift, Jonathan Trostle, Theodore Ts'o, Brian Tung, Jacques Vidrine, Assar Westerlund, and Nicolas Williams. Many other members of MIT Project Athena, the MIT networking group, and the Kerberos and CAT working groups of the IETF contributed but are not listed.
对Kerberos的开发和规范做出贡献的有Jeffrey Altman、John Brezak、Marc Colan、Johan Danielsson、Don Davis、Doug Engert、Dan Geer、Paul Hill、John Kohl、Marc Horowitz、Matt Hur、Jeffrey Hutzelman、Paul Leach、John Linn、Ari Medvinsky、Sasha Medvinsky、Steve Miller、Jon Rochlis、Jerome Saltzer、，杰弗里·席勒、詹妮弗·施泰纳、拉尔夫·斯威克、迈克·斯威夫特、乔纳森·特罗斯特尔、西奥多·曹、布赖恩·东、雅克·维德林、阿萨尔·韦斯特隆德和尼古拉斯·威廉姆斯。麻省理工学院雅典娜项目、麻省理工学院网络小组以及IETF的Kerberos和CAT工作组的许多其他成员也参与了这项工作，但没有列出。
A. ASN.1 module
A.ASN.1模块
KerberosV5Spec2 {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) krb5spec2(2)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
KerberosV5Spec2 {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) krb5spec2(2)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
-- OID arc for KerberosV5
--
-- This OID may be used to identify Kerberos protocol messages
-- encapsulated in other protocols.
--
-- This OID also designates the OID arc for KerberosV5-related OIDs.
--
-- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID.
id-krb5 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2)
}
-- OID arc for KerberosV5
--
-- This OID may be used to identify Kerberos protocol messages
-- encapsulated in other protocols.
--
-- This OID also designates the OID arc for KerberosV5-related OIDs.
--
-- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its OID.
id-krb5 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2)
}
Int32 ::= INTEGER (-2147483648..2147483647)
-- signed values representable in 32 bits
Int32 ::= INTEGER (-2147483648..2147483647)
-- signed values representable in 32 bits
UInt32 ::= INTEGER (0..4294967295)
-- unsigned 32 bit values
UInt32 ::= INTEGER (0..4294967295)
-- unsigned 32 bit values
Microseconds ::= INTEGER (0..999999)
-- microseconds
Microseconds ::= INTEGER (0..999999)
-- microseconds
KerberosString ::= GeneralString (IA5String)
KerberosString ::= GeneralString (IA5String)
Realm ::= KerberosString
Realm ::= KerberosString
PrincipalName ::= SEQUENCE {
name-type [0] Int32,
name-string [1] SEQUENCE OF KerberosString
}
PrincipalName ::= SEQUENCE {
name-type [0] Int32,
name-string [1] SEQUENCE OF KerberosString
}
KerberosTime ::= GeneralizedTime -- with no fractional seconds
KerberosTime ::= GeneralizedTime -- with no fractional seconds
HostAddress ::= SEQUENCE {
addr-type [0] Int32,
address [1] OCTET STRING
}
HostAddress ::= SEQUENCE {
addr-type [0] Int32,
address [1] OCTET STRING
}
-- NOTE: HostAddresses is always used as an OPTIONAL field and
-- should not be empty.
HostAddresses -- NOTE: subtly different from rfc1510,
-- NOTE: HostAddresses is always used as an OPTIONAL field and
-- should not be empty.
HostAddresses -- NOTE: subtly different from rfc1510,
-- but has a value mapping and encodes the same
::= SEQUENCE OF HostAddress
-- but has a value mapping and encodes the same
::= SEQUENCE OF HostAddress
-- NOTE: AuthorizationData is always used as an OPTIONAL field and
-- should not be empty.
AuthorizationData ::= SEQUENCE OF SEQUENCE {
ad-type [0] Int32,
ad-data [1] OCTET STRING
}
-- NOTE: AuthorizationData is always used as an OPTIONAL field and
-- should not be empty.
AuthorizationData ::= SEQUENCE OF SEQUENCE {
ad-type [0] Int32,
ad-data [1] OCTET STRING
}
PA-DATA ::= SEQUENCE {
-- NOTE: first tag is [1], not [0]
padata-type [1] Int32,
padata-value [2] OCTET STRING -- might be encoded AP-REQ
}
PA-DATA ::= SEQUENCE {
-- NOTE: first tag is [1], not [0]
padata-type [1] Int32,
padata-value [2] OCTET STRING -- might be encoded AP-REQ
}
KerberosFlags ::= BIT STRING (SIZE (32..MAX))
-- minimum number of bits shall be sent,
-- but no fewer than 32
KerberosFlags ::= BIT STRING (SIZE (32..MAX))
-- minimum number of bits shall be sent,
-- but no fewer than 32
EncryptedData ::= SEQUENCE {
etype [0] Int32 -- EncryptionType --,
kvno [1] UInt32 OPTIONAL,
cipher [2] OCTET STRING -- ciphertext
}
EncryptedData ::= SEQUENCE {
etype [0] Int32 -- EncryptionType --,
kvno [1] UInt32 OPTIONAL,
cipher [2] OCTET STRING -- ciphertext
}
EncryptionKey ::= SEQUENCE {
keytype [0] Int32 -- actually encryption type --,
keyvalue [1] OCTET STRING
}
EncryptionKey ::= SEQUENCE {
keytype [0] Int32 -- actually encryption type --,
keyvalue [1] OCTET STRING
}
Checksum ::= SEQUENCE {
cksumtype [0] Int32,
checksum [1] OCTET STRING
}
Checksum ::= SEQUENCE {
cksumtype [0] Int32,
checksum [1] OCTET STRING
}
Ticket ::= [APPLICATION 1] SEQUENCE {
tkt-vno [0] INTEGER (5),
realm [1] Realm,
sname [2] PrincipalName,
enc-part [3] EncryptedData -- EncTicketPart
}
Ticket ::= [APPLICATION 1] SEQUENCE {
tkt-vno [0] INTEGER (5),
realm [1] Realm,
sname [2] PrincipalName,
enc-part [3] EncryptedData -- EncTicketPart
}
-- Encrypted part of ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
flags [0] TicketFlags,
key [1] EncryptionKey,
crealm [2] Realm,
-- Encrypted part of ticket
EncTicketPart ::= [APPLICATION 3] SEQUENCE {
flags [0] TicketFlags,
key [1] EncryptionKey,
crealm [2] Realm,
cname [3] PrincipalName, transited [4] TransitedEncoding, authtime [5] KerberosTime, starttime [6] KerberosTime OPTIONAL, endtime [7] KerberosTime, renew-till [8] KerberosTime OPTIONAL, caddr [9] HostAddresses OPTIONAL, authorization-data [10] AuthorizationData OPTIONAL }
cname[3]主名称、转换[4]转换编码、authtime[5]KerberosTime、starttime[6]KerberosTime可选、endtime[7]KerberosTime、续订至[8]KerberosTime可选、caddr[9]主机地址可选、授权数据[10]授权数据可选}
-- encoded Transited field
TransitedEncoding ::= SEQUENCE {
tr-type [0] Int32 -- must be registered --,
contents [1] OCTET STRING
}
-- encoded Transited field
TransitedEncoding ::= SEQUENCE {
tr-type [0] Int32 -- must be registered --,
contents [1] OCTET STRING
}
TicketFlags ::= KerberosFlags
-- reserved(0),
-- forwardable(1),
-- forwarded(2),
-- proxiable(3),
-- proxy(4),
-- may-postdate(5),
-- postdated(6),
-- invalid(7),
-- renewable(8),
-- initial(9),
-- pre-authent(10),
-- hw-authent(11),
-- the following are new since 1510
-- transited-policy-checked(12),
-- ok-as-delegate(13)
TicketFlags ::= KerberosFlags
-- reserved(0),
-- forwardable(1),
-- forwarded(2),
-- proxiable(3),
-- proxy(4),
-- may-postdate(5),
-- postdated(6),
-- invalid(7),
-- renewable(8),
-- initial(9),
-- pre-authent(10),
-- hw-authent(11),
-- the following are new since 1510
-- transited-policy-checked(12),
-- ok-as-delegate(13)
AS-REQ ::= [APPLICATION 10] KDC-REQ
AS-REQ ::= [APPLICATION 10] KDC-REQ
TGS-REQ ::= [APPLICATION 12] KDC-REQ
TGS-REQ ::= [APPLICATION 12] KDC-REQ
KDC-REQ ::= SEQUENCE {
-- NOTE: first tag is [1], not [0]
pvno [1] INTEGER (5) ,
msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --),
padata [3] SEQUENCE OF PA-DATA OPTIONAL
-- NOTE: not empty --,
req-body [4] KDC-REQ-BODY
}
KDC-REQ ::= SEQUENCE {
-- NOTE: first tag is [1], not [0]
pvno [1] INTEGER (5) ,
msg-type [2] INTEGER (10 -- AS -- | 12 -- TGS --),
padata [3] SEQUENCE OF PA-DATA OPTIONAL
-- NOTE: not empty --,
req-body [4] KDC-REQ-BODY
}
KDC-REQ-BODY ::= SEQUENCE {
kdc-options [0] KDCOptions,
KDC-REQ-BODY ::= SEQUENCE {
kdc-options [0] KDCOptions,
cname [1] PrincipalName OPTIONAL
-- Used only in AS-REQ --,
realm [2] Realm
-- Server's realm
-- Also client's in AS-REQ --,
sname [3] PrincipalName OPTIONAL,
from [4] KerberosTime OPTIONAL,
till [5] KerberosTime,
rtime [6] KerberosTime OPTIONAL,
nonce [7] UInt32,
etype [8] SEQUENCE OF Int32 -- EncryptionType
-- in preference order --,
addresses [9] HostAddresses OPTIONAL,
enc-authorization-data [10] EncryptedData OPTIONAL
-- AuthorizationData --,
additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
-- NOTE: not empty
}
cname [1] PrincipalName OPTIONAL
-- Used only in AS-REQ --,
realm [2] Realm
-- Server's realm
-- Also client's in AS-REQ --,
sname [3] PrincipalName OPTIONAL,
from [4] KerberosTime OPTIONAL,
till [5] KerberosTime,
rtime [6] KerberosTime OPTIONAL,
nonce [7] UInt32,
etype [8] SEQUENCE OF Int32 -- EncryptionType
-- in preference order --,
addresses [9] HostAddresses OPTIONAL,
enc-authorization-data [10] EncryptedData OPTIONAL
-- AuthorizationData --,
additional-tickets [11] SEQUENCE OF Ticket OPTIONAL
-- NOTE: not empty
}
KDCOptions ::= KerberosFlags
-- reserved(0),
-- forwardable(1),
-- forwarded(2),
-- proxiable(3),
-- proxy(4),
-- allow-postdate(5),
-- postdated(6),
-- unused7(7),
-- renewable(8),
-- unused9(9),
-- unused10(10),
-- opt-hardware-auth(11),
-- unused12(12),
-- unused13(13),
-- 15 is reserved for canonicalize
-- unused15(15),
-- 26 was unused in 1510
-- disable-transited-check(26),
--
-- renewable-ok(27),
-- enc-tkt-in-skey(28),
-- renew(30),
-- validate(31)
KDCOptions ::= KerberosFlags
-- reserved(0),
-- forwardable(1),
-- forwarded(2),
-- proxiable(3),
-- proxy(4),
-- allow-postdate(5),
-- postdated(6),
-- unused7(7),
-- renewable(8),
-- unused9(9),
-- unused10(10),
-- opt-hardware-auth(11),
-- unused12(12),
-- unused13(13),
-- 15 is reserved for canonicalize
-- unused15(15),
-- 26 was unused in 1510
-- disable-transited-check(26),
--
-- renewable-ok(27),
-- enc-tkt-in-skey(28),
-- renew(30),
-- validate(31)
AS-REP ::= [APPLICATION 11] KDC-REP
AS-REP ::= [APPLICATION 11] KDC-REP
TGS-REP ::= [APPLICATION 13] KDC-REP
TGS-REP ::= [APPLICATION 13] KDC-REP
KDC-REP ::= SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --),
padata [2] SEQUENCE OF PA-DATA OPTIONAL
-- NOTE: not empty --,
crealm [3] Realm,
cname [4] PrincipalName,
ticket [5] Ticket,
enc-part [6] EncryptedData
-- EncASRepPart or EncTGSRepPart,
-- as appropriate
}
KDC-REP ::= SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (11 -- AS -- | 13 -- TGS --),
padata [2] SEQUENCE OF PA-DATA OPTIONAL
-- NOTE: not empty --,
crealm [3] Realm,
cname [4] PrincipalName,
ticket [5] Ticket,
enc-part [6] EncryptedData
-- EncASRepPart or EncTGSRepPart,
-- as appropriate
}
EncASRepPart ::= [APPLICATION 25] EncKDCRepPart
EncASRepPart ::= [APPLICATION 25] EncKDCRepPart
EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
EncTGSRepPart ::= [APPLICATION 26] EncKDCRepPart
EncKDCRepPart ::= SEQUENCE {
key [0] EncryptionKey,
last-req [1] LastReq,
nonce [2] UInt32,
key-expiration [3] KerberosTime OPTIONAL,
flags [4] TicketFlags,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
srealm [9] Realm,
sname [10] PrincipalName,
caddr [11] HostAddresses OPTIONAL
}
EncKDCRepPart ::= SEQUENCE {
key [0] EncryptionKey,
last-req [1] LastReq,
nonce [2] UInt32,
key-expiration [3] KerberosTime OPTIONAL,
flags [4] TicketFlags,
authtime [5] KerberosTime,
starttime [6] KerberosTime OPTIONAL,
endtime [7] KerberosTime,
renew-till [8] KerberosTime OPTIONAL,
srealm [9] Realm,
sname [10] PrincipalName,
caddr [11] HostAddresses OPTIONAL
}
LastReq ::= SEQUENCE OF SEQUENCE {
lr-type [0] Int32,
lr-value [1] KerberosTime
}
LastReq ::= SEQUENCE OF SEQUENCE {
lr-type [0] Int32,
lr-value [1] KerberosTime
}
AP-REQ ::= [APPLICATION 14] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (14),
ap-options [2] APOptions,
ticket [3] Ticket,
authenticator [4] EncryptedData -- Authenticator
}
AP-REQ ::= [APPLICATION 14] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (14),
ap-options [2] APOptions,
ticket [3] Ticket,
authenticator [4] EncryptedData -- Authenticator
}
APOptions ::= KerberosFlags
-- reserved(0),
-- use-session-key(1),
APOptions ::= KerberosFlags
-- reserved(0),
-- use-session-key(1),
-- mutual-required(2)
--相互要求（2）
-- Unencrypted authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno [0] INTEGER (5),
crealm [1] Realm,
cname [2] PrincipalName,
cksum [3] Checksum OPTIONAL,
cusec [4] Microseconds,
ctime [5] KerberosTime,
subkey [6] EncryptionKey OPTIONAL,
seq-number [7] UInt32 OPTIONAL,
authorization-data [8] AuthorizationData OPTIONAL
}
-- Unencrypted authenticator
Authenticator ::= [APPLICATION 2] SEQUENCE {
authenticator-vno [0] INTEGER (5),
crealm [1] Realm,
cname [2] PrincipalName,
cksum [3] Checksum OPTIONAL,
cusec [4] Microseconds,
ctime [5] KerberosTime,
subkey [6] EncryptionKey OPTIONAL,
seq-number [7] UInt32 OPTIONAL,
authorization-data [8] AuthorizationData OPTIONAL
}
AP-REP ::= [APPLICATION 15] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (15),
enc-part [2] EncryptedData -- EncAPRepPart
}
AP-REP ::= [APPLICATION 15] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (15),
enc-part [2] EncryptedData -- EncAPRepPart
}
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
ctime [0] KerberosTime,
cusec [1] Microseconds,
subkey [2] EncryptionKey OPTIONAL,
seq-number [3] UInt32 OPTIONAL
}
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
ctime [0] KerberosTime,
cusec [1] Microseconds,
subkey [2] EncryptionKey OPTIONAL,
seq-number [3] UInt32 OPTIONAL
}
KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (20),
safe-body [2] KRB-SAFE-BODY,
cksum [3] Checksum
}
KRB-SAFE ::= [APPLICATION 20] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (20),
safe-body [2] KRB-SAFE-BODY,
cksum [3] Checksum
}
KRB-SAFE-BODY ::= SEQUENCE {
user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL,
seq-number [3] UInt32 OPTIONAL,
s-address [4] HostAddress,
r-address [5] HostAddress OPTIONAL
}
KRB-SAFE-BODY ::= SEQUENCE {
user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL,
seq-number [3] UInt32 OPTIONAL,
s-address [4] HostAddress,
r-address [5] HostAddress OPTIONAL
}
KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (21),
-- NOTE: there is no [2] tag
KRB-PRIV ::= [APPLICATION 21] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (21),
-- NOTE: there is no [2] tag
enc-part [3] EncryptedData -- EncKrbPrivPart }
enc part[3]EncryptedData--EncKrbPrivPart}
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL,
seq-number [3] UInt32 OPTIONAL,
s-address [4] HostAddress -- sender's addr --,
r-address [5] HostAddress OPTIONAL -- recip's addr
}
EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE {
user-data [0] OCTET STRING,
timestamp [1] KerberosTime OPTIONAL,
usec [2] Microseconds OPTIONAL,
seq-number [3] UInt32 OPTIONAL,
s-address [4] HostAddress -- sender's addr --,
r-address [5] HostAddress OPTIONAL -- recip's addr
}
KRB-CRED ::= [APPLICATION 22] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (22),
tickets [2] SEQUENCE OF Ticket,
enc-part [3] EncryptedData -- EncKrbCredPart
}
KRB-CRED ::= [APPLICATION 22] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (22),
tickets [2] SEQUENCE OF Ticket,
enc-part [3] EncryptedData -- EncKrbCredPart
}
EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
ticket-info [0] SEQUENCE OF KrbCredInfo,
nonce [1] UInt32 OPTIONAL,
timestamp [2] KerberosTime OPTIONAL,
usec [3] Microseconds OPTIONAL,
s-address [4] HostAddress OPTIONAL,
r-address [5] HostAddress OPTIONAL
}
EncKrbCredPart ::= [APPLICATION 29] SEQUENCE {
ticket-info [0] SEQUENCE OF KrbCredInfo,
nonce [1] UInt32 OPTIONAL,
timestamp [2] KerberosTime OPTIONAL,
usec [3] Microseconds OPTIONAL,
s-address [4] HostAddress OPTIONAL,
r-address [5] HostAddress OPTIONAL
}
KrbCredInfo ::= SEQUENCE {
key [0] EncryptionKey,
prealm [1] Realm OPTIONAL,
pname [2] PrincipalName OPTIONAL,
flags [3] TicketFlags OPTIONAL,
authtime [4] KerberosTime OPTIONAL,
starttime [5] KerberosTime OPTIONAL,
endtime [6] KerberosTime OPTIONAL,
renew-till [7] KerberosTime OPTIONAL,
srealm [8] Realm OPTIONAL,
sname [9] PrincipalName OPTIONAL,
caddr [10] HostAddresses OPTIONAL
}
KrbCredInfo ::= SEQUENCE {
key [0] EncryptionKey,
prealm [1] Realm OPTIONAL,
pname [2] PrincipalName OPTIONAL,
flags [3] TicketFlags OPTIONAL,
authtime [4] KerberosTime OPTIONAL,
starttime [5] KerberosTime OPTIONAL,
endtime [6] KerberosTime OPTIONAL,
renew-till [7] KerberosTime OPTIONAL,
srealm [8] Realm OPTIONAL,
sname [9] PrincipalName OPTIONAL,
caddr [10] HostAddresses OPTIONAL
}
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (30),
ctime [2] KerberosTime OPTIONAL,
cusec [3] Microseconds OPTIONAL,
stime [4] KerberosTime,
KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (30),
ctime [2] KerberosTime OPTIONAL,
cusec [3] Microseconds OPTIONAL,
stime [4] KerberosTime,
susec [5] Microseconds, error-code [6] Int32, crealm [7] Realm OPTIONAL, cname [8] PrincipalName OPTIONAL, realm [9] Realm -- service realm --, sname [10] PrincipalName -- service name --, e-text [11] KerberosString OPTIONAL, e-data [12] OCTET STRING OPTIONAL }
susec[5]微秒，错误代码[6]Int32，crealm[7]领域可选，cname[8]PrincipalName可选，领域[9]领域--服务领域--，sname[10]PrincipalName--服务名称--，电子文本[11]KerberosString可选，电子数据[12]八位字符串可选}
METHOD-DATA ::= SEQUENCE OF PA-DATA
METHOD-DATA ::= SEQUENCE OF PA-DATA
TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
data-type [0] Int32,
data-value [1] OCTET STRING OPTIONAL
}
TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
data-type [0] Int32,
data-value [1] OCTET STRING OPTIONAL
}
-- preauth stuff follows
--预授权内容如下
PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC
PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC
PA-ENC-TS-ENC ::= SEQUENCE {
patimestamp [0] KerberosTime -- client's time --,
pausec [1] Microseconds OPTIONAL
}
PA-ENC-TS-ENC ::= SEQUENCE {
patimestamp [0] KerberosTime -- client's time --,
pausec [1] Microseconds OPTIONAL
}
ETYPE-INFO-ENTRY ::= SEQUENCE {
etype [0] Int32,
salt [1] OCTET STRING OPTIONAL
}
ETYPE-INFO-ENTRY ::= SEQUENCE {
etype [0] Int32,
salt [1] OCTET STRING OPTIONAL
}
ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY
ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY
ETYPE-INFO2-ENTRY ::= SEQUENCE {
etype [0] Int32,
salt [1] KerberosString OPTIONAL,
s2kparams [2] OCTET STRING OPTIONAL
}
ETYPE-INFO2-ENTRY ::= SEQUENCE {
etype [0] Int32,
salt [1] KerberosString OPTIONAL,
s2kparams [2] OCTET STRING OPTIONAL
}
ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY
ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY
AD-IF-RELEVANT ::= AuthorizationData
AD-IF-RELEVANT ::= AuthorizationData
AD-KDCIssued ::= SEQUENCE {
ad-checksum [0] Checksum,
i-realm [1] Realm OPTIONAL,
i-sname [2] PrincipalName OPTIONAL,
elements [3] AuthorizationData
AD-KDCIssued ::= SEQUENCE {
ad-checksum [0] Checksum,
i-realm [1] Realm OPTIONAL,
i-sname [2] PrincipalName OPTIONAL,
elements [3] AuthorizationData
}
}
AD-AND-OR ::= SEQUENCE {
condition-count [0] Int32,
elements [1] AuthorizationData
}
AD-AND-OR ::= SEQUENCE {
condition-count [0] Int32,
elements [1] AuthorizationData
}
AD-MANDATORY-FOR-KDC ::= AuthorizationData
AD-MANDATORY-FOR-KDC ::= AuthorizationData
END
终止
B. Changes since RFC 1510
B.自RFC 1510以来的变化
This document replaces RFC 1510 and clarifies specification of items that were not completely specified. Where changes to recommended implementation choices were made, or where new options were added, those changes are described within the document and listed in this section. More significantly, "Specification 2" in Section 8 changes the required encryption and checksum methods to bring them in line with the best current practices and to deprecate methods that are no longer considered sufficiently strong.
本文件取代RFC 1510，并澄清了未完全规定的项目规范。如果对建议的实施选项进行了更改，或者添加了新选项，这些更改将在文档中描述并在本节中列出。更重要的是，第8节中的“规范2”更改了所需的加密和校验和方法，使其符合当前最佳实践，并反对不再认为足够强大的方法。
Discussion was added to Section 1 regarding the ability to rely on the KDC to check the transited field, and on the inclusion of a flag in a ticket indicating that this check has occurred. This is a new capability not present in RFC 1510. Pre-existing implementations may ignore or not set this flag without negative security implications.
在第1节中增加了关于依赖KDC检查传输场的能力的讨论，以及关于在记录单中包含一个标志以表明已进行了该检查的讨论。这是RFC 1510中不存在的新功能。预先存在的实现可能会忽略或不设置此标志，而不会产生负面的安全影响。
The definition of the secret key says that in the case of a user the key may be derived from a password. In RFC 1510, it said that the key was derived from the password. This change was made to accommodate situations where the user key might be stored on a smart-card, or otherwise obtained independently of a password.
密钥的定义是，对于用户来说，密钥可能来自密码。在RFC1510中，它说密钥是从密码派生的。进行此更改是为了适应用户密钥可能存储在智能卡上或以其他方式独立于密码获取的情况。
The introduction mentions the use of public key cryptography for initial authentication in Kerberos by reference. RFC 1510 did not include such a reference.
引言中提到了在Kerberos中通过引用使用公钥加密进行初始身份验证。RFC 1510未包含此类参考。
Section 1.3 was added to explain that while Kerberos provides authentication of a named principal, it is still the responsibility of the application to ensure that the authenticated name is the entity with which the application wishes to communicate.
添加第1.3节是为了解释，虽然Kerberos提供了命名主体的身份验证，但应用程序仍有责任确保经过身份验证的名称是应用程序希望与之通信的实体。
Discussion of extensibility has been added to the introduction.
介绍中增加了对可扩展性的讨论。
Discussion of how extensibility affects ticket flags and KDC options was added to the introduction of Section 2. No changes were made to existing options and flags specified in RFC 1510, though some of the
在第2节的介绍中增加了关于扩展性如何影响票证标志和KDC选项的讨论。未对RFC 1510中指定的现有选项和标志进行任何更改，尽管
sections in the specification were renumbered, and text was revised to make the description and intent of existing options clearer, especially with respect to the ENC-TKT-IN-SKEY option (now section 2.9.2) which is used for user-to-user authentication. The new option and ticket flag transited policy checking (Section 2.7) was added.
规范中的章节重新编号，并对文本进行修订，以使现有选项的描述和意图更加清晰，特别是关于用于用户对用户身份验证的ENC-TKT-in-SKEY选项（现为第2.9.2节）。增加了新的选项和票证标志转换策略检查（第2.7节）。
A warning regarding generation of session keys for application use was added to Section 3, urging the inclusion of key entropy from the KDC generated session key in the ticket. An example regarding use of the sub-session key was added to Section 3.2.6. Descriptions of the pa-etype-info, pa-etype-info2, and pa-pw-salt pre-authentication data items were added. The recommendation for use of pre-authentication was changed from "MAY" to "SHOULD" and a note was added regarding known plaintext attacks.
第3节中增加了一条关于生成应用程序使用的会话密钥的警告，敦促将KDC生成的会话密钥中的密钥熵包含在票据中。第3.2.6节增加了一个关于使用子会话密钥的示例。添加了pa-etype-info、pa-etype-info2和pa-pw-salt预认证数据项的说明。使用预认证的建议从“可能”改为“应该”，并添加了关于已知明文攻击的说明。
In RFC 1510, Section 4 described the database in the KDC. This discussion was not necessary for interoperability and unnecessarily constrained implementation. The old Section 4 was removed.
在RFC1510中，第4节描述了KDC中的数据库。这种讨论对于互操作性和不必要的限制实现是不必要的。旧的第4节被删除。
The current Section 4 was formerly Section 6 on encryption and checksum specifications. The major part of this section was brought up to date to support new encryption methods, and moved to a separate document. Those few remaining aspects of the encryption and checksum specification specific to Kerberos are now specified in Section 4.
当前的第4节以前是关于加密和校验和规范的第6节。本节的主要部分更新为最新版本，以支持新的加密方法，并转移到单独的文档中。第4节现在指定了Kerberos特有的加密和校验和规范的其余几个方面。
Significant changes were made to the layout of Section 5 to clarify the correct behavior for optional fields. Many of these changes were made necessary because of improper ASN.1 description in the original Kerberos specification which left the correct behavior underspecified. Additionally, the wording in this section was tightened wherever possible to ensure that implementations conforming to this specification will be extensible with the addition of new fields in future specifications.
对第5节的布局进行了重大更改，以澄清可选字段的正确行为。由于原始Kerberos规范中对ASN.1的描述不正确，导致正确的行为未被指定，因此许多更改都是必要的。此外，本节中的措辞尽可能收紧，以确保符合本规范的实施将随着未来规范中新字段的添加而扩展。
Text was added describing time_t=0 issues in the ASN.1. Text was also added, clarifying issues with implementations treating omitted optional integers as zero. Text was added clarifying behavior for optional SEQUENCE or SEQUENCE OF that may be empty. Discussion was added regarding sequence numbers and behavior of some implementations, including "zero" behavior and negative numbers. A compatibility note was added regarding the unconditional sending of EncTGSRepPart regardless of the enclosing reply type. Minor changes were made to the description of the HostAddresses type. Integer types were constrained. KerberosString was defined as a (significantly) constrained GeneralString. KerberosFlags was defined to reflect existing implementation behavior that departs from the
添加了描述ASN.1中时间\u t=0问题的文本。还添加了文本，澄清了将省略的可选整数视为零的实现问题。添加了文本，以澄清可选序列或可能为空的序列的行为。增加了关于序列号和一些实现行为的讨论，包括“零”行为和负数。添加了关于无条件发送enctgsrepart的兼容性说明，无论随附的回复类型如何。对HostAddresses类型的描述进行了细微更改。整数类型受到约束。KerberosString被定义为（显著）受约束的通用字符串。KerberosFlags的定义是为了反映与
definition in RFC 1510. The transited-policy-checked(12) and the ok-as-delegate(13) ticket flags were added. The disable-transited-check(26) KDC option was added.
RFC 1510中的定义。已添加已检查的传输策略（12）和确定为代理（13）票证标志。添加了禁用过渡检查（26）KDC选项。
Descriptions of commonly implemented PA-DATA were added to Section 5. The description of KRB-SAFE has been updated to note the existing implementation behavior of double-encoding.
第5节增加了对常用PA数据的描述。KRB-SAFE的描述已经更新，以注意双重编码的现有实现行为。
There were two definitions of METHOD-DATA in RFC 1510. The second one, intended for use with KRB_AP_ERR_METHOD was removed leaving the SEQUENCE OF PA-DATA definition.
RFC 1510中有两种方法数据定义。第二个用于KRB_AP_ERR_方法的方法被删除，留下PA数据定义序列。
Section 7, naming constraints, from RFC 1510 was moved to Section 6.
第7节，命名限制，从RFC 1510移至第6节。
Words were added describing the convention that domain-based realm names for newly-created realms should be specified as uppercase. This recommendation does not make lowercase realm names illegal. Words were added highlighting that the slash-separated components in the X.500 style of realm names is consistent with existing RFC 1510 based implementations, but that it conflicts with the general recommendation of X.500 name representation specified in RFC 2253.
添加了描述新创建领域的基于域的域名应指定为大写的约定的文字。此建议不会使小写域名非法。添加了强调X.500风格域名中斜杠分隔的组件与现有基于RFC 1510的实现是一致的，但它与RFC 2253中指定的X.500名称表示的一般建议相冲突的文字。
Section 8, network transport, constants and defined values, from RFC 1510 was moved to Section 7. Since RFC 1510, the definition of the TCP transport for Kerberos messages was added, and the encryption and checksum number assignments have been moved into a separate document.
第8节，网络传输，常数和定义值，从RFC 1510移至第7节。自RFC 1510以来，添加了Kerberos消息的TCP传输定义，并将加密和校验和编号分配移动到单独的文档中。
"Specification 2" in Section 8 of the current document changes the required encryption and checksum methods to bring them in line with the best current practices and to deprecate methods that are no longer considered sufficiently strong.
当前文档第8节中的“规范2”更改了所需的加密和校验和方法，使其符合当前最佳实践，并反对不再认为足够强大的方法。
Two new sections, on IANA considerations and security considerations were added.
增加了两个关于IANA注意事项和安全注意事项的新章节。
The pseudo-code has been removed from the appendix. The pseudo-code was sometimes misinterpreted to limit implementation choices and in RFC 1510, it was not always consistent with the words in the specification. Effort was made to clear up any ambiguities in the specification, rather than to rely on the pseudo-code.
伪代码已从附录中删除。伪代码有时被误解以限制实现选择，在RFC1510中，它并不总是与规范中的文字一致。我们努力消除规范中的任何歧义，而不是依赖伪代码。
An appendix was added containing the complete ASN.1 module drawn from the discussion in Section 5 of the current document.
增加了一个附录，其中包含从当前文件第5节的讨论中得出的完整ASN.1模块。
END NOTES
尾注
(*TM) Project Athena, Athena, and Kerberos are trademarks of the Massachusetts Institute of Technology (MIT).
（*TM）项目Athena、Athena和Kerberos是麻省理工学院（MIT）的商标。
Normative References
规范性引用文件
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[RFC3961]Raeburn，K.，“Kerberos 5的加密和校验和规范”，RFC 3961，2005年2月。
[RFC3962] Raeburn, K., "Advanced Encryption Standard (AES) Encryption for Kerberos 5", RFC 3962, February 2005.
[RFC3962]Raeburn，K.，“Kerberos 5的高级加密标准（AES）加密”，RFC 3962，2005年2月。
[ISO-646/ECMA-6] International Organization for Standardization, "7-bit Coded Character Set for Information Interchange", ISO/IEC 646:1991.
[ISO-646/ECMA-6]国际标准化组织，“信息交换用7位编码字符集”，ISO/IEC 646:1991。
[ISO-2022/ECMA-35] International Organization for Standardization, "Character code structure and extension techniques", ISO/IEC 2022:1994.
[ISO-2022/ECMA-35]国际标准化组织，“字符代码结构和扩展技术”，ISO/IEC 2022:1994。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC2253] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[RFC2253]Wahl，M.，Kille，S.，和T.Howes，“轻量级目录访问协议（v3）：可分辨名称的UTF-8字符串表示”，RFC 2253，1997年12月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513]Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[X680] Abstract Syntax Notation One (ASN.1): Specification of Basic Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC International Standard 8824-1:1998.
[X680]抽象语法符号一（ASN.1）：基本符号规范，ITU-T建议X.680（1997）| ISO/IEC国际标准8824-1:1998。
[X690] ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International Standard 8825-1:1998.
[X690]ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）的规范，ITU-T建议X.690（1997）| ISO/IEC国际标准8825-1:1998。
Informative References
资料性引用
[ISO-8859] International Organization for Standardization, "8-bit Single-byte Coded Graphic Character Sets -- Latin Alphabet", ISO/IEC 8859.
[ISO-8859]国际标准化组织，“8位单字节编码图形字符集——拉丁字母”，ISO/IEC 8859。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964]Linn，J.，“Kerberos版本5 GSS-API机制”，RFC19641996年6月。
[DGT96] Don Davis, Daniel Geer, and Theodore Ts'o, "Kerberos With Clocks Adrift: History, Protocols, and Implementation", USENIX Computing Systems 9:1, January 1996.
[DGT96]Don Davis、Daniel Geer和Theodore T'o，“时钟漂移的Kerberos：历史、协议和实现”，USENIX Computing Systems 9:11996年1月。
[DS81] Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key Distribution Protocols," Communications of the ACM, Vol. 24 (8), p. 533- 536, August 1981.
[DS81]Dorothy E.Denning和Giovanni Maria Sacco，“关键分发协议中的时间戳”，ACM通信，第24（8）卷，第页。1981年8月533-536日。
[KNT94] John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The Evolution of the Kerberos Authentication System". In Distributed Open Systems, pages 78-94. IEEE Computer Society Press, 1994.
[KNT94]John T.Kohl、B.Clifford Neuman和Theodore Y.Ts'o，“Kerberos身份验证系统的演变”。在分布式开放系统中，第78-94页。IEEE计算机学会出版社，1994年。
[MNSS87] S. P. Miller, B. C. Neuman, J. I. Schiller, and J. H. Saltzer, Section E.2.1: Kerberos Authentication and Authorization System, M.I.T. Project Athena, Cambridge, Massachusetts, December 21, 1987.
[MNSS87]S.P.Miller、B.C.Neuman、J.I.Schiller和J.H.Saltzer，第E.2.1节：Kerberos身份验证和授权系统，M.I.T.项目雅典娜，马萨诸塞州剑桥，1987年12月21日。
[NS78] Roger M. Needham and Michael D. Schroeder, "Using Encryption for Authentication in Large Networks of Computers," Communications of the ACM, Vol. 21 (12), pp. 993-999, December 1978.
[NS78]Roger M.Needham和Michael D.Schroeder，“在大型计算机网络中使用加密进行身份验证”，《ACM通信》，第21卷（12），第993-999页，1978年12月。
[Neu93] B. Clifford Neuman, "Proxy-Based Authorization and Accounting for Distributed Systems," in Proceedings of the 13th International Conference on Distributed Computing Systems, Pittsburgh, PA, May 1993.
[Neu93]B.Clifford Neuman，“分布式系统基于代理的授权和会计”，载于第13届分布式计算系统国际会议记录，宾夕法尼亚州匹兹堡，1993年5月。
[NT94] B. Clifford Neuman and Theodore Y. Ts'o, "An Authentication Service for Computer Networks," IEEE Communications Magazine, Vol. 32 (9), p. 33- 38, September 1994.
[NT94]B.Clifford Neuman和Theodore Y.Ts'o，“计算机网络的身份验证服务”，IEEE通信杂志，第32卷（9），p。1994年9月33日至38日。
[Pat92] J. Pato, Using Pre-Authentication to Avoid Password Guessing Attacks, Open Software Foundation DCE Request for Comments 26 (December 1992.
[PAT92] J.PATO，使用预认证来避免口令猜测攻击，打开软件基础DCE请求评论26（1992年12月）。
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[RFC1510]Kohl，J.和C.Neuman，“Kerberos网络身份验证服务（V5）”，RFC15101993年9月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]伊斯特莱克，D.，3，席勒，J.和S.克罗克，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[SNS88] J. G. Steiner, B. C. Neuman, and J. I. Schiller, "Kerberos: An Authentication Service for Open Network Systems," p. 191-202, Usenix Conference Proceedings, Dallas, Texas, February 1988.
[SNS88]J.G.Steiner、B.C.Neuman和J.I.Schiller，“Kerberos：开放网络系统的身份验证服务”，第。191-202，Usenix会议记录，德克萨斯州达拉斯，1988年2月。
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005.
[RFC4121]Zhu，L.，Jaganathan，K.，和S.Hartman，“Kerberos版本5通用安全服务应用程序接口（GSS-API）机制：版本2”，RFC 41212005年7月。
Authors' Addresses
作者地址
Clifford Neuman Information Sciences Institute University of Southern California 4676 Admiralty Way Marina del Rey, CA 90292, USA
克利福德纽曼信息科学研究所南加州大学4676海军陆路码头德雷雷，CA 90292，美国
EMail: bcn@isi.edu
EMail: bcn@isi.edu
Tom Yu Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139, USA
Tom Yu麻省理工学院美国马萨诸塞州剑桥马萨诸塞大道77号，邮编02139
EMail: tlyu@mit.edu
EMail: tlyu@mit.edu
Sam Hartman Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139, USA
Sam Hartman麻省理工学院马萨诸塞大道77号剑桥，马萨诸塞州02139
EMail: hartmans-ietf@mit.edu
EMail: hartmans-ietf@mit.edu
Kenneth Raeburn Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge, MA 02139, USA
肯尼思·雷伯恩麻省理工学院美国马萨诸塞州剑桥马萨诸塞大道77号，邮编：02139
EMail: raeburn@mit.edu
EMail: raeburn@mit.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。