Subject: [OAUTH-WG] [Fwd: New Version Notification for draft-barnes-oauth-model-00]

From: Richard Barnes <[email-masked]>
Date: Mon, 06 Jul 2009 14:57:33 -0400

Hi all,

As promised at IETF 74, Matt and I spent some time thinking about the 
security model underlying OAuth, abstracted from the specific HTTP 
mechanics.  This draft attempts to explain how the OAuth authorization 
model works, what security features it provides, and how.  Hopefully 
this will help make the protocol documents more comprehensible, and 
maybe even provide a framework to extend OAuth to other protocols than 
HTTP.

Until it gets mirrored over to the tools site, you can find the draft here:
<http://www.ietf.org/internet-drafts/draft-barnes-oauth-model-00.txt>

Questions, comments, and all other feedback are welcome.

Thanks a lot,
--Richard

-------- Original Message --------
Subject: New Version Notification for draft-barnes-oauth-model-00
Date: Mon,  6 Jul 2009 11:52:05 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
CC: [email-masked]

A new version of I-D, draft-barnes-oauth-model-00.txt has been 
successfuly submitted by Richard Barnes and posted to the IETF repository.

Filename:	 draft-barnes-oauth-model
Revision:	 00
Title:		 The OAuth Security Model for Delegated Authorization
Creation_date:	 2009-07-06
WG ID:		 Independent Submission
Number_of_pages: 20

Abstract:
This document describes the security model for the OAuth
authorization system, which allows a party that holds some
authorization to delegate a subset of that authorization to another
party, without requiring either party to disclose its credentials to
the other.  In this document, we describe a set of design
constraints, a high-level work flow for establishing authorizations
subject to those constraints, and set of security requirements for
protocols that implement this model.

The IETF Secretariat.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 07 Jul 2009 14:43:23 -0600

<hat type="individual"/>

> Questions, comments, and all other feedback are welcome.

IMHO this document provides a very clear introduction to the concepts
behind OAuth. It has quite a bit of overlap with the web-delegation I-D;
do you have plans to merge the two or at least cross-pollinate?

A few relatively minor comments...

1. The document is not always internally consistent regarding
terminology (e.g., it sometimes uses "Consumer" instead of "Client").
Furthermore, consistency across OAuth documents would be helpful for
implementers (e.g., the pages at http://oauth.net/ use the terms
"Consumer", "Service Provider", and "User"). I do like the use of the
terms "Server" and "Client" because then the term "Resource Owner" can
be seen as an addition to the standard client-server model, as pointed
out in the spec.

2. I found the definitions of "request token", "verification token", and
"access token" to be unclear, specifically the use of "is associated" as
definitional (perhaps it would help to describe the purpose of each
token and the data that they contain, not merely the entities that are
"associated" via the tokens).

3. It's not clear to me what this means under Section 3.1 ("Trust
Assumptions"):

   We do not assume that any entity acting as an RO is the genuine
   RO for the protected resources.  This assurance will need to be
   provided by the authorization system.

Do you mean one of the following, or something different?

(3a) We cannot know if the principal (human) controlling an RO-agent is
the correct principal.

(3b) The Server determines if the purported RO is the genuine RO via
standard authentication mechanisms.

If (3b) then I think we want to use the term "authentication" here, not
"authorization".

4. Under Section 4.1 ("General Requirements and Assumptions"), I find
this text strange:

   The Server MUST be able to authenticate both to the Client and the
   RO, but may use different identities for each.

Why would the Server need to use different identities? Perhaps there is
a use case for that, but it might be helpful to spell it out.

5. Under Section 4.3.2 ("Verification Token Issuance"), it appears that
authentication of the Resource Owner by the Server occurs before the
channel between those two parties is protected with regard to integrity
and confidentiality. It might be helpful to spell out the reasons for
this order.

6. Under Section 5.1 ("Protection from Outside Interference"), there is
a simple typo "The Client knows that the Client is the genuine RO..."
(change second instance of "Client" to "RO").

