One document matched: draft-ietf-krb-wg-pkinit-alg-agility-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC4120 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml'>
<!ENTITY RFC4346 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml'>
<!ENTITY RFC1964 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1964.xml'>
<!ENTITY RFC2743 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2743.xml'>
<!ENTITY RFC4556 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4556.xml'>
<!ENTITY RFC3852 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3852.xml'>
<!ENTITY RFC1320 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1320.xml'>
<!ENTITY RFC1321 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1321.xml'>
<!ENTITY RFC4634 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4634.xml'>
<!ENTITY RFC3280 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3280.xml'>
<!ENTITY RFC3961 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3961.xml'>
<!ENTITY RFC3766 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3766.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes"?>
<rfc ipr='full3978' updates="4556" category="std" docName=" draft-ietf-krb-wg-pkinit-alg-agility-03">
<front><title abbrev="PK-INIT Crypto Agility">PK-INIT Cryptographic Algorithm Agility</title>
<author initials="L.H." surname="Astrand" fullname="Love Hornquist Astrand">
<organization>Stockholm University</organization>
<address><postal>
<street>SE-106 91</street>
<city>Stockholm</city>
<country>Sweden</country>
</postal>
<email>ha@it.su.se</email></address>
</author>
<author initials="L." surname="Zhu" fullname="Larry Zhu">
<organization>Microsoft Corporation</organization>
<address><postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>
<email>lzhu@microsoft.com</email></address>
</author>
<date month="July" year="2007"></date>
<area>Security</area><workgroup>NETWORK WORKING GROUP</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>The PK-INIT defined in RFC 4556 is examined and updated to remove
protocol structures tied to specific cryptographic algorithms. The affinity to SHA
as the check-sum algorithm in the authentication request is analyzed.
The PK-INIT 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.</t>
<t>These changes provide protection preemptively against vulnerabilities
discovered in the future against any specific cryptographic algorithm, and
allow incremental deployment of newer algorithms. </t>
</abstract>
</front><middle>
<section anchor="introduction" title="Introduction">
<t>In August 2004, Xiaoyun Wang's research group reported MD4 <xref target="RFC1320"/> collisions
generated using hand calculation [WANG04] alongside attacks on later hash function designs in the MD4, MD5 <xref target="RFC1321"/> and SHA <xref target="RFC4634"/> family.
Implementations based on Wang's algorithm can find collisions in real time.
These discoveries challenged the security
for protocols relying on the collision resistance properties
of these hashes, for example one can forge a digital signature when SHA-1 <xref target="RFC4634"/> is
the digest algorithm. A more far reaching side effect of these
recent events, however, is that it is now generally considered flawed or
distasteful at least if protocols are designed to use only specific
algorithms.</t>
<t>The Internet Engineer Task Force (IETF) called for actions to update existing protocols to provide
crypto algorithm agility in order to untie protocols with specific
algorithms. The idea is that if the protocol has crypto algorithm
agility, and when a new vulnerability specific to an algorithm is
discovered, this algorithm can be disabled via protocol negotiation
quickly, thus we can avoid the wait for the multi-year
standardization and implementation efforts to update the protocols. In additon, crypto agility allows deployment
of new crypto algorithms to be done incrementally, rather than requring a
"flag day" on which the change must be deployed everywhere at the
same time in order to maintain interoperability
</t>
<t>This document is to update PK-INIT <xref target="RFC4556"/> to provide crypto algorithm
agility. Several protocol structures used in the <xref target="RFC4556"/> protocol
are either tied to SHA-1, or require the algorithms not negotiated but rather based on
local policy. The following concerns have been addressed: </t>
<t> <list style="symbols">
<t> The checksum algorithm in the
authentication request is hardwired to use SHA-1 <xref target="RFC4634"/>.<vspace blankLines="1"/></t>
<t> The acceptable
digest algorithms for signing the authentication data are not
discoverable.<vspace blankLines="1"/></t>
<t>The key derivation function in Section 3.2.3 is
hardwired to use SHA-1.<vspace blankLines="1"/> </t>
<t>The acceptable digest algorithms for
signing the client X.509 certificates are not discoverable.</t></list>
</t>
<t>To accomplish these, new key derivation functions (KDFs) identifiable by object identifiers are defined.
The PKINIT client provides a list of KDFs in the request and
the KDC picks one in the response, thus a mutually-supported KDF is negotiated.</t>
<t>Furthermore, structures are defined to allow the client discover the Cryptographic Message Syntax (CMS) <xref target="RFC3852"/>
digest algorithms supported by the KDC for signing the pre-authentication
data and signing the client X.509 certificate.</t>
</section>
<section title="Requirements Notation" toc="default">
<t>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 <xref
target="RFC2119" pageno="false" format="default"></xref>.</t>
</section>
<section anchor="pachk" title="paChecksum Agility">
<t>The paChecksum defined in Section 3.2.1 of <xref target="RFC4556"/> provides a cryptographic
bindings between the client's pre-authentication data and the corresponding Kerberos request body. This also prevents the KDC body
from being tempered with. SHA-1 is the only allowed checksum
algorithm defined in <xref target="RFC4556"/>. This facility relies the collision
resistance properties of the SHA-1 checksum <xref target="RFC4634"/>. </t>
<t>When the reply key delivery mechanism is based on public key encryption as described in Section 3.2.3. of <xref target="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 <xref target="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 <xref target="kdf"/> provides the
cryptographic binding and integrity protection.
</t>
</section>
<section title="CMS Digest Algorithm Agility">
<t> When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned
as described In section 3.2.2 of <xref target="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.</t>
<figure>
<artwork>
TD_CMS_DATA_DIGEST_ALGORITHMS 111
</artwork>
</figure>
<t>
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:</t>
<figure>
<artwork>
TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
AlgorithmIdentifier
-- Contains the list of CMS algorithm [RFC3852]
-- identifiers that identify the digest algorithms
-- acceptable by the KDC for signing CMS data in
-- the order of decreasing preference.
</artwork>
</figure>
<t>The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy
digest algorithms supported by the KDC.</t>
<t>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.</t>
</section>
<section title="X.509 Certificate Signer Algorithm Agility">
<t>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 <xref target="RFC4556"/>, conforming implementations can OPTIONALLY send a list of digest algorithms acceptable by the KDC for use by the 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:</t>
<figure>
<artwork>
TD_CERT_DIGEST_ALGORITHMS 112
TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE {
allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier,
-- Contains the list of CMS algorithm [RFC3852]
-- 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
-- [RFC3280].
...
}
</artwork>
</figure>
<t>The KDC fills in allowedAlgorithm field with the list of algorithm
<xref target="RFC3852"/> 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 <xref target="RFC3280"/>.</t>
</section>
<section anchor="kdf" title="KDF agility">
<t>Based on <xref target="RFC3766"/> and [X9.42],
Section 3.2.3.1 of <xref target="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 <xref target="RFC4634"/>.</t>
<t>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:</t>
<figure>
<artwork>
id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit 6}
-- PKINIT KDFs
id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER ::= { id-pkinit-kdf 1}
-- SP800 56A ASN.1 structured hash based KDF using SHA-1
id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER ::= { id-pkinit-kdf 2 }
-- SP800 56A ASN.1 structured hash based KDF using SHA-256
id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER ::= { id-pkinit-kdf 3 }
-- SP800 56A ASN.1 structured hash based KDF using SHA-512
</artwork>
</figure>
<t>Where id-pkinit is defined in <xref target="RFC4556"/>. The id-pkinit-kdf-ah-sha1 KDF is the
ASN.1 structured hash based KDF (HKDF) [SP80056A] that uses SHA-1 <xref target="RFC4634"/> 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 <xref target="RFC4634"/> and SHA-512 <xref target="RFC4634"/> respectively.
The common input parameters for these KDFs are provided as follows:</t>
<t>
<list style="symbols">
<t>The secret value is the shared secret value generated by the Diffie-Hellman exchange. The
Diffie-Hellman shared value is first padded with leading zeros such that the
size of the secret value in octets is the same as that of the
modulus, then represented as a string of octets in big-endian
order. <vspace blankLines="1"/></t>
<t>The key data length is K. K is the key-generation seed length in bits <xref target="RFC3961"/> for the Authentication Service (AS) reply
key. The enctype of the AS reply key is selected according to <xref target="RFC4120"/>.<vspace blankLines="1"/></t>
<t>The algorithm identifier input parameter is the identifier of the respective KDF. For example, this is id-pkinit-kdf-ah-sha1 if
the KDF is the [SP80056A] ASN.1 structured HKDF using SHA-1 as the hash. <vspace blankLines="1"/></t>
<t>The initiator identifier is an OCTET STRING that contains the ASN.1 DER encoding of the KRB5PrincipalName
<xref target="RFC4556"/> that identifies the client as specified in the AS-REQ <xref target="RFC4120"/> in the request.<vspace blankLines="1"/></t>
<t>The recipient identifier is an OCTET STRING that contains the ASN.1 DER encoding of the KRB5PrincipalName
<xref target="RFC4556"/> that identifies the TGS as specified in the AS-REQ <xref target="RFC4120"/> in the request.<vspace blankLines="1"/></t>
<t>The supplemental private information is absent (not used).<vspace blankLines="1"/></t>
<t> The supplemental public information is an OCTET STRING that contains the ASN.1 DER encoding of the structure PkinitSuppPubInfo as defined
later in this section. <vspace blankLines="1"/> </t>
<t>The hash length is 128 for id-pkinit-kdf-ah-sha1, 256 for id-pkinit-kdf-ah-sha256, and 512 for id-pkinit-kdf-ah-sha512.<vspace blankLines="1"/></t>
<t>The maximum hash input length is 2^64 in bits.</t>
</list>
</t>
<t>The structure PkinitSuppPubInfo is defined as follows:</t>
<figure>
<artwork>
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.
ticket [3] Ticket,
-- This is the ticket in the KDC reply.
...
}
</artwork>
</figure>
<t> The PkinitSuppPubInfo structure contains mutually-known public information specific
to the authentication exchange. The enctype field is the enctype of the AS reply key as selected according to <xref target="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 <xref target="RFC4556"/> in the KDC reply. The ticket field is filled
with the ticket in the KDC reply. The PkinitSuppPubInfo
provides a cryptographic
bindings between the pre-authentication data and the
corresponding ticket request and response, thus addresses the concerns described in <xref target="pachk"/>. </t>
<t>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() <xref target="RFC3961"/> using that returned keying material as the input.</t>
<t>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.
</t>
<t>
To acomplish this, the AuthPack structure in <xref target="RFC4556"/> is extended as follows:</t>
<figure>
<artwork>
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,
-- Contains the object identifier of the KDF.
...
}
</artwork>
</figure>
<t>The new field supportedKDFs contains an unordered set of KDFs supported by the client. </t>
<t> 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.</t>
<t> The DHRepInfo structure in <xref target="RFC4556"/> is extended as follows:</t>
<figure>
<artwork>
DHRepInfo ::= SEQUENCE {
dhSignedData [0] IMPLICIT OCTET STRING,
serverDHNonce [1] DHNonce OPTIONAL,
...,
kdf [2] KDFAlgorithmId OPTIONAL,
-- The KDF picked by the KDC.
...
}
</artwork>
</figure>
<t>
The new field kdf in the extended DHRepInfo structure identifies the KDF picked by the KDC. This kdf field MUST be filled
by the comforming KDC if the supportedKDFs field is present in the request, and it
MUST be one of the KDFs supported by the client as indicated in the request. Which KDF is chosen is a matter of the local policy on the KDC.</t>
<t>If the supportedKDFs field is not present in the request, the kdf field in the reply MUST be absent.</t>
<t>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.</t>
<t>Implementations comforming to this specification MUST support id-pkinit-kdf-ah-sha256.</t>
</section>
<section anchor="securityconsideration" title="Security Considerations" toc="default">
<t>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. </t>
</section>
<section title="Acknowledgements">
<t> Jeffery Hutzelman reviewed the document and provided suggestions for improvements.</t>
</section>
<section title="IANA Considerations">
<t>There is no action required for IANA.</t>
</section>
</middle>
<back>
<references title="Normative References">&RFC2119;&RFC4120;&RFC4556;&RFC3852;&RFC4634;&RFC3280;&RFC3961;
</references>
<references title="Informative References"> &RFC1320; &RFC1321; &RFC3766;
</references>
<section anchor="asnmod" title="PKINIT ASN.1 Module">
<figure>
<artwork>
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 3280.
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
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.
TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF
AlgorithmIdentifier
-- Contains the list of CMS algorithm [RFC3852]
-- 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 [RFC3852]
-- 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
-- [RFC3280].
...
}
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.
ticket [3] Ticket,
-- This is the ticket 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,
-- Contains 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
</artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:09:11 |