<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4838 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4838.xml">
<!ENTITY RFC6257 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6257.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC7049 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7049.xml">
<!ENTITY RFC6255 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6255.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="std" docName="draft-birrane-dtn-scot-00" ipr="trust200902"
 obsoletes="" submissionType="IETF" updates="" xml:lang="en">
 <front>
  <title>Security Context Template </title>

  <author fullname="Edward J. Birrane, III" 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>

<author fullname="Sarah Heiner" initials="S.H."
   surname="Heiner">
   <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 240 592 3704</phone>
     <email>Sarah.Heiner@jhuapl.edu</email>
  </address>
</author>


<date month="July" day="10" year="2020"/>

<!-- Meta-data -->

<area>General</area>

<workgroup>Delay-Tolerant Networking</workgroup>

<keyword>security</keyword>
<keyword>context</keyword>


<abstract>
   <t>
      This document defines a standard template for security contexts 
      written for the Bundle Protocol Security Protocol (BPSec).
   </t>

</abstract>

</front>

<middle>

<section anchor="intro" title="Introduction" toc="default">
   
  <t>  
    The Bundle Protocol (BP) may operate in environments that prevent
    reliable synchronization of session information, to include
    negotiated cryptographic material. To accommodate for this possibility, 
    BP bundles may use extension blocks to carry annotative information. The
    Bundle Protocol Security Protocol (BPSec) defines security-related
    extension blocks (security blocks) to carry cryptographic material, to
    optionally include material that might otherwise be expected resident
    at communication endpoints. To accomplish these, BPSec security blocks
    specify a "security context" comprising the material generated for, 
    carried with, and/or otherwise utilized by the block.
  </t>

  <t>
    Where BPSec security blocks traverse networks for which a synchronized
    security mechanism exists, a security context can be defined which 
    minimally identifies endpoint information. For example, in networks 
    that support TLS, a security context can be defined to carry TLS
    record information after a successful TLS handshake has been used to
    synchronize state at the endpoints of the exchange. Alternatively, where 
    no such synchronizing security mechanisms exist, a security context
    can be defined which carries necessary configuration, cryptographic
    material, and policy. 
  </t>

  <t>
    The diversity of networks in which BP, and thus BPSec, may be deployed
    implies a diversity of network contexts in which security may be applied.
    For this reason, it is expected that multiple security contexts will be
    defined for BPSec security blocks, such that BPSec agents may select the 
    most suitable context. 

    This document defines a template for the documentation of security 
    contexts. This template includes Bundle Protocol (BP) reason codes,
    discrete events in the life-cycle of a security block, and policy actions 
    that may be taken by a bundle node when processing a security block.  
  </t>

  <section title="Specification Scope">

    <t>

      This document defines the information that must be addressed in the 
      definition of any BPSec security context specification. Specifically, this 
      document details the following information.

      <list style="symbols">

        <t>  
          Data specification requirements.
        </t>

        <t>
          Definitions and handling requirements for standard BP reason codes.
        </t>

        <t>
          Definitions and handling requirements for standard error codes.
        </t>

        <t>
          Guidance for specifying context-specific parameters and results.
        </t>

      </list>

      The SCoT addresses only that information necessary for the proper
      specification, interpretation, and processing of BPSec security blocks. 
      Any specific security protocol, cipher suite, or enumeration set other 
      than those defined by BP and BPSec are not considered part of this
      document. 
    </t>

  </section>

  <section anchor="reldoc" title="Related Documents" toc="default">

    <t>
       This document is best read and understood within the context of the 
       following other DTN documents:
    </t>

    <t>
      The Concise Binary Object Representation (CBOR) format <xref target="RFC7049"/>
      defines a data format that allows for small code size, fairly small
      message size, and extensibility without version negotiation.  The 
      block-specific-data associated with BPSec security blocks are encoded
      in this data format.
    </t>

    <t>
      The Bundle Protocol <xref target="I-D.ietf-dtn-bpbis"/> defines the 
      format and processing of bundles, defines the extension block format 
      used to represent BPSec security blocks, and defines the canonical block
      structure used by this specification.
    </t>


    <t>   
      The Bundle Security Protocol <xref target="I-D.ietf-dtn-bpsec"/> defines
      the BP extension blocks used to implement security services in a DTN.
      This also outlines the need for security contexts customized to the 
      networks in which BP and BPSec are deployed. 
    </t>

  </section>

  <section anchor="term" title="Terminology" toc="default">
      
    <t>
      This section defines terminology unique to the Security Context 
      Template. 

      Definitions of other terms specific to BP and BPSec, such as "Security Acceptor",
      "Security Block", "Security Context", Security Operation", "Security Service",
      "Security Source", and "Security Target" are as defined in BPSec
      <xref target="I-D.ietf-dtn-bpsec"/>. 
    </t>

  </section>

