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@MYREALM and the KDC for MYREALM would decide if rick@MYREALM can act as sales@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@MYREALM to one server, and helpdesk@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@MYREALM and I could add a group TGT for rick/sales@MYREALM and, based on that, request a service ticket that will be in the name of sales@MYREALM. Note how the intermediate principal name rick/sales@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos