Re: [jose] SPI proposal

Hannes Tschofenig <hannes.tschofenig@gmx.net> Sat, 09 February 2013 11:45 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 2FED621F8BAF for <jose@ietfa.amsl.com>; Sat, 9 Feb 2013 03:45:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.411
X-Spam-Level:
X-Spam-Status: No, score=-103.411 tagged_above=-999 required=5 tests=[AWL=1.188, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100]
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 2JmK-h2EFZPd for <jose@ietfa.amsl.com>; Sat, 9 Feb 2013 03:45:15 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2CF21F88E4 for <jose@ietf.org>; Sat, 9 Feb 2013 03:45:13 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.12]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MOmOu-1Ty4Kd11jq-0069O2 for <jose@ietf.org>; Sat, 09 Feb 2013 12:45:13 +0100
Received: (qmail invoked by alias); 09 Feb 2013 11:45:12 -0000
Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.100]) [88.115.219.140] by mail.gmx.net (mp012) with SMTP; 09 Feb 2013 12:45:12 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+b82UdR8ObCz9J7Je4WAD1xVeZmhtXFPr+4Yaex7 gA6SdexNwrIAn6
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
In-Reply-To: <CA+k3eCSgXXit3KbK0XHzbhadyXTOGxvrRBm6ha8XJQhieoY0nQ@mail.gmail.com>
Date: Sat, 9 Feb 2013 13:45:09 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: Brian Campbell <bcampbell@pingidentity.com>
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: Richard Barnes <rlb@ipv.sx>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, "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: Sat, 09 Feb 2013 11:45:16 -0000

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