Kitten Working Group L. Hornquist Astrand
Internet-Draft Apple, Inc
Updates: 4556 (if approved) L. Zhu
Intended status: Standards Track Microsoft Corporation
Expires: October 4, 2015 M. Wasserman
Painless Security
W. Mills, Ed.
Microsoft Corporation
April 2, 2015

PKINIT Algorithm Agility
draft-ietf-kitten-pkinit-alg-agility-00.txt

Abstract

This document updates PKINIT, as defined in RFC 4556, to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable.

These changes provide preemptive protection against vulnerabilities discovered in the future against any specific cryptographic algorithm, and allow incremental deployment of newer algorithms.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on October 4, 2015.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.


Table of Contents

1. Introduction

This document updates PKINIT [RFC4556] to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable.

These changes provide preemptive protection against vulnerabilities discovered in the future against any specific cryptographic algorithm, and allow incremental deployment of newer algorithms.

In August 2004, Xiaoyun Wang's research group reported MD4 [RFC6150] collisions generated using hand calculation [WANG04], alongside attacks on later hash function designs in the MD4, MD5 [RFC1321] and SHA [RFC6234] family. These attacks and their consequences are discussed in [RFC6194]. These discoveries challenged the security of protocols relying on the collision resistance properties of these hashes.

The Internet Engineering Task Force (IETF) called for actions to update existing protocols to provide crypto algorithm agility so that protocols support multiple cryptographic algorithms (including hash functions) and provide clean, tested transition strategies between algorithms.

This document updates PKINIT to provide crypto algorithm agility. Several protocol structures used in the [RFC4556] protocol are either tied to SHA-1, or do not support negotiation or discovery, but are instead based on local policy. The following concerns have been addressed in this update:

To address these concerns, new key derivation functions (KDFs), identified by object identifiers, are defined. The PKINIT client provides a list of KDFs in the request and the Key Distribution Center (KDC) picks one in the response, thus a mutually-supported KDF is negotiated.

Furthermore, structures are defined to allow the client to discover the Cryptographic Message Syntax (CMS) [RFC5652] digest algorithms supported by the KDC for signing the pre-authentication data and signing the client X.509 certificate.

2. Requirements Notation

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

3. paChecksum Agility

The paChecksum defined in Section 3.2.1 of [RFC4556] provides a cryptographic binding between the client's pre-authentication data and the corresponding Kerberos request body. This also prevents the KDC body from being tampered with. SHA-1 is the only allowed checksum algorithm defined in [RFC4556]. This facility relies on the collision resistance properties of the SHA-1 checksum [RFC6234].

When the reply key delivery mechanism is based on public key encryption as described in Section 3.2.3. of [RFC4556], the asChecksum in the KDC reply provides the binding between the pre- authentication and the ticket request and response messages, and integrity protection for the unauthenticated clear text in these messages. However, if the reply key delivery mechanism is based on the Diffie-Hellman key agreement as described in Section 3.2.3.1 of [RFC4556], the security provided by using SHA-1 in the paChecksum is weak. In this case, the new KDF selected by the KDC as described in Section 6 provides the cryptographic binding and integrity protection.

4. CMS Digest Algorithm Agility

When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as described In section 3.2.2 of [RFC4556], implementations comforming to this specification can OPTIONALLY send back a list of supported CMS types signifying the digest algorithms supported by the KDC, in the decreasing preference order. This is accomplished by including a TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the error data.

            
td-cms-digest-algorithms INTEGER ::= 111

          

The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains the ASN.1 Distinguished Encoding Rules (DER) [X680] [X690] encoded TD-CMS-DIGEST-ALGORITHMS-DATA structure defined as follows:

TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
    AlgorithmIdentifier
        -- Contains the list of CMS algorithm [RFC5652]
        -- identifiers that identify the digest algorithms
        -- acceptable by the KDC for signing CMS data in
        -- the order of decreasing preference.

          

