Subject: [jose] SPI proposal

From: Richard Barnes <[email-masked]>
Date: Wed, 6 Feb 2013 17:11:50 -0500

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

---

From: Mike Jones <[email-masked]>
Date: Wed, 6 Feb 2013 22:26:31 +0000

Thanks for writing this up, Richard.  I believe that captures the intent fairly well.

As we'd discussed off-list, I believe that it would be more consistent if, in the case were you are using a previously cached "spi" value, that the header contained "alg":"spi" and "spi":spi-value.  That would maintain the invariant that implementations always use the "alg" value to determine what the rest of the structure is - albeit in this case, via an indirection.

Also, then we'd register "spi" like any other "alg" value.  Other algorithms specify the use of particular header parameters.  This one would be no exception.  Registering it as an algorithm would also make it clear that it is up to implementations whether to support it or not.

I don't feel super-strongly about this, but I always try for consistency, where reasonable.  I think that this is such a case.

Again, thanks for the write-up to help move this forward.

                                                            Cheers,
                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Wednesday, February 06, 2013 2:12 PM
To: [email-masked]
Subject: [jose] SPI proposal

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

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.

---

From: Mike Jones <[email-masked]>
Date: Wed, 6 Feb 2013 22:28:19 +0000

BTW, what JSON data type did you intend to be used for the "spi" value?  A JSON string?  A string with any structure, or an unconstrained Unicode string?  A base64url-encoded byte sequence?

                                                            -- Mike

From: Mike Jones
Sent: Wednesday, February 06, 2013 2:27 PM
To: 'Richard Barnes'; [email-masked]
Subject: RE: [jose] SPI proposal

                                                            Cheers,
                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Wednesday, February 06, 2013 2:12 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [jose] SPI proposal

Feedback welcome,
--Richard

---

From: Richard Barnes <[email-masked]>
Date: Wed, 6 Feb 2013 17:31:21 -0500

I was thinking base64-encoded binary.
--Richard

On Wed, Feb 6, 2013 at 5:28 PM, Mike Jones <[email-masked]>wrote:

>  BTW, what JSON data type did you intend to be used for the “spi” value?
> A JSON string?  A string with any structure, or an unconstrained Unicode
> string?  A base64url-encoded byte sequence?****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Mike Jones
> *Sent:* Wednesday, February 06, 2013 2:27 PM
> *To:* 'Richard Barnes'; [email-masked]
> *Subject:* RE: [jose] SPI proposal****
>
> ** **
>
> Thanks for writing this up, Richard.  I believe that captures the intent
> fairly well.****
>
> ** **
>
> As we’d discussed off-list, I believe that it would be more consistent if,
> in the case were you are using a previously cached “spi” value, that the
> header contained “alg”:”spi” and “spi”:*spi-value*.  That would maintain
> the invariant that implementations always use the “alg” value to determine
> what the rest of the structure is – albeit in this case, via an indirection.
> ****
>
> ** **
>
> Also, then we’d register “spi” like any other “alg” value.  Other
> algorithms specify the use of particular header parameters.  This one would
> be no exception.  Registering it as an algorithm would also make it clear
> that it is up to implementations whether to support it or not.****
>
> ** **
>
> I don’t feel super-strongly about this, but I always try for consistency,
> where reasonable.  I think that this is such a case.****
>
> ** **
>
> Again, thanks for the write-up to help move this forward.****
>
> ** **
>
>                                                             Cheers,****
>
>                                                             -- Mike****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Richard Barnes
> *Sent:* Wednesday, February 06, 2013 2:12 PM
> *To:* [email-masked]
> *Subject:* [jose] SPI proposal****
>
> ** **
>
> from having to re-send the same parameters.****
>
> ** **
>
> needed for the encryption/decryption/signing/verification sections.****
>
> ** **
>
> Feedback welcome,****
>
> --Richard****
>
> ** **
>
> -----BEGIN-----****
>
> Section 4.1.X. "spi" Header Parameter****
>
> ** **
>
> 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****
>
> ** **
>
> MUST fail.****
> -----END-----****
> ** **
> ** **
> [9] http://tools.ietf.org/wg/jose/trac/ticket/9****
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 6 Feb 2013 17:33:56 -0500

Including this as an "alg" value would pollute the definition of "alg".
 Right now, "alg" values tell you how the key is wrapped, and any full
header MUST have one.  SPI has a completely different semantic.  The
proposed text uses the presence of "alg" as a signal that a full header was
present, providing a very simple state machine for SPI processing:

if (alg && !spi) { /* normal */ }
else if (alg && spi) { /* add to cache */ }
else if (!alg && spi) { /* pull from cache */ }

On Wed, Feb 6, 2013 at 5:26 PM, Mike Jones <[email-masked]>wrote:

> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Richard Barnes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 07 Feb 2013 08:35:07 +0200

Hi Richard,

when I tried to use the JW* specifications in OAuth my assumption was 
that the kid (key id) provides exactly the purpose you outline below 
(and call spi). (Btw, I prefer kid rather than SPI).

