Re: ACL for Constrained Delegation?
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 Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: ACL for Constrained Delegation?
Hi Benjamin / MIT, How would I setup these delegations, and only these delegations, with MIT Kerberos5? http://k5wiki.kerberos.org/wiki/Projects/ConstrainedDelegation notes that there is a krbAllowedToDelegateTo attribute that can be set in LDAP (manually) to limit delegation. I don't think I have an actual example handy. Thanks for the pointer! I looked into the LDAP specs for this attribute, and some questions remain. An example could give a working solution, but perhaps MIT should answer these questions by updating the project documentation page? LOOKUP: This refers to an LDAP attribute krbAllowedToDelegateTo. In the LDAP scheme, this is defined as # A list of services to which a service principal can delegate. attributetype ( 1.3.6.1.4.1.5322.21.2.4 NAME 'krbAllowedToDelegateTo' EQUALITY caseExactIA5Match SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26) This attribute may be incorporated into the krbPrincipalAux auxiliary class, which presumably is attached to krbPrincipal: ## The principal data auxiliary class. Holds principal information ## and is used to store principal information for Person, Service objects. objectclass ( 2.16.840.1.113719.1.301.6.8.1 NAME 'krbPrincipalAux' SUP top AUXILIARY MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $ krbPrincipalKey $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $ krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $ krbLastPwdChange $ krbLastAdminUnlock $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginFailedCount $ krbExtraData $ krbAllowedToDelegateTo ) ) QUESTIONS: * These specifications do not clarify how the list of services is represented in the attribute -- is it done through multiple krbAllowedToDelegateTo attributes (this is permitted) or is there a format such as space-separation or comma-separation? * These specifications do not clarify how services are declared -- probably through their krbPrincipalName or krbCanonicalName? Or does that depend on the whether there is a krbCanonicalName for the principal? Are abbreviated forms (dropping the @REALM part) permitted/advised? It’d be good to have these questions answered. Thanks for any help you can give, Rick van Rein OpenFortress Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: ACL for Constrained Delegation?
On Wed, 2014-02-19 at 09:28 +0100, Rick van Rein wrote: Hello, I’m trying to understand how to configure Constrained Delegation in the KDC. I think I got the GSSAPI client side part, notably S4U2Proxy, but I can only seem to find proxy / proxiable flags in the KDC setup. And these don’t have undisputably clear semantics, from what I’ve read. Let’s say I want to setup webmail.example.com with permissions to access LDAP, IMAP and SMTP; however, sendmail.example.com can only access SMTP and contacts.example.com can only access LDAP; schematically: HTTP/webmail.example.com — ldap/ldap.example.com HTTP/webmail.example.com — imap/imap.example.com HTTP/webmail.example.com — smtp/smtp.example.com HTTP/sendmail.example.com — smtp/smtp.example.com HTTP/contacts.example.com — ldap/ldap.example.com How would I setup these delegations, and only these delegations, with MIT Kerberos5? Hi Rick, it is not currently really possible with Standard MIT. I have introduced a mechanism to handle this in the FreeIPA project (where we build our own DAL) and with Shawn we are working on bringing this to the standard MIT LDAP driver. Se the project page here: http://k5wiki.kerberos.org/wiki/Projects/KerberosDelegationACL If you want to help with this effort there is some work to do to implement thi in the current MIT LDAP code. Simo. -- Simo Sorce * Red Hat, Inc * New York Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: ACL for Constrained Delegation?
On 02/20/2014 06:34 AM, Rick van Rein wrote: * These specifications do not clarify how the list of services is represented in the attribute -- is it done through multiple krbAllowedToDelegateTo attributes (this is permitted) or is there a format such as space-separation or comma-separation? It's done only through multiple attributes. * These specifications do not clarify how services are declared -- probably through their krbPrincipalName or krbCanonicalName? Or does that depend on the whether there is a krbCanonicalName for the principal? Are abbreviated forms (dropping the @REALM part) permitted/advised? Dropping the @REALM part should work if it is equal to the KDC realm. The value of krbAllowedToDelegateTo is parsed as a principal name using the standard parsing function, and compared to the target of the constrained delegation request. As for aliases, my reading of the code is that we have had some unintentional behavior changes across versions. * Up to 1.10, we compared against the server name in the request. * In 1.11, we compared against the canonical name of the target server. * In 1.12, we went back to comparing against the requested name. Although the change from 1.10 to 1.11 wasn't specifically intended, it might have been desirable in retrospect. For the moment, you'll need to list each service an intermediate server might request constrained delegation to. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
ACL for Constrained Delegation?
Thanks Greg, This clarifies the last pieces. Dare I suggest upgrading the (online) documentation? Thanks Simo, For adding an interesting future angle to this story -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: ACL for Constrained Delegation?
On Wed, Feb 19, 2014 at 11:41 PM, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: 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? That's exactly right. 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?) The question very much makes sense. The original Kerberos design required that the applications have the final say on policy as to, e.g., cross-realm transit path policy and authorization in general. KDCs get to reject things (e.g., if there's no cross-realm trust relationship they must reject), and they get to indicate approval (e.g., TRANSIT-POLICY-CHECKED), but in principle they leave policy to the service application. I missed the cut-off for -00 Internet-Drafts for IETF89, so the following is as-yet not submitted, but it will be submitted soon, and its goal is to address this problem: https://raw.github.com/nicowilliams/kitten/master/gss-authzid.txt Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: ACL for Constrained Delegation?
On Thu, 2014-02-20 at 22:36 +0100, Rick van Rein wrote: Hello Simo, I had a look at the project page KerberosDelegationACL, and one thing struck me as odd about the specification. * lack of AllowToImpersonate means ALL clients can be impersonated. This appears non-intuitive to me; moreover, treating the “zero case” in a special way almost always leads to trouble, exceptions and security hazards. If not in code, then it usually confuses the security admin or surrounding scripts. I have no idea if this is too late, but the following follows IMHO a more consistent / logical line while retaining expressiveness: * lack of the Krb5DelegationACL class means that NO access control restrictions are applied * lack of AllowToImpersonate means NO clients can be impersonated * to impersonate ALL clients, use a suitable regex memberPrincipal FWIW :) Too late :-) In the default case you generally allow all in these situations. This compromise comes fro the fact that there is no real grouping mechanism in the KDC nor a way to experess the concept of all, a regex would not really do it nuless you are thinking of .* We could change the code so that you have to add the literal ALL maybe, I am not opposed, and could easily migrate FreeIPA users to that syntax. Shawn, what do you think ? Simo. -- Simo Sorce * Red Hat, Inc * New York Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: ACL for Constrained Delegation?
Hi Simo, In the default case you generally allow all in these situations. You mean, you’d like to be able to add the ACL class, no further attributes and then let everyone in? Why then mention the ACL, I wonder. The rest of the ACL design says “…and if none of the rules match, than the answer is NO” and the exception for “unless there is no ACL rule, then it is YES” is an inconsistency in the structure. Such flipping points are usually where error and dismay are born. This compromise comes fro the fact that there is no real grouping mechanism in the KDC nor a way to experess the concept of all, a regex would not really do it nuless you are thinking of .*” I was thinking of that regex, yes, but didn’t know what syntax to write down :) It’d be a group named ALL, in your example. We could change the code so that you have to add the literal ALL maybe, I am not opposed, and could easily migrate FreeIPA users to that syntax. That last bit is impressive :) -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: ACL for Constrained Delegation?
On Fri, 2014-02-21 at 00:05 +0100, Rick van Rein wrote: Hi Simo, In the default case you generally allow all in these situations. You mean, you’d like to be able to add the ACL class, no further attributes and then let everyone in? Why then mention the ACL, I wonder. No, the only attribute that is allowed to be missing is AllowedToImpersonate. If any other one is missing you get no authorization. The rest of the ACL design says “…and if none of the rules match, than the answer is NO” and the exception for “unless there is no ACL rule, then it is YES” is an inconsistency in the structure. Such flipping points are usually where error and dismay are born. You misunderstood how this works, if there is no target or member principal there is nothing to match, so no ACL apply so no access is granted. This compromise comes fro the fact that there is no real grouping mechanism in the KDC nor a way to experess the concept of all, a regex would not really do it nuless you are thinking of .*” I was thinking of that regex, yes, but didn’t know what syntax to write down :) It’d be a group named ALL, in your example. Unfortunately AlowToImpersonate is not a free form field, we'd need to add something else. We could change the code so that you have to add the literal ALL maybe, I am not opposed, and could easily migrate FreeIPA users to that syntax. That last bit is impressive :) Unfortunately I kind of have to take it back. I forgot that AllowToImpersonate has actually DN syntax, so you cannot simply store ALL in there. We would need to standardize a DN that represent all users or add a separate attribute to define 'categories' as an additional filter. This was the actual reason why the default is 'all' when it is missing, mostly because all our use cases allow a specific service to proxy any users but only for specific targets. After all it makes no sense to have no allowed clients (why would you create an ACI if that were the case, absence of an ACI already prevents access). HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
ACL for Constrained Delegation?
Hello, I’m trying to understand how to configure Constrained Delegation in the KDC. I think I got the GSSAPI client side part, notably S4U2Proxy, but I can only seem to find proxy / proxiable flags in the KDC setup. And these don’t have undisputably clear semantics, from what I’ve read. Let’s say I want to setup webmail.example.com with permissions to access LDAP, IMAP and SMTP; however, sendmail.example.com can only access SMTP and contacts.example.com can only access LDAP; schematically: HTTP/webmail.example.com — ldap/ldap.example.com HTTP/webmail.example.com — imap/imap.example.com HTTP/webmail.example.com — smtp/smtp.example.com HTTP/sendmail.example.com — smtp/smtp.example.com HTTP/contacts.example.com — ldap/ldap.example.com How would I setup these delegations, and only these delegations, with MIT Kerberos5? Thanks! -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: ACL for Constrained Delegation?
On Wed, 19 Feb 2014, Rick van Rein wrote: Hello, I’m trying to understand how to configure Constrained Delegation in the KDC. I think I got the GSSAPI client side part, notably S4U2Proxy, but I can only seem to find proxy / proxiable flags in the KDC setup. And these don’t have undisputably clear semantics, from what I’ve read. Let’s say I want to setup webmail.example.com with permissions to access LDAP, IMAP and SMTP; however, sendmail.example.com can only access SMTP and contacts.example.com can only access LDAP; schematically: HTTP/webmail.example.com — ldap/ldap.example.com HTTP/webmail.example.com — imap/imap.example.com HTTP/webmail.example.com — smtp/smtp.example.com HTTP/sendmail.example.com — smtp/smtp.example.com HTTP/contacts.example.com — ldap/ldap.example.com How would I setup these delegations, and only these delegations, with MIT Kerberos5? http://k5wiki.kerberos.org/wiki/Projects/ConstrainedDelegation notes that there is a krbAllowedToDelegateTo attribute that can be set in LDAP (manually) to limit delegation. I don't think I have an actual example handy. -Ben Kaduk Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: ACL for Constrained Delegation?
On 02/19/2014 09:47 PM, Benjamin Kaduk wrote: On Wed, 19 Feb 2014, Rick van Rein wrote: I’m trying to understand how to configure Constrained Delegation in the KDC. I think I got the GSSAPI client side part, notably S4U2Proxy, but I can only seem to find proxy / proxiable flags in the KDC setup. And these don’t have undisputably clear semantics, from what I’ve read. Let’s say I want to setup webmail.example.com with permissions to access LDAP, IMAP and SMTP; however, sendmail.example.com can only access SMTP and contacts.example.com can only access LDAP; schematically: HTTP/webmail.example.com — ldap/ldap.example.com HTTP/webmail.example.com — imap/imap.example.com HTTP/webmail.example.com — smtp/smtp.example.com HTTP/sendmail.example.com — smtp/smtp.example.com HTTP/contacts.example.com — ldap/ldap.example.com How would I setup these delegations, and only these delegations, with MIT Kerberos5? http://k5wiki.kerberos.org/wiki/Projects/ConstrainedDelegation notes that there is a krbAllowedToDelegateTo attribute that can be set in LDAP (manually) to limit delegation. I don't think I have an actual example handy. 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? 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?) --dkg signature.asc Description: OpenPGP digital signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
