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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Internet-Drafts

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Authentication Technology Next Generation of the IETF.

        Title           : Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension
        Authors         : Michiko Short
                          Seth Moore
                          Paul Miller
        Filename        : draft-ietf-kitten-pkinit-freshness-05.txt
        Pages           : 8
        Date            : 2016-03-21

Abstract:
   This document describes how to further extend the Public Key
   Cryptography for Initial Authentication in Kerberos (PKINIT)
   extension [RFC4556] to exchange an opaque data blob that a KDC can
   validate to ensure that the client is currently in possession of the
   private key during a PKINIT AS exchange.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-freshness/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-kitten-pkinit-freshness-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-freshness-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Rick van Rein (OpenFortress)
Hi,

> Abstract:
> This document describes how to further extend the Public Key
> Cryptography for Initial Authentication in Kerberos (PKINIT)
> extension [RFC4556] to exchange an opaque data blob that a KDC can
> validate to ensure that the client is currently in possession of the
> private key during a PKINIT AS exchange.
>
If I read the draft correctly, then failure of the client to comply with
the KDC's idea of proper freshness quoting can end up in an infinite
cycle of KRB-ERROR with freshness tokens?  There is a remark about
receiving the second KRB-ERROR with a freshness token (not of the first)
but nothing seems to be limiting the number of freshness token handling
cycles.  Did I miss that?

-Rick

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Paul Miller (NT)
The KDC is stateless, so as far as the KDC is concerned there is nothing to do about that cycle.  It is the responsibility of the client not to retry indefinitely.

It's really no different than the behavior already expected of clients with respect to KDC_ERR_TIME_SKEW and password.  If the client cannot agree with a KDC on a time then it needs to stop retrying.  The conditions to cause this are nearly identical as it would require that the client to round-robin different KDCs that have sufficient time skew from each other not to accept each other's time/freshness token for password/certificate respectively.

-----Original Message-----
From: Rick van Rein [mailto:[hidden email]]
Sent: Monday, March 21, 2016 5:40 PM
To: [hidden email]
Cc: [hidden email]
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt

Hi,

> Abstract:
> This document describes how to further extend the Public Key
> Cryptography for Initial Authentication in Kerberos (PKINIT) extension
> [RFC4556] to exchange an opaque data blob that a KDC can validate to
> ensure that the client is currently in possession of the private key
> during a PKINIT AS exchange.
>
If I read the draft correctly, then failure of the client to comply with the KDC's idea of proper freshness quoting can end up in an infinite cycle of KRB-ERROR with freshness tokens?  There is a remark about receiving the second KRB-ERROR with a freshness token (not of the first) but nothing seems to be limiting the number of freshness token handling cycles.  Did I miss that?

-Rick

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Rick van Rein (OpenFortress)
Hi Paul,

> The KDC is stateless, so as far as the KDC is concerned there is nothing to do about that cycle.

And so it should be.  If anything is done to defend against infinite looping clients it should probably take the form of bulk defense against attackish patterns.

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

Thanks,
 -Rick

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
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
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Michiko Short
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:[hidden email]]
Sent: Tuesday, March 22, 2016 5:48 AM
To: Rick van Rein <[hidden email]>; Paul Miller (NT) <[hidden email]>
Cc: [hidden email]; [hidden email]
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
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
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:[hidden email]]
> Sent: Tuesday, March 22, 2016 5:48 AM
> To: Rick van Rein <[hidden email]>; Paul Miller (NT) <[hidden email]>
> Cc: [hidden email]; [hidden email]
> 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
> [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten
>

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Michiko Short
In reply to this post by Benjamin Kaduk-2
You got it. :)

Can we get an IANA number as well?

-----Original Message-----
From: Benjamin Kaduk [mailto:[hidden email]]
Sent: Wednesday, April 6, 2016 7:23 AM
To: Michiko Short <[hidden email]>
Cc: Greg Hudson <[hidden email]>; [hidden email]; [hidden email]
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:[hidden email]]
> Sent: Tuesday, March 22, 2016 5:48 AM
> To: Rick van Rein <[hidden email]>; Paul Miller (NT)
> <[hidden email]>
> Cc: [hidden email]; [hidden email]
> 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
> [hidden email]
> 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
>

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten