[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
JOSE Working Group                                             R. Barnes
Internet-Draft                                                       BBN
Intended status: Informational                            March 21, 2013
Expires: September 22, 2013


                     JOSE Security Parameters Index
                        draft-barnes-jose-spi-00

Abstract

   The use cases for JOSE include cases where a given sender and
   receiver use an out-of-band mechanism to negotiate cryptographic
   parameters, so that these parameters do not have to appear in a JOSE
   object.  This document proposed a modification to the JOSE formats to
   allow for signaling that pre-negotiated parameters are being used,
   and if so, which parameters.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 22, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as



Barnes                 Expires September 22, 2013               [Page 1]


Internet-Draft                  JOSE SPI                      March 2013


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  "spi" (Security Parameters Index) Header Parameter  . . . . . . 4
   3.  Changes to Processing Steps . . . . . . . . . . . . . . . . . . 5
   4.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     4.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     4.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7







































Barnes                 Expires September 22, 2013               [Page 2]


Internet-Draft                  JOSE SPI                      March 2013


1.  Introduction

   The use cases for JOSE include cases where a given sender and
   receiver use an out-of-band mechanism to negotiate cryptographic
   parameters, such as OpenID Connect.  This allows the sender and
   receiver to exchange JOSE objects without having to include all of
   the required security parameters, for example, algorithm names and
   public keys.

   The current specifications for JSON Web Encryption (JWE)
   [I-D.ietf-jose-json-web-encryption] and JSON Web Signature (JWS)
   [I-D.ietf-jose-json-web-signature] accommodate these use cases by
   simply omitting requirements levels on some parameters.  For exmaple,
   it should be REQUIRED for some sort of key or key identifier to be
   provided, so that the recipient of an object knows which key to use
   to process it.  However, since two parties may have pre-negotiated
   which key to use, all key and key identifier fields are marked as
   OPTIONAL in the current specification.  This leaves JWE and JWS
   without a good notion of what a well-formed object looks like.

   A better approach would be to put hard requirements on parameters,
   but allow them to be omitted if they have been pre-negotiated.  Thus,
   the specifications might REQUIRED that a "kid", "jwk", or "jku" field
   be present in an object, except if the object contains an indicator
   that some parameters have been pre-negotiated.  Following the
   terminology from IPsec [RFC4301], we call this flag a "security
   parameters index", or SPI.

   The addition of SPI would clarify the processing model for JWE to
   include an explicit provision for pre-negotiated parameters.  Namely,
   if an object contains an "spi" value, then the recipient first the
   object to a normal JWE or JWS object by filling in the pre-negotiated
   parameters.  Then it can process the object as normal.

   This document proposes two main changes.  First, we provide a
   definition of the "spi" header parameter, to be added to Section 4.1
   of the JWE specification and the JWS specification.  Second, we
   propose changes to the processing instructions in the respective
   specifications.












Barnes                 Expires September 22, 2013               [Page 3]


Internet-Draft                  JOSE SPI                      March 2013


2.  "spi" (Security Parameters Index) Header Parameter

   The "spi" header parameter contains an opaque string, which refers to
   a set of pre-negotiated security parameters, established through some
   out-of-band negotiation protocol.  The association of security
   parameters to SPI values is the responsibility of the negotiation
   protocol, as are other management considerations (e.g., the lifetime
   of a set of parameters).

   When an object contains an SPI value, fields with pre-negotiated
   values MAY be omitted, even if they would otherwise be REQUIRED.  If
   the recipient of an object encounters an SPI value references a known
   set of security parameters, then the recipient MUST populate them
   into relevant fields in the object before further processing.  If the
   SPI value is unknown to a recipient, or the recipient does not
   support pre-negotiation of parameters, then the "spi" field MUST be
   ignored.  (Implementations SHOULD issue a warning in this case,
   because of the risk that processing will fail due to missing
   parameters.)
































Barnes                 Expires September 22, 2013               [Page 4]


Internet-Draft                  JOSE SPI                      March 2013


3.  Changes to Processing Steps

   In JWE, Section 5.1, add the following text to step 10:

      If pre-negotiated parameters are used, add an "spi" field and
      remove any pre-negotiated parameters.

   In JWE, Section 5.2. add the following step after step 3:

      The JWE Header SHOULD be examined for an "spi" parameter.  If an
      "spi" parameter is present and contains a recognized value, add
      the corresponding pre-negotiated parameters to the Header object.

   In JWS, Section 5.1, add the following text to step 3:

      If pre-negotiated parameters are used, add an "spi" field and
      remove any pre-negotiated parameters.

   In JWS, Section 5.2., add the following step after step 3:

      The JWS Header SHOULD be examined for an "spi" parameter.  If an
      "spi" parameter is present and contains a recognized value, add
      the corresponding pre-negotiated parameters to the Header object.




























Barnes                 Expires September 22, 2013               [Page 5]


Internet-Draft                  JOSE SPI                      March 2013


4.  References

4.1.  Normative References

   [I-D.ietf-jose-json-web-encryption]
              Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web
              Encryption (JWE)", draft-ietf-jose-json-web-encryption-08
              (work in progress), December 2012.

   [I-D.ietf-jose-json-web-signature]
              Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", draft-ietf-jose-json-web-signature-08
              (work in progress), December 2012.

4.2.  Informative References

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

































Barnes                 Expires September 22, 2013               [Page 6]


Internet-Draft                  JOSE SPI                      March 2013


Author's Address

   Richard Barnes
   BBN

   Email: rlb@ipv.sx













































Barnes                 Expires September 22, 2013               [Page 7]