draft-ietf-kitten-pkinit-alg-agility-07.txt   draft-ietf-kitten-pkinit-alg-agility-08.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 Oracle Corporation Intended status: Standards Track Oracle Corporation
Expires: October 20, 2019 M. Wasserman Expires: October 22, 2019 M. Wasserman
Painless Security Painless Security
G. Hudson G. Hudson
MIT MIT
April 18, 2019 April 20, 2019
PKINIT Algorithm Agility PKINIT Algorithm Agility
draft-ietf-kitten-pkinit-alg-agility-07 draft-ietf-kitten-pkinit-alg-agility-08
Abstract Abstract
This document updates the Public Key Cryptography for Initial This document updates the Public Key Cryptography for Initial
Authentication in Kerberos standard (PKINIT) [RFC4556], to remove 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.
skipping to change at page 1, line 44 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 October 20, 2019. This Internet-Draft will expire on October 22, 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 3, line 8 skipping to change at page 3, line 8
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 . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . 15 12.1. Normative References . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 17 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The Public Key Cryptography for Initial Authentication in Kerberos The Public Key Cryptography for Initial Authentication in Kerberos
(PKINIT) standard [RFC4556] defines several protocol structures that (PKINIT) standard [RFC4556] defines several protocol structures that
are either tied to SHA-1 [RFC6234], or do not support negotiation or are either tied to SHA-1 [RFC6234], or do not support negotiation or
discovery, but are instead based on local policy: discovery, but are instead based on local policy:
skipping to change at page 14, line 18 skipping to change at page 14, line 18
functions and other cryptographic functions. If a given negotiation functions and other cryptographic functions. If a given negotiation
is unauthenticated, care must be taken to accept only secure values; is unauthenticated, care must be taken to accept only secure values;
to do otherwise allows an active attacker to perform a downgrade to do otherwise allows an active attacker to perform a downgrade
attack. attack.
The discovery method described in Section 4 uses a Kerberos error The discovery method described in Section 4 uses a Kerberos error
message, which is unauthenticated in a typical exchange. An attacker message, which is unauthenticated in a typical exchange. An attacker
may attempt to downgrade a client to a weaker CMS type by forging a may attempt to downgrade a client to a weaker CMS type by forging a
KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error. It is a matter of KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error. It is a matter of
local policy whether a client accepts a downgrade to a weaker CMS local policy whether a client accepts a downgrade to a weaker CMS
type. A client may reasonably assume that the real KDC implements type, and whether the KDC accepts the weaker CMS type. A client may
all hash functions used in the client's X.509 certificate, and refuse reasonably assume that the real KDC implements all hash functions
attempts to downgrade to weaker hash functions. used in the client's X.509 certificate, and refuse attempts to
downgrade to weaker hash functions.
The discovery method described in Section 5 also uses a Kerberos The discovery method described in Section 5 also uses a Kerberos
error message. An attacker may attempt to downgrade a client to a error message. An attacker may attempt to downgrade a client to a
certificate using a weaker signing algorithm by forging a certificate using a weaker signing algorithm by forging a
KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. It is a matter of local KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. It is a matter of local
policy whether a client accepts a downgrade to a weaker certificate. policy whether a client accepts a downgrade to a weaker certificate,
This attack is only possible if the client device possesses multiple and whether the KDC accepts the weaker certificate. This attack is
client certificates of varying strength. only possible if the client device possesses multiple client
certificates of varying strength.
In the KDF negotiation method described in Section 6, the client In the KDF negotiation method described in Section 6, the client
supportedKDFs value is protected by the signature on the supportedKDFs value is protected by the signature on the
signedAuthPack field in the request. If this signature algorithm is signedAuthPack field in the request. If this signature algorithm is
weak to collision attacks, an attacker may attempt to downgrade the weak to collision attacks, an attacker may attempt to downgrade the
negotiation by substituting an AuthPack with a different or absent negotiation by substituting an AuthPack with a different or absent
supportedKDFs value, using a PKINIT freshness token [RFC8070] to supportedKDFs value, using a PKINIT freshness token [RFC8070] to
partially control the legitimate AuthPack value. A client performing partially control the legitimate AuthPack value. A client performing
anonymous PKINIT [RFC8062] does not sign the AuthPack, so an attacker anonymous PKINIT [RFC8062] does not sign the AuthPack, so an attacker
can easily remove the supportedKDFs value in this case. Finally, the can easily remove the supportedKDFs value in this case. Finally, the
kdf field in the DHRepInfo of the KDC response is unauthenticated, so kdf field in the DHRepInfo of the KDC response is unauthenticated, so
could be altered or removed by an attacker, although this alteration could be altered or removed by an attacker, although this alteration
will likely result in a decryption failure by the client rather than will likely result in a decryption failure by the client rather than
a successful downgrade. It is a matter of local policy whether a a successful downgrade. It is a matter of local policy whether a
client accepts a downgrade to the old KDF. client accepts a downgrade to the old KDF, and whether the KDC allows
the use of the old KDF.
The paChecksum field, which binds the client pre-authentication data The paChecksum field, which binds the client pre-authentication data
to the Kerberos request body, remains fixed at SHA-1. If an attacker to the Kerberos request body, remains fixed at SHA-1. If an attacker
substitutes a different request body using an attack against SHA-1 (a substitutes a different request body using an attack against SHA-1 (a
second preimage attack is likely required as the attacker does not second preimage attack is likely required as the attacker does not
control any part of the legitimate request body), the KDC will not control any part of the legitimate request body), the KDC will not
detect the substitution. Instead, if a new KDF is negotiated, the detect the substitution. Instead, if a new KDF is negotiated, the
client will detect the substitution by failing to decrypt the reply. client will detect the substitution by failing to decrypt the reply.
An attacker may attempt to impersonate the KDC to the client via an
attack on the hash function used in the dhSignedData signature,
substituting the attacker's subjectPublicKey for the legitimate one
without changing the hash value. It is a matter of local policy
which hash function the KDC uses in its signature and which hash
functions the client will accept in the KDC signature. A KDC may
reasonably assume that the client implements all hash functions used
in the KDF algorithms listed the supportedKDFs field of the request.
10. Acknowledgements 10. Acknowledgements
Jeffery Hutzelman, Shawn Emery, Tim Polk, Kelley Burgin, Ben Kaduk, Jeffery Hutzelman, Shawn Emery, Tim Polk, Kelley Burgin, Ben Kaduk,
Scott Bradner, and Eric Rescorla reviewed the document and provided Scott Bradner, and Eric Rescorla reviewed the document and provided
suggestions for improvements. suggestions for improvements.
11. IANA Considerations 11. IANA Considerations
IANA is requested to update the following registrations in the IANA is requested to update the following registrations in the
Kerberos Pre-authentication and Typed Data Registry created by Kerberos Pre-authentication and Typed Data Registry created by
 End of changes. 9 change blocks. 
12 lines changed or deleted 24 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/