1. Summary
This document specifies an updated Public Key Cryptography for Initial
Authentication in Kerberos (PKINIT, rfc4556) which is not dependent on
SHA-1. In particular, it describes negotiation for Key Derivation
Functions, and includes test vectors for these schemes.
This is a Standards Track document since its core goal is to update
PKINIT, which is a standard part of Kerberos implementations.
Accordingly, it updates rfc4556 (PKINIT), which is Standards Track.
Robbie Harwood is the document shepherd. Benjamin Kaduk is the
responsible Area Director.
2. Review and Consensus
There is consensus for this document, which improves Kerberos's ability to
handle compromise of cryptographic algorithms. Having options other than
SHA-1 for PKINIT is noncontroversial within the working groups; this
document defines SHA-256, SHA-512, and SHA-384 as additional
possibilities, and assigns additional Object Identifiers for them.
This document has been around for quite a long time, originally part of
krb-wg before being taken up by kitten in the re-charter. Implementations
have existed in both MIT krb5 and Heimdal since 2011 and 2008,
respectively. Most shaping review happened under krb-wg, but those
contributors are also participants in kitten.
During drafting, there were concerns that using an unknown well-known
principal name together with PKINIT agility would cause an error code
overlap, despite there being no known shipped implementations.
Conservatively, the error code was reassigned. We also spent time on
thinking through our ASN.1, and making sure the appendix module was
all-inclusive.
This document received review and/or implementation from a significant
number of working group contributors. Two implementations (which can
reproduce test vectors) have proved stable and manageable in production
environments, and no unaddressed issues have been reported from any others
that might exist. In an ideal world it would have been published much
sooner, but has been repeatedly deprioritized in favor of other work.
3. Intellectual property
There are no intellectual property disclosures against this document, and
all three authors (and editor) have confirmed compliance with BCPs 78
and 79. Since this document contains contributions from before 2008, it
may not be modified outside the IETF Standards Process.
4. Other information
The IANA considerations are simple: rfc6113 previously created a registry
with entries reserved for this document (hence the "missing reference"
from idnits). This document requests said entries be updated to point to
this document.
rfc6234 is cited normatively, which also flags idnits. However, it is
already present in the Downref Registry.