Subject: [OAUTH-WG] Signature crypto

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 24 Nov 2009 09:56:38 -0700

I think we have consensus that the spec should not mandate a particular hash algorithm. This still leave the issue of assigning algorithms short names for the purpose of negotiation and declaration. Is there a registry available for such algorithms we can use or do we need to create a new one?

EHL

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 24 Nov 2009 16:10:32 -0700

On 11/24/09 9:56 AM, Eran Hammer-Lahav wrote:
> I think we have consensus that the spec should not mandate a
> particular hash algorithm. This still leave the issue of assigning
> algorithms short names for the purpose of negotiation and
> declaration. Is there a registry available for such algorithms we can
> use or do we need to create a new one?

The IANA maintains a registry here:

http://www.iana.org/assignments/hash-function-text-names

Peter

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Nov 2009 13:52:24 +0000

> I think we have consensus that the spec should not mandate a particular hash algorithm. This still leave the issue of assigning algorithms short names for the purpose of negotiation and declaration…

Sorry to have missed out on the thread where that was discussed, but
it'd be odd for an IETF security spec to not mandate some algorithms
and quite likely to generate comments later in the process if there's
no well-defined way to ensure interop. Do we have that?

Ta,
S.

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Wed, 25 Nov 2009 06:18:43 -0800

+1 to stephen's comment.

when it comes to algorithm support and selection, i think the consensus
that's emerged is we should require an algorithm that "looks good" at the
moment the spec is being drafted, but allow the use of other optional
algorithms. ("looks good" here means that there are no known successful
attacks against the math of the algorithm and there's a general consensus
amongst cryptographers that there won't be one in the next 20 years.)

the rationale behind this may have to do with the experience some
implementers had with MOSS / MIME Object Security Services (aka RFC1848.)
MOSS was specified to address issues people had raised with PEM (Privacy
Enhanced Mail). The problem with MOSS is that it was near infinitely
flexible and you could create an implementation that strictly adhered to the
specification, but was non-interoperable if you chose to support a different
set of optional encipherment algorithms.

so the concern here is that if you allow all hash algorithms to be optional,
you'll find some outlier who wants to use HAVAL with Rabin Williams to
generate signatures and will sell this solution into the marketplace, then
go out of business. people who bought the solution won't think anything's
wrong 'til they try to hook it up to someone else who's using a more
traditional SHA256+RSA or ECDSA solution. a great wailing and gnashing of
teeth will follow.

but if we REQUIRE that everyone use SHA256 but allow other hash algorithms,
then we won't have this problem.

-cheers
-meadhbh

--
  infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
        http://wiki.secondlife.com/wiki/User:Infinity_Linden

On Wed, Nov 25, 2009 at 05:52, Stephen Farrell <[email-masked]>wrote:

>
>
> Eran Hammer-Lahav wrote:
> > I think we have consensus that the spec should not mandate a particular
> hash algorithm. This still leave the issue of assigning algorithms short
> names for the purpose of negotiation and declaration. Is there a registry
> available for such algorithms we can use or do we need to create a new one?
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Hubert Le Van Gong <[email-masked]>
Date: Wed, 25 Nov 2009 15:28:46 +0100

+1
A mandatory support will surely help interoperability. If we also have
the negotiation piece
of protocol we had discussed before then we should be fine on that end
of things.

Hubert

---

From: "Vrancken Bart bv" <[email-masked]>
Date: Wed, 25 Nov 2009 16:49:25 +0100

+1
Interoperability is the most important part for a spec like this. Require that everyone uses 1 specific algorithm and allow other algorithms.

Bart

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hubert Le Van Gong
Sent: woensdag 25 november 2009 15:29
To: Infinity Linden (Meadhbh Hamrick)
Cc: OAuth WG ([email-masked])
Subject: Re: [OAUTH-WG] Signature crypto

+1

Hubert

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 25 Nov 2009 18:19:45 +0200

This case is interesting. 
 
Until recently I have also thought that one has to specify a
mandatory-to-implement algorithm in a security protocol since otherwise
interoperability would really suffer. When working in KEYPROV I learned
through Russ Housley that this is actually not true. 

He said:
"
Some specifications in the security area do not pick a mandatory to
implement algorithm.  RFC 5280 is one example.  Instead the companion
specifications tell what algorithm is appropriate for a particular
environment. 
"
 
There are a few reasons why you often cannot agree on a specific
algorithm. Examples are different usage scenarios that demand a certain
algorithm, certain software packages that may or may not support certain
algorithms at a specific point in time, different performance/hardware
requirements, IPR concerns, etc.
 
In any case it is likely that the chosen algorithm will get replaced in
a few years from now and one does not want to update the specification
every time. Hence, having some form of crypto-agility is generally a
good idea since you might want to negotiate a set of algorithms anyway
and it is quite likely that an algorithm is found that both parties
support. 
 
Ciao
Hannes

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Infinity Linden (Meadhbh Hamrick)
	Sent: 25 November, 2009 16:19
	To: Stephen Farrell
	Cc: OAuth WG ([email-masked])
	Subject: Re: [OAUTH-WG] Signature crypto

	+1 to stephen's comment. 

	when it comes to algorithm support and selection, i think the
consensus that's emerged is we should require an algorithm that "looks
good" at the moment the spec is being drafted, but allow the use of
other optional algorithms. ("looks good" here means that there are no
known successful attacks against the math of the algorithm and there's a
general consensus amongst cryptographers that there won't be one in the
next 20 years.)

	the rationale behind this may have to do with the experience
some implementers had with MOSS / MIME Object Security Services (aka
RFC1848.) MOSS was specified to address issues people had raised with
PEM (Privacy Enhanced Mail). The problem with MOSS is that it was near
infinitely flexible and you could create an implementation that strictly
adhered to the specification, but was non-interoperable if you chose to
support a different set of optional encipherment algorithms.

	so the concern here is that if you allow all hash algorithms to
be optional, you'll find some outlier who wants to use HAVAL with Rabin
Williams to generate signatures and will sell this solution into the
marketplace, then go out of business. people who bought the solution
won't think anything's wrong 'til they try to hook it up to someone else
who's using a more traditional SHA256+RSA or ECDSA solution. a great
wailing and gnashing of teeth will follow.

	but if we REQUIRE that everyone use SHA256 but allow other hash
algorithms, then we won't have this problem.

	-cheers
	-meadhbh

	--
	  infinity linden (aka meadhbh hamrick)  *  it's pronounced
"maeve"
	        http://wiki.secondlife.com/wiki/User:Infinity_Linden

	On Wed, Nov 25, 2009 at 05:52, Stephen Farrell
<[email-masked]> wrote:

		Eran Hammer-Lahav wrote:
		> I think we have consensus that the spec should not
mandate a particular hash algorithm. This still leave the issue of
assigning algorithms short names for the purpose of negotiation and
declaration. Is there a registry available for such algorithms we can
use or do we need to create a new one?

		Sorry to have missed out on the thread where that was
discussed, but
		it'd be odd for an IETF security spec to not mandate
some algorithms
		and quite likely to generate comments later in the
process if there's
		no well-defined way to ensure interop. Do we have that?
		
		Ta,
		S.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 25 Nov 2009 09:19:40 -0700

Mandating a baseline is still something we don't have consensus on. What I meant is that we agreed to allow crypto negotiation and therefore need a way to manage the algorithm names somehow. Looks like the IANA registry mentioned is the way to go.

EHL

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, November 25, 2009 5:52 AM
> To: Eran Hammer-Lahav
> hash algorithm. This still leave the issue of assigning algorithms short names
> for the purpose of negotiation and declaration. Is there a registry available
> for such algorithms we can use or do we need to create a new one?
> 
> Sorry to have missed out on the thread where that was discussed, but it'd be
> odd for an IETF security spec to not mandate some algorithms and quite likely
> to generate comments later in the process if there's no well-defined way to
> ensure interop. Do we have that?
> 
> Ta,
> S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Nov 2009 16:44:17 +0000

Eran Hammer-Lahav wrote:
> Mandating a baseline is still something we don't have consensus on. 

Personally I reckon that that'll be required in the end.

> What I meant is that we agreed to allow crypto negotiation and
therefore need a way to manage the algorithm names somehow. Looks like
the IANA registry mentioned is the way to go.

Sounds reasonable if all you need to negotiate are hash
algorithm names. Is that the case?

I also note that the update rule for that registry is fairly
strict - it requires a standards track RFC that UPDATEs or
OBSOLETEs RFC3279 so if folks want to use algorithms other
than those already listed, it might make more sense to start
a new registry with a different update rule. I would hope
though that there's no need for hash functions other than
those listed (until the NIST competition is done at least
and I expect that 3279 will be UPDATEd after that).

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Nov 2009 16:56:40 +0000

5280 is a special case since its a profile that gets
referenced by other RFCs so there's always a 2nd RFC
involved there. While one could imagine OAuth having
a separate RFC that just specifies a current algorithm
set, I'm not sure that'd be best...it might, but I'd
suspect not. My reason for that is that I'd expect that
we'd rev. something else in the protocol about as
often as (or more often than) we'd change the mandatory
to implement algorithm. But I guess we'll see.

S.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 25 Nov 2009 10:52:22 -0700

> Sent: Wednesday, November 25, 2009 8:44 AM
> To: Eran Hammer-Lahav
> Sounds reasonable if all you need to negotiate are hash algorithm names. Is
> that the case?

Yes.

> I also note that the update rule for that registry is fairly strict - it requires a
> standards track RFC that UPDATEs or OBSOLETEs RFC3279 so if folks want to
> use algorithms other than those already listed, it might make more sense to
> start a new registry with a different update rule. I would hope though that
> there's no need for hash functions other than those listed (until the NIST
> competition is done at least and I expect that 3279 will be UPDATEd after
> that).
> 
> S.
> 
> 
> 
> >
> > EHL
> >
> >>> particular
> >> hash algorithm. This still leave the issue of assigning algorithms
> >> short names for the purpose of negotiation and declaration. Is there
> >> a registry available for such algorithms we can use or do we need to
> create a new one?
> >>

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Wed, 25 Nov 2009 10:24:05 -0800

selecting a required to implement algorithm is independent of extensibility.
it is always possible to get both.

and yes, you can separate required algorithms from core functionality. so if
RFC XXX0 described OAuth mechanisms, and then RFCXXX1 described SHA1+RSA as
being required while RFCXXX2 described ECDSA as being required, you could
get people talking about supporting "RFCXXX1" or "RFCXXX2" instead of
talking about supporting RFCXXX0.

RTP did a pretty good job of describing core concepts and features in
RFC3550, then added a/v in RFC3551. Secure RTP (or SRTP) was defined in
RFC3771, and mandated a particular set of algorithms. unfortunately, some of
these algorithms were difficult to implement on some handsets. AES, for
instance seemed to eat up a lot of CPU time on some lower end devices. there
was a second scheme that used a lighter-weight algorithm, but i don't think
it ever saw the light of day.

so the moral of the story is that if you don't mandate a required algorithm,
you'll get MOSS.

you _can_ separate the mechanism from the required algorithm, and put the
two in different RFCs. but it doesn't eliminate all risk of
non-interoperability, because as soon as you define your first "profile"
RFC, you're going to find that someone want's to use a second set of
algorithms. experience tends to show that only one of these will be
predominant. at that point, people lose interest in the non-predominant
profile and back the one which is perceived to have more external support.
so at this point the only thing that separating the algorithms out buys you
is you get to defer selection of the "required" algorithm spec.

RFC5280 is probably okay with not specifying a required algorithm because
SHA1+RSA is a de facto standard in this community because Verisign dominated
the industry for so long and only supported SHA1+RSA and *shudder* MD5+RSA.

this doesn't affect organizations that do like using commercial CA's (like
the federal bridge CA) because they already have large organizations (like
NIST, AMX, etc.) describing a collection of acceptable algorithms. in those
communities, vendors generally don't talk about RFC5280 compatibility, but
rather "suitability for use with the federal bridge" or "suitability for use
with the automotive information exchange."

OAuth does _not_ have a pre-existing group which mandates algorithms. thus,
i think that NOT requiring an algorithm somewhere will lead to a bit of
confusion amongst people wishing to implement the spec.

still, it's not like the sky's falling. but i would offer the predictions:

a. if we don't have a required algorithm somewhere, you will find that OAuth
users will select whatever algorithm set they like. many times, they will
choose algorithms that other people don't use. when they start to want to
interoperate with these people, there will be a mild gnashing of teeth as
the two parties make a pairwise agreement over which algorithm they'll use.
it's not the end of the world, but this sort of pairwise algorithm
negotiation will occur all over the place.

b. if you put required algorithms in a second RFC, distinct from the draft
defining OAuth mechanisms, you will quickly see someone write an additional
draft with a new set of required algorithms. you'll then have a mild amount
of confusion over which one should be supported, possibly ending when
everyone decides to support both. in this case, you might as well have
defined both as being REQUIRED.