That's it for now. Thanks for working on this document.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Richard Barnes <[email-masked]>
Date: Wed, 08 Jul 2009 17:20:37 -0400

Hey Peter,

Thanks for your comments.  I've submitted -01 with changes that I hope 
will address most of them:
<http://tools.ietf.org/html/draft-barnes-oauth-model-01>
<http://tools.ietf.org/rfcdiff?url2=draft-barnes-oauth-model-01.txt>
(Thank goodness for the later revised draft deadline!)

Responses to your comments inline below.

--Richard

> do you have plans to merge the two or at least cross-pollinate?

Not concretely, but I agree that it makes sense to align the two. 
Separate drafts probably still makes sense, but maybe this draft can 
relieve -web-delegation of the need to explain big-picture stuff, 
allowing it to focus more on how information gets carried between 
parties and how authentication is done.

> be seen as an addition to the standard client-server model, as pointed

Geez, there was *one* "Consumer" that slipped in!  I deleted it, and 
replaced with Client.  I'm really agnostic as to the terminology; I just 
went with "Client/Server/RO" because that was what draft-hammer-oauth used.

> "associated" via the tokens).

I changed the definitions in -01 to try to clarify (1) that the Server 
issues them as temporary identifiers for things (Clients, 
authorizations), and (2) what the tokens mean when they come back to the 
Server ("give me a verfication token for this Client", "I've been 
granted this authorization").  Let me know whether the current text is 
better.

> 3. It's not clear to me what this means under Section 3.1 ("Trust
...
> If (3b) then I think we want to use the term "authentication" here, not

Replaced this sentence with one that is hopefully a little clearer:
"
We do not assume that any entity acting as an RO is the genuine RO for 
the protected resources.  It will be necessary for the OAuth system to 
provide the Client and Server assurance that the RO in the process is 
the genuine owner of the resources in question.  (The Server can verify 
this directly, with standard authentication mechanisms; the Client will 
rely on an authenticated assertion by the Server.)
"

> a use case for that, but it might be helpful to spell it out.

Don't have a use case, just wanted to be clear that the "same identity" 
requirement for the other two entities doesn't apply to the Server 
(primarily since the server is authoritative -- if someone impersonates 
it, the process just fails) Changed to:
"
The Server MUST be able to authenticate both to the Client and the RO, 
but it is not required to use the same identity for both.
"

> and confidentiality. It might be helpful to spell out the reasons for

The reason for this is that there are different requirements for the 
*request* for a verification token and the *response* containing the 
token: The request just needs RO authentication, while the response also 
needs confidentiality protection.  Added a para to clarify:
"
    Some might note that there is an asymmetry to the security
    requirements for the two halves of this transaction: The request for
    a verification token is only authenticated, while the response also
    needs to be confidentiality- and integrity-protected.  This is
    because the injection of a false request token can only cause the
    process to fail (since the Client identity provided by the server
    will be wrong), while leakage of the verification token can cause
    used to grant an unintended authorization.  For simplicity, it is
    RECOMMENDED that the same channel (with full protections) be used for
    the request and the response.
"

> (change second instance of "Client" to "RO").

Fixed.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 08 Jul 2009 17:05:47 -0600

<hat type="individual"/>

Thanks, Richard! A few comments below.

> parties and how authentication is done.

That makes sense.

> granted this authorization").  Let me know whether the current text is

Will do.

> but it is not required to use the same identity for both.

The vague thought in my head was that if the Client and RO want to
compare notes about the Server, it would be helpful for the Server to
appear the same to the other parties.

>    the request and the response.

My concern was that there might be an authentication downgrade attack
(e.g., downgrade DIGEST to PLAIN) if the channel is not protected before
authentication occurs, but I did not give it a great deal of thought
before formulating my question so I might be off-base here. I'll ponder
it further before raising the issue again. :)

Peter

- --
Peter Saint-Andre
https://stpeter.im/