Subject: [OAUTH-WG] why are we signing?

From: Brian Eaton <[email-masked]>
Date: Sun, 8 Nov 2009 21:02:53 -0800

Hey folks -

What are the use cases for cryptography in OAuth?  Why are we signing
requests?  And how much of each request do we need to sign in order to
be useful?

As I see it, we have roughly the following menu of choices:

1) No signatures.
    Just use bearer tokens.  Use transport layer encryption to keep
those bearer tokens from leaking.

2) Signed tokens.
    We could just sign a timestamp, rather than entire messages.

3) Partially signed messages.
    We could sign just the request URL, or the request URL plus some parameters.

4) Fully signed messages.
     Sign as much of the HTTP request as possible, down to the bits of
the HTTP entity body.

My guess is we need at least two out of those four choices (one with
bearer tokens, a la OAuth 1.0 plaintext) and another with
cryptography.  But I'm not sure whether we need to sign entire
messages, or if we can get away with something simpler and still have
reasonable security.

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 9 Nov 2009 00:48:32 -0700

The problem is, we are not likely to ever reach consensus on 'reasonable security'.

For example, I don't find most cookie-based session systems reasonably secure without SSL/TLS. Being able to sit at a coffee shop with free wifi and a laptop and steal sessions cookies, then access people's email for the duration the cookie is valid isn't reasonable or secure.

If you would like to try this approach, I would suggest adding next to each option the list of common attacks still possible under those terms. It will allow us to evaluate the added security each level of complexity brings.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Eaton
> Sent: Sunday, November 08, 2009 9:03 PM
> To: [email-masked]
> Subject: [OAUTH-WG] why are we signing?
> 
> Hey folks -
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Chris Messina <[email-masked]>
Date: Mon, 9 Nov 2009 00:00:09 -0800

Indeed, in the beginning of OAuth, that was one of the primary drivers that
lead us to the decision to sign everything — because of the non-SSL case...

While it's possibly increasingly common to expect that serious developers
will go and buy an SSL cert, that may not be the case for the wider array of
hobbyist types. Now, that's not to say that they are the only audience that
needs to be addressed, but the idea was to make it harder for them to screw
up if they leaked their API calls... Clearly it turned out that the signing
bit intended to prevent against such attacks itself was too hard to
implement, and so now we're having these conversations again.

At least now we have more data about what the market will bear now.

Anyway, that's my recollection. But it might also not be exactly the
explanation for what you're looking for.

Chris

On Sun, Nov 8, 2009 at 11:48 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> For example, I don't find most cookie-based session systems reasonably
> secure without SSL/TLS. Being able to sit at a coffee shop with free wifi
> and a laptop and steal sessions cookies, then access people's email for the
> duration the cookie is valid isn't reasonable or secure.
>
> If you would like to try this approach, I would suggest adding next to each
> option the list of common attacks still possible under those terms. It will
> allow us to evaluate the added security each level of complexity brings.
>
> EHL
>

-- 
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com
Diso Project: http://diso-project.org
OpenID Foundation: http://openid.net

This email is:   [ ] shareable    [X] ask first   [ ] private

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Nov 2009 17:12:40 +0900

<hat type='individual'/>

On 11/9/09 5:00 PM, Chris Messina wrote:

> While it's possibly increasingly common to expect that serious
> developers will go and buy an SSL cert, that may not be the case for the
> wider array of hobbyist types.

CA-issued domain certificates do not necessarily cost money, so even
"hobbyist types" and others can obtain such certificates. Ping me
offlist if you want examples.

Peter

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 9 Nov 2009 01:26:09 -0700

We are not likely to provide less security than currently offered by the 1.0a specification (on the authentication side). While I welcome this discussion, my focus is to enable the two edge cases: "full" security (as currently offered by the OAuth HMAC method) and "transport layer" security (as currently offered by the PLAINTEXT method). I am confident that we can significantly simplify the HMAC-based solution. It is already much simpler in my working draft (which I will focus on next, right after my batch of discovery specs is out this week).

EHL

From: Chris Messina [mailto:[email-masked]]
Sent: Monday, November 09, 2009 12:00 AM
To: Eran Hammer-Lahav
Cc: Brian Eaton; [email-masked]
Subject: Re: [OAUTH-WG] why are we signing?

Indeed, in the beginning of OAuth, that was one of the primary drivers that lead us to the decision to sign everything - because of the non-SSL case...

While it's possibly increasingly common to expect that serious developers will go and buy an SSL cert, that may not be the case for the wider array of hobbyist types. Now, that's not to say that they are the only audience that needs to be addressed, but the idea was to make it harder for them to screw up if they leaked their API calls... Clearly it turned out that the signing bit intended to prevent against such attacks itself was too hard to implement, and so now we're having these conversations again.

Anyway, that's my recollection. But it might also not be exactly the explanation for what you're looking for.

Chris
On Sun, Nov 8, 2009 at 11:48 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
The problem is, we are not likely to ever reach consensus on 'reasonable security'.

EHL

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of Brian Eaton
> To: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

--
Chris Messina
Open Web Advocate

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 9 Nov 2009 18:00:57 +0900

Hi Chris, 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Chris Messina
Sent: 09 November, 2009 17:00
To: Eran Hammer-Lahav
Cc: [email-masked]
Subject: Re: [OAUTH-WG] why are we signing?

Indeed, in the beginning of OAuth, that was one of the primary drivers that
lead us to the decision to sign everything - because of the non-SSL case... 

The OAuth signing mechanism does not sign anything, only certain parts.
Signing everything was consider difficult since the complete data stream may
not be available.  
 
There is also a TLS-PSK variant that would not require you to use
certificates if that is considered to be the problem. 

 I rather believe that the description was difficult to understand (and
hence implementers got it wrong). Once libraries are available then there is
no need for application designers to worry about these issues. 

Ciao
Hannes

Chris

On Sun, Nov 8, 2009 at 11:48 PM, Eran Hammer-Lahav <[email-masked]>
wrote:

The problem is, we are not likely to ever reach consensus on 'reasonable
security'.

EHL

-- 
Chris Messina
Open Web Advocate

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 9 Nov 2009 18:20:22 +0900

Hi Brian, 

There is no doubt that one can sign different parts of the message to show
that you know the key and to bind the token to the request itself.

You can find examples of signing different practices in other protocols. For
example, DKIM allows you to vary the amount of elements being signed (see
h-parameter on page 20 of http://www.ietf.org/rfc/rfc4871.txt). SIP
Identity, http://www.rfc-editor.org/rfc/rfc4474.txt, signs a fixed number of
fields (although more than the current Oauth spec). 

There is most likely no right answer since it depends a bit on the threat
model and the usage scenarios. Here is an example. The signature mechanism
prevents replays of the token. The HTTP case and the SIP/XMPP communication
model are different since with XMPP/SIP there is also the risk that
intermediaries see the token passing by and misuse it. The usage of Oauth
has been suggested also for XMPP (see
http://xmpp.org/extensions/xep-0235.html) and for SIP (see
http://tools.ietf.org/html/draft-beck-oauth-sip-eval-00). 

Ciao
Hannes

>Hey folks -
>
>What are the use cases for cryptography in OAuth?  Why are we 
>signing requests?  And how much of each request do we need to 
>sign in order to be useful?
>
>    Just use bearer tokens.  Use transport layer encryption to 
>keep those bearer tokens from leaking.
>
>2) Signed tokens.
>     Sign as much of the HTTP request as possible, down to the 
>bits of the HTTP entity body.
>
>My guess is we need at least two out of those four choices 
>(one with bearer tokens, a la OAuth 1.0 plaintext) and another 
>with cryptography.  But I'm not sure whether we need to sign 
>entire messages, or if we can get away with something simpler 
>and still have reasonable security.
>
>Cheers,
>Brian

---

From: John Kemp <[email-masked]>
Date: Mon, 9 Nov 2009 09:28:27 -0500

On Nov 9, 2009, at 12:02 AM, Brian Eaton wrote:

[...]

> messages, or if we can get away with something simpler and still have

I agree that bearer tokens are useful.

As for signatures, the question is really all in the subject line. And  
I guess the answers I would come up with, generally-speaking would be:

i) To authenticate the entity doing the signing, by means of the use  
and verification of that entity's key. Such authentication can be a  
basis for authorizing that entity via the presence of the token in the  
message to do whatever is asked for in the request message.
ii) To bind the token and the rest of the message together to ensure  
that the recipient can detect whether the (important parts of the)  
message was tampered with by a third-party.

