Subject: Concerns about oauth sasl mechanism

From: Sam Hartman <[email-masked]>
Date: Wed, 11 Aug 2010 14:55:46 -0400

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 12 Aug 2010 15:00:06 -0600

> think it's a good use of this WG's time.

The SAML-OAUTH work that seems to have the most traction in the OAuth WG
is development of methods for using a SAML assertion to get or present
an OAuth token. I agree that using an OAuth token as a way to do SASL
authentication is much less interesting.

> concern in that case as well.

I think that development of SASL mechanisms needs to happen in the
(refactored) KITTEN WG, not in the OAuth WG or anywhere else.

> entirely justify why I didn't raise this objection there. 

Given existing security issues with OpenID as it is usually deployed, I
tend to agree -- although I have heard about deployments under
controlled circumstances (inside enterprises) that have stronger
security properties than the OpenID deployments on the open Internet.

> Roughly, I

Could you clarify which line you're talking about? :)

Peter

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Aug 2010 17:25:50 -0400

The line about whether we should spend kitten's time on it.  I think
having multiple insecure SASL mechanisms under development or even
having a string of insecure sasl mechanisms is not an effective use of
our time.

To be secure, I think a mechanism needs to:

* Not provide an attacker with a weak password equivelent (yapp is out)
* Provide mutual authentication
* Provide channel binding or security layers

I understand we've made exceptions for SAML and OpenID.  Perhaps after
Oauth is done we'll look at its deployment and make a similar exception.

A lot of my reasoning here is that registering a SASL mechanism is easy:
it's first-come, first-serve. So, what are you actually getting out of
spending IETF security area review cycles and IESG cycles if at the end
of the day the result is not actually secure.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2010 16:30:24 -0500

> * Provide channel binding or security layers

+1.

(What's YAPP?)

> of the day the result is not actually secure.

Likely answer: the imprimatur of "RFC", even if it isn't on the
Standards track.

Nico
--

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 Aug 2010 22:37:14 +0100

Hi Sam,

Sam Hartman wrote:
 [...]

>* Provide channel binding or security layers
Agreed.
Can we change the proposed OAuth mechanism to satisfy these requirements?

>of the day the result is not actually secure.
I am a big believer in helping people to avoid damage by designing 
something insecure. So I would rather avoid telling people "go away, we 
are not interested".

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Aug 2010 17:39:33 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Thu, Aug 12, 2010 at 05:25:50PM -0400, Sam Hartman wrote:
    >> * Not provide an attacker with a weak password equivelent (yapp
    >> is out) * Provide mutual authentication * Provide channel binding
    >> or security layers

    Nicolas> +1.

    Nicolas> (What's YAPP?)
What's Kirt's thing called?

    >> I understand we've made exceptions for SAML and OpenID.  Perhaps
    >> after Oauth is done we'll look at its deployment and make a
    >> similar exception.
    >> 
    >> A lot of my reasoning here is that registering a SASL mechanism
    >> is easy: it's first-come, first-serve. So, what are you actually
    >> getting out of spending IETF security area review cycles and IESG
    >> cycles if at the end of the day the result is not actually
    >> secure.

    Nicolas> Likely answer: the imprimatur of "RFC", even if it isn't on
    Nicolas> the Standards track.

There's an rfc-editor independent stream for that.

    Nicolas> Nico --

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Aug 2010 17:44:24 -0400

>>>>> "Alexey" == Alexey Melnikov <[email-masked]> writes:

    Alexey> Hi Sam,
    Alexey> Sam Hartman wrote:
    Alexey> [...]
    Alexey> I am a big believer in helping people to avoid damage by
    Alexey> designing something insecure. So I would rather avoid
    Alexey> telling people "go away, we are not interested".

O, if someone like the OpenID folks or Oauth folks come to us and want
to do the work to make something meet those security requirements, I'm
all for it!  That would be great.  However if after discussing what
someone wants with them, they're unable to design something that is
secure and that meets their needs then our goals are not aligned and we
should get out of each others' way.

If the OAuth proposal has channel bindings/mutual auth or the proponents
want to modify it to do so, then we should absolutely focus on it.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2010 16:49:22 -0500

> What's Kirt's thing called?

Ah, YAP.  It requires channel binding though, and it requires unique
channel bindings.

I like to think of YAP as an optimization of SCRAM that can be used when
you have unique channel bindings.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Aug 2010 18:19:39 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> I like to think of YAP as an optimization of SCRAM that can
    Nicolas> be used when you have unique channel bindings.

I like to think of it as insecure:-)

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 12 Aug 2010 17:21:57 -0500

> I like to think of it as insecure:-)

