< draft-ietf-kitten-pkinit-alg-agility-06.txt   draft-ietf-kitten-pkinit-alg-agility-07.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: September 7, 2019 M. Wasserman Expires: October 20, 2019 M. Wasserman
Painless Security Painless Security
G. Hudson, Ed. G. Hudson
MIT MIT
March 6, 2019 April 18, 2019
PKINIT Algorithm Agility PKINIT Algorithm Agility
draft-ietf-kitten-pkinit-alg-agility-06 draft-ietf-kitten-pkinit-alg-agility-07
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 September 7, 2019. This Internet-Draft will expire on October 20, 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 4 skipping to change at page 3, line 4
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 . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . 15 12.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 16 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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:
o The checksum algorithm in the authentication request is hardwired o The checksum algorithm in the authentication request is hardwired
to use SHA-1. to use SHA-1.
skipping to change at page 14, line 13 skipping to change at page 14, line 13
D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6 D3C78A79 D65213EF E9A826F7 5DFB01F7 2362FB16 FB01DAD6
9. Security Considerations 9. Security Considerations
This document describes negotiation of checksum types, key derivation This document describes negotiation of checksum types, key derivation
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
message, which is unauthenticated in a typical exchange. An attacker
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
local policy whether a client accepts a downgrade to a weaker CMS
type. A client may reasonably assume that the real KDC implements
all 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
error message. An attacker may attempt to downgrade a client to a
certificate using a weaker signing algorithm by forging a
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.
This attack is only possible if the client device possesses multiple
client certificates of varying strength.
In the KDF negotiation method described in Section 6, the client
supportedKDFs value is protected by the signature on the
signedAuthPack field in the request. If this signature algorithm is
weak to collision attacks, an attacker may attempt to downgrade the
negotiation by substituting an AuthPack with a different or absent
supportedKDFs value, using a PKINIT freshness token [RFC8070] to
partially control the legitimate AuthPack value. A client performing
anonymous PKINIT [RFC8062] does not sign the AuthPack, so an attacker
can easily remove the supportedKDFs value in this case. Finally, the
kdf field in the DHRepInfo of the KDC response is unauthenticated, so
could be altered or removed by an attacker, although this alteration
will likely result in a decryption failure by the client rather than
a successful downgrade. It is a matter of local policy whether a
client accepts a downgrade to the old KDF.
The paChecksum field, which binds the client pre-authentication data
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
second preimage attack is likely required as the attacker does not
control any part of the legitimate request body), the KDC will not
detect the substitution. Instead, if a new KDF is negotiated, the
client will detect the substitution by failing to decrypt the reply.
10. Acknowledgements 10. Acknowledgements
Jeffery Hutzelman, Shawn Emery, Tim Polk, Kelley Burgin, Ben Kaduk, Jeffery Hutzelman, Shawn Emery, Tim Polk, Kelley Burgin, Ben Kaduk,
and Scott Bradner reviewed the document and provided suggestions for Scott Bradner, and Eric Rescorla reviewed the document and provided
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
section 7.1 of RFC 6113 to refer to this specification. These values section 7.1 of RFC 6113 to refer to this specification. These values
were reserved for this specification in the initial registrations. were reserved for this specification in the initial registrations.
TD-CMS-DIGEST-ALGORITHMS 111 [ALG-AGILITY] TD-CMS-DIGEST-ALGORITHMS 111 [ALG-AGILITY]
TD-CERT-DIGEST-ALGORITHMS 112 [ALG-AGILITY] TD-CERT-DIGEST-ALGORITHMS 112 [ALG-AGILITY]
skipping to change at page 16, line 19 skipping to change at page 17, line 15
[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>.
[RFC8062] Zhu, L., Leach, P., Hartman, S., and S. Emery, Ed.,
"Anonymity Support for Kerberos", RFC 8062,
DOI 10.17487/RFC8062, February 2017,
<https://www.rfc-editor.org/info/rfc8062>.
[RFC8070] Short, M., Ed., Moore, S., and P. Miller, "Public Key
Cryptography for Initial Authentication in Kerberos
(PKINIT) Freshness Extension", RFC 8070,
DOI 10.17487/RFC8070, February 2017,
<https://www.rfc-editor.org/info/rfc8070>.
[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.
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
skipping to change at page 19, line 29 skipping to change at page 20, line 32
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
Greg Hudson (editor) Greg Hudson
MIT MIT
Email: ghudson@mit.edu Email: ghudson@mit.edu
 End of changes. 10 change blocks. 
15 lines changed or deleted 66 lines changed or added

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