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 — 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. > > 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. > > 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. > > A proxy ticket is one that was issued based on a proxiable ticket. > > Source: http://web.mit.edu/~kerberos/krb5-devel/doc/user/tkt_mgmt.html This doesn’t answer all my questions about these bits but it’s clearly not as tight as the KDC’s option, you’d 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’d leave it to end users, you’d probably end up with security issues relating the local version of it — the registry or configuration files. It could easily end up being make-belief / feel-good security which isn’t actually as strong as you might think. Cheers, -Rick
signature.asc
Description: Message signed with OpenPGP using GPGMail
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
