No matter what algorithm or key size we pick the choice will prove
unsupportable for any number of implementers due to everything from security
issues (no matter what key size we pick, someone will have a real need for
something larger) to legal issues (various countries have their own opinions
about what to use where, a la the NSA suite list).
So we are going to have to support multiple algorithms and we are going to have
to deal with algorithm negotiation. I literally can see no way around that.
Yaron
From: [email protected] [mailto:[email protected]] On Behalf Of
Anthony Nadalin
Sent: Wednesday, September 29, 2010 8:34 AM
To: Dirk Balfanz; Mike Jones
Cc: [email protected]
Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts
> So this one I do feel more strongly about: We should only include crypto
> mechanisms that everybody MUST support. Otherwise, we'll have to invent some
> sort of negotiation step in the protocol: "do you support alg XYZ? No I
> don't, > please use ABC". Let's not do that.
>As just one datapoint, Google would have a hard time supporting ECC, since
>it's not in the Java core library. We don't use bouncycastle.
I agree that there can be license issues that one could encounter with ECC (as
we all did with RSA), there are already customers that require ECC, and so
there is a need to have alternative algorithms that you don't have to support.
We already have the issue of "do you support" with claims and token types, etc
From: [email protected] [mailto:[email protected]] On Behalf Of Dirk
Balfanz
Sent: Tuesday, September 28, 2010 10:23 AM
To: Mike Jones
Cc: [email protected]
Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts
On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones
<[email protected]<mailto:[email protected]>> wrote:
Dirk and I both posted JSON Token drafts on Thursday. They are at
http://balfanz.github.com/jsontoken-spec/draft-balfanz-jsontoken-00.html (which
I'll refer to as Dirk's draft) and
http://self-issued.info/docs/draft-goland-json-web-token-00.html (which I'll
refer to as JWT). This note points out some of the differences (and
commonalities) in the interest of building consensus towards a unified approach.
Commonalities:
* Both have ways of expressing the signature algorithm, token issuer,
token expiration time, and intended audience.
* Both use a form of base64url encoding of the JSON claim data.
* Both require support for the HMAC SHA-256 signature algorithm, and
describe how to sign with RSA SHA-256 as well.
Differences:
* Dirk's draft uses a base64url encoding that may include one or two
'=' pad characters. The JWT draft uses base64url encoding without padding.
* JWT uses shorter claim names in the interest of brevity ("iss",
"exp", and "aud", versus "issuer", "not_after", and "audience").
* JWT also describes how to sign with ECDSA SHA-256, plus HMAC, RSA,
and ECDSA with longer key lengths.
* Dirk's tokens must be signed, whereas signing JWTs is optional.
* Dirk's draft provides for a key_id parameter and a means of
serializing keys.
* Dirk's draft utilizes a Magic Signatures envelope, whereas the only
"envelope" component of a JWT is the encoded signature.
* Dirk's draft proposes that a particular discovery mechanism be used
with JSON tokens.
Let me tackle the differences one at a time, in hopes of driving towards a
consensus position.
Hi there - thanks for writhing this up. Comments below:
* To pad or not to pad: The '=' pad characters add length, are not
URL-safe (and therefore must be escaped when used in URLs, adding more length),
and add no information. Therefore, I would propose that we agree not to use
padding (as permitted by RFC 4648, Section
5<http://tools.ietf.org/html/rfc4648#section-5>), especially since a no-padding
implementation is trivial, as shown in JWT Section
13<http://self-issued.info/docs/draft-goland-json-web-token-00.html#base64urlnotes>.
I don't feel strongly about this, but remember John Panzer's cautionary tales
here: Apparently, padding-less encoding is not well-supported in some
frameworks, which can lead to confusion.
* Claim name length: Given that a core goal of both specs is short
tokens, I would propose that we use the shorter reserved claim names. Having
short tokens is especially important when used with mobile browsers, where URL
length restrictions may be severe. (People are always free to use longer ones
in any particular application context if they have a reason to do so.)
I don't feel strongly about this, but I think many people do want to have more
descriptive names here.
* Elliptic curve crypto and longer key lengths: The JWT spec defines
how to use ECC as well as HMAC and RSA. Given ECC's inclusion in NSA Suite
B<http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml> and that it
has engineering advantages over RSA (shorter key lengths and more efficient
computations), it makes sense that any modern spec incorporating cryptography
allow its use as an option. Likewise, it makes sense for the spec to define
how to use longer key lengths on an optional basis.
So this one I do feel more strongly about: We should only include crypto
mechanisms that everybody MUST support. Otherwise, we'll have to invent some
sort of negotiation step in the protocol: "do you support alg XYZ? No I don't,
please use ABC". Let's not do that.
As just one datapoint, Google would have a hard time supporting ECC, since it's
not in the Java core library. We don't use bouncycastle.
* Unsigned tokens: In some application contexts, it may make sense to
send unsigned tokens if carried in a signed and/or encrypted container or
channel. Allowing for unsigned tokens means that double signing need not occur.
That one just confuses me :-) What's the difference between OAuth without
signatures and unsigned tokens? Is the latter not just a more complicated way
of doing the former?
* Key identification: I agree that having means of identifying and
distributing keys are critical for to end-to-end security of signed tokens.
That's a separate point from whether the key identification and distribution
mechanisms should be part of the token format specification, or treated
separately. I would advocate that it be treated separately (as was done with
SWTs as well), but am open to discussion on this point.
* Discovery: Like key distribution, I believe that an agreement on
discovery mechanisms is critical to many use cases. But like key distribution,
I'd like us to take that up in a separate specification, rather than tightly
binding the use of JSON tokens to a particular discovery mechanism.
Here is where I'm coming from: I find the public-key versions of the signatures
much more intriguing - they allow for easier key management, key rotation, etc.
To actually reap the benefits of key rotation, though, we need to say how to
find out what the currently-used key is. If we don't, then a lot of the
potential advantage of using public keys evaporates. I'm concerned that,
lacking the discovery spec, developers will start hard-coding keys into their
servers, and we'll end up in a situation where we can't rotate keys when
Something Bad happens.
* Envelope structure: Dirk's draft proposes that the signed content be
wrapped in a particular kind of envelope. Among other things, this envelope
can help prevent a token from being repurposed from one context to another, by
having a clear (and cryptographically verified) declaration that "This is a
JSON token". I understand this motivation and am open to discussions on how to
best achieve it, while still providing as little mechanism as possible (but no
less :)).
Well, you've seen my proposal on how to achieve it :-), but I'm also open to
better ways, if someone comes up with one...
Dirk.
Dirk, and others, please jump in!
-- Mike
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
