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

From: [email-masked]
Date: Fri, 11 Dec 2015 14:21:25 -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 Working Group 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-02.txt
	Pages           : 8
	Date            : 2015-12-11

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-02

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

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: Luke Howard <[email-masked]>
Date: Sat, 12 Dec 2015 15:18:05 +1100

In 5.,  there’s a missing space after the comma after Sam’s second acknowledgement.

— Luke

---

From: Greg Hudson <[email-masked]>
Date: Sat, 12 Dec 2015 19:58:19 -0500

I have just one substantive concern:

    If the freshness token is not valid, the KDC MUST return
    KDC_ERR_PREAUTH_EXPIRED [RFC6113] with PA_AS_FRESHNESS.
[...]
    If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message
    that includes a freshness token, [...]

KDC_ERR_PREAUTH_FAILED has been changed to KDC_ERR_PREAUTH_EXPIRED as I
requested.  However, it still talks vaguely about including a freshness
token in the error, which I noted as a problem in my August 17 feedback.

In RFC 4120, the e-data field is an octet string whose form and
semantics depend on the error code, with speculation that it might
contain TYPED-DATA (a presumption which we have since abandoned).  Only
KDC_ERR_PREAUTH_REQUIRED has a specified e-data format in RFC 4120; that
format is METHOD-DATA, which is a SEQUENCE OF PA-DATA.

RFC 6113 section 5.4.4 implicitly forces all error e-data to be in
METHOD-DATA form if the error might occur in response to a FAST request.
 A facility is given for translating TYPED-DATA to METHOD-DATA, but
there unfortunately isn't an explicit statement about how the e-data
model is changed.  Sam alluded to this in March 2009:
http://www.ietf.org/mail-archive/web/krb-wg/current/msg00067.html

An implementor who sees "KDC_ERR_PREAUTH_EXPIRED with PA_AS_FRESHNESS"
might do several things, depending on their depth of understanding.
With a good understanding of RFC 6113 (or perhaps by accident), they
might encode METHOD-DATA containing a PA_AS_FRESHNESS element and put
that in the e-data field.  With a bad understanding, the implementor
might put the freshness value directly in the e-data field, or something
else.

In my August 17 feedback, I suggested:
> One alternative is to use KDC_ERR_PREAUTH_EXPIRED from RFC 6113.  There
> is no specification for including METHOD-DATA in such an error, so the
> client would have to restart from scratch, without the benefit of a
> newly valid freshness token.  But I think that is okay; recovering from
> a delay which resulted in a not-so-fresh freshness token should not be a
> common scenario.

I still think that is the simplest thing to do.  There is no need to
optimize round-trips for such an uncommon scenario.  At a minimum, I
think clients should be allowed to respond to KDC_ERR_PREAUTH_EXPIRED by
restarting with an unauthenticated AS-REQ.

Editorial concerns:

* "Public key encryption requires certificates with an encryption key,
that is not deployed on many existing smart cards": he added comma is
good, but "which" should not have been changed to "that," as the clause
is non-restrictive.  (Ben's August 16 feedback was not meant to apply to
every use of the word "which".)

* "the client uses its private key only to sign the AuthPack structure
(...), that is performed before any traffic is sent to the KDC": again,
"which" should not have been changed to "that," as the clause is
non-restrictive.

* Section 2.3, "The PA_AS_FRESHNESS padata-value field of the PA-DATA
structure SHALL": strike the "PA_AS_FRESHNESS" from this sentence.
(This was a problem with the previous version of the draft, which I
failed to notice in my August 17 feedback.)

* Section 7: "single use" should be "single-use".

* Section 8: add a comma before the word "depending."  Add a "the"
before "existing".

---

From: Seth Moore <[email-masked]>
Date: Tue, 15 Dec 2015 00:30:12 +0000

Thanks for the feedback, Greg.

> -----Original Message-----
> From: Kitten [mailto:[email-masked]] On Behalf Of Greg Hudson
> Sent: Saturday, December 12, 2015 4:58 PM
> To: [email-masked]

> KDC_ERR_PREAUTH_FAILED has been changed to
> KDC_ERR_PREAUTH_EXPIRED as I requested.  However, it still talks vaguely
> about including a freshness token in the error, which I noted as a problem in
> my August 17 feedback.
> 
> In RFC 4120, the e-data field is an octet string whose form and semantics
> depend on the error code, with speculation that it might contain TYPED-DATA
> (a presumption which we have since abandoned).  Only
> KDC_ERR_PREAUTH_REQUIRED has a specified e-data format in RFC 4120;
> that format is METHOD-DATA, which is a SEQUENCE OF PA-DATA.
> 
> RFC 6113 section 5.4.4 implicitly forces all error e-data to be in METHOD-DATA
> form if the error might occur in response to a FAST request.

Fair point. Michiko and I had a chat, and we agree it would be clearer to just 
add an explicit note that the e-data is a METHOD-DATA which contains an 
entry containing the PA_AS_FRESHNESSS octet string. This would be in section
2.2 "Generation of KRB_ERROR Message". This should avoid implementation
Confusion.

> > One alternative is to use KDC_ERR_PREAUTH_EXPIRED from RFC 6113.
> > There is no specification for including METHOD-DATA in such an error,
> > so the client would have to restart from scratch, without the benefit
> > of a newly valid freshness token.  But I think that is okay;
> > recovering from a delay which resulted in a not-so-fresh freshness
> > token should not be a common scenario.
> 
> I still think that is the simplest thing to do.  There is no need to optimize
> round-trips for such an uncommon scenario.  At a minimum, I think clients
> should be allowed to respond to KDC_ERR_PREAUTH_EXPIRED by restarting
> with an unauthenticated AS-REQ.

It would be a little simpler, sure. However, it seems overly pessimistic to do 
so. I'm not sure we know enough about possible implementations to state
that the expired error will truly be rare. In addition, any time a client passes
expired freshness to a KDC, it seems safe to assume that the client will want
a new freshness token. Why not just supply it to them?

Cheers,
Seth