Re: [OAUTH-WG] Comparing the JSON Token drafts

Dirk Balfanz <balfanz@google.com> Thu, 07 October 2010 16:33 UTC

Return-Path: <balfanz@google.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E89A3A7253 for <oauth@core3.amsl.com>; Thu, 7 Oct 2010 09:33:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.027
X-Spam-Level:
X-Spam-Status: No, score=-105.027 tagged_above=-999 required=5 tests=[AWL=0.949, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfCmemUsqrae for <oauth@core3.amsl.com>; Thu, 7 Oct 2010 09:33:48 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 329873A6C24 for <oauth@ietf.org>; Thu, 7 Oct 2010 09:33:44 -0700 (PDT)
Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id o97GYgx2009032 for <oauth@ietf.org>; Thu, 7 Oct 2010 09:34:42 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1286469282; bh=p99o2tOOxvfllfpmc9zdLVK5ubE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Hl12yGKI2wytjFowXPREH0y4bvyvIxqmnEZFCjpu39c7kMDGVesXBg1MHQKnMO5VE 4+U7z3rLutJ0W/ahylbYg==
Received: from iwn41 (iwn41.prod.google.com [10.241.68.105]) by wpaz24.hot.corp.google.com with ESMTP id o97GYe7d005867 for <oauth@ietf.org>; Thu, 7 Oct 2010 09:34:40 -0700
Received: by iwn41 with SMTP id 41so39488iwn.15 for <oauth@ietf.org>; Thu, 07 Oct 2010 09:34:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=VI83oAo4ZlkwjzsQ9ejCIyipEI01AR8P+r06ljzlBrc=; b=Gf1fzSycSeZab4+Vhr1DglpXEQa/nBJD7kKtqquKWV0KErnlybmFUMKG307rQhWm0l vBoswjupQ95yM+3/FRbA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=geIwiKC3XHPk2ox9DaJC6ZY6Vfj3RPRYlZz8u685BRnegDcRus2pWompKA8KOuFthJ RKmlFqLvVe4MTqK5LGIA==
MIME-Version: 1.0
Received: by 10.231.15.203 with SMTP id l11mr1066811iba.182.1286469278521; Thu, 07 Oct 2010 09:34:38 -0700 (PDT)
Received: by 10.231.36.133 with HTTP; Thu, 7 Oct 2010 09:34:38 -0700 (PDT)
In-Reply-To: <180155C5EA10854997314CA5E063D18F093C69@TK5EX14MBXC113.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B168042967394314AA9AF0@TK5EX14MBXC207.redmond.corp.microsoft.com> <AANLkTimokq-36Xt2hjrD1+Htj74d0L9jubg_c8=4sOXk@mail.gmail.com> <1990A18DEA6E97429CFD1B4D2C5DA7E70D4009@TK5EX14MBXC101.redmond.corp.microsoft.com> <7C01E631FF4B654FA1E783F1C0265F8C635D37DB@TK5EX14MBXC113.redmond.corp.microsoft.com> <AANLkTik+StBEhK+40kqWP7qtPGHf8o0byPRdU-KLufuW@mail.gmail.com> <1990A18DEA6E97429CFD1B4D2C5DA7E70D88DA@TK5EX14MBXC101.redmond.corp.microsoft.com> <AANLkTinkQag3_xmHevY5wTNXaympZcX8W7mMFB-0ns0V@mail.gmail.com> <180155C5EA10854997314CA5E063D18F093C69@TK5EX14MBXC113.redmond.corp.microsoft.com>
Date: Thu, 7 Oct 2010 09:34:38 -0700
Message-ID: <AANLkTi=mkh5=GDJcbSsHnNqxLHygUF=PfOk2V07GOo6W@mail.gmail.com>
From: Dirk Balfanz <balfanz@google.com>
To: Anthony Nadalin <tonynad@microsoft.com>
Content-Type: multipart/alternative; boundary=002215046c8f5c6202049209781c
X-System-Of-Record: true
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Comparing the JSON Token drafts
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Oct 2010 16:33:53 -0000

Ok, so in the spirit of convergence, I give you (optional) ECC - do you give
me Magic Signature Compact Serialization? :-)

Dirk.

On Thu, Oct 7, 2010 at 12:18 AM, Anthony Nadalin <tonynad@microsoft.com>wrote;wrote:

>  I think that this would be the baseline and if there is interest in some
> sort of negotiation protocol then could take that up at  a later time, I
> know its not the best but we need to be able to support the government
> endorsed algorithms
>
>
>
> *From:* Dirk Balfanz [mailto:balfanz@google.com]
> *Sent:* Wednesday, October 06, 2010 2:26 PM
> *To:* Anthony Nadalin
> *Cc:* Yaron Goland; Mike Jones; oauth@ietf.org
>
> *Subject:* Re: [OAUTH-WG] Comparing the JSON Token drafts
>
>
>
> 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 <tonynad@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:balfanz@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 <yarong@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-bounces@ietf.org [mailto:oauth-bounces@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-bounces@ietf.org [mailto:oauth-bounces@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.Jones@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>)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
>
>
>
>
>
>
>
>
>