Re: [jose] SPI proposal

Brian Campbell <bcampbell@pingidentity.com> Mon, 11 February 2013 15:29 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0775321F8A6E for <jose@ietfa.amsl.com>; Mon, 11 Feb 2013 07:29:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[AWL=1.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16t8vrzvciMC for <jose@ietfa.amsl.com>; Mon, 11 Feb 2013 07:29:54 -0800 (PST)
Received: from na3sys009aog130.obsmtp.com (na3sys009aog130.obsmtp.com [74.125.149.143]) by ietfa.amsl.com (Postfix) with ESMTP id A9EF021F8AAD for <jose@ietf.org>; Mon, 11 Feb 2013 07:29:53 -0800 (PST)
Received: from mail-ob0-f200.google.com ([209.85.214.200]) (using TLSv1) by na3sys009aob130.postini.com ([74.125.148.12]) with SMTP ID DSNKURkOcYhn+1C4OcH/WqkeP7zxv/nHux7/@postini.com; Mon, 11 Feb 2013 07:29:53 PST
Received: by mail-ob0-f200.google.com with SMTP id un3so29595824obb.3 for <jose@ietf.org>; Mon, 11 Feb 2013 07:29:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=5oi8B36mi7PQv5my7MN5ETOtwpp9MQptivOpFhL8c9M=; b=ZjhRw3nKhEjzn3d/9SwAFKyXwIKBwSI4ccoBFzKtI47FloAh3sdcgopTbW6jpKmd1t cdv4OZXdpIiDtA2SM5PmjuW7O8je0n6tpd6Np6d5GGWG9Jkr7GUfv65Zbhnza4PtfsKc S9opLFhjIMbMMnhZHhgaHAubq2NJV0dEUJu9603jdjbiW0mFxmcV/tJ4m3sJZ9pdPsPi vqynR88vAh187eAU8hAxcC3l0ZeJzuEYPGZBMtMI6ldyfDijxBkvP9e5TK0cgJ+HCaqy sUoQq36qjssYVBz1SRw9HmsZphrW/okv5MhislkB9voycg/Pf+JUi0Wk17zHN2gYFHqD fb1A==
X-Received: by 10.42.91.209 with SMTP id q17mr17448313icm.50.1360596283753; Mon, 11 Feb 2013 07:24:43 -0800 (PST)
X-Received: by 10.42.91.209 with SMTP id q17mr17448305icm.50.1360596283639; Mon, 11 Feb 2013 07:24:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.139.8 with HTTP; Mon, 11 Feb 2013 07:24:13 -0800 (PST)
In-Reply-To: <DAD30B11-CE37-45A1-B764-C30D91F70390@gmx.net>
References: <CAL02cgSt7w5CrP+DXo7bz_+YsxKsVMoRbZLNWa6EHjnAyScWMg@mail.gmail.com> <CA+k3eCQ_bsTxYq6u5BVe_Xk1ycOhAwWe=ebfAwk+66JavJJQfA@mail.gmail.com> <CAL02cgRvUvf39RyDOStRXZ1Ne6p9gLrAxjtH8kfmdhE4kWG-3w@mail.gmail.com> <CA+k3eCSgXXit3KbK0XHzbhadyXTOGxvrRBm6ha8XJQhieoY0nQ@mail.gmail.com> <DAD30B11-CE37-45A1-B764-C30D91F70390@gmx.net>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 11 Feb 2013 08:24:13 -0700
Message-ID: <CA+k3eCS=8F_zJsDE2ueU0YnNWXg7nwvUhxMbmzhk3oLGRqR2Wg@mail.gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: multipart/alternative; boundary=90e6ba5bbe132b493b04d57482c6
X-Gm-Message-State: ALoCoQlfG5ZwKydmH0a5FkU59rInO6ypHDv2m19TfBAGW74xwdZk7iN+KDJBMXPL0pLhk57XTGQz9hGJf0ohDuGW7xypq4Sq9Lwo/vQgdm2iv9Slw8URmaCGQJ6xqyKePrSyip25yvvd
Cc: Richard Barnes <rlb@ipv.sx>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] SPI proposal
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Feb 2013 15:29:55 -0000

I believe the "kid" Key ID header parameter already meets the need for
named keys.


On Sat, Feb 9, 2013 at 4:45 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net
> wrote:

