Subject: [SPKM] Issues with Naming

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Thu, 12 Oct 2006 16:19:02 -0400

At the 67th IETF meeting, one of the issues that we would like to 
discuss is naming. Prior to the creation of this list, we had many email 
discussions on naming with Nicolas Williams, Martin Rex, Sandeep Ramesh, 
and others.
A few of the relevant messages are attached. We learned form the 
discussion that we need to get help of the cs community. The point of 
this mail is to setup the discussion about naming by summarizing the 
issues so that we can get the ball rolling and also setup our discussion 
for the IETF meeting.

Note while we're discussing these issues in the context of 
draft-adamson-rfc2847-bis, they need to be addressed with any PKI GSSAPI 
mechanism.

Server-side names
-----------------

 -- Problem: the client constructs a 'target-name' based on the limited 
 information (ie service name, service hostname), without having server's 
 certificate. then after the client receives the target's certificate it 
 has to match the constructed 'target-name' against the received certificate.

 -- the current draft proposes a number of matching rules.

     [comment] received negative reaction to our proposal to include a 
 'structure' in the CN field of the certificate. we proposed to have 
 CN=nfs/hostname, then match it to the 'target-name' of nfs/hostname.
  
Instead of the matching rules, we propose that we follow the same 
approach as does PKINIT (for the KDC certs).
 -- Another solution (that follows PKINIT approach):
     -- Require the server to have SPKM3 Extended Key Usage (EKU) X509v3 
 extension in its certificate.
     -- Require the server to have SPKM3 Subject Alternative Name (SAN).
         -- [issue]  what to put in the SAN?
           -- dnsNAme=<hostname>
           -- otherName wth type-id field=id-spkm3-san (OID) and value=???
             
 [comment] In PKINIT, SAN carries KerberosPrincipalName. In 
 SPKM3, we have no established name space to rely on.

 Client-side names
 -----------------

 -- Problem: after the context negotiation, the server needs to construct a 
 'client-name' from the received certificate. Currently, an X509 DN lacks a 
 canonical form and GSSAPI requires that each mechanism implements 
 gss_export_name() which returns a name in a canonical form that can be used 
 for access control.

 In the context of NFSv4, the lack of a canonical 'client-name' from the gss 
 context posses a problem for mapping the exported name into an NFSv4 name.

     -- the current draft proposes a set of rules to transform an X509 DN 
 into a canonical form (but the rules have limitiations)
   
    [comment] we still stand by our design to make the client-side name 
to be a canonical X509 name from the client's certificate. We can't 
really put SAN in a client certificate as does PKINIT because we have no 
namespace to fallback on like Kerberos does. The best we could do is add 
a requirement to have an SPKM3 EKU in the certificate. However, we still 
would need to produce a canonical name for the client. Therefore, we 
would like to come up with a set up rules that transform an X509DN into 
a canonical name. Of course, any other alternatives are

-->Andy and Olga

Subject: Re: SPKM-3 draft review
From: Olga Kornievskaia <[email-masked]>
To: Nicolas Williams <[email-masked]>
Cc: "William A.(Andy) Adamson" <[email-masked]>, [email-masked], [email-masked], Kevin Coffman <[email-masked]>, Sandeep Ramesh <[email-masked]>
Date: Tue, 16 May 2006 14:08:30 -0400

see a comment at the end...

Nicolas Williams wrote:

>>>>>>Among other things I disagree with the choice of name construction.
>>>>>>            
>>>>>>
>>>>"Name types" section has been reworked. The gist is: X500 name have no 
>>>>canonical form.
>>>>        
>>>>
>>>Sort of.  That doesn't mean that you can't prescribe matching rules for
>>>GSS-API generic syntax to certificate DNs and/or SANs, as well as
>>>mechanism-specific naming syntaxes that more closely match cert naming.
>>>      
>>>
>>ok - instead of defining rules for SPKM-3 canonical name form, prescribe 
>>matching rules.
>>    
>>
>
>Well, not entirely instead.  You can make a best effort for canonical
>name form.
>
>  
>
that's is exactly what we did. when i said "x500 name have no canonical 
form", i met to say none of the standards define a canonical form. the 
rest of the paragraph from the original email described as you put it "a 
best effort for canonical name form".

>>>Without a directory GSS_Canonicalize_name() can't do much -- oh well.
>>>      
>>>
>>hey! no directory service is a feature!
>>    
>>
>
>Right.
>  
>
i'm puzzled by the statement 'without a directory 
gss_canonicalize_name() can't do much. i think this function will do 
just fine without a directory service. spkm-3 carries the certs of the 
participants in their tokens. so all the necessary info for getting a 
canonical name and then possibly checking an ACL is there.

