Subject: Re: [jose] Proposal about the SPI proposal

From: Richard Barnes <[email-masked]>
Date: Fri, 8 Mar 2013 14:26:56 -0500

-----BEGIN-----
Section 4.1.X. "spi" (Security Parameters Index) 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 using an out-of-band negotiation mechanism 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
pre-negotiated parameters for the JWE, such as values for the "alg" or
"zip" parameters, or a value for the Encrypted Key component.

A JWE whose header contains an SPI value MAY omit the Encrypted Key
component, by making this field zero-length in the compact serialization.
An entity receiving such a JWE reconstructs the full JWE by adding the
cached header fields to the header, and adding the Encrypted Key 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.

The out-of-band management protocol MUST ensure that the SPI value is
unique within the sender's context.  To prevent the SPI value from being
used to interfere with JOSE processing, the management protocol SHOULD also
ensure that it is difficult for a third party (who has not participated in
the management protocol) to guess an SPI value.  As a simple way to meet
both of these requirements, it is RECOMMENDED that the SPI value be a
128-bit random value.
-----END-----

On Wed, Feb 27, 2013 at 1:50 PM, Richard Barnes <[email-masked]> wrote:

> 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.
>
>
>> ****
>>
>>   - What are the complexity implications of having JWEs no longer contain
>> a fixed set of field?
>>
>
> Very little.  SPI would add a little pre-processing to populate the
> missing fields in a JWE/JWS
>
>
>> ****
>>
>>   - Would JWSs similarly have a different number of fields?
>>
>
> Yes.
>
>
>> ****
>>
>>   - Indeed, is the proposal even applicable in the JWS case, or does it
>> only make sense for JWEs?
>>
>
> 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.
>
>
>> ****
>>
>>   - What are the motivating use cases for this functionality?
>>
>
> 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****
>>
>> ** **
>>
>> 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****
>>
>> ** **
>>
>> On Wed, Feb 20, 2013 at 11:25 AM, Nat Sakimura <[email-masked]>
>> wrote:****
>>
>> 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****
>>
>> ** **
>>
>> 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****
>>
>> ** **
>>
>> _______________________________________________
>> jose mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/jose****
>>
>>
>>
>> ****
>>
>> ** **
>>
>> --
>> Nat Sakimura (=nat)****
>>
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en****
>>
>>
>> _______________________________________________
>> jose mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/jose****
>>
>> ** **
>>
>
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 8 Mar 2013 14:27:17 -0500

Sorry, meant to start with: Revised text for the SPI proposal follows.

On Fri, Mar 8, 2013 at 2:26 PM, Richard Barnes <[email-masked]> wrote:

> protocol.  Each entry in the table is indexed by an SPI value, and
> contains pre-negotiated parameters for the JWE, such as values for the
> "alg" or "zip" parameters, or a value for the Encrypted Key component.
>
> object contains an unrecognized SPI value, then the recipient MUST
> consider it invalid.
>
>> "alg" is an indicator of key wrapping technique.  So if this is one of
>> the pre-negotiated parameters, then it should be absent.
>>
>>
>>> ****
>>>
>>>   - What are the complexity implications of having JWEs no longer
>>> contain a fixed set of field?
>>>
>>