</section>


<section anchor="overview" title="System Overview">

  <t>
    This section describes how a security context is used by BPSec to 
    normalize the diversity of environments encountered by the Bundle Protocol. 
  </t>

  <section title="Methods of Establishing Context">

    <t>
      The definition of a security context is based in the concept that
      different networks would provide annotative security information in 
      different ways as a function of the capabilities of the network itself.
      This section discusses three general methods of generating context
      information: out-of-band, in-band, and a hybrid approach.
    </t>  

    <t>
      For each of these methods the term "in-band" refers to information
      carried within a bundle. 
    </t>

    <section title="Out-Of-Band Mode">

      <t>
        The Out-of-Band method of context establishment utilizes out-of-band 
        information only, requiring session information to be pre-shared. The 
        sending and receiving nodes must be configured using an out-of-band 
        method such as separate key management, one-time padding, or ID-based 
        encryption and use a pre-placed session key in order to establish 
        the context. 
      </t>

      <t>
        <figure title="In-Band Mode">
          <artwork align="center">&#xA;
      
+-------------+                                          +-------------+
|             |  (3)          +------------+         (4) |             |
|     BPA     |  -----------> |   bundle   | ----------> |     BPA     |
|             |               +------------+             |             |
+-------------+                                          +-------------+
| Convergence |                                          | Convergence |
|    Layer    |                                          |    Layer    |
+-------------+                                          +-------------+
       ^                                                        ^
       |                                                        |
       | (2)                                                    | (5)
       |                                                        |
       v                                                        v
  __________                                               __________
 /          \                                             /          \
 \__________/                                             \__________/ 
 |          |                   (1)                       |          |
 | Database | &lt;-----------------------------------------> | Database |
 \__________/                                             \__________/                    

          </artwork>
        </figure>   

      </t>

      <t>
        Step 1 shows the out-of-band configuration of both the sending and 
        receiving nodes. A session key is pre-placed in the databases accessible 
        by the nodes in step 1. Step 2 shows the sending node retrieving this 
        session key which is used in step 3 to add a security block to the bundle 
        which may transport a shared key between the sending and receiving nodes. 
        The bundle arrives at the receiving node in step 4, and the pre-placed 
        session key is retrieved in step 5. The session key can be used along 
        with the shared key to establish the context between the two nodes.
      </t>

    </section>

    <section title="In-Band Mode">
  
    <t>
      The In-Band method of context establishment utilizes in-band information 
      only. The key encryption key for both the sending and receiving node must be 
      pre-placed so that the node can fetch the information from its in-band 
      database. The session key and any additional information necessary to 
      establish the context is transported by the bundle. The receiving 
      node must use its pre-placed key-encryption-key in order to recover the 
      session key when the bundle is received.
    </t>

    <t>
      <figure title="In-Band Mode">
        <artwork align="center">&#xA;
      
