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

From: [email-masked]
Date: Mon, 21 Mar 2016 15:32:15 -0700

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/

---

From: Rick van Rein <[email-masked]>
Date: Tue, 22 Mar 2016 01:39:58 +0100

Hi,

> 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

---

From: "Paul Miller (NT)" <[email-masked]>
Date: Tue, 22 Mar 2016 01:39:45 +0000

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:[email-masked]] 
Sent: Monday, March 21, 2016 5:40 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt

Hi,

> 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

---

From: Rick van Rein <[email-masked]>
Date: Tue, 22 Mar 2016 08:09:49 +0100

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

---

From: Greg Hudson <[email-masked]>
Date: Tue, 22 Mar 2016 08:47:39 -0400

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

---

From: Michiko Short <[email-masked]>
Date: Tue, 22 Mar 2016 17:20:11 +0000

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

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