draft-ietf-kitten-pkinit-alg-agility-05.txt   draft-ietf-kitten-pkinit-alg-agility-06.txt 
Kitten Working Group L. Hornquist Astrand Kitten Working Group L. Hornquist Astrand
Internet-Draft Apple, Inc Internet-Draft Apple, Inc
Updates: 4556 (if approved) L. Zhu Updates: 4556 (if approved) L. Zhu
Intended status: Standards Track Microsoft Corporation Intended status: Standards Track Oracle Corporation
Expires: August 30, 2019 M. Wasserman Expires: September 7, 2019 M. Wasserman
Painless Security Painless Security
G. Hudson, Ed. G. Hudson, Ed.
MIT MIT
February 26, 2019 March 6, 2019
PKINIT Algorithm Agility PKINIT Algorithm Agility
draft-ietf-kitten-pkinit-alg-agility-05 draft-ietf-kitten-pkinit-alg-agility-06
Abstract Abstract
This document updates PKINIT, as defined in RFC 4556, to remove This document updates the Public Key Cryptography for Initial
Authentication in Kerberos standard (PKINIT) [RFC4556], to remove
protocol structures tied to specific cryptographic algorithms. The protocol structures tied to specific cryptographic algorithms. The
PKINIT key derivation function is made negotiable, and the digest PKINIT key derivation function is made negotiable, and the digest
algorithms for signing the pre-authentication data and the client's algorithms for signing the pre-authentication data and the client's
X.509 certificates are made discoverable. X.509 certificates are made discoverable.
These changes provide preemptive protection against vulnerabilities These changes provide preemptive protection against vulnerabilities
discovered in the future against any specific cryptographic discovered in the future against any specific cryptographic
algorithm, and allow incremental deployment of newer algorithms. algorithm, and allow incremental deployment of newer algorithms.
Status of This Memo Status of This Memo
skipping to change at page 1, line 43 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 30, 2019. This Internet-Draft will expire on September 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 41
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. paChecksum Agility . . . . . . . . . . . . . . . . . . . . . 4 3. paChecksum Agility . . . . . . . . . . . . . . . . . . . . . 4
4. CMS Digest Algorithm Agility . . . . . . . . . . . . . . . . 4 4. CMS Digest Algorithm Agility . . . . . . . . . . . . . . . . 4
5. X.509 Certificate Signer Algorithm Agility . . . . . . . . . 5 5. X.509 Certificate Signer Algorithm Agility . . . . . . . . . 5
6. KDF agility . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. KDF agility . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Interoperability . . . . . . . . . . . . . . . . . . . . . . 11 7. Interoperability . . . . . . . . . . . . . . . . . . . . . . 11
8. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Test vectors . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Common Inputs . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Common Inputs . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Test Vector for SHA-1, enctype 18 . . . . . . . . . . . . 12 8.2. Test Vector for SHA-1, enctype 18 . . . . . . . . . . . . 12
8.2.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12 8.2.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 12
8.2.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12 8.2.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 12
8.3. Test Vector for SHA-256, enctype . . . . . . . . . . . . 13 8.3. Test Vector for SHA-256, enctype . . . . . . . . . . . . 13
8.3.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13 8.3.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13
8.3.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13 8.3.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13
8.4. Test Vector for SHA-512, enctype . . . . . . . . . . . . 13 8.4. Test Vector for SHA-512, enctype . . . . . . . . . . . . 13
8.4.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13 8.4.1. Specific Inputs . . . . . . . . . . . . . . . . . . . 13
8.4.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13 8.4.2. Outputs . . . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 16 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This document updates PKINIT [RFC4556] to remove protocol structures The Public Key Cryptography for Initial Authentication in Kerberos
tied to specific cryptographic algorithms. The PKINIT key derivation (PKINIT) standard [RFC4556] defines several protocol structures that
function is made negotiable, the digest algorithms for signing the are either tied to SHA-1 [RFC6234], or do not support negotiation or
pre-authentication data and the client's X.509 certificates are made discovery, but are instead based on local policy:
discoverable.
These changes provide preemptive protection against vulnerabilities o The checksum algorithm in the authentication request is hardwired
discovered in the future against any specific cryptographic to use SHA-1.
algorithm, and allow incremental deployment of newer algorithms.
o The acceptable digest algorithms for signing the authentication
data are not discoverable.
o The key derivation function in Section 3.2.3.1 of [RFC4556] is
hardwired to use SHA-1.
o The acceptable digest algorithms for signing the client X.509
certificates are not discoverable.
In August 2004, Xiaoyun Wang's research group reported MD4 [RFC6150] In August 2004, Xiaoyun Wang's research group reported MD4 [RFC6150]
collisions generated using hand calculation [WANG04], alongside collisions generated using hand calculation [WANG04], alongside
attacks on later hash function designs in the MD4, MD5 [RFC1321] and attacks on later hash function designs in the MD4, MD5 [RFC1321] and
SHA [RFC6234] family. These attacks and their consequences are SHA [RFC6234] family. These attacks and their consequences are
discussed in [RFC6194]. These discoveries challenged the security of discussed in [RFC6194]. These discoveries challenged the security of
protocols relying on the collision resistance properties of these protocols relying on the collision resistance properties of these
hashes. hashes.
The Internet Engineering Task Force (IETF) called for actions to The Internet Engineering Task Force (IETF) called for actions to
update existing protocols to provide crypto algorithm agility so that update existing protocols to provide crypto algorithm agility so that
protocols support multiple cryptographic algorithms (including hash protocols support multiple cryptographic algorithms (including hash
functions) and provide clean, tested transition strategies between functions) and provide clean, tested transition strategies between
algorithms, as recommended by BCP 201 [RFC7696]. algorithms, as recommended by BCP 201 [RFC7696].
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:
o The checksum algorithm in the authentication request is hardwired
to use SHA-1 [RFC6234].
o The acceptable digest algorithms for signing the authentication
data are not discoverable.
o The key derivation function in Section 3.2.3.1 of [RFC4556] is
hardwired to use SHA-1.
o The acceptable digest algorithms for signing the client X.509
certificates are not discoverable.
To address these concerns, new key derivation functions (KDFs), To address these concerns, new key derivation functions (KDFs),
identified by object identifiers, are defined. The PKINIT client identified by object identifiers, are defined. The PKINIT client
provides a list of KDFs in the request and the Key Distribution provides a list of KDFs in the request and the Key Distribution
Center (KDC) picks one in the response, thus a mutually-supported KDF Center (KDC) picks one in the response, thus a mutually-supported KDF
is negotiated. is negotiated.
Furthermore, structures are defined to allow the client to discover Furthermore, structures are defined to allow the client to discover
the Cryptographic Message Syntax (CMS) [RFC5652] digest algorithms the Cryptographic Message Syntax (CMS) [RFC5652] digest algorithms
supported by the KDC for signing the pre-authentication data and supported by the KDC for signing the pre-authentication data and
signing the client X.509 certificate. signing the client X.509 certificate.
skipping to change at page 4, line 48 skipping to change at page 4, line 42
messages. However, if the reply key delivery mechanism is based on 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 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 [RFC4556], the security provided by using SHA-1 in the paChecksum is
weak, and nothing else cryptographically binds the AS request to the weak, and nothing else cryptographically binds the AS request to the
ticket response. In this case, the new KDF selected by the KDC as ticket response. In this case, the new KDF selected by the KDC as
described in Section 6 provides the cryptographic binding and described in Section 6 provides the cryptographic binding and
integrity protection. integrity protection.
4. CMS Digest Algorithm Agility 4. CMS Digest Algorithm Agility
When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned Section 3.2.2 of [RFC4556] is updated to add optional typed data to
as described in Section 3.2.2 of [RFC4556], implementations the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error. When a KDC
conforming to this specification can OPTIONALLY send back a list of implementation conforming to this specification returns this error
supported CMS types signifying the digest algorithms supported by the code, it MAY include in a list of supported CMS types signifying the
KDC, in the decreasing preference order. This is accomplished by digest algorithms supported by the KDC, in the decreasing preference
including a TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the order. This is accomplished by including a
error data. TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the error data.
td-cms-digest-algorithms INTEGER ::= 111 td-cms-digest-algorithms INTEGER ::= 111
The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains
the ASN.1 Distinguished Encoding Rules (DER) [X680] [X690] encoded the ASN.1 Distinguished Encoding Rules (DER) [X680] [X690] encoded
TD-CMS-DIGEST-ALGORITHMS-DATA structure defined as follows: TD-CMS-DIGEST-ALGORITHMS-DATA structure defined as follows:
TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
AlgorithmIdentifier AlgorithmIdentifier
-- Contains the list of CMS algorithm [RFC5652] -- Contains the list of CMS algorithm [RFC5652]
-- identifiers indicating the digest algorithms -- identifiers indicating the digest algorithms
-- acceptable to the KDC for signing CMS data in -- acceptable to the KDC for signing CMS data in
-- the order of decreasing preference. -- the order of decreasing preference.
skipping to change at page 5, line 29 skipping to change at page 5, line 24
The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy
digest algorithms supported by the KDC. digest algorithms supported by the KDC.
This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS
can facilitate trouble-shooting when none of the digest algorithms can facilitate trouble-shooting when none of the digest algorithms
supported by the client is supported by the KDC. supported by the client is supported by the KDC.
5. X.509 Certificate Signer Algorithm Agility 5. X.509 Certificate Signer Algorithm Agility
When the client's X.509 certificate is rejected and the Section 3.2.2 of [RFC4556] is updated to add optional typed data to
KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as the KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. When a KDC conforming
described in Section 3.2.2 of [RFC4556], implementations conforming to this specification returns this error, it MAY send a list of
to this specification can OPTIONALLY send a list of digest algorithms digest algorithms acceptable to the KDC for use by the Certificate
acceptable to the KDC for use by the Certificate Authority (CA) in Authority (CA) in signing the client's X.509 certificate, in the
signing the client's X.509 certificate, in the decreasing preference decreasing preference order. This is accomplished by including a
order. This is accomplished by including a TD_CERT_DIGEST_ALGORITHMS TD_CERT_DIGEST_ALGORITHMS typed data element in the error data. The
typed data element in the error data. The corresponding data corresponding data contains the ASN.1 DER encoding of the structure
contains the ASN.1 DER encoding of the structure TD-CERT-DIGEST- TD-CERT-DIGEST-ALGORITHMS-DATA defined as follows:
ALGORITHMS-DATA defined as follows:
td-cert-digest-algorithms INTEGER ::= 112 td-cert-digest-algorithms INTEGER ::= 112
TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
-- Contains the list of CMS algorithm [RFC5652] -- Contains the list of CMS algorithm [RFC5652]
-- identifiers indicating the digest algorithms -- identifiers indicating the digest algorithms
-- that are used by the CA to sign the client's -- that are used by the CA to sign the client's
-- X.509 certificate and are acceptable to the KDC -- X.509 certificate and are acceptable to the KDC
-- in the process of validating the client's X.509 -- in the process of validating the client's X.509
skipping to change at page 6, line 36 skipping to change at page 6, line 36
algorithm [RFC5652] identifiers indicating digest algorithms that are algorithm [RFC5652] identifiers indicating digest algorithms that are
used by the CA to sign the client's X.509 certificate and are used by the CA to sign the client's X.509 certificate and are
acceptable to the KDC in the process of validating the client's X.509 acceptable to the KDC in the process of validating the client's X.509
certificate, in the order of decreasing preference. The certificate, in the order of decreasing preference. The
rejectedAlgorithm field identifies the signing algorithm for use in rejectedAlgorithm field identifies the signing algorithm for use in
signing the client's X.509 certificate that has been rejected by the signing the client's X.509 certificate that has been rejected by the
KDC in the process of validating the client's certificate [RFC5280]. KDC in the process of validating the client's certificate [RFC5280].
6. KDF agility 6. KDF agility
Based on [RFC3766] and [X9.42], Section 3.2.3.1 of [RFC4556] defines Section 3.2.3.1 of [RFC4556] is updated to define additional Key
a Key Derivation Function (KDF) that derives a Kerberos protocol key Derivation Functions (KDFs) to derive a Kerberos protocol key based
based on the secret value generated by the Diffie-Hellman key on the secret value generated by the Diffie-Hellman key exchange.
exchange. This KDF requires the use of SHA-1 [RFC6234]. Section 3.2.1 of [RFC4556] is updated to add a new field to the
AuthPack structure to indicate which new KDFs are supported by the
client. Section 3.2.3 of [RFC4556] is updated to add a new field to
the DHRepInfo structure to indicate which KDF is selected by the KDC.
The KDF algorithm described in this document (based on [SP80056A]) The KDF algorithm described in this document (based on [SP80056A])
can be implemented using any cryptographic hash function. can be implemented using any cryptographic hash function.
A new KDF for PKINIT usage is identified by an object identifier. A new KDF for PKINIT usage is identified by an object identifier.
The following KDF object identifiers are defined: The following KDF object identifiers are defined:
id-pkinit OBJECT IDENTIFIER ::= id-pkinit OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosv5(2) pkinit (3) } security(5) kerberosv5(2) pkinit (3) }
skipping to change at page 11, line 20 skipping to change at page 11, line 20
exchange was subjected to a downgrade attack. It is a matter of exchange was subjected to a downgrade attack. It is a matter of
local policy on the client whether to reject the reply when the kdf local policy on the client whether to reject the reply when the kdf
field is absent in the reply; if compatibility with non-updated KDCs field is absent in the reply; if compatibility with non-updated KDCs
is not a concern, the reply should be rejected. is not a concern, the reply should be rejected.
Implementations conforming to this specification MUST support id- Implementations conforming to this specification MUST support id-
pkinit-kdf-ah-sha256. pkinit-kdf-ah-sha256.
7. Interoperability 7. Interoperability
An old client interoperating with a new KDC will not recognize a TD-
CMS-DIGEST-ALGORITHMS-DATA element in a
KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error, or a TD-CERT-
DIGEST-ALGORITHMS-DATA element in a
KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. Because the error data is
encoded as typed data, the client will ignore the unrecognized
elements.
An old KDC interoperating with a new client will not include a TD-
CMS-DIGEST-ALGORITHMS-DATA element in a
KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error, or a TD-CERT-
DIGEST-ALGORITHMS-DATA element in a
KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. To the client this
appears just as if a new KDC elected not to include a list of digest
algorithms.
An old client interoperating with a new KDC will not include the An old client interoperating with a new KDC will not include the
supportedKDFs field in the request. The KDC MUST omit the kdf field supportedKDFs field in the request. The KDC MUST omit the kdf field
in the reply and use the [RFC4556] KDF as expected by the client, or in the reply and use the [RFC4556] KDF as expected by the client, or
reject the request if local policy forbids use of the old KDF. reject the request if local policy forbids use of the old KDF.
A new client interoperating with an old KDC will include the A new client interoperating with an old KDC will include the
supportedKDFs field in the request; this field will be ignored as an supportedKDFs field in the request; this field will be ignored as an
unknown extension by the KDC. The KDC will omit the kdf field in the unknown extension by the KDC. The KDC will omit the kdf field in the
reply and will use the [RFC4556] KDF. The client can deduce from the reply and will use the [RFC4556] KDF. The client can deduce from the
omitted kdf field that the KDC is not updated to conform to this omitted kdf field that the KDC is not updated to conform to this
skipping to change at page 15, line 46 skipping to change at page 16, line 5
Rules: Specification of Basic Encoding Rules (BER), Rules: Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Encoding Canonical Encoding Rules (CER) and Distinguished Encoding
Rules (DER)", November 2008. Rules (DER)", November 2008.
12.2. Informative References 12.2. Informative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992, DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>. <https://www.rfc-editor.org/info/rfc1321>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, DOI 10.17487/RFC3766, April 2004,
<https://www.rfc-editor.org/info/rfc3766>.
[RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", [RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status",
RFC 6150, DOI 10.17487/RFC6150, March 2011, RFC 6150, DOI 10.17487/RFC6150, March 2011,
<https://www.rfc-editor.org/info/rfc6150>. <https://www.rfc-editor.org/info/rfc6150>.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<https://www.rfc-editor.org/info/rfc6194>. <https://www.rfc-editor.org/info/rfc6194>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms", Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<https://www.rfc-editor.org/info/rfc7696>. <https://www.rfc-editor.org/info/rfc7696>.
[WANG04] Wang, X., Lai, X., Fheg, D., Chen, H., and X. Yu, [WANG04] Wang, X., Lai, X., Fheg, D., Chen, H., and X. Yu,
"Cryptanalysis of Hash functions MD4 and RIPEMD", August "Cryptanalysis of Hash functions MD4 and RIPEMD", August
2004. 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 Appendix A. PKINIT ASN.1 Module
KerberosV5-PK-INIT-Agility-SPEC { KerberosV5-PK-INIT-Agility-SPEC {
iso(1) identified-organization(3) dod(6) internet(1) iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) pkinit(5) agility (1) security(5) kerberosV5(2) modules(4) pkinit(5) agility (1)
} DEFINITIONS EXPLICIT TAGS ::= BEGIN } DEFINITIONS EXPLICIT TAGS ::= BEGIN
IMPORTS IMPORTS
AlgorithmIdentifier, SubjectPublicKeyInfo AlgorithmIdentifier, SubjectPublicKeyInfo
FROM PKIX1Explicit88 { iso (1) FROM PKIX1Explicit88 { iso (1)
skipping to change at page 19, line 6 skipping to change at page 19, line 4
dhSignedData [0] IMPLICIT OCTET STRING, dhSignedData [0] IMPLICIT OCTET STRING,
serverDHNonce [1] DHNonce OPTIONAL, serverDHNonce [1] DHNonce OPTIONAL,
..., ...,
kdf [2] KDFAlgorithmId OPTIONAL, kdf [2] KDFAlgorithmId OPTIONAL,
-- The KDF picked by the KDC. -- The KDF picked by the KDC.
... ...
} }
END END
Authors' Addresses Authors' Addresses
Love Hornquist Astrand Love Hornquist Astrand
Apple, Inc Apple, Inc
Cupertino, CA Cupertino, CA
USA USA
Email: lha@apple.com Email: lha@apple.com
Larry Zhu Larry Zhu
Microsoft Corporation Oracle Corporation
One Microsoft Way 500 Oracle Parkway
Redmond, WA 98052 Redwood Shores, CA 94065
USA USA
Email: lzhu@microsoft.com Email: larryzhu@live.com
Margaret Wasserman Margaret Wasserman
Painless Security Painless Security
356 Abbott Street 356 Abbott Street
North Andover, MA 01845 North Andover, MA 01845
USA USA
Phone: +1 781 405-7464 Phone: +1 781 405-7464
Email: mrw@painless-security.com Email: mrw@painless-security.com
URI: http://www.painless-security.com URI: http://www.painless-security.com
 End of changes. 22 change blocks. 
73 lines changed or deleted 69 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/