+-------------+                                          +-------------+
|             |  (3)          +------------+         (4) |             |
|     BPA     |  -----------> |   Bundle   | ----------> |     BPA     |
|             |               +------------+             |             |
+-------------+                                          +-------------+
| Convergence |                                          | Convergence |
|    Layer    |                                          |    Layer    |
+-------------+                                          +-------------+
      ^                                                        ^
      |                                                        |
      | (2)                                                    | (5)
      |                                                        |        
      v                                                        v
  __________                                               __________
 /          \                                             /          \
 \__________/                                             \__________/ 
 |          |                                             |          |
 | Database |  (1)                                   (1)  | Database |
 \__________/                                             \__________/    

        </artwork>
      </figure>   
    </t>

    <t>
      Step 1 indicates that the key encryption key has been pre-placed at both the 
      sending and receiving node. The key encryption key is supplied to the 
      sending node in step 2, which then uses this key in step 3 to add a security 
      block to the bundle. This security block contains a session key and other 
      necessary security context parameters used to establish the context. The 
      bundle is received in step 4, and the key encryption key pre-placed at the 
      receiving node is fetched in step 5. The key encryption key is used to 
      recover the session key from the bundle, and the session key can be used to 
      retrieve the rest of the security results from the block.
    </t>

    </section>

    <section title="Hybrid Mode">

      <t>
        Using the Hybrid method of context establishment, both in-band and 
        out-of-band information is utilized. A session key is negotiated 
        out-of-band, while any additional information necessary to establish the 
        context is transported by the bundle.
      </t>

      <t>
        <figure title="Hybrid Mode">
          <artwork align="center">&#xA;
      
+-------------+                                          +-------------+ 
|             |  (3)          +------------+         (4) |             | 
|     BPA     |  -----------> |   Bundle   | ----------> |     BPA     | 
|             |               +------------+             |             | 
+-------------+                                          +-------------+ 
| Convergence |                                          | Convergence | 
|    Layer    | &lt;---------------------------------------&gt;|    Layer    | 
+-------------+                     (1)                  +-------------+ 
       ^                                                        ^ 
       |                                                        | 
       | (2)                                                    | (2) 
       |                                                        | 
       V                                                        V 
  __________                                               __________ 
 /          \                                             /          \ 
 \__________/                                             \__________/ 
 |          |                                             |          | 
 | Database |                                             | Database | 
 \__________/                                             \__________/

          </artwork>
        </figure>   
      </t>
      <t>
        Step 1 shows session establishment, performed by the convergence layer 
        of two BP nodes using in-band information including a negotiated session 
        key. At step 2, the session data is stored at both nodes in their 
        respective databases. The sending node adds a security block to the 
        bundle containing the information necessary to establish the context in 
        the form of security context parameters in step 3. Step 4 shows the 
        augmented bundle arriving at the receiving node. The receiving node can 
        then use the session data in its database (in-band information) and the 
        session information transmitted in the bundle as security context 
        parameters (out-of-band information).
      </t>
    </section>
  </section>

  <section title="Security Policy Roles">
    <t>
      A security context may be interpreted differently based on the role of the
      BPSec-aware node processing the security service. This section defines
      the roles associated with a security operation. 

      <list style="hanging" hangIndent="6">

        <t hangText="Security Source">
          <vspace/>
          A security source node must add the security service to the bundle 
          as specified by some policy. The bundle will first be inspected to 
          ensure that the newly required security block has not already been 
          added to the bundle. If it is determined that the required security 
          block is not already represented in the bundle, a new security block 
          is added and the specified security context is used to apply the 
          security service to each security target.
        </t>

        <t hangText="Security Verifier">
          <vspace/>
          A security verifier node must verify (not process) a security 
          service in the bundle as specified by the receiver security policy. 
          <vspace/>
          <vspace/>
          A security verifier will verify the integrity signature(s) stored as 
          security results of the BIB if the security service described by the 
          receiver security policy rule is integrity. 
          <vspace/>
          <vspace/>
          If policy identifies a BCB for which the node is a security verifier, 
          authenticity of the data belonging to the BCB's security targets is 
          verified. Some confidentiality security contexts may not support this 
          action, as the cipher suite(s) that they utilize do not expose an 
          authentication function. 
        </t>

        <t hangText="Security Acceptor">
          <vspace/>
          A security acceptor node must process a security service in the 
          bundle as specified by policy. In order to process a 
          security service, each security target belonging to the security 
          block must have its integrity verified and/or its contents decrypted.
        </t>
      </list>
    </t>
  </section>

