Kitten Working Group L. Hornquist Astrand
Internet-Draft Apple, Inc
Updates: 4556 (if approved) L. Zhu
Intended status: Standards Track Microsoft Corporation
Expires: May 9, 2019 M. Wasserman
Painless Security
G. Hudson, Ed.
MIT
November 5, 2018
PKINIT Algorithm Agilitydraft-ietf-kitten-pkinit-alg-agility-03
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 https://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 May 9, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
Hornquist Astrand, et al. Expires May 9, 2019 [Page 1]

Internet-Draft PKINIT Algorithm Agility November 2018
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 181. 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:
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 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),
identified by object identifiers, are defined. The PKINIT client
Hornquist Astrand, et al. Expires May 9, 2019 [Page 3]

Internet-Draft PKINIT Algorithm Agility November 2018
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.
Hornquist Astrand, et al. Expires May 9, 2019 [Page 4]

Internet-Draft PKINIT Algorithm Agility November 2018
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.
The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy
digest algorithms supported by the KDC.
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
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:
Hornquist Astrand, et al. Expires May 9, 2019 [Page 5]

Internet-Draft PKINIT Algorithm Agility November 2018
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].
...
}
The KDC fills in allowedAlgorithm field with the list of algorithm
[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:
Hornquist Astrand, et al. Expires May 9, 2019 [Page 6]

Internet-Draft PKINIT Algorithm Agility November 2018
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:
o The key data length (K) is the key-generation seed length in bits
[RFC3961] for the Authentication Service (AS) reply key. The
enctype of the AS reply key is selected according to [RFC4120].
o 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.
o 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.
o 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 [SP80056A] ASN.1 structured HKDF
using SHA-1 as the hash.
o The initiator identifier (partyUInfo) contains the ASN.1 DER
encoding of the KRB5PrincipalName [RFC4556] that identifies the
client as specified in the AS-REQ [RFC4120] in the request.
o The recipient identifier (partyVInfo) contains the ASN.1 DER
encoding of the KRB5PrincipalName [RFC4556] that identifies the
TGS as specified in the AS-REQ [RFC4120] in the request.
o The supplemental public information (suppPubInfo) is the ASN.1 DER
encoding of the structure PkinitSuppPubInfo as defined later in
this section.
o The supplemental private information (suppPrivInfo) is absent.
o The maximum hash input length is 2^64 in bits.
The structure for OtherInfo is defined as follows:
Hornquist Astrand, et al. Expires May 9, 2019 [Page 8]

Internet-Draft PKINIT Algorithm Agility November 2018
OtherInfo ::= SEQUENCE {
algorithmID AlgorithmIdentifier,
partyUInfo [0] OCTET STRING,
partyVInfo [1] OCTET STRING,
suppPubInfo [2] OCTET STRING OPTIONAL,
suppPrivInfo [3] OCTET STRING OPTIONAL
}
The structure PkinitSuppPubInfo 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 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
[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.
To acomplish this, the AuthPack structure in [RFC4556] is extended as
follows:
Hornquist Astrand, et al. Expires May 9, 2019 [Page 9]

Internet-Draft PKINIT Algorithm Agility November 2018
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
...
}
The new field supportedKDFs contains an unordered set of KDFs
supported by the client.
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.
The DHRepInfo structure in [RFC4556] is extended as follows:
DHRepInfo ::= SEQUENCE {
dhSignedData [0] IMPLICIT OCTET STRING,
serverDHNonce [1] DHNonce OPTIONAL,
...,
kdf [2] KDFAlgorithmId OPTIONAL,
-- The KDF picked by the KDC.
...
}
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.
If the supportedKDFs field is not present in the request, the kdf
field in the reply MUST be absent.
Hornquist Astrand, et al. Expires May 9, 2019 [Page 10]