Concealing user principal names for realm crossover

[Greg Hudson]

On 03/14/2015 05:10 AM, Rick van Rein wrote:
> I’ve been looking for ways of concealing principal names with Kerberos.  I think this
> is of interest in relation to Internet-wide realm crossover with Kerberos.  The only
> way I found are the anonymity mechanisms of RFC 6112, but that provides too little
> information to the service to support any form of access control; it would be more
> useful to have an intermediate level of concealment, based on pseudonyms, roles
> and groups.  The service would be configured to permit sales at MYREALM and the
> KDC for MYREALM would decide if rick at MYREALM can act as sales at MYREALM.

I can think of two basic ways of modeling this:

1. Use authorization data to convey group membership, and request a
partially-anonymous ticket (WELLKNOWN/ANONYMOUS at REALM) with
authorization data indicating membership in a specific group.

2. Use principal names to identify groups, and allow group members to
obtain tickets for group principal names on the basis of their
individual TGTs.

Option #1 is more in keeping with the tradition of Active Directory.
What's missing is:

* The PAC isn't standardized.

* Asking for a group membership authorization data element in a
partially anonymous ticket isn't standardized.

* Groups as you describe them are scoped to the client realm; groups
scoped to the server realm don't match the problem statement.  I'm not
sure how groups conveyed in PACs are scoped.

Option #2 requires a choice of how group members obtain tickets.  Some
possibilities include:

2a. A TGS request with a specified cname.

2b. A FAST AS request using the member's ticket as the armor ticket.
(This sounds attractive at first because you can already express it as a
kinit command, but what would the reply key be?)

2c. An AS request with a new preauth mechanism (or just repurposing
PA-TGS-REQ as a preauth mech).

Option #2 clearly scopes group names to the client realm, requires no
changes to application server tooling (you just grant access to
sales at REALM like you would any other principal), and doesn't require any
special processing by the target realm.  But I'm still not sure it would
be the preferred option on kitten.

All the options require additional tooling on the client as well as
additional processing by the client realm KDC.  On the client side, one
needs to think about how the decision to conceal the principal name is
made.  If it's user-driven, option #2 and ccache collections get you
most of the way there: you just issue a special kinit command (or GUI
equivalent) to get a TGT for sales at MYREALM, store that ticket in the
cache collection, and use that cache to authenticate.  If it's
application-driven or configuration-driven, option #1 might work better,
with the partially anonymous ticket stored in the same cache as the
individual's tickets.

>  * Is this concealment of user names considered a good idea?

I've heard the idea come up before.  For example, an academic journal
access service might want to know that you're a student or professor at
a university which has paid for journal access, but it doesn't really
want to know specifically who you are.  But I don't know if it's a
common enough use case to justify the added complexity.