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

[Michiko Short <[e-mail]>]

Time for me to publish a new draft since this one is expiring. 

We found a use case in our implementation of PKInit where the client must request a freshness token or else they will get a principal not found error, so we need to keep the client behavior. I would prefer to not make that MS-PKCA Microsoft extension. It there any problem with keeping the client language as is? Also we would prefer to keep token generation limited to the public key case. Yes, we are hoping to expand the number of customers who use PKInit, but there will still be customers for a while who do not, have old servers, etc.

-----Original Message-----
From: Michiko Short 
Sent: Wednesday, March 18, 2015 1:07 PM
To: 'Greg Hudson'; Sam Hartman
Cc: Benjamin Kaduk; [e-mail]
Subject: RE: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt

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:[e-mail]] 
Sent: Friday, March 13, 2015 12:26 PM
To: Michiko Short; Sam Hartman
Cc: Benjamin Kaduk; [e-mail]
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt

On 03/13/2015 02:55 PM, Michiko Short wrote:
> Once the tool reopens then I will submit the version without the client request behavior. 
> 
> [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. 

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.