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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 6 Apr 2016 10:22:54 -0400 (EDT)

Hi Michiko,

Can you please submit a new revision making the MUST --> SHOULD change?

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.

Thanks,

Ben

On Tue, 22 Mar 2016, Michiko Short wrote:

> Since the infinite loop problem exists for Kerberos clients already, I would prefer to not specify something since this is an extension to an extension.
>
> However, the must is valid. Not sure how we all missed that.
> "If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that includes a freshness token, it SHOULD retry using the new freshness token."
>
> I would really like to get this to last call and get the official IANA number
>
> -----Original Message-----
> From: Greg Hudson [mailto:[email-masked]]
> Sent: Tuesday, March 22, 2016 5:48 AM
> To: Rick van Rein <[email-masked]>; Paul Miller (NT) <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt
>
> On 03/22/2016 03:09 AM, Rick van Rein wrote:
> >> It is the responsibility of the client not to retry indefinitely.
> >
> > May I suggest that you state that in the text?  The current draft is a procedure, and could benefit from invariant statements to clarify the cases that fall outside of the intended procedure.
>
> If I understand correctly, we are worried about an infinite loop of AS-REQ -> KDC_ERR_PREAUTH_EXPIRED -> AS-REQ -> ... due to the section 2.5.
>
> If we need to alter this text anyway, I don't like the requirement that "If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that includes a freshness token, it MUST retry using the new freshness token."  MUSTs are to be used when behavior "is actually required for interoperation or to limit behavior which has potential for causing harm" (RFC 2119 section 6).  A client which implements RFC 6113 could respond to KDC_ERR_PREAUTH_EXPIRED the same way it already does, by retrying from the beginning, without affecting interoperability or causing harm.
>
> I suggest the following text:
>
>   If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that
>   includes a freshness token, it SHOULD retry the PKINIT-authenticated
>   AS-REQ using the new freshness token.  The client MAY restart the
>   conversation instead.  The client MUST limit the number of retries to
>   avoid looping forever in case of a misbehaving KDC.
>
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: Greg Hudson <[email-masked]>
Date: Wed, 6 Apr 2016 11:02:08 -0400

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

---

From: Michiko Short <[email-masked]>
Date: Wed, 6 Apr 2016 18:17:30 +0000

You got it. :) 

Can we get an IANA number as well?

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]] 
Sent: Wednesday, April 6, 2016 7:23 AM
To: Michiko Short <[email-masked]>
Cc: Greg Hudson <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt

Hi Michiko,

Also, I would like to get an explicit confirmation from Greg that this text is not problematic (in Section 2.4):

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.

Thanks,

Ben

On Tue, 22 Mar 2016, Michiko Short wrote:

> Subject: Re: [kitten] I-D Action: 
> draft-ietf-kitten-pkinit-freshness-05.txt
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
> etf.org%2fmailman%2flistinfo%2fkitten&data=01%7c01%7cmichikos%40microsoft.com%7c141d07e5fb25470ba38508d35e26f59a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=spLywtsgLuqPMT0lESglYZVAeOh7wbHYX%2fkQO9zcJm4%3d
>