One document matched: draft-ietf-krb-wg-pkinit-alg-agility-07.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc6150 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6150.xml'>
<!ENTITY rfc1321 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1321.xml'>
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc5280 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml'>
<!ENTITY rfc3766 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3766.xml'>
<!ENTITY rfc5652 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5652.xml'>
<!ENTITY rfc3961 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3961.xml'>
<!ENTITY rfc4120 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml'>
<!ENTITY rfc4556 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4556.xml'>
<!ENTITY rfc6234 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6234.xml'>
<!ENTITY rfc6194 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6194.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" ipr="pre5378Trust200902" updates="4556" docName="draft-ietf-krb-wg-pkinit-alg-agility-07.txt">
<front>
<title>PKINIT Algorithm Agility</title>
<author initials="L." surname="Hornquist Astrand" fullname="Love Hornquist Astrand">
<organization>Apple, Inc</organization>
<address>
<postal>
<street/>
<city>Cupertino, CA</city> <code/>
<country>USA</country>
</postal>
<email>lha@apple.com</email>
</address>
</author>
<author initials="L" surname="Zhu" fullname="Larry Zhu">
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond, WA</city> <code>98052</code>
<country>USA</country>
</postal>
<email>lzhu@microsoft.com</email>
</address>
</author>
<author initials="M." surname="Wasserman" fullname="Margaret Wasserman">
<organization>Painless Security</organization>
<address>
<postal>
<street>356 Abbott Street</street>
<city>North Andover</city> <region>MA</region>
<code>01845</code>
<country>USA</country>
</postal>
<phone>+1 781 405-7464</phone>
<email>mrw@painless-security.com</email>
<uri>http://www.painless-security.com</uri>
</address>
</author>
<date day="22" month="October" year="2012"/>
<area>Security</area>
<workgroup>Kerberos Working Group</workgroup>
<abstract>
<t>
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.
</t>
<t>
These changes provide preemptive protection against
vulnerabilities discovered in the future against any specific
cryptographic algorithm, and allow incremental deployment of
newer algorithms.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document updates PKINIT <xref target="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.
</t>
<t>
These changes provide preemptive protection against
vulnerabilities discovered in the future against any specific
cryptographic algorithm, and allow incremental deployment of
newer algorithms.
</t>
<t>
In August 2004, Xiaoyun Wang's research group reported MD4
<xref target="RFC6150"/> collisions generated using hand
calculation <xref target="WANG04"/>, alongside attacks on
later hash function designs in the MD4, MD5
<xref target="RFC1321"/> and SHA <xref target="RFC6234"/>
family. These attacks and their consequences are discussed in
<xref target="RFC6194"/>. These discoveries challenged the
security of protocols relying on the collision resistance
properties of these hashes.
</t>
<t>
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.
</t>
<t>
This document updates PKINIT to provide crypto algorithm
agility. Several protocol structures used in the
<xref target="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:
</t>
<t>
<list style="symbols">
<t>
The checksum algorithm in the authentication request is hardwired
to use SHA-1 <xref target="RFC6234"/>.
</t>
<t>
The acceptable digest algorithms for signing the authentication
data are not discoverable.
</t>
<t>
The key derivation function in Section 3.2.3 of
<xref target="RFC4556"/> is hardwired to use SHA-1.
</t>
<t>
The acceptable digest algorithms for signing the client X.509
certificates are not discoverable.
</t>
</list>
</t>
<t>
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.
</t>
<t>
Furthermore, structures are defined to allow the client to
discover the Cryptographic Message Syntax (CMS)
<xref target="RFC5652"/> 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">
<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"/>.</t>
</section>
<section anchor="paChecksum" title="paChecksum Agility">
<t>
The paChecksum defined in Section 3.2.1 of
<xref target="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 <xref target="RFC4556"/>. This
facility relies on the collision resistance properties of the
SHA-1 checksum <xref target="RFC6234"/>.
</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 Section 6 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>
<t>
<figure>
<artwork>
<![CDATA[
td-cms-digest-algorithms INTEGER ::= 111
]]>
</artwork>
</figure>
</t>
<t>
The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS
contains the ASN.1 Distinguished Encoding Rules (DER)
<xref target="X680"/> <xref target="X690"/> encoded
TD-CMS-DIGEST-ALGORITHMS-DATA structure defined as follows:
</t>
<t>
<figure>
<artwork><![CDATA[
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.
]]>
</artwork>
</figure>
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
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:
<figure>
<artwork><![CDATA[
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].
...
}
]]>
</artwork>
</figure>
The KDC fills in allowedAlgorithm field with the list of
algorithm <xref target="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
<xref target="RFC5280"/>.
</t>
</section>
<section anchor="KDF" title="KDF agility">
<t>
Based on <xref target="RFC3766"/> and <xref target="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="RFC6234"/>.
</t>
<t>
New KDFs defined in this document based on
<xref target="SP80056A"/> can be used in conjunction with any
hash functions.
</t>
<t>
A new KDF is identified by an object identifier. The
following KDF object identifiers are defined:
</t>
<t>
<figure>
<artwork><![CDATA[
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
id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER ::= { id-pkinit-kdf 4 }
-- SP800 56A ASN.1 structured hash based KDF using SHA-384
]]>
</artwork>
</figure>
</t>
<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) <xref target="SP80056A"/> that uses SHA-1
<xref target="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 <xref target="RFC6234"/>
and SHA-512 <xref target="RFC6234"/> respectively.
</t>
<t>
To name the input parameters, an abbreviated version of the
ASN.1 version of the KDF from <xref target="SP80056A"/> is
described below, use <xref target="SP80056A"/> for the full
reference.
<list style="numbers">
<t>
reps = ceiling (keydatalen/hash length (H))
</t>
<t>
Initialize a 32-bit, big-endian bit string counter as 1.
</t>
<t>
For i = 1 to reps by 1, do the following:
<list style="numbers">
<t>
Compute Hashi = H(counter || Z || OtherInfo).
</t>
<t>
Increment counter (modulo 2^32)
</t>
</list>
</t>
<t>
Set key_material = Hash1 || Hash2 || ... so that length of
key is K bits.
</t>
<t>
The above ASN.1 structured <xref target="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>
</list>
</t>
<t>
The input parameters for these KDFs are provided as follows:
</t>
<t>
<list style="symbols">
<t>
The key data length (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"/>.
</t>
<t>
The hash length (H) is 160 bits for id-pkinit-kdf-ah-sha1,
256 bits for id-pkinit-kdf-ah-sha256, 384 bits for
id-pkinit-kdf-ah-sha384 and 512 bits for
id-pkinit-kdf-ah-sha512.
</t>
<t>
The secret value (Z) 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.
</t>
<t>
The algorithm identifier (algorithmID) input parameter is
the identifier of the respective KDF. For example, this
is id-pkinit-kdf-ah-sha1 if the KDF is the
<xref target="SP80056A"/> ASN.1 structured HKDF using
SHA-1 as the hash.
</t>
<t>
The initiator identifier (partyUInfo) 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.
</t>
<t>
The recipient identifier (partyVInfo) 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.
</t>
<t>
The supplemental public information (suppPubInfo) is the
ASN.1 DER encoding of the structure PkinitSuppPubInfo as
defined later in this section.
</t>
<t>
The supplemental private information (suppPrivInfo) is absent.
</t>
<t>
The maximum hash input length is 2^64 in bits.
</t>
</list>
</t>
<t>
The structure for OtherInfo is defined as follows:
<figure>
<artwork><![CDATA[
OtherInfo ::= SEQUENCE {
algorithmID AlgorithmIdentifier,
partyUInfo [0] OCTET STRING,
partyVInfo [1] OCTET STRING,
suppPubInfo [2] OCTET STRING OPTIONAL,
suppPrivInfo [3] OCTET STRING OPTIONAL
}
]]>
</artwork>
</figure>
</t>
<t>
The structure PkinitSuppPubInfo is defined as follows:
<figure>
<artwork><![CDATA[
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.
...
}
]]>
</artwork>
</figure>
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
<xref target="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
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.
</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:
<figure>
<artwork><![CDATA[
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
...
}
]]>
</artwork>
</figure>
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:
<figure>
<artwork><![CDATA[
DHRepInfo ::= SEQUENCE {
dhSignedData [0] IMPLICIT OCTET STRING,
serverDHNonce [1] DHNonce OPTIONAL,
...,
kdf [2] KDFAlgorithmId OPTIONAL,
-- The KDF picked by the KDC.
...
}
]]>
</artwork>
</figure>
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>
<t>
This document introduces the following new PKINIT error code:
</t>
<t>
<list style="symbols">
<t>
KDC_ERR_NO_ACCEPTABLE_KDF 82
</t>
</list>
</t>
<t>
If no acceptable KDF is found, the error
KDC_ERR_NO_ACCEPTABLE_KDF (82) will be returned..
</t>
</section>
<section title="Test vectors">
<t>
This section contains test vectors for the KDF defined above.
</t>
<section title="Common Inputs">
<t>
<figure>
<artwork><![CDATA[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
]]>
</artwork>
</figure>
</t>
</section>
<section title="Test Vector for SHA-1, enctype 18">
<section title="Specific Inputs">
<t>
<figure>
<artwork><![CDATA[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
]]>
</artwork>
</figure>
</t>
</section>
<section title="Outputs">
<t>
<figure>
<artwork><![CDATA[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
]]>
</artwork>
</figure>
</t>
</section>
</section>
<section title="Test Vector for SHA-256, enctype ">
<section title="Specific Inputs">
<t>
<figure>
<artwork><![CDATA[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
]]>
</artwork>
</figure>
</t>
</section>
<section title="Outputs">
<t>
<figure>
<artwork><![CDATA[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
]]>
</artwork>
</figure>
</t>
</section>
</section>
<section title="Test Vector for SHA-512, enctype ">
<section title="Specific Inputs">
<t>
<figure>
<artwork><![CDATA[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
]]>
</artwork>
</figure>
</t>
</section>
<section title="Outputs">
<t>
<figure>
<artwork><![CDATA[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
]]>
</artwork>
</figure>
</t>
</section>
</section>
</section>
<section title="Security Considerations">
<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, Shawn Emery, Tim Polk and Kelley Burgin
reviewed the document and provided suggestions for
improvements.
</t>
</section>
<section title="IANA Considerations">
<t>
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.
</t>
<t>
<figure>
<artwork>
<![CDATA[
TD-CMS-DIGEST-ALGORITHMS 111 [ALG-AGILITY]
TD-CERT-DIGEST-ALGORITHMS 112 [ALG-AGILITY]
]]>
</artwork>
</figure>
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc5280;
&rfc3766;
&rfc5652;
&rfc3961;
&rfc4120;
&rfc4556;
&rfc6234;
&rfc6194;
<reference anchor='SP80056A'>
<front>
<title>Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm
Cryptography</title>
<author initials='E.' surname='Barker' fullname='Elaine Barker'>
<organization>National Institute of Standards and Technology</organization>
</author>
<author initials='D.' surname='Don' fullname='Don Johnson'>
<organization>National Institute of Standards and Technology</organization>
</author>
<author initials='M.' surname='Smid' fullname='Miles Smid'>
<organization>National Institute of Standards and Technology</organization>
</author>
<date year='2006' month='March'/>
</front>
</reference>
<reference anchor='X680'>
<front>
<title>
ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation
</title>
<author><organization>ITU</organization></author>
</front>
</reference>
<reference anchor='X690'>
<front>
<title>
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)
</title>
<author><organization>ITU</organization></author>
</front>
</reference>
</references>
<references title="Informative References">
&rfc6150;
&rfc1321;
<reference anchor="X9.42">
<front>
<title>
Public Key Cryptography for the Financial Services
Industry: Agreement of Symmetric Keys Using Discrete
Logarithm Cryptography
</title>
<author><organization>ANSI</organization></author>
<date year='2003'/>
</front>
</reference>
<reference anchor='WANG04'>
<front>
<title>Cryptanalysis of Hash functions MD4 and RIPEMD</title>
<author initials='X.' surname='Wang'> <organization/></author>
<author initials='X.' surname='Lai'> <organization/></author>
<author initials='D.' surname='Fheg'> <organization/></author>
<author initials='H.' surname='Chen'> <organization/></author>
<author initials='X.' surname='Yu'> <organization/></author>
<date year='2004' month='August'/>
</front>
</reference>
</references>
<section title="PKINIT ASN.1 Module">
<t>
<figure>
<artwork>
<![CDATA[
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
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 [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
]]>
</artwork>
</figure>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:08:11 |