One document matched: draft-barnes-jose-spi-00.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<rfc ipr="trust200902" docName="draft-barnes-jose-spi-00" category="info">

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

  <front>
    <title abbrev="JOSE SPI">JOSE Security Parameters Index</title>

    <author initials="R." surname="Barnes" fullname="Richard Barnes">
      <organization>BBN</organization>
      <address>
        
        
        <email>rlb@ipv.sx</email>
        
      </address>
    </author>

    <date year="2013" month="March" day="21"/>

    <area>Security</area>
    <workgroup>JOSE Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


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



    </abstract>


  </front>

  <middle>


<section anchor="intro" title="Introduction">

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

<t>The current specifications for JSON Web Encryption (JWE) <xref target="I-D.ietf-jose-json-web-encryption"/> and JSON Web Signature (JWS) <xref target="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.</t>

<t>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 <xref target="RFC4301"/>, we call this flag a “security parameters index”, or SPI.</t>

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

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

</section>
<section anchor="spi-security-parameters-index-header-parameter" title="“spi” (Security Parameters Index) Header Parameter">

<t>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).  </t>

<t>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.)  </t>

</section>
<section anchor="changes-to-processing-steps" title="Changes to Processing Steps">

<t>In JWE, Section 5.1, add the following text to step 10:</t>

<t><list style='empty'>
  <t>If pre-negotiated parameters are used, add an “spi” field and remove any pre-negotiated parameters.</t>
</list></t>

<t>In JWE, Section 5.2. add the following step after step 3:</t>

<t><list style='empty'>
  <t>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.</t>
</list></t>

<t>In JWS, Section 5.1, add the following text to step 3:</t>

<t><list style='empty'>
  <t>If pre-negotiated parameters are used, add an “spi” field and remove any pre-negotiated parameters.</t>
</list></t>

<t>In JWS, Section 5.2., add the following step after step 3:</t>

<t><list style='empty'>
  <t>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.</t>
</list></t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor='I-D.ietf-jose-json-web-encryption'>
<front>
<title>JSON Web Encryption (JWE)</title>

<author initials='M' surname='Jones' fullname='Michael Jones'>
    <organization />
</author>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<author initials='J' surname='Hildebrand' fullname='Joe Hildebrand'>
    <organization />
</author>

<date month='December' day='28' year='2012' />

<abstract><t>JSON Web Encryption (JWE) is a means of representing encrypted content using JavaScript Object Notation (JSON) data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification.  Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) specification.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-jose-json-web-encryption-08' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-encryption-08.txt' />
<format type='PDF'
        target='http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-encryption-08.pdf' />
</reference>



<reference anchor='I-D.ietf-jose-json-web-signature'>
<front>
<title>JSON Web Signature (JWS)</title>

<author initials='M' surname='Jones' fullname='Michael Jones'>
    <organization />
</author>

<author initials='J' surname='Bradley' fullname='John Bradley'>
    <organization />
</author>

<author initials='N' surname='Sakimura' fullname='Nat Sakimura'>
    <organization />
</author>

<date month='December' day='28' year='2012' />

<abstract><t>JSON Web Signature (JWS) is a means of representing content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) data structures.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-jose-json-web-signature-08' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-signature-08.txt' />
<format type='PDF'
        target='http://www.ietf.org/internet-drafts/draft-ietf-jose-json-web-signature-08.pdf' />
</reference>




    </references>

    <references title='Informative References'>





<reference anchor='RFC4301'>

<front>
<title>Security Architecture for the Internet Protocol</title>
<author initials='S.' surname='Kent' fullname='S. Kent'>
<organization /></author>
<author initials='K.' surname='Seo' fullname='K. Seo'>
<organization /></author>
<date year='2005' month='December' />
<abstract>
<t>This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer.  This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='4301' />
<format type='TXT' octets='262123' target='http://www.rfc-editor.org/rfc/rfc4301.txt' />
</reference>




    </references>



  </back>
</rfc>