Concealing user principal names for realm crossover
Nico Williams
nico at cryptonector.com
Wed Mar 18 12:03:18 EDT 2015
See the IETF ABFAB WG. They have a GSS mechanism that can do what you want.
Kerberos can also do what you want (though some KDC-side pieces may
need to get written), as follows: a) it has two forms of anonymous
principal names (with anon realm and with non-anon realm; you want the
latter), b) there's authorization-data, including the AD PAC and the
CAMMAC to carry embedded authorization data, and you could design your
own if need be.
Per-group principal names are not that useful, especially if you have
many group memberships. First, it means having lots of TGTs, second,
it means greatly complicating identity selection! If you only have a
handful of group memberships, then you could manage until you have
many, but then what?
The ABFAB approach is to let some other entity (your KDC/IdP/whatever
and/or proxies) take care of adding/removing assertions about your
group memberships and privileges, as well as hiding your identity, as
you transit to the target principal. This is much easier on the
client application and mechanism. Kerberos too can do this, the
"other entity" being the KDCs, of course, but perhaps only when used
by chasing referrals, since the KDCs have to know the service
principal name in order to properly edit their assertions. Of course,
this approach does mean putting a lot of policy (and a mechanism for
expressing it, and keeping it consistent) in the KDCs.
Active Directory basically does all of this within and across forests,
though without hiding principal names unless the client asks to, and
with some limitations (e.g., services tend to see all your memberships
in groups from their respective forests).
RedHat's FreeIPA may provide some similar functionality, but I'm not
familiar with it. Ditto Samba.
Nico
--
More information about the Kerberos
mailing list