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

From: Sam Hartman <[email-masked]>
Date: Mon, 04 May 2015 08:48:41 -0400

I think it is entirely reasonably to ask all clients to send a freshness
request.

---

From: Greg Hudson <[email-masked]>
Date: Mon, 04 May 2015 11:12:33 -0400

> I think it is entirely reasonably to ask all clients to send a freshness

I think it's a little unfortunate, but if it will make Microsoft's life
easier, an few extra bytes in each AS request won't break the world.

MIT krb5 clients will probably send the freshness request
unconditionally, since our preauth framework doesn't make it easy to
determine ahead of time whether the client can do authenticated PKINIT.
 We'll need to be prepared to retry without it because of older MIT krb5
KDCs, but we already have logic for that because of PA-REQ-ENC-PA-REP
(RFC 6806).

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 May 2015 13:32:17 -0400

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:

    Greg> On 05/04/2015 08:48 AM, Sam Hartman wrote:
    >> I think it is entirely reasonably to ask all clients to send a
    >> freshness request.

    Greg> I think it's a little unfortunate, but if it will make
    Greg> Microsoft's life easier, an few extra bytes in each AS request
    Greg> won't break the world.

Well, it is kind of what RFC 4120 anticipates you'll do whenever you
introduce a new option.

---

From: Greg Hudson <[email-masked]>
Date: Mon, 04 May 2015 14:35:16 -0400

> Well, it is kind of what RFC 4120 anticipates you'll do whenever you

The freshness token is a padata value in the method-data of a
PREAUTH_REQUIRED error.  To an old client, it looks like like an
unsupported preauth mech or a piece of unrecognized informational
preauth data (which is what it is).  We have never required clients to
indicate support for either of these things.  For instance, RFC 4120
requires KDCs to send ETYPE-INFO2 in method-data even if the request
does not use a new enctype.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 May 2015 14:56:01 -0400

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:

    Greg> On 05/04/2015 01:32 PM, Sam Hartman wrote:
    Greg> I think it's a little unfortunate, but if it will make
    Greg> Microsoft's life easier, an few extra bytes in each AS request
    Greg> won't break the world.
    >> 
    >> Well, it is kind of what RFC 4120 anticipates you'll do whenever
    >> you introduce a new option.

    Greg> The freshness token is a padata value in the method-data of a
    Greg> PREAUTH_REQUIRED error.  To an old client, it looks like like
    Greg> an unsupported preauth mech or a piece of unrecognized
    Greg> informational preauth data (which is what it is).  We have
    Greg> never required clients to indicate support for either of these
    Greg> things.  For instance, RFC 4120 requires KDCs to send
    Greg> ETYPE-INFO2 in method-data even if the request does not use a
    Greg> new enctype.

We require clients to indicate support for FAST and permit them to
indicate support for pkinit.
My point is that RFC 4120 anticipates people indicating support for
features when a KDC might wish to know whether the feature is supported
prior to generating a response.