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

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 <ghudson@mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>, kitten@ietf.org
Subject: Re: [kitten] I-D Action:
	draft-ietf-kitten-pkinit-freshness-00.txt
Message-ID: <54CE6472.9050408@mit.edu>
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
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

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

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