Subject: [abfab] Delegation

From: "Jim Schaad" <[email-masked]>
Date: Wed, 18 Apr 2012 13:01:58 -0700

In the Plasma work effort we have spent much of the last month thinking
about and doing some discussions on the question of delegated access.   In
the process we have located the following SAML document
http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-delegation-cs-01.
pdf which discusses how to create a SAML statement which has the delegation
information built in.  This gives us what we need in order to do the
evaluation on the RP about what delegation has occurred.

The problem is that there is currently no way to discuss the questions of
delegation in the EAP protocols that I know of.  This has not been a problem
when we were looking at just the question of accessing a network; however
the additional resources that we are now looking at because of ABFAB are now
starting to make this an interesting question to looking at.

The questions that I would have for the EMU group are:

1.  Is there any interest in looking at the issues of how one requests a
delegated access to occur?

2.  What set of restrictions are going to be necessary for doing delegation.
At present, since the only cases that I care about are going to be the ABFAB
cases all I would actually need to the ability to say in one of the tunneled
messages a simple statement to the effect that "I want delegate access to
<name>" which would either be granted or denied.

3.  If we do delegated access, what things other than the SAML statement
returned in the ABFAB context need to be changed?  

4.  Do we need to be able to do both delegation, where the delegation
process is understood by the RP, and impersonation where the RP may not be
able to tell that the authenticated entity is not really the same as the
named entity returned to the RP from the IdP.

5.  Are there other issues that need to be discussed?

Jim

---

From: Sam Hartman <[email-masked]>
Date: Fri, 20 Apr 2012 11:42:03 -0400

We've started some discussions of delegation in the moonshot project as
well.

We're focusing more on the RP side of it. That is, how an RP obtains a
credential to act as a delegated user, rather than the question of how
we indicate to a down-stream RP that delegation has occurred.

we were thinking of providing a RADIUS attribute for an RP to ask for a
delegation credential.  If that is supplied in an access-request then an
IDP/AAA server MAY supply a credential and key in an access-accept.
That credential could be used as an EAP credential (say with some PSK
method--possibly TEAP with a PSK cipher) to attempt to act as a user.
Then the IDP would be in a position to decide whether the delegation is
permitted.

This covers as much of delegation as AD gives you today.
It does not  have a rich conversation between the user and IDP about
what delegation is required; for that you'd need to involve EMU in some
way.

Also, note that this is a form of cross-domain delegation.  Within in a
resource domain, I think it makes more sense for the RP to end up with a
Kerberos ticket (in many cases at least).

Just letting you know some thoughts going on elsewhere.

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 20 Apr 2012 15:56:44 +0000

>Just letting you know some thoughts going on elsewhere.

In this vein...

I expect, if it goes anywhere, that SAML-EC will eventually support
SAML-based delegation in the manner implemented by the Shibboleth project.
I don't have the experience yet to understand how to specify that in
conjunction with GSS, but it should be straightforward.

I'm not expecting that Moonshot would involve a SAML request in its
delegation model, but if that comes into play, it would be good to align
that work. (For the record, this is done traditionally by including an
Audience condition in the AuthnRquest.)

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Fri, 20 Apr 2012 12:08:07 -0400

>>>>> "Cantor," == Cantor, Scott <[email-masked]> writes:

>Just letting you know some thoughts going on elsewhere.

    Cantor,> In this vein...

    Cantor,> I expect, if it goes anywhere, that SAML-EC will eventually
    Cantor,> support SAML-based delegation in the manner implemented by
    Cantor,> the Shibboleth project.  I don't have the experience yet to
    Cantor,> understand how to specify that in conjunction with GSS, but
    Cantor,> it should be straightforward.

The delegated credential handle coming out of gss_accept_sec_context
should include a credential element with the appropriate delegation.
As far as how you request the delegation, we don't currently have a good
story for that.

---

From: Luke Howard <[email-masked]>
Date: Sat, 21 Apr 2012 01:18:55 +0200

> As far as how you request the delegation, we don't currently have a good

You can defer the delegation until you try to initiate a security context with the delegated credential handle. That's the design for S4U2Proxy in MIT (Nico's idea, not mine).

Or are you talking about something else... I guess this doesn't work if you need to know you'll delegate at the time of the initial authentication.

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 Apr 2012 08:51:27 -0400

>>>>> "Luke" == Luke Howard <[email-masked]> writes:

    Luke> On 20/04/2012, at 6:08 PM, Sam Hartman wrote:

    >> should include a credential element with the appropriate
    >> delegation.  As far as how you request the delegation, we don't
    >> currently have a good story for that.

    Luke> You can defer the delegation until you try to initiate a
    Luke> security context with the delegated credential handle. That's
    Luke> the design for S4U2Proxy in MIT (Nico's idea, not mine).

    Luke> Or are you talking about something else... I guess this
    Luke> doesn't work if you need to know you'll delegate at the time
    Luke> of the initial authentication.

     was assuming you needed to know at time of initial auth.
However, I don't know whether that is tru for SAML.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 24 Apr 2012 15:25:02 -0700

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.

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?

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.

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.

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.

5.  For Moonshot - how much of the delegation can be done via Kerberos
rather than SAML?

Back to my issue.

Part of what I need can be done via configuration, but I am not sure that
all of it can be.  I can think of cases where a delegation SAML statement is
going to be required and as there is no standardized way of asking for one
it is going to be problematic until that is developed.  

What can be done with active directory currently is done via either RP
delegation or configuration work on the resource.  Exchange has this complex
system of marking who a mailbox owner is and who else can play in the
mailbox and then turning that information into RFC822 header information
that almost nobody can follow.   This means that in many cases the necessary
information can be put into either attributes in the original message (Bob
is Alice's executive assistant) and then the enforcement policies can be
directly written to deal with looking for all of the different types of
roles that people can be playing and who they are playing for.  The think I
don't like about this is that somebody doing a temp placement needs to have
a different type of role and a different set of rules.  This makes the
configuration half hard no matter what you do.

Jim

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Friday, April 20, 2012 8:42 AM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: Re: [abfab] Delegation
> 
> 
> credential to act as a delegated user, rather than the question of how we
> indicate to a down-stream RP that delegation has occurred.
> 
> It does not  have a rich conversation between the user and IDP about what
> delegation is required; for that you'd need to involve EMU in some way.
> 
resource
> domain, I think it makes more sense for the RP to end up with a Kerberos
> ticket (in many cases at least).
>

---

From: Nico Williams <[email-masked]>
Date: Tue, 24 Apr 2012 21:49:01 -0500

> 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?

> 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).

> 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.

> 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.

> could not do it internally.

Why be reluctant?

> 5.  For Moonshot - how much of the delegation can be done via Kerberos

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
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 25 Apr 2012 10:52:27 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> The first is what you are looking at, that is how to allow for
    Jim> an RP to act as a delegate of the original user.  The second is
    Jim> how to allow user 1 to act as a delegate of user 2.  The second
    Jim> is the one that I am more interested in at the moment.

I'm confused.
In my mind these are not distinct.