Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-01

[Benjamin Kaduk <[e-mail]>]

Hi Michiko,

On Sun, 16 Aug 2015, Benjamin Kaduk wrote:

> This message begins the Working Group Last Call (WGLC) of "Public Key
> Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness
> Extension" <draft-ietf-kitten-pkinit-freshness-01>. The WGLC will last two
> weeks, ending on Sunday, August 30th.  The draft is available at:

Looking over the traffic from the WGLC period, it seems that some
revisions to the document are required.  Going over the list's archive:

Greg noted that there was some ambiguity in section 2.4 regarding the
contents of the KRB-ERROR message in the case when a supplied freshness
token is not valid, in his message at
http://www.ietf.org/mail-archive/web/kitten/current/msg05783.html .

That message also raised the question of using KDC_ERR_PREAUTH_FAILED for
a retriable answer, which does not seem to have been resolved yet.  With
no hat on, I'm inclined to avoid KDC_ERR_PREAUTH_FAILED for retriable
errors.

Greg also made some editorial comments in that same message.

Bryce Nordgren also found an editorial change in
http://www.ietf.org/mail-archive/web/kitten/current/msg05794.html (the
content question in that message seems to have been resolved in subsequent
list traffic).

Bryce also notes in a later message that the document should say that the
implementation-defined validation procedure must actually guarantee
freshness.  Something similar to Greg's explanation in
http://www.ietf.org/mail-archive/web/kitten/current/msg05795.html might be
reasonable, say, in the security considerations.

I also supplied a couple editorial comments in
http://www.ietf.org/mail-archive/web/kitten/current/msg05801.html

jhutz made some (mostly) editorial suggestions in his review,
http://www.ietf.org/mail-archive/web/kitten/current/msg05802.html (some of
the non-editorial comments are mitigated by Greg's follow-up in
http://www.ietf.org/mail-archive/web/kitten/current/msg05803.html )

This question from jhutz's message remains unresolved:
"Do we need to call out that a client MUST use a freshness token it got
during an earlier iteration of the same AS exchange?  So, for example,
it can't change its mind about principal names or KDC options or
requested AD and still expect the freshness token to be valid?"  I don't
think this is a particularly critical issue, so it may suffice to just
note that a KDC implementation MAY bind the freshness token to parameters
in the AS-REQ, so the client implementation should use the freshness token
it got during an earlier iteration of the same AS exchange or be prepared
to handle failures resulting from the KDC validation failure for the
binding to the AS-REQ parameter(s).


Can you please generate a revised I-D addressing these comments (i.e.,
including proposed resolutions to the as-yet-unresolved questions)?
Depending on the scope of the changes, another WGLC may be needed; if the
changes are minor and uncontroversial, we might be able to skip it.

Thanks,

Ben