If we are only interested in i) then signing any piece of the message  
might be sufficient. If we are interested in ii) (or some other  
security property) then we will need to identify which pieces of the  
message we want to provide that, or other, security properties for.

- johnk

---

From: Brian Eaton <[email-masked]>
Date: Mon, 9 Nov 2009 16:27:18 -0800

> The problem is, we are not likely to ever reach consensus on 'reasonable security'.

Agreed, we are going to need a couple of options to cover even the
most vanilla use cases.  I fully expect other people to come up with
more options for their specific use cases.

My goal with this conversation is to identify the vanilla use cases
that would cover most applications.

> For example, I don't find most cookie-based session systems reasonably secure without SSL/TLS.
> Being able to sit at a coffee shop with free wifi and a laptop and steal sessions cookies, then access
> people's email for the duration the cookie is valid isn't reasonable or secure.

OK, so let's consider OAuth-authenticated access to such a service...
does signing requests improve security?

I don't think so.  The user's password is going to be sent in
clear-text when they log in to the service to approve the oauth token.
 And whenever they view a web page on the service their session
cookies are sent in clear text.  The user's data (which is what really
matters in this whole discussion...) is sent in clear text.

AFAICT, using HMAC-SHA1 or RSA-SHA1 in such an environment doesn't
protect users that much.  The service really needs to support https if
they are concerned about that threat model.

Cheers,
Brian

---

From: John Panzer <[email-masked]>
Date: Mon, 9 Nov 2009 16:34:10 -0800

Counter-argument:  The login pages are protected with https, so their
password is protected.  Their session cookies are sent in clear text but are
themselves encrypted and are refreshed every (say) 10 minutes to minimize
exposure from leakage.  The user's data certainly is sent in clear text form
and an attacker can both read it and impersonate the user to send data if
they grab the cookies, at least for 10 minutes.  So I got nothin' there.

(Would bearer token plus a way to securely rotate the token every N minutes
make the OAuth session at least as secure as the above scenario?)

On Mon, Nov 9, 2009 at 4:27 PM, Brian Eaton <[email-masked]> wrote:

> secure without SSL/TLS.

-- 
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 09 Nov 2009 20:15:59 -0500

[...]

Oh no!  This must never happen.  It MUST be that either Kerberos is 
employed to bypass sending of the password altogether, or the password 
is sent over TLS.

Igor

---

From: Dick Hardt <[email-masked]>
Date: Tue, 10 Nov 2009 02:09:26 +0000

On 2009-11-09, at 4:34 PM, John Panzer wrote:

> Counter-argument:  The login pages are protected with https, so  
> their password is protected.

One might then ask why HTTPS is not used for all the other activity if  
it is sensitive. HTTPS is available. Crypto gets cheaper and cheaper  
with Moore's law.

>  Their session cookies are sent in clear text but are themselves  
> encrypted and are refreshed every (say) 10 minutes to minimize  
> exposure from leakage.

A lot of damage could be done in those ten minutes.

> The user's data certainly is sent in clear text form and an attacker  
> can both read it and impersonate the user to send data if they grab  
> the cookies, at least for 10 minutes.  So I got nothin' there.
>
> (Would bearer token plus a way to securely rotate the token every N  
> minutes make the OAuth session at least as secure as the above  
> scenario?)

I think so. :-)

-- Dick

---

From: John Panzer <[email-masked]>
Date: Mon, 9 Nov 2009 18:47:23 -0800

> it is sensitive. HTTPS is available. Crypto gets cheaper and cheaper

It would be interesting to see the price differential (for peak
traffic/worst case scenario you need to provision for).

Imagine that the resource is, say, a 10MB image.

> A lot of damage could be done in those ten minutes.

But much less than can be done if passwords can be collected and used
later when the user is asleep, to access arbitrary services (and
probably unrelated services because everyone is using the same
email-based username and low-security password for everything).

>> minutes make the OAuth session at least as secure as the above

Don't we want that anyway?

---

From: Dick Hardt <[email-masked]>
Date: Tue, 10 Nov 2009 03:11:15 +0000

> traffic/worst case scenario you need to provision for).

That would be interesting.

> Imagine that the resource is, say, a 10MB image.

Setting up the connection is pretty expensive compared to moving data.

> email-based username and low-security password for everything).

Clearly. Point being that lots of damage can happen in ten minutes.  
Take Twitter for an example, I can send LOTS of spam to all your  
followers as direct messages and follow a bunch of people you don't  
want to follow. I have gotten malware spam from other people's Twitter  
accounts.

> Don't we want that anyway?

Yes. Refreshing the Access Token is a recommendation in WRAP.

-- Dick

---

From: John Panzer <[email-masked]>
Date: Mon, 9 Nov 2009 20:18:13 -0800

My $.02 for what it's worth:  #1 is sufficient, if there is a standard
mechanism to also handle access token timeout+renewal, because then
OAuth is at least as secure as existing cookie based mechanisms.

#1 may well be sufficient even without that proviso, assuming TLS is
widely deployable, scalable, and Ben Laurie doesn't blog about more
vulnerabilities next week (kidding!)

(Note that nothing stops someone from doing their own encryption of
user data using some other mechanism, if they really need to do so;
OAuth just wouldn't standardize this.)

---

From: Brian Eaton <[email-masked]>
Date: Mon, 9 Nov 2009 21:58:28 -0800

On Mon, Nov 9, 2009 at 6:28 AM, John Kemp <[email-masked]> wrote:
> If we are only interested in i) [authenticating the entity] then signing any piece of the message might
> be sufficient. If we are interested in ii) [binding the signature to the message] (or some other security property)
> then we will need to identify which pieces of the message we want to provide
> that, or other, security properties for.

OK, let me try to summarize what I've heard on this thread about the
different use-cases for message signing:

- sign the HTTP request
  Used to prevent MITM from replaying token to a different URL.  Also
limits the replay attack window to minutes instead of hours.

- sign various other parts of the message
   DKIM: signs various message headers
   SIP: unspecified, just says "relevant parts of SIP request"
   XMPP: signs from, to, and purpose of message (roughly)
   OpenSocial: signs identity parameters
   Simple Web Tokens: signs identity parameters

XMPP and OpenSocial both needed to invent their own signature base
string logic in order to reuse OAuth, and I strongly suspect that the
SIP folks will need to do the same.

