RFC 6113
A Generalized Framework for Kerberos Pre-Authentication
6. Assigned Constants
The pre-authentication framework and FAST involve using a number of Kerberos protocol constants. This section lists protocol constants first introduced in this specification drawn from registries not managed by IANA. Many of these registries would best be managed by IANA; that is a known issue that is out of scope for this document. The constants described in this section have been accounted for and will appear in the next revision of the Kerberos core specification or in a document creating IANA registries. Section 7 creates IANA registries for a different set of constants used by the extensions described in this document.6.1. New Errors
KDC_ERR_PREAUTH_EXPIRED 90 KDC_ERR_MORE_PREAUTH_DATA_REQUIRED 91 KDC_ERR_PREAUTH_BAD_AUTHENTICATION_SET 92 KDC_ERR_UNKNOWN_CRITICAL_FAST_OPTIONS 936.2. Key Usage Numbers
KEY_USAGE_FAST_REQ_CHKSUM 50 KEY_USAGE_FAST_ENC 51 KEY_USAGE_FAST_REP 52 KEY_USAGE_FAST_FINISHED 53 KEY_USAGE_ENC_CHALLENGE_CLIENT 54 KEY_USAGE_ENC_CHALLENGE_KDC 556.3. Authorization Data Elements
AD-authentication-strength 70 AD-fx-fast-armor 71 AD-fx-fast-used 726.4. New PA-DATA Types
PA-FX-COOKIE 133 PA-AUTHENTICATION-SET 134 PA-AUTH-SET-SELECTED 135 PA-FX-FAST 136 PA-FX-ERROR 137 PA-ENCRYPTED-CHALLENGE 138
7. IANA Considerations
This document creates a number of IANA registries. These registries are all located under Kerberos Parameters on http://www.iana.org. See [RFC5226] for descriptions of the registration policies used in this section.7.1. Pre-Authentication and Typed Data
RFC 4120 defines pre-authentication data, which can be included in a KDC request or response in order to authenticate the client or extend the protocol. In addition, it defines Typed-Data, which is an extension mechanism for errors. Both pre-authentication data and typed data are carried as a 32-bit signed integer along with an octet string. The encoding of typed data and pre-authentication data is slightly different. However, the types for pre-authentication data and typed-data are drawn from the same namespace. By convention, registrations starting with TD- are typed data and registrations starting with PA- are pre-authentication data. It is important that these data types be drawn from the same namespace, because some errors where it would be desirable to include typed data require the e-data field to be formatted as pre-authentication data. When Kerberos FAST is used, pre-authentication data encoding is always used. There is one apparently conflicting registration between typed data and pre-authentication data. PA-GET-FROM-TYPED-DATA and TD-PADATA are both assigned the value 22. However, this registration is simply a mechanism to include an element of the other encoding. The use of both should be deprecated. This document creates a registry for pre-authentication and typed data. The registration procedures are as follows. Expert review for pre-authentication mechanisms designed to authenticate users, KDCs, or establish the reply key. The expert first determines that the purpose of the method is to authenticate clients, KDCs, or to establish the reply key. If so, expert review is appropriate. The expert evaluates the security and interoperability of the specification. IETF review is required if the expert believes that the pre- authentication method is broader than these three areas. Pre- authentication methods that change the Kerberos state machine or otherwise make significant changes to the Kerberos protocol should be Standards Track RFCs. A concern that a particular method needs to be a Standards Track RFC may be raised as an objection during IETF review.
Several of the registrations indicated below were made at a time when
the Kerberos protocol was less mature and do not meet the current
requirements for this registry. These registrations are included in
order to accurately document what is known about the use of these
protocol code points and to avoid conflicts.
Type Value Reference
----------------------------------------------------------------------
PA-TGS-REQ 1 [RFC4120]
PA-ENC-TIMESTAMP 2 [RFC4120]
PA-PW-SALT 3 [RFC4120]
[reserved] 4 [RFC6113]
PA-ENC-UNIX-TIME 5 (deprecated) [RFC4120]
PA-SANDIA-SECUREID 6 [RFC4120]
PA-SESAME 7 [RFC4120]
PA-OSF-DCE 8 [RFC4120]
PA-CYBERSAFE-SECUREID 9 [RFC4120]
PA-AFS3-SALT 10 [RFC4120] [RFC3961]
PA-ETYPE-INFO 11 [RFC4120]
PA-SAM-CHALLENGE 12 [KRB-WG.SAM]
PA-SAM-RESPONSE 13 [KRB-WG.SAM]
PA-PK-AS-REQ_OLD 14 [PK-INIT-1999]
PA-PK-AS-REP_OLD 15 [PK-INIT-1999]
PA-PK-AS-REQ 16 [RFC4556]
PA-PK-AS-REP 17 [RFC4556]
PA-PK-OCSP-RESPONSE 18 [RFC4557]
PA-ETYPE-INFO2 19 [RFC4120]
PA-USE-SPECIFIED-KVNO 20 [RFC4120]
PA-SVR-REFERRAL-INFO 20 [REFERRALS]
PA-SAM-REDIRECT 21 [KRB-WG.SAM]
PA-GET-FROM-TYPED-DATA 22 (embedded in typed data) [RFC4120]
TD-PADATA 22 (embeds padata) [RFC4120]
PA-SAM-ETYPE-INFO 23 (sam/otp) [KRB-WG.SAM]
PA-ALT-PRINC 24 (crawdad@fnal.gov) [HW-AUTH]
PA-SERVER-REFERRAL 25 [REFERRALS]
PA-SAM-CHALLENGE2 30 (kenh@pobox.com) [KRB-WG.SAM]
PA-SAM-RESPONSE2 31 (kenh@pobox.com) [KRB-WG.SAM]
PA-EXTRA-TGT 41 Reserved extra TGT [RFC6113]
TD-PKINIT-CMS-CERTIFICATES 101 CertificateSet from CMS
TD-KRB-PRINCIPAL 102 PrincipalName
TD-KRB-REALM 103 Realm
TD-TRUSTED-CERTIFIERS 104 [RFC4556]
TD-CERTIFICATE-INDEX 105 [RFC4556]
TD-APP-DEFINED-ERROR 106 Application specific [RFC6113]
TD-REQ-NONCE 107 INTEGER [RFC6113]
TD-REQ-SEQ 108 INTEGER [RFC6113]
TD_DH_PARAMETERS 109 [RFC4556]
TD-CMS-DIGEST-ALGORITHMS 111 [ALG-AGILITY]
TD-CERT-DIGEST-ALGORITHMS 112 [ALG-AGILITY] PA-PAC-REQUEST 128 [MS-KILE] PA-FOR_USER 129 [MS-KILE] PA-FOR-X509-USER 130 [MS-KILE] PA-FOR-CHECK_DUPS 131 [MS-KILE] PA-AS-CHECKSUM 132 [MS-KILE] PA-FX-COOKIE 133 [RFC6113] PA-AUTHENTICATION-SET 134 [RFC6113] PA-AUTH-SET-SELECTED 135 [RFC6113] PA-FX-FAST 136 [RFC6113] PA-FX-ERROR 137 [RFC6113] PA-ENCRYPTED-CHALLENGE 138 [RFC6113] PA-OTP-CHALLENGE 141 (gareth.richards@rsa.com) [OTP-PREAUTH] PA-OTP-REQUEST 142 (gareth.richards@rsa.com) [OTP-PREAUTH] PA-OTP-CONFIRM 143 (gareth.richards@rsa.com) [OTP-PREAUTH] PA-OTP-PIN-CHANGE 144 (gareth.richards@rsa.com) [OTP-PREAUTH] PA-EPAK-AS-REQ 145 (sshock@gmail.com) [RFC6113] PA-EPAK-AS-REP 146 (sshock@gmail.com) [RFC6113] PA_PKINIT_KX 147 [RFC6112] PA_PKU2U_NAME 148 [PKU2U] PA-SUPPORTED-ETYPES 165 [MS-KILE] PA-EXTENDED_ERROR 166 [MS-KILE]7.2. Fast Armor Types
FAST armor types are defined in Section 5.4.1. A FAST armor type is a signed 32-bit integer. FAST armor types are assigned by standards action. Type Name Description ------------------------------------------------------------ 0 Reserved. 1 FX_FAST_ARMOR_AP_REQUEST Ticket armor using an ap-req.7.3. FAST Options
A FAST request includes a set of bit flags to indicate additional options. Bits 0-15 are critical; other bits are non-critical. Assigning bits greater than 31 may require special support in implementations. Assignment of FAST options requires standards action.
Type Name Description
-------------------------------------------------------------------
0 RESERVED Reserved for future expansion of this
field.
1 hide-client-names Requesting the KDC to hide client
names in the KDC response
16 kdc-follow-referrals Reserved.
8. Security Considerations
The kdc-referrals option in the Kerberos FAST padata requests the KDC
to act as the client to follow referrals. This can overload the KDC.
To limit the damages of denial of service using this option, KDCs MAY
restrict the number of simultaneous active requests with this option
for any given client principal.
Regarding the facilities provided by the Encrypted Challenge FAST
factor, the challenge key is derived from the client secrets and
because the client secrets are known only to the client and the KDC,
the verification of the EncryptedChallenge structure proves the
client's identity, the verification of the EncryptedChallenge
structure in the KDC reply proves that the expected KDC responded.
Therefore, the Encrypted Challenge FAST factor as a pre-
authentication mechanism offers the following facilities: Client
Authentication and KDC Authentication. There is no un-authenticated
cleartext introduced by the Encrypted Challenge FAST factor.
FAST provides an encrypted tunnel over which pre-authentication
conversations can take place. In addition, FAST optionally
authenticates the KDC to the client. It is the responsibility of
FAST factors to authenticate the client to the KDC. Care MUST be
taken to design FAST factors such that they are bound to the
conversation. If this is not done, a man-in-the-middle may be able
to cut&paste a FAST factor from one conversation to another. The
easiest way to do this is to bind each FAST factor to the armor key
that is guaranteed to be unique for each conversation.
The anonymous PKINIT mode for obtaining an armor ticket does not
always authenticate the KDC to the client before the conversation
begins. Tracking the KDC verified state guarantees that by the end
of the conversation, the client has authenticated the KDC. However,
FAST factor designers need to consider the implications of using
their factor when the KDC has not yet been authenticated. If this
proves problematic in an environment, then the particular FAST factor
should not be used with anonymous PKINIT.
Existing pre-authentication mechanisms are believed to be at least as
secure when used with FAST as they are when used outside of FAST.
One part of this security is making sure that when pre-authentication methods checksum the request, they checksum the inner request rather than the outer request. If the mechanism checksummed the outer request, a man-in-the-middle could observe it outside a FAST tunnel and then cut&paste it into a FAST exchange where the inner rather than outer request would be used to select attributes of the issued ticket. Such attacks would typically invalidate auditing information or create a situation where the client and KDC disagree about what ticket is issued. However, such attacks are unlikely to allow an attacker who would not be able to authenticate as a principal to do so. Even so, FAST is believed to defend against these attacks in existing legacy mechanism. However, since there is no standard for how legacy mechanisms bind the request to the pre-authentication or provide integrity protection, security analysis can be difficult. In some cases, FAST may significantly improve the integrity protection of legacy mechanisms. The security of the TGS exchange depends on authenticating the client to the KDC. In the AS exchange, this is done using pre- authentication data or FAST factors. In the TGS exchange, this is done by presenting a TGT and by using the session (or sub-session) key in constructing the request. Because FAST uses a request body in the inner request, encrypted in the armor key, rather than the request body in the outer request, it is critical that establishing the armor key be tied to the authentication of the client to the KDC. If this is not done, an attacker could manipulate the options requested in the TGS request, for example, requesting a ticket with different validity or addresses. The easiest way to bind the armor key to the authentication of the client to the KDC is for the armor key to depend on the sub-session key of the TGT. This is done with the implicit TGS armor supported by this specification. Future armor types designed for use with the TGS MUST either bind their armor keys to the TGT or provide another mechanism to authenticate the client to the KDC.9. Acknowledgements
Sam Hartman would like to thank the MIT Kerberos Consortium for its funding of his time on this project. Several suggestions from Jeffrey Hutzelman based on early revisions of this documents led to significant improvements of this document. The proposal to ask one KDC to chase down the referrals and return the final ticket is based on requirements in [CROSS]. Joel Weber had a proposal for a mechanism similar to FAST that created a protected tunnel for Kerberos pre-authentication.
Srinivas Cheruku and Greg Hudson provided valuable review comments.10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6112] Zhu, L., Leach, P., and S. Hartman "Anonymity Support for Kerberos", RFC 6112, April 2011.10.2. Informative References
[ALG-AGILITY] Astrand, L. and L. Zhu, "PK-INIT algorithm agility", Work in Progress, August 2008. [CROSS] Sakane, S., Zrelli, S., and M. Ishiyama , "Problem statement on the cross-realm operation of Kerberos in a specific system", Work in Progress, July 2007. [EKE] Bellovin, S. and M. Merritt, "Augmented Encrypted Key Exchange: A Password-Based Protocol Secure Against Dictionary Attacks and Password File Compromise, Proceedings of the 1st ACM Conference on Computer and Communications Security, ACM Press.", November 1993. [HW-AUTH] Crawford, M., "Passwordless Initial Authentication to Kerberos by Hardware Preauthentication", Work in Progress, October 2006. [IEEE1363.2] IEEE, "IEEE P1363.2: Password-Based Public-Key Cryptography", 2004.
[KRB-WG.SAM] Hornstein, K., Renard, K., Neuman, C., and G. Zorn, "Integrating Single-use Authentication Mechanisms with Kerberos", Work in Progress, July 2004. [MS-KILE] Microsoft, "Kerberos Protocol Extensions", <http:// msdn.microsoft.com/en-us/library/cc206927.aspx>. [OTP-PREAUTH] Richards, G., "OTP Pre-authentication", Work in Progress, February 2011. [PK-INIT-1999] Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky, S., Wray, J., and J. Trostle, "Public Key Cryptography for Initial Authentication in Kerberos", Work in Progress, July 1999. [PKU2U] Zhu, L., Altman, J., and N. Williams, "Public Key Cryptography Based User-to-User Authentication - (PKU2U)", Work in Progress, November 2008. [REFERRALS] Hartman, S., Ed., Raeburn, K., and L. Zhu, "Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm Referrals", Work in Progress, March 2011. [RFC4557] Zhu, L., Jaganathan, K., and N. Williams, "Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4557, June 2006.
Appendix A. Test Vectors for KRB-FX-CF2
This informative appendix presents test vectors for the KRB-FX-CF2 function. Test vectors are presented for several encryption types. In all cases, the first key (k1) is the result of string-to- key("key1", "key1", default_parameters) and the second key (k2) is the result of string-to-key("key2", "key2", default_parameters). Both keys are of the same enctype. The presented test vector is the hexadecimal encoding of the key produced by KRB-FX-CF2(k1, k2, "a", "b"). The peppers are one-octet ASCII strings. In performing interoperability testing, there was significant ambiguity surrounding [RFC3961] pseudo-random operations. These test vectors assume that the AES pseudo-random operation is aes-ecb(trunc128(sha-1(input))) where trunc128 truncates its input to 128 bits. The 3DES pseudo-random operation is assumed to be des3-cbc(trunc128(sha-1(input))). The DES pseudo-random operation is assumed to be des-cbc(md5(input)). As specified in RFC 4757, the RC4 pseudo-random operation is hmac-sha1(input). Interoperability testing also demonstrated ambiguity surrounding the DES random-to-key operation. The random-to-key operation is assumed to be distribute 56 bits into high-7-bits of 8 octets and generate parity. These test vectors were produced with revision 22359 of the MIT Kerberos sources. The AES 256 and AES 128 test vectors have been confirmed by multiple other implementors. The RC4 test vectors have been confirmed by one other implementor. The DES and triple DES test vectors have not been confirmed. aes 128 (enctype 17): 97df97e4b798b29eb31ed7280287a92a AES256 (enctype 18): 4d6ca4e629785c1f01baf55e2e548566 b9617ae3a96868c337cb93b5e72b1c7b DES (enctype 1): 43bae3738c9467e6 3DES (enctype 16): e58f9eb643862c13ad38e529313462a7f73e62834fe54a01 RC4 (enctype 23): 24d7f6b6bae4e5c00d2082c5ebab3672
Appendix B. ASN.1 Module
KerberosPreauthFramework { iso(1) identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) modules(4) preauth-framework(3) } DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum, Int32, EncryptedData, PA-ENC-TS-ENC, PA-DATA, KDC-REQ-BODY, Microseconds, KerberosFlags, UInt32 FROM KerberosV5Spec2 { iso(1) identified-organization(3) dod(6) internet(1) security(5) kerberosV5(2) modules(4) krb5spec2(2) }; -- as defined in RFC 4120. PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE { pa-type [0] Int32, -- same as padata-type. pa-hint [1] OCTET STRING OPTIONAL, pa-value [2] OCTET STRING OPTIONAL, ... } KrbFastArmor ::= SEQUENCE { armor-type [0] Int32, -- Type of the armor. armor-value [1] OCTET STRING, -- Value of the armor. ... } PA-FX-FAST-REQUEST ::= CHOICE { armored-data [0] KrbFastArmoredReq, ... } KrbFastArmoredReq ::= SEQUENCE { armor [0] KrbFastArmor OPTIONAL, -- Contains the armor that identifies the armor key. -- MUST be present in AS-REQ. req-checksum [1] Checksum, -- For AS, contains the checksum performed over the type -- KDC-REQ-BODY for the req-body field of the KDC-REQ -- structure; -- For TGS, contains the checksum performed over the type
-- AP-REQ in the PA-TGS-REQ padata.
-- The checksum key is the armor key, the checksum
-- type is the required checksum type for the enctype of
-- the armor key, and the key usage number is
-- KEY_USAGE_FAST_REQ_CHKSUM.
enc-fast-req [2] EncryptedData, -- KrbFastReq --
-- The encryption key is the armor key, and the key usage
-- number is KEY_USAGE_FAST_ENC.
...
}
KrbFastReq ::= SEQUENCE {
fast-options [0] FastOptions,
-- Additional options.
padata [1] SEQUENCE OF PA-DATA,
-- padata typed holes.
req-body [2] KDC-REQ-BODY,
-- Contains the KDC request body as defined in Section
-- 5.4.1 of [RFC4120].
-- This req-body field is preferred over the outer field
-- in the KDC request.
...
}
FastOptions ::= KerberosFlags
-- reserved(0),
-- hide-client-names(1),
-- kdc-follow-referrals(16)
PA-FX-FAST-REPLY ::= CHOICE {
armored-data [0] KrbFastArmoredRep,
...
}
KrbFastArmoredRep ::= SEQUENCE {
enc-fast-rep [0] EncryptedData, -- KrbFastResponse --
-- The encryption key is the armor key in the request, and
-- the key usage number is KEY_USAGE_FAST_REP.
...
}
KrbFastResponse ::= SEQUENCE {
padata [0] SEQUENCE OF PA-DATA,
-- padata typed holes.
strengthen-key [1] EncryptionKey OPTIONAL,
-- This, if present, strengthens the reply key for AS and
-- TGS. MUST be present for TGS
-- MUST be absent in KRB-ERROR.
finished [2] KrbFastFinished OPTIONAL,
-- Present in AS or TGS reply; absent otherwise.
nonce [3] UInt32,
-- Nonce from the client request.
...
}
KrbFastFinished ::= SEQUENCE {
timestamp [0] KerberosTime,
usec [1] Microseconds,
-- timestamp and usec represent the time on the KDC when
-- the reply was generated.
crealm [2] Realm,
cname [3] PrincipalName,
-- Contains the client realm and the client name.
ticket-checksum [4] Checksum,
-- checksum of the ticket in the KDC-REP using the armor
-- and the key usage is KEY_USAGE_FAST_FINISH.
-- The checksum type is the required checksum type
-- of the armor key.
...
}
EncryptedChallenge ::= EncryptedData
-- Encrypted PA-ENC-TS-ENC, encrypted in the challenge key
-- using key usage KEY_USAGE_ENC_CHALLENGE_CLIENT for the
-- client and KEY_USAGE_ENC_CHALLENGE_KDC for the KDC.
END
Authors' Addresses
Sam Hartman
Painless Security
EMail: hartmans-ietf@mit.edu
Larry Zhu
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
EMail: larry.zhu@microsoft.com