This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS can facilitate trouble-shooting when none of the digest algorithms supported by the client is supported by the KDC.

5. X.509 Certificate Signer Algorithm Agility

td-cert-digest-algorithms INTEGER ::= 112

TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
        allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
                   -- Contains the list of CMS algorithm [RFC5652]
                   -- identifiers that identify the digest algorithms
                   -- that are used by the CA to sign the client's
                   -- X.509 certificate and acceptable by the KDC in
                   -- the process of validating the client's X.509
                   -- certificate, in the order of decreasing
                   -- preference.
        rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,
                   -- This identifies the digest algorithm that was
                   -- used to sign the client's X.509 certificate and
                   -- has been rejected by the KDC in the process of
                   -- validating the client's X.509 certificate
                   -- [RFC5280].
        ...
}

          

When the client's X.509 certificate is rejected and the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as described in section 3.2.2 of [RFC4556], conforming implementations can OPTIONALLY send a list of digest algorithms acceptable by the KDC for use by the Certificate Authority (CA) in signing the client's X.509 certificate, in the decreasing preference order. This is accomplished by including a TD_CERT_DIGEST_ALGORITHMS typed data element in the error data. The corresponding data contains the ASN.1 DER encoding of the structure TD-CERT-DIGEST-ALGORITHMS-DATA defined as follows: [RFC5652] identifiers that identify digest algorithms that are used by the CA to sign the client's X.509 certificate and acceptable by the KDC in the process of validating the client's X.509 certificate, in the order of decreasing preference. The rejectedAlgorithm field identifies the signing algorithm for use in signing the client's X.509 certificate that has been rejected by the KDC in the process of validating the client's certificate [RFC5280].

6. KDF agility

Based on [RFC3766] and [X9.42], Section 3.2.3.1 of [RFC4556] defines a Key Derivation Function (KDF) that derives a Kerberos protocol key based on the secret value generated by the Diffie-Hellman key exchange. This KDF requires the use of SHA-1 [RFC6234].

New KDFs defined in this document based on [SP80056A] can be used in conjunction with any hash functions.

A new KDF is identified by an object identifier. The following KDF object identifiers are defined:

id-pkinit OBJECT IDENTIFIER ::=
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) kerberosv5(2) pkinit (3) }
    -- Defined in RFC 4556 and quoted here for the reader.

id-pkinit-kdf OBJECT IDENTIFIER      ::= { id-pkinit kdf(6) }
    -- PKINIT KDFs

id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER
    ::= { id-pkinit-kdf sha1(1) }
    -- SP800-56A ASN.1 structured hash based KDF using SHA-1

id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER
    ::= { id-pkinit-kdf sha256(2) }
    -- SP800-56A ASN.1 structured hash based KDF using SHA-256

id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER
    ::= { id-pkinit-kdf sha512(3) }
    -- SP800-56A ASN.1 structured hash based KDF using SHA-512

id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER
    ::= { id-pkinit-kdf sha384(4) }
    -- SP800-56A ASN.1 structured hash based KDF using SHA-384

          

Where id-pkinit is defined in [RFC4556]. The id-pkinit-kdf-ah-sha1 KDF is the ASN.1 structured hash based KDF (HKDF) [SP80056A] that uses SHA-1 [RFC6234] as the hash function. Similarly id-pkinit-kdf-ah-sha256 and id-pkinit-kdf-ah-sha512 are the ASN.1 structured HKDF using SHA-256 [RFC6234] and SHA-512 [RFC6234] respectively.

To name the input parameters, an abbreviated version of the ASN.1 version of the KDF from [SP80056A] is described below, use [SP80056A] for the full reference.

  1. reps = ceiling (keydatalen/hash length (H))
  2. Initialize a 32-bit, big-endian bit string counter as 1.
  3. For i = 1 to reps by 1, do the following:
    1. Compute Hashi = H(counter || Z || OtherInfo).
    2. Increment counter (modulo 2^32)

  4. Set key_material = Hash1 || Hash2 || ... so that length of key is K bits.
  5. The above ASN.1 structured [SP80056A] HKDF produces a bit string of length K in bits as the keying material, and then the AS reply key is the output of random-to-key() [RFC3961] using that returned keying material as the input.