>>>>                 rfc2253 proposes a string representation but it is 
>>>>still not canonical. It does not address the order of multi-valued DNs, 
>>>>white spaces and case (this might not have a solution though). We 
>>>>propose to use rfc2253 format with additional rules (details are in 
>>>>section 2.5.1.1), briefly it's ordering or AVAs, removal of white spaces 
>>>>and making values all lower case. However, string representation can 
>>>>still be non-canonical because some implementation may lack an 
>>>>OID-to-string translation for an attribute present in an X500 
>>>>distinguished name (eg., 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=US). So 
>>>>two different implementations might represent the same DN with different 
>>>>string representation (one which would include a string for the OID and 
>>>>another will have to go with hex value of the OID as in the example). So 
>>>>for the gss_export_name() we propose to then DER-encode the string.  The 
>>>>result should be a canonical name that can be used for ACLs.
>>>>        
>>>>
>>>For the gss_export_name() you might even just return the whole cert...
>>>      
>>>
>>ug.
>>    
>>
>
>Why is that a problem?
>  
>
users change their certs (eg., public/private key expires) and keep the 
same name. a good example would be a kx509 cert which gives the user a 
new cert every day based on kerberos creds. using a cert as an ACL 
doesn't seem to be a good idea.

Subject: Re: SPKM-3 draft review
From: Martin Rex <[email-masked]>
To: [email-masked] (Olga Kornievskaia)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Tue, 16 May 2006 23:10:03 +0200 (MET DST)

Olga Kornievskaia wrote:
> 
> that's is exactly what we did. when i said "x500 name have no canonical 
> form", i met to say none of the standards define a canonical form. the 
> rest of the paragraph from the original email described as you put it "a 
> best effort for canonical name form".

I agree.

Since we have differences based on the amout of whitespace around
the RDN seperators, different acceptable RDN seperator chars,
differences in the case of the RDN attribute labels, there is
quite some amount of "canonicalization" that can be done
within gss_canonicalize_name() or gss_import_name()--which
one is up to the implementation).

ACL comparisons based on exported names do a memcmp(), so case
does matter (even on the attribute labels), and so does the type
and amount of whitespace and the RDN seperator char.

> >>>>
> >>>For the gss_export_name() you might even just return the whole cert...
> >>>      
> >>>
> >>ug.
> >>    
> >>
> >
> >Why is that a problem?
> >  
> >
> users change their certs (eg., public/private key expires) and keep the 
> same name. a good example would be a kx509 cert which gives the user a 
> new cert every day based on kerberos creds. using a cert as an ACL 
> doesn't seem to be a good idea.
 
I also strongly dislike the idea of returning a certificate
from gss_export_name().  None of the SPKM and SPKM-like mechanisms
that I've seen do that.

The two variants of gss_export_name() that I've seen use either
the printable subject DName encapsulated in the generic framing
for exported names or the ASN.1 DER encoding of the DName.

The ASN.1 DER is more error-prone, because it contains
ASN.1 tags of the encoding and it's not unlikely that a gssapi mechanism
creates a different ASN.1 encoding from a printable name that what
the CA created when it issued the certificate -- i.e. the gssapi mechanism
needs to always canonicalize through a printable representation
in order to account for encoding differences (IA5String vs. Printable,
abused T61String vs. correct UTF8String vs. correct T61String).
This is particularly true for non-standard name components,
which often will end up with an OID-dump in the DName...

There seem to be a a significant amount of PKIs using non-standard
(or at least uncommon) DName components instead of subjectAltName

-Martin

Subject: Re: SPKM-3 draft review
From: Nicolas Williams <[email-masked]>
To: Olga Kornievskaia <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Fri, 26 May 2006 17:19:57 -0500

On Fri, May 26, 2006 at 05:59:45PM -0400, Olga Kornievskaia wrote:
> Nicolas Williams wrote:
> >Careful with terminology.  This does not mean what you clarified to me.
> >
> >You mean to say that you'll use the output of a Name-to-rfc2253-to-Name
> >conversion, with DER as the ASN.1 encoding.
> >
> >That's fine.
> > 
> >
> Let me try again. SPKM-3 spec proposes: given a DER encoded certificate, 
                                                  ^^^^^^^^^^^^^^^^^^^^^^^
						  don't say this, say
						  "PKIX certificate" or
						  "x.509 certificate"
						  as the encoding
						  thereof is irrelevant
						  for this discussion
