Subject: [kitten] Naming extensions, next round: issuer and other standard name attributes

From: Nico Williams <[email-masked]>
Date: Thu, 22 Dec 2011 01:42:04 -0600

We want to be able to inquire a NAME's and name attribute's issuer.  Until
today I thought this would mean that we should add a function like
GSS_Get_name_attribute() but which also outputs the attribute's issuer
name as a NAME.  Then the lightbulb went off:

    For any given attribute name, all we need to do is transform it, such as by
    prefixing it with another attribute name, such that the resulting
attribute's value
    will be the issuer of the original.

For example, if given an attribute X we could obtain the issuer name by calling
GSS_Get_name_attribute() to get the attribute named
"urn:ietf:...:issuer-name X",
which would then output an exported name token for the attribute X's
issuer NAME,
and the display name of the issuer as well.

This idea might seem strange at first, but think that if we had a
function by which
to get an actual NAME object for an issuer, the application would
likely turn around
and call GSS_Display/Export_name() on it.  This approach then
simplifies the API!

(I met with Sam today, and as soon as I said "for any given attribute name" he
knew the rest before I said anything else and agreed with the idea.)

This gets us everything except the issuer name's name-type, so we can add an
additional attribute prefix by which to request the issuer name's
name-type, which
results in GSS_Get_name_attribute() outputting the name-type OID as a DER-
encoded value and as a string in the display_value output parameter.

Oh, and we might want a prefix by which to get a composite exported name token
for the issuer.

Also, these attribute name prefixes used alone should operate on the input_name
itself rather than a given attribute of it.

This gives us our first opportunity to specify a generic attribute
name.  Are there
others?  Yes!  An obvious one is the trust transited path, which I
believe we can
generalize such that its value and display_value is specific to the
mechanism that
is the source of the given MN.

So I think we have at least four generic name attributes to specify:

 - urn:ietf:<TBD>:issuer-name
 - urn:ietf:<TBD>:issuer-name-name-type
 - urn:ietf:<TBD>:issuer-name-composite
 - urn:ietf:<TBD>:transit-path (this last one would not be used as a prefix)

The transit path would be nicer and more generic still if were
available as discrete
elements, one per-transit hop, so perhaps we want:

 - urn:ietf:<TBD>:transit-path-hop-name:<hop-number>
 - urn:ietf:<TBD>:transit-path-hop-name-name-type:<hop-number>
 - urn:ietf:<TBD>:transit-path-hop-name-composite:<hop-number>

I would also like us to define a single name attribute by which to
specify application-
specific authorization-data to be carried by the mechanism.  The
example use case
I gave earlier was of privileges ("capabilities" in Linux speak) by
which to reduce
privileges that would be granted by the peer.

 - urn:ietf:<TBD>:application-attribute

We could say that attribute names of the form
"urn:ietf:<TBD>:application-attribute <X>"
are all supported by any mechanism that supports this one attribute.

That's quite a few generic attributes.

Any others?  I can think of some that I'm not so sure about, such as a
name attribute
whose value is an exported composite name token of the local name of
the security
context from which this name came: this would allow APIs that receive
only a single
NAME parameter to actually have access to the name of the other peer
of a security
context when the NAME passed in was obtained from GSS_Inquire_context() or
GSS_Init/Accept_sec_context().  But I think that's a bit of a stretch.

Also, given that section 6 (Representation of Attribute Names) gives
the ability to
prefix a name attribute with another, I don't think we need to define
a further notion of
name attribute namespace.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 22 Dec 2011 12:32:19 -0600

Another set of useful generic attributes would be ones corresponding
to the components of multi-component names such as
GSS_C_NT_HOSTBASED_SERVICE:

 - urn:ietf:<TBD>:hostbased-service:service
 - urn:ietf:<TBD>:hostbased-service:hostname

This would allow for generic applications to inquire a hostbased
service MN and get at the components generically.  Today applications
can't do this without understanding mechanism-specific name type
syntaxes.

For example, today a hostbased service name MN for Kerberos will
display as service/hostname@REALM, NOT as service@hostname, so an
application that wants to see what hostname was used has to know how
to parse this -- what a pain!  This gets much worse with PKIX-based
mechanisms too.

The above problem comes up a *lot* for GSS acceptor applications that
use GSS_C_NO_CREDENTIAL and which have actual credentials for multiple
acceptor names.

With naming extensions the application could simply call
GSS_Get_name_attribute(acceptor_name,
"urn:ietf:<TBD>:hostbased-service:hostname") to get the hostname, and
GSS_Get_name_attribute(acceptor_name,
"urn:ietf:<TBD>:hostbased-service:service") to get the service name.
And this is completely generic!

(Mechanisms that don't have true hostbased service naming and instead
substitute host naming, like the old mech_dh mechanism.)

Also add:

 - urn:ietf:<TBD>:applicable-name-type:<name-type>
   (value is "true" if the MN can be considered to be of the given name type)

 - urn:ietf:<TBD>:best-fit-generic-name-type
   (value is OID of generic name type that best fits the given MN)

and numbered component accessors:

 - urn:ietf:<TBD>:name-component:<number>

So, the list of generic name attributes so far would be:

 - issuer attributes:

 - transit path attributes
    - urn:ietf:<TBD>:transit-path
    - urn:ietf:<TBD>:transit-path-hop-name:<hop-number>
    - urn:ietf:<TBD>:transit-path-hop-name-name-type:<hop-number>
    - urn:ietf:<TBD>:transit-path-hop-name-composite:<hop-number>

 - name type and name component attributes
    - urn:ietf:<TBD>:best-fit-generic-name-type
    - urn:ietf:<TBD>:applicable-name-type:<name-type>
    - urn:ietf:<TBD>:name-component:<number>
    - urn:ietf:<TBD>:hostbased-service:service
    - urn:ietf:<TBD>:hostbased-service:hostname
    - urn:ietf:<TBD>:domainbased-service:service
    - urn:ietf:<TBD>:domainbased-service:domain
    - urn:ietf:<TBD>:domainbased-service:hostname

 - other attributes

Nico
--