NETWORK WORKING GROUP                                            B. Tung
Internet-Draft                                                 C. Neuman
Expires: June 6, 2005                        USC Information Sciences Institute
Expires: August 4, 2005                                           L. Zhu
                                                                  M. Hur
                                                   Microsoft Corporation
                                                            S. Medvinsky
                                                          Motorola, Inc.
                                                        December 6, 2004
                                                        January 31, 2005

     Public Key Cryptography for Initial Authentication in Kerberos
                    draft-ietf-cat-kerberos-pk-init
                   draft-ietf-cat-kerberos-pk-init-23

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 6, August 4, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004). (2005).

Abstract

   This document describes protocol extensions (hereafter called PKINIT)
   to the Kerberos protocol specification.  These extensions provide a
   method for integrating public key cryptography into the initial
   authentication exchange, by passing digital certificates and
   associated authenticators in preauthentication pre-authentication data fields.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4  3
   3.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . . .  5  4
     3.1   Definitions, Requirements, and Constants . . . . . . . . .  5  4
       3.1.1   Required Algorithms  . . . . . . . . . . . . . . . . .  5  4
       3.1.2   Defined Message and Encryption Types . . . . . . . . .  6  5
       3.1.3   Algorithm Identifiers  . . . . . . . . . . . . . . . .  7  6
     3.2   PKINIT Preauthentication Pre-authentication Syntax and Use . . . . . . . . .  7  6
       3.2.1   Generation of Client Request . . . . . . . . . . . . . . . . . . . .  8  7
       3.2.2   Validation   Receipt of Client Request  . . . . . . . . . . . . . 10 .  9
       3.2.3   Generation of KDC Reply  . . . . . . . . . . . . . . . . . . . . . . 12
       3.2.4   Validation   Receipt of KDC Reply . . . . . . . . . . . . . . . . . 17
     3.3   KDC Indication of PKINIT Support . . . . . . . . . . . . . 17 18
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19 18
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 19
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22 20
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     7.1   Normative References . . . . . . . . . . . . . . . . . . . 20
     7.2   Informative References . . . . . . . . . . . . . . . 22 . . . 21
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 21
   A.  PKINIT ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . 24 21
       Intellectual Property and Copyright Statements . . . . . . . . 28 27

1.  Introduction

   A client typically authenticates itself to a service in Kerberos
   using three distinct though related exchanges.  First, the client
   requests a ticket-granting ticket (TGT) from the Kerberos
   authentication server (AS).  Then, it uses the TGT to request a
   service ticket from the Kerberos ticket-granting server (TGS).
   Usually, the AS and TGS are integrated in a single device known as a
   Kerberos Key Distribution Center, or KDC.  (In this document, we will
   refer to both the AS and the TGS as the KDC.)  Finally, the client
   uses the service ticket to authenticate itself to the service.

   The advantage afforded by the TGT is that the client need explicitly
   request a ticket and expose exposes his credentials
   long-term secrets only once.  The TGT and its associated session key
   can then be used for any subsequent service ticket requests.  One
   result of this is that all further authentication is independent of
   the method by which the initial authentication was performed.
   Consequently, initial authentication provides a convenient place to
   integrate public-key cryptography into Kerberos authentication.

   As defined, defined in [CLAR], Kerberos authentication exchanges use
   symmetric-key cryptography, in part for performance.  One cost
   disadvantage of using symmetric-key cryptography is that the keys
   must be shared, so that before a client can authenticate itself, he
   must already be registered with the KDC.

   Conversely, public-key cryptography (in conjunction with an
   established Public Key Infrastructure) permits authentication without
   prior registration with a KDC.  Adding it to Kerberos allows the
   widespread use of Kerberized applications by clients without
   requiring them to register first with a KDC--a requirement that has
   no inherent security benefit.

   As noted above, a convenient and efficient place to introduce
   public-key cryptography into Kerberos is in the initial
   authentication exchange.  This document describes the methods and
   data formats for integrating public-key cryptography into Kerberos
   initial authentication.

2.  Conventions Used in This Document

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

   In this document, we will refer to both the AS and the TGS as the
   KDC.

3.  Extensions

   This section describes extensions to [CLAR] for supporting the use of
   public-key cryptography in the initial request for a ticket.

   Briefly, this document defines the following extensions to [CLAR]:

   1.  The client indicates the use of public-key authentication by
      including a special preauthenticator in the initial request.  This
      preauthenticator contains the client's public-key data and a
      signature.

   2.  The KDC tests the client's request against its authentication
      policy and trusted Certification Authorities (CAs).

   3.  If the request passes the verification tests, the KDC replies as
      usual, but the reply is encrypted using either:

      a.  a symmetric encryption key, signed using the KDC's signature
         key and encrypted using the client's encryption key; or

      b.  a key generated through a Diffie-Hellman (DH) key exchange
         [RFC2631] with the client, signed using the KDC's signature
         key; or

      b.  a symmetric encryption key, signed using the KDC's signature
         key and encrypted using the client's public key.

      Any keying material required by the client to obtain the
      Encryption
      encryption key for decrypting the KDC reply is returned in a preauthentication
      pre-authentication field accompanying the usual reply.

   4.  The client obtains the encryption key, decrypts the reply, and
      then proceeds as usual.

   Section 3.1 of this document defines enumerates the required algorithms and
   necessary extension message formats. types.  Section 3.2 describes their syntax and use the
   extension messages in greater detail.

3.1  Definitions, Requirements, and Constants

3.1.1  Required Algorithms

   All PKINIT implementations MUST support the following algorithms:

   o  AS reply key: AES256-CTS-HMAC-SHA1-96 etype [KCRYPTO].

   o  Signature algorithm: SHA-1 digest and RSA. sha-1WithRSAEncryption [RFC3279].

   o  Reply  KDC AS reply key delivery method: RSA or ephemeral-ephemeral
      Diffie-Hellman.
      Diffie-Hellman exchange (Diffie-Hellman keys are not cached).

