Concealing user principal names for realm crossover

[Simo Sorce]

On Sat, 2015-03-14 at 10:10 +0100, Rick van Rein wrote:
> Hello,
> 
> 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.
> 
> So, what I’ve been looking for is a mechanism to change the cname, possibly without
> new password entry.  The client code would know how to request these new identities,
> possibly differntiating for the various services contacted; I might be sales at MYREALM
> to one server, and helpdesk at MYREALM to another.  I am hoping to find a way to
> modify software, but not the protocol; but that might be an unachievable ideal.
> 
> The practice of adding a slash and a second level could be helpful.  My initial TGT might
> be rick at MYREALM and I could add a group TGT for rick/sales at MYREALM and, based
> on that, request a service ticket that will be in the name of sales at MYREALM.  Note how
> the intermediate principal name rick/sales at MYREALM can be helpful in the formulation
> of policies, and how the existence of this name establishing group membership, even for
> internal use.  (Policy might of course require a password, for instance for */admin@*)
> 
> I have investigated two angles, but neither seems to work:
>  (1) change my client name; canonicalisation from RFC 6806 could help here, but it
>      explicitly constrains canonicalization to AS exchanges.
>  (2) one might request encrypting a TGT to another TGT, perhaps using RFC 4120’s
>      additional-tickets field in KDC-REQ-BODY, along with the ENC-TKT-IN-SKEY flag.
>      But as far as I can tell, this is not normally used with a newly requested cname.
> 
> So now I’m wondering…
>  * Is this concealment of user names considered a good idea?

It may be useful

>  * Am I correct that there libkrb5 and GSS-API do not support this?

Probably they don;t as it has never been considered this way.

>  * Is the idea of going through user/role with KDC-enforced policy good?

I do not think the idea of changing principal names to be particularly
good.

>  * Am I correct that there are no protocol elements for it yet?

No, there is Authorization Data which you should use for this kind of
messaging. You can use the CAMMAC now to be able to assign roles in a
custom AD and have it transported from your TGT to service tickets w/o
further processing power spent at TGS time.

>  * Are the ideas under (1) and (2) above worth considering?

Probably not. (1) should be handle with additional Authorization Data
(2) probably using FAST into a pkinit anonymous channel.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York