<section title="Common Events and Actions">

  <t>
    This section describes the identification of common events and actions 
    associated with the processing of BPSec blocks at bundle nodes. Since
    these items are not specific to a single security context, they should
    be considered standard across all defined security contexts for BPSec.
  </t>

  <section title="Bundle Protocol Reason Codes">

    <t>
      This section describes a set of reason codes associated with the 
      processing of a bundle based on a security analysis performed by 
      a BPSec-aware BPA.
    </t>

    <t>
      Bundle protocol agents (BPAs) must process blocks and bundles in 
      accordance with both BP policy and BPSec policy. The decision to
      receive, forward, deliver, or delete a bundle may be communicated to
      the report-to address of the bundle, in the form of a status report, as a 
      method of tracking the progress of the bundle through the network. The
      status report for a bundle may be augmented with a "reason code" 
      explaining why the particular action was taken on the bundle. 
    
      <list style="hanging" hangIndent="6">

        <t hangText="Missing Security Service">
          <vspace/>
          This reason code indicates that a bundle was missing one or more 
          required security services. This reason code is used when a bundle is 
          received by a security verifier or security acceptor and is missing a 
          security service required by that verifier or acceptor.
        </t>

        <t hangText="Unknown Security Service">
          <vspace/>
          This reason code indicates that a security service present in a bundle
          cannot be understood by the security verifier or security acceptor of
          that service. For example, if a security service references a security
          context identifier, cipher suite name, or other parameter that is not
          known by the verifier/acceptor then the service cannot be processed and
          this reason code may be sent. This reason should not be sent by a node 
          that is not configured as a verifier or acceptor of the service. There 
          is no requirement that all BPSec-aware nodes in a network be able to 
          understand all security services in all bundles in the network. 
        </t>

        <t hangText="Unexpected Security Service">
          <vspace/>
          This reason code indicates that a BPSec-aware node received a bundle
          which contained more security services than expected. This is 
          typically used to indicate that a bundle contained a security service
          which was not required by the BPSec-aware node receiving the bundle.
          This reason code should not be seen as an error condition as it is 
          expected that BPSec-aware nodes will see security services
          in a bundle for which they are neither a verifier nor an acceptor. In
          certain networks, this reason code may be useful in identifying 
          misconfiguration in the network.
        </t>

        <t hangText="Failed Security Service">
          <vspace/>
          This reason code indicates that a BPSec-aware node was unable to 
          process an existing, known security service in a bundle. This may
          occur when a security-source is unable to add a required service to 
          a bundle. This may occur if a security service fails to verify at a 
          security verifier. This may occur is a security service fails to be
          processed at a security acceptor. 
        </t>

        <t hangText="Conflicting Security Services">
          <vspace/>
          This reason code indicates that a bundle received by a BPSec-aware
          node included a set of security services disallowed by the BPSec
          protocol and that security processing was unable to be proceed
          because of a BPSec protocol violation. 
        </t>
      </list>
    </t>
  </section>

  <section anchor="sec_events" title="Event Codes">
    <t>
      A life-cycle of a security operation within BPSec is independent of the 
      security context used to populate the contents of that security operation.
      However, security contexts must provide guidance on how a BPSec-aware
      node should react to these events for security operations using that
      context. 
    </t>

    <t>
      This section identifies the unique events in the life-cycle of a security
      operation that may identify processing points within a security context. 
    </t>

    <section  title="Security Source Events">
      <t>
        At a security source, three events may be associated with the security 
        operation as its life-cycle is initiated. 
      </t>

      <t>
        <list style="hanging" hangIndent="6">
          <t hangText="source_for_sop">
            <vspace/>
            When a node is designated as a security source for a security 
            operation, there is a security policy rule that requires the 
            security operation to be present in the bundle. When the sender 
            security policy rule that applies to the bundle is identified, the 
            security operation is acknowledged as needed. 
          </t>

          <t hangText="sop_added_at_source">
            <vspace/>
            A security operation is added when it is represented in the bundle 
            as a fully populated security block. In order for the security 
            operation to be considered as added, the security block must be 
            allocated for the bundle, represented in the bundle, and populated. 
            Population of a security block includes information provided by the 
            sender security policy rule and any security results associated with 
            the security operation. These security results must be calculated 
            and stored in either the security block or the security target 
            block's block-type-specific data.
          </t>

          <t hangText="sop_misconfigured_at_source">
            <vspace/>
            When a security operation is transitioning from being needed to 
            added, it may end up misconfigured. A security operation may be 
            misconfigured if resource exhaustion occurs and there is not 
            appropriate space to store a required security block or other 
            components of the security block. A security operation will also be 
            considered to be misconfigured if any of the required security 
            results cannot be successfully calculated.
          </t>
        </list>
      </t>
    </section> 

    <section title="Security Verifier Events">
      <t>
         At a security verifier, five events may be associated with the 
         security operation. 
      </t>

      <t>
        <list style="hanging" hangIndent="6">
          <t hangText="verifier_for_sop">
            <vspace/>
            A node is designated as a security verifier when a receiver security 
            policy rule is identified which is applicable to the current bundle 
            and is associated with the security verifier role. The security 
            operation described by the rule is then considered to be needed by 
            the security verifier node.
          </t>

          <t hangText="sop_misconfigured_at_verifier">
            <vspace/>
            A security operation may be identified as misconfigured by the 
            security verifier node. A misconfigured security operation may 
            encounter a resource allocation issue and be unable to add an 
            additional, required security result. A misconfigured security 
            operation may also identify an incorrect security context or 
            parameter, causing a conflict the security policy rule.
          </t>

          <t hangText="sop_missing_at_verifier">
            <vspace/>
            A security operation may transition from needed to missing if the 
            required security block cannot be located in the bundle by the 
            security verifier node.
          </t>

          <t hangText="sop_corrupted_at_verifier">
            <vspace/>
            A corrupted security operation is identified as a security block 
            which is unsuccessfully processed by the security verifier node. A 
            corrupted security operation indicates that the security target 
            cannot be verified.
          </t>

          <t hangText="sop_verified">
            <vspace/>
            When a security operation is designated as processed, the security 
            target has been successfully verified.
          </t>
        </list>
      </t>
    </section>

    <section title ="Security Acceptor Events">
      <t>
         At a security acceptor, five events may be associated with the 
         security operation. 
      </t>

      <t>
        <list style="hanging" hangIndent="6">
          <t hangText="acceptor_for_sop">
            <vspace/>
            A node is designated as a security acceptor when a receiver 
            security policy rule is identified that is both applicable to the 
            current bundle and associated with the security acceptor role. The 
            security operation described by the rule is then considered to be 
            needed by the security acceptor node.
          </t>

          <t hangText="sop_misconfigured_at_acceptor">
            <vspace/>
            A security operation may be identified as misconfigured by the 
            security acceptor node. A misconfigured security 
            operation signals an incorrect security context or 
            parameter, causing a conflict the security policy rule.
          </t>

          <t hangText="sop_missing_at_acceptor">
            <vspace/>
            A security operation is missing if the required security block 
            cannot be located in the bundle by the security acceptor node.
          </t>

          <t hangText="sop_corrupted_at_acceptor">
            <vspace/>
            A corrupted security operation is identified as a security block 
            which is unsuccessfully processed by the security acceptor node. A 
            corrupted security operation indicates that the security target 
            cannot be verified and/or decrypted.
          </t>

          <t hangText="sop_processed">
            <vspace/>
            When a security operation is designated as processed, the security 
            target has been successfully verified and/or decrypted and is 
            removed from the bundle.
          </t>

        </list>
      </t>
    </section>
  </section>

  <section anchor="proc_act" title="Processing Actions">

    <t>
      This section defines a standard set of processing actions that can be
      specified when defining the policy associated with a security
      context. The benefit of enumerating these actions is to provide a common
      set of terminology and design across multiple security contexts with
      the purpose of making the development of multi-security-context
      BPSec implementations as similar as possible.
    </t>

    <t>
      In particular, a security context may wish to override how a BPSec 
      implementation treats the block processing control flags associated
      with a security block and/or its target block using that context. While
      the creator of a target block may set block processing flags it may be
      insecure to process the block in accordance with those flags. Similarly,
      if a target block has been modified since its was created, it is possible
      that the target block's processing flags have also been modified and
      should not necessarily be honored by a receiving BPA.
    </t>

    <t>
      A security context should specify the situations in which the following
      actions should be taken by a BPSec implementation at a BPSec-aware
      node in the network.
    </t>

    <t>
      <list style="hanging" hangIndent="6">
        <t hangText="remove_sop">
          <vspace/>
          When the security operation is removed, it is no longer required for 
          that bundle. If the security operation is the only operation 
          represented by the security block, the block must be removed from the 
          bundle. Otherwise, the security target's block number is removed from 
          the security block to indicate that the particular operation no 
          longer applies.
        </t>

        <t hangText="remove_sop_target">
          <vspace/>
          Remove security operation's security target and the security 
          operations associated with that target - The security operation's 
          security target is removed from the bundle, as are any additional 
          security operations associated with that target. For example, if the 
          target block of a confidentiality service is removed, the integrity 
          security operation for that target would be removed as well.
        </t>

        <t hangText="remove_all_target_sops">
          <vspace/>
          Remove all security operations for the security target - This option 
          is used to remove all of the security operations associated with the 
          security target while retaining the security target in the bundle.
        </t>

        <t hangText="do_not_forward">
          <vspace/>
          Selecting this option will end bundle transmission at the current 
          node, regardless of bundle destination. 
        </t>

        <t hangText="request_storage">
          <vspace/>
          This option is paired with 'Do Not Forward 
          Bundle' in order to retain a copy of the bundle at the current node. 
          Bundle storage cannot be guaranteed, as node resources are unknown at 
          the time of bundle transmission, but selecting this option will result 
          in an effort to retain a copy of the bundle at the node.
        </t>

        <t hangText="report_reason_code(code)">
          <vspace/>
          Generate a status report describing the treatment of the bundle and
          use the provided reason code as the reason.
        </t>
          

        <t hangText="override_target_bpcf(mask, new_values)">
          <vspace/>
          Override one or more block processing control flags of the the target 
          block and process the block in accordance with the overridden flags. 
          The overridden flags MUST NOT be written back to the target block,
          and only used for processing the block locally. 
          <vspace/>
          <vspace/>
          Manipulating individual flags to be forced to 0, forced to 1, or kept 
          as specified in the target block requires two inputs. This can be
          accomplished by the operation:
          <vspace/>
          <vspace/>
          local_flags = (block_flags &amp; mask) | (~mask &amp; values)
        </t>

        <t hangText="override_sop_bpcf(mask, new_values)">
          <vspace/>
          Override one or more block processing control flags of the security
          block associated with the sop and process the block in accordance with 
          the overridden flags. The overridden flags MUST NOT be written back to 
          the security block, and only used for processing the block locally. 
          <vspace/>
          <vspace/>
          Manipulating individual flags to be forced to 0, forced to 1, or kept 
          as specified in the target block requires two inputs. This can be
          accomplished by the operation:
          <vspace/>
          <vspace/>
          local_flags = (block_flags &amp; mask) | (~mask &amp; values)
        </t>
      </list>
    </t>
  </section>

</section>


<section anchor="policy" title="Security Policy Considerations" toc="default">
  <t>
    A security context details the environment in which cryptographic
    materials are provided to, and retrieved from, the cipher suites used for
    security services in the network. For this reason, the policy associated
    with determining proper configuration information must be addressed in the
    specifications defining new security contexts because this information
    may differ amongst security contexts.
  </t>

  <t>
    This section identifies several policy questions that should be addressed
    in the specification of a security context. In the absence of guidelines
    for a specific security context, this section defines what should be
    considered default behavior for any security context.
  </t>

  <t>
    <list style="hanging" hangIndent="6">
      <t hangText="Target Block Identification">
        <vspace/>
        Security contexts should define how a target block of a security
        service should be identified. This identification is used when
        determining whether to add a security block at a security source,
        whether to check a security block at a verifier, and whether a node
        should consider itself the acceptor of the block.
        <vspace/>
        <vspace/>
        DEFAULT BEHAVIOR: Unless otherwise specified, a
        target block MUST be identified at a security source by the three-tuple
        of {bundle source EID, bundle destination EID, and block type of
        the target block}.  A target block at a security verifier and a
        security acceptor is identified by these three information elements 
        plus the security context identifier. 
      </t>

      <t hangText="Security Parameter Local Overrides">
        <vspace/>
        Security contexts should define the circumstances in which a local
        BPSec-aware node may override parameters in a security block with 
        locally-configured parameters. 
        <vspace/>
        <vspace/>
        DEFAULT BEHAVIOR: Unless otherwise specified, a locally-provided
        security parameter MUST NOT override a security parameter present in 
        a security block. A local parameter can only be used in cases where the
        corresponding parameter is not present in the security block itself. 
      </t>      

      <t hangText="Security Processing Actions">
        <vspace/>
        Security contexts should define the circumstances in which the
        processing actions defined in <xref target="proc_act"/> should be
        used and with what inputs. 
        <vspace/>
        <vspace/>
        DEFAULT BEHAVIOR: Unless otherwise specified, the local, BPSec-aware
        node MUST enforce policy actions as a function of some local policy
        definition at the node itself. This may be through the definition of
        generic actions for all security contexts or it may be identified
        based on a specific security context. 
      </t>
    </list>
  </t>