3.1.2  Defined Message and Encryption Types

   PKINIT makes use of the following new preauthentication pre-authentication types:

       PA-PK-AS-REQ                             16
       PA-PK-AS-REP                             17

   PKINIT also makes use of the following new authorization data type:

       AD-INITIAL-VERIFIED-CAS                   9

   PKINIT introduces the following new error codes:

       KDC_ERR_CLIENT_NOT_TRUSTED                62
       KDC_ERR_KDC_NOT_TRUSTED                   63
       KDC_ERR_INVALID_SIG                       64
       KDC_ERR_KEY_SIZE                          65
       KDC_ERR_CERTIFICATE_MISMATCH              66
       KDC_ERR_CANT_VERIFY_CERTIFICATE           70
       KDC_ERR_INVALID_CERTIFICATE               71
       KDC_ERR_REVOKED_CERTIFICATE               72
       KDC_ERR_REVOCATION_STATUS_UNKNOWN         73
       KDC_ERR_CLIENT_NAME_MISMATCH              75

   PKINIT uses the following typed data types for errors:

       TD-TRUSTED-CERTIFIERS                    104
       TD-CERTIFICATE-INDEX                     105
       TD-DH-PARAMETERS                         109

   PKINIT defines the following encryption types, for use in the
   KRB_AS_REQ AS-REQ
   message (to indicate acceptance of the corresponding encryption OIDs
   Object Identifiers (OIDs) in PKINIT):

       dsaWithSHA1-CmsOID                         9
       md5WithRSAEncryption-CmsOID               10
       sha1WithRSAEncryption-CmsOID              11
       rc2CBC-EnvOID                             12
       rsaEncryption-EnvOID   (PKCS1 v1.5)       13
       rsaES-OAEP-EnvOID      (PKCS1 v2.0)       14
       des-ede3-cbc-EnvOID                       15

   The above encryption types are used by the client only within the
   KDC-REQ-BODY to indicate which CMS [RFC2630] Cryptographic Message Syntax (CMS)
   [RFC3852] algorithms it supports.  Their use within Kerberos
   EncryptedData structures is not specified by this document.

   The ASN.1 module for all structures defined in this document (plus
   IMPORT statements for all imported structures) are given in
   Appendix A.

   All structures defined in or imported into this document MUST be
   encoded using Distinguished Encoding Rules (DER) [X690].  All imported data
   structures wrapped in OCTET STRINGs must be encoded according to the
   rules specified in
   Kerberos [CLAR] or CMS [RFC2630] as appropriate. corresponding specifications.

   Interoperability note: Some implementations may not be able to decode
   CMS objects encoded with BER but not DER; specifically, they may not
   be able to decode infinite length encodings.  To maximize
   interoperability, implementers SHOULD encode CMS objects used in
   PKINIT with DER.

3.1.3  Algorithm Identifiers

   PKINIT does not define, but does make use of, the following algorithm
   identifiers.

   PKINIT uses the following algorithm identifier for Diffie-Hellman key
   agreement [FIPS74]: [RFC3279]:

        dhpublicnumber

   PKINIT uses the following signature algorithm identifiers [RFC3279]:

       sha-1WithRSAEncryption (RSA with SHA1)
       md5WithRSAEncryption   (RSA with MD5)
       id-dsa-with-sha1       (DSA with SHA1)

   PKINIT uses the following encryption algorithm identifiers [RFC2437] [RFC3447]
   for encrypting the temporary key with a public key:

       rsaEncryption          (PKCS1 v1.5)
       id-RSAES-OAEP          (PKCS1 v2.0)

   PKINIT uses the following algorithm identifiers [RFC2630] [RFC3370][RFC3565]
   for encrypting the reply key with the temporary key:

       des-ede3-cbc           (three-key 3DES, CBC mode)
       rc2-cbc                (RC2, CBC mode)
       aes256_CBC
       id-aes256-CBC          (AES-256, CBC mode)

3.2  PKINIT Preauthentication Pre-authentication Syntax and Use

   This section defines the syntax and use of the various
   preauthentication
   pre-authentication fields employed by PKINIT.

3.2.1  Generation of Client Request

   The initial authentication request (KRB_AS_REQ) (AS-REQ) is sent as per [CLAR]; in
   addition, a preauthentication pre-authentication field contains data signed by the
   client's private signature key, as follows:

       WrapContentInfo ::= OCTET STRING (CONSTRAINED BY {
               -- Contains a BER encoding of ContentInfo.
       })

       WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY {
               -- Contains a BER encoding of IssuerAndSerialNumber.
       })

       PA-PK-AS-REQ ::= SEQUENCE {
          signedAuthPack          [0] IMPLICIT WrapContentInfo, OCTET STRING,
                   -- Type Contains a CMS type ContentInfo encoded
                   -- according to [RFC3852].
                   -- The contentType field of the type ContentInfo
                   -- is id-signedData (1.2.840.113549.1.7.2),
                   -- and the content field is a SignedData.
                   -- Content The eContentType field for the type SignedData is AuthPack
                   -- (defined below). id-pkauthdata (1.3.6.1.5.2.3.1), and the
                   -- eContent field contains the DER encoding of the
                   -- type AuthPack.
                   -- AuthPack is defined below.
          trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
                   -- A list of CAs, trusted by
                                       -- the client, that can
                   -- be used to certify
                                       -- KDCs. validate KDC certificates.
          kdcCert                 [2] IMPLICIT WrapIssuerAndSerial OCTET STRING
                                      OPTIONAL,
                   -- Contains a CMS type IssuerAndSerialNumber encoded
                   -- according to [RFC3852].
                   -- Identifies a particular KDC
                                       -- certificate, if the client
                   -- client already has it.
           clientDHNonce           [3] DHNonce OPTIONAL,
          ...
       }

       DHNonce ::= OCTET STRING

       TrustedCA ::= CHOICE {
          caName                  [1] Name, IMPLICIT OCTET STRING,
                   -- Fully qualified X.500 name Contains a PKIX type Name encoded according to
                   -- as defined in [RFC3280].
          issuerAndSerial         [2] IMPLICIT WrapIssuerAndSerial, OCTET STRING,
                   -- Contains a CMS type IssuerAndSerialNumber encoded
                   -- according to [RFC3852].
                   -- Identifies a specific CA
                                       -- certificate.
          ...
       }

       AuthPack ::= SEQUENCE {
          pkAuthenticator         [0] PKAuthenticator,
          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
                   -- Defined in [RFC3280].
                   -- Present only if the client wishes to use the
                   -- is using ephemeral-ephemeral
                                       -- Diffie-Hellman. Diffie-Hellman key agreement method.
          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
                                      OPTIONAL,
                   -- List of CMS encryption types
                                       -- supported by
                   -- client in order
                                       -- of (decreasing) preference.
          clientDHNonce           [3] DHNonce OPTIONAL,
                   -- Present only if the client indicates that it
                   -- wishes to cache DH keys or to allow the KDC to
                   -- do so.
          ...
       }

       PKAuthenticator ::= SEQUENCE {
          cusec                   [0] INTEGER (0..999999),
          ctime                   [1] KerberosTime,
                   -- cusec and ctime are used as
                                       -- in [CLAR], for replay
                   -- prevention.
          nonce                   [2] INTEGER (0..4294967295),
                   -- Chosen randomly;  This nonce does not need to
                   -- match with the nonce in the KDC-REQ-BODY.
          paChecksum              [3] OCTET STRING,
                   -- Contains the SHA1 checksum,
                                       -- performed over
                   -- KDC-REQ-BODY.
          ...
       }

   The ContentInfo in [RFC3852] structure for the signedAuthPack field is
   filled out as follows:

   1.  The eContent contentType field contains data of type AuthPack.  It MUST
       contain the pkAuthenticator, type ContentInfo is id-signedData
       (as defined in [RFC3852]), and MAY also contain the client's
       Diffie-Hellman public value (clientPublicValue). content field is a SignedData
       (as defined in [RFC3852]).

   2.  The eContentType field MUST contain the OID value for the type SignedData is id-pkauthdata:
       { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
       pkinit(3) pkauthdata(1) }.

   3.  The eContent field for the type SignedData contains the DER
       encoding of the type AuthPack.

   4.  The signerInfos field MUST contain of the type SignedData contains a single
       signerInfo, which contains the signature over the type AuthPack.

   4.

   5.  The certificates field MUST contain at least a signature
       verification of the type SignedData contains the
       client's certificate chain and additional certificates intended to
       facilitate certification path construction, so that the KDC can use to
       validate the client's certificate and verify the signature over
       the type AuthPack.  The certificate chain(s) certificates field MUST NOT contain the root
       "root" CA certificate.

   5.  If a certificates.

   6.  The client's Diffie-Hellman key public value (clientPublicValue) is being used,
       included if and only if the parameters client wishes to use the
       Diffie-Hellman key agreement method.  For the Diffie-Hellman key
       agreement method, implementations MUST be
       chosen from support Oakley Group 1024-bit
       MODP well-known group 2 or 14.  Implementations MUST support
       Group 2; they are RECOMMENDED to [RFC2412] and SHOULD support Group Oakley
       2048-bit MODP well-known group 14 (See
       [RFC2409]).

   6. and Oakley 4096-bit MODP
       well-known group 16 [RFC3526].  They MAY support Oakley 185-bit
       EC2N group 4 [RFC2412].  The Diffie-Hellman group size should be
       chosen so as to provide sufficient cryptographic security.  The
       exponents should have at least twice as many bits as the
       symmetric keys that will be derived from them [ODL99].

   7.  The client may wish to cache DH parameters keys or to allow the KDC to do
       so.  If so, then the client must include includes the clientDHNonce field.  The
       This nonce string needs to be as long as the longest key length
       of the symmetric key types that the client supports.  The  This nonce
       MUST be chosen randomly.

