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

From: Michiko Short <[email-masked]>
Date: Mon, 9 Feb 2015 21:18:38 +0000

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.

2. If it is needed, does it need to have a different padata type value from PA-AS-FRESHNESS?

I am open to the idea. We can have a single padata-type (PA-AS-FRESHNESS) then specify in requests, the padata-value shall be empty and in responses, the padata-value contains the actual freshness token. What do others think?

3. The draft defines "PA-AS-FRESHNESS-REQUEST ::= NULL".  Is the intent that the client will use a padata-value of 05 00 (an ASN.1 NULL value encoded in DER)?  An empty padata-value would be more traditional and more compact.

Our proposal was ASN.1 NULL object (tag 5). An empty octet string for padata-value works, too.

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?

5. It looks like this mechanism is general enough to be used by other preauthentication mechanisms in the future, if they have similar requirements.  Perhaps the RFC should explicitly call out that possibility.

I thought that as well which is why I pulled the PK out of the naming so that future extensions could use the token and it would not look odd. 

-----Original Message-----

----------------------------------------------------------------------

Message: 1
Date: Sun, 01 Feb 2015 12:37:54 -0500
From: Greg Hudson <[email-masked]>
To: Benjamin Kaduk <[email-masked]>, [email-masked]
Subject: Re: [kitten] I-D Action:
	draft-ietf-kitten-pkinit-freshness-00.txt
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=windows-1252

I have some questions, mostly related to PA-AS-FRESHNESS-REQUEST:

1. Is this padata type needed at all?  The only benefit I can see is that KDCs can omit PA-AS-FRESHNESS from the PREAUTH_REQUIRED hint list if the client doesn't support it, but that benefit vanishes as more clients support the new feature.

2. If it is needed, does it need to have a different padata type value from PA-AS-FRESHNESS?

3. The draft defines "PA-AS-FRESHNESS-REQUEST ::= NULL".  Is the intent that the client will use a padata-value of 05 00 (an ASN.1 NULL value encoded in DER)?  An empty padata-value would be more traditional and more compact.

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.

5. It looks like this mechanism is general enough to be used by other preauthentication mechanisms in the future, if they have similar requirements.  Perhaps the RFC should explicitly call out that possibility.

------------------------------

Subject: Digest Footer

_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

------------------------------

End of Kitten Digest, Vol 123, Issue 1
**************************************

---

From: Greg Hudson <[email-masked]>
Date: Mon, 09 Feb 2015 16:33:15 -0500

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

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

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.