Subject: [jose] Proposal about the SPI proposal

From: Brian Campbell <[email-masked]>
Date: Fri, 8 Feb 2013 16:01:15 -0700

Maybe this was apparent from my comments/questions on the SPI proposal over
the last couple days[1] but I have concerns that run the gamut from
operational complexity and fragility to security problems. I believe
strongly that, without considerably more analysis and specification detail,
the current SPI work is much too risky to consider go in the current base
JOSE WG drafts.

As an alternative I'd like to request/propose that the SPI stuff be
submitted as new I-D to help facilitate that additional discussion and
analysis that I think it needs.

Thanks,
Brian

[1] http://www.ietf.org/mail-archive/web/jose/current/msg01500.html

---

From: Richard Barnes <[email-masked]>
Date: Fri, 8 Feb 2013 18:41:08 -0500

It seems to me that without the "build up a table" language, there's no
risk in the SPI proposal at all (see revised text below).  Fails safe: If
you get an SPI you don't know, you reject the object.  The only risk is in
the design of the key management protocols, which is a separate topic.
 Think of it like this split between RFC 4303 (ESP) and RFC 4306 (IKEv2,
the key management protocol).

And I'm not sure how having it in an I-D makes any difference at all.

--Richard

-----BEGIN-----
Section 4.1.X. "spi" Header Parameter

The "spi" (Security Parameters Index) header parameter contains a
base64url-encoded 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 use an out-of-band mechanism to negotiate
cryptographic parameters.

Entities supporting the use of the "spi" parameter maintain a table of
cached security parameters.  The maintenance of this table, e.g., how
entries are added or removed, is done by the out-of-band key management
protocol.  Each entry in the table is indexed by an SPI value, and contains
the following cryptographic parameters
-- JWE header fields
-- Encrypted Key
-- Initialization Vector

A JWE whose header contains an SPI value MUST NOT contain Encrypted Key or
Initialization Vector components.  It will thus have two base64url-encoded
components, the header and the encrypted data.  An entity receiving such a
JWE reconstructs the full JWE by adding the cached header fields to the
header, and adding the Encrypted Key and Initialization Vector components
to the JWE.  The reconstructed JWE is then processed as normal.  If a JWE
object contains an unrecognized SPI value, then the recipient MUST consider
it invalid.
-----END-----

On Fri, Feb 8, 2013 at 6:01 PM, Brian Campbell
<[email-masked]>wrote:

> Maybe this was apparent from my comments/questions on the SPI proposal
> over the last couple days[1] but I have concerns that run the gamut from
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>

---

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

+1 I think a new I-D would be appropriate as this give us additional time to review, discuss and process

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Friday, February 8, 2013 3:01 PM
To: [email-masked]
Subject: [jose] Proposal about the SPI proposal

Maybe this was apparent from my comments/questions on the SPI proposal over the last couple days[1] but I have concerns that run the gamut from operational complexity and fragility to security problems. I believe strongly that, without considerably more analysis and specification detail, the current SPI work is much too risky to consider go in the current base JOSE WG drafts.
As an alternative I'd like to request/propose that the SPI stuff be submitted as new I-D to help facilitate that additional discussion and analysis that I think it needs.

Thanks,
Brian

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 9 Feb 2013 15:39:29 +0200

I would suggest that we forget the SPI proposal and fix the text for the key id proposal in the three proposals. 
kid and spi are actually doing the same. 

The requirements for key naming are: 
 * The value is used to select the key
 * It has to uniquely select the key.
 * If you cannot find the key corresponding then this must lead to an error.

Here is from example text about key naming from RFC 4962: 

      Uniquely named keys

         AAA key management proposals require a robust key naming
         scheme, particularly where key caching is supported.  The key
         name provides a way to refer to a key in a protocol so that it
         is clear to all parties which key is being referenced.  Objects
         that cannot be named cannot be managed.  All keys MUST be
         uniquely named, and the key name MUST NOT directly or
         indirectly disclose the keying material.  If the key name is
         not based on the keying material, then one can be sure that it
         cannot be used to assist in a search for the key value.

Here is the text from draft-ietf-jose-json-web-encryption-08: 

4.1.10.  "kid" (Key ID) Header Parameter

   The "kid" (key ID) header parameter is a hint indicating which key
   was used to encrypt the JWE; this can be used to determine the
   private key needed to decrypt the JWE.  This parameter allows
   originators to explicitly signal a change of key to recipients.
   Should the recipient be unable to locate a key corresponding to the
   "kid" value, they SHOULD treat that condition as an error.  The
   interpretation of the "kid" value is unspecified.  Its value MUST be
   a string.  Use of this header parameter is OPTIONAL.

   When used with a JWK, the "kid" value MAY be used to match a JWK
   "kid" parameter value.

My proposal would be: 

----
4.1.10.  "kid" (Key ID) Header Parameter

   The "kid" (key ID) header parameter indicates which key and  
   associated parameters were used to encrypt the JWE.  
   This parameter also allows
   originators to explicitly signal a change of key to recipients.
   Should the recipient be unable to locate a key corresponding to the
   "kid" value, they MUST treat that condition as an error.  

   The value in the "kid" MUST be treated as a a case sensitive string.
   Use of this header parameter is OPTIONAL.

----

Here is the text from draft-ietf-jose-json-web-signature-08:

4.1.7.  "kid" (Key ID) Header Parameter

   The "kid" (key ID) header parameter is a hint indicating which key
   was used to secure the JWS.  This parameter allows originators to
   explicitly signal a change of key to recipients.  Should the
   recipient be unable to locate a key corresponding to the "kid" value,
   they SHOULD treat that condition as an error.  The interpretation of
   the "kid" value is unspecified.  Its value MUST be a string.  Use of
   this header parameter is OPTIONAL.

   When used with a JWK, the "kid" value MAY be used to match a JWK
   "kid" parameter value.

My proposal would be: 

----
4.1.7.  "kid" (Key ID) Header Parameter

   The "kid" (key ID) header parameter is a hint indicating which key
   was used to secure the JWS.  This parameter allows originators to
   explicitly signal a change of key to recipients.  Should the
   recipient be unable to locate a key corresponding to the "kid" value,
   they SHOULD treat that condition as an error.  The interpretation of
   the "kid" value is unspecified.  Its value MUST be a string.  Use of
   this header parameter is OPTIONAL.

   The "kid" (key ID) header parameter indicates which key and  
   associated parameters were used for the digital signature and  
   the keyed message digest computation of the JWS.   
   This parameter also allows
   originators to explicitly signal a change of key to recipients.
   Should the recipient be unable to locate a key corresponding to the
   "kid" value, they MUST treat that condition as an error.  

   The value in the "kid" MUST be treated as a a case sensitive string.  
   Use of this header parameter is OPTIONAL.
----

Here is the text from draft-ietf-jose-json-web-key-08: 

4.4.  "kid" (Key ID) Parameter

   The "kid" (key ID) member can be used to match a specific key.  This
   can be used, for instance, to choose among a set of keys within a JWK
   Set during key rollover.  The interpretation of the "kid" value is
   unspecified.  Key ID values within a JWK Set need not be unique.  The
   "kid" value is a case sensitive string.  Use of this member is
   OPTIONAL.

   When used with JWS or JWE, the "kid" value MAY be used to match a JWS
   or JWE "kid" header parameter value.

   In some contexts, different keys using the same Key ID value might be
   present, with the keys being disambiguated using other information,
   such as the "kty" or "use" values.  For example, imagine "kid" values
   like "Current", "Upcoming", and "Deprecated", used for key rollover
   guidance.  One could apply a label to all keys where the
   classification fits.  If there are multiple "Current" keys, then in
   this example, they might be differentiated either by having different
   "kty" or "use" values, or some combination of both.  As one example,
   there might only be one current RSA signing key and one current
   Elliptic Curve signing key, but both would be "Current".

