[35778] in Kerberos
Re: ACL for Constrained Delegation?
daemon@ATHENA.MIT.EDU (Rick van Rein)
Thu Feb 20 05:17:06 2014
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Rick van Rein <rick@openfortress.nl>
In-Reply-To: <5305958F.70009@fifthhorseman.net>
Date: Thu, 20 Feb 2014 11:14:45 +0100
Message-Id: <6EB7B83B-84BB-4AB0-8D20-35F81A1A60EC@openfortress.nl>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: kerberos@mit.edu
Content-Type: multipart/mixed; boundary="===============1495023294=="
Errors-To: kerberos-bounces@mit.edu
--===============1495023294==
Content-Type: multipart/signed;
boundary="Apple-Mail=_6942973B-E4DE-4218-AF5B-CE8123A98332";
protocol="application/pgp-signature"; micalg=pgp-sha1
--Apple-Mail=_6942973B-E4DE-4218-AF5B-CE8123A98332
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
Hello,
Thanks for your responses.
> This arrangement seems to suggest that the delegation constraint is
> something that will be managed for all principals by the KDC =
explicitly,
> rather than the end user being able to decide (or even know?) what
> explicit delegations are being offered. Am i understanding this =
right?
This is what I read into it too =97 and it is what I was looking =
(asking) for.
> Is there any mechanism for user-controllable delegation? (or perhaps
> more fundamentally, does this question even make sense, given the =
power
> held by the KDC already?)
You probably know about the capabilities of forwardable and proxiable =
tickets, right? I was diverting away from that with my question, but:
> If a ticket is forwardable, then the KDC can issue a new ticket (with =
a different network address, if necessary) based on the forwardable =
ticket. This allows for authentication forwarding without requiring a =
password to be typed in again. For example, if a user with a forwardable =
TGT logs into a remote system, the KDC could issue a new TGT for that =
user with the netword address of the remote system, allowing =
authentication on that host to work as though the user were logged in =
locally.
>=20
> When the KDC creates a new ticket based on a forwardable ticket, it =
sets the forwarded flag on that new ticket. Any tickets that are created =
based on a ticket with the forwarded flag set will also have their =
forwarded flags set.
>=20
> A proxiable ticket is similar to a forwardable ticket in that it =
allows a service to take on the identity of the client. Unlike a =
forwardable ticket, however, a proxiable ticket is only issued for =
specific services. In other words, a ticket-granting ticket cannot be =
issued based on a ticket that is proxiable but not forwardable.
>=20
> A proxy ticket is one that was issued based on a proxiable ticket.
>=20
> Source: http://web.mit.edu/~kerberos/krb5-devel/doc/user/tkt_mgmt.html
This doesn=92t answer all my questions about these bits but it=92s =
clearly not as tight as the KDC=92s option, you=92d be trusting =
everything behind a service instead of controlling who-may-do-what. To =
me, the tight control sounds a bit too tedious to be dealt with by end =
users, although from a security perspective I do agree with your wish =
(if I read it correctly) to do that.
Constrained Delegation was introduced by Microsoft AFAIK, and their =
intention was to setup refined contorl in their Active Directory =
product. If you=92d leave it to end users, you=92d probably end up with =
security issues relating the local version of it =97 the registry or =
configuration files. It could easily end up being make-belief / =
feel-good security which isn=92t actually as strong as you might think.
Cheers,
-Rick
--Apple-Mail=_6942973B-E4DE-4218-AF5B-CE8123A98332
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
iEYEARECAAYFAlMF1ZUACgkQFBGpwol1RgbhTgCdFoVLv8mRwwknrMg1S6vsF9l+
BQsAoIeMMoguXmwmE4KtKrDnHGG20gj0
=8CeL
-----END PGP SIGNATURE-----
--Apple-Mail=_6942973B-E4DE-4218-AF5B-CE8123A98332--
--===============1495023294==
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
--===============1495023294==--
