Subject: Meeting on Naming

From: Sam Hartman <[email-masked]>
Date: Mon, 14 Mar 2005 18:08:22 -0500

Nico and I got together today to discuss naming.

We were mostly trying to focus on API considerations for the name
attributes proposal.  We didn't end up getting that far because we
ended up running into some more fundamental design issues.

We believe there are roughly three types of attributes:

* Attributes added/set on a name

* Attributes communicated from the context/credentials

* Attributes mapped from other attributes.

There are two types of mapped attributes.  The first are
mechanism-specific expansions of container attributes.  For example
the MS PAC might get split into attributes for user sids, group sids,
etc.  The other type of mapped attribute tends to be platform or
attribute specific.  For example, Nico wants a way of mappying a gss
name into uids and gids of the local platform based on the attributes
of that name.  You might have local policy that said to prefer some
NFS-based authzdata for Kerberos, then to prefer some PAC based data,
then to try an attribute certificate, etc.

We assume that attributes are labeled by OIDs.  It is critical that
the OID not convey any information about how trusted the name is.  For
example, there might be an OID for some Kerberos authorization data
element.  It might be possible to get the same OID through a
SubjectAltName in a cert, or through some other mechanism.  Trust of
name attributes will be critical.  Trust levels include:

* Asserted by the peer

* Set locally

* Authenticated by the credential

* Mapped from an authenticated attribute by an authenticated mechanism

It may be necessary to discuss which specific entity is authenticting
authentic assertions.  We hope not.

note that Kerberos authorization data is typically only asserted by
the peer.  Authorization data issued by the KDC or some other
authority where the signature is verified can be trusted as
authenticated by the credential.

Similarly, an attribute certificate would be an assertion by the peer
unless the CA is trusted and the attribute cert is bound to a subject
of a public key cert used in the authentication.

We discussed iterators for the naming API.  Ideally we'd like to have
an interface that returns a set of attribute names and then for each
of those have operations to get the values associated with the
attribbute.  I'm going to go talk to UI designers and see how well
this model can be made to interact with object frameworks etc.  I
suspect we may have problems in this regard.

We're not clear that the second type of mapped attribute (mapping gss
names to platform attributes) belongs in the GSS name proper.  It may
be a good idea to have a similar set of APIs along side the naming
APIs to deal with this case.

We realize that container attributes will require particular care
especially in how their contents are expanded.

We believe that the representation of names should not be language
specific.  In particular, we believe that the values of attributes
should be network representations, not pointers to language-binding
specific structures.  Along with this, we only believe that name
attributes having network representations are suited for use with
GSSAPI.

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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Mar 2005 20:52:34 -0600

Thank you for this wonderful summary of our discussions on naming!

Nico
--