Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6113

A Generalized Framework for Kerberos Pre-Authentication

Pages: 48
Proposed Standard
Updates:  4120
Part 3 of 3 – Pages 37 to 48
First   Prev   None

Top   ToC   RFC6113 - Page 37   prevText

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 93

6.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 55

6.3. Authorization Data Elements

AD-authentication-strength 70 AD-fx-fast-armor 71 AD-fx-fast-used 72

6.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
Top   ToC   RFC6113 - Page 38

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.
Top   ToC   RFC6113 - Page 39
   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]
Top   ToC   RFC6113 - Page 40
 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.
Top   ToC   RFC6113 - Page 41
      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.
Top   ToC   RFC6113 - Page 42
   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.
Top   ToC   RFC6113 - Page 43
   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.
Top   ToC   RFC6113 - Page 44
   [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.
Top   ToC   RFC6113 - Page 45

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
Top   ToC   RFC6113 - Page 46

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
Top   ToC   RFC6113 - Page 47
              -- 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.
Top   ToC   RFC6113 - Page 48
          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