Client identity selection: stored mappings

[Nico Williams]

On Wed, Mar 23, 2011 at 2:57 PM,  <ghudson at mit.edu> wrote:
> As mentioned earlier, we want the GSSAPI-krb5 code to look up a client
> principal name based on some information about the target service.  In
> the first cut, the information available will likely be the service
> name and hostname as provided to GSSAPI.  Later on, additional
> information might be available from application-provided hints (such
> as application name and application account name).  The first cut will
> probably require mappings to be maintained out of band, but later
> there might be in-band mechanisms for updating it.

One might want to use realm as a lookup key, but, of course, one might
have to first try to get a ticket in order to determine the host's
realm, but then credential selection has to have been done first.
Catch-22.  However, one could still do it this way if there are no
privacy concerns...  The client tries a credential -any and all, in
parallel- and tries to get a service ticket for the given host, then
for all the resulting unique host realms lookup which credential is
preferred.  That's quite heavyweight, but there might not be any
secure way to canonicalize the hostname, thus no secure way to pick
the right credential when the user does not enter a canonical
hostname!  Is this a privacy vs. security trade-off?  Looks like it to
me, but I may be missing something.

> I don't have a detailed proposal for mappings yet.  We don't have much
> history in accessing user-specific configuration yet.  Some open
> questions:
>
> * People have already suggested that the mapping system be pluggable.
>  Should there be some kind of aggregation of mapping modules--perhaps
>  just a configurable module order?  Or should there be just one
>  mapping module, and you can configure what it is?

I'd settle for one.

> * It would be possible to just make a pluggable mapping system and not
>  create a default module for it.  (No module means no mappings, in
>  which case GSSAPI clients would just use the default principal.)
>  We've done things like that in the past, but it tends to hinder
>  testing and adoption.

Agreed.

> * Should there be system mappings in addition to user mappings?  This
>  would probably require some kind of wildcard result which is then
>  matched against the set of available client credentials.  If there
>  are system mappings, does it make sense to use the domain_realm
>  section as a fallback?

If system mappings could be keyed by realm (see above!) then I think
system-wide mappings could be quite useful.  Otherwise probably not so
much, but I think it's safe to say that supporting system-wide
mappings would be nice.

> * We'll be starting with at least two lookup criteria (target hostname
>  and target service name).  What kind of wildcarding should be
>  supported, and how should the search order work?  KIM provides some
>  precedent here.

What you want as the lookup key is the acceptor name, whatever type it
might be (it might not be a host-based service!).  You'd probably want
to use the name in RFC1964 form, not any generic name syntax, but
minus the realm.  Or you might want to use the acceptor's realm (but
see above).

> For the default user mapping module:
>
> * File location: $HOME/.krb5/idmap?  Something else?

I don't like "idmap" for this.  I know, bikeshedding...  I'd like "idselection"

> * File format: profile?  XML?  Whitespace-separated fields?  Something
>  else?

No opinion on this yet.  If the format is XML or anything of the sort
then you'll want tools to edit the file with, tools other than
$EDITOR.

> * Update discipline for in-band updates: atomic replacement via
>  rename?  That works on Unix but not Windows.  Other options?

No opinion yet.

If you use SQLite3 then some of these problems go away (but SQLite3
doesn't mix so well with NFS home directories, so that's a
problem...).

> (KIM uses an OSX preferences file to hold user mappings, which doesn't
> provide much guidance outside of that platform.)

Well, GNOME has its own too.