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

From: [email-masked]
Date: Fri, 06 Mar 2015 18:43:28 -0800

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 Working Group 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-01.txt
	Pages           : 7
	Date            : 2015-03-06

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 which 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:
http://tools.ietf.org/html/draft-ietf-kitten-pkinit-freshness-01

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

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: Benjamin Kaduk <[email-masked]>
Date: Wed, 11 Mar 2015 14:03:43 -0400 (EDT)

Hi Michiko,

> http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-freshness-01

Thanks for the update.

It looks like this addresses all of Greg's questions, so I expect we will
put this in the queue for WGLC.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 11 Mar 2015 14:05:27 -0400 (EDT)

Whoops, muscle memory failed on the email address.
-Ben

---

From: Greg Hudson <[email-masked]>
Date: Wed, 11 Mar 2015 17:02:09 -0400

> put this in the queue for WGLC.

I still believe that section 2.1 is not necessary; clients should not
need to indicate support for PA_AS_FRESHNESS for a KDC to send it the
method-data of a preauth-required error.

My last statement on the topic is here:

    http://www.ietf.org/mail-archive/web/kitten/current/msg05326.html

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 11 Mar 2015 17:26:04 -0400 (EDT)

>     http://www.ietf.org/mail-archive/web/kitten/current/msg05326.html

Oops, sorry I missed that.
Yes, I believe you are correct.

-Ben

---

From: Michiko Short <[email-masked]>
Date: Thu, 12 Mar 2015 22:27:03 +0000

Sam,

Are you ok with pulling the client request behavior? 

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]] 
Sent: Wednesday, March 11, 2015 2:26 PM
To: Greg Hudson
Cc: Michiko Short; [email-masked]
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt

On Wed, 11 Mar 2015, Greg Hudson wrote:

> > It looks like this addresses all of Greg's questions, so I expect we 
> > will put this in the queue for WGLC.
>

-Ben

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Mar 2015 10:18:11 -0400

Yes, if you include the freshness token  in its own pa-type, that is
also fine, and I'm sorry I missed that.

---

From: Michiko Short <[email-masked]>
Date: Fri, 13 Mar 2015 16:50:01 +0000

Once the tool reopens then I will submit the version without the client request behavior. 

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Friday, March 13, 2015 7:18 AM
To: Michiko Short
Cc: Benjamin Kaduk; Greg Hudson; Sam Hartman; [email-masked]
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt

Yes, if you include the freshness token  in its own pa-type, that is also fine, and I'm sorry I missed that.

---

From: Michiko Short <[email-masked]>
Date: Fri, 13 Mar 2015 18:55:45 +0000

[Michiko Short] Creating a freshness token will be a crypto hit on the KDC, so sending freshness tokens to clients who will never use them will negatively impact KDC performance with no gains. If the PKInit client does not explicitly ask for the token, then clients using password authentication will also have freshness tokens generated and sent to them.

---

From: Greg Hudson <[email-masked]>
Date: Fri, 13 Mar 2015 15:26:18 -0400

> [Michiko Short] Creating a freshness token will be a crypto hit on the KDC, so sending freshness tokens to clients who will never use them will negatively impact KDC performance with no gains. If t…

That's worth considering.  Here are my thoughts:

* A freshness token doesn't have to be unique to a request or client; it
just has to be unknown to an attacker far in advance of an AS exchange.
 A KDC could compute a new global freshness token every five minutes or
so (by encrypting the current time in a TGS key, for instance) and use
it for many requests.

* A KDC only needs to send a freshness token if it is offering PKINIT
(or a future mechanism which also uses freshness tokens).  I guess it's
unusual for that to be a per-client decision by the KDC; typically
either the KDC is configured with PKINIT support or it isn't, and it
offers PKINIT to all clients if it is.

* Is AES encryption a significant load factor on modern KDCs?  I don't
have numbers for our KDC at the moment.  It probably depends a lot on
whether AES-NI can be used.

* If a client wants to save the KDC the effort of computing a freshness
token, it has to decide ahead of time whether it might be able to use
PKINIT (or a future mechanism which also uses freshness tokens).  This
is generally possible, but maybe a bit complex.

---

From: Michiko Short <[email-masked]>
Date: Wed, 18 Mar 2015 20:06:57 +0000

I think a KDC implementation can always choose to send a Freshness token, but that should be an implementation option not a requirement. Having a KDC only send the Freshness Token on client gives the option to limit generating Freshness tokens to just PKInit clients. 

-----Original Message-----
From: Greg Hudson [mailto:[email-masked]] 
Sent: Friday, March 13, 2015 12:26 PM
To: Michiko Short; Sam Hartman
Cc: Benjamin Kaduk; [email-masked]
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt

* A freshness token doesn't have to be unique to a request or client; it just has to be unknown to an attacker far in advance of an AS exchange.
 A KDC could compute a new global freshness token every five minutes or so (by encrypting the current time in a TGS key, for instance) and use it for many requests.

* A KDC only needs to send a freshness token if it is offering PKINIT (or a future mechanism which also uses freshness tokens).  I guess it's unusual for that to be a per-client decision by the KDC; typically either the KDC is configured with PKINIT support or it isn't, and it offers PKINIT to all clients if it is.

* Is AES encryption a significant load factor on modern KDCs?  I don't have numbers for our KDC at the moment.  It probably depends a lot on whether AES-NI can be used.

* If a client wants to save the KDC the effort of computing a freshness token, it has to decide ahead of time whether it might be able to use PKINIT (or a future mechanism which also uses freshness tokens).  This is generally possible, but maybe a bit complex.