[Wg-uma] Fwd: [OAUTH-WG] [Fwd: I-D ACTION:draft-vrancken-oauth-redelegation-00.txt]

Diego R. Lopez diego.lopez at rediris.es
Fri Sep 11 04:28:21 PDT 2009


Hi,

On 10 Sep 2009, at 17:06, Eve Maler wrote:
> Interesting.  It would be great if you could briefly walk us through  
> your understanding of the redelegation draft on the call, to make  
> sure we're all up to speed...?  If we have ideas to contribute to  
> that discussion, what's the best way to do that?


My apologies again for throwing this at you and not showing in the  
call, but I was nor allowed to make any kind of connection
while flying from Vienna...

Looking at the minutes of the call, I'd like to stress my idea that I  
see the multiple delegation OAuth profile as
an opportunity of offering an enhanced user experience by combining an  
AM and a AM-aware First Client. This way,
the access to certain resources matching common policies could be  
simplified, as the First Client could directly
transfer credentials. In no way I was thinking of a possible  
substitution of an AM for the delegation schema.

In what relates to the security concerns regarding delegation, I'm  
attaching the discussion I had with Richars Barnes
on this issue some time ago. I guess that any comment we have on this  
can be forwarded to the oauth at ietf.org list.

Be goode,

8 
< 
---------------------------------------------------------------------------------------------------
From: "Diego R. Lopez" <diego.lopez at rediris.es>
To: Richard Barnes <rbarnes at bbn.com>
Cc: Peter Saint-Andre <stpeter at stpeter.im>, "oauth at ietf.org" <oauth at ietf.org 
 >
Subject: Re: [OAUTH-WG] What is 4-legged OAuth?
Date: Wed, 29 Jul 2009 11:59:32 +0200

On 29 Jul 2009, at 11:25, Richard Barnes wrote:

 > That of course raises another point that I'm not clear on: Why is
 > the 3-legged case not composable?  Once an authorization has been
 > delegated to the Client, it seems like the Client could in principle
 > act as a Resource Owner for that authorization, so that he could
 > delegate to the next tier.
 >
 > There may be a desire for the RO to be able to flag that the Client
 > can sub-delegate his delegated authorization, but that would seem to
 > be an issue of the scope of the authorization, which has been
 > outside the scope of the protocol.


I'm afraid that, unless you define a very clear procedure for that
delegation, the whole protocol would
be signed as breaking privacy (and I think it can probably be the
case). Having written and implemented
a delegated authorization profile for SAML, I can tell preserving
privacy is not easy at all in the moment
you allow delegations to be stacked, and other solutions, like the
external services depicted by
ProtectServe do scale much better.

8 
< 
---------------------------------------------------------------------------------------------------
From: Richard Barnes <rbarnes at bbn.com>
To: "Diego R. Lopez" <diego.lopez at rediris.es>
CC: Peter Saint-Andre <stpeter at stpeter.im>, "oauth at ietf.org" <oauth at ietf.org 
 >
Subject: Re: [OAUTH-WG] What is 4-legged OAuth?
Date: Wed, 29 Jul 2009 12:33:55 +0200

Diego,

Having a well-defined procedure for delegation was the point of OAuth in
the first place!  I'm just not clear on what risks you introduce by
re-using it to sub-delegate; none are immediately clear to me.

8 
< 
---------------------------------------------------------------------------------------------------
From: "Diego R. Lopez" <diego.lopez at rediris.es>
To: Richard Barnes <rbarnes at bbn.com>
Cc: Peter Saint-Andre <stpeter at stpeter.im>, "oauth at ietf.org" <oauth at ietf.org 
 >
Subject: Re: [OAUTH-WG] What is 4-legged OAuth?
Date: Wed, 29 Jul 2009 13:25:10 +0200

Richard,

On 29 Jul 2009, at 12:33, Richard Barnes wrote:
 > Having a well-defined procedure for delegation was the point of
 > OAuth in the first place!  I'm just not clear on what risks you
 > introduce by re-using it to sub-delegate; none are immediately clear
 > to me.

If I have understood you well, what you proposed is to allow clients
to forward their authorization tokens
to other potential clients. To do so, you can make it with or without
user explicit consent. In the first case,
unless you send back the user to the SP (what would be exactly the
same as the three-legged case with just
a shorter path in user interactions) you are allowing a third party to
ask the user to take decisions on
access to the SP, and this seems to me a clear path for phishing. In
the second case, you are simply
transmitting the authotization without the explicit user consent, and
that would break several privacy
protecting laws (at least, here in the EU)

Furthermore, since traceability is a essential requirement for any
access control infrastructure,
the unconstrained delegation would require a strict control of the
potential clients that can share
a token at the SP, including a detailed check of who is using the
token and from whom it was generated,
and this requires as well the ability of tracing the delegation path
up to the original client, implying
that tokens must be augmented with traces of the delegations, and
you'll agree in that this won't scale.

8 
< 
---------------------------------------------------------------------------------------------------
From: Richard Barnes <rbarnes at bbn.com>
To: "Diego R. Lopez" <diego.lopez at rediris.es>
CC: Peter Saint-Andre <stpeter at stpeter.im>, "oauth at ietf.org" <oauth at ietf.org 
 >
