<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5652 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5652.xml">
<!ENTITY RFC5759 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5759.xml">
<!ENTITY RFC6318 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6318.xml">
<!ENTITY RFC6257 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6257.xml">
<!ENTITY RFC5050 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5050.xml">  
<!ENTITY RFC3370 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3370.xml">
<!ENTITY RFC3394 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3394.xml">
<!ENTITY RFC3565 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3565.xml">
<!ENTITY RFC5084 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5084.xml">
<!ENTITY RFC5480 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5480.xml">
<!ENTITY RFC5753 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5753.xml">
<!ENTITY RFC5754 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5754.xml">               
]>
<?rfc toc="yes"?>
<!-- generate a table of contents -->
<?rfc symrefs="yes"?>
<!-- use anchors instead of numbers for references -->
<?rfc sortrefs="yes" ?>
<!-- alphabetize the references -->
<?rfc compact="yes" ?>
<!-- conserve vertical whitespace -->
<?rfc subcompact="no" ?>
<!-- but keep a blank line between list items -->
<rfc category="exp" docName="draft-birrane-dtn-bpsec-suiteb-ciphersuites-00" ipr="trust200902"
     obsoletes="" submissionType="IETF" updates="" xml:lang="en">
  <front>
    <title>Suite B Ciphersuites for Bundle Protocol Security (BPSec)</title>

    <author fullname="Edward J. Birrane" initials="E.J."
            surname="Birrane">
      <organization abbrev="JHU/APL">The Johns Hopkins University Applied
      Physics Laboratory</organization>

      <address>
        <postal>
          <street>11100 Johns Hopkins Rd.</street>

          <city>Laurel</city>

          <region>MD</region>

          <code>20723</code>

          <country>US</country>
        </postal>

        <phone>+1 443 778 7423</phone>

        <email>Edward.Birrane@jhuapl.edu</email>
      </address>
    </author>

    <date month="December" year="2015"/>

    <!-- Meta-data -->

    <area>General</area>

    <workgroup>Delay-Tolerant Networking</workgroup>

    <keyword>security</keyword>

    <keyword>bundle</keyword>

    <keyword>integrity</keyword>

    <keyword>authentication</keyword>

    <keyword>confidentiality</keyword>

    <abstract>
      <t>         
         This document proposes ciphersuites to be used for Bundle Protocol
         Security (BPSec). These new ciphersuites provide compatibility with the 
         United States National Security Agency's Suite B specifications.
      </t>         
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction" toc="default">
      <t>
         This document specifies ciphersuites to be used with Bundle Protocol
         Security (BPSec) <xref target="I-D.ietf-dtn-bpsec"/>. These suites 
         provide compatibility with the United States National Security Agency's 
         Suite B specifications.
      </t>
      <t>                    
         This document is an update to the Suite-B 
         profile created by Burgin and Hennessy <xref target="I-D.hennessy-bsp-suiteb-ciphersuites"/>. This
         update adapts the profile from BSP <xref target="RFC6257"/> to BPSec. 
      </t>
   </section>      
   
   <section anchor="term" title="Requirements Language" toc="default">
      <t>
         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
        "OPTIONAL" in this document are to be interpreted as described in
        <xref format="default" pageno="false" target="RFC2119"/>.
      </t>
   </section>
   
   <section title="Suite B Ciphersuites">
      <section title="Overview">      
      <t>
         This section defines new ciphersuites for use with the security
         block types BIB and BCB.  The BIB ciphersuites are based
         on digital signatures using ECDSA.  The BCB ciphersuites use
         ECDH for key agreement, AES in Galois/Counter Mode (GCM) for content
         encryption, and AES Key Wrap for key encryption.  All proposed
         ciphersuites use SHA-256 or SHA-384 as the hash algorithm.
      </t>
      <t>      
         The ciphersuites use the mechanisms defined in Cryptographic Message
         Syntax (CMS) <xref target="RFC5652"/> for packaging the keys, signatures, etc., for
         transport in the appropriate security block.  Additionally, the
         ciphersuites follow the guidance and requirements of RFC 6318 <xref target="RFC6318"/>
         which specifies the conventions for using Suite B algorithms in 
         Secure/Multipurpose Internet Mail Extensions (S/MIME).
      </t>
      <t>      
         CMS values are generated using ASN.1 [X.208-88], the Basic Encoding
         Rules (BER) [X.209-88], and the Distinguished Encoding Rules (DER)
         [X.509-88].
      </t>
       </section>
       
      <section title="Suites BIB-ECDSA-SHA256 and BIB-ECDSA-SHA384">
         <t>         
            The BIB-ECDSA-SHA256 ciphersuite has ciphersuite ID value 0xB1, and
            the BIB-ECDSA-SHA384 ciphersuite has ciphersuite ID value 0xB2.
         </t>         
         <t>
            In BIB-ECDSA-SHA256, ECDSA MUST be used with the SHA-256 message
            digest algorithm and the P-256 elliptic curve, as specified in
            <xref target="RFC6318"/>.  In BIB-ECDSA-SHA384, ECDSA MUST be used 
            with the SHA-384 message digest algorithm and the P-384 elliptic 
            curve, as specified in <xref target="RFC6318"/>.  The P-256 and 
            P-384 elliptic curves are specified in <xref target="DSS"/>.
         </t>
         <t>
            The SHA-256 and SHA-384 message digest algorithms are defined in FIPS
            Pub 180-3 <xref target="RFC5754"/>.  The algorithm identifiers for 
            SHA-256 and SHA-384 are defined in <xref target="RFC5754"/>.  
            RFC 5754 specifies the conventions for using SHA-256 and SHA-384 
            with CMS.  Within the CMS signed-data content type, message digest 
            algorithm identifiers are located in the SignedData digestAlgorithms 
            field and the SignerInfo digestAlgorithm field.
         </t>               
         <t>
            RFC 5753 <xref target="RFC5753"/> specifies the conventions for using 
            ECDSA with CMS.  RFC 5480 <xref target="RFC5480"/> defines the 
            signature algorithm identifiers used in CMS for ECDSA with SHA-256 
            and ECDSA with SHA-384.  Relevant details are repeated here.
         </t>
      
         <t>        
            Within the CMS signed-data content type, signature algorithm
            identifiers are located in the SignerInfo signatureAlgorithm field of
            SignedData.  In addition, signature algorithm identifiers are located
            in the SignerInfo signatureAlgorithm field of countersignature
            attributes.  When either signature algorithm identifier is used, the
            AlgorithmIdentifier parameters field MUST be absent.
         </t>

         <t>        
            When signing, the ECDSA algorithm generates two values, commonly
            called r and s.  To transfer these two values as one signature, they
            MUST be encoded using the ECDSA-Sig-Value type specified in RFC 5480
            <xref target="RFC5480"/>.
         </t>

         <t>      
            Because the signature field in SignedData SignatureValue is a
            security-result field, the entire key-information item MUST be placed
            in the BIB's security-result field, rather than security-
            parameters.
         </t>
         
      </section>
      
      <section title="Suites BCB-ECDH-SHA256-AES128 and BCB-ECDH-SHA384-AES256">
         <t>
            The BCB-ECDH-SHA256-AES128 ciphersuite has ciphersuite ID value 0xB3,
            and the BCB-ECDH-SHA384-AES256 ciphersuite has ciphersuite ID value
            0xB4.
         </t>
         <t>
            These schemes encrypt any block in a bundle except the primary
            block and another BCB block. Both ciphersuites use ephemeral-static 
            ECDH, which means that the security source possesses an ephemeral 
            ECDH key pair and the security destination possesses a static ECDH key pair.
         </t>
         
         <t>
            In BCB-ECDH-SHA256-AES128, ephemeral-static ECDH MUST be used with
            the SHA-256 KDF, AES-128 Key Wrap, and the P-256 elliptic curve, as
            specified in <xref target="RFC6318"/>.  In BCB-ECDH-SHA384-AES256, 
            ephemeral-static ECDH MUST be used with the SHA-384 KDF, AES-256 
            Key Wrap, and the P-384 elliptic curve, as specified in <xref target="RFC6318"/>.  
            The P-256 and P-384 elliptic curves are specified in <xref target="DSS"/>.
         </t>
         
         <t>
            When a key agreement algorithm is used in CMS, a key-encryption
            algorithm is also needed to encrypt the content encryption key (CEK).
            These ciphersuites use Advanced Encryption Standard (AES) Key Wrap,
            as specified in RFC 3394 <xref target="RFC3394"/> and <xref target="AESWRAP"/>, 
            as the key-
            encryption algorithm.  The key-encryption key used with the AES Key
            Wrap algorithm is obtained from a key derivation function (KDF).
            These ciphersuites use a KDF based on SHA-256 and SHA-384.
         </t>
         <t>         
            Section 3.1 of RFC 5753 <xref target="RFC5753"/> specifies the conventions for using
            ECDH with CMS.  Here the bundle encryption key (BEK), used to encrypt
            the target block, is the data to be carried in a CMS enveloped-data
            content type.  CMS encrypts the BEK with a freshly generated content
            encryption key (CEK) and the result is placed in the encryptedContent
            field of an EnvelopedData EncryptedContentInfo structure.  The CEK is
            encrypted with the ECDH-generated pairwise key-encryption key (KEK)
            using the AES Key Wrap algorithm.  The result is placed in the
            EnvelopedData RecipientInfos KeyAgreeRecipientInfo
            RecipientEncryptedKey EncryptedKey field.
         </t>
         
         <t>
            Algorithm identifiers needed when using ECDH with CMS are provided in
            RFC 6318 <xref target="RFC6318"/> section 4.  Within the CMS enveloped-data content
            type, the key agreement algorithm identifier is placed in the
            EnvelopedData RecipientInfos KeyAgreeRecipientInfo
            keyEncryptionAlgorithm field.  The key wrap algorithm identifier is
            placed in the KeyWrapAlgorithm parameters within the EnvelopedData
            RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm field.
         </t>

         <t>         
            KDFs based on SHA-256 and SHA-384 are used to derive a pairwise key-
            encryption key from the shared secret produced by ephemeral-static
            ECDH.  Section 4.3 of RFC 6318 <xref target="RFC6318"/> specify the conventions for
            using the KDF with the shared secret generated with ephemeral-static
            ECDH with the CMS.
         </t>
         
         <t>         
            Target block BSP encryption is done using the AES algorithm in Galois/
            Counter Mode (GCM) as described in <xref target="RFC5084"/>.  For 
            consistency with the description in <xref target="RFC5084"/>, we refer 
            to the GCM IV as a nonce.  The same key and nonce combination MUST 
            NOT be used more than once. The nonce is constructed by concatenating
            a salt field and an initialization vector, as follows.
        </t>        

         <t>        
            The salt field is a four-octet value, usually chosen at random.  
            The salt need not be kept secret. The initialization vector (IV) is 
            an eight-octet value, usually chosen at random. The value need not 
            be kept secret.
         </t>
         
         <t>         
            The BEK is a 16-octet (128 bits) value in BCB-ECDH-SHA256-AES128, and
            is a 32-octet value (256 bits) in BCB-ECDH-SHA384-AES256.  The BEK
            SHOULD be chosen randomly and MUST be kept secret.
         </t>

         <t>        
            The Integrity Check Value (ICV) from the AES-GCM content encryption
            is a 16-octet value used to verify that the protected data has not
            been altered.  Normally, the ICV is concatenated with the ciphertext
            to produce the output of AES-GCM encryption.  However, to avoid
            expansion of the payload, the ICV value is placed in the security-
            result field of the BCB.  The value need not be kept secret.
         </t>
         
         <t>
            Each ciphersuite populates a single BCB in the bundle. This BCB MUST
            contain security-parameters and security-result fields. The security-parameters 
            field includes the salt, IV, and key-information items where the key-
            information item contains the encrypted BEK encoded in a CMS
            EnvelopedData structure.  The security-results-field contains the
            ICV. The ciphertext is NOT stored in the BCB, but replaces the
            plaintext from the target block. The other bytes of the target block,
            such as type, flags, and length, are not modified.         
         </t>

      </section>
      
   </section>
  

   <section title="Security Considerations">
      <t>
         Two levels of security may be achieved using this specification.
         Users must consider their risk environment to determine which level
         is appropriate for their own use.
      </t>

      <t>
         The security considerations in <xref target="I-D.ietf-dtn-bpsec"/> 
         discuss the BPSec Protocol and apply here as well.
      </t>
      
      <t>
         The security considerations in <xref target="RFC5652"/> discuss the CMS 
         as a method for digitally signing data and encrypting data.
      </t>
      <t>
         The security considerations in <xref target="RFC3370"/> discuss cryptographic
         algorithm implementation concerns in the context of the CMS.
      </t>
      <t>      
         The security considerations in <xref target="RFC5753"/> discuss the use 
         of elliptic curve cryptography (ECC) in the CMS.
      </t>
      <t>      
         The security considerations in <xref target="RFC3565"/> discuss the use of AES in
         the CMS, and the security considerations in <xref target="RFC5084"/> discuss the
         Galois/Counter Mode.         
      </t>
    
   </section> 

   <section title="IANA Considerations">
      <t>
          This protocol has fields that have been registered by IANA.
      </t>      
   
      <t>      
         The BPSec has a ciphersuite number field and certain ciphersuites are
         defined. The registration policy for this registry is: Specification 
         Required. The Value range is: Variable Length.
         
      </t>
   
      <t>      
         IANA is requested to assign the following values for the ciphersuite
         number field.
         
         <figure><artwork><![CDATA[
                       Ciphersuite Numbers Registry:

       +-------+--------------------------------------+----------------+
       | Value | Description                          | Reference      |
       +-------+--------------------------------------+----------------+
       | 0xB1  | BIB-ECDSA-SHA256                     | This document  |
       | 0xB2  | BIB-ECDSA-SHA384                     | This document  |
       | 0xB3  | BCB-ECDH-SHA256-AES128               | This document  |
       | 0xB4  | BCB-ECDH-SHA384-AES256               | This document  |
       +-------+--------------------------------------+----------------+

]]></artwork></figure>
      </t>
   </section>   
  </middle>

  <back>
    <references title="Normative References">
      
       
       <?rfc include="reference.I-D.ietf-dtn-bpsec.xml"?>
              <reference anchor="AESWRAP">
          <front>
             <title>AES Key Wrap Specification</title>
             <author>
                <organization>
                   National Institute of Standards and Technology
                </organization>
             </author>
             <date month="November" year="2001"/>
          </front>
       </reference>
              
       <reference anchor="FIPS180-3">
          <front>
             <title>Secure Hash Standard</title>
             <author>
                <organization>
                   National Institute of Standards and Technology
                </organization>
             </author>
             <date month="October" year="2008"/>
          </front>
          <seriesInfo name="FIPS PUB" value="180-3"/>
       </reference>
       
       <reference anchor="DSS">
          <front>
             <title>Digital Signature Standard (DSS)</title>
             <author>
                <organization>
                   National Institute of Standards and Technology
                </organization>
             </author>
             <date month="June" year="2009"/>
          </front>
          <seriesInfo name="FIPS PUB" value="186-3"/>
       </reference>
              
       <reference anchor="FIPS197">
          <front>
             <title>Advanced Encryption Standard (AES)</title>
             <author>
                <organization>
                   National Institute of Standards and Technology
                </organization>
             </author>
             <date month="November" year="2001"/>
          </front>
          <seriesInfo name="FIPS PUB" value="197"/>
       </reference>
              
       &RFC2119;
       &RFC3370;
       &RFC3394;
       &RFC3565;
       &RFC5084;
       &RFC5480;                   
       &RFC5652;
       &RFC5753;
       &RFC5754;
       &RFC6318;       
        
    </references>

    <references title="Informative References">

      &RFC6257;
      &RFC5050;
       
      <?rfc include="reference.I-D.hennessy-bsp-suiteb-profile.xml"?>  
      <?rfc include="reference.I-D.hennessy-bsp-suiteb-ciphersuites.xml"?>
      
      <reference anchor="SP800-56A">
         <front>
            <title>Recommendation for Pair-wise Key Establishment Schemes Using Discrete Logarithm Cryptography</title>
             <author>
                <organization> 
                   National Institute of Standards and Technology                   
                </organization>
             </author>
             
             <date month="March" year="2007"/>
          </front>
          <seriesInfo name="NIST Special Publication" value="800-56A"/>                    
       </reference>
               
      <reference anchor="SuiteB" target="http://www.nsa.gov/ia/programs/suiteb_cryptography/">
         <front>
            <title>Fact Sheet NSA Suite B Cryptography</title>
             <author>
                <organization> 
                   U.S. National Security Agency                   
                </organization>
             </author>
             
             <date month="January" year="2009"/>
          </front>
          <seriesInfo name="NIST Special Publication" value="800-56A"/>                    
       </reference>
                                                      
    </references>

  </back>
</rfc>
