[SPKM] Re: Comments on draft-zhu-pku2u-01.txt

Liqiang(Larry) Zhu wrote:
> This is designed for fast session resumption. When the initiator already
> obtained a service ticket in prior sessions, it can just use that cached
> ticket right away.
>   
Ok. However, I think that it makes more sense to explain the initial 
step first (ie., when no security context has been established between 
the parties), then explain the case of reusing previously acquired 
credentials.
>> Isn't there a missing reference to the Section 3.2.3 of RFC4556. Unlike KDC and principal, acceptor and initiator don't share any secrets. PKINIT's PA_PK_AS_REP is needed here for the initiator to make use of the ticket created by the acceptor.    
> RFC4556 updates RFC4120, unless there is something here specific to
> RFC4556, I do not see the need here.
>   
The doc states that:

   The initiator always includes the PA_PK_AS_REQ pre-authentication data computed according
   to Section 3.2.1 of [RFC4556].

I might be wrong but I believe that the reply message contains 
PA_PK_AS_REP pre-auth data as pre Section 3.2.2 of rfc4556. If not, 
ignore my comment. Otherwise, I think clarifying that the reply is not 
simply AS_REP is important.
>> This draft does not support non-Kerberos environments. By that I mean, a Kerberos domain must exist and users of PKU2U must have Kerberos principal names.
>>     
> How was this deduced? What is a Kerberos domain? And it should not be
> needed. what environments are not supported? Can you expand on this?
Naming of PKU2U participants is defined in terms on Kerberos name forms. 
Like SPKM3, PKU2U does not assume that the initiator knows the 
acceptor's certificate (at least there is nothing in the spec that says 
otherwise). Thus, the initiator needs to create/invent a name for the 
acceptor and include it in the AS_REQ. The document assume that the name 
would be in a Kerberos form. At this point, the likelihood that the 
initiator can create a correct KRB_NT_500_PRINCIPAL name that would 
eventually be matched to the DN in the acceptor's certificate is low. 
Thus, the other option is to create a typical Kerberos name 
"principal_name/instance@realm". The set of "principal_name/instance" 
names in a given "realm" constitutes a Kerberos domain. Such names must 
have been established and existed prior the initiator and acceptor's 
communication.

Now that I think about it, I have a question as to how would 
identification verification work when the certificate say don't have a 
SAN with principal_name in them? How would you match the 
"name/instance@realm" name to a DN?

>> Name type NT-X500-PRINCIPAL which is rfc2253 string representation of 
>> the distinguished name does not produce a canonical name.    
> PKU2U requires little endian order:
>
>    The Distinguished Name contained in the
>    PKU2U Kerberos principal name MUST begin with the most specific
>    attribute and continue with progressively broader attrbiutes.
>
> With this constraint, is there a case where this does not produce a
> canonical name?
>   
One example is multi-valued RDNs. I might be wrong but wasn't there a 
problem (in practice) of having different "string" names for RDN OIDs 
(or different implementations not knowing a mapping from an oid to a 
string name of an RDN, thus leading to different string representations).

>> Naming needs work. Comments made about naming in SPKM3 apply here.    
> Can you point me to the comments, it would help. 
I just realized that the discussion I was referring to occurred prior to 
the creation of the spkm mailing list. Thus, it was a private discussion 
that included comments from Nico Williams and Martin Rex.

_______________________________________________
SPKM mailing list
SPKM@ietf.org
https://www1.ietf.org/mailman/listinfo/spkm