Re: choosing principal names

On Wed, Oct 5, 2011 at 12:39 PM, Russ Allbery <[email protected]> wrote:
> Love Hörnquist Åstrand <[email protected]> writes:
>
>> I think there should be very little kerberos programmers, there should
>> be more gss programmers.
>
> Which reminds me: does anyone have a good "guide to GSS names for Kerberos
> developers"?  The GSS naming scheme has always been completely opaque to
> me, and I'm afraid that the GSS-API code I've written just uses cargo-cult
> naming conventions without understanding them.

It's pretty simple, really:

 - on gss_import_name() of a string you need a name-type that
determines the syntax of that string
    - GSS_C_NT_HOSTBASED_SERVICE means the string must be in the form
service@hostname
    - GSS_C_NT_USERNAME means the string must be a username (no domain
qualifier is specified, but in an AD forest world it should be used)
    - GSS_C_NULL_OID or GSS_KRB5_NT_PRINCIPAL_NAME means the string is
a raw Kerberos principal name in unparsed form (i.e., with '/' and '@'
characters backslash-quoted, with components separated by '/', and the
realm separated by '@', ... all per-RFC1964).
   - there's also GSS_C_NT_DOMAINBASED__SERVICE, but most of you
aren't going to be using it

 - gss_display_name() gives you raw Kerberos principal names (again,
in unparsed, RFC1964 form)

There's also "naming extensions", where attributes like, e.g., the
MSFT AD PAC, are associated with and retrievable from the gss_name_t
object representing the source principal of an established security
context on the acceptor side.

Authorization should generally be done on the basis of:

 - gss_export_name() tokens compared (or looked up) byte-wise
 - gss_display_name() strings (and name type) compared like strings
(this is not guaranteed to work well for every mechanism, so it's not
advisable -- it will work for Kerberos, however)
 - name attributes (SIDs from the PAC, etc...)

For example, an NFS server could map an RPCSEC_GSS client principal to
filesystem IDs (user IDs and group IDs) using:

 - a table indexed by exported name token
 - a set of rules for mapping principal names to usernames, then
lookup the user/group IDs of the resulting users
 - name attributes (SIDs from the PAC)

The upcoming RPCSEC_GSSv3 actually allows the client to assert some
additional user/group IDs on the wire, and the server can then use
various contextual information to decide whether to allow those.
Similarly for privileges ("capabilities", in Linux speak) and labels.
So that the totality of the authorization context can be a bit more
than the client principal's name and credentials might otherwise imply
without any additional context (context, here, includes such things as
share options).

Nico
--