Concealing user principal names for realm crossover

[Rick van Rein]

Hi Nico,

Thanks.

> See the IETF ABFAB WG.  They have a GSS mechanism that can do what you want.

I’m not sure what you mean — they have GSS-EAP of course, but is that
what you mean?

> 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?

Yes, this is a problem to solve.

> 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.

Yes.  In the ARPA2.net infrastructure we are assuming a hosted KDC
and it might take on this task, but that would complicate the KDC.
On the client end, we will probably place this in to our "TLS Pool”
daemon (which is like to also support SSH and GSS-based transports)
so we could also automate much there.  The advantage of the latter
is that it might interact with the user for new connections.

Cheers,
 -Rick