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

[Greg Hudson <[e-mail]>]

On 04/06/2016 10:22 AM, Benjamin Kaduk wrote:
> Also, I would like to get an explicit confirmation from Greg that this
> text is not problematic (in Section 2.4):
> 
>    [...] If the freshness token is not valid, the KDC MUST
>    return a KRB_ERROR [RFC4120] message with the error-code
> 
> KDC_ERR_PREAUTH_EXPIRED [RFC6113].  The e-data field of the error
>    contains a METHOD-DATA object [RFC4120] which specifies a valid
>    PA_AS_FRESHNESS padata-value.
> 
> I see an old comment from Greg in the archives that RFC 6113 made no
> specification for including METHOD-DATA in a KDC_ERR_PREAUTH_EXPIRED error
> packet, but a more recent message indicated general acceptance of the
> whole document (with no specific mention of this text).  My understanding
> is that the concern related to the need to unambiguously specify how to
> construct the error packet, since RFC 6113 did not give guideance on this
> scenario (whereas RFC 4120 did give guidance for constructing error
> packets for KDC_ERR_PREAUTH_FAILED), but the thread is old enough that I
> would like another confirmation.

My preference remains to send an unadorned KDC_ERR_PREAUTH_EXPIRED and
let the client restart from the beginning, just as it would for an
expired cookie.  The extra round trip is a negligible cost for such an
unusual event, and simplicity has value in a protocol as complicated as
Kerberos.  Seth Moore disagreed with me on the grounds that expired
freshness tokens might not be rare; this argument seems far-fetched to
me, but I think any further discussion on the point would be hand-waving.

That said, I don't believe the text is problematic at this point,
because it unambiguously specifies how to construct the error packet.