[36846] in Kerberos
Concealing user principal names for realm crossover
daemon@ATHENA.MIT.EDU (Rick van Rein)
Sat Mar 14 13:57:26 2015
From: Rick van Rein <rick@openfortress.nl>
Date: Sat, 14 Mar 2015 10:10:04 +0100
To: "<kerberos@mit.edu>" <Kerberos@mit.edu>
Message-Id: <F52FF3C8-97F8-46F3-9814-8CA9EE022C5C@openfortress.nl>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/mixed; boundary="===============1227278929=="
Errors-To: kerberos-bounces@mit.edu
--===============1227278929==
Content-Type: multipart/signed;
boundary="Apple-Mail=_3558CAD4-3193-46CD-9A83-43DFB844C0E1";
protocol="application/pgp-signature"; micalg=pgp-sha1
--Apple-Mail=_3558CAD4-3193-46CD-9A83-43DFB844C0E1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Hello,
I=E2=80=99ve 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=E2=80=99ve 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=E2=80=99s
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=E2=80=99m wondering=E2=80=A6
* 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
--Apple-Mail=_3558CAD4-3193-46CD-9A83-43DFB844C0E1
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iEYEARECAAYFAlUD+u8ACgkQFBGpwol1RgayTgCgkpXHDd5Gv0Jc5SMQ54hSpwxm
76gAnA/IeLcpRsR0tu2Hllr5xt5l+q4Z
=MRot
-----END PGP SIGNATURE-----
--Apple-Mail=_3558CAD4-3193-46CD-9A83-43DFB844C0E1--
--===============1227278929==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============1227278929==--