Several of those applications involve legitimate proxies that
legitimately munge certain parts of the message, and are supposed to
leave other parts untouched.

Cheers,
Brian

---

From: Dick Hardt <[email-masked]>
Date: Tue, 10 Nov 2009 17:52:04 +0000

At IIW last week, myself, Biran Eaton from Google and Allen Tom from  
Yahoo! presented what is now called OAuth WRAP

The specs and discussion specific to those documents is at:

	http://groups.google.com/group/oauth-wrap-wg

We plan to submit the document as an I-D next week when I-D submission  
is open again, and for further work to occur in the IETF OAuth WG.

-- Dick

---

From: "Paul C. Bryan" <[email-masked]>
Date: Tue, 10 Nov 2009 10:06:04 -0800

Hi Dick:

Given that WRAP is so different from OAuth (as I know it), other than
the fact that OAuth could be used to negotiate the issuance of a WRAP
refresh token, I'm curious why you chose to associate this with OAuth by
giving it an "OAuth" prefix. It seems to me that it would only create
confusion in this space.

Paul

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Tue, 10 Nov 2009 11:16:25 -0800

and just to make things vaguely more confusing, some of us are working on
the Virtual Worlds Region Agent Protocol (VWRAP) which makes use of OAuth.
so it's possible you might see someone discussing a use case of OAuth
related to VWRAP. please note it's not a typo. there really is a VWRAP.

-cheers
-meadhbh
--
  infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
        http://wiki.secondlife.com/wiki/User:Infinity_Linden

---

From: John Panzer <[email-masked]>
Date: Tue, 10 Nov 2009 11:36:13 -0800

My personal hope is that these can be merged, as they address nearly the
same use cases.  WRAP is described differently from OAuth but my
understanding is that it's possible do do a nearly 1:1 mapping between the
two by picking appropriate options in OAuth and perhaps defining some things
left undefined by the OAuth base spec.
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

---

From: Dick Hardt <[email-masked]>
Date: Tue, 10 Nov 2009 19:46:44 +0000

Good question. Given the positive reception WRAP received at IIW and  
that capabilities in WRAP are expected to come out of the work in the  
IETF OAuth WG, there was consensus from the OAuth community to include  
WRAP as OAuth profiles.

-- Dick

---

From: "Paul C. Bryan" <[email-masked]>
Date: Tue, 10 Nov 2009 11:56:57 -0800

I guess I must admit I'm a bit surprised that the general consensus
would be to merge with/profile WRAP as OAuth, as the deltas between the
two protocols as defined seems quite substantial. Does this mean that
for all intents and purposes I should consider the existing OAuth IETF
drafts to date to be deprecated in favour of WRAP?

Paul

---

From: Dick Hardt <[email-masked]>
Date: Tue, 10 Nov 2009 20:10:46 +0000

Eran has stated that the upcoming drafts will have the capabilities in  
OAuth WRAP. Hopefully the Dpec provides a basis for useful dialog for  
those attending the BoF later this week in Hiroshima.

-- Dick

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 10 Nov 2009 14:16:23 -0700

My 2c:

WRAP was developed out of necessity due to limitations in OAuth and product release schedule. Without going into too much detail about whether a whole new protocol was really necessary, the WRAP authors felt that it was, and that their timeline could not accommodate waiting for the OAUTH WG to accommodate their use cases in the new version of the spec. We now have a new and separate spec in the space.

I have encouraged the authors to submit their spec as input for the WG and to collaborate to make the upcoming WG spec cover their use case. The goal would be to render the separate WRAP spec unnecessary. How they or others would choose to apply this to their implementation is beyond my control or (TBH) interest.

Most of the innovative ideas in WRAP are around the delegation flow (and there are some good ideas in there). I plan to use some of that as the basis for the new delegation spec. On the authentication side, WRAP uses bearer token with no crypto which will be supported by the PLAIN flavor.

As for how to manage community expectations, the OAuth brand, etc.: I was opposed to putting WRAP under the OAuth brand (the entire effort started as "Simple OAuth"). Others felt that pretending WRAP was an OAuth profile (it is not) and naming it as such would be less confusing or less damaging to the OAuth brand (if you call it the same thing, there is no competition). I didn't care enough to (continue) that argument given my view that by the time WRAP will get the wide attention OAuth has, this WG will produce stable drafts of the new OAuth and will make this irrelevant.

EHL

On 11/10/09 11:56 AM, "Paul C. Bryan" <[email-masked]> wrote:

Paul

---

From: "Paul C. Bryan" <[email-masked]>
Date: Tue, 10 Nov 2009 13:40:30 -0800

Hi Eran:

Thanks for your clarification.

It seems to me that without simple guidelines on what's reasonable to be
called "OAuth", anyone can propose a protocol that purports to be
related in some way to OAuth, at the expense of community confusion and
dilution of its meaning. Is there a way to mitigate this kind of
occurrence other than by simply dismissing it as noise?

Paul

On Tue, 2009-11-10 at 14:16 -0700, Eran Hammer-Lahav wrote:
> My 2c:
> 
> WRAP was developed out of necessity due to limitations in OAuth and
> product release schedule. Without going into too much detail about
> whether a whole new protocol was really necessary, the WRAP authors
> felt that it was, and that their timeline could not accommodate
> waiting for the OAUTH WG to accommodate their use cases in the new
> version of the spec. We now have a new and separate spec in the space.
> 
> I have encouraged the authors to submit their spec as input for the WG
> and to collaborate to make the upcoming WG spec cover their use case.
> The goal would be to render the separate WRAP spec unnecessary. How
> they or others would choose to apply this to their implementation is
> beyond my control or (TBH) interest.
> 
> Most of the innovative ideas in WRAP are around the delegation flow
> (and there are some good ideas in there). I plan to use some of that
> as the basis for the new delegation spec. On the authentication side,
> WRAP uses bearer token with no crypto which will be supported by the
> PLAIN flavor.
> 
> As for how to manage community expectations, the OAuth brand, etc.: I
> was opposed to putting WRAP under the OAuth brand (the entire effort
> started as “Simple OAuth”). Others felt that pretending WRAP was an
> OAuth profile (it is not) and naming it as such would be less
> confusing or less damaging to the OAuth brand (if you call it the same
> thing, there is no competition). I didn’t care enough to (continue)
> that argument given my view that by the time WRAP will get the wide
> attention OAuth has, this WG will produce stable drafts of the new
> OAuth and will make this irrelevant.
> 
> EHL
> 
> 
> 
> 
>         > > refresh token, I'm curious why you chose to associate this
>         with 
>         > > OAuth by
>         > >> We plan to submit the document as an I-D next week when
>         I-D 
>         > >> submission

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 10 Nov 2009 14:46:25 -0700

Not really. It is more about who you listen to than who is speaking.

EHL

On 11/10/09 1:40 PM, "Paul C. Bryan" <[email-masked]> wrote:

Hi Eran:

Paul

On Tue, 2009-11-10 at 14:16 -0700, Eran Hammer-Lahav wrote:
> started as "Simple OAuth"). Others felt that pretending WRAP was an
> thing, there is no competition). I didn't care enough to (continue)

---

From: John Panzer <[email-masked]>
Date: Tue, 10 Nov 2009 14:38:30 -0800

To clarify the distinctions between OAuth WRAP and OAuth 1.0a, the OAuth
WRAP doc[1] Appendix C states the following:

"OAuth WRAP    requires        the     Authorization   Server  to
 support HTTPS,  OAuth   1.0A    does    not."

This is an important distinction, though I assume it applies only to the
profile(s) supplied as part of WRAP and not to extension profile(s) that may
be created.  E.g., one could create a fourth profile which did not require
HTTPs -- it just would not be as interoperable as the others, and servers
and clients are not required to support it, but it would be otherwise
compatible with WRAP if I understand correctly.)

"The   Access  Token   in      OAuth   WRAP    is      opaque  to      the
  Client. The     Client  does    not     need    to      perform any
cryptography    except  for     calling HTTPS."

This is also important, but what is the difference between WRAP and OAuth
1.0A PLAINTEXT mode?  They seem to be pretty much identical to me, if there
is a difference it should be called out.

"The   Access  Token   in      OAuth   WRAP    can     contain authorization
  information,    or      claims, enabling        the     Protected
Resource        to      determine       the     Client's
 authorization   without querying        any     other   resource."

I don't understand this distinction; this sounds exactly like the OAuth 1.0a
token.  What am I missing?

Best,
John

PS:  Sorry for the munged text, that's what I get when I copy and paste from
the PDF to ASCII, any chance of getting a plain text or HTML version of the
spec?
[1] http://oauth-wrap-wg.googlegroups.com/web/WRAP-v0.9.7.2.pdf

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 12 Nov 2009 06:14:40 +0900

>  support HTTPS,  OAuth   1.0A    does    not."

It's not clear to me that this distinction would force someone to define
or label a new protocol. For instance in XMPP the protocol requires
support for TLS in *implementations*, but leaves the use of TLS by any
one *deployment* up to local service policy.

> profile(s) supplied as part of WRAP and not to extension profile(s) that
> may be created.  E.g., one could create a fourth profile which did not
> require HTTPs -- it just would not be as interoperable as the others,
> and servers and clients are not required to support it, but it would be
> otherwise compatible with WRAP if I understand correctly.)
> 
> "The   Access  Token   in      OAuth   WRAP    is      opaque  to    
>  the     Client. 

Isn't the token always opaque to the client? What semantic information
should we expect a client to clean from an access token?

> The     Client  does    not     need    to      perform
> any     cryptography    except  for     calling HTTPS."

A security review would tell us if that assumption is warranted. And,
again, this seems to be more of a deployment choice (the client and
server require SSL/TLS and therefore feel safe in using PLAINTEXT) than
a protocol change.

> This is also important, but what is the difference between WRAP and
> OAuth 1.0A PLAINTEXT mode?  They seem to be pretty much identical to me,
> if there is a difference it should be called out.

Agreed.

> "The   Access  Token   in      OAuth   WRAP    can     contain
> authorization   information,    or      claims, enabling        the    
> Protected     Resource        to      determine       the     Client's  
> I don't understand this distinction; this sounds exactly like the OAuth
> 1.0a token.  What am I missing?

Yes, this sounds very similar.

/psa

---

From: <[email-masked]>
Date: Thu, 12 Nov 2009 02:49:52 +0100

On Mon, Nov 9, 2009 at 6:28 AM, John Kemp <[email-masked]> wrote:
> be sufficient. If we are interested in ii) [binding the signature to
the message] (or some other security property)

>   SIP: unspecified, just says "relevant parts of SIP request"
Hannes Tschofenig suggested handle SIP messages the way described in RfC
4474 (SIP identity). It lists the parts of a SIP messsage that need to
be protected.

Wolfgang

---

From: Brian Eaton <[email-masked]>
Date: Wed, 11 Nov 2009 17:54:01 -0800

So we've got at least five different use cases for signing requests
with the oauth access token and token secret.

Sweet.

The downside to the use cases is that they all have incompatible
signature base strings.  I'd like to see us come up with something so
that we don't have to reinvent the base string again for every single
use case.

Cheers,
Brian

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 12 Nov 2009 11:25:34 +0900 (JST)

Finally looking at OAuth-WRAP draft, it occurs to me that there is some 
context to the architecture presented there that might help.  Let me say 
that I haven't been involved in the development of WRAP, so might be 
getting this wrong from the point of view of WRAP folks, I apologize if 
so.

The concept of a "security token service" (STS) has been developed and 
promoted as an architecture (or pattern, perhaps) in the community that 
might be variously labelled as WS-Security or WS-* or SOAP-based Web 
Services.  Searching for the phrase will reveal lots of explanatory 
material.  At least in enterprise circles the STS concept has become 
pretty well accepted, even if not so widely deployed.  As a concrete 
WS-based service the STS is accessed via the WS-Trust protocol.  WS-Trust 
conveys security tokens but is intended to be token-neutral, that is, it 
can be profiled to carry many/most/all tokens associated with existing 
security protocols.  A WS-Trust-based STS then (in theory) can translate 
between what a client has and what a resource server needs.  This pattern 
is appealing in large organizations to centralize token issuance in the 
face of many apps with heterogenous security protocol needs.

It is my impression that the discussions that led to WRAP were around the 
observation by some large organizations that they find the STS pattern 
attractive to manage access with partners of all kinds; but that the WS-* 
stack is hard to deploy; and OAuth does something much similar and is much 
easier to deploy.  So they'd like a "RESTized STS" or a "OAuth with an STS 
in it".  That's more or less what I see in this proposal, though I haven't 
read it in detail.

So, eg, statements about "opaque tokens" in WRAP as far as I can tell 
aren't meant to distinguish it from OAuth 1.0 but to reflect the design 
inputs from WS-Trust and STS.

  - RL "Bob"

---

From: Chris Messina <[email-masked]>
Date: Wed, 11 Nov 2009 18:50:41 -0800

On Tue, Nov 10, 2009 at 1:40 PM, Paul C. Bryan <[email-masked]> wrote:

It seems to me that without simple guidelines on what's reasonable to
be called "OAuth", anyone can propose a protocol that purports to be related
in some way to OAuth, at the expense of community confusion and dilution of
its meaning. Is there a way to mitigate this kind of occurrence other than
by simply dismissing it as noise?

Hi Paul,

This is an important point and one that drove the move to rename WRAP to
OAuth WRAP.

Let me explain how this decision was made, with an eye to what it means for
other projects calling themselves "OAuth".

Dick Hardt originally reached out to various members of the OAuth community
in August and explained what he, Brian Eaton, and Allen Tom were working on
(perhaps there were others, but they seem like the core group). At the time,
they called the initiative "Simple OAuth" — "simple" because of its reliance
on HTTPS for handling the crypto. While moving the crypto to SSL simplified
the protocol and removed the need for signing (the biggest problem for
developers implementing OAuth) it created a new burden, which was obtaining
a certificate.

Now, the point was made to me that anyone serious about security will have
to obtain an SSL cert anyway, so that wasn't such a big deal. However, from
the perspective of the individual or independent developer, I felt like this
was a fairly serious change in OAuth, and a challenge to the promise of the
OAuth protocol (namely one protocol for authorization, regardless of the
size of your organization). I want people who run their own WordPress
installs on a shared host to be able to use OAuth just as large providers
like Google and Yahoo do.

I didn't want this new effort to use the name OAuth for exactly the reasons
that you specified. This seemed like a fork of the project and a dilution of
the brand. It also seemed to conflict with Eran's work here at the IETF and
I encouraged Dick to seek a more transparent process to developing the
protocol.