> Hi Brian,
>
> keys need to have a name.
>
> Whether you call it SPI, key id, or something else does not really matter.
>
> It also does not matter whether the keys (and the associated parameters)
> are established manually, or using some key management.
>
> In the context of OAuth there are actually various keys flying around and
> therefore they need to have different names.
> I was referring to the key used between the client and the resource server
> when used with
>
> I believe even without Richard's proposal the necessary pieces are already
> in the current document; what is need is to further clarify them.
> Ciao
> Hannes
>
> On Feb 8, 2013, at 4:21 PM, Brian Campbell wrote:
>
> > Seems to me that, in the absence of more advanced management, the use of
> spi is potentially very very fragile. And that, in many cases, such
> advanced management would be a lot more trouble than it's worth. But maybe
> I'm missing the bigger picture.
> >
> > My own applications of JOSE are in OpenID and OAuth (and similar) and
> the JOSE message is generally sent from one entity to another thought a web
> browser user agent as an intermediary. That situation doesn't lend itself
> well to use of spi or even easily creating some management protocol around
> it.
> >
> > WRT collision and scoping to sender, I had the same thought but there's
> not, AFAIK, a reliable way to identify the sender. No?
> >
> > Anyway, I get the point of just establishing the basic behavior. But I'd
> like to be careful not to inadvertently impose a lot of complexity or
> potential operational or security issues when doing so.
> >
> >
> >
> >
> >
> >
> > On Thu, Feb 7, 2013 at 7:52 AM, Richard Barnes <rlb@ipv.sx> wrote:
> > The motivation here is not very deep.  A lot of the current design
> (e.g., the three-letter names) is focused on reducing header size.  The SPI
> proposal further compresses header size in cases where two entities will be
> exchanging many JOSE objects.  I understood from some discussions with
> OpenID folks that this was often the case for their use cases.
> >
> > Obviously, you could build a whole management protocol around this stuff
> (cf. IKE for IPsec).  Whatever application is using this would need to
> figure out how to deal with the issues you note, as well as things like
> what happens when an object shows up with an unknown SPI.  (I don't think
> collision is an issue, if you can scope to sender; the sender just ensures
> uniqueness.)  The idea of this basic proposal is to establish the basic
> behavior, around which you could then wrap more advanced management.
> >
> > --Richard
> >
> >
> > On Thu, Feb 7, 2013 at 9:42 AM, Brian Campbell <
> bcampbell@pingidentity.com> wrote:
> > Admittedly I'm not really up on this spi issue or the motivation behind
> it but a couple questions came to mind when I saw this. How does the
> receiver protect against unbounded growth of the cache? And index
> collision? And for distributed environments, it seems supporting this could
> be very cumbersome.
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Feb 6, 2013 at 3:11 PM, Richard Barnes <rlb@ipv.sx> wrote:
> > To move us toward closing Issue #9 [9], here is some proposed text for
> an SPI [1] field.  To recall, SPI stands for "security parameters index",
> borrowing a term from IPsec.  The idea is that in cases where the same
> crypto parameters are being used repeatedly, this would save the parties
> from having to re-send the same parameters.
> >
> > The below text is designed for the JWE spec, but could be adapted for
> JWS (just keep header, ignore part about key/iv).  Similar text is probably
> needed for the encryption/decryption/signing/verification sections.
> >
> > Feedback welcome,
> > --Richard
> >
> > -----BEGIN-----
> > Section 4.1.X. "spi" Header Parameter
> >
> > The "spi" (Security Parameters Index) header parameter contains an
> opaque byte string that labels a set of security parameters.  This index is
> designed to enable the use of smaller headers in cases where entities will
> be re-using the same security parameters for several messages.
> >
> > Entities supporting the use of the "spi" parameter MUST maintain a table
> of cached security parameters.  When an entity receives an object whose
> header contains both "spi" and "alg" values, then it MUST cache the
> following values from the JWE, indexed by the "spi" value:
> > -- Contents of the JWE header
> > -- Encrypted Key
> > -- Initialization Vector
> >
> > If an object containing an "spi" parameter but no "alg" parameter, then
> it MUST NOT contain an Encrypted Key or Initialization Vector.  That is, it
> will have the form "header.ciphertext.integrity_value".  When a recipient
> receives such an object, it uses the "spi" value to retrieve cached header,
> key, and initialization vector and reconstructs a full JWE.  This full JWE
> can then be further processed according to the normal JWE processing rules.
>  If the recipient has no cached parameters for the "spi" value, the process
> MUST fail.
> > -----END-----
> >
> >
> > [9] http://tools.ietf.org/wg/jose/trac/ticket/9
> >
> > _______________________________________________
> > jose mailing list
> > jose@ietf.org
> > https://www.ietf.org/mailman/listinfo/jose
> >
> >
> >
> >
> > _______________________________________________
> > jose mailing list
> > jose@ietf.org
> > https://www.ietf.org/mailman/listinfo/jose
>
>