3.2.2  Validation  Receipt of Client Request

   Upon receiving the client's request, the KDC validates it.  This
   section describes the steps that the KDC MUST (unless otherwise
   noted) take in validating the request.

   The KDC must look looks for a client the client's certificate in the signedAuthPack. signedAuthPack
   (based on the signerInfo) and validate this certificate.

   If
   it the KDC cannot find one signed by a CA it trusts, certification path to validate the client's
   certificate, it sends back an error of type
   KDC_ERR_CANT_VERIFY_CERTIFICATE.  The accompanying e-data for this
   error is a TYPED-DATA (as defined in [CLAR]).  For this error, the
   data-type is TD-TRUSTED-CERTIFIERS, and the data-value is the DER
   encoding of

       TrustedCertifiers ::= SEQUENCE OF OCTET STRING
                   -- The OCTET STRING contains a PKIX type Name encoded
                   -- according to [RFC3280].

   If, while verifying processing the certificate chain, certification path, the KDC determines that
   the signature on one of the certificates in the signedAuthPack is
   invalid, it returns an error of type KDC_ERR_INVALID_CERTIFICATE.
   The accompanying e-data for this error is a TYPED-DATA, whose
   data-type is TD-CERTIFICATE-INDEX, and whose data-value is the DER
   encoding of the index into the CertificateSet field, ordered as sent
   by the client:

       CertificateIndex ::= OCTET STRING
                   -- Contains a CMS type IssuerAndSerialNumber encoded
                   -- according to [RFC3852].
                   -- IssuerAndSerialNumber of
                           -- certificate with an
                   -- invalid signature.

   If more than one certificate signature is invalid, the KDC MAY send
   one TYPED-DATA per invalid signature.

   The KDC MAY SHOULD also check whether any certificates in the client's chain
   certification path have been revoked.  If any of them have been
   revoked, the KDC MUST return an error of type
   KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
   revocation status but is unable to do so, it SHOULD return an error
   of type KDC_ERR_REVOCATION_STATUS_UNKNOWN.  The certificate or
   certificates affected are identified exactly as for an error of type
   KDC_ERR_INVALID_CERTIFICATE (see above).

   In addition to validating the certificate chain, client's certificate, the KDC MUST also
   check that the this certificate properly maps to the client's principal
   name as specified in the KRB_AS_REQ AS-REQ as follows:

   1.  If the KDC has its own mapping from the name in the client's
      certificate to a Kerberos name, it uses that Kerberos name.

   2.  Otherwise, if the client's certificate contains a SubjectAltName
      extension with a Kerberos name in the otherName field, it uses
      that name.

      The otherName field (of type AnotherName) in the SubjectAltName
      extension MUST contain krb5PrincipalName KRB5PrincipalName as defined below.

      The type-id is:

       krb5PrincipalName field of the type AnotherName is id-pksan:

       id-pksan OBJECT IDENTIFIER ::= iso (1) org (3) dod (6)
       internet (1) security (5) kerberosv5
         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
           x509-sanan (2) 2 }

      The value field of the type AnotherName is the DER encoding of the
      following ASN.1 type:

       KRB5PrincipalName ::= SEQUENCE {
           realm                   [0] Realm,
           principalName           [1] PrincipalName
       }

   If the KDC does not have its own mapping and there is no Kerberos
   name present in the client's certificate, or if the name in the
   request does not match the name in the certificate (including the
   realm name), or
   if there is no name in the request, the KDC MUST return error code
   KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data for
   this error.

   Even if the client's certificate chain is validated, and the names in the
   certificate validated and it is mapped to the request match,
   client's principal name, the KDC may decide not to reject
   requests on accept the basis of
   client's certificate, depending on local policy.

   The KDC MAY require the absence or presence of specific EKU
   OIDs.  For example, the certificate may include an Extended Key Usage (EKU) OID of
   KeyPurposeId [RFC3280] id-pkekuoid in the extensions field: field of the
   client's certificate:

       id-pkekuoid OBJECT IDENTIFIER ::=
         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
           pkinit(3) pkekuoid(4) }
              -- PKINIT client authentication.
              -- Key usage bits that may be consistent: digitalSignature
              -- nonRepudiation, and (keyEncipherment or keyAgreement).

   As a matter of local policy, the KDC may decide to reject requests on
   the basis of the absence or presence of specific EKU OIDs.  KDCs
   implementing this requirement SHOULD also accept the EKU KeyPurposeId
   id-ms-sc-logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement,
   as there are a large number of client certificates deployed for use
   with PKINIT which have this EKU.

   The KDC MUST return the error code KDC_ERR_CLIENT_NOT_TRUSTED if the
   client's cerficate certificate is not accepted.

   If

   Once the client's certificate is accepted, the KDC can then verify
   the client's signature on over the signedAuthPack type AuthPack according to [RFC3852].
   If the signature fails to verify, the KDC MUST return error
   KDC_ERR_INVALID_SIG.  There is no accompanying e-data for this error.

   The KDC MUST check the timestamp to ensure that the request is not a
   replay, and that the time skew falls within acceptable limits.  The
   recommendations clock skew times in [CLAR] apply here.  If the check
   fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
   KRB_AP_ERR_SKEW, respectively.

   If the clientPublicValue is filled in, indicating that the client
   wishes to use ephemeral-ephemeral Diffie-Hellman, the Diffie-Hellman key agreement method, the KDC checks SHOULD
   check to see if the key parameters satisfy its policy.  If they do
   not, it MUST return error code KDC_ERR_KEY_SIZE.  The accompanying
   e-data is a TYPED-DATA, whose data-type is TD-DH-PARAMETERS, and
   whose data-value is the DER encoding of a the following:

       TD-DH-PARAMETERS ::= SEQUENCE OF DomainParameters (see [RFC3279]), including
   appropriate
                   -- Type DomainParameters is defined in [RFC3279].
                   -- Contains a list of Diffie-Hellman group
                   -- parameters with in decreasing preference order.

   TD-DH-PARAMETERS contains a list of Diffie-Hellman group parameters
   that the KDC supports in decreasing preference order, from which the
   client should pick one to retry the request.

   The KDC MUST return error code KDC_ERR_CERTIFICATE_MISMATCH if the
   client included a kdcCert field in the PA-PK-AS-REQ and the KDC does
   not have the corresponding certificate.

   The KDC MUST return error code KDC_ERR_KDC_NOT_TRUSTED if the client
   did not include a kdcCert field, but did include a trustedCertifiers
   field, and the KDC does not possesses a certificate issued by one of
   the listed certifiers.

   If there is a supportedCMSTypes field in the AuthPack, the KDC must
   check to see if it supports any of the listed types.  If it supports
   more than one of the types, the KDC SHOULD use the one listed first.
   If it does not support any of them, it MUST return an error of type
   KRB5KDC_ERR_ETYPE_NOSUPP.