My proposal would be: 

----

4.4.  "kid" (Key ID) Parameter

   The "kid" (key ID) header parameter indicates the name of the key.  The key 
   id must be unique for the specific context so that the recipient is able to 
   determine what key to use for a cryptographic operation without additional information. 
   This parameter also allows  originators to explicitly signal a change of 
   key to recipients. Should the recipient be unable to locate a key corresponding to the
   "kid" value, they MUST treat that condition as an error.  

   When the JSON Web Key payload is used together with a JWS or a JWE
   and the "kid" value matches the value in the JWS
   or JWE "kid" header parameter value then a key transport mechanism is
  used, i.e., the key itself is attached to the JWS or the JWE payload.  

-----

Notice that I changed the description for the JSON Web Key quite a bit since this non-uniqueness description was a bit of nonsense. 
If you have the ability to uniquely name the key using a kid then why wouldn't you want to do it. This simplifies implementations. 

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Mon, 11 Feb 2013 16:45:22 -0300

I agree that doing it as a new I-D is better than trying to fit it in without sufficient thought.

John B.

---

From: Mike Jones <[email-masked]>
Date: Mon, 11 Feb 2013 19:54:52 +0000

+1 to SPI being a separate I-D, for discussion purposes.

Having thought about this, I feel like there are a number unanswered questions about this proposal, and that writing it up concretely would be useful to help the working group identify and address them and determine the best path forward.

These questions/issues include:
  - What are the security implications of repeatedly reusing the same CMK and IV and how can/should they be mitigated?
  - Is having the absence of an "alg" field, paired with the presence of an "spi" field the best way to handle this?
  - What are the complexity implications of having JWEs no longer contain a fixed set of field?
  - Would JWSs similarly have a different number of fields?
  - Indeed, is the proposal even applicable in the JWS case, or does it only make sense for JWEs?
  - What are the motivating use cases for this functionality?
  - What syntax would be used for the "spi" parameter?  Unrestricted Unicode strings?  Base64url-encoded byte strings?  UUIDs? ...

                                                                Thanks,
                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Monday, February 11, 2013 11:45 AM
To: Brian Campbell
Cc: [email-masked]
Subject: Re: [jose] Proposal about the SPI proposal

John B.

On 2013-02-08, at 8:01 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Brian

[1] http://www.ietf.org/mail-archive/web/jose/current/msg01500.html
_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: Edmund Jay <[email-masked]>
Date: Mon, 11 Feb 2013 16:29:44 -0800 (PST)

+1 for new I-D.

________________________________
From: Brian Campbell <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: Fri, February 8, 2013 3:01:51 PM
Subject: [jose] Proposal about the SPI proposal

Maybe this was apparent from my comments/questions on the SPI proposal over the 
last couple days[1] but I have concerns that run the gamut from operational 
complexity and fragility to security problems. I believe strongly that, without 
considerably more analysis and specification detail, the current SPI work is 
much too risky to consider go in the current base JOSE WG drafts.

As an alternative I'd like to request/propose that the SPI stuff be submitted as 
new I-D to help facilitate that additional discussion and analysis that I think 
it needs.

Thanks,
Brian

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 20 Feb 2013 11:25:07 -0500

ditto.

2013/2/11 Edmund Jay <[email-masked]>

> +1 for new I-D.
>
>
>
> ------------------------------
> *From:* Brian Campbell <[email-masked]>
> *To:* "[email-masked]" <[email-masked]>
> *Sent:* Fri, February 8, 2013 3:01:51 PM
> *Subject:* [jose] Proposal about the SPI proposal
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Richard Barnes <[email-masked]>
Date: Wed, 20 Feb 2013 13:03:38 -0500

Obviously, this will not be in a -00 draft for Orlando.  So discussion
should continue based on the text proposed to the list.

