Re: [jose] Proposal about the SPI proposal

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

On Fri, Mar 8, 2013 at 2:26 PM, Richard Barnes <rlb@ipv.sx> wrote:

> -----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 <rlb@ipv.sx> 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:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf
>>> Of *Richard Barnes
>>> *Sent:* Wednesday, February 20, 2013 10:04 AM
>>> *To:* Nat Sakimura
>>> *Cc:* Brian Campbell; jose@ietf.org; 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 <sakimura@gmail.com>
>>> wrote:****
>>>
>>> ditto. ****
>>>
>>> 2013/2/11 Edmund Jay <ejay@mgi1.com>****
>>>
>>> +1 for new I-D.
>>>
>>> ****
>>>
>>> ** **
>>>  ------------------------------
>>>
>>> *From:* Brian Campbell <bcampbell@pingidentity.com>
>>> *To:* "jose@ietf.org" <jose@ietf.org>
>>> *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
>>> jose@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jose****
>>>
>>>
>>>
>>> ****
>>>
>>> ** **
>>>
>>> --
>>> Nat Sakimura (=nat)****
>>>
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en****
>>>
>>>
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jose****
>>>
>>> ** **
>>>
>>
>>
>