So what's the proposal, then? That OAuth service providers document what crypto mechanisms they support? And developers will just have to know which alg to use with which service provider? I guess I could live with that...
Dirk. On Mon, Oct 4, 2010 at 12:37 AM, Anthony Nadalin <tony...@microsoft.com>wrote: > I don’t believe that negotiation (policy) has to be part of this > proposal, so in the spec if one of the claims is not supported then the > token MUST not be processed. We have this today in the web services security > stack and there are really no issues. > > > > *From:* Dirk Balfanz [mailto:balf...@google.com] > *Sent:* Friday, October 01, 2010 8:45 PM > *To:* Yaron Goland > *Cc:* Anthony Nadalin; Mike Jones; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Comparing the JSON Token drafts > > > > On Fri, Oct 1, 2010 at 3:41 PM, Yaron Goland <yar...@microsoft.com> wrote: > > 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. > > > > I agree that over time, what will be considered secure will change. I also > agree that usually this means that there is some sort of negotiation > happening on what the two parties support. How would that happen here? > Remember that - as one datapoint - Google won't be able to support the ECC > algorithm. What happens when you can't support one of the proposed > algorithms, and there is no provision in the protocol to signal this to > other parties? > > > > Dirk. > > > > > > Yaron > > > > *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Anthony Nadalin > *Sent:* Wednesday, September 29, 2010 8:34 AM > *To:* Dirk Balfanz; Mike Jones > > > *Cc:* oauth@ietf.org > *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:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf > Of *Dirk Balfanz > *Sent:* Tuesday, September 28, 2010 10:23 AM > *To:* Mike Jones > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Comparing the JSON Token drafts > > > > On Mon, Sep 27, 2010 at 5:46 PM, Mike Jones <michael.jo...@microsoft.com> > 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 J). > > 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