The input parameters for these KDFs are provided as follows:

OtherInfo ::= SEQUENCE { 
        algorithmID   AlgorithmIdentifier, 
        partyUInfo     [0] OCTET STRING, 
        partyVInfo     [1] OCTET STRING, 
        suppPubInfo    [2] OCTET STRING OPTIONAL, 
        suppPrivInfo   [3] OCTET STRING OPTIONAL 
}

          

The structure for OtherInfo is defined as follows:

PkinitSuppPubInfo ::= SEQUENCE {
       enctype           [0] Int32,
              -- The enctype of the AS reply key
       as-REQ            [1] OCTET STRING,
           -- This contains the AS-REQ in the request.
       pk-as-rep         [2] OCTET STRING,
           -- Contains the DER encoding of the type
           -- PA-PK-AS-REP [RFC4556] in the KDC reply.
       ...
}

          

The structure PkinitSuppPubInfo is defined as follows: [RFC4120]. The as-REQ field contains the DER encoding of the type AS-REQ [RFC4120] in the request sent from the client to the KDC. Note that the as-REQ field does not include the wrapping 4 octet length field when TCP is used. The pk-as-rep field contains the DER encoding of the type PA-PK-AS-REP [RFC4556] in the KDC reply. The PkinitSuppPubInfo provides a cryptographic bindings between the pre-authentication data and the corresponding ticket request and response, thus addressing the concerns described in Section 3.

The KDF is negotiated between the client and the KDC. The client sends an unordered set of supported KDFs in the request, and the KDC picks one from the set in the reply.

AuthPack ::= SEQUENCE {
       pkAuthenticator   [0] PKAuthenticator,
       clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
       supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
                OPTIONAL,
       clientDHNonce     [3] DHNonce OPTIONAL,
       ...,
       supportedKDFs     [4] SEQUENCE OF KDFAlgorithmId OPTIONAL,
           -- Contains an unordered set of KDFs supported by the
           -- client.
       ...
}

KDFAlgorithmId ::= SEQUENCE {
       kdf-id            [0] OBJECT IDENTIFIER,
           -- The object identifier of the KDF
       ...
}

          

To acomplish this, the AuthPack structure in [RFC4556] is extended as follows:

The KDFAlgorithmId structure contains an object identifier that identifies a KDF. The algorithm of the KDF and its parameters are defined by the corresponding specification of that KDF.

DHRepInfo ::= SEQUENCE {
        dhSignedData         [0] IMPLICIT OCTET STRING,
        serverDHNonce        [1] DHNonce OPTIONAL,
        ...,
        kdf                  [2] KDFAlgorithmId OPTIONAL,
            -- The KDF picked by the KDC.
        ...
}

          

The DHRepInfo structure in [RFC4556] is extended as follows:

If the supportedKDFs field is not present in the request, the kdf field in the reply MUST be absent.

If the client fills the supportedKDFs field in the request, but the kdf field in the reply is not present, the client can deduce that the KDC is not updated to conform with this specification. In that case, it is a matter of local policy on the client whether to reject the reply when the kdf field is absent in the reply.

Implementations comforming to this specification MUST support id-pkinit-kdf-ah-sha256.

This document introduces the following new PKINIT error code:

If no acceptable KDF is found, the error KDC_ERR_NO_ACCEPTABLE_KDF (100) will be returned..

7. Test vectors

This section contains test vectors for the KDF defined above.

7.1. Common Inputs

Z: Length = 256 bytes, Hex Representation = (All Zeros)
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 000000000 00000000 00000000 00000000

client: Length = 9 bytes, ASCII Representation = lha@SU.SE

server: Length = 18 bytes, ASCII Representation = krbtgt/SU.SE@SU.SE

