Re: [SPKM] Issues with Naming

[Nicolas Williams <[e-mail]>]

On Thu, Oct 12, 2006 at 04:19:02PM -0400, William A.(Andy) Adamson wrote:
> 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.

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.

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

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.

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

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

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.

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

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.

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

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

_______________________________________________
SPKM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/spkm