3.2.3  Generation of KDC Reply

   Assuming that the client's request has been properly validated, the
   KDC proceeds as per [CLAR], except as follows.

   The KDC MUST set the initial flag and include an authorization data
   of type AD-INITIAL-VERIFIED-CAS in the issued ticket.  The value is
   an OCTET STRING containing the DER encoding of InitialVerifiedCAs:

       InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
          ca                      [0] Name,
           Validated IMPLICIT OCTET STRING,
                   -- Contains a PKIX type Name encoded according to
                   -- [RFC3280].
          validated               [1] BOOLEAN,
          ...
       }

   The KDC MAY wrap any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
   containers if the list of CAs satisfies the KDC's realm's policy
   (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag). flag
   [CLAR]).  Furthermore, any TGS must copy such authorization data from
   tickets used in a PA-TGS-REQ of the TGS-REQ to the resulting ticket,
   including the AD-IF-RELEVANT container, if present.

   Application servers that understand this authorization data type
   SHOULD apply local policy to determine whether a given ticket bearing
   such a type *not* contained within an AD-IF-RELEVANT container is
   acceptable.  (This corresponds to the AP server checking the
   transited field when the TRANSITED-POLICY-CHECKED flag has not been
   set.)
   set [CLAR].)  If such a data type is contained within an
   AD-IF-RELEVANT container, AP servers MAY apply local policy to
   determine whether the authorization data is acceptable.

   The KRB_AS_REP AS-REP is otherwise unchanged from [CLAR].  The KDC encrypts the
   reply as usual, but not with the client's long-term key.  Instead, it
   encrypts it with either a generated encryption key, or a shared key derived from a Diffie-Hellman exchange.
   exchange, or a generated encryption key.  The contents of the
   PA-PK-AS-REP indicate the type of encryption which key that was delivery method is used:

       PA-PK-AS-REP ::= CHOICE {
          dhInfo                  [0] DHRepInfo,
          encKeyPack              [1] IMPLICIT WrapContentInfo, OCTET STRING,
                   -- Type Contains a CMS type ContentInfo encoded
                   -- according to [RFC3852].
                   -- The contentType field of the type ContentInfo is
                   -- id-envelopedData (1.2.840.113549.1.7.3).
                   -- The content field is an EnvelopedData.
                   -- Content The contentType field for the type EnvelopedData
                   -- is id-signedData (1.2.840.113549.1.7.2).
                   -- The eContentType field for the inner type
                   -- SignedData over (when unencrypted) is id-pkrkeydata
                   -- (1.2.840.113549.1.7.3) and the eContent field
                   -- contains the DER encoding of the type
                   -- ReplyKeyPack.
                   -- ReplyKeyPack (defined below). is defined below.
          ...
       }

       DHRepInfo ::= SEQUENCE {
          dhSignedData            [0] ContentInfo, IMPLICIT OCTET STRING,
                   -- Type Contains a CMS type ContentInfo encoded according
                   -- to [RFC3852].
                   -- The contentType field of the type ContentInfo is
                   -- id-signedData (1.2.840.113549.1.7.2), and the
                   -- content field is a SignedData.
                   -- Content The eContentType field for the type SignedData is KDCDHKeyInfo
                   -- (defined below). id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
                   -- eContent field contains the DER encoding of the
                   -- type KDCDHKeyInfo.
                   -- KDCDHKeyInfo is defined below.
          serverDHNonce           [1] DHNonce OPTIONAL
                   -- Present if and only if dhKeyExpiration is
                   -- present.
       }

       KDCDHKeyInfo ::= SEQUENCE {
          subjectPublicKey        [0] BIT STRING,
                   -- Equals KDC's public exponent
                                       -- (g^a key, y = g^x mod p). p.
                   -- INTEGER MUST be ASN.1 encoded as payload an INTEGER;
                   -- This encoding is then used as the contents
                   -- (i.e., the value) of this BIT STRING. STRING field.
          nonce                   [1] INTEGER (0..4294967295),
                   -- Contains the nonce in the PKAuthenticator of the
                   -- request if cached DH keys are NOT used,
                   -- 0 otherwise.
          dhKeyExpiration         [2] KerberosTime OPTIONAL,
                   -- Expiration time for KDC's cached values, present
                   -- if and only if cached values. DH keys are used.  If this field
                   -- field is omitted then the
                                       -- serverDHNonce field
                   -- MUST also
                                       -- be omitted.
          ...
       }

   The fields of