as-req: Length = 10 bytes, Hex Representation =
AAAAAAAA AAAAAAAA AAAA

pk-as-rep:  Length = 9 bytes, Hex Representation =
BBBBBBBB BBBBBBBB BB

ticket: Length =  55 bytes, Hex Representation =
61353033 A0030201 05A1071B 0553552E 5345A210 300EA003 020101A1 0730051B
036C6861 A311300F A0030201 12A20804 0668656A 68656A

            

7.2. Test Vector for SHA-1, enctype 18

7.2.1. Specific Inputs

algorithm-id: (id-pkinit-kdf-ah-sha1) Length = 8 bytes, Hex 
Representation = 2B060105 02030601

enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal
Representation = 18

              

7.2.2. Outputs

key-material: Length = 32 bytes, Hex Representation =
E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD

key: Length = 32 bytes, Hex Representation =
E6AB38C9 413E035B B079201E D0B6B73D 8D49A814 A737C04E E6649614 206F73AD

              

7.3. Test Vector for SHA-256, enctype

7.3.1. Specific Inputs

algorithm-id: (id-pkinit-kdf-ah-sha256) Length = 8 bytes, Hex 
Representation = 2B060105 02030602

enctype: (aes256-cts-hmac-sha1-96) Length = 1 byte, Decimal
Representation = 18

              

7.3.2. Outputs

key-material: Length = 32 bytes, Hex Representation =
77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5

key: Length = 32 bytes, Hex Representation =
77EF4E48 C420AE3F EC75109D 7981697E ED5D295C 90C62564 F7BFD101 FA9bC1D5

              

7.4. Test Vector for SHA-512, enctype

7.4.1. Specific Inputs

algorithm-id: (id-pkinit-kdf-ah-sha512) Length = 8 bytes, Hex 
Representation = 2B060105 02030603

enctype: (des3-cbc-sha1-kd) Length = 1 byte, Decimal Representation = 16

              

7.4.2. Outputs

key-material: Length = 24 bytes, Hex Representation =
D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6

key: Length = 32 bytes, Hex Representation =
D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6

              

8. Security Considerations

This document describes negotiation of checksum types, key derivation functions and other cryptographic functions. If negotiation is done unauthenticated, care MUST be taken to accept only acceptable values.

9. Acknowledgements

Jeffery Hutzelman, Shawn Emery, Tim Polk and Kelley Burgin reviewed the document and provided suggestions for improvements.

10. IANA Considerations

IANA is requested to update the following registrations in the Kerberos Pre-authentication and Typed Data Registry created by section 7.1 of RFC 6113 to refer to this specification. These values were reserved for this specification in the initial registrations.

      
            TD-CMS-DIGEST-ALGORITHMS   111  [ALG-AGILITY]
            TD-CERT-DIGEST-ALGORITHMS  112  [ALG-AGILITY]

          

11. References

11.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.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R. and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[SP80056A] Barker, E., Don, D. and M. Smid, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", March 2006.
[X680] ITU, "ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", November 2008.
[X690] ITU, "ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", November 2008.

11.2. Informative References

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", RFC 6150, March 2011.
[RFC6194] Polk, T., Chen, L., Turner, S. and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, March 2011.
[WANG04] Wang, X., Lai, X., Fheg, D., Chen, H. and X. Yu, "Cryptanalysis of Hash functions MD4 and RIPEMD", August 2004.
[X9.42] ANSI, "Public Key Cryptography for the Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography", 2003.

Appendix A. PKINIT ASN.1 Module

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

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

   Ticket, Int32, Realm, EncryptionKey, Checksum
       FROM KerberosV5Spec2 { iso(1) identified-organization(3)
         dod(6) internet(1) security(5) kerberosV5(2)
         modules(4) krb5spec2(2) }
         -- as defined in RFC 4120.

   PKAuthenticator, DHNonce, id-pkinit
       FROM KerberosV5-PK-INIT-SPEC {
         iso(1) identified-organization(3) dod(6) internet(1)
         security(5) kerberosV5(2) modules(4) pkinit(5) };
         -- as defined in RFC 4556.

