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

[Michiko Short <[e-mail]>]

You got it. :) 

Can we get an IANA number as well?

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

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:[e-mail]]
> Sent: Tuesday, March 22, 2016 5:48 AM
> To: Rick van Rein <[e-mail]>; Paul Miller (NT) 
> <[e-mail]>
> Cc: [e-mail]; [e-mail]
> 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
> [e-mail]
> 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
>