Several weeks went by and progress was made — including the eventual
renaming of the protocol to WRAP. This seemed like a fairly satisfactory
development.

At IIW, Dick presented a joint session with Brian Eaton (Google) on WRAP.
There was considerable interest and many suggestions and improvements were
proposed.

Following the session, I reconsidered my position. My original concern with
WRAP (when it was called "Simple OAuth") was that it would fragment the
efforts of the community. If a new protocol came out calling itself "Simple
OAuth", people would gravitate to it and potentially abandon work on
improving the core spec. Now with WRAP clearly taking cycles from the people
at Yahoo, Google, and Microsoft who would otherwise be working on OAuth
Core, we had a decision to make: refuse them the ability to use the brand or
find a middle ground that might pave the way for similar
implementation-driven projects to find a foothold in the OAuth community.

On top of that, the OAuth community must confront the simplicity and
elegance of Facebook Connect. Although not everyone is paying attention to
Facebook, theirs is a significant enough distraction from standards-based
work that we must keep in mind that OAuth does not exist in a vacuum. From a
competitive perspective, we must constantly work to improve our technology,
and make it easier to adopt the "open" and "universal" solution — to the
point where Facebook could adopt it.

In that light, it's also important to remember where OAuth came from.

The original contributors to OAuth were a small, tight knit group of folks
solving a problem that each of them shared. They looked to the work that had
come before them — for patterns and solutions that had been established by
the Googles, Yahoos, Flickrs, Microsofts, and AOLs of the web. What they
came up with was, unexpectedly, adopted by most of the companies that were
the inspiration for the universal solution.

That said, looking back, OAuth itself was largely developed in semi-secrecy,
with a closed mailing list and a private spec that didn't see the light of
day until months into the process. I know this because I was the one that
made the decision to keep our work private. Whether we like it or not, the
best work doesn't always come from completely transparent processes and so
I'd be a hypocrite if I didn't evaluate WRAP in the same light that lead to
the original success of OAuth.

Now, when it came to deciding what to call WRAP, well... that was more of a
political calculation than a technical one. Dick had done the right thing in
coming to us early and telling us what he was working on. I wish it had
happened on the public list, but that was his decision to make and the fact
of the matter is: they're damned near a 1.0 spec and are now ready for
feedback.

This is a perfectly valid way to develop specs and standards — especially
since they're leading with an implementation. OAuth Core 1.0 captured the
best thinking around del-auth when it was produced — and represented the
beginning of a collaborative conversation about how to move away from
password confetti.

In the time since OAuth was launched, we've seen a multifold increase in the
number of sites that no longer collect user passwords and instead use some
form of the OAuth pattern. From my perspective, that's a massive improvement
over the previous status quo. The OAuth project has raised awareness of the
problem of user authentication credentials being passed to parties that
shouldn't have them, and it's lead to the development of a viable and more
powerful alternative. But that work isn't finished — and when it comes to
deploying this alternative in a widespread way, it turns out that what works
for one kind of developer or provider doesn't work for all of them.

Therefore, I see WRAP as an experimental branch of OAuth — and one that's
closer in spirit, goals, and intention to OAuth than different from it.

The work that Eran is doing now on OAuth 2.0 will invariably have to
consider it — and even he accepts that there are some good ideas built into
it. We also know now that signing is not trivial and is one central element
of OAuth that is inhibiting its adoption, probably more than any other.
Therefore, there is a need to improve the usability of OAuth, and WRAP seems
to be squarely aimed at offering a solution to that problem — while also
offering a more deployable solution for larger, distributed providers.

Given all this, it seemed to me that WRAP was more "in the family of OAuth"
than a distant cousin — or one that should necessarily have to develop its
own, independent community. We're all trying to solve similar and related
problems, and we need cohesion and consistency in the message that we offer
to the world. Forking OAuth at this stage in its development is not, in my
estimation, an option, and is why I changed my mind and decided that WRAP
should be renamed to OAuth WRAP.

Of course it's up to the OAuth WRAP maintainers to make their case and
answer the community's questions and criticisms — but I'd much rather have
them do that within the existing community infrastructure than separately.

If other projects wish to call themselves "OAuth", I hope that they'll have
to run through a similar gauntlet of proving how they relate to this broader
initiative, and how they're improving the overall stack of best practices
and patterns that make up the OAuth technology. Stagnant technology is dead
technology, and I'm happy to see at least a vibrant conversation about what
does and doesn't fit into OAuth.

That was probably more than you wanted to know, but I felt it was worth
explaining the WRAP -> OAuth WRAP lineage.

Chris

> My 2c:
]]>
> version of the spec. We now have a new and separate spec in the space.
]]>
> beyond my control or (TBH) interest.
]]>
> WRAP uses bearer token with no crypto which will be supported by the
]]>
> OAuth and will make this irrelevant.
]]>
> EHL
]]>
]]>
]]>
]]>
> On 11/10/09 11:56 AM, "Paul C. Bryan" <[email-masked]> wrote:
]]>
>         drafts to date to be deprecated in favour of WRAP?
]]>
>         Paul
]]>
>         > >> is open again, and for further work to occur in the IETF
]]>
]]>

-- 
Chris Messina
Open Web Advocate

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 12 Nov 2009 01:09:13 -0700

I don't think it was a good idea to associate WRAP with OAuth (beyond the obvious technical similarities). I also don't think the decision was appropriately made.

WRAP is in no way a profile of OAuth no matter how you look at it - it is a completely separate protocol developed by different people.

WRAP and OAuth are competing protocols and this conflict can only be resolved by a new protocol replacing both. OAuth will need to change to accommodate the use cases driving WRAP's development. While this is certainly my intention, the IETF process does not guarantee that. Meanwhile, at least some of WRAP's three corporate sponsors are going to ship running code using it, and it is actively being promoted as a viable alternative. This is not criticism (at least not in this context), just  a matter of fact.

The IETF WG is going to review and consider the many new (good) ideas contained in WRAP as soon as it is submitted as input into the WG in the form of an I-D. I am grateful to the authors for making it available in this manner. It certainly makes my life easier.

I am hoping that the IETF WG can produce stable implementers drafts soon which will provide developers a better alternative than both OAuth 1.0 and WRAP. The next few months will tell if this move has hurt the OAuth brand and how it will impact what we end up calling the new WG protocol.

All of this is nothing but the usual tension between the needs of corporations to deliver products on their own timeline and the slow speed of standards development, especially for something with a high profile like OAuth. But it would have moved much faster if the energy spent on WRAP was instead invested here.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Messina
Sent: Wednesday, November 11, 2009 6:51 PM
To: Paul C. Bryan
Cc: [email-masked]; [email-masked]; [email-masked]; John Panzer; Dick Hardt; Brian Eaton; Eric Sachs
Subject: [WRAP] Re: [OAUTH-WG] OAuth WRAP

On Tue, Nov 10, 2009 at 1:40 PM, Paul C. Bryan <[email-masked]<mailto:[email-masked]>> wrote:

It seems to me that without simple guidelines on what's reasonable to be called "OAuth", anyone can propose a protocol that purports to be related in some way to OAuth, at the expense of community confusion and dilution of its meaning. Is there a way to mitigate this kind of occurrence other than by simply dismissing it as noise?

Hi Paul,

This is an important point and one that drove the move to rename WRAP to OAuth WRAP.

Let me explain how this decision was made, with an eye to what it means for other projects calling themselves "OAuth".