3.2.3.1  Using Diffie-Hellman Key Exchange

   In this case, the PA-PK-AS-REP contains a DHRepInfo structure.

   The ContentInfo [RFC3852] structure for the dhSignedData are to be field is
   filled in as follows:

   1.  The eContent contentType field contains data of the type KDCDHKeyInfo. ContentInfo is id-signedData
       (as defined in [RFC3852]), and the content field is a SignedData
       (as defined in [RFC3852]).

   2.  The eContentType field contains for the type SignedData is the OID value
       for id-pkdhkeydata: { iso(1) org(3) dod(6) internet(1)
       security(5) kerberosv5(2) pkinit(3) pkdhkeydata(2) }.

   3.  The eContent field for the type SignedData contains the DER
       encoding of the type KDCDHKeyInfo.

   4.  The signerInfos field of the type SignedData contains a single
       signerInfo, which is contains the signature of over the type
       KDCDHKeyInfo.

   4.

   5.  The certificates field of the type SignedData contains a signature verification the KDC's
       certificate chain and additional certificates intended to facilitate
       certification path construction, so that the client will use to can validate
       the KDC's certificate and verify the KDC's signature over the
       type KDCDHKeyInfo.  This field may only be left empty if the
       client did include a kdcCert field in the PA-PK-AS-REQ,
       indicating that it the client already has the KDC's certificate.
       The
       certificate chain certificates field MUST NOT contain the root "root" CA certificate.

   5. certificates.

   6.  If the client included the clientDHNonce field, then the KDC may
       choose to reuse its DH parameters. keys.  If the server reuses DH
       parameters keys then
       it MUST include an expiration time in the dhKeyExperiation field.
       Past the point of the expiration time, the signature of over the
       type DHRepInfo is considered invalid. expired/invalid.  When the server
       reuses DH parameters keys then it MUST include a serverDHNonce at least as
       long as the length of keys for the symmetric encryption system
       used to encrypt the AS reply.  Note that including the
       serverDHNonce changes how the client and server calculate the key
       to use to encrypt the reply; see below for details.  Clients MUST  The KDC
       SHOULD NOT reuse DH parameters keys unless the
       response includes the serverDHNonce field.

   If clientDHNonce field is
       present in the Diffie-Hellman request.

   The reply key exchange is used, for use to decrypt the KDC reply key [CLAR] is derived as
   follows:

   1.  Both the KDC and the client calculate the shared secret value
      DHKey:

           DHKey = g^(ab) g^(xb * xa) mod p

      where a xb and b xa are the client's and KDC's and client's private exponents,
      respectively.  DHKey, padded first with leading zeros as needed to
      make it as long as the modulus p, is represented as a string of
      octets in big-endian order (such that the size of DHKey in octets
      is the size of the modulus p).

   2.  Let K be the key-generation seed length [KCRYPTO] of the reply
      key whose enctype is selected according to [CLAR].

   3.  Define the function octetstring2key() as follows:

           octetstring2key(x) == random-to-key(K-truncate(
                                    SHA1(0x00 | x) |
                                    SHA1(0x01 | x) |
                                    SHA1(0x02 | x) |
                                    ...
                                    ))

      where x is an octet string; | is the concatenation operator; 0x00,
      0x01, 0x02, etc., are each represented as a single octet;
      random-to-key() is an operation that generates a protocolkey protocol key from
      a bitstring of length K; and K-truncate truncates its input to the
      first K bits.  Both K and random-to-key() are defined in the
      kcrypto profile [KCRYPTO] for the enctype of the reply key.

   4.  When cached DH parameters keys are used, let n_c be the clientDHNonce, and
      n_k be the serverDHNonce; otherwise, let both n_c and n_k be empty
      octet strings.

   5.  The KDC reply key k is:

           k = octetstring2key(DHKey | n_c | n_k)

   If

3.2.3.2  Using Public Key Encryption

   In this case, the Diffie-Hellman PA-PK-AS-REP contains a ContentInfo structure
   wrapped in an OCTET STRING.  The reply key exchange is not used, for use to decrypt the KDC
   reply key [CLAR] is encrypted in the encKeyPack, encKeyPack field, which contains
   data of type ReplyKeyPack:

       ReplyKeyPack ::= SEQUENCE {
          replyKey                [0] EncryptionKey,
                   -- Defined in [CLAR].
                                       -- Used Contains the session key used to encrypt main reply.
                                       -- MUST be at least as strong
                                       -- as session key.  (Using the
                   -- same enctype and a strong
                                       -- prng should suffice, if no
                                       -- stronger encryption system
                                       -- is available.) enc-part field in the AS-REP.
          nonce                   [1] INTEGER (0..4294967295),
                   -- Contains the nonce in
                                       -- the KDCDHKeyInfo. PKAuthenticator of the
                   -- request.
          ...
       }

   The fields of the ContentInfo [RFC3852] structure for the encKeyPack MUST be field is
   filled in as follows:

   1.  The content is contentType field of the type SignedData. ContentInfo is id-envelopedData
       (as defined in [RFC3852]), and the content field is an
       EnvelopedData (as defined in [RFC3852]).

   2.  The eContent contentType field for the
      SignedData is of type ReplyKeyPack.

   2. EnvelopedData is
       id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
       pkcs (1) pkcs7 (7) signedData (2) }.

   3.  The eContentType field for the inner type SignedData contains (when
       decrypted from the OID value encryptedContent field for the type
       EnvelopedData) is id-pkrkeydata: { iso(1) org(3) dod(6)
       internet(1) security(5) kerberosv5(2) pkinit(3) pkrkeydata(3) }.

   3.

   4.  The eContent field for the inner type SignedData contains the DER
       encoding of the type ReplyKeyPack.

   5.  The signerInfos field of the inner type SignedData contains a
       single signerInfo, which is contains the signature of over the type
       ReplyKeyPack.

   4.

   6.  The certificates field of the inner type SignedData contains a signature verification the
       KDC's certificate chain and additional certificates intended to
       facilitate certification path construction, so that the client will use to
       can validate the KDC's certificate and verify the KDC's signature
       over the type ReplyKeyPack.  This field may only be left empty if
       the client included a kdcCert field in the PA-PK-AS-REQ,
       indicating that it the client already has the KDC's certificate.
       The certificate
      chain certificates field MUST NOT contain the root "root" CA certificate.

   5.  The contentType for the EnvelopedData contains the OID value for
      id-signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
      pkcs (1) pkcs7 (7) signedData (2) }.

   6. certificates.

   7.  The recipientInfos field of the type EnvelopedData is a SET which
       MUST contain exactly one member of type KeyTransRecipientInfo.
       The encryptedKey for of this member contains the temporary key which
       is encrypted using the client's public key.

   7.

   8.  The unprotectedAttrs or originatorInfo fields of the type
       EnvelopedData MAY be present.