Well, yes :)  I don't find the one-round-trip saving to be sufficiently
compelling to have the application understand the difference between
unique and non-unique CB, much less to have the initiator implementation
inspect the CB to see that it is nominally unique (which would violate
abstractions)

Nico
--

---

From: "Scott Cantor" <[email-masked]>
Date: Thu, 12 Aug 2010 18:41:37 -0400

> want to modify it to do so, then we should absolutely focus on it.

For the record, possibly repeating myself from an earlier statement, I would
like to modify my SAML proposal, with help, to allow for both.

I don't know how easy that will be or what kinds of modifications of IdPs it
will take, and I think it will be necessary to allow for their absence to
get any progress made in the interim, but I'm not interested in the lowest
bar here, just a migration path. For example, it's likely that part of
introducing such additions will be best accomplished by proposing new SAML
profiles to the OASIS TC so that they are usable outside the context of the
SASL/GSS work.

It probably also bears noting that one of the reasons why I don't care *at
all* about the fact that some IdPs might not support the ECP profile today
is that I think other modifications to IdPs (such as this kind of thing)
will continue to be necessary in the future.

-- Scott

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 13 Aug 2010 14:59:02 +0300

Hi Sam, 

"I haven't followed xyz but here are my comments" is not a good start. 
 
I hear complaints about this and that but then nobody cares about
posting anything to the Oauth mailing list nor to show up at the Oauth
meeting either. Almost nobody at the OAuth face-to-face meeting has read
the specs. 

Having said that I find it a bit strange to require channel bindings.
The funny thing is that I have heard that comment already at one of the
Oauth meetings. Then, I asked what this actually means. The answer was
*I don't know*. So, what should I think about these comments?

I am happy to have a discussion about channel bindings in the context of
Oauth (and of Oauth - SASL in particular) and even about how to re-write
RFC 5056 in a way that it can be understood by humans. Interestingly
enough I tried to figure out what Channel Bindings would provide us with
SASL OpenID (together with my co-authors) and we weren't convinced about
the value!

Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 13 Aug 2010 15:06:14 +0300

Are we standardizing research results or standardizing what industry
does? Please have a look at http://tools.ietf.org/search/rfc5218

I am happy to discuss the security properties of various aspects but
let's pick it one by one and also consider deployability. 

* Mutual authentication: We are talking about a three party protocol
here and so what does mutual authentication actually mean. 

* Channel Binding: Again, a different setup than described in RFC 5056.
Would be nice to know if someone has deployment experience with it. 

* Authentication: Like with many identity management systems the
authentication part is actually outside the scope of these protocols.
This is true for SAML, OpenID, etc. 

Ciao
Hannes

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Alexey Melnikov
> Sent: Friday, August 13, 2010 12:37 AM
> To: Sam Hartman
> Cc: [email-masked]
> Subject: Re: Concerns about oauth sasl mechanism
> 
> Hi Sam,
> 
> Sam Hartman wrote:
>  [...]
> 
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 13 Aug 2010 15:19:25 +0300

Hi Sam, 

> should get out of each others' way.

I have to comment on that. 

I am not going to talk about my impression of what went wrong when some
of the OpenID guys came to the IETF and wanted to do the protocol work
here. Instead, I focus on the Oauth case. 

The Oauth community came to the IETF to do their standardization work
because they hoped they would get really good security advice (and
utilize some of the other protocol experience we have in the IETF). 

Since the formation of the group I tried to involve various groups in
the IETF to provide their review comments. I gave a presentation at the
SECDIR lunch meeting, I volunteered to give a tutorial at the SAAG
meeting (but instead the presentation about MashSSL was favored by the
Ads and I could only put the slides in the proceedings), I posted mails
to various lists and people. At the last IETF meeting Blaine and I gave
an Oauth tutorial on Friday to involve those folks who have not had time
to read the spec. 

With all this I got very little feedback from the IETF security
community. 

The folks in Oauth are not impressed by random statements like "we need
channel bindings" because they want to know "What is it?" and "What are
the benefits?". I think that this is the right attitude. 

Then, these guys implement and deploy. Many folks on security mailing
lists neither implement nor deploy. They just write documents and
complain. That's cheap. 

