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

[Greg Hudson <[e-mail]>]

On 02/09/2015 04:18 PM, Michiko Short wrote:
> 1. Is this padata type needed at all?  
> 
> My understanding (confirmed by Sam) is that RFC 4120 extensibility guidelines require that the KDC ensure the clients understand the response. I am open to discussion.

Surely clients must ignore unknown preauth types in a preauth-required
error.  Otherwise all new preauth methods (including specified ones such
as PKINIT and OTP) would have required an indication of client support
in the request.

> 4. The draft defines "PA-AS-FRESHNESS ::= OCTET STRING".  Is it desirable to wrap the freshness token in a DER OCTET STRING tag, or could we just transmit the value directly within the padata-value?  Of course the value still needs to have type OCTET STRING within the PKAuthenticator.
> 
> If we skip the OCTET STRING definition then we need to specify that the padata-value directly is the freshness octet string (i.e., no wrapping in the padata-value OCTET STRING). The PKAuthenticator needs to specify that the freshnessToken component is an OCTET STRING and with a comment that the value shall be as received in padata-value (basically just a copy of the whole DER-encoded padata-value value). The advantage though (besides  being shorter) is that we could now simply claim that the padata-value directly carries a freshness token, when non-empty. Is that what you were thinking?

Yes.  In addition to making the preauth-required error slightly shorter,
this change eliminates an implementation step and an exceptional case in
the client code required to implement the feature.

If we make this change and the PA-AS-FRESHNESS token sent by the KDC is
empty, I don't think the client should treat that as an exceptional
case; it should include an empty OCTET STRING value in the
freshnessToken field of the PKAuthenticator, like it would for any other
PA-AS-FRESHNESS padata-value.