Concealing user principal names for realm crossover

[Rick van Rein]

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?
 * Am I correct that there libkrb5 and GSS-API do not support this?
 * Is the idea of going through user/role with KDC-enforced policy good?
 * Am I correct that there are no protocol elements for it yet?
 * Are the ideas under (1) and (2) above worth considering?

Thanks!
 -Rick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20150314/e31fd8d5/attachment.bin