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

From: Michiko Short <[email-masked]>
Date: Mon, 27 Apr 2015 22:34:35 +0000

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; [email-masked]
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:[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

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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 29 Apr 2015 16:25:00 -0400 (EDT)

On Mon, 27 Apr 2015, Michiko Short wrote:

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

I think I've lost track of which client behavior is in question -- is this
just the part where the client sends an empty PA_AS_FRESHNESS padata to
indicate support of freshness tokens and prompt the KDC to send one (in
contrast to having the KDC always send a freshness token on all requests
or all requests being offered PKINIT)?

It does not seem like a bad scheme to me in the abstract, but it seems
that if we permit it, than all clients wishing to use freshness tokens
must be prepared to implement it, in case they encounter a KDC which does
not proactively provide freshness tokens.  That's probably fine, but we
should consciously take that choice instead of just falling into it.

-Ben

---

From: Michiko Short <[email-masked]>
Date: Thu, 30 Apr 2015 20:49:26 +0000

Valid point.

So the RFC has the option where the client requests and the KDC provides on request. 

Two other options:
1. client sends an AS ping without explicit request
2. client sends PKInit AS-REQ which fails with KDC responding with the freshness token.

My understanding is that 1 is a non-starter for non-Microsoft implementations since accounts are typically configured to not require pre authentication which means that the KDC would return a TGT. 

2 would result in double the PKInit AS-REQs. I would prefer not to have throw away crypto operations and my expectation is that over time this would be how all the PKInit exchanges would work as realms protect against this attack. Additionally, although I am not aware of any implementations, this would be a hard blocker for anyone wanting to have user approval for using a certificate. Also, I am not sure if this would set off security software because it would increase AS-REQ failures which might be considered an attack. Anything looking for an increase in AS-REQ failures would need to be updated to look for a corresponding freshness token or filter out PKInit (unless it was trying to look for this attack). When we created the AS ping for AES we got a tons of inquiries due the increase in authentication failures with the deployment of Windows Vista.

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]] 
Sent: Wednesday, April 29, 2015 1:25 PM
To: Michiko Short
Cc: Greg Hudson; Sam Hartman; [email-masked]
Subject: RE: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt

On Mon, 27 Apr 2015, Michiko Short wrote:

> 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 

I think I've lost track of which client behavior is in question -- is this just the part where the client sends an empty PA_AS_FRESHNESS padata to indicate support of freshness tokens and prompt the KDC to send one (in contrast to having the KDC always send a freshness token on all requests or all requests being offered PKINIT)?

It does not seem like a bad scheme to me in the abstract, but it seems that if we permit it, than all clients wishing to use freshness tokens must be prepared to implement it, in case they encounter a KDC which does not proactively provide freshness tokens.  That's probably fine, but we should consciously take that choice instead of just falling into it.

-Ben