Working in the Web 2.0 environment they want to get something done soon
(rather than in 5 years). Clearly a different culture. Some of the
design constraints therefore come from this working environment. Here is
an example: You cannot sign the entire HTTP message because the Web
programming language does not provide you with the entire HTTP message.
Another example: You have to work with the same origin policy in a web
browser and hence certain encodings and message flow look at bit funny. 

In a nutshell, those who complain here should sign up at the Oauth list
and do a review. 

Ciao
Hannes

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Aug 2010 10:23:44 -0500

> meeting either. Almost nobody at the OAuth face-to-face meeting has read

We can't help you with that last part!  ;)

> Having said that I find it a bit strange to require channel bindings.

Is that just because you don't know what that means?

> *I don't know*. So, what should I think about these comments?

Well, for one that those OAuth participants haven't "read the specs",
but evidently you knew that (per the above).  If OAuth participants
don't "read the specs" then I am not at all surprised that they don't
know what channel binding means.

> SASL OpenID (together with my co-authors) and we weren't convinced about

I too am happy to have a discussion about channel binding.  And I'll be
happy to entertain a re-write of RFC5056 if you like.  Maybe you could
start with some specific complaints?  But what am I to make of comments
that on the one hand indicate you don't understand X and on the other
state that you believe X is not needed?

Yes, you can avoid channel binding in some cases.

Suppose you are using TLS, with server certs, and you believe that you
have a good enough, trustworthy PKI for the server certs, then you don't
need channel binding in the RFC5056 sense.  In that case you'll happen
to be doing a form of channel binding by using the same (or similar)
service/host ID in TLS and OAuth.  Some of us consider this to be weak
security, and too restrictive; it might be good enough for some users.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 13 Aug 2010 10:29:54 -0500

> here and so what does mutual authentication actually mean. 

"Mutual authentication" is a bit of a term of art.  It can mean either
of two things, as well as both: a) that the two peers "prove" to each
other that they possess the same session keys before proceeding to
exchange sensitive information, b) that the two peers have names that
are authenticated to each other.  (a) comes from Kerberos.  (b) is the
meaning most people would expect.

In general we want both.

> Would be nice to know if someone has deployment experience with it. 

I'm not sure what you're talking about here.

> This is true for SAML, OpenID, etc. 

In the sense that these protocols shouldn't require invasive changes to
deployed authentication infrastructure?  Yes.

Nico
--

---

From: "Scott Cantor" <[email-masked]>
Date: Fri, 13 Aug 2010 13:36:49 -0400

> the benefits?". I think that this is the right attitude.

I don't think everything has to be useful to Google and a random army of
scripters that want to implement everything from scratch in Javascript
though. If you want a standard, it should be rich enough to handle more than
just what they choose to care about.

And before you say "come to the WG and ask", I don't believe the foundation
is right, so I'm not going to try and build my house extension on it. That's
my prerogative.

> (rather than in 5 years).

Here's where that gets you:

http://code.google.com/p/browsersec/wiki/Main

I know some people think that can be reined back in and fixed, but I really
don't.

-- Scott

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Aug 2010 21:09:42 +0300

I have asked my OpenID-SASL co-authors whether I can forward the private 
mail exchange we had about the topic of channel bindings. I hope to be 
able to forward it to the list soon.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Aug 2010 21:26:25 +0300

Hi Nico,

> meaning most people would expect.
I know the definition of mutual authentication. In fact, I prefer the 
one from the Handbook of Applied Cryptography:
http://www.cacr.math.uwaterloo.ca/hac/about/chap10.pdf
"
Entity authentication is the process whereby one party is assured 
(through acquisition
of corroborative evidence) of the identity of a second party involved in 
a protocol,
and that the second has actually participated (i.e., is active at, or 
immediately prior to, the
time the evidence is acquired).
"

Note that for some of the discussions it might be useful to 
differentiate between entity authentication and key confirmation.

"Key confirmation is the property whereby one party is assured that a second
(possibly unidentified) party actually has possession of a particular 
secret key.
"
http://www.cacr.math.uwaterloo.ca/hac/about/chap12.pdf

Anyway, what I meant is that with OpenID-SASL, OAuth-SASL, and with the 
SAML-SASL approach as well we have three parties in the picture, not 
just two. Hence, there is the question between whom authentication 
really happens.

