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@MYREALM and the > KDC for MYREALM would decide if rick@MYREALM can act as sales@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@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@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@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. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