Dick Hardt originally reached out to various members of the OAuth community in August and explained what he, Brian Eaton, and Allen Tom were working on (perhaps there were others, but they seem like the core group). At the time, they called the initiative "Simple OAuth" - "simple" because of its reliance on HTTPS for handling the crypto. While moving the crypto to SSL simplified the protocol and removed the need for signing (the biggest problem for developers implementing OAuth) it created a new burden, which was obtaining a certificate.

Now, the point was made to me that anyone serious about security will have to obtain an SSL cert anyway, so that wasn't such a big deal. However, from the perspective of the individual or independent developer, I felt like this was a fairly serious change in OAuth, and a challenge to the promise of the OAuth protocol (namely one protocol for authorization, regardless of the size of your organization). I want people who run their own WordPress installs on a shared host to be able to use OAuth just as large providers like Google and Yahoo do.

I didn't want this new effort to use the name OAuth for exactly the reasons that you specified. This seemed like a fork of the project and a dilution of the brand. It also seemed to conflict with Eran's work here at the IETF and I encouraged Dick to seek a more transparent process to developing the protocol.

Several weeks went by and progress was made - including the eventual renaming of the protocol to WRAP. This seemed like a fairly satisfactory development.

At IIW, Dick presented a joint session with Brian Eaton (Google) on WRAP. There was considerable interest and many suggestions and improvements were proposed.

Following the session, I reconsidered my position. My original concern with WRAP (when it was called "Simple OAuth") was that it would fragment the efforts of the community. If a new protocol came out calling itself "Simple OAuth", people would gravitate to it and potentially abandon work on improving the core spec. Now with WRAP clearly taking cycles from the people at Yahoo, Google, and Microsoft who would otherwise be working on OAuth Core, we had a decision to make: refuse them the ability to use the brand or find a middle ground that might pave the way for similar implementation-driven projects to find a foothold in the OAuth community.

On top of that, the OAuth community must confront the simplicity and elegance of Facebook Connect. Although not everyone is paying attention to Facebook, theirs is a significant enough distraction from standards-based work that we must keep in mind that OAuth does not exist in a vacuum. From a competitive perspective, we must constantly work to improve our technology, and make it easier to adopt the "open" and "universal" solution - to the point where Facebook could adopt it.

The original contributors to OAuth were a small, tight knit group of folks solving a problem that each of them shared. They looked to the work that had come before them - for patterns and solutions that had been established by the Googles, Yahoos, Flickrs, Microsofts, and AOLs of the web. What they came up with was, unexpectedly, adopted by most of the companies that were the inspiration for the universal solution.

That said, looking back, OAuth itself was largely developed in semi-secrecy, with a closed mailing list and a private spec that didn't see the light of day until months into the process. I know this because I was the one that made the decision to keep our work private. Whether we like it or not, the best work doesn't always come from completely transparent processes and so I'd be a hypocrite if I didn't evaluate WRAP in the same light that lead to the original success of OAuth.

Now, when it came to deciding what to call WRAP, well... that was more of a political calculation than a technical one. Dick had done the right thing in coming to us early and telling us what he was working on. I wish it had happened on the public list, but that was his decision to make and the fact of the matter is: they're damned near a 1.0 spec and are now ready for feedback.

This is a perfectly valid way to develop specs and standards - especially since they're leading with an implementation. OAuth Core 1.0 captured the best thinking around del-auth when it was produced - and represented the beginning of a collaborative conversation about how to move away from password confetti.

In the time since OAuth was launched, we've seen a multifold increase in the number of sites that no longer collect user passwords and instead use some form of the OAuth pattern. From my perspective, that's a massive improvement over the previous status quo. The OAuth project has raised awareness of the problem of user authentication credentials being passed to parties that shouldn't have them, and it's lead to the development of a viable and more powerful alternative. But that work isn't finished - and when it comes to deploying this alternative in a widespread way, it turns out that what works for one kind of developer or provider doesn't work for all of them.

Therefore, I see WRAP as an experimental branch of OAuth - and one that's closer in spirit, goals, and intention to OAuth than different from it.

The work that Eran is doing now on OAuth 2.0 will invariably have to consider it - and even he accepts that there are some good ideas built into it. We also know now that signing is not trivial and is one central element of OAuth that is inhibiting its adoption, probably more than any other. Therefore, there is a need to improve the usability of OAuth, and WRAP seems to be squarely aimed at offering a solution to that problem - while also offering a more deployable solution for larger, distributed providers.

Given all this, it seemed to me that WRAP was more "in the family of OAuth" than a distant cousin - or one that should necessarily have to develop its own, independent community. We're all trying to solve similar and related problems, and we need cohesion and consistency in the message that we offer to the world. Forking OAuth at this stage in its development is not, in my estimation, an option, and is why I changed my mind and decided that WRAP should be renamed to OAuth WRAP.

Of course it's up to the OAuth WRAP maintainers to make their case and answer the community's questions and criticisms - but I'd much rather have them do that within the existing community infrastructure than separately.

If other projects wish to call themselves "OAuth", I hope that they'll have to run through a similar gauntlet of proving how they relate to this broader initiative, and how they're improving the overall stack of best practices and patterns that make up the OAuth technology. Stagnant technology is dead technology, and I'm happy to see at least a vibrant conversation about what does and doesn't fit into OAuth.

That was probably more than you wanted to know, but I felt it was worth explaining the WRAP -> OAuth WRAP lineage.

Chris

]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>
]]>

--
Chris Messina
Open Web Advocate

Personal: http://factoryjoe.com<http://factoryjoe.com/>
Follow me on Twitter: http://twitter.com/chrismessina

Citizen Agency: http://citizenagency.com<http://citizenagency.com/>
Diso Project: http://diso-project.org<http://diso-project.org/>
OpenID Foundation: http://openid.net<http://openid.net/>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
To post to this group, send email to [email-masked]
To unsubscribe from this group, send email to [email-masked]
For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en
-~----------~----~----~----~------~----~------~--~---

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 12 Nov 2009 01:17:15 -0700

As a matter of process, I would suggest looking at what the 1.0 HMAC-SHA1 method signs, and discuss if it is where we should be. We are working with an existing draft and should structure our discussions as feedback to that point of reference. This doesn't limit the conclusion in any way, and is how this WG has been chartered.

EHL

> Sent: Wednesday, November 11, 2009 5:54 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: John Panzer <[email-masked]>
Date: Thu, 12 Nov 2009 07:45:40 -0800

I think that https plus bearer token is sufficient for 90% of use
cases.  I haven't heard a first principles argument otherwise.  If for
no other reason than the record, could the proponents of signing
explain why bearer token over TLS will not meet their needs?

---

From: Brian Eaton <[email-masked]>
Date: Thu, 12 Nov 2009 08:12:03 -0800

> in it".  That's more or less what I see in this proposal, though I haven't

Pretty close.  I'd add that the notion of having a highly secured
credential issuing service and less trusted application servers is a
pretty old one.  It's baked into most trusted third-party
authentication protocols, older ones like kerberos, and newer ones
like SAML.

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 13 Nov 2009 00:18:06 -0700

Are you suggesting using TLS for every protected resource or just for obtaining the token and refreshing it?

OAuth today already supports this via the PLAINTEXT method (though not very cleanly with all the other parameters still required even if useless).

Also What use cases? And where is this 90% comes from?