For OpenID-SASL, for example, mutual authentication happens between the 
end host / user and the identity provider, and then there is also 
authentication of the relying party to the end host. Finally, depending 
on the specific profile being used there is also authentication between 
the identity provider and the relying party.

> I'm not sure what you're talking about here.

Do we have some implementation and deployment experience with some of 
the channel binding approaches?

> deployed authentication infrastructure?  Yes.
Some of the protocols it was the intention to leave the authentication 
part between the user and the identity provider outside the scope of the 
standardized protocol. This has certain implication. It allows a variety 
of different authentication infrastructures to be used without the need 
to update the standard in a way that is suitable for the identity 
providers environment. Typically, the user interface experience is 
different between each identity provider and sometimes this is actually 
used for the purpose of branding. On the other hand it makes a security 
analysis more difficult. For the OpenID-SASL design, for example, it 
meant that we had to think about how to integrate this flexible 
authentication approach into the design since we didn't want to change 
the way OpenID works nor to change the deployed OpenID infrastructure 
(by, for example, mandating one specific authentication procedure). It 
also means that we had to deal with different protocol interactions, in 
our case SASL and HTTP-Browser interactions.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Aug 2010 21:35:43 +0300

Hey Scott,

I understand your approach and the thinking behind it.

There are obviously trade-offs and it is hard to find the right balance 
between deployability and security.
In the IETF we had some good examples of "picking up deployed stuff" and 
some examples of where we thought it would be a good idea and then the 
industry decided against it.

I also understand that some of the communities have a somewhat different 
way of working. There are sometimes quite big gaps (in thinking) between 
the different communities. I should know that best given that I had the 
chance to look a bit deeper into the privacy work recently and noticed 
this massive imbalance between the approach people from the research 
community take in comparison with deployment happening on the Internet 
pushed by some Web2.0 companies.

Anyway, we are not going to reach a conclusion on a philosophical level. 
Hence, let us move on and figure out what the channel stuff would get us 
for the protocols in discussion.

Ciao
Hannes

---

From: "Scott Cantor" <[email-masked]>
Date: Sun, 15 Aug 2010 18:53:23 -0400

> for the protocols in discussion.

If you want to see what I think it buys you, you can find that here:

http://www.ietf.org/mail-archive/web/kitten/current/msg01943.html

(Sorry for the line runons, I guess the soft wrapping in my client isn't
friendly to this particular archive.)

I think it fundamentally comes back to whether one thinks commercial SSL is
nonsense or not. I think it is. I know a lot of Web 2.0ers claim it's not.

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 15 Aug 2010 23:17:50 -0500

On Sun, Aug 15, 2010 at 09:26:25PM +0300, Hannes Tschofenig wrote:
> Anyway, what I meant is that with OpenID-SASL, OAuth-SASL, and with
> the SAML-SASL approach as well we have three parties in the picture,
> not just two. Hence, there is the question between whom
> authentication really happens.

