Subject: [OAUTH-WG] "Upgrade" to HTTPS option

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Dec 2009 16:48:03 -0700

How do people feel about the idea of allowing the server to say it is willing to accept a plaintext request (with or without a secret) but only over HTTPS?

This is a bit odd because is conflates the http and https schemes to discuss the same resource regardless of the scheme, but it is how most sites deploy their endpoints.

For example:

A request for http://example.com/resource/1 will yield the following response:

  HTTP/1.1 401 Unauthorized
  WWW-Authenticate: Token realm="http://example.com/", class="oauth", methods="HMAC Plain-S"

Which means OAuth tokens are accepted using the HMAC method, or the Plain method over HTTPS. If the client wishes to use Plain, it must send an authenticated response to https://example.com/resource/1.

Comments?

EHL
PS. You'll notice I am throwing a lot of new ideas to the list for feedback as I am working on my authentication draft. Feel free to bounce your own ideas (thanks James!).

---

From: "Paul C. Bryan" <[email-masked]>
Date: Thu, 03 Dec 2009 15:51:33 -0800

On Thu, 2009-12-03 at 16:48 -0700, Eran Hammer-Lahav wrote:
> How do people feel about the idea of allowing the server to say it is
> willing to accept a plaintext request (with or without a secret) but
> only over HTTPS?
> 
> This is a bit odd because is conflates the http and https schemes to
> discuss the same resource regardless of the scheme, but it is how most
> sites deploy their endpoints.

I think it's wrong for exactly the reason you stated above. The presence
of "-S" means the resource is also exposed at the same hostname, but
implicitly via HTTPS on port 443, with the same URI. This is too much of
a stretch for me.

> Which means OAuth tokens are accepted using the HMAC method, or the
> Plain method over HTTPS. If the client wishes to use Plain, it must
> send an authenticated response to https://example.com/resource/1.
> 
> Comments?
> 
> EHL
> PS. You'll notice I am throwing a lot of new ideas to the list for
> feedback as I am working on my authentication draft. Feel free to
> bounce your own ideas (thanks James!).
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Dec 2009 16:57:29 -0700

What if the HTTPS URI was explicitly provided, not implied by inserting an 's' into the URI? Not sure what's the best way of providing it, but I'm sure we can find a way...

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul C. Bryan
> Sent: Thursday, December 03, 2009 3:52 PM
> To: OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option
> 
> I think it's wrong for exactly the reason you stated above. The presence of "-
> S" means the resource is also exposed at the same hostname, but implicitly
> via HTTPS on port 443, with the same URI. This is too much of a stretch for
> me.
> 
> >
> > For example:
> >

---

From: "Paul C. Bryan" <[email-masked]>
Date: Thu, 03 Dec 2009 16:00:09 -0800

On Thu, 2009-12-03 at 16:57 -0700, Eran Hammer-Lahav wrote:

> What if the HTTPS URI was explicitly provided, not implied by
> inserting an 's' into the URI? Not sure what's the best way of
> providing it, but I'm sure we can find a way...

That's definitely much less of a stretch. :) Perhaps somehow using XRD?

Paul

> > > A request for http://example.com/resource/1 will yield the
> following
> > > response:
> > >
> > >   WWW-Authenticate: Token realm="http://example.com/",
> class="oauth",
> > > methods="HMAC Plain-S"
> > >

---

From: Brian Eaton <[email-masked]>
Date: Thu, 3 Dec 2009 16:06:17 -0800

> This is a bit odd because is conflates the http and https schemes to discuss the same resource regardless of the scheme, but it is how most sites deploy their endpoints.

I'm not wild about this, I don't think it will be necessary in
practice.  Clients are going to know which URL to access.

I'm nervous about trying to do too much with discovery.

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Dec 2009 17:08:39 -0700

I am strongly against using XRD for this level of discovery. Requiring multiple round trips is one of the reasons Digest failed adoption.

EHL

> Sent: Thursday, December 03, 2009 4:00 PM

---

From: John Panzer <[email-masked]>
Date: Thu, 3 Dec 2009 16:16:20 -0800

Why doesn't the server just use this?

http://www.faqs.org/rfcs/rfc2817.html

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

On Thu, Dec 3, 2009 at 4:08 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> I am strongly against using XRD for this level of discovery. Requiring
> multiple round trips is one of the reasons Digest failed adoption.
>
> EHL
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Dec 2009 17:17:11 -0700

At one point the OAuth Discovery draft provided a way to say "I support PLAINTEXT over HTTPS or HMAC-SHA1 over HTTP", but it also provided the OAuth endpoint for each of these. This was limited to the authorization flow and not part of accessing protected resources. I was toying with the idea of making this available right from the WWW-Authenticate header field but it does feel odd.

EHL