Subject: Re: [OAUTH-WG] What is 4-legged OAuth?
Date: Wed, 29 Jul 2009 14:07:16 +0200

You're misunderstanding what I'm proposing.  Let me try to state what
I'm thinking more clearly.  For consistency, I'll use terms from
draft-barnes-oauth-model.

I'm not proposing that one client simply pass its access token to some
other potential client -- you're absolutely correct that that doesn't
provide the user approval or traceability that you would want.

What I'm talking about is doing the *entire* OAuth delegation procedure
twice: First with the User as RO and Client1 as Client, then again with
Client1 as RO and Client2 as Client (the Server being the same the whole
time).  In graphic form:

                                 +----------+            --+
                                 | Resource |              |
                                 | Owner 1  |              |
                                 +----------+              |
                                      ^|                   | OAuth 1

                                      ||                   |
                              req-tk-1||ver-tk-1           |
                                      |V                   |
                                 +----------+----------+   |
       +-----------req-tk-1----->| Client   = Resource | --+
       | +---------acc-tk-1----->| 1          Owner 2  | --+
       | |                       +----------+----------+   |

  +----------+                        ^|                   |
  | Server   |                        ||                   |
  |          |                req-tk-2||ver-tk-2           | OAuth 2

  +----------+                        |V                   |
       | |                       +----------+              |
       | +---------req-tk-2----->| Client   |              |
       +-----------acc-tk 2----->| 2        |              |
                                 +----------+            --+


Doing this would enable accountable sub-delegation, since all the
delegations are made through the Server.

The one thing that's not immediately clear is how you fit user consent
for the sub-delegation into this picture.  But there's an easy answer
there too: Permission to sub-delegate is just another permission that
can be delegated via OAuth.  In the above example, Client1 would have to
receive permission to sub-delegate to Client2 in his initial
transaction.  You could also imagine a three-OAuth model, where:
1. OAuth1: RO grants Client1 permission to access resources
2. Client1 requests permission to sub-delegate to Client2
3. OAuth2: RO grants Client1 permission to sub-delegate to Client2
4. OAuth3: Client 1 grants Client2 permission to access resources

Either way, these are just concatenations of OAuth transactions.  What's
missing, besides an informational document to describe how this works?

8 
< 
---------------------------------------------------------------------------------------------------
From: "Diego R. Lopez" <diego.lopez at rediris.es>
To: Richard Barnes <rbarnes at bbn.com>
Cc: "oauth at ietf.org" <oauth at ietf.org>
Subject: Re: [OAUTH-WG] What is 4-legged OAuth?
Date: Wed, 29 Jul 2009 18:34:15 +0200

Hi Richard,

On 29 Jul 2009, at 14:07, Richard Barnes wrote:

 > You're misunderstanding what I'm proposing.  Let me try to state
 > what I'm thinking more clearly.  For consistency, I'll use terms
 > from draft-barnes-oauth-model.
 >
 > I'm not proposing that one client simply pass its access token to
 > some other potential client -- you're absolutely correct that that
 > doesn't provide the user approval or traceability that you would  
want.
 >
 > What I'm talking about is doing the *entire* OAuth delegation
 > procedure twice: First with the User as RO and Client1 as Client,
 > then again with Client1 as RO and Client2 as Client (the Server
 > being the same the whole time).  In graphic form: . . .

Agreed. I totally misunderstood your first statement, probably because
the fourth leg idea misled me. Looking
at it now, it totally makes sense, though I'd say is more a chained-
three-legged than a four-legged model...

 > Doing this would enable accountable sub-delegation, since all the
 > delegations are made through the Server.

Indeed.

 > The one thing that's not immediately clear is how you fit user
 > consent for the sub-delegation into this picture.  But there's an
 > easy answer there too: Permission to sub-delegate is just another
 > permission that can be delegated via OAuth.  In the above example,
 > Client1 would have to receive permission to sub-delegate to Client2
 > in his initial transaction.  You could also imagine a three-OAuth
 > model, where:
 > 1. OAuth1: RO grants Client1 permission to access resources
 > 2. Client1 requests permission to sub-delegate to Client2
 > 3. OAuth2: RO grants Client1 permission to sub-delegate to Client2
 > 4. OAuth3: Client 1 grants Client2 permission to access resources

Or a fourth or a fitfth or... That's why I think that calling it
"chained" would be better.

 > Either way, these are just concatenations of OAuth transactions.
 > What's missing, besides an informational document to describe how
 > this works?

Nothing, I'd say... Anyway, I still have a couple of concerns about
usability and transitivity. Usability in
this context is very much connected to practical security and to the
requirement for informed consent: I think
that the way in which confirmation for delegation and its limits are
presented to the user is a key aspect, and
should be stressed in the discussion of security aspects. Second, I
assume that the permission for delegation
can only be granted by the first transaction, so further delegations
in delegated transactions should be
explicitly prohibited.

8 
< 
---------------------------------------------------------------------------------------------------

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez

Red.es - RedIRIS
The Spanish NREN

e-mail: diego.lopez at rediris.es
jid:        diego.lopez at rediris.es
Tel:    +34 955 056 621
Mobile: +34 669 898 094
-----------------------------------------






More information about the Wg-uma mailing list