[kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-03.txt

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

[kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Authentication Technology Next Generation of the IETF.

        Title           : Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension
        Authors         : Michiko Short
                          Seth Moore
                          Paul Miller
        Filename        : draft-ietf-kitten-pkinit-freshness-03.txt
        Pages           : 8
        Date            : 2016-02-24

   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.

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:

Kitten mailing list
[hidden email]
Reply | Threaded
Open this post in threaded view

Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-03.txt

Greg Hudson
This version of the draft contains the following new text in section 2.4:

> If the realm requires freshness and the PA_PK_AS_REQ message does not
> contain the freshness token, the KDC MUST return a KRB_ERROR
> [RFC4120] message with the error-code KDC_ERR_PREAUTH_REQUIRED
> [RFC4120] with a padata element with padata-type PA_AS_FRESHNESS and
> padata-value of the freshness token to the METHOD-DATA object.

My initial reaction to this text was that it sounds like protocol
wishful thinking.  If the client is too old to support freshness tokens,
re-sending the same KRB_ERROR as the KDC sent in step 2.2 will not cause
the client to magically develop that support.

It is possible that this text is intended to apply when a client does
support freshness tokens, but did not use one because it was attempting
optimistic PKINIT (so sections 2.1-2.3 did not occur).  I'm not sure it
makes sense for a client with freshness token support to perform
optimistic PKINIT; such optimist attempts will only become less optimal
over time as KDCs start to require freshness tokens.

If this text is intended to apply to an optimist PKINIT scenario, then
it is inconsistent with RFC 6113, which specifies the use of
KDC_ERR_PREAUTH_FAILED to indicate failures of optimistic

On a less important note, the new text in section 2.2 is not
grammatically correct; it uses the construction "The KDC will respond
with a [message] and adding a padata [...]".

Kitten mailing list
[hidden email]