Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: "IETF-Announce" <email@example.com> Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, "The IESG" <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org Subject: 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. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-freshness/
Technical Summary 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 particularly rough? Document Quality 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. Personnel 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. NEW: 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.