Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 6113


A Generalized Framework for Kerberos Pre-Authentication

Part 3 of 3, p. 37 to 48
Prev RFC Part


prevText      Top      Up      ToC       Page 37 
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

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      Up      ToC       Page 38 
7.  IANA Considerations

   This document creates a number of IANA registries.  These registries
   are all located under Kerberos Parameters on
   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

   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

Top      Up      ToC       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-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-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   ( [HW-AUTH]
 PA-SAM-CHALLENGE2          30   ( [KRB-WG.SAM]
 PA-SAM-RESPONSE2           31   ( [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-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]

Top      Up      ToC       Page 40 
 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-AUTH-SET-SELECTED       135  [RFC6113]
 PA-FX-FAST                 136  [RFC6113]
 PA-FX-ERROR                137  [RFC6113]
 PA-OTP-CHALLENGE           141  ( [OTP-PREAUTH]
 PA-OTP-REQUEST             142  ( [OTP-PREAUTH]
 PA-OTP-CONFIRM             143  ( [OTP-PREAUTH]
 PA-OTP-PIN-CHANGE          144  ( [OTP-PREAUTH]
 PA-EPAK-AS-REQ             145  ( [RFC6113]
 PA-EPAK-AS-REP             146  ( [RFC6113]
 PA_PKINIT_KX               147  [RFC6112]
 PA_PKU2U_NAME              148  [PKU2U]
 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

          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

Top      Up      ToC       Page 41 
      Type    Name                   Description
      0     RESERVED               Reserved for future expansion of this
      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      Up      ToC       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      Up      ToC       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      Up      ToC       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://

   [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      Up      ToC       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

   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
   DES (enctype 1): 43bae3738c9467e6
   3DES (enctype 16): e58f9eb643862c13ad38e529313462a7f73e62834fe54a01
   RC4 (enctype 23): 24d7f6b6bae4e5c00d2082c5ebab3672

Top      Up      ToC       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)

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

          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      Up      ToC       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)

          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      Up      ToC       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.

Authors' Addresses

   Sam Hartman
   Painless Security


   Larry Zhu
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052