On Tue, Apr 24, 2012 at 5:25 PM, Jim Schaad <[email protected]> wrote: > The first is what you are looking at, that is how to allow for an RP to act > as a delegate of the original user. The second is how to allow user 1 to > act as a delegate of user 2. The second is the one that I am more > interested in at the moment.
There are several authorization decisions to make. Is a given client principal allowed to delegate credentials? to what target principals? and what third principals can those targets impersonate the client to? and does the client get to decide or influence the answer to the previous question? > However looking at the first case there are some questions that I think are > interesting. > > 1. Should the fact that a delegation is occurring - and perhaps what > delegation is occurring - be something that the user should be able to see > and thus be a candidate for channel bindings? In the Microsoft S4U model the user doesn't get to know that the target principal will be impersonating the user. I've considered (and still may implement) a GSS-equivalent of the ssh-agent as a way to delegate credentials by proxying back to the client. This approach allows real-time auditing UIs for the user, but the client has to be online as long as those "delegated" credentials are needed (this is both, a feature and a bug). Whether the user should get to see an audit trail of some (which?), all, or no impersonation events is itself an authorization issue. (Since the user could always use a "gss-agent" the user could always see an audit trail, but, of course, only if the target supports/allows this). > 2. At what point will the RP know that a delegation operation is needed. I > think that there may be many cases where this is not known at the start as > noted in your last message. It is also possible that different delegation > statements may be needed to talk to different entities. What RP2 and RP3 > will accept may not be quite the same SAML statements. Thus it is possible > that multiple delegation statements may be required. In the GSS-API the simplest thing to do is to pretend that the client principal did delegate credentials to the acceptor, and the acceptor will find out to what extent those credentials work when... it tries to initiate security contexts with them. Trying to represent constrained credentials in more detail is something we could attempt if need be, but most likely will be a dead end (e.g., there is nothing a Kerberos acceptor can do to get, say, a list of principals that an S4U2Proxy credential can be used for). In other words: the best we can do is probably to pretend the acceptor has a full delegated credential even though it may fail in some, most, or even all cases. > 3. The delegated SAML statement is quite probably not going to be the same > as the SAML statement about the subject. The set of attributes may be > restricted in several different ways. I think that this means that there > may be a requirement for a request of a delegated SAML statement that would > be independent of a request for a new SAML statement with additional > attributes. I believe that the second is doable through Josh's draft but > the first has no standardization at all. A delegated credential allows for impersonation, so, yes, a delegated GSS-EAP credential necessarily has to be different than a typical SAML statement. A RADIUS request for delegated credentials is very much akin to Kerberos S4U. > 4. I would be very reluctant to standardize asking for delegation as a > Radius attribute. That being said I don't see any reason that Moonshot > could not do it internally. Why be reluctant? > 5. For Moonshot - how much of the delegation can be done via Kerberos > rather than SAML? You could use S4U. Windows uses S4U to transition PKI to Kebreros. EAP to Kerberos would be very, very similar -- the same, actually. But the "delegated" credential that results will have fairly limited scope, such as allowing the RP to impersonate the client to a small number of services in the same realm as the RP, or in an AD forest, but not to arbitrary services all over the Internet, say. Nico -- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