3.2.4  Validation  Receipt of KDC Reply

   Upon receipt of the KDC's reply, the client proceeds as follows.  If
   the PA-PK-AS-REP contains a dhSignedData, the client obtains and
   verifies dhSignedData field, the Diffie-Hellman parameters, and obtains client derives
   the shared key using the same procedure used by the KDC as
   described above. defined in
   Section 3.2.3.1.  Otherwise, the message contains an encKeyPack, and
   the client decrypts and verifies the temporary encryption key.

   In either case, the client MUST check validate the KDC's certificate and
   verify the signature in the SignedData according to [RFC3852].
   Unless the client can otherwise prove that the KDC's certificate is
   for the target KDC (i.e., the subject distinguished name in the KDC
   certificate is bound to the hostname or IP address of the KDC
   authenticating the client), it MUST do the following to verify the
   responder's identity:

   1.  The client checks to see if the included certificate contains a subjectAltName
      Subject Alternative Name extension of type [RFC3280] carrying a dNSName or
      an iPAddress (if the KDC is specified by an IP address instead of
      a name).  If it does, it MUST check to see if that extension name value
      matches that of the KDC it believes it is communicating with, with
      matching rules specified in
   RFC 2459.  Exception: If the client has some external information as
   to the identity of the KDC, this check MAY be omitted. [RFC3280].

   2.  The client also MUST check verifies that the KDC's certificate contains an
   extendedKeyUsage OID of MUST contain the
      EKU KeyPurposeId [RFC3280] id-pkkdcekuoid:

       id-pkkdcekuoid OBJECT IDENTIFIER ::=
         { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
           pkinit(3) pkkdcekuoid(5) }
              -- Signing KDC responses.
              -- Key usage bits that may be consistent:
              -- digitalSignature.

   If all applicable checks are satisfied, the client then decrypts the
   main reply
   enc-part of the KDC-REP in the AS_REP with the resulting key, and
   then proceeds as described in
   [1]. [CLAR].

3.3  KDC Indication of PKINIT Support

   If pre-authentication is required, but was not present in the
   request, per [CLAR] an error message with the code
   KDC_ERR_PREAUTH_FAILED 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.  The KDC can then
   indicate the support of PKINIT by including a PA-PK-AS-REQ element in
   that METHOD-DATA object.

   Otherwise if it is required by the KDC's local policy that the client
   must be pre-authenticated using the preauthentication pre-authentication mechanism
   specified in this document, but no PKINIT pre-authentication was
   present in the request, an error message with the code
   KDC_ERR_PREAUTH_FAILED SHOULD be returned.

   The padata-value for

   KDCs MUST leave the padata-value of PA-PK-AS-REQ entry in the
   KRB-ERROR's METHOD-DATA object
   is an empty octet string (i.e., send a zero-length OCTET
   STRING), and SHOULD be ignored otherwise. clients MUST ignore this and any other value.  Future
   extensions to this protocol may specify other data to send instead of
   an empty OCTET STRING.

4.  Security Considerations

   PKINIT raises certain security considerations beyond those that can
   be regulated strictly in protocol definitions.  We will address them
   in this section.

   PKINIT extends the cross-realm model to the public-key
   infrastructure.  Users of PKINIT must understand security policies
   and procedures appropriate to the use of Public Key Infrastructures.

   Standard Kerberos allows the possibility of interactions between
   cryptosystems of varying strengths; this document adds interactions
   with public-key cryptosystems to Kerberos.  Some administrative
   policies may allow the use of relatively weak public keys.  Using
   such keys to wrap data encrypted under stronger conventional
   cryptosystems may be inappropriate.

   PKINIT requires keys for symmetric cryptosystems to be generated.
   Some such systems contain "weak" keys.  For recommendations regarding
   these weak keys, see [CLAR].

   PKINIT allows the use of a zero nonce in the PKAuthenticator when
   cached Diffie-Hellman keys are used.  In this case, message binding
   is performed using the nonce in the main request in uses the same way as
   it is done RSA key pair for ordinary KRB_AS_REQs (without the PKINIT
   pre-authenticator).  The nonce field in the KDC request body is
   signed through the checksum in the PKAuthenticator, which
   cryptographically binds the PKINIT pre-authenticator to the main body
   of the AS Request encryption and also provides message integrity for the full AS
   Request.

   However, signing when a PKINIT pre-authenticator in the KRB_AS_REP has a
   zero-nonce, and an attacker has somehow recorded this
   pre-authenticator and discovered the corresponding Diffie-Hellman
   private
   doing RSA encryption based key (e.g., with a brute-force attack), the attacker will be
   able to fabricate his own KRB_AS_REP messages that impersonate the
   KDC with this same pre-authenticator. delivery.  This compromised
   pre-authenticator will remain valid as long as its expiration time
   has not been reached and it is therefore important for clients to
   check this expiration time and for the expiration time to be
   reasonably short, which depends on the size not recommended
   usage of the Diffie-Hellman
   group. RSA keys [RFC3447], by using DH based key delivery this is
   avoided.

   Care should be taken in how certificates are chosen for the purposes
   of authentication using PKINIT.  Some local policies may require that
   key escrow be used for certain certificate types.  Deployers of
   PKINIT should be aware of the implications of using certificates that
   have escrowed keys for the purposes of authentication.

   PKINIT does not provide for a "return routability" test to prevent
   attackers from mounting a denial-of-service attack on the KDC by
   causing it to perform unnecessary and expensive public-key
   operations.  Strictly speaking, this is also true of standard
   Kerberos, although the potential cost is not as great, because
   standard Kerberos does not make use of public-key cryptography.

   The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
   permit empty SEQUENCEs to be encoded.  Such empty sequences may only
   be used if the KDC itself vouches for the user's certificate.  [This
   seems to reflect the consensus of the Kerberos working group.]

5.  Acknowledgements

   The following people have made significant contributions to this
   draft: Paul Leach, Phil Hallin, Kelvin Yiu, Sam Hartman, Love
   Hornquist Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan
   Trostle, Tom Yu Yu, Jeffrey Hutzelman, David Cross, Dan Simon and
   Karthik Jaganathan.

   Special thanks to Clifford Neuman, Mat Hur and Jeff
   Hutzelman. Sasha Medvinsky who
   wrote earlier versions of this document.

   The authors are indebt to the Kerberos working group chair Jeffrey
   Hutzelman who kept track of various issues and was enormously helpful
   during the creation of this document.

   Some of the ideas on which this document is based arose during
   discussions over several years between members of the SAAG, the IETF
   CAT working group, and the PSRG, regarding integration of Kerberos
   and SPX.  Some ideas have also been drawn from the DASS system.
   These changes are by no means endorsed by these groups.  This is an
   attempt to revive some of the goals of those groups, and this
   document approaches those goals primarily from the Kerberos
   perspective.

   Lastly, comments from groups working on similar ideas in DCE have
   been invaluable.