c. if chaos looms for longer than it takes for a FLOSS developer to
reasonably apply support to PHP, Python/WSGI and Java, then you'll see
whatever algorithm choice that developer makes become the de facto standard
(because it's available everywhere.) if we're unlucky, that developer will
make their algorithm choice based on the 1996 edition of Applied Crypto
which does not have suitable exhortations for developers to eschew MD5.

so... it's probably less about it being absolutely necessary to select a
required algorithm for the spec, and more about what kind of chaos can we
live with?

-cheers
-meadhbh

---

From: John Kemp <[email-masked]>
Date: Wed, 25 Nov 2009 14:01:04 -0500

Infinity Linden (Meadhbh Hamrick) wrote:

[...]

> 
> so the moral of the story is that if you don't mandate a required 
> algorithm, you'll get MOSS.

And is that, in practice, a problem for anyone?

[...]

> a. if we don't have a required algorithm somewhere, you will find that 
> OAuth users will select whatever algorithm set they like. many times, 
> they will choose algorithms that other people don't use. when they start 
> to want to interoperate with these people, there will be a mild gnashing 
> of teeth as the two parties make a pairwise agreement over which 
> algorithm they'll use. it's not the end of the world, but this sort of 
> pairwise algorithm negotiation will occur all over the place.
> 
> b. if you put required algorithms in a second RFC, distinct from the 
> draft defining OAuth mechanisms, you will quickly see someone write an 
> additional draft with a new set of required algorithms. you'll then have 
> a mild amount of confusion over which one should be supported, possibly 
> ending when everyone decides to support both. in this case, you might as 
> well have defined both as being REQUIRED.
> 
> whatever algorithm choice that developer makes become the de facto 
> standard (because it's available everywhere.) if we're unlucky, that 
> developer will make their algorithm choice based on the 1996 edition of 
> Applied Crypto which does not have suitable exhortations for developers 
> to eschew MD5.
> 
> required algorithm for the spec, and more about what kind of chaos can 
> we live with?

Yes, I'd say that might even be roughly the choice but put it in 
different terms:

What kind of interoperability do we want?

If an implementation is forced to implement a particular hash algorithm 
in order to be "compliant" with the specification when it won't in 
practice use that algorithm, I don't see that as very useful. Either 
implementors will say their implementation is compliant, or they'll say 
that their implementation is not OAuth (or RFCXXXX). How does either of 
those things help anyone?

As Hannes noted, if we require a specific hash algorithm then every time 
we need to change the MTI algorithm(s) we also need to update the 
specification.

In any case, I wouldn't really call it "chaos" just because there are 
multiple OSS implementations. I hope that people will develop tools that 
work for them. And I suspect that the most important parts of OAuth to 
standardize on are a) the protocol itself, b) the HTTP authentication 
mechanism and c) a method of negotiating the relevant twiddly bits, as 
necessary (and where it should be noted that "no signature at all" is 
potentially an acceptable signature algorithm).

- johnk

---

From: Brian Eaton <[email-masked]>
Date: Wed, 25 Nov 2009 11:07:28 -0800

> potentially an acceptable signature algorithm).

Yep.

Whatever signature scheme we specify here is going to be obsolete in a
few years.  The most important thing is that there is a smooth upgrade
path.

Cheers,
Brian

---

From: Ben Laurie <[email-masked]>
Date: Wed, 25 Nov 2009 13:31:02 -0800

> few years.  The most important thing is that there is a smooth upgrade

And no smooth downgrade path :-)

---

From: Breno <[email-masked]>
Date: Wed, 25 Nov 2009 20:30:00 -0800

John Panzer managed that mandated implementation is not the same as mandated
support. We could require all OAuth compliant libraries to include support
for a particular hash algorithm (to facilitate interoperability testing) but
make it clear that no service provider is required to support it.

Without a mandatory implemented algorithm it can be difficult to weed out
bugs by interoperability exercises among different libraries.

On Wed, Nov 25, 2009 at 8:19 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> Mandating a baseline is still something we don't have consensus on. What I
> meant is that we agreed to allow crypto negotiation and therefore need a way
> to manage the algorithm names somehow. Looks like the IANA registry
> mentioned is the way to go.
>
> EHL
>
> names

-- 
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Wed, 25 Nov 2009 20:30:59 -0800

I meant 'John Panzer suggested' rather than 'John Panzer managed'

If I were not in the habit of sending clarification messages I would blame
it on the flu I'm recovering from.

On Wed, Nov 25, 2009 at 8:30 PM, Breno <[email-masked]> wrote:

> John Panzer managed that mandated implementation is not the same as
> mandated support. We could require all OAuth compliant libraries to include
> support for a particular hash algorithm (to facilitate interoperability
> testing) but make it clear that no service provider is required to support
> it.
>
>> it'd be

-- 
Breno de Medeiros

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 27 Nov 2009 14:42:35 +1100

>> Sounds reasonable if all you need to negotiate are hash algorithm names.
>> Is that the case?

> Yes.

Not quite.
OAuth (at least the authentication part) mainly needs a MAC algorithm, not a hash algorithm.
HMAC is one popular MAC algorithm that is build from a hash algorithm.
However, there are other MAC algorithms — based on block ciphers for instance (eg CMAC-AES).
The hash registry http://www.iana.org/assignments/hash-function-text-names/ is not really going to help.

P.S. The body-signing OAuth extension is the one place that uses a hash (not a MAC) directly.

James Manger