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

[Michiko Short <[e-mail]>]

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:[e-mail]] 
Sent: Wednesday, April 29, 2015 1:25 PM
To: Michiko Short
Cc: Greg Hudson; Sam Hartman; [e-mail]
Subject: RE: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt

On Mon, 27 Apr 2015, Michiko Short wrote:

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

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