headers
Jim Schaad | 18 Apr 2012 22:01

Delegation

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
(Continue reading)

Permalink | Reply |
headers
Sam Hartman | 20 Apr 2012 17:42
Favicon

Re: Delegation


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.
Permalink | Reply |
headers
Cantor, Scott | 20 Apr 2012 17:56
Picon
Favicon

Re: Delegation

On 4/20/12 11:42 AM, "Sam Hartman" <hartmans <at> painless-security.com> wrote:
>
>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
Permalink | Reply |
headers
Sam Hartman | 20 Apr 2012 18:08
Favicon

Re: Delegation

>>>>> "Cantor," == Cantor, Scott <cantor.2 <at> osu.edu> writes:

    Cantor,> On 4/20/12 11:42 AM, "Sam Hartman" <hartmans <at> painless-security.com> wrote:
    >> 
>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.
Permalink | Reply |
headers
Luke Howard | 21 Apr 2012 01:18
Favicon
Gravatar

Re: Delegation


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

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

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
Permalink | Reply |
headers
Sam Hartman | 23 Apr 2012 14:51
Favicon

Re: Delegation

>>>>> "Luke" == Luke Howard <lukeh <at> padl.com> writes:

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

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

    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.
Permalink | Reply |
headers
Jim Schaad | 25 Apr 2012 00:25

Re: Delegation


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
(Continue reading)

Permalink | Reply |
headers
Nico Williams | 25 Apr 2012 04:49

Re: Delegation

On Tue, Apr 24, 2012 at 5:25 PM, Jim Schaad <ietf <at> augustcellars.com> 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.
(Continue reading)

Permalink | Reply |
headers
Sam Hartman | 25 Apr 2012 16:52
Favicon

Re: Delegation

>>>>> "Jim" == Jim Schaad <ietf <at> augustcellars.com> 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.
Permalink | Reply |

Gmane