[kitten] Protocol Action: 'Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension' to Proposed Standard (draft-ietf-kitten-pkinit-freshness-07.txt)
The IESG has approved the following document:
- 'Public Key Cryptography for Initial Authentication in Kerberos
(PKINIT) Freshness Extension'
(draft-ietf-kitten-pkinit-freshness-07.txt) as Proposed Standard
This document is the product of the Common Authentication Technology Next
Generation Working Group.
The IESG contact persons are Stephen Farrell and Kathleen Moriarty.
This document describes how to further extend the Public Key
Cryptography for Initial Authentication in Kerberos (PKINIT)
extension [RFC4556] to exchange an opaque data blob that a KDC can
validate to ensure that the client is currently in possession of the
private key during a PKINIT AS exchange.
Working Group Summary
Was there anything in the WG process that is worth noting?
For example, was there controversy about particular points
or were there decisions where the consensus was
There is strong consensus for this document, and is the result of
active discussion and review among WG members and implementers. There
were two main discussion topics that formed this document. The first
regarded the choice to specify the freshness token contents as KDC
implementation-defined. The token is an element that is both generated
and used by the KDC only, being opaque to the client. While there is
sometimes the need to have interoperability between KDC-only formats
within a realm, there is a precedence within the WG to not standardize
these and let the implementations supply documentation on their
formats. The other topic was regarding the pre-authentication error
code and handling; The initial choice of KDC_ERR_PREAUTH_FAILED was
decided as unsuitable for a retriable error and was changed to
KDC_ERR_PREAUTH_EXPIRED defined in RFC 6113.
Matt Rogers is the document shepherd. Stephen Farrell is the
irresponsible Area Director.
RFC Editor Note
Please add the following new paragraph to the end of section 7.
If freshness tokens sent by the KDC are too short or too
predictable, an attacker may be able to defeat the mechanism
by creating signatures using every possible token value.
To prevent this attack, the freshness token SHOULD contain
a minimum of 64 unpredictable bits.