Subject: Re: [OAUTH-WG] [oauth] #2: No Required Signature Method

From: "oauth issue tracker" <[email-masked]>
Date: Mon, 03 Aug 2009 07:33:42 -0000

#2: No Required Signature Method
---------------------------------+------------------------------------------
 Reporter:  [email-masked]  |        Owner:     
     Type:  defect               |       Status:  new
 Priority:  major                |    Milestone:     
Component:  authentication       |      Version:     
 Severity:  Active WG Document   |   Resolution:     
 Keywords:                       |  
---------------------------------+------------------------------------------

Comment(by [email-masked]):

 Mandatory-to-implement discussions in the IETF have a bad history. Is
 there any reason not to mandate all three? Don't all implementations to
 date already implement all three or is any of the mechanisms in practice
 never implemented?

-- 
Ticket URL: <https://trac.tools.ietf.org/wg/oauth/trac/ticket/2#comment:2>
oauth <http://tools.ietf.org/oauth/>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 3 Aug 2009 14:25:02 -0700

They are not all implemented, and when they are, not consistently. A client cannot assume any of the methods to be supported today.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of oauth issue tracker
> Sent: Monday, August 03, 2009 12:34 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] [oauth] #2: No Required Signature Method
> 
> Ticket URL:
> <https://trac.tools.ietf.org/wg/oauth/trac/ticket/2#comment:2>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 13 Aug 2009 21:57:43 -0600

>  date already implement all three or is any of the mechanisms in practice

Leif, it's not clear to me what you mean by "MTI discussions have a bad
history". The idea behind MTI is that we define a baseline mechanism
that all clients and servers are guaranteed to implement, which will
help to improve interperability. Can you point to examples of MTI
guidelines that have not improved interoperability?

Peter

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

---

From: Leif Johansson <[email-masked]>
Date: Fri, 14 Aug 2009 23:18:27 +0200

> guidelines that have not improved interoperability?

LDAP authentication mechanisms is an example - or HTTP dito for that 
matter!

The problem is that quite often the choice of authentication mechanisms 
mostly hinges on the environment where the protocol is deployed. For
instance LDAP in many "enterprisey" deployments use GSSAPI instead 
sasl plain+tls. GSSAPI isn't MTI for LDAP. Having a mandatory to implement
mechanism for LDAP has neither helped (nor perhaps hindered) LDAP - imho.

In practice an LDAP implementations need to implement *all* mechs in wide 
use today to be useful - GSSAPI (SASL GSSSAPI really), tls+SASL EXTERNAL, 
tls+plain - and a few more.

I'm not saying MTI is bad - I'm just not convinced it helps much in practice.

	Cheers Leif

---

From: Hubert Le Van Gong <[email-masked]>
Date: Mon, 17 Aug 2009 12:30:12 +0200

Another facet of this discussion is whether we should recommend/mandate
other signature methods. Security experts (and I don't claim to be one)
at my company highly recommend we look for stronger algos (any new
protocol should support, at a minimum, HMAC-SHA256 and RSA-SHA256).

Cipher suite agility, i.e. allowing implementations to move on to a newer
cipher suites like SHA3 (when avail.) or ECC, should be considered too.
Of course this will come at the cost of a slight increase in complexity
of the protocol (to express signature capabilities or lack of support for
a specific one for instance).

Hubert

---

From: Blaine Cook <[email-masked]>
Date: Tue, 18 Aug 2009 11:03:18 +0100

> a specific one for instance).

OAuth in its existing form has this capability, specifically in the
oauth_signature_method parameter. I know there was some debate at the
IETF about the naming of that parameter, but the intent is to allow
OAuth to keep up with changes to the crypto landscape without
requiring protocol-level changes.

b.

---

From: Hubert Le Van Gong <[email-masked]>
Date: Tue, 18 Aug 2009 12:33:00 +0200

Agreed, but the Consumer is sort of fishing in the dark since it does not know
whether the Service Provider (SP) , at the time of the request, will
also support
the same method. Moreover we don't have a standard way for the SP to
say "I can't do method X but will accept Y or Z".
We can always defer to the OOB initial introduction or some additional
discovery step to sort things out but it might be better to have some minimal
capability baked in the spec.

Just my 2 cents.

Hubert

---

From: Paul Lindner <[email-masked]>
Date: Tue, 18 Aug 2009 13:23:23 -0700

Adding supported signatures to the OAuth Problem Reporting extension might
be one way to deal with this issue:
http://wiki.oauth.net/ProblemReporting

A response parameter like oauth_acceptable_signatures would suffice.

---

From: Leif Johansson <[email-masked]>
Date: Sat, 22 Aug 2009 00:32:03 +0200

> A response parameter like oauth_acceptable_signatures would suffice.

A negotiation like that might be vulnerable to a downgrade attack - i.e when 
an attacker is able to convince a client to settle for a less secure mechanism 
by modifying the list of mechanisms.

In general the server would have to confirm the list of mechanisms in an 
authenticated message and the client compare the unauthenticated list
to the authenticated list.

	Cheers Leif