The GSS-API concerns itself with just the initiator and acceptor.  These
are typically the client and the server.  Infrastructure services are
not exposed through the API (well, the naming extensions work will
expose them, but that's a different issue).

So, when we say mutual authentication in this context, then, we mean
that the initiator (client) and acceptor (server) both have a _name_,
and that each name is "authenticated" to the other.  A name that's
meaningful to users.  Typically the initator name is the name of a user.
And typically the acceptor name is a host-based service name.

We also want key confirmation.

> For OpenID-SASL, for example, mutual authentication happens between
> the end host / user and the identity provider, and then there is
> also authentication of the relying party to the end host. Finally,
> depending on the specific profile being used there is also
> authentication between the identity provider and the relying party.

You lost me.  What are all the entities here?

 - user
 - IdP
 - service being accessed by the user
 - host hosting the service

(I'd rather stay away from the term "relying party".)

Now, who is authenticated, and to whom?

> Do we have some implementation and deployment experience with some
> of the channel binding approaches?

Microsoft has deployed IWA.  That's, effectively, HTTP/Negotiate, but
with HTTPS (i.e., TLS), and with tls-unique or tls-server-end-point CB.

> Some of the protocols it was the intention to leave the
> authentication part between the user and the identity provider
> outside the scope of the standardized protocol. This has certain
> implication. It allows a variety of different authentication
> infrastructures to be used without the need to update the standard
> in a way that is suitable for the identity providers environment.

This is fine.  See the discussion of Scott Cantor's ECP SAML mechanism.

> Typically, the user interface experience is different between each
> identity provider and sometimes this is actually used for the
> purpose of branding. On the other hand it makes a security analysis
> more difficult.  [...]

Trusted third parties change the security analysis, but don't
necessarily make it more difficult.  Mostly you end up having to explain
that a trusted third party can become a passive or active attacker.

(For example, Kerberos KDCs can recover the plaintext of all
client<->server conversations where the server is in the same realm as
the KDC and the conversations are not further protected.  PKIX CAs can
MITM you.)

In fact, Kerberos is a perfect example.  The Kerberos GSS-API mechanism
doesn't concern itself at all with how the user was pre-authenticated to
the KDC.  The IdP in your OpenID design, like the IdP in Scott Cantor's,
can authenticate users in any way it wants.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 16 Aug 2010 08:57:15 -0400

>>>>> ""Tschofenig," == "Tschofenig, Hannes (NSN <- FI/Espoo)" <[email-masked]>> writes:

    "Tschofenig,> Hi Sam, "I haven't followed xyz but here are my
    "Tschofenig,> comments" is not a good start.

I have followed SASL.  I feel qualified to speak to the SASL working
group about what mechanisms I believe it should standardize.

I think that as someone proposing to add standards-track work to
kitten's charter, you have an obligation to understand the community
you're joining, and to a fairly large extent its previous discussions
especially as they relate to scope, style and the like.

Certainly if I were going to show up at oauth and make a statement about
channel binding there--I'd do a lot better than "You should have channel
binding; I don't know what it is."

My statement is that if this working group is going to standardize a
SASL mechanism it should have channel bindings or security layers.

Your tone has put me off explaining how we got where we are today in
kitten on the list. I have no desire to participate in a list
conversation that has already reached this level of defensiveness.  In
another context, such as a phone call, I'd be happy to try and work
through things with you.  You may find others who will have this
conversation with you on-list.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 16 Aug 2010 09:21:37 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
    Nicolas> then, we mean that the initiator (client) and acceptor
    Nicolas> (server) both have a _name_, and that each name is
    Nicolas> "authenticated" to the other.  A name that's meaningful to
    Nicolas> users.  Typically the initator name is the name of a user.
    Nicolas> And typically the acceptor name is a host-based service
    Nicolas> name.

Hmm.  I'm not sure that's really true.  In particular in scram, I
thought it was more like the client has a name and the server was the
guy who actually had those credentials.  Regardless of whether this is
permissible in GSS-API, SASL's definition of mutual authentication is
permissive enough that you can have mutual authentication if you happen
to share long-term credentials and prove that you have the same
credentials on both sides.

I'm not sure that you can extend this to a multi-party protocol without
introducing naming.

---

From: Klaas Wierenga <[email-masked]>
Date: Mon, 16 Aug 2010 15:28:38 +0200

On 8/16/10 3:21 PM, Sam Hartman wrote:

Sam,

>>>>>> "Nicolas" == Nicolas Williams<[email-masked]>  writes:

me neither, otoh, I am not conviced that we need to extend this to a 
multi-party protocol. So far it seems that we are still talking about an 
initiator and an acceptor only in the SASL-sense. Outside SASL there may 
be tons of stuff going on, with all kinds of either or not mutual 
authentications, but that is here not really relevant, or am I missing 
something?

Klaas

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 16 Aug 2010 09:20:43 -0500

> I'm not sure that you can extend this to a multi-party protocol without

As a matter of fact, we concluded that SCRAM does name the acceptor.
Implementations can lookup passwords in a table indexed by {initiator
name, acceptor name}, or prompt the user for a password for the given
{initiator name, acceptor name}.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 16 Aug 2010 09:41:46 -0500

> > I'm not sure that you can extend this to a multi-party protocol without

I forgot to answer this.

First, in SCRAM we do name the acceptor, but because the acceptor
doesn't have any kind of credentials aside from those shared with the
initiator... the acceptor isn't authenticated as strongly as the
initiator.

Perhaps if we had insisted that the acceptor name be added to the
password salting process, then we could say that the acceptor is
strongly authenticated (as strongly as the initiator anyways).  But
there was a lot of resistance to putting in anything like an acceptor
name, or realm (or domain) in particular.

Now, to extend PSK-like mechanisms to a multi-party protocol...  I don't
see how to do it without adding the acceptor name into the salting
process.  If we do then we definitely have acceptor naming.  If we don't
then you've no idea who an initiator's peer is.

Nico
--