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 <> Thu, 22 December 2016 18:26 UTC

Return-Path: <>
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id CFC091294DD; Thu, 22 Dec 2016 10:26:31 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <>
To: IETF-Announce <>
Subject: Protocol Action: 'Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension' to Proposed Standard (draft-ietf-kitten-pkinit-freshness-07.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <>
Date: Thu, 22 Dec 2016 10:26:31 -0800
Archived-At: <>
Cc:,,,, The IESG <>,
X-Mailman-Version: 2.1.17
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Dec 2016 18:26:32 -0000

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:

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


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.