I for one have always rejected the argument that since cookies are already so broken, there was little point in trying to make API security better. When we originally worked on OAuth we explicitly looked to prevent replay attacks as well as intercepting and changing an authenticated request. We limited our scope to protecting the request URI and (some) parameters. That provided sufficient protection to the APIs people had in mind at the time which were mostly GET/POST requests with just a few parameters. The body hash extension then extended the usefulness of the protocol to other payloads.

The delegation half of the protocol deals with exchanging passwords with tokens. Those who find bearer token sufficient without any additional crypto can simply focus their attention on that. On the authentication side, I would like to offer something other than "use TLS for everything" or risk attacks for ("only") 10 minutes.

EHL

> From: John Panzer [mailto:[email-masked]]
> Sent: Thursday, November 12, 2009 7:46 AM
> To: Eran Hammer-Lahav
> Cc: [email-masked]
> > As a matter of process, I would suggest looking at what the 1.0 HMAC-
> SHA1 method signs, and discuss if it is where we should be. We are
> working with an existing draft and should structure our discussions as
> feedback to that point of reference. This doesn't limit the conclusion
> in any way, and is how this WG has been chartered.
> >
> > EHL
> >
> >
> >> >> then we will need to identify which pieces of the message we want
> to
> >> > provide
> >> > Hannes Tschofenig suggested handle SIP messages the way described
> in
> >> RfC
> >> > 4474 (SIP identity). It lists the parts of a SIP messsage that
> need
> >> to
> >> > be protected.
> >> >
> >> > Wolfgang
> >> >

---

From: Brian Eaton <[email-masked]>
Date: Fri, 13 Nov 2009 00:01:47 -0800

On Thu, Nov 12, 2009 at 11:18 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> The body hash extension then extended the usefulness of the protocol to other payloads.

Careful how much faith you put in the body hash extension. =)  The
appendix has lots of caveats about how hard it is to deploy in
practice.  I don't expect most service providers to be able to do it.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 13 Nov 2009 09:20:08 -0700

True. But when deployed...

At some point the complexity of the protocol tips over and TLS becomes a lot more attractive for protected resources requests. If you cannot gain easy access to the raw entity-body then you don't really have much other options left other than secure the entire channel.

EHL

> From: Brian Eaton [mailto:[email-masked]]
> Sent: Friday, November 13, 2009 12:02 AM
> To: Eran Hammer-Lahav
> Cc: John Panzer; [email-masked]

---

From: John Panzer <[email-masked]>
Date: Fri, 13 Nov 2009 08:37:00 -0800

The 90% is just MHO.

I think we should be sure that using TLS for everything is unviable in
2010 before diving into complicated signing and binding.  For my use
cases, non body signed requests are about equivalent to bearer token
in terms of security; body signing is an interop pain point; absent a
deus ex machina with a new, secure, simple, ip-free, interoperable
algorithm for body signing I would personally use PLAINTEXT over TLS
for resource access and move on to more important things.

Note that nothing stops someone from defining a data protocol which
supplies signatures and even binds to the important bits of the
envelope.  And if you can get XML Dsig to work interoperably for your
protocol, great!  But OAuth 2 could be defined to leave that to
protocols and extensions.  In theory this would make things less
interoperable, but in practice signatures are a huge interop pain
point anyway (IMHO) so I do not believe there is a practical
difference in the field.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 13 Nov 2009 10:21:43 -0700

> Sent: Friday, November 13, 2009 8:37 AM
> To: Eran Hammer-Lahav
> Cc: [email-masked]

That's half of what we are explicitly chartered to do. My point is that people should focus on the parts of the protocol they care about. I think such a reduction in functionality and scope would require a more explicit reconsideration of this entire WG.

I for one, see great value in offering some form of crypto-based security for cases where TLS is not suitable.

I am also not buying the argument that we should avoid crypto because it is hard. The same argument can be made about TLS (who really writes their own libraries for that?).

EHL

> > OAuth today already supports this via the PLAINTEXT method (though
> not very cleanly with all the other parameters still required even if
> useless).
> >
> > I for one have always rejected the argument that since cookies are
> already so broken, there was little point in trying to make API
> security better. When we originally worked on OAuth we explicitly
> looked to prevent replay attacks as well as intercepting and changing
> an authenticated request. We limited our scope to protecting the
> request URI and (some) parameters. That provided sufficient protection
> to the APIs people had in mind at the time which were mostly GET/POST
> requests with just a few parameters. The body hash extension then
> extended the usefulness of the protocol to other payloads.
> >
> > The delegation half of the protocol deals with exchanging passwords
> with tokens. Those who find bearer token sufficient without any
> additional crypto can simply focus their attention on that. On the
> authentication side, I would like to offer something other than "use
> TLS for everything" or risk attacks for ("only") 10 minutes.
> >
> > EHL
> >
> >> On Thursday, November 12, 2009, Eran Hammer-Lahav
> <[email-masked]>
> >> wrote:
> >> >> signature base strings.  I'd like to see us come up with
> something
> >> so
> >> >> >> If we are only interested in i) [authenticating the entity]
> then
> >> >> > signing any piece of the message might
> >> >> >> be sufficient. If we are interested in ii) [binding the
> signature
> >> to
> >> >> >> OK, let me try to summarize what I've heard on this thread
> about
> >> the
> >> >> >>   Used to prevent MITM from replaying token to a different
> URL.
> >> >>  Also

---

From: John Panzer <[email-masked]>
Date: Fri, 13 Nov 2009 09:33:34 -0800

I agree 100% with Eran below :)

To frame the discussion:  There's clearly a complexity scale here.  At some
point along this complexity scale, you get both better security and
interoperability by simply switching to TLS.  I think everybody agrees there
is such a tipping point somewhere along the spectrum; there's just spirited
discussion about where it lies.

There's another issue of course:  We're trying to optimize two variables,
complexity and security, at once.  This means you need to map a 2d problem
to a 1d scalar, which means making choices, which means spirited discussion.
 Here are two meta-points:

1. You can add security with additional checks, restrictions, and
signatures.  You can never remove complexity once it's mandated.

2. Too much complexity is insecure!  Both because people don't get it right,
and because it hinders adoption of our more secure approach over the much
easier status quo of sharing username and password with every web app on the
Internet.

On Fri, Nov 13, 2009 at 8:20 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> At some point the complexity of the protocol tips over and TLS becomes a
> lot more attractive for protected resources requests. If you cannot gain
> easy access to the raw entity-body then you don't really have much other
> options left other than secure the entire channel.
>
> EHL
>

---

From: John Panzer <[email-masked]>
Date: Fri, 13 Nov 2009 09:47:34 -0800

Replies inline (sorry for async postings):

On Fri, Nov 13, 2009 at 9:21 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> That's half of what we are explicitly chartered to do. My point is that
> people should focus on the parts of the protocol they care about. I think
> such a reduction in functionality and scope would require a more explicit
> reconsideration of this entire WG.
>

If the WG needs to consider it, then I move that we do the first, PLAINTEXT,
relying-on-TLS-when-necessary half (at least to the point of an I-D that
people can go implement) before moving on to the far more complex world of
new signature algorithms.

This doesn't mean having two specs, just stabilizing the bits nobody has
serious arguments about so people who need the first half can move forward.
 Obviously things can change in draft, etc., but we're all playing the odds
here and actual running code is important to have.

> I am also not buying the argument that we should avoid crypto because it is
> hard. The same argument can be made about TLS (who really writes their own
> libraries for that?).
>

