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