> we will retrieve the subject name and use the rfc2253 algorithm to get a 
> string representation of the distinguished name, it's a UTF8 string (the 
> *name* of the rfc2253 is "UTF-8 String Representation of Distinguished 
> Names").  Ok.  now given this string, we propose to DER encode it. I 
                                                      ^^^^^^^^^^^^^
> believe you say: "this is fine".

No, no, you've made the same mistake again.

To say "DER encode it" might mean "slap a DER Universal UTF8String tag and
length in front of the UTF-8 string and be done."

What you probably meant is "*parse* the rfc2253 string and output a DER
encoding of the RFC3280 ASN.1 'Name' type."

The key here is to carefully specify what ASN.1 type you're saying to
DER encode.

> Now I said: for DER encoding, we propose to use UTF8String for each RDN 
> attribute value. An example of an RDN in this case is "CN=aglo". We 
> propose to encode the value "aglo" as an UTF8String. If you look at the 
> rfc3280, CommonName encoding is defined as:
> 
> CommonName ::= PrintableString (SIZE (1..ub-common-name-length))
> 
> I believe DER encoding difference arise when even though PrintableString 
> type is specified different implementation might use IA5String instead 
> of PrintableString.
> 
> So to 'nail it down' since rfc2253 converted everything to UTF8, we 
> continue to use this encoding for each RDN value. Is this more clear?

Well, this points out that for I18N SPKM-3 depends on PKIX I18N.

I don't think you can or should try to tackle I18N in a GSS mechanism
that depends on I18N in components that haven't been internationalized.

Yet another reason to take this to the IETF now.

Nico
-- 
_______________________________________________
SPKM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/spkm

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Oct 2006 16:46:33 -0500

> Server-side names

Background: the initial token has to name the acceptor -- that is, it
has to convey the target name that the application passed to
GSS_Init_sec_context().  RFC2847 provides a field of type Name for this.

[I don't recall but it's possible that I may have missed some of this
background in those e-mails we exchanged a while back.]

Now, Name is quite restrictive, but since the Name in this token needn't
actually be a cert Name as much as something that can be matched to an
appropriate acceptor certificate, matching rules can allow SPKM to
express the basic GSS-API name types with relative ease.  Adding new
name types may prove difficult.

I would prefer not using Name, but depending on the matching rules I
could hold my nose and live with Name.

>  CN=nfs/hostname, then match it to the 'target-name' of nfs/hostname.

That works for GSS_C_NT_HOSTBASED_SERVICE, but what about other name
types?

Also, what if I import an exported name token and pass that to
GSS_Init_sec_context() as the target name?  That has to work too.

>  extension in its certificate.

IMO the EKU has to relate to the GSS-API service name, not to the
mechanism.  Who cares what the mechanism is?

>  Client-side names

There is no easy choice here.  You could use a structure that includes
the cert's DN, its KU/EKUs and its SubjectAltName, if any.  That's
almost like using the whole certificate minus public key and other info
that can change more often than the "name" of the cert.

>  context posses a problem for mapping the exported name into an NFSv4 name.

There is no requirement, in RFC3530 or elsewhere, that NFSv4
implementations use the "gsscred" method of mapping client principals to
local identities.

(The "gsscred" method of... consists of looking up an entry, in a
database keyed by exported name token, whose value indicates the
principal's local identity.)

NFSv4 implementations could do other things.

The KITTEN WG is chartered to, among other things, develop extensions to
the GSS-API that would help in this particular case.  Thus NFSv4
implementations could look at the "attributes" of a client principal
(i.e., the initiator's NAME object returned by GSS_Accept_sec_context())
and derive local identities or  "gsscred" database keys from them.

Your complaint about the lack of a canonical name for PKIX identities is
not new, and KITTEN WG is well aware of it.

Whatever SPKM-x ends up doing w.r.t. canonical exported name forms will
be merely pragmatic and less than ideal, unless...  see below.

> a canonical name. Of course, any other alternatives are

Another, perhaps better option, would be for the protocol to allow the
client to assert a canonical name for it that the acceptor then makes
sure matches the client's certificate, then GSS_Accept_sec_context() can
return an initiator NAME whose exported form will agree with what the
initiator asserted.

Initiator applications would have control over what name to assert
through the desired_name argument to the GSS_Acquire/Add_cred()
functions used to acquire an initiator CREDENTIAL for use with
GSS_Init_sec_context().

To me this would imply using something that includes a GeneralName...

Nico
--