The only problem with the KID, as I raised on the list before, is that 
it should be in the header and not in the body (since otherwise it would 
not be visible when the data inside the body is encrypted.

Ciao
Hannes

On 02/07/2013 12:11 AM, Richard Barnes 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-----
> 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.
>
> following values from the JWE, indexed by the "spi" value:
> 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-----
>
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 7 Feb 2013 09:40:21 -0500

As I understood it, 'kid' identifies a key, not the whole collection of
security parameters.  But if that's not the case, sure, we can use 'kid'.

In either case, apparently the spec needs to be clarified.

On Thu, Feb 7, 2013 at 1:35 AM, Hannes Tschofenig <[email-masked]
> wrote:

> Hi Richard,
>
> when I tried to use the JW* specifications in OAuth my assumption was that
> the kid (key id) provides exactly the purpose you outline below (and call
> spi). (Btw, I prefer kid rather than SPI).
>
> The only problem with the KID, as I raised on the list before, is that it
> should be in the header and not in the body (since otherwise it would not
> be visible when the data inside the body is encrypted.
>
> Ciao
> Hannes
>
>> probably needed for the encryption/decryption/signing/**verification
>> sections.
>>
>> Feedback welcome,
>> --Richard
>>
>> -----BEGIN-----
>> it will have the form "header.ciphertext.integrity_**value".  When a
>> [9] http://tools.ietf.org/wg/jose/**trac/ticket/9<http://tools.ietf.org/wg/jose/trac/ticket/9>
>>
>>
>> ______________________________**_________________
>> jose mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/jose<https://www.ietf.org/mailman/listinfo/jose>
>>
>>
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 7 Feb 2013 07:42:31 -0700

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.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 7 Feb 2013 09:52:14 -0500

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
<[email-masked]>wrote:

>> it MUST NOT contain an Encrypted Key or Initialization Vector.  That is, it

---

From: Mike Jones <[email-masked]>
Date: Thu, 7 Feb 2013 17:31:58 +0000

Yes, "kid" is used to identify keys.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Thursday, February 07, 2013 6:40 AM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [jose] SPI - KID conflict -- Re: SPI proposal

As I understood it, 'kid' identifies a key, not the whole collection of security parameters.  But if that's not the case, sure, we can use 'kid'.

On Thu, Feb 7, 2013 at 1:35 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi Richard,

when I tried to use the JW* specifications in OAuth my assumption was that the kid (key id) provides exactly the purpose you outline below (and call spi). (Btw, I prefer kid rather than SPI).

The only problem with the KID, as I raised on the list before, is that it should be in the header and not in the body (since otherwise it would not be visible when the data inside the body is encrypted.

Ciao
Hannes

Feedback welcome,
--Richard

-----END-----

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 8 Feb 2013 10:06:41 +0200

Yes, it needs to be clarified in the text that it also refers to the algorithms associated with that key. 

And: I noticed that the kid is now a header parameter (which is good). 

On Feb 7, 2013, at 4:40 PM, Richard Barnes wrote:

> On Thu, Feb 7, 2013 at 1:35 AM, Hannes Tschofenig <[email-masked]> wrote:
> Hi Richard,
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 8 Feb 2013 10:10:34 +0200

The question around the header-size is independent of the kid vs. spi proposal. In both cases the content could be the same, i.e., the key name are the same. 

In the context of OAuth (and OpenID connect) there is actually a key distribution protocol build around it and that's, for example, what the MAC specification does. 

On Feb 7, 2013, at 4:52 PM, Richard Barnes 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 <[email-masked]> 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.
> 
> 
> 
> 
> 
> 
> 
>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 8 Feb 2013 07:21:28 -0700

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 <[email-masked]> wrote:

> On Thu, Feb 7, 2013 at 9:42 AM, Brian Campbell <[email-masked]
> > 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.
>>
>>
>>
>>
>>
>>
>>
>>
>>> an SPI [1] field.  To recall, SPI stands for "security parameters index",
>>> JWS (just keep header, ignore part about key/iv).  Similar text is probably
>>> opaque byte string that labels a set of security parameters.  This index is

---

From: Richard Barnes <[email-masked]>
Date: Fri, 8 Feb 2013 16:56:39 -0500

As Hannes points out, there are already a couple of examples of key
management protocols that are being built around JWT (and thus JWS/JWE).

I would actually be OK stripping away the protocol-like bits of the SPI
proposal (i.e., the part about putting things into the cache).  We could
just say: If a host uses an external process for agreeing on cryptographic
parameters for use with JOSE objects, then it MUST maintain a table,
indexed by SPI, and [reconstruct a full JWE before processing].  That way,
the key management protocols could focus on how to get stuff associated
with an SPI (including things like lifetimes, scoping, etc.).

That also provides a neat taxonomy to JOSE use cases:
1. The parties have engaged in pre-negotiation and agreed on all
parameters, so they just use SPI
2. The parties have only exchanged keys, so everything else needs to be
explicitly indicated.

On Fri, Feb 8, 2013 at 9:21 AM, Brian Campbell
<[email-masked]>wrote:

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

---

From: Anthony Nadalin <[email-masked]>
Date: Sat, 9 Feb 2013 00:42:47 +0000

I also think that this would be very  cumbersome to support and needs much more thought

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Thursday, February 7, 2013 6:43 AM
To: Richard Barnes
Cc: [email-masked]
Subject: Re: [jose] SPI proposal

On Wed, Feb 6, 2013 at 3:11 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> 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.

Feedback welcome,
--Richard

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 9 Feb 2013 13:45:09 +0200

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. 
> 
>  
> 
> 
> 
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Feb 2013 08:24:13 -0700

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 <[email-masked]

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

---

From: John Bradley <[email-masked]>
Date: Mon, 11 Feb 2013 15:01:32 -0300

I am also quite sure that kid is the thing we should use for naming keys as is the current case.

The question is if we want to be able to pass other combinations of header parameters by reference rather than by value.   Sort of the JOSE equivalent of OAuth scope.

The concern I have is that the sender of a JWE is not verifiable (unless we how mown a known rat hole)  without that you have a global name problem, and potentially others.

I would prefer to not have consideration of this optimization hold up the overall spec.

John B.

On 2013-02-11, at 12:24 PM, Brian Campbell <[email-masked]> wrote:

> 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 <[email-masked]> wrote:
> Hi Brian,
>