> From: Brian Eaton [mailto:[email-masked]]
> Sent: Thursday, December 03, 2009 4:06 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG ([email-masked])
> > How do people feel about the idea of allowing the server to say it is willing
> to accept a plaintext request (with or without a secret) but only over HTTPS?
> >
> > This is a bit odd because is conflates the http and https schemes to discuss
> the same resource regardless of the scheme, but it is how most sites deploy
> their endpoints.
> 
> I'm not wild about this, I don't think it will be necessary in practice.  Clients
> are going to know which URL to access.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Dec 2009 17:18:13 -0700

That's an upgrade of the entire channel. What I am talking about is simply to say, "you want plain text? Sure! But go over there (HTTPS)".

EHL

From: John Panzer [mailto:[email-masked]]
Sent: Thursday, December 03, 2009 4:16 PM
To: Eran Hammer-Lahav
Cc: Paul C. Bryan; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option

--
John Panzer / Google
[email-masked]<mailto:[email-masked]> / abstractioneer.org<http://abstractioneer.org> / @jpanzer

On Thu, Dec 3, 2009 at 4:08 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
I am strongly against using XRD for this level of discovery. Requiring multiple round trips is one of the reasons Digest failed adoption.

EHL

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of Paul C. Bryan
> To: OAuth WG ([email-masked]<mailto:[email-masked]>)
> > > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> > Behalf
> > > Of Paul C. Bryan
> > > To: OAuth WG ([email-masked]<mailto:[email-masked]>)
> > > > [email-masked]<mailto:[email-masked]>
> > > [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

---

From: Breno <[email-masked]>
Date: Thu, 3 Dec 2009 16:23:01 -0800

I tend to agree with John.

I think in most cases, upgrading the channel is the right option if HTTPS is
available.

It might be that some endpoints want to support HMAC via HTTP. Why not
simply indicate HMAC as the only available option at the HTTP endpoint?

On Thu, Dec 3, 2009 at 4:18 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> That’s an upgrade of the entire channel. What I am talking about is simply
> to say, “you want plain text? Sure! But go over there (HTTPS)”.
>
>
>
> EHL
>
>
>
> *From:* John Panzer [mailto:[email-masked]]
> *Sent:* Thursday, December 03, 2009 4:16 PM
> *To:* Eran Hammer-Lahav
> *Cc:* Paul C. Bryan; OAuth WG ([email-masked])
>
> *Subject:* Re: [OAUTH-WG] "Upgrade" to HTTPS option
>
>
>

-- 
Breno de Medeiros

---

From: John Panzer <[email-masked]>
Date: Thu, 3 Dec 2009 16:25:34 -0800

I suppose the difference is that you need to discover this before sending
the plaintext secret in the Authorization: header, otherwise it's kind of
useless.
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

---

From: John Panzer <[email-masked]>
Date: Thu, 3 Dec 2009 16:29:49 -0800

At one point I implemented a system to do a 301 redirect over to an
equivalent https: endpoint if an Authorization:-less request came in for a
protected resource on an http: URI.  The client would then redirect, switch
to SSL, and there would be a regular RFC 2617 Unauthenticated response
followed by a password challenge at the client, followed by a successful
transfer of the base64-encoded password over https.

The loophole here is if the client ever gets it into its head to pass the
secret unprovoked over the unprotected http channel (we never issued an RFC
2617 challenge over the unprotected channel).  But if clients are that
broken there's little one can do to stop them, really.

BTW, the above actually worked with most decent feed readers that supported
HTTP Basic.

On Thu, Dec 3, 2009 at 4:23 PM, Breno <[email-masked]> wrote:

> I think in most cases, upgrading the channel is the right option if HTTPS
> is available.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Dec 2009 17:41:41 -0700

I think it is safe to conclude this idea does not have legs (2, 3, or otherwise).

EHL

From: John Panzer [mailto:[email-masked]]
Sent: Thursday, December 03, 2009 4:30 PM
To: Breno
Cc: Eran Hammer-Lahav; OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option

At one point I implemented a system to do a 301 redirect over to an equivalent https: endpoint if an Authorization:-less request came in for a protected resource on an http: URI.  The client would then redirect, switch to SSL, and there would be a regular RFC 2617 Unauthenticated response followed by a password challenge at the client, followed by a successful transfer of the base64-encoded password over https.

The loophole here is if the client ever gets it into its head to pass the secret unprovoked over the unprotected http channel (we never issued an RFC 2617 challenge over the unprotected channel).  But if clients are that broken there's little one can do to stop them, really.

BTW, the above actually worked with most decent feed readers that supported HTTP Basic.

On Thu, Dec 3, 2009 at 4:23 PM, Breno <[email-masked]<mailto:[email-masked]>> wrote:
I tend to agree with John.

I think in most cases, upgrading the channel is the right option if HTTPS is available.

It might be that some endpoints want to support HMAC via HTTP. Why not simply indicate HMAC as the only available option at the HTTP endpoint?

On Thu, Dec 3, 2009 at 4:18 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
That's an upgrade of the entire channel. What I am talking about is simply to say, "you want plain text? Sure! But go over there (HTTPS)".

EHL

From: John Panzer [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, December 03, 2009 4:16 PM
To: Eran Hammer-Lahav
Cc: Paul C. Bryan; OAuth WG ([email-masked]<mailto:[email-masked]>)

EHL

--
Breno de Medeiros

---

From: "Moore, Jonathan (CIM)" <[email-masked]>
Date: Thu, 3 Dec 2009 20:16:20 -0500

What about sending your 401 but adding a Link header[1] pointing to the HTTPS resource, with a link extension specifying the acceptable methods?

Like:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Token realm="http://example.com/", class="oauth",
  methods="HMAC"
Link: <https://example.com/>; rel="alternate"; oauth-method="Plain"

Jon

[1] http://tools.ietf.org/html/draft-nottingham-http-link-header-03
........
Jon Moore
Comcast Interactive Media

-----Original Message-----
From: [email-masked] on behalf of Eran Hammer-Lahav
Sent: Thu 12/3/2009 7:41 PM
To: John Panzer; Breno
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] "Upgrade" to HTTPS option

EHL

EHL

EHL

--
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Dec 2009 18:24:49 -0700

Yeah...

We can revisit this later. I am playing around with using links for some authorization discovery but not sure if it makes sense yet.

BTW, link draft is at -06 with a -07 coming out shortly.

EHL

> From: Moore, Jonathan (CIM) [mailto:[email-masked]]
> Sent: Thursday, December 03, 2009 5:16 PM
> To: Eran Hammer-Lahav; John Panzer; Breno
> Cc: [email-masked]
> Subject: RE: [OAUTH-WG] "Upgrade" to HTTPS option
> 
> What about sending your 401 but adding a Link header[1] pointing to the
> HTTPS resource, with a link extension specifying the acceptable methods?
> 
> Like:
> 
> protected resource on an http: URI.  The client would then redirect, switch to
> SSL, and there would be a regular RFC 2617 Unauthenticated response
> The loophole here is if the client ever gets it into its head to pass the secret
> unprovoked over the unprotected http channel (we never issued an RFC
> 2617 challenge over the unprotected channel).  But if clients are that broken
> there's little one can do to stop them, really.
> 
> [email-masked]<mailto:[email-masked]> /
> abstractioneer.org<http://abstractioneer.org> / @jpanzer
> 
> 
> On Thu, Dec 3, 2009 at 4:23 PM, Breno
> <[email-masked]<mailto:[email-masked]>>
> wrote:
> On Thu, Dec 3, 2009 at 4:18 PM, Eran Hammer-Lahav
> <[email-masked]<mailto:[email-masked]>> wrote:
> That's an upgrade of the entire channel. What I am talking about is simply to
> say, "you want plain text? Sure! But go over there (HTTPS)".
> 
> EHL
> 
> From: John Panzer
> [mailto:[email-masked]<mailto:[email-masked]>]
> [email-masked]<mailto:[email-masked]> /
> abstractioneer.org<http://abstractioneer.org> / @jpanzer
> 
> On Thu, Dec 3, 2009 at 4:08 PM, Eran Hammer-Lahav
> <[email-masked]<mailto:[email-masked]>> wrote:
> I am strongly against using XRD for this level of discovery. Requiring multiple
> round trips is one of the reasons Digest failed adoption.
> 
> EHL
> 
> > From: [email-masked]<mailto:[email-masked]>
> > [mailto:[email-masked]<mailto:[email-masked]>] On
> > Behalf Of Paul C. Bryan
> > > > From: [email-masked]<mailto:[email-masked]>
> > > > [mailto:[email-masked]<mailto:[email-masked]>] On
> > > Behalf
> > > > Of Paul C. Bryan
> > > > > How do people feel about the idea of allowing the server to say
> > > > > it
> > > is
> > > > > This is a bit odd because is conflates the http and https
> > > > > schemes
> > > to
> > > > > discuss the same resource regardless of the scheme, but it is
> > > > > how
> > > most
> > > > > PS. You'll notice I am throwing a lot of new ideas to the list
> > > > > for feedback as I am working on my authentication draft. Feel
> > > > > free to bounce your own ideas (thanks James!).

---

From: John Panzer <[email-masked]>
Date: Thu, 3 Dec 2009 22:44:37 -0800

Yeah, I'm not recommending it :).  The other reason not to, if you need one,
is that redirects interact particularly badly with libraries, caches,a nd
proxies when you venture beyond GET requests.
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

On Thu, Dec 3, 2009 at 4:41 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> *Sent:* Thursday, December 03, 2009 4:30 PM
> *To:* Breno
> *Cc:* Eran Hammer-Lahav; OAuth WG ([email-masked])
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 8 Dec 2009 18:55:02 -0500

Just to put one more nail in this coffin: This mechanism would offer a  
cute bid-down attack, in which the man-in-the-middle says, "sorry, I  
only support PLAINTEXT, please go to https://evil.com/oauth/".