Nobody; we get them from Ben Laurie.  But they're already available
everywhere, so nobody has to write them, while the OAuth 2 libraries,
whatever they will be, are available nowhere right now.  So whatever OAuth
comes up with has to be _significantly_ simpler and easier than using
openssl.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 13 Nov 2009 13:25:45 -0700

While my approach is slightly different (one of the very few benefits of being the editor), it is what the plan is. The authentication spec is going to offer two methods: Plain (bearer token with optional shared secret), and HMAC (a significantly simplified signature flow based on the HMAC one in 1.0 but with less flexibility for limited platforms). Instead of sacrificing security I have been trying to make the case we should just raise the bar for what an OAuth client should be able to do. Both will accomplish simplicity but at different costs. The Plain method will give the bearer-token+TLS crown everything they need out of that spec.

The delegation spec is where most of the work is needed, and where I would like to see us adopt much of the new and improved ideas from WRAP.

EHL

From: John Panzer [mailto:[email-masked]]
Sent: Friday, November 13, 2009 9:48 AM
To: Eran Hammer-Lahav
Cc: [email-masked]
Subject: Re: [OAUTH-WG] why are we signing?

Replies inline (sorry for async postings):
On Fri, Nov 13, 2009 at 9:21 AM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:

> From: John Panzer [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>

If the WG needs to consider it, then I move that we do the first, PLAINTEXT, relying-on-TLS-when-necessary half (at least to the point of an I-D that people can go implement) before moving on to the far more complex world of new signature algorithms.

This doesn't mean having two specs, just stabilizing the bits nobody has serious arguments about so people who need the first half can move forward.  Obviously things can change in draft, etc., but we're all playing the odds here and actual running code is important to have.

Nobody; we get them from Ben Laurie.  But they're already available everywhere, so nobody has to write them, while the OAuth 2 libraries, whatever they will be, are available nowhere right now.  So whatever OAuth comes up with has to be _significantly_ simpler and easier than using openssl.

EHL

> On Thursday, November 12, 2009, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
> wrote:
> >> From: John Panzer [mailto:[email-masked]<mailto:[email-masked]>]
> >> Cc: [email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]>>
> >> wrote:
> >> >> To: [email-masked]<mailto:[email-masked]>
> >> >> Cc: [email-masked]<mailto:[email-masked]>
> >> >> On Wed, Nov 11, 2009 at 5:49 PM,  <[email-masked]<mailto:[email-masked]>> wrote:
> >> >> >
> >> >> > On Mon, Nov 9, 2009 at 6:28 AM, John Kemp <[email-masked]<mailto:[email-masked]>>
> wrote:
> [email-masked]<mailto:[email-masked]> / abstractioneer.org<http://abstractioneer.org> / @jpanzer

---

From: Dick Hardt <[email-masked]>
Date: Mon, 30 Nov 2009 19:17:45 +0000

> I for one, see great value in offering some form of crypto-based security for cases where TLS is not suitable.

Are these use cases enumerated somewhere?

(Apologies for coming into the conversation late)

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 30 Nov 2009 21:22:31 +0200

I would also like to hear about the cases where TLS is not suitable. 

Hannes 

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Dick Hardt
>Sent: 30 November, 2009 21:18
>To: Eran Hammer-Lahav
>Cc: [email-masked]
>> I for one, see great value in offering some form of 
>crypto-based security for cases where TLS is not suitable.
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 30 Nov 2009 13:27:26 -0700

OAuth is being proposed as a generally useful method for securing API calls. I expect many open source libraries to implement it on the server side and use it for blog plugins, widgets, and other highly distributed software. If OAuth required the use of TLS, it would simply be ignored by all those applications which will likely continue using Basic.

With all due respect to big companies, their resources, and ability to effortlessly deploy SSL/TLS, it is still an expensive and complex process for more developers deploying small scale server components.

EHL

> From: Tschofenig, Hannes (NSN - FI/Espoo)
> [mailto:[email-masked]]
> Sent: Monday, November 30, 2009 11:23 AM
> To: ext Dick Hardt; Eran Hammer-Lahav
> Cc: [email-masked]
> Subject: RE: [OAUTH-WG] why are we signing?
> 
> >Of ext Dick Hardt

---

From: John Panzer <[email-masked]>
Date: Mon, 30 Nov 2009 12:40:49 -0800

A possible path for a TLS-challenged site is to simply send tokens in the
clear. This has security implications of course -- though if you're talking
about server to server calls, it's not nearly as bad as browser side cookies
-- but combined with a way to rotate tokens automatically is still a major
improvement over HTTP Basic.

My question is, how large is the set of possible server implementors that
cannot implement TLS, yet still need security better than the clear-tokens
method above?  Can I suggest that if they comprise less than 10% of usage --
however we want to measure that -- then they could dealt with via extensions
rather than core?

(Note also that if someone is just setting up a test service or a fun
startup, they could start without TLS and upgrade without changing their
code at all, which isn't a horribly bad story -- if you want more security,
you can buy it for a nominal fee.  This has worked pretty well for online
merchants.)

On Mon, Nov 30, 2009 at 12:27 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> OAuth is being proposed as a generally useful method for securing API
> calls. I expect many open source libraries to implement it on the server
> side and use it for blog plugins, widgets, and other highly distributed
> software. If OAuth required the use of TLS, it would simply be ignored by
> all those applications which will likely continue using Basic.
>
> With all due respect to big companies, their resources, and ability to
> effortlessly deploy SSL/TLS, it is still an expensive and complex process
> for more developers deploying small scale server components.
>
> EHL
>

---

From: Mike Malone <[email-masked]>
Date: Mon, 30 Nov 2009 14:32:28 -0800

> Are these use cases enumerated somewhere?

I'm not completely opposed to the TLS route, but since you asked...
off the top of my head, here are a couple drawbacks to using TLS
instead of signing:
  - Bigger burden on developers who need to debug this stuff (i.e.,
you can't sniff your own traffic to debug requests & responses).
  - Properly setting up TLS can be complicated and expensive. For
developers who don't have a lot of ops skills the barrier may be too
high.
  - You can no longer pass around signed URLs as another level of
delegation (a use case that I use regularly for making XHR & POST
requests from the browser). This could be a non-issue if some other
mechanism for fourth-party delegation existed.

If we were coming up with a more secure replacement for browser-based
HTTP basic auth (and looking at Aza Raskin's work with identity in
Firefox, OAuth in the browser doesn't appear to be that far off) would
you want to mandate that all auth'd HTTP traffic use TLS? Not sure if
the answer is yes or no, but I'm guessing many of the
advantages/drawbacks will be the same.

Mike

---

From: Brian Eaton <[email-masked]>
Date: Mon, 30 Nov 2009 16:14:36 -0800

> advantages/drawbacks will be the same.

We should be really cautious about claiming that *anything* we do
replaces TLS.  I've seen at least one academic paper criticizing OAuth
on the basis that OAuth was designed to be secure in the absence of
TLS, yet doesn't actually achieve that goal.

Cheers,
Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 30 Nov 2009 19:10:01 -0700

<hat type='individual'/>

> TLS, yet doesn't actually achieve that goal.

And given that TLS isn't even as secure as we thought it was (cf. the
current issues with a renegotiation attack), we really should be doubly
cautious about security technologies (like OAuth 1.0 signatures) that
have experienced significantly less implementation and deployment than
SSL/TLS (which is one of the few successful security technologies).

Peter

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