ucred_t and kerberos

[Marcus Watts]

Nicolas Williams <Nicolas.Williams at sun.com> writes:
...
> > Its not clear if the "OS facilities for local auth" you are referring
> > to could handle this across two servers.
> 
> At least getpeerucred(3C) on Solaris is intended to eventually support
> operation across a network.  For now it does not.

Ok.  I'll bite.  I am not at all sure this is useful for "afs
-localauth".  It might be *very* useful for afs with rxtcp.   Soo...

As I look at solaris 10 pages, it seems to me that what getpeerucred
returns is actually a very different animal.  It's not a "kerberos
credential" at all.  It is much more like "authdata", what MicroSoft
calls a "pac", or what AFS returns from "GetCPS".  That is, it has the
user's uid (afs: viceid), plus a list of the groups the user belongs
to, & other random information.  Some of this is incredibly OS specific
(even version-specific), such as "projid", "zoneid", and "priv_set".
There doesn't seem to be any provision for "generic" information that
might be valid for another host type.  Given its context, I'm surprised
it doesn't also include the control tty, sid, & pgrp.  Missing bits
certainly include any notion of the user's loginid (kerberos principal,
or afs "name").  Also missing is the kerberos session key; perhaps just
as well given it doesn't seem to have any connection whatsoever to
kerberos.  Interesting, getpeerucred does have the notion of working
with several local file descriptor types, including tcp -- all via
"streams".

So, in tomorrow's world, let us suppose we had (say) a linux machine, a
windows machine, & a sun machine, all happily exchanging ucred_t's via
tcp.  How can they each know that the ucred_t that they receive hasn't
been tampered with on the wire (after all, streams are internal to
solaris; on the wire it's pure tcp/ip).  What extension to tcp allows
this traffic to pass?  How would the linux, windows, & sun machines
know that the ucred they receive on the wire is for a local
authorization domain that the machine should actually trust (for
instance, if the ucred_t says that the user has "root" privileges,
should the local machine believe that?)  How is the content being
passed on the same connection being secured from tampering?
For certain applications, I might want to have a single process
that can act on behalf of multiple different users at once.
The AFS cache manager and in general unix don't handle this (well),
but with windows, I can do very interesting things by switching
security tokens on the fly.  With AFS, I can write programs
that manage multiple rx client connections using different
user credentials and kerberos tickets.  What should I expect to see
that works with getpeerucred to provide this functionality?

And, of course, how does this all relate to Kerberos, and in
general, what ietf or other groups should I expect to see discussion
about this?

				-Marcus Watts