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

From: [email-masked]
Date: Wed, 24 Feb 2016 09:29:05 -0800

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

Abstract:
   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:
https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-freshness/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-kitten-pkinit-freshness-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-freshness-03

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:
ftp://ftp.ietf.org/internet-drafts/

---

From: Greg Hudson <[email-masked]>
Date: Wed, 24 Feb 2016 13:40:10 -0500

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
pre-authentication.

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 [...]".