Subject: Re: [kitten] Concerns about oauth sasl mechanism

From: William Mills <[email-masked]>
Date: Thu, 19 Aug 2010 10:00:46 -0700

Hi,

I've included the initial post in the thread below, and this is in response to reading all of the thread I see in the archive.  I'll add the disclaimer that I'm new to the writing of RFCs and I'm likely to make some novice mistakes.  That said....

The initial dracft of the OAuth mechanism spec did not include a security layer because I was both punting to see if anyone objected, and leaning on the OAuth design to provide options for cleartext communication that are still secure (this I realise is a point of conversation still).

My goal is pretty simple, I want to get people to stop storing their password in devices (phones, pdas, etc) and giving their passwords to folks like moble phone providers, and specifically I'm looking at the mail (IMAP/POP/SMTP) space.  A side effect of this is that passwords stop flowing in the clear to mail services that choose not to use TLS.

In the space I'm focussing on transport security is TLS if it's implemented.  Channel binding to TLS (I am in the camp that thinks TLS is not perfect but it's good enough, even in light of the fact that almost no one checks revocations) seems reasonable, BUT I think there are a bunch of places out there where an OAuth mechanims in SASL is still a win that will not have TLS in place, and I think that means I don't want to require TLS.  I can be argued off this point perhaps, and driving people to use TLS would be a good thing too.  This focus is not necessailry the right solution for the general case.  Is channel binding the right strategy here?

A security layer is certainly a possibility, but I did not know where to start on making that part of the initial draft and I wanted to get something out there to get working on the things that are more well defined for me.

Another question is: OAuth itself (in it's current form) allows for either a bearer token (password substitute which may expire) or signed requests, and relys on the implementor to choose the crrect security model for their application.  My presumption was that a SASL mechanism should not change the protocol being tunneled too much.  What's the right strategy for a successful and implementable spec here?

Thanks,

-bill

________________________________

*	To: kitten at ietf.org <mailto:[email-masked]> 
*	Subject: Concerns about oauth sasl mechanism
*	From: Sam Hartman <hartmans-ietf at mit.edu <mailto:[email-masked]> >
*	Date: Wed, 11 Aug 2010 14:55:46 -0400
*	Delivered-to: kitten at core3.amsl.com <mailto:[email-masked]> 
*	List-archive: <http://www.ietf.org/mail-archive/web/kitten>
*	List-help: <mailto:[email-masked]?subject=help>
*	List-id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
*	List-post: <mailto:[email-masked]>
*	List-subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:[email-masked]?subject=subscribe>
*	List-unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:[email-masked]?subject=unsubscribe>
*	User-agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)

________________________________

I'll admit that I'm a bit concerned about the never of SASL/GSS
mechanisms we're creating that have no better security than cram-md5 and
may have somewhat less.

I don't think we need any more SASL mechanisms that provide neither
security layers nor channel binding.  I haven't followed the OAuth
standards in a while. If they currently have something that can be used
for channel binding or if they gain such a facility, I think
standardizing such a mechanism here would be great.  Otherwise, I don't
think it's a good use of this WG's time.

Obviously, nothing stops proponents of such a mechanism of registering
it or even getting an non-IETF RFC.  I guess nothing even stops them
from trying to recharter OAuth, although I would bring up the same
concern in that case as well.

I understand that a similar argument can be made about the SAML and
OpenID mechanism. First, I have some hope for the SAML mechanism.  I'll
admit that I'm quite conflicted on the OpenID mechanism and that I can't
entirely justify why I didn't raise this objection there. Roughly, I
think that's very close to the line and this is over the line.

--Sam

________________________________

*	Follow-Ups: 

	*	RE: Concerns about oauth sasl mechanism <http://www.ietf.org/mail-archive/web/kitten/current/msg01935.html>  

		*	From: Tschofenig, Hannes (NSN - FI/Espoo)

		*	Re: Concerns about oauth sasl mechanism <http://www.ietf.org/mail-archive/web/kitten/current/msg01920.html>  

		*	From: Peter Saint-Andre

*	Prev by Date: Feedback solicited for Privacy and Identity Management Terminology <http://www.ietf.org/mail-archive/web/kitten/current/msg01918.html>  
*	Next by Date: Re: Concerns about oauth sasl mechanism <http://www.ietf.org/mail-archive/web/kitten/current/msg01920.html>  
*	Previous by thread: Feedback solicited for Privacy and Identity Management Terminology <http://www.ietf.org/mail-archive/web/kitten/current/msg01918.html>  
*	Next by thread: Re: Concerns about oauth sasl mechanism <http://www.ietf.org/mail-archive/web/kitten/current/msg01920.html>  
*	Index(es): 

	*	Date <http://www.ietf.org/mail-archive/web/kitten/current/maillist.html#01919> 
	*	Thread <http://www.ietf.org/mail-archive/web/kitten/current/threads.html#01919> 

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Aug 2010 12:44:59 -0500

On Thu, Aug 19, 2010 at 10:00:46AM -0700, William Mills wrote:
> I've included the initial post in the thread below, and this is in
> response to reading all of the thread I see in the archive.  I'll add
> the disclaimer that I'm new to the writing of RFCs and I'm likely to
> make some novice mistakes.  That said....
> 
> The initial dracft of the OAuth mechanism spec did not include a
> security layer because I was both punting to see if anyone objected,
> and leaning on the OAuth design to provide options for cleartext
> communication that are still secure (this I realise is a point of
> conversation still).

What do you mean by "options for cleartext communication that are still
secure"?  Integrity protection without confidentiality protection?

There's nothing wrong with an option for integrity protection w/o
confidentiality protection.  But note that we still call that a
"security layer" (in SASL terminology).

> My goal is pretty simple, I want to get people to stop storing their
> password in devices (phones, pdas, etc) and giving their passwords to
> folks like moble phone providers, and specifically I'm looking at the
> mail (IMAP/POP/SMTP) space.  A side effect of this is that passwords
> stop flowing in the clear to mail services that choose not to use TLS.
> 
> In the space I'm focussing on transport security is TLS if it's
> implemented.  Channel binding to TLS (I am in the camp that thinks TLS
> is not perfect but it's good enough, even in light of the fact that
> almost no one checks revocations) seems reasonable, BUT I think there
> are a bunch of places out there where an OAuth mechanims in SASL is
> still a win that will not have TLS in place, and I think that means I
> don't want to require TLS.  I can be argued off this point perhaps,
> and driving people to use TLS would be a good thing too.  This focus
> is not necessailry the right solution for the general case.  Is
> channel binding the right strategy here?

Channel binding by definition requires a secure channel.  The lack of a
secure channel implies that channel binding cannot be done.

You can have the option to not have a secure channel.  But when there is
one, channel binding is a good thing to do.

> A security layer is certainly a possibility, but I did not know where
> to start on making that part of the initial draft and I wanted to get
> something out there to get working on the things that are more well
> defined for me.

The SASL community has effectively decided that security layers are
obsolete, that instead of security layers applications should do channel
binding to TLS.

(This happened in the context of the SCRAM mechanism.  SCRAM does not
provide security layers.  It provides channel binding instead.  There
was a lengthy thread about this that concluded with consensus that
security layers were undesirable.)

> Another question is: OAuth itself (in it's current form) allows for
> either a bearer token (password substitute which may expire) or signed
> requests, and relys on the implementor to choose the crrect security
> model for their application.  My presumption was that a SASL mechanism
> should not change the protocol being tunneled too much.  What's the
> right strategy for a successful and implementable spec here?

I'd need to know more to answer this.  But my gut feeling is that you'd
want to base the SASL mechanism on the signed request/reply profile.

Does OAuth provide for mutual authentication?  I.e., can the server's
name (and service name) be authenticated to the client by the user's
OpenID provider?

Nico
--

---

From: William Mills <[email-masked]>
Date: Thu, 19 Aug 2010 13:19:53 -0500

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Thursday, August 19, 2010 10:45 AM
> To: William Mills
> Cc: [email-masked]
> Subject: Re: [kitten] Concerns about oauth sasl mechanism
> 
> What do you mean by "options for cleartext communication that 
> are still secure"?  Integrity protection without 
> confidentiality protection?

Yes, the tokens are cryptographically signed, or the signed exchange is signed with a shared secret.

> 
> There's nothing wrong with an option for integrity protection 
> w/o confidentiality protection.  But note that we still call 
> that a "security layer" (in SASL terminology).
> 

So in the initial draft we're leaning on the integrity protection in OAuth rather than spellign it out in the SASL mechanism.  Does that work, or do we need to pull something in to the mechanism spec?

> Channel binding by definition requires a secure channel.  The 
> lack of a secure channel implies that channel binding cannot be done.
> 
> You can have the option to not have a secure channel.  But 
> when there is one, channel binding is a good thing to do.

We can certainly add that.  Is there a spec we should use as an example to draw from?  

> The SASL community has effectively decided that security 
> layers are obsolete, that instead of security layers 
> applications should do channel binding to TLS.
> 
> (This happened in the context of the SCRAM mechanism.  SCRAM 
> does not provide security layers.  It provides channel 
> binding instead.  There was a lengthy thread about this that 
> concluded with consensus that security layers were undesirable.)
> 
> I'd need to know more to answer this.  But my gut feeling is 
> that you'd want to base the SASL mechanism on the signed 
> request/reply profile.
> 
> Does OAuth provide for mutual authentication?  I.e., can the 
> server's name (and service name) be authenticated to the 
> client by the user's OpenID provider?

No, there is no provision currently for the client to authenticate the server (protected resource is the OAuth term).  The current direction is to have endpoint discovery (via WebFinger for example), but that's not sufficient to call it authentication.  It's a really interesting problem, and my initial thought is that OpenID my be used to verify the server's identity, but that starts to get into a weird hybrid of both OpenID and OAuth.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 19 Aug 2010 13:38:49 -0500

> is signed with a shared secret.

OK.  That is still referred to as a "security layer".

> So in the initial draft we're leaning on the integrity protection in
> OAuth rather than spellign it out in the SASL mechanism.  Does that
> work, or do we need to pull something in to the mechanism spec?

The messages themselves might be defined outside the SASL mechanism
itself; the SASL mechanism specification can make normative references
to other documents.

> We can certainly add that.  Is there a spec we should use as an

SCRAM [RFC5802] is probably a good example.

> No, there is no provision currently for the client to authenticate the
> server (protected resource is the OAuth term).  The current direction
> is to have endpoint discovery (via WebFinger for example), but that's
> not sufficient to call it authentication.  It's a really interesting
> problem, and my initial thought is that OpenID my be used to verify
> the server's identity, but that starts to get into a weird hybrid of
> both OpenID and OAuth.

You will need to have host naming and authentication in your mechanism.
This is practically unavoidable given the way that GSS-API and SASL are
used in Internet protocols.  A combination of mechanisms is certainly
not out of the question.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Aug 2010 21:44:14 +0200 (MEST)

William Mills wrote:
> password in devices (phones, pdas, etc) and giving their passwords
> to folks like moble phone providers, and specifically I'm looking
> at the mail (IMAP/POP/SMTP) space.  A side effect of this is that
> passwords stop flowing in the clear to mail services that choose
> not to use TLS.

You must be kidding.  Sharing your passwords for a personal service
with some other organization than that which provides that particular
service is unconditionally a bad idea.

If there are currently providers that do not offer TLS-protected
logons, they must be explicitly UNsupported.  Let market pressure
force them to offer password-based authentication over encrypted
communication links.

Why would you want to put potentially millions of user credentials
in jeopardy if there's at most a few hundred service providers which
should be exterminated anyway if they show so little little respect
for the security and privacy of their own users.

-Martin