id-pkinit-kdf OBJECT IDENTIFIER      ::= { id-pkinit kdf(6) }
    -- PKINIT KDFs

id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER
    ::= { id-pkinit-kdf sha1(1) }
    -- SP800-56A ASN.1 structured hash based KDF using SHA-1

id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER
    ::= { id-pkinit-kdf sha256(2) }
    -- SP800-56A ASN.1 structured hash based KDF using SHA-256

id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER
    ::= { id-pkinit-kdf sha512(3) }
    -- SP800-56A ASN.1 structured hash based KDF using SHA-512

id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER
    ::= { id-pkinit-kdf sha384(4) }
    -- SP800-56A ASN.1 structured hash based KDF using SHA-384

TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
    AlgorithmIdentifier
        -- Contains the list of CMS algorithm [RFC5652]
        -- identifiers that identify the digest algorithms
        -- acceptable by the KDC for signing CMS data in
        -- the order of decreasing preference.

TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
       allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
           -- Contains the list of CMS algorithm [RFC5652]
           -- identifiers that identify the digest algorithms
           -- that are used by the CA to sign the client's
           -- X.509 certificate and acceptable by the KDC in
           -- the process of validating the client's X.509
           -- certificate, in the order of decreasing
           -- preference.
       rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL,
           -- This identifies the digest algorithm that was
           -- used to sign the client's X.509 certificate and
           -- has been rejected by the KDC in the process of
           -- validating the client's X.509 certificate
           -- [RFC5280].
       ...
}

OtherInfo ::= SEQUENCE { 
        algorithmID   AlgorithmIdentifier, 
        partyUInfo     [0] OCTET STRING, 
        partyVInfo     [1] OCTET STRING, 
        suppPubInfo    [2] OCTET STRING OPTIONAL, 
        suppPrivInfo   [3] OCTET STRING OPTIONAL 
}

PkinitSuppPubInfo ::= SEQUENCE {
       enctype           [0] Int32,
           -- The enctype of the AS reply key.
       as-REQ            [1] OCTET STRING,
           -- This contains the AS-REQ in the request.
       pk-as-rep         [2] OCTET STRING,
           -- Contains the DER encoding of the type
           -- PA-PK-AS-REP [RFC4556] in the KDC reply.
       ...
}

AuthPack ::= SEQUENCE {
       pkAuthenticator   [0] PKAuthenticator,
       clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
       supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
                OPTIONAL,
       clientDHNonce     [3] DHNonce OPTIONAL,
       ...,
       supportedKDFs     [4] SEQUENCE OF KDFAlgorithmId OPTIONAL,
           -- Contains an unordered set of KDFs supported by the
           -- client.
       ...
}

KDFAlgorithmId ::= SEQUENCE {
       kdf-id            [0] OBJECT IDENTIFIER,
           -- The object identifier of the KDF
       ...
}

DHRepInfo ::= SEQUENCE {
       dhSignedData      [0] IMPLICIT OCTET STRING,
       serverDHNonce     [1] DHNonce OPTIONAL,
       ...,
       kdf               [2] KDFAlgorithmId OPTIONAL,
           -- The KDF picked by the KDC.
       ...
}
END

          

Authors' Addresses

Love Hornquist Astrand Apple, Inc Cupertino, CA, USA EMail: lha@apple.com
Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA, 98052 USA EMail: lzhu@microsoft.com
Margaret Wasserman Painless Security 356 Abbott Street North Andover, MA 01845 USA Phone: +1 781 405-7464 EMail: mrw@painless-security.com URI: http://www.painless-security.com
William J. Mills (editor) Microsoft Corporation 3210 Porter Dr. Palo Alto, CA 94304 USA EMail: wimills@microsoft.com