Subject: [OAUTH-WG] OAuth 1.0 PLAINTEXT without SSL/TLS

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 8 Jan 2010 19:15:21 -0700

I no longer think there is a valid reason why the OAuth 1.0 specification does not mandate using a secure channel with PLAINTEXT, and I would like to make this change from SHOULD to MUST in the RFC draft [1].

Is there anyone using OAuth PLAINTEXT *not* over TLS/SSL? Is there a *good* reason why the 1.0 specification should not mandate using a secure channel for PLAINTEXT? If someone really wants to use it without, it's a free country but I can't think of any reason.

The only reason not to make the change is if there are existing deployed use cases where PLAINTEXT is used in such a way. If there are none after two years, we should not allow it moving forward.

EHL

[1] http://tools.ietf.org/html/draft-hammer-oauth

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 08 Jan 2010 21:44:35 -0500

I fully support this. I think Zachary has been questioning that 
"should," too, in his recent post.

Furthermore, even if there are implementations that are not using TLS 
(or SSL), I would look at it as an implementation--not 
specification--problem. The specification must not have known security 
holes.

Igor

Eran Hammer-Lahav wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: John Kemp <[email-masked]>
Date: Sat, 9 Jan 2010 07:42:57 -0500

On Jan 8, 2010, at 9:15 PM, Eran Hammer-Lahav wrote:

[...]

>  Is there a *good* reason why the 1.0 specification should not mandate using a secure channel for PLAINTEXT? 

I guess the question is whether you want implementations using other methods to ensure confidentiality and which don't need other security properties (servers on an intranet, for example, firewalled/VPN'd from the general Internet) to become non-conforming?

> The only reason not to make the change is if there are existing deployed use cases where PLAINTEXT is used in such a way.

I would imagine that there are deployments of OAuth in environments where they simply want to use PLAINTEXT for authorization, and have existing methods of dealing with other security properties. 

What is the actual reasoning behind this change? I don't understand why we would suddenly now decide to make some whole class of implementations non-conforming, even if there were only few deployments?

Regards,

- johnk

---

From: Blaine Cook <[email-masked]>
Date: Sat, 9 Jan 2010 13:17:12 +0000

> What is the actual reasoning behind this change? I don't understand why we would suddenly now decide to make some whole class of implementations non-conforming, even if there were only few deployme…

Eran did ask if anyone was using OAuth PLAINTEXT without SSL; that
said, I don't think that it matters if anyone is using PLAINTEXT with
SSL; the spec should outline the basis for interop, and
implementations that want to be interoperable and secure MUST check to
see that SSL is being used for PLAINTEXT (especially server
implementations).

Implementations are always free (as in free country) to have special
flags that disable the security checks and put their OAuth
implementation into non-spec-compliant mode. The same sort of
principle applies to TLS client implementations; the certificate chain
MUST be checked as per the specification, but many clients allow
developers just issue warnings or provide flags to turn off the
warnings that the certificate chain checks are not being performed.
Even though silenced warnings that your TLS connections are insecure
is bad, it's better than the authors of TLS libraries not having to
consider those warnings at all.

b.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 9 Jan 2010 10:12:22 -0700

Hi John,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of John Kemp
> Sent: Saturday, January 09, 2010 4:43 AM

> What is the actual reasoning behind this change? I don't understand why we
> would suddenly now decide to make some whole class of implementations
> non-conforming, even if there were only few deployments?

I have come to the conclusion that arguments against requiring a secure channel during some portions of the protocols are irrelevant. We have been making the case that some environments will not be able to deploy OAuth if SSL/TLS is requires, but we should put that claim under the same practical scrutiny as other requirements we consider. I did a quick survey of existing implementations and every single one uses HTTPS for obtaining tokens and for PLAINTEXT requests.

If someone if going to write internal implementations, they are free to change the protocol as they see fit. In such cases interop is more influenced by the internal nature of the system than the specification. But I can't come up with a single reason why we should allow, by making it a SHOULD, to implement OAuth in such an obviously insecure way (in an IETF RFC).

My argument is that there is little practical difference between sending token secrets in the clear to not validating signatures. Once you open the door for someone to steal secrets, nothing else matters.

My proposed language would be along the lines of "MUST use a secure channel such as TLS/SSL or another mechanism providing the same protections". This allows not using TLS/SSL when the environment provides the same protections some other way.

EHL

---

From: John Panzer <[email-masked]>
Date: Sat, 9 Jan 2010 10:30:56 -0800

> My proposed language would be along the lines of "MUST use a secure channel such as TLS/SSL or another mechanism providing the same protections". This allows not using TLS/SSL when the environment…

(Such as a vpn for example.) +1.

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

---

From: John Kemp <[email-masked]>
Date: Sat, 9 Jan 2010 20:46:48 -0500

Hey Eran!

On Jan 9, 2010, at 12:12 PM, Eran Hammer-Lahav wrote:

[...] (sure, agreed)

> My proposed language would be along the lines of "MUST use a secure channel such as TLS/SSL or another mechanism providing the same protections". This allows not using TLS/SSL when the environment…

Your wording looks good to me.

Cheers,

- johnk

> 
> EHL
> 
> -- 
> You received this message because you are subscribed to the Google Groups "OAuth" 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?hl=en.
> 
>