</section>

  
<section anchor="def_sec_context" title="Security Context Template" toc="default">

  <t>
    This section defines a recommended outline for the definition of a 
    security context for BPSec. The purpose of such an outline is to both
    ensure that no critical information is omitted when authoring new
    security contexts and to reduce the cognitive load associated with 
    implementing new security contexts by having them confirm to a standard
    representation. 
  </t>

  <t>
    A security context specification should include the following elements.

    <list style="numbers">
      <t> Overview </t>
      <t> Interfaces</t>
      <t> Definitions </t>
      <t> Canonicalization Algorithms </t>
      <t> Processing </t>
      <t> Policy</t>
      <t> IANA Considerations </t>
    </list>

    A single specification may define one or more security contexts, in which
    case this information would be repeated for each security context.
  </t>

  <t> 
    The remainder of this section provides information on the topics that
    should be covered in each of these sections.
  </t>

  <section title="Overview">
    <t>
      This section should identify the rationale for creating a security
      context, whether the context uses in-band, out-of-band, or hybrid
      mechanisms for information exchange, and the unique situations in which
      the context should be used. 
    </t>
  </section>

  <section title="Interfaces">
    <t>
      Security context interfaces detail any special considerations or
      assumptions made when designing the algorithms for creating or otherwise
      processing the contents of security blocks.       
    </t>

    <section title="Information Provided to the Cipher Suite">
      <t>
        This section should identify how the security context interfaces with 
        the cipher suite (or cipher suites) used to process the security 
        service. This may be as simple as providing parameters from the 
        security block to a cipher suite implementation. This may also be a 
        more complex interface involving fusing parameter information 
        carried by the security block with local information to provide an 
        interface to the cipher suite.
      </t>
      <t>
        A cipher suite may include parameters such as a key length, mode, or 
        number of rounds, which is part of the cipher suite definition. These 
        parameters are considered "locked" parameters and are not to be 
        confused with the "free" parameters that the user may define for each 
        security context. Where not already defined by the cipher suite
        itself, the security context should clearly identify which 
        parameters should be considered "free" and which should be
        considered "locked". 
      </t>
      <t>
        In addition to listing cipher suites, this section should identify
        information relating to all "free" cipher suite parameters. This may
        include selected bit lengths, which parameters are provided by the
        local node, which parameters must be present in the security block
        itself, and how parameters should be protected when represented in 
        a security block. 
      </t>
    </section>

    <section title="Information Provided by the BPA">

      <t>
        A security context specification should describe the information it 
        expects to be provided to it by the local BPA, separate from the 
        contents of the security block and target block from the bundle. 
      </t>

      <t>
        For example, a BPA may additionally provide local the security context 
        parameters.
      </t>
    </section>

    <section title="Information Provided to the BPA">

      <t>
        A security context specification should describe the information that
        it will provide back to the local BPA. Typically this is either the
        output of a cipher suite to be added to a security block in a bundle,
        or some signal for a process event associated with a verification or
        processing action. 
      </t>

    </section>
  </section>

  <section title="Definitions">
    <t>
      This section defines custom parameters and results associated with the
      security context and carried either within a security block or as
      part of local node configuration. 
    </t>

    <t>
      Each security context parameters and result is defined as a key-value 
      pair, where the key is a CBOR-encoded integer and the value is defined as 
      the CBOR encoding of its data type. This section must define any unique
      parameters and results used by the security context, to include the
      following information.

      <list style="symbols">
        <t> 
          The integer identifier of the parameter or result item. 
        </t>
        <t> 
          Whether multiple instances of this item can be present in a 
          security block at one time, and whether at least one instance
          of this item is required to be defined. 
        </t>
        <t>
          Whether this item must be present only in the security block, or
          whether it can also be included as part of the configuration of a
          local node, and how to determine which version of the item to use
          in the event that it is defined in both the security block and the
          local node. 
        </t>
        <t>
          The data type of the item and how that data type must be CBOR 
          encoded for representation in the security block.
        </t>
      </list>
    </t>
  </section>

  <section title="Canonicalization Algorithms">
    <t>
      Security context canonicalization algorithms take precedence over any others defined.
      The exact data and its form when provided to the canonicalization algorithm must be 
      determined by the security context.
    </t>

    <t>
      Consistency and determinism of the block-type-specific data provided as input to the 
      security context is critical for security services to function as expected.
    </t>
  </section>

  <section title="Processing">
    <t>
        A security context specification should describe how the context should
        be used to perform every processing action described in <xref target="sec_events"/>. 
    </t>
  </section>

  <section title="Policy">
    <t>
        A security context specification should describe how the context should
        be configured from a policy perspective. This should include, at a
        minimum, under which circumstances each policy action identified in
        <xref target="proc_act"/> should be taken.
    </t>
  </section>

  <section title="IANA Considerations">
      <t>
        Each security context MUST provide an entry in the IANA security context 
        identifier registry to uniquely identify the identifiers of each
        security context. 
      </t>
  </section>

</section>
</section>

</middle>


<back>
  
  <references title="Normative References">

    &RFC7049;    

    <?rfc include="reference.I-D.draft-ietf-dtn-bpbis-25"?>
    <?rfc include="reference.I-D.draft-ietf-dtn-bpsec-22"?>

  </references>
 
</back>

</rfc>



















