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

Dirk Balfanz <balfanz@google.com> Sat, 02 October 2010 03:44 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 830163A6D14 for <oauth@core3.amsl.com>; Fri, 1 Oct 2010 20:44:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.908
X-Spam-Level:
X-Spam-Status: No, score=-104.908 tagged_above=-999 required=5 tests=[AWL=1.068, 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 vw0qvcWQx-MI for <oauth@core3.amsl.com>; Fri, 1 Oct 2010 20:44:10 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 244893A6CF3 for <oauth@ietf.org>; Fri, 1 Oct 2010 20:44:07 -0700 (PDT)
Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o923ivaX028168 for <oauth@ietf.org>; Fri, 1 Oct 2010 20:44:57 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1285991097; bh=Lh51f9ykmfM73Cv8+tW19J1rcMs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=FC30hXseJGpcf75kgxxbcp8UUZu5S6sl8Py/ZQcT8Pr/6tls4T+a79o8bgxW3hG6W e5drglOg/zJnoCl0XGsSw==
Received: from iwn37 (iwn37.prod.google.com [10.241.68.101]) by hpaq5.eem.corp.google.com with ESMTP id o923isAR006455 for <oauth@ietf.org>; Fri, 1 Oct 2010 20:44:55 -0700
Received: by iwn37 with SMTP id 37so5400537iwn.29 for <oauth@ietf.org>; Fri, 01 Oct 2010 20:44:54 -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=soxnWmswWECWg1sodm+Us8ZGI+YP8KI7JHn03Q7dDtE=; b=vRTT7bf7laarvJ5oeNLxHCytg9wX1YJ4tcXE87J6xUx1wU3pftA2lW+ViNE2HhS/2v 44lYJvTOdRDNzkEPZe/A==
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=s+bLDBMgDTQDs9JpfW1Y9IrxUKqXFuCGkJ5jiMrEPYb4MGlALjULOzSXUh/kV+B+dT mBCE8uWSE8nUT5j226cA==
MIME-Version: 1.0
Received: by 10.231.146.212 with SMTP id i20mr6703324ibv.52.1285991094134; Fri, 01 Oct 2010 20:44:54 -0700 (PDT)
Received: by 10.231.130.9 with HTTP; Fri, 1 Oct 2010 20:44:54 -0700 (PDT)
In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C635D37DB@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>
Date: Fri, 01 Oct 2010 20:44:54 -0700
Message-ID: <AANLkTik+StBEhK+40kqWP7qtPGHf8o0byPRdU-KLufuW@mail.gmail.com>
From: Dirk Balfanz <balfanz@google.com>
To: Yaron Goland <yarong@microsoft.com>
Content-Type: multipart/alternative; boundary="0016e6469b0c59a64a04919a2226"
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: Sat, 02 Oct 2010 03:44:16 -0000

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>),
> 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
>
>
>
>
>