6.  IANA Considerations

   This document has no actions for IANA.

7

7.  References

7.1  Normative References

   [CLAR]     Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)",
              draft-ietf-krb-wg-kerberos-clarifications, work in
              progress.

   [FIPS74]   NIST, Guidelines     RFC-Editor: To be replaced by RFC number for Implementing and Using
              the NBS Encryption Standard, April 1981.  FIPS PUB 74. draft-ietf-
              krb-wg-kerberos-clarifications.  Work in Progress.

   [KCRYPTO]  Raeburn, K., "Encryption and Checksum Specifications  RFC-Editor: To be replaced by RFC number for
              Kerberos 5", December 2004. draft-ietf-
              krb-wg-crypto.  Work in Progress.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2409]  Harkins, D. and D. Carrel,

   [RFC2412]  Orman, H., "The Internet OAKLEY Key Exchange
              (IKE)", Determination Protocol",
              RFC 2409, 2412, November 1998.

   [RFC2437]  Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
              Specifications Version 2.0", RFC 2437, October 1998.

   [RFC2630]  Housley, R., "Cryptographic Message Syntax",

   [RFC2631]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
              RFC 2630, 2631, June 1999.

   [RFC3279]  Bassham, L., Polk, W. and R. Housley, "Algorithms and
              Identifiers for the Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 3279, April 2002.

   [RFC3280]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              April 2002.

   [RFC3370]  Housley, R., "Cryptographic Message Syntax (CMS)
              Algorithms", RFC 3370, August 2002.

   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, February 2003.

   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
              Diffie-Hellman groups for Internet Key Exchange (IKE)",
              RFC 3526, May 2003.

   [RFC3565]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
              Encryption Algorithm in Cryptographic Message Syntax
              (CMS)", RFC 3565, July 2003.

   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
              RFC 3852, July 2004.

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

7.2  Informative References

   [ODL99]    Odlyzko, A., "Discrete logarithms: The past and the
              future, Designs, Codes, and Cryptography (1999)".

Authors' Addresses

   Brian Tung
   USC Information Sciences Institute
   4676 Admiralty Way Suite 1001, Marina del Rey CA
   Marina del Rey, CA  90292
   US

   EMail: brian@isi.edu

   Clifford Neuman
   USC Information Sciences Institute
   4676 Admiralty Way Suite 1001, Marina del Rey CA
   Marina del Rey, CA  90292
   US

   EMail:

   Email: brian@isi.edu

   Larry Zhu
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   US

   EMail:

   Email: lzhu@microsoft.com

   Matt Hur
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   US

   EMail: matthur@microsoft.com

   Sasha Medvinsky
   Motorola, Inc.
   6450 Sequence Drive
   San Diego, CA  92121
   US

   EMail: smedvinsky@motorola.com