Does anyone have further technical comments?

--Richard

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Feb 2013 18:09:15 +0000

See my questions/issues in http://www.ietf.org/mail-archive/web/jose/current/msg01549.html, which were:

I don't think a number of them have been answered.

                                                            Thanks,
                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Wednesday, February 20, 2013 10:04 AM
To: Nat Sakimura
Cc: Brian Campbell; [email-masked]; Edmund Jay
Subject: Re: [jose] Proposal about the SPI proposal

Obviously, this will not be in a -00 draft for Orlando.  So discussion should continue based on the text proposed to the list.

--Richard

On Wed, Feb 20, 2013 at 11:25 AM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:
ditto.
2013/2/11 Edmund Jay <[email-masked]<mailto:[email-masked]>>
+1 for new I-D.

________________________________
From: Brian Campbell <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Fri, February 8, 2013 3:01:51 PM
Subject: [jose] Proposal about the SPI proposal

Thanks,
Brian

---

From: Richard Barnes <[email-masked]>
Date: Wed, 27 Feb 2013 13:50:03 -0500

Ah, sorry I never got around to those.  Responses inline.

  - What are the security implications of repeatedly reusing the same CMK
> and IV and how can/should they be mitigated?
>

Good point.  Re-using IVs is a terrible idea.  SPI should represent some
set of pre-negotiated parameters, where the set of parameters that are
pre-set is part of the pre-negotiation.  So one application might
pre-negotiate algorithms, but pass keys in-band, but another might
pre-negotiate algorithms and keys.  (You could even envision agreeing on an
IV generation procedure...)

> ****
>
>   - Is having the absence of an “alg” field, paired with the presence of
> an “spi” field the best way to handle this?
>

"alg" is an indicator of key wrapping technique.  So if this is one of the
pre-negotiated parameters, then it should be absent.

> ****

Very little.  SPI would add a little pre-processing to populate the missing
fields in a JWE/JWS

> ****

Yes.

> ****

There's less of a need for JWS.  You could say SPI "1234" indicates that
I'm signing under a given 4096-bit RSA key, saving yourself hundreds of
octets.  So it would be like "jku", with fewer octets and without the
implication that you could go fetch it over the Internet.

> ****

As I said before, cases where there's some out-of-band mechanism to
pre-negotiate certain parameters.  For example, the OpenID Connect
discovery process.
<
http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest

> ****
>
>   - What syntax would be used for the “spi” parameter?  Unrestricted
> Unicode strings?  Base64url-encoded byte strings?  UUIDs? …
>

Doesn't really matter.  Make it the same as "kid" (i.e., string); they're
both opaque identifiers.

> ****
>
> ** **
>
> I don’t think a number of them have been answered.****
>
> ** **
>
>                                                             Thanks,****
>
>                                                             -- Mike****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Richard Barnes
> *Sent:* Wednesday, February 20, 2013 10:04 AM
> *To:* Nat Sakimura
> *Cc:* Brian Campbell; [email-masked]; Edmund Jay
> *Subject:* Re: [jose] Proposal about the SPI proposal****
>
> ** **
>
> should continue based on the text proposed to the list.****
>
> ** **
>
> Does anyone have further technical comments?****
>
> ** **
>
> --Richard****
>
> ** **
>
> ****
> ditto. ****
> 2013/2/11 Edmund Jay <[email-masked]>****
>
> +1 for new I-D.
>
> ****
>
> ** **
> *Subject:* [jose] Proposal about the SPI proposal****
>
> ** **
>
> JOSE WG drafts.****
> analysis that I think it needs.****
>
> ** **
>
> Thanks,
> Brian****
>
>
> [1] http://www.ietf.org/mail-archive/web/jose/current/msg01500.html****
>
> ** **
>
> https://www.ietf.org/mailman/listinfo/jose****
>
>
>
> ****
>
> ** **
>
> --
> Nat Sakimura (=nat)****
>
> @_nat_en****
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>