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

[Greg Hudson <[e-mail]>]

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.