Appendix A.  PKINIT ASN.1 Module

       KerberosV5-PK-INIT-SPEC {
               iso(1) identified-organization(3) dod(6) internet(1)
               security(5) kerberosV5(2) modules(4) pkinit(3) pkinit(5)
       } DEFINITIONS EXPLICIT TAGS ::= BEGIN

       IMPORTS
           SubjectPublicKeyInfo, AlgorithmIdentifier, Name AlgorithmIdentifier
               FROM PKIX1Explicit88 { iso (1)
                 identified-organization (3) dod (6) internet (1)
                 security (5) mechanisms (5) pkix (7) id-mod (0)
                 id-pkix1-explicit (18) }

           ContentInfo, IssuerAndSerialNumber
                 -- As defined in RFC 3280.

           DomainParameters
               FROM CryptographicMessageSyntax PKIX1Algorithms88 { iso(1) member-body(2)
                 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
                 modules(0) cms(1)
                 identified-organization(3) dod(6)
                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
                 id-mod-pkix1-algorithms(17) }
                 -- As defined in RFC 3279.

           KerberosTime, TYPED-DATA, PrincipalName, Realm, EncryptionKey
               FROM KerberosV5Spec2 { iso(1) identified-organization(3)
                 dod(6) internet(1) security(5) kerberosV5(2)
                 modules(4) krb5spec2(2) } ;

       id-pkinit OBJECT IDENTIFIER ::=
         { iso (1) org (3) dod (6) internet (1) security (5)
           kerberosv5 (2) pkinit (3) }

       id-pkdhkeydata

       id-pkauthdata  OBJECT IDENTIFIER  ::= { id-pkinit 1 }
       id-pkdhkeydata OBJECT IDENTIFIER  ::= { id-pkinit 2 }
       id-pkrkeydata  OBJECT IDENTIFIER  ::= { id-pkinit 3 }
       id-pkekuoid    OBJECT IDENTIFIER  ::= { id-pkinit 4 }
       id-pkkdcekuoid OBJECT IDENTIFIER  ::= { id-pkinit 5 }

       pa-pk-as-req INTEGER ::=                 16
       pa-pk-as-rep INTEGER ::=                 17

       ad-initial-verified-cas INTEGER ::=       9

       td-trusted-certifiers INTEGER ::=        104
       td-certificate-index INTEGER ::=         105
       td-dh-parameters INTEGER ::=             109
       WrapContentInfo ::= OCTET STRING (CONSTRAINED BY {
              -- Contains a BER encoding of ContentInfo.
       })

       WrapIssuerAndSerial ::= OCTET STRING (CONSTRAINED BY {
              -- Contains a BER encoding of IssuerAndSerialNumber.
       })

       PA-PK-AS-REQ ::= SEQUENCE {
          signedAuthPack          [0] IMPLICIT WrapContentInfo, OCTET STRING,
                   -- Type Contains a CMS type ContentInfo encoded
                   -- according to [RFC3852].
                   -- The contentType field of the type ContentInfo
                   -- is id-signedData (1.2.840.113549.1.7.2),
                   -- and the content field is a SignedData.
                   -- Content The eContentType field for the type SignedData is AuthPack
                   -- (defined below). id-pkauthdata (1.3.6.1.5.2.3.1), and the
                   -- eContent field contains the DER encoding of the
                   -- type AuthPack.
                   -- AuthPack is defined below.
          trustedCertifiers       [1] SEQUENCE OF TrustedCA OPTIONAL,
                   -- A list of CAs, trusted by
                                      -- the client, that can
                   -- be used to certify
                                      -- KDCs. validate KDC certificates.
          kdcCert                 [2] IMPLICIT WrapIssuerAndSerial OCTET STRING
                                      OPTIONAL,
                   -- Contains a CMS type IssuerAndSerialNumber encoded
                   -- according to [RFC3852].
                   -- Identifies a particular KDC
                                      -- certificate, if the client
                   -- client already has it.
          clientDHNonce           [3] DHNonce OPTIONAL,
          ...
       }

       DHNonce ::= OCTET STRING

       TrustedCA ::= CHOICE {
          caName                  [1] Name, IMPLICIT OCTET STRING,
                   -- Fully qualified X.500 name Contains a PKIX type Name encoded according to
                   -- as defined in [RFC3280].
          issuerAndSerial         [2] IMPLICIT WrapIssuerAndSerial, OCTET STRING,
                   -- Contains a CMS type IssuerAndSerialNumber encoded
                   -- according to [RFC3852].
                   -- Identifies a specific CA
                                      -- certificate.
          ...
       }

       AuthPack ::= SEQUENCE {
          pkAuthenticator         [0] PKAuthenticator,
          clientPublicValue       [1] SubjectPublicKeyInfo OPTIONAL,
                   -- Defined in [RFC3280].
                   -- Present only if the client wishes to use the
                   -- is using ephemeral-ephemeral
                                      -- Diffie-Hellman. Diffie-Hellman key agreement method.
          supportedCMSTypes       [2] SEQUENCE OF AlgorithmIdentifier
                                      OPTIONAL,
                   -- List of CMS encryption types
                                      -- supported by
                   -- client in order
                                      -- of (decreasing) preference.
          clientDHNonce           [3] DHNonce OPTIONAL,
                   -- Present only if the client indicates that it
                   -- wishes to cache DH keys or to allow the KDC to
                   -- do so.
          ...
       }
       PKAuthenticator ::= SEQUENCE {
          cusec                   [0] INTEGER (0..999999),
          ctime                   [1] KerberosTime,
                   -- cusec and ctime are used as
                                      -- in [CLAR], for replay
                   -- prevention.
          nonce                   [2] INTEGER (0..4294967295),
                   -- Chosen randomly;  This nonce does not need to
                   -- match with the nonce in the KDC-REQ-BODY.
          paChecksum              [3] OCTET STRING,
                   -- Contains the SHA1 checksum,
                                      -- performed over
                   -- KDC-REQ-BODY.
          ...
       }

       TrustedCertifiers ::= SEQUENCE OF OCTET STRING
                   -- The OCTET STRING contains a PKIX type Name encoded
                   -- according to [RFC3280].

       CertificateIndex ::= OCTET STRING
                   -- Contains a CMS type IssuerAndSerialNumber encoded
                   -- according to [RFC3852].

       KRB5PrincipalName ::= SEQUENCE {
           realm                   [0] Realm,
           principalName           [1] PrincipalName
       }

       InitialVerifiedCAs ::= SEQUENCE OF SEQUENCE {
          ca                      [0] Name,
          Validated IMPLICIT OCTET STRING,
                   -- Contains a PKIX type Name encoded according to
                   -- [RFC3280].
          validated               [1] BOOLEAN,
          ...
       }

       PA-PK-AS-REP ::= CHOICE {
          dhInfo                  [0] DHRepInfo,
          encKeyPack              [1] IMPLICIT WrapContentInfo, OCTET STRING,
                   -- Type Contains a CMS type ContentInfo encoded
                   -- according to [RFC3852].
                   -- The contentType field of the type ContentInfo is
                   -- id-envelopedData (1.2.840.113549.1.7.3).
                   -- The content field is an EnvelopedData.
                   -- Content The contentType field for the type EnvelopedData
                   -- is id-signedData (1.2.840.113549.1.7.2).
                   -- The eContentType field for the inner type
                   -- SignedData over (when unencrypted) is id-pkrkeydata
                   -- (1.2.840.113549.1.7.3) and the eContent field
                   -- contains the DER encoding of the type
                   -- ReplyKeyPack.
                   -- ReplyKeyPack (defined below). is defined below.
          ...
       }

       DHRepInfo ::= SEQUENCE {
          dhSignedData            [0] ContentInfo, IMPLICIT OCTET STRING,
                   -- Type Contains a CMS type ContentInfo encoded according
                   -- to [RFC3852].
                   -- The contentType field of the type ContentInfo is
                   -- id-signedData (1.2.840.113549.1.7.2), and the
                   -- content field is a SignedData.
                   -- Content The eContentType field for the type SignedData is KDCDHKeyInfo
                   -- (defined below). id-pkdhkeydata (1.3.6.1.5.2.3.2), and the
                   -- eContent field contains the DER encoding of the
                   -- type KDCDHKeyInfo.
                   -- KDCDHKeyInfo is defined below.
          serverDHNonce           [1] DHNonce OPTIONAL
                   -- Present if and only if dhKeyExpiration is
                   -- present.
       }

       KDCDHKeyInfo ::= SEQUENCE {
          subjectPublicKey        [0] BIT STRING,
                   -- Equals KDC's public exponent
                                      -- (g^a key, y = g^x mod p). p.
                   -- INTEGER MUST be ASN.1 encoded as payload an INTEGER;
                   -- This encoding is then used as the contents
                   -- (i.e., the value) of this BIT STRING. STRING field.
          nonce                   [1] INTEGER (0..4294967295),
                   -- Contains the nonce in the PKAuthenticator of the
                   -- request if cached DH keys are NOT used,
                   -- 0 otherwise.
          dhKeyExpiration         [2] KerberosTime OPTIONAL,
                   -- Expiration time for KDC's cached values, present
                   -- if and only if cached values. DH keys are used.  If this field
                   -- field is omitted then the
                                      -- serverDHNonce field
                   -- MUST also
                                      -- be omitted.
          ...
       }

       ReplyKeyPack ::= SEQUENCE {
          replyKey                [0] EncryptionKey,
                   -- Defined in [CLAR].
                                      -- Used Contains the session key used to encrypt main reply.
                                      -- MUST be at least as strong
                                      -- as session key.  (Using the
                   -- same enctype and a strong
                                      -- prng should suffice, if no
                                      -- stronger encryption system
                                      -- is available.) enc-part field in the AS-REP.
          nonce                   [1] INTEGER (0..4294967295),
                   -- Contains the nonce in
                                      -- the KDCDHKeyInfo. PKAuthenticator of the
                   -- request.

          ...
       }

       TD-DH-PARAMETERS ::= SEQUENCE OF DomainParameters
                   -- Contains a list of Diffie-Hellman group
                   -- parameters in decreasing preference order.
       END

Intellectual Property Statement

   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.

   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.

   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.

Disclaimer of Validity

   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.

Copyright Statement

   Copyright (C) The Internet Society (2004). (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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.