One document matched: draft-irtf-dtnrg-bundle-security-11.xml
<?xml version="1.0" encoding="utf-8"?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc comments="yes"?>
<?rfc sortrefs="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="pre5378Trust200902" docName="draft-irtf-dtnrg-bundle-security-11">
<front>
<title abbrev="Bundle Security Protocol"> Bundle Security Protocol Specification </title>
<author initials="S.F." surname="Symington" fullname="Susan Flynn Symington">
<organization>The MITRE Corporation</organization>
<address>
<postal>
<street>7515 Colshire Drive</street>
<city>McLean</city>
<region>VA</region>
<code>22102</code>
<country>US</country>
</postal>
<phone>+1 (703) 983-7209</phone>
<email>susan@mitre.org</email>
<uri>http://mitre.org/</uri>
</address>
</author>
<author initials="S." surname="Farrell" fullname="Stephen Farrell">
<organization>Trinity College Dublin</organization>
<address>
<postal>
<street>Distributed Systems Group</street>
<street>Department of Computer Science</street>
<street>Trinity College </street>
<city>Dublin</city>
<code>2</code>
<country>Ireland</country>
</postal>
<phone>+353-1-608-1539</phone>
<email>stephen.farrell@cs.tcd.ie</email>
</address>
</author>
<author initials="H." surname="Weiss" fullname="Howard Weiss">
<organization>SPARTA, Inc.</organization>
<address>
<postal>
<street>7110 Samuel Morse Drive</street>
<city>Columbia</city>
<region>MD</region>
<code>21046</code>
<country>US</country>
</postal>
<phone>+1-443-430-8089</phone>
<email>hsw@sparta.com</email>
</address>
</author>
<author initials="P." surname="Lovell" fullname="Peter Lovell">
<organization>SPARTA, Inc.</organization>
<address>
<postal>
<street>7110 Samuel Morse Drive</street>
<city>Columbia</city>
<region>MD</region>
<code>21046</code>
<country>US</country>
</postal>
<phone>+1-443-430-8052</phone>
<email>peter.lovell@sparta.com</email>
</address>
</author>
<date year="2009"/>
<area>Security</area>
<workgroup>DTN Research Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>DTN</keyword>
<keyword>Delay-Tolerant Networking</keyword>
<keyword>Disruption-Tolerant Networking</keyword>
<abstract>
<t>This document defines the bundle security protocol, which provides data
integrity and confidentiality services for the bundle protocol.
Separate capabilities are provided to protect the bundle payload and
additional data that may be included within the bundle. We also describe
various bundle security considerations including policy options. </t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in <xref target="RFC2119"/>.</t>
<t>This document defines security features for the bundle protocol
<xref target="DTNBP"/> intended for use in delay tolerant networks,
in order to provide DTN security services.</t>
<t>The bundle protocol is used in DTNs which overlay multiple networks, some of
which may be challenged by limitations such as intermittent and possibly
unpredictable loss of connectivity, long or variable delay, asymmetric data
rates, and high error rates. The purpose of the bundle protocol is to support
interoperability across such stressed networks. The bundle protocol is layered
on top of underlay-network-specific convergence layers, on top of
network-specific lower layers, to enable an application in one network to
communicate with an application in another network, both of which are spanned
by the DTN. </t>
<t>Security will be important for the bundle protocol. The stressed environment
of the underlying networks over which the bundle protocol will operate makes it
important for the DTN to be protected from unauthorized use, and this stressed
environment poses unique challenges for the mechanisms needed to secure the
bundle protocol. Furthermore, DTNs may very likely be deployed in environments
where a portion of the network might become compromised, posing the usual
security challenges related to confidentiality, integrity and availability.</t>
<t>Different security processing applies to the payload and extension
blocks that may accompany it in a bundle, and different rules apply to
various extension blocks.</t>
<t>This document describes both the base Bundle Security Protocol (BSP) and
a set of mandatory ciphersuites. A ciphersuite is a specific collection of
various cryptographic algorithms and implementation rules that are used
together to provide certain security services.</t>
<t>The Bundle Security Protocol applies, by definition, only to those nodes
that implement it, known as "security-aware" nodes. There MAY be other nodes
in the DTN that do not implement BSP. All nodes can interoperate with the
exception that BSP security operations can only happen at security-aware nodes. </t>
<section title="Related Documents" toc="default">
<t>This document is best read and understood within the context of the
following other DTN documents: </t>
<t> <list>
<t>The Delay-Tolerant Network Architecture <xref target="DTNarch"/>
defines the architecture for delay-tolerant networks, but does not
discuss security at any length. </t>
<t>The DTN Bundle Protocol <xref target="DTNBP"/> defines the format
and processing of the blocks used to implement the bundle protocol,
excluding the security-specific blocks defined here. </t>
</list> </t>
</section>
<section title="Terminology" toc="default">
<t> We introduce the following terminology for purposes of clarity: </t>
<t> <list>
<t>source - the bundle node from which a bundle originates</t>
<t>destination - the bundle node to which a bundle is ultimately destined</t>
<t>forwarder - the bundle node that forwarded the bundle on its most recent
hop</t>
<t>intermediate receiver or "next hop" - the neighboring bundle node to which a forwarder
forwards a bundle.</t>
<t>path - the ordered sequence of nodes through which a bundle passes on its way from
source to destination</t>
</list> </t>
<t>In the figure below, which is adapted from figure 1 in the Bundle Protocol Specification,
four bundle nodes (denoted BN1, BN2, BN3, and BN4) reside above
some transport layer(s). Three distinct transport and network protocols
(denoted T1/N1, T2/N2, and T3/N3) are also shown.</t>
<figure anchor="protocolStack">
<preamble> </preamble>
<artwork>
+---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+
| BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 |
+---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+
| T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 |
+---------v-+ +-^---------v-+ +-^---------v + +-^---------+
| N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 |
+---------v-+ +-^---------v + +-^---------v-+ +-^---------+
| >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ |
+-----------+ +------------+ +-------------+ +-----------+
| | | |
|<-- An Internet --->| |<--- An Internet --->|
| | | |
BN = "Bundle Node" (as defined in the Bundle Protocol Specification
</artwork>
<postamble>
Bundle Nodes Sit at the Application layer of the Internet Model.
</postamble>
</figure>
<t>Bundle node BN1 originates a bundle that it forwards to BN2. BN2 forwards
the bundle to BN3, and BN3 forwards the bundle to BN4. BN1 is the source of the
bundle and BN4 is the destination of the bundle. BN1 is the first forwarder, and
BN2 is the first intermediate receiver; BN2 then becomes the forwarder, and BN3 the
intermediate receiver; BN3 then becomes the last forwarder, and BN4 the last intermediate
receiver, as well as the destination. </t>
<t>If node BN2 originates a bundle (for example, a bundle
status report or a custodial signal), which is then forwarded on to BN3, and
then to BN4, then BN2 is the source of the bundle (as well as being the first
forwarder of the bundle) and BN4 is the destination of the bundle (as well as
being the final intermediate receiver). </t>
<t>
We introduce the following security-specific DTN terminology:
</t>
<t> <list>
<t>security-source - a bundle node that adds a security block to a bundle</t>
<t>security-destination - a bundle node that processes a security block of a
bundle</t>
<t>security path - the ordered sequence of security-aware nodes theough which a
bundle passes on its way from the security-source to the security-destination</t>
</list> </t>
<t>Referring to <xref target="protocolStack"/> again:</t>
<t>If the bundle that originates at BN1 as source is given a security block by BN1,
then BN1 is the security-source of this bundle with
respect to that security block, as well as being the source of the bundle. </t>
<t>If the bundle that originates at BN1 as source is given a security block by BN2,
then BN2 is the security-source of this bundle with
respect to that security block, even though BN1 is the source. </t>
<t>If the bundle that originates at BN1 as source is given a security block
by BN1 that is intended to be processed by BN3, then BN1 is the
security-source and BN3 is the security destination with respect to this security
block. The security path for this block is BN1 to BN3. </t>
<t>A bundle MAY have multiple security blocks. The security-source of a bundle with
respect to a given security block in the bundle MAY be the same as or different from
the security-source of the bundle with respect to a different security block in the bundle.
Similarly, the security-destination of a bundle with respect to each of that bundle's
security blocks MAY be the same or different. Therefore the security paths for
various blocks MAY be and often will be different.</t>
<t>If the bundle that originates at BN1 as source is given a security block
by BN1 that is intended to be processed by BN3, and BN2 adds a security block
with security-destination BN4, the security paths for the two blocks overlap
but not completely. This problem is discussed further in
<xref target="sec.sz"/>. </t>
<t>As required in <xref target="DTNBP"/>, forwarding nodes MUST transmit blocks in
a bundle in the same order in which they were received.
This requirement applies to all dtn nodes, not just ones which implement security
processing. Blocks in a bundle MAY be added or deleted according to the applicable
specification, but those blocks which are both received and transmitted MUST be
transmitted in the same order that they were received.</t>
<t>If a node is not security-aware then it forwards the security blocks unchanged
in the bundle. The non-security-aware nodes are transparent relay points and are
invisible as far as security processing is concerned. </t>
<t>The block sequence also indicates the order in which certain significant actions
have affected the bundle, and therefore the sequence in which actions MUST occur
in order to produce the bundle at its destination. </t>
</section>
</section>
<section title="Security Blocks" toc="default" anchor="Headers">
<t>There are four types of security block that MAY be included in a bundle.
These are the Bundle Authentication Block (BAB), the Payload Integrity Block (PIB),
the Payload Confidentiality Block (PCB) and the Extension Security Block (ESB).</t>
<t> <list>
<t>The BAB is used to assure the authenticity and integrity of the bundle
along a single hop from forwarder to intermediate receiver. This is actually
from a security-aware forwarder to the next security-aware intermediate receiver
and could be more than one actual hop.</t>
<t>The PIB is used to assure the authenticity and integrity of the payload from
the PIB security-source, which creates the PIB, to the PIB security-destination,
which verifies the PIB authenticator. The authentication information in the
PIB MAY (if the ciphersuite allows) be verified by any node in between
the PIB security-source and the PIB security-destination that has access to the
cryptographic keys and revocation status information required to do so. </t>
<t>Since a BAB protects a bundle on a "hop-by-hop" basis and other security
blocks MAY be protecting over several hops or end-to-end, whenever both are
present the BAB MUST form the "outer" layer of protection - that is, the
BAB MUST always be calculated and added to the bundle after all other
security bloacks have been calculated and added to the bundle.</t>
<t>The PCB indicates that the payload has been encrypted, in whole or in part,
at the PCB security-source in order to protect the bundle content while
in transit to the PCB security-destination.</t>
<t>PIB and PCB protect the payload and are regarded as "payload-related"
for purposes of the security discussion in this document. Other blocks are
regarded as "non-payload" blocks. Of course, the primary block is
unique and has separate rules.</t>
<t>The ESB provides security for non-payload blocks in a bundle.
ESB therefore is not applied to PIB or PCBs, and of course is not
appropriate for either the payload block or primary block.</t>
</list> </t>
<t>Each of the security blocks uses the Canonical Bundle Block Format as
defined in the Bundle Protocol Specification. That is, each security block is
comprised of the following elements:</t>
<t> <list>
<t>- Block type code</t>
<t>- Block processing control flags</t>
<t>- Block EID reference list (optional)</t>
<t>- Block data length</t>
<t>- Block-type-specific data fields</t>
</list> </t>
<t> Since the four security blocks have most fields in common, we can shorten
the description of the Block-type-specific data fields of each security block
if we first define an abstract security block (ASB) and then specify each of
the real blocks in terms of the fields which are present/absent in an ASB.
Note that no bundle ever contains an actual ASB, which is simply a specification
artifact.</t>
<section title="Abstract Security Block" toc="default" anchor="asb">
<t>An ASB consists of the following mandatory and optional fields:</t>
<t> <list>
<t>- Block-type code (one byte) - as in all bundle protocol blocks except the
primary bundle block. The block types codes for the security blocks are:</t>
<t> <list>
<t>BundleAuthenticationBlock - BAB: 0x02</t>
<t>PayloadIntegrityBlock - PIB: 0x03</t>
<t>PayloadConfidentialityBlock - PCB: 0x04</t>
<t>ExtensionSecurityBlock - ESB: 0x09</t>
</list> </t>
<t>- Block processing control flags (SDNV) - defined as in all bundle protocol
blocks except the primary bundle block (as described in the Bundle Protocol
<xref target="DTNBP"/>). SDNV encoding is described
in the bundle protocol. There are no general constraints on the use of the block
processing flags, and some specific requirements are discussed later.</t>
<t>- EID references - composite field defined in <xref target="DTNBP"
format="default" pageno="false"/> containing references to one or two EIDs.
Presence of the EID-reference field is indicated by the setting of the
"block contains an EID-reference field" (EID_REF) bit
of the block processing control flags. If one or more references is present,
flags in the ciphersuite ID field, described below, specify which.</t>
<t>If no EID fields are present then the composite field itself is
omitted entirely, rather than containing a count field of zero, since
such a representation is not permitted. The EID_REF bit is not set.</t>
<t>The possible EIDs are:-</t>
<t> <list>
<t>- (optional) Security-source - specifies the security source for the
block. If this is omitted, then the source of the bundle is assumed to be the
security-source.</t>
<t>- (optional) Security-destination - specifies the security destination for
the block. If this is omitted, then the destination of the bundle is assumed
to be the security-destination.</t>
</list> </t>
<t>If two EIDs are present, security-source is first and security-destination
comes second.</t>
<t>- Block data length (SDNV) - as in all bundle protocol blocks except the
primary bundle block. SDNV encoding is described in the bundle protocol.</t>
<t>- Block-type-specific data fields as follows:</t>
<t> <list>
<t>- Ciphersuite ID (SDNV)</t>
<t>- Ciphersuite flags (SDNV)</t>
<t>- (optional) Correlator - when more than one related block is inserted
then this field MUST have the same value in each related block instance.
This is encoded as an SDNV. See note in <xref target="frag"/>
with regard to correlator values in bundle fragments.</t>
<t>- (optional) Ciphersuite parameters - compound field of next two items</t>
<t> <list>
<t>- Ciphersuite parameters length - specifies the length of the following
Ciphersuite parameters data field and is encoded as an SDNV. </t>
<t>- Ciphersuite parameters data - parameters to be used with the
ciphersuite in use, e.g. a key identifier or initialization vector (IV).
See <xref target="sec.PRF"/> for a list of potential parameters and their
encoding rules. The particular set of parameters that are included in this
field are defined as part of the ciphersuite specification.</t>
</list> </t>
<t>- (optional) Security result - compound field of next two items</t>
<t> <list>
<t>- Security result length - contains the length of the next field and is encoded
as an SDNV.</t>
<t>- Security result data - contains the results of the appropriate
ciphersuite-specific calculation (e.g. a signature, MAC or ciphertext block
key).</t>
</list> </t>
</list> </t>
</list> </t>
<figure anchor="ASBdiagram">
<preamble>
</preamble>
<artwork>
+----------------+----------------+----------------+----------------+
| type | flags (SDNV) | EID ref list(comp) |
+----------------+----------------+----------------+----------------+
| length (SDNV) | ciphersuite (SDNV) |
+----------------+----------------+----------------+----------------+
| ciphersuite flags (SDNV) | correlator (SDNV) |
+----------------+----------------+----------------+----------------+
|params len(SDNV)| ciphersuite params data |
+----------------+----------------+----------------+----------------+
|res-len (SDNV) | security result data |
+----------------+----------------+----------------+----------------+
</artwork>
<postamble>The structure of an abstract security block
</postamble>
</figure>
<t>Some ciphersuites are specified in <xref target="ciphersuites"/>,
which also specifies the rules which MUST be
satisfied by ciphersuite specifications. Additional ciphersuites MAY be
defined in separate specifications. Ciphersuite IDs not specified are reserved.
Implementations of the bundle security protocol decide which ciphersuites to
support, subject to the requirements of <xref target="ciphersuites"/>.
It is RECOMMENDED that implementations that allow additional ciphersuites permit
ciphersuite ID values at least up to and including 127, and they MAY decline to
allow larger ID values. </t>
<t>The structure of the ciphersuite flags field is shown in
<xref target="CIDFig"/>. In each case the presence of an optional
field is indicated by setting the value of the corresponding flag to one. A value of
zero indicates the corresponding optional field is missing. Presently there are
five flags defined for the field and for convenience these are shown as they would
be extracted from a single-byte SDNV. Future additions may cause the field to grow
to the left so, as with the flags fields defined in <xref target="DTNBP"/>,
the description below numbers the bit positions from the right rather than
the standard RFC definition which numbers bits from the left. </t>
<t> <list>
<t>src - bit 4 indicates whether the EID-reference
field of the ASB contains the optional reference to the security-source.</t>
<t>dest - bit 3 indicates whether the EID-reference
field of the ASB contains the optional reference to the security-destination.</t>
<t>parm - bit 2 indicates whether the ciphersuite-parameters-length and ciphersuite
parameters data fields are present or not. </t>
<t>corr - bit 1 indicates whether or not the ASB contains an optional
correlator.</t>
<t>res - bit 0 indicates whether or not the ASB contains the
security result length and security result data fields.</t>
<t>bits 5-6 are reserved for future use. </t>
</list> </t>
<figure anchor="CIDFig">
<preamble>
</preamble>
<artwork>
Ciphersuite flags
Bit Bit Bit Bit Bit Bit Bit
6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+
| reserved |src |dest |parm |corr |res |
+-----+-----+-----+-----+-----+-----+-----+
</artwork>
</figure>
<t>A little bit more terminology: if the block is a PIB then when we refer to the
"PIB-source", we mean the security source for the PIB as represented by the
EID reference in the EID-references field. Similarly we may refer to the PCB-dest,
meaning the security-destination of the PCB, again as represented by an EID reference.
For example, referring to <xref target="protocolStack"/>
again, if the bundle that originates at BN1 as source is given a Confidentiality Block
(PCB) by BN1 that is protected using a key held by BN3 and it is given a Payload Integrity
Block (PIB) by BN1, then BN1 is both the PCB-source and the PIB-source of the bundle,
and BN3 is the PCB-dest of the bundle.</t>
<t>The correlator field is used to associate several related instances of a
security block. This can be used to place a BAB that contains the ciphersuite information
at the "front" of a (probably large) bundle, and another correlated BAB that contains the
security result at the "end" of the bundle. This allows even very memory-constrained nodes to
be able to process the bundle and verify the BAB. There are similar
use cases for multiple related instances of PIB and PCB as will be seen below.</t>
<t>The ciphersuite specification MUST make it clear whether or not
multiple block instances are allowed, and if so, under what conditions. Some
ciphersuites can of course leave flexibility to the implementation,
whereas others might mandate a fixed number of instances.</t>
<t>For convenience, we use the term "first block" to refer to the initial block
in a group of correlated blocks, or to the single block if there are no others
in the set. Obviously there can be several unrelated groups in a bundle, each
containing only one block or more than one, and each has its own "first block".
</t>
</section>
<section title="Bundle Authentication Block" toc="default" anchor="sec.BAB">
<t>In this section we describe typical BAB field values for two scenarios -
where a single instance of the BAB contains all the information and where two related
instances are used, one "up front" which contains the ciphersuite and another
following the payload which contains the security result (e.g. a MAC).</t>
<t>For the case where a single BAB is used:</t>
<t> <list>
<t>The block-type code field value MUST be 0x02.</t>
<t>The block processing control flags value can be set to whatever values are
required by local policy.
Ciphersuite designers should carefully consider the
effect of setting flags that either discard the block or delete the bundle
in the event that this block cannot be processed.</t>
<t>The ciphersuite ID MUST be documented as a hop-by-hop
authentication-ciphersuite which requires one instance of the BAB.</t>
<t>The correlator field MUST NOT be present.</t>
<t>The ciphersuite parameters field MAY be present, if so specified in the
ciphersuite specification.</t>
<t>An EID reference to the security-source MAY be present and, if so,
it MUST identify the forwarder of the bundle. The security-source can
also be specified as part of key information described in
<xref target="sec.PRF"/> or another block such as the Previous Hop
Insertion Block. The security-source might also be inferred from
some implementation-specific means such as the convergence layer.</t>
<t>An EID reference to the security-destination MAY be present
and is useful to ensure that the bundle has been forwarded
to the correct next-hop node.</t>
<t>The security result MUST be present as it is effectively the "output" from
the ciphersuite calculation (e.g. the MAC or signature) applied to the
(relevant parts of) the bundle (as specified in the ciphersuite definition).
</t>
</list> </t>
<t>For the case using two related BAB instances, the first instance is as defined
above, except the ciphersuite ID MUST be documented as a hop-by-hop authentication
ciphersuite that requires two instances of the BAB. In addition, the correlator MUST
be present and the security result length and security result fields MUST be
absent. The second instance of the BAB MUST have the same correlator value
present and MUST contain security result length and security result data fields.
The other optional fields MUST NOT be present.
Typically, this second instance of a BAB will be the last block of the bundle.</t>
<t>The details of key transport for BAB are specified by the particular
ciphersuite. In the absence of conflicting requirements, the following
should be noted by implementors: </t>
<t> <list>
<t>the key information item <xref target="sec.PRF"/> is optional, and if not
provided then the key should be inferred from the source-destination tuple,
being the previous key used, a key created from a key-derivation function,
or a pre-shared key</t>
<t>since BAB is for a single hop, by definition, the capabilities of the
underlying convergence layer might be useful for key transport</t>
<t>depending upon the key mechanism used, bundles can be signed by the sender,
or authenticated for one or more recipients, or both. </t>
</list> </t>
</section>
<section title="Payload Integrity Block" toc="default" anchor="sec.PIB">
<t>A PIB is an ASB with the following additional restrictions:</t>
<t> <list>
<t>The block type code value MUST be 0x03.</t>
<t>The block processing control flags value can be set to whatever values are
required by local policy. Ciphersuite designers should carefully consider the
effect of setting flags that either discard the block or delete the bundle
in the event that this block cannot be processed.</t>
<t>The ciphersuite ID MUST be documented as an end-to-end
authentication-ciphersuite or as an end-to-end error-detection-ciphersuite.
</t>
<t>The correlator MUST be present if the ciphersuite requires more than
one related instance of a PIB be present in the bundle. The correlator MUST NOT be
present if the ciphersuite only requires one instance of the PIB in the
bundle.</t>
<t>The ciphersuite parameters field MAY be present.</t>
<t>An EID reference to the security-source MAY be present.</t>
<t>An EID reference to the security-destination MAY be present.</t>
<t>The security result is effectively the "output" from the ciphersuite
calculation (e.g. the MAC or signature) applied to the (relevant parts of) the
bundle. As in the case of the BAB, this field MUST be present if the correlator
is absent. If more than one related instance of the PIB is required then this is
handled in the same way as described for the BAB above.</t>
<t>The ciphersuite MAY process less than the entire original bundle payload,
either because the current payload is a fragment of the original bundle or
just becuase it is defined to process some subset. For whatever reason,
if the ciphersuite processes less than the complete, original bundle payload,
the ciphersuite parameters of this block MUST specify which bytes of the
bundle payload are protected. </t>
</list> </t>
<t>For some ciphersuites, (e.g. those using asymmetric keying to produce
signatures or those using symmetric keying with a group key), the security
information can be checked at any hop on the way to the security destination
that has access to the required keying information. This possibility is
further discussed in <xref target="sec.bon"/> below. </t>
<t>The use of a generally-available key is RECOMMENDED if custodial transfer
is employed and all nodes SHOULD verify the bundle before accepting custody. </t>
<t> Most asymmetric PIB-ciphersuites will use the PIB-source to indicate the
signer and will not require the PIB-dest field because the key needed to verify
the PIB authenticator will be a public key associated with the PIB-source. </t>
</section>
<section title="Payload Confidentiality Block" toc="default" anchor="sec.PCB">
<t>A typical confidentiality ciphersuite will encrypt the payload using a
randomly generated bundle encrypting key (BEK) and will use a key information
item in the PCB security parameters to carry the BEK encrypted with some long term
key encryption key (KEK) or well-known public key. If neither the destination
nor security-destination resolves the key to use for decryption, the key
information item in the ciphersuite parameters field can also be used to
indicate the decryption key with which the BEK can be recovered.
If the bundle already contains PIBs and/or PCBs these SHOULD also
be encrypted using this same BEK, as described just below for
"super-encryption".</t>
<t>It is strongly RECOMMENDED that a data integrity mechanism be used in
conjunction with confidentiality, and that encryption-only ciphersuites
NOT be used. AES-GCM satisfies this requirement.
The "authentication tag" or "integrity check value" is
stored into security-result rather than being appended to the payload
as is common in some protocols since, as described below, it is
important that there be no change in the size of the payload.</t>
<t>The payload is encrypted "in-place", that is, following encryption,
the payload block payload field contains ciphertext, not plaintext.
The payload block processing flags are unmodified.</t>
<t>The "in-place" encryption of payload bytes is to allow bundle payload
fragmentation and re-assembly, and custody transfer, to operate
without knowledge of whether or not encryption has occurred and,
if so, how many times. </t>
<t>Fragmentation and reassembly and custody transfer are adversely affected
by a change in size of the payload due to ambiguity about what byte range of
the original payload is actually in any particular fragment. Ciphersuites
SHOULD place any payload expansion, such as authentication tags
(integrity check values) and any padding generated by a block-mode
cipher, into an "integrity check value" item in the security-result field
(see <xref target="sec.PRF"/>) of the confidentiality block.</t>
<t>Payload super-encryption is allowed; that is, encrypting a payload
that has already been encrypted, perhaps more than once.
Ciphersuites SHOULD define super-encryption such that, as well as
re-encrypting the payload, it also protects the parameters of earlier
encryption. Failure to do do may represent a vulnerability in some
circumstances. </t>
<t>Confidentiality is normally applied to the payload, and possibly to
additional blocks. It is RECOMMENDED to apply a Payload Confidentiality
ciphersuite to non-payload blocks only if these should be super-encrypted
with the payload. If super-encryption of the block is not desired then
protection of the block should be done using the Extension Security Block
mechanism rather than PCB.</t>
<t>Multiple related PCB instances are required if both the payload
and PIBs and PCBs in the bundle are to be encrypted. These multiple
PCB instances require correlators to associate them with each other
since the key information is provided only in the first PCB. </t>
<t>There are situations where more than one PCB instance is required but
the instances are not "related" in the sense which requires correlators.
One example is where a payload is encrypted for more than one security-destination
so as to be robust in the face of routing uncertainties. In this scenario
the payload is encrypted using a BEK. Several PCBs contain the BEK
encrypted using different KEKs, one for each destination.
These multiple PCB instances, are not "related" and should not
contain correlators. </t>
<t>The ciphersuite MAY apply different rules to confidentiality
for non-payload blocks.</t>
<t>A PCB is an ASB with the following additional restrictions:</t>
<t> <list>
<t>The block type code value MUST be 0x04.</t>
<t>The block processing control flags value can be set to whatever values are
required by local policy, except that a PCB "first block"
MUST have the "replicate in every fragment" flag set.
This flag SHOULD NOT be set otherwise.
Ciphersuite designers should carefully consider the
effect of setting flags that either discard the block or delete the bundle
in the event that this block cannot be processed.</t>
<t>The ciphersuite ID MUST be documented as a confidentiality-ciphersuite.</t>
<t>The correlator MUST be present if there is more than one related PCB instance.
The correlator MUST NOT be present if there are no related PCB instances.</t>
<t>If a correlator is present, the key information MUST
be placed in the PCB "first block".</t>
<t>Any additional bytes generated as a result of encryption and/or
authentication processing of the payload SHOULD be placed in an
"integrity check value" field (see <xref target="sec.PRF"/>)
in the security-result of the first PCB.</t>
<t>The ciphersuite parameters field MAY be present.</t>
<t>An EID reference to the security-source MAY be present.</t>
<t>An EID reference to the security-destination MAY be present.</t>
<t>The security result MAY be present and normally contains fields such as
an encrypted bundle encryption key, authentication tag or
the encrypted versions of bundle blocks other than the payload block.</t>
</list> </t>
<t>As was the case for the BAB and PIB, if the ciphersuite requires more
than one instance of the PCB, then the "first block" MUST contain any optional
fields (e.g., security destination etc.) that apply to all instances with this
correlator. These MUST be contained in the first instance and MUST NOT be repeated
in other correlated blocks. Fields that are specific to a particular instance
of the PCB MAY appear in that PCB. For example, security result fields MAY
(and probably will) be included in multiple related PCB instances, with each
result being specific to that particular block.
Similarly, several PCBs might each contain a ciphersuite parameters field
with an IV specific to that PCB instance.</t>
<t>Put another way: when confidentiality will generate multiple blocks, it
MUST first create a PCB with the required ciphersuite ID, parameters etc. as
specified above. Typically, this PCB will appear "early" in the bundle. If this
"first" PCB doesn't contain all of the ciphertext, then it MAY be followed by
other, correlated PCBs which MUST NOT repeat the ciphersuite parameters,
security-source, or security-destination fields from the first PCB.</t>
<t>PCB ciphersuites MUST specify which blocks are to be encrypted.
The specification MAY be flexible and be dependent upon block type,
security policy, various data values and other inputs but it MUST be
deterministic. The determination of whether a block is to be encrypted
or not MUST NOT be ambiguous.</t>
<t>The ciphersuite MAY process less than the entire original bundle payload,
either because the current payload is a fragment of the original bundle or
just becuase it is defined to process some subset. For whatever reason,
if the ciphersuite processes less than the complete, original bundle payload
the PCB MUST specify, as part of the ciphersuite parameters, which bytes
of the bundle payload are protected. </t>
<t>After decryption the plaintext recovered from the security-result field
should then replace the PCB in the bundle for further processing (e.g. PIB
verification). This recovered plaintext MUST contain all the appropriate block
type, processing flags and length information. In other words delete the PCB in
question and place the recovered plaintext, which consists of some complete
non-payload block, in the bundle at the location from which the PCB was
deleted.</t>
<t>A ciphersuite MUST NOT mix payload data and a non-payload block in a single PCB.</t>
<t>Even if a to-be-encrypted block has the "discard" flag set, whether or not
the PCB's "discard" flag is set is an implementation/policy decision for the
encrypting node. (The "discard" flag is more properly called the "discard if
block cannot be processed" flag.)</t>
<t>Any existing eid-list in the to-be-encapsulated original block
remains exactly as-is, and becomes the eid-list for the replacing block.
The encapsulation process MUST NOT replace or remove the existing
eid-list entries. This is critically important for correct updating
of entries at the security-destination. </t>
<t>At the security-destination, either specific destination or the
bundle destination, the processes described above are reversed.
The payload is decrypted in-place using the salt, IV and key values
in the first PCB, including verification using the ICV.
These values are described below in <xref target="sec.PRF"/>.
Each correlated PCB is also processed at the same destination,
using the salt and key values from the first PCB and the
block-specific IV item. The "encapsulated block" item in
security-result is decrypted and validated, using also the tag
which SHOULD have been appended to the ciphertext of the original
block data. Assuming the validation succeeds, the resultant
plaintext, which is the entire content of the original
block, replaces the PCB at the same place in the bundle.
The block type reverts to that of the original block
prior to encapsulation, and the other block-specific data fields
also return to their original values. Implementors are cautioned
that this "replacement" process requires delicate stitchery,
as the eid-list contents in the decapsulated block are invalid.
As noted above, the eid-list references in the original block were
preserved in the replacing PCB, and will have been updated as
necessary as the bundle has toured the dtn. The references from the
PCB MUST replace the references within the eid-list of the
newly-decapsulated block. Caveat implementor. </t>
</section>
<section title="Extension Security Block" toc="default" anchor="sec.ESB">
<t>Extension security blocks provide protection for non-payload-related
portions of a bundle. They MUST NOT be used for the primary block or payload,
including payload-related security blocks (PIBs and PCBs).</t>
<t>It is sometimes desirable to protect certain parts of a bundle in ways
other than those applied to the bundle payload. One such example is bundle
metadata that might specify the kind of data in the payload but not the
actual payload detail, as described in <xref target="DTNMD"/>.
</t>
<t>ESBs are typically used to apply confidentiality protection.
While it is possible to create an integrity-only ciphersuite,
the block protection is not transparent and makes access to the
data more difficult. For simplicity, this discussion describes
use of a confidentiality ciphersuite.</t>
<t>The protection mechanisms in ESBs are similar to other security blocks
with two important differences:</t>
<t> <list>
<t>- different key values are used (using same key as for payload would
defeat the purpose)</t>
<t>- the block is not encrypted or super-encrypted with the payload</t>
</list> </t>
<t>A typical ESB ciphersuite will encrypt the extension block using a
randomly generated ephemeral key and will use the key information item
in the security parameters field to carry the key encrypted with some
long term key encryption key (KEK) or well-known public key.
If neither the destination
nor security-destination resolves the key to use for decryption, the key
information item in the ciphersuite parameters field can be used also to
indicate the decryption key with which the BEK can be recovered. </t>
<t>It is strongly RECOMMENDED that a data integrity mechanism be used in
conjunction with confidentiality, and that encryption-only ciphersuites
NOT be used. AES-GCM satisfies this requirement.</t>
<t>The ESB is placed in the bundle in the same position as the block being
protected. That is, the entire original block is processed (encrypted, etc)
and encapsulated in a "replacing" ESB-type block, and this appears in the
bundle at the same sequential position as the original block. The processed
data is placed in the security-result field.</t>
<t>The process is reversed at the security destination with the recovered
plaintext block replacing the ESB that had encapsulated it. Processing
of EID-list entries, if any, is described above in <xref target="sec.PCB"/> and
this MUST be followed in order to correctly recover EIDs.</t>
<t>An ESB is an ASB with the following additional restrictions:</t>
<t> <list>
<t>Block type is 0x09. </t>
<t>Ciphersuite flags indicate which fields are present in this block.
Ciphersuite designers should carefully consider the
effect of setting flags that either discard the block or delete the bundle
in the event that this block cannot be processed.</t>
<t>EID references MUST be stored in the EID reference list. </t>
<t>Security-source MAY be present. If not present, then the bundle-source
is used as the security-source.</t>
<t>Security-destination MAY be present. If not present, then the
bundle-destination is used as the security-destination. </t>
</list> </t>
<t>The security-parameters MAY optionally contain a block-type field
to indicate the type of the encapsulated block. Since this replicates
a field in the encrypted portion of the block, it is a slight security
risk and its use is therefore OPTIONAL.</t>
</section>
<section title="Parameters and Result Fields" toc="default" anchor="sec.PRF">
<t>Various ciphersuites include several items in the security-parameters
and/or security-result fields. Which items MAY appear is defined by the
particular ciphersuite description. A ciphersuite MAY support several
instances of the same type within a single block.</t>
<t>Each item is represented as type-length-value. Type is a single byte
indicating which item this is. Length is the count of data bytes to follow,
and is an SDNV-encoded integer. Value is the data content of the item.</t>
<t>Item types are</t>
<t> <list>
<t> 0: reserved</t>
<t> 1: initialization vector (IV)</t>
<t> 2: reserved</t>
<t> 3: key information</t>
<t> 4: fragment range (offset and length as a pair of SDNVs)</t>
<t> 5: integrity signature</t>
<t> 6: reserved</t>
<t> 7: salt</t>
<t> 8: PCB integrity check value (ICV)</t>
<t> 9: reserved</t>
<t> 10: encapsulated block</t>
<t> 11: block type of encapsulated block</t>
<t> 12 - 191: reserved</t>
<t> 192 - 250: private use</t>
<t> 251 - 255: reserved</t>
</list> </t>
<t>The folowing descriptions apply to usage of these items for all ciphersuites.
Additional characteristics are noted in the discussion for specific suites.</t>
<t> <list>
<t>- initialization vector(IV): random value, typically eight to sixteen bytes</t>
<t>- key information: key material encoded or protected by the key management system,
and used to transport an ephemeral key protected by a long-term key.
This item is discussed further below in <xref target="sec.KT"/></t>
<t>- fragment range: pair of SDNV values (offset then length) specifying the range
of payload bytes to which a particular operation applies. This is termed
"fragment range" since that is its typical use, even though sometimes it
describes a subset range that is not a fragment. The offset value MUST be
the offset within the original bundle, which might not be the offset within
the current bundle if the current bundle is already a fragment</t>
<t>- integrity signature: result of BA or PI digest or signing operation.
This item is discussed further below in <xref target="sec.KT"/></t>
<t>- salt: an IV-like value used by certain confidentiality suites</t>
<t>- PCB integrity check value(ICV): output from certain confidentiality
ciphersuite operations to be used at the destination to verify that the
protected data has not been modified</t>
<t>- encapsulated block: result of confidentiality operation on certain
blocks, contains the ciphertext of the block and MAY also contain an
integrity check value appended to the ciphertext; MAY also contain
padding if required by the encryption mode; used for non-payload
blocks only</t>
<t>- block type of encapsulated block: block type code for a block
that has been encapsulated in ESB</t>
</list> </t>
</section>
<section title="Key Transport" toc="default" anchor="sec.KT">
<t>This specification endeavours to maintain separation between the
security protocol and key management. However, these two interact in
the transfer of key information, etc., from security-source
to security-destination.
The intent of the separation is to facilitate use of a variety of
key management systems without a necessity to tailor a ciphersuite
to each individually. </t>
<t>The key management process deals with such things as long-term keys,
specifiers for long-term keys, certificates for long-term keys
and integrity signatures using long-term keys. The ciphersuite itself
should not require a knowledge of these, and separation is improved
if it treats these as opaque entities, to be handled by the key management
process.</t>
<t>The key management process deals specifically with the content of two
of the items defined above in <xref target="sec.PRF"/>:-
key information (item type 3) and integrity signature (item type 5).
The ciphersuite MUST define the details and format for these items.
To facilitate interoperability, it is strongly RECOMMENDED that the
implementations use the appropriate definitions from Cryptographic
Message Syntax (CMS) <xref target="RFC5652"/> and related RFCs. </t>
<t>Many situations will require several pieces of key information.
Again, ciphersuites MUST define whether they accept these packed
into a single key information item and/or separated into multiple
instances of key information. For interoperability, it is
RECOMMENDED that ciphersuites accept these packed into a single
key-information item, and that they MAY
additionally choose to accept them sent as separate items.</t>
</section>
<section title="PIB and PCB combinations">
<t>Given the above definitions, nodes are free to combine applications
of PIB and PCB in any way they wish - the correlator value allows for
multiple applications of security services to be handled separately.
Since PIB and PCB apply to the payload and ESB to non-payload blocks,
combinations of ESB with PIB and/or PCB are not considered.</t>
<t>There are some obvious security problems that could arise when
applying multiple services. For example, if we encrypted a payload but left a
PIB security result containing a signature in the clear, payload
guesses could be confirmed.</t>
<t>We cannot, in general, prevent all such problems since we cannot assume that
every ciphersuite definition takes account of every other ciphersuite
definition. However, we can limit the potential for such problems by requiring
that any ciphersuite which applies to one instance of a PIB or PCB, MUST be
applied to all instances with the same correlator.</t>
<t>We now list the PIB and PCB combinations which we envisage as being useful to
support:</t>
<t> <list>
<t>Encrypted tunnels - a single bundle MAY be encrypted many times en-route to
its destination. Clearly it has to be be decrypted an equal number of times, but we
can imagine each encryption as representing the entry into yet another layer of
tunnel. This is supported by using multiple instances of PCB, but with the
payload encrypted multiple times, "in-place". Depending upon the ciphersuite
defintion, other blocks can and should be encrypted, as discussed above
and in <xref target="sec.PCB"/> to ensure that parameters are protected
in the case of super-encryption.</t>
<t>Multiple parallel authenticators - a single security source might wish to
protect the integrity of a bundle in multiple ways.
This could be required if the bundle's path is
unpredictable, and if various nodes might be involved as security destinations.
Similarly, if the security source cannot determine in advance which algorithms
to use, then using all might be reasonable. This would result in uses of PIB
which presumably all protect the payload, and which cannot in general protect
one another. Note that this logic can also apply to a BAB, if the unpredictable
routing happens in the convergence layer, so we also envisage support for
multiple parallel uses of BAB.</t>
<t>Multiple sequential authenticators - if some security destination requires
assurance about the route that bundles have taken, then it might insist that
each forwarding node add its own PIB. More likely, however would be that outbound
"bastion" nodes would be configured to sign bundles as a way of allowing the
sending "domain" to take accountability for the bundle. In this case, the
various PIBs will likely be layered, so that each protects the earlier
applications of PIB.</t>
<t>Authenticated and encrypted bundles - a single bundle MAY require both
authentication and confidentiality. Some specifications first apply
the authenticator and follow this by encrypting the payload and authenticator.
As noted previously in the case where the authenticator is a signature, there
are security reasons for this ordering. (See the PCB-RSA-AES128-PAYLOAD-PIB-PCB
ciphersuite defined later in <xref target="rsaaes"/>.)
Others apply the authenticator after encryption, that is, to the ciphertext.
This ordering is generally recommended and minimizes attacks which, in some
cases, can lead to recovery of the encryption key.
</t>
</list> </t>
<t>There are no doubt other valid ways to combine PIB and PCB instances, but
these are the "core" set supported in this specification. Having said that,
as will be seen,
the mandatory ciphersuites defined here are quite specific and restrictive in
terms of limiting the flexibility offered by the correlator mechanism. This is
primarily designed to keep this specification as simple as possible, while at
the same time supporting the above scenarios.</t>
</section>
</section>
<section title="Security Processing" toc="default">
<t>This section describes the security aspects of bundle processing. </t>
<section anchor="secPEP" title="Nodes as policy enforcement points"
toc="default">
<t>All nodes are REQUIRED to have and enforce their own configurable security
policies, whether these policies be explicit or default, as defined in
<xref target="sec.Defaults"/>. </t>
<t>All nodes serve as Policy Enforcement Points (PEP) insofar as they enforce
polices that MAY restrict the permissions of bundle nodes to inject traffic
into the network. Policies MAY apply to traffic originating at the current node,
traffic terminating at the current node and traffic to be forwarded by the
current node to other nodes. If a particular transmission request, originating
either locally or remotely, satisfies the node's policy or policies
and is therefore accepted, then an outbound bundle can be created and
dispatched. If not, then in its role as a PEP, the node will not create or
forward a bundle. Error handling for such cases is currently considered out
of scope of this document.</t>
<t>Policy enforcing code MAY override all other processing steps described here
and elsewhere in this document. For example, it is valid to implement a node
which always attempts to attach a PIB. Similarly it is also valid to implement
a node which always rejects all requests which imply the use of a PIB.</t>
<t>Nodes MUST consult their security policy to determine the criteria that
a received bundle ought to meet before it will be forwarded. These criteria
MUST include a determination of whether or not the received bundle MUST include
a valid BAB, PIB, PCB or ESB. If the bundle does not meet the node's policy
criteria, then the bundle MUST be discarded and processed no further; in this
case, a bundle status report indicating the failure MAY be generated.</t>
<t>The node's policy MAY call for the node to add or subtract some security
blocks, for example, requiring the node attempt to encrypt (parts of) the
bundle for some security-destination, or requiring that the node add a
PIB. If the node's policy requires a BAB to be added to the bundle, it MUST be
added last so that the calculation of its security result MAY take into
consideration the values of all other blocks in the bundle.</t>
</section>
<section anchor="sec.stack" title="Processing order of security blocks"
toc="default">
<t>The processing order of security actions for a bundle is critically
important for the actions to complete successfully. In general, the
actions performed at the originating node MUST be executed in the
reverse sequence at the destination. There are variations and
exceptions, and these are noted below.</t>
<t>The sequence is maintained in the ordering of security blocks in the
bundle. It is for this reason that blocks MUST not be rearranged at
forwarding nodes, whether they support the security protocols or not.
The only blocks that participate in this ordering are the primary
and payload blocks, and the PIB and PCB security blocks themselves.
All other extension blocks, including ESBs, are ignored for purposes of
determining the processing order.</t>
<t>The security blocks are added to and removed from a bundle in a
last-in-first-out (LIFO) manner, with the top of the stack immediately
after the primary block. A newly-created bundle has just the primary and
payload blocks, and the stack is empty. As security actions are requested
for the bundle, security blocks are pushed onto the stack immediately after
the primary block. The early actions have security blocks close to the
payload, later actions have blocks nearer to the primary block.
The actions deal with only those blocks in the bundle at the
time so, for example, the first to be added processes only the payload
and primary blocks, the next might process the first if it chooses and
the payload and primary, and so on. The last block to be added can
process all the blocks. </t>
<t>When the bundle is received, this process is reversed and
security processing begins at the top of the stack, immediately
after the primary block. The security actions are performed and
the block is popped from the stack. Processing continues with the
next security block until finally only the payload and primary
blocks remain.</t>
<t>The simplicity of this description is undermined by various
real-world requirements. Nonetheless it serves as a helpful
initial framework for understanding the bundle security
process.</t>
<t>The first issue is a very common one and easy to handle.
The bundle may be sent indirectly to its destination, requiring
several forwarding hops to finally arrive there. Security
processing happens at each node, assuming that the node supports
bundle security. For the following discussion, we assume that
a bundle is created and that confidentiality, then payload
integrity and finally bundle authentication are applied to it.
The block sequence would therefore be primary-BAB-PIB-PCB-payload.
Traveling from source to destination requires going through
one intermediate node, so the trip consists of two hops. </t>
<t>When the bundle is received at the intermediate node, the
receive processing validates the BAB and pops it from
the stack. However the PIBs and PCBs have the final
destination as their security destination, so these can't
be processed and removed. The intermediate node then begins
the send process with the four remaining blocks in the bundle.
The outbound processing adds any security blocks required
by local policy, and these are pushed on the stack immediately
after the primary block, ahead of the PIB. In this
example, the intermediate node adds a PIB as a signature
that the bundle has passed through the node. </t>
<t>The receive processing at the destination first handles
the intermediate node's PIB and pops it, next is the
originator's PIB, also popped, and finally the
originator's confidentiality block which allows the
payload to be decrypted and the bundle handled for
delivery.</t>
<t>DTNs in practice are likely to be more complex.
The security policy for a node specifies the security requirements
for a bundle.
The policy will possibly cause one or more security operations
to be applied to the bundle at the current node, each with its own
security-destination. Application of policy at subsequent nodes
might cause additional security operations, each with a
security-destination. The list of security-destinations
in the security blocks (BAB, PIB and PCB, not ESB) creates
a partial-ordering of nodes that MUST be visited en route to the
bundle destination. </t>
<t>The bundle security scheme does not deal with security paths
that overlap partially but not completely.
The security policy for a node MUST avoid specifying for a bundle
a security-destination that causes a conflict with any existing
security-destination in that bundle.
This discussed further below in <xref target="sec.sz"/>.</t>
<t>The second issue relates to the reversibility of certain
security process actions. In general, the actions fall into
two categories: those which do not affect other parts of the
bundle, and those which are fully reversible. Creating a
bundle signature, for example, does not change the bundle
content except for the result. The encryption performed as
part of the confidentiality processing does change the bundle,
but the reverse processing at the destination restores the
original content. </t>
<t>The third category is the one where the bundle content has
changed slightly and in a non-destructive way, but there is no
mechanism to reverse the change. The simplest example is the
addition of an EID-reference to a security block. The addition
of the reference causes the text to be added to the bundle's
dictionary. The text may be used also by other references so
removal of the block and this specific eid-reference does not
cause removal of the text from the dictionary. This shortcoming
is of no impact to the "sequential" or "wrapping" security
schemes described above, but does cause failures with
"parallel" authentication mechanisms. Solutions for this
problem are implementation-specific and typically involve
multi-pass processing such that blocks are added at one
stage and the security results calculated at a later stage
of the overall process.</t>
<t>Certain ciphersuites have sequence requirements for their correct
operation, most notably the bundle authentication ciphersuites.
Processing for bundle authentication is required to happen after all
other sending operations, and prior to any receive operations at the
next hop node. It follows therefore that BA blocks MUST always be
pushed onto the stack after all others.</t>
<t>Although we describe the security block list as a stack, there are
some blocks which are placed after the payload and therefore are not
part of the stack. The BundleAuthentication ciphersuite #1 ("BA1")
requires a second, correlated block to contain the security-result
and this block is placed after the payload, usually as the last block
in the bundle. We can apply the stack rules even to these blocks by
specifying that they be added to the end of the bundle at the same
time that their "owner" or "parent" block is pushed on the stack.
In fact, they form a stack beginning at the payload but growing
in the other direction. Also, not all blocks in the main stack
have a corresponding entry in the trailing stack. The only blocks
which MUST follow the payload are those mandated by ciphersuites
as correlated blocks for holding a security-result. No other
blocks are required to follow the payload block and it is
RECOMMENDED that they NOT do so.</t>
<t>ESBs are effectively placeholders for the blocks they encapsulate
and, since those do not form part of the processing sequence
described above, ESBs themselves do not either.
ESBs MAY be correlated, however, so the "no reordering"
requirement applies to them as well.</t>
</section>
<section anchor="sec.sz" title="Security Regions"
toc="default">
<t>Each security block has a security path, as described in the
discussion for <xref target="protocolStack"/>, and the paths for
various blocks are often different. </t>
<t>BA blocks are always for a single hop and these restricted
paths never cause conflict. </t>
<t>The paths for PIBs and PCBs are often from bundle source
to bundle destination, to provide end-to-end protection.
A bundle-source-to-bundle-destination path likewise never
causes a problem. </t>
<t>Another common scenario is for gateway-to-gateway
protection of traffic between two sub-networks
("tunnel-mode").</t>
<t>Looking at <xref target="protocolStack"/> and the
simplified version shown in <xref target="sz1"/>, we can
regard BN2 and BN3 as gateways connecting the two
subnetworks labeled "An internet". As long as they provide
security for the BN2-BN3 path, all is well. Problems begin,
for example, when BN2 adds blocks with BN4 as the
security-destination, and originating node BN1 has created
blocks with BN3 as security-destination. We now have two paths
and neither is a subset of the other. </t>
<t>This scenario should be prevented by node BN2's security
policy being aware of the already-existing block with BN3 as
the security destination. This policy SHOULD NOT specify a
security-dest that is further distant than any existing
security-dest. </t>
<figure anchor="sz1">
<preamble> </preamble>
<artwork>
+---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+
| BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 |
+---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+
>>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^
<------------- BN1 to BN3 path ------------>
<------------- BN2 to BN4 path ------------>
</artwork>
<postamble> Overlapping security paths</postamble>
</figure>
<t>Consider the case where the security concern is for
data integrity, so the blocks are PIBs.
BN1 creates one ("PIa") along with the new bundle, and BN2
pushes its own PIB "PIb" on the stack, with
security-destination BN4. When this bundle arrives at BN3,
the bundle blocks are
<figure> <artwork>
primary - PIb - PIa - payload
</artwork> </figure>
Block PIb is not destined for this node BN3 so has to be forwarded.
This is the security-destination for block PIa so, after validation,
it should be removed from the bundle. But that will invalidate the
PIb signature when the block is checked at the final destination.
The PIb signature includes the primary block, PIb itself, PIa and
the payload block, so PIa MUST remain in the bundle. This is why
security blocks are treated as a stack and add/remove operations
are permitted only at the top-of-stack. </t>
<t>The situation would be worse if the security concern is
confidentiality, so PCBs are employed, such as the
confidentiality ciphersuite #3 ("PC3") described in
<xref target="rsaaes"/>. In this scenario, BN1 would encrypt the
bundle with BN3 as security-destination, BN2 would super-encrypt
the payload and encapsulate the PC3 block for security-destination BN4.
BN3 forwards all the blocks without change. BN4 decrypts the payload
from its super-encryption and decapsulates the PC3 block, only to
find that it should have been processed earlier. Assuming that BN4
has no access to BN3's key store, BN4 has no way to decrypt the
bundle and recover the original content.
</t>
<t>As mentioned above, authors of security policy need to use care to
ensure that their policies do not cause overlaps. These guidelines
should prove helpful:</t>
<t><list>
<t>the originator of a bundle can always specify the bundle-dest as
the security-dest, and should be cautious about doing otherwise</t>
<t>in the "tunnel-mode" scenario where two sub-networks are connected
by a tunnel through a network, the gateways can each specify the other
as security-dest, and should be cautious about doing otherwise</t>
<t>BAB is never a problem because it is always only a single hop</t>
<t>PIB for a bundle without PCB will usually specify the bundle
destination as security-dest</t>
<t>PIB for a bundle containing a PCB should specify as its
security-dest the security-dest of the PCB (outermost PCB if there
are more than one)</t>
</list></t>
</section>
<section anchor="C14N" title="Canonicalisation of bundles" toc="default">
<t>In order to verify a signature or MAC on a bundle the exact same bits, in
the exact same order, MUST be input to the calculation upon verification as
were input upon initial computation of the original signature or MAC value.
Consequently, a node MUST NOT change the encoding of any URI in the dictionary
field, e.g., changing the DNS part of some HTTP URL from lower case to upper case.
Because bundles MAY be modified while in transit (either correctly or due to
implementation errors), a canonical form of any given bundle (that contains a
BAB or PIB) MUST be defined.</t>
<t>This section defines bundle canonicalisation algorithms used in the
<xref target="BABhmac"/> and <xref target="PIBrsasha"/> ciphersuites.
Other ciphersuites can use these or define their own canonicalization
procedures. </t>
<section anchor="strictC14N" title="Strict canonicalisation" toc="default">
<t>The first algorithm that can be used permits no changes at all to the bundle
between the security-source and
the security-destination. It is mainly intended for use in BAB ciphersuites. This
algorithm conceptually catenates all blocks in the order presented, but
omits all security result data fields in blocks of this ciphersuite type.
That is, when a BA ciphersuite specifies this algorithm then we
omit all BAB security results for all BA ciphersuites, when a PIB ciphersuite specifies
this algorithm then we omit all PIB security results for all PI ciphersuites.
All security result length fields are
included, even though their corresponding security result data fields are omitted.</t>
<t>Notes:</t>
<t> <list>
<t>- In the above we specify that security result data is omitted. This means that
no bytes of the security result data are input. We do not set the security
result length to zero. Rather, we assume that the security result length will
be known to the module that implements the ciphersuite before the security result is
calculated, and require that this value be in the security result length field even
though the security result data itself will be omitted.</t>
<t>- The 'res' bit of the ciphersuite ID, which indicates whether or not the
security result length and security result data field are present,
is part of the canonical form.</t>
<t>-The value of the block data length field, which indicates the length of the block,
is also part of the canonical form. Its value indicates the
length of the entire bundle when the bundle includes the security result data field.</t>
<t>-BABs are always added to bundles after PIBs, so when a PIB ciphersuite specifies
this strict canonicalisation algorithm and the PIB is received with a bundle that
also includes one or more BABs, application of strict canonicalisation as part of
the PIB security result verification process requires that all BABs in the bundle
be ignored entirely.</t>
</list> </t>
</section>
<section anchor="mutableC14N" title="Mutable canonicalisation" toc="default">
<t>This algorithm is intended to protect parts of the bundle which
should not be changed in-transit. Hence it omits the mutable parts of the
bundle.</t>
<t>The basic approach is to define a canonical form of the primary block and
catenate it with the security (PIBs and PCBs only) and payload blocks in the
order that they will be transmitted. This algorithm ignores all other blocks,
including ESBs, because it cannot be determined whether or not they will
change as the bundle transits the network. In short, this canonicalization
protects the payload, payload-related security blocks and parts of the
primary block. </t>
<t>Many fields in various blocks are stored as variable-length SDNVs.
These are canonicalized in unpacked form, as eight-byte fixed-width fields
in network byte order. The size of eight bytes is chosen because
implementations MAY handle larger values as invalid, as noted in
<xref target="DTNBP" />. </t>
<t>The canonical form of the primary block is shown
in <xref target="primaryc14n"/>.
Essentially, it de-references the dictionary block, adjusts lengths
where necessary and ignores flags that MAY change in transit.</t>
<figure anchor="primaryc14n">
<preamble>
</preamble>
<artwork>
+----------------+----------------+----------------+----------------+
| Version | Processing flags (incl. COS and SRR) |
+----------------+----------------+---------------------------------+
| Canonical primary block length |
+----------------+----------------+---------------------------------+
| Destination endpoint ID length |
+----------------+----------------+---------------------------------+
| |
| Destination endpoint ID |
| |
+----------------+----------------+---------------------------------+
| Source endpoint ID length |
+----------------+----------------+----------------+----------------+
| |
| Source endpoint ID |
| |
+----------------+----------------+---------------------------------+
| Report-to endpoint ID length |
+----------------+----------------+----------------+----------------+
| |
| Report-to endpoint ID |
| |
+----------------+----------------+----------------+----------------+
| |
+ Creation Timestamp (2 x SDNV) +
| |
+---------------------------------+---------------------------------+
| Lifetime |
+----------------+----------------+----------------+----------------+
</artwork>
<postamble>
The canonical form of the primary bundle block.
</postamble>
</figure>
<t>The fields shown in <xref target="primaryc14n"/>
are:</t>
<t> <list>
<t>Version is the single-byte value in the primary block. </t>
<t>Processing flags in the primary block is an SDNV, and includes the
class-of-service (COS) and status report request (SRR) fields.
For purposes of canonicalization, the SDNV is unpacked into a
fixed-width field and some bits are masked out. The unpacked field
is ANDed with mask 0x0000 0000 0007 C1BE to set to zero all reserved
bits and the "bundle is a fragment" bit. </t>
<t>Length - a four-byte value containing the length (in bytes) of this
structure, in network byte order.</t>
<t>Destination endpoint ID length and value - are the length (as a
four byte value in network byte order) and value of the destination
endpoint ID from the primary bundle block. The URI is simply copied
from the relevant part(s) of the dictionary block and is not itself
canonicalised. Although the dictionary entries contain null-terminators,
the null-terminators are not included in the length or the
canonicalization. </t>
<t>Source endpoint ID length and value are handled similarly to the
destination.</t>
<t>Report-to endpoint ID length and value are handled similarly to the
destination.</t>
<t>Creation time (2 x SDNV) and Lifetime (SDNV) are simply copied
from the primary block, with the SDNV values being represented as
eight-byte unpacked values.</t>
<t>Fragment offset and Total application data unit length are ignored,
as is the case for the "bundle is a fragment" bit mentioned above.
If the payload data to be canonicalized is less than the complete,
original bundle payload, the offset and length are specified in the
security-parameters. </t>
</list> </t>
<t>For non-primary blocks being included in the canonicalization, the
block processing flags value used for canonicalization is the unpacked
SDNV value with reserved and mutable bits masked to zero. The unpacked
value is ANDed with mask 0x0000 0000 0000 0077 to zero reserved bits
and the "last block" flag. The "last block" flag is ignored because
BABs and other security blocks MAY be added for some parts of the journey
but not others so the setting of this bit might change from hop to hop.</t>
<t>Endpoint ID references in security blocks are canonicalized using the
de-referenced text form in place of the reference pair. The reference
count is not included, nor is the length of the endpoint ID text.</t>
<t>The block-length is canonicalized as an eight-byte unpacked value
in network byte order. If the payload data to be canonicalized is less
than the complete, original bundle payload, this field contain the
size of the data being canonicalized (the "effective block") rather
that the actual size of the block.</t>
<t>Payload blocks are generally canonicalized as-is with the exception
that in some instances only a portion of the payload data is to be
protected. In such a case, only those bytes are included in the canonical
form, and additional ciphersuite parameters are required to specify
which part of the payload is protected, as discussed further below. </t>
<t>Security blocks are handled likewise, except that the ciphersuite
will likely specify that the "current" security block security
result field not be considered part of the canonical form. This
differs from the strict canonicalisation case since we might use
the mutable canonicalisation algorithm to handle sequential
signatures such that signatures cover earlier ones.</t>
<t>ESBs MUST NOT be included in the canonicalization.</t>
<t>Notes:</t>
<t> <list>
<t>- The canonical form of the bundle is not transmitted. It is
simply an artifact used as input to digesting.</t>
<t>- We omit the reserved flags because we cannot determine if
they will change in transit. The masks specified above will have to be
revised if additional flags are defined and they need to be protected. </t>
<t>- Our URI encoding does not preserve the "null-termination" convention
from the dictionary field, nor do we separate the scheme and ssp as is done
there.</t>
<t>- The URI encoding will cause errors if any node rewrites the
dictionary content (e.g. changing the DNS part of an HTTP URL from
lower-case to upper case). This could happen transparently when
a bundle is synched to disk using one set of software and then read from disk
and forwarded by a second set of software. Because there are no general
rules for canonicalising URIs (or IRIs), this problem may be an
unavoidable source of integrity failures.</t>
<t>- All SDNV fields here are canonicalized as eight-byte unpacked values
in network byte order. Length fields are canonicalized as four-byte values
in network byte order. Encoding does not need optimization since the values
are never sent over the network.</t>
<t>If a bundle is fragmented before the PIB is applied then the PIB applies
to a fragment and not the entire bundle. However, the protected fragment could
be subsequently further fragmented, which would leave the verifier unable to
know which bytes were protected by the PIB. Even in the absence of frgmentation
the same situation applies if the ciphersuite is defined to allow protection
of less than the entire, original bundle payload. </t>
<t>For this reason, PIB ciphersuites which support applying a PIB to less than
the complete, original bundle payload MUST specify, as part of the ciphersuite
parameters, which bytes of the bundle payload are protected. When verification
occurs, only the specified range of the payload bytes are input to PIB verification.
It is valid for a ciphersuite to be specified so as to only apply to
entire bundles and not to fragments. A ciphersuite MAY be specified to
apply to only a portion of the payload, regardless of whether the
payload is a fragment or the complete original bundle payload. </t>
<t>The same fragmentation issue applies equally to PCB ciphersuites.
Ciphersuites which support applying confidentiality to fragments MUST specify,
as part of the ciphersuite parameters, which bytes of the bundle payload are
protected. When decrypting a fragment, only the specified bytes are processed.
It is also valid for a confidentiality ciphersuite to be specified so as to
only apply to entire bundles and not to fragments.</t>
</list> </t>
<t>This definition of mutable canonicalization assumes that endpoint IDs
themselves are immutable and is unsuitable for use in environments where
that assumption might be violated. </t>
<t>Since the canonicalization applies to a specific bundle rather than a
payload, an originator's signature cannot be verified if a payload is
forwarded, as the forwarded bundle will have a different source.</t>
<t>The solution for either of these issues is to define and use a PIB
ciphersuite having an alternate version of mutable canonicalization
any fields from the primary block.</t>
</section>
</section>
<section title="Endpoint ID confidentiality" toc="default" anchor="srcPCB">
<t>Every bundle MUST contain a primary block that contains the source and
destinations endpoint IDs, and others, and that cannot be encrypted.
If endpoint ID confidentiality is required, then bundle-in-bundle
encapsulation can solve this problem in some instances.</t>
<t>Similarly, confidentiality requirements MAY also apply to other
parts of the primary block (e.g. the current-custodian) and that is
supported in the same manner.</t>
</section>
<section title="Bundles received from other nodes" toc="default" anchor = "sec.bon">
<t>Nodes implementing this specification SHALL consult their security policy to
determine whether or not a received bundle is required by policy to include a
BAB. If the bundle has no BAB and one is not required then BAB processing on
the received bundle is complete and the bundle is ready to be further processed
for PIB/PCB/ESB handling or delivery or forwarding. </t>
<t>If the bundle is required to have a BAB but does not, then the bundle
MUST be discarded and processed no further. If the bundle is required to have
a BAB but all of its BABs identify a different node other than the receiving node
as the BAB security destination, then the bundle MUST be discarded and processed
no further.</t>
<t>If the bundle is required to have a BAB and has one or more BABs that
identify the receiving node as the BAB security destination,
or for which there is no security destination, then
the value in the security result field(s) of the BAB(s) MUST be verified according
to the ciphersuite specification. If for all such BABs in the bundle either the BAB
security source cannot be determined or the security result value check fails,
the bundle has failed to authenticate and the bundle MUST be discarded and
processed no further. If any of the BABs present verify, or if a BAB is
not required, the bundle is ready for further processing as determined
by extension blocks and/or policy.</t>
<t>BABs received in a bundle MUST be stripped before the bundle is forwarded.
New BABs MAY be added as required by policy. This MAY require correcting the
"last block" field of the to-be-forwarded bundle.</t>
<t>Further processing of the bundle MUST take place in the order indicated by the
various blocks from the primary block to the payload block, except as defined by
an applicable specification.</t>
<t>If the bundle has a PCB and the receiving node is the PCB destination for the
bundle (either because the node is listed as the bundle's PCB-dest or because
the node is listed as the bundle's destination and there is no PCB-dest),
the node MUST decrypt the relevant parts of the bundle in accordce with the ciphersuite
specification. The PCB SHALL be deleted. If the relevant parts of the bundle
cannot be decrypted (i.e. the decryption key cannot be deduced or decryption fails),
then the bundle MUST be discarded and processed no further; in this case a bundle
deletion status report (see the Bundle Protocol <xref target="DTNBP"/>) indicating
the decryption failure MAY be generated. If the PCB security result included the
ciphertext of a block other than the payload block, the recovered plaintext block
MUST be placed in the bundle at the location from which the PCB was deleted.</t>
<t>If the bundle has one or more PIBs for which the receiving node is the bundle's PIB
destination (either because the node is listed in the bundle's PIB-dest or because the
node is listed as the bundle's destination and there is no PIB-dest), the node MUST
verify the value in the PIB security result field(s) in accordance with the ciphersuite
specification. If all the checks fail, the bundle has failed to authenticate and the bundle
SHALL be processed according to the security policy. A bundle status report indicating the
failure MAY be generated.
Otherwise, if the PIB verifies, the bundle is ready to be processed for either
delivery or forwarding. Before forwarding the bundle, the node SHOULD remove
the PIB from the bundle, subject to the requirements of <xref target="sec.stack"/>,
unless it is likely that some downstream node will also be able to verify the PIB.</t>
<t>If the bundle has a PIB and the receiving node is not the bundle's PIB-dest
the receiving node MAY attempt to verify the value in the security result field.
If it is able to check and the check fails, the node SHALL discard the bundle
and it MAY send a bundle status report indicating the failure.</t>
<t>If the bundle has an ESB and the receiving node is the ESB destination for the
bundle (either because the node is listed as the bundle's ESB-dest or because
the node is listed as the bundle's destination and there is no ESB-dest),
the node MUST decrypt and/or decapsulate the encapsulated block in accordance with the
ciphersuite specification. The decapsulated block replaces the ESB in the bundle
block sequence, and the ESB is thereby deleted. If the content
cannot be decrypted (i.e., the decryption key cannot be deduced or decryption fails),
then the bundle MAY be discarded and processed no further unless the security policy
specifies otherwise. In this case a bundle deletion status report (see the Bundle Protocol
<xref target="DTNBP"/>) indicating the decryption failure MAY be generated. </t>
</section>
<section title="The At-Most-Once-Delivery Option" toc="default">
<t>An application MAY request (in an implementation specific manner)
that a node be registered as a member of an
endpoint and that received bundles destined for that endpoint be
delivered to that application. </t>
<t>An option for use in such cases is known as
"at-most-once-delivery". If this option is chosen, the application
indicates that it wants the node to check for duplicate bundles, discard
duplicates, and deliver at most one copy of each received bundle to the
application. If this option is not chosen, the application indicates that
it wants the node to deliver all received bundle copies to the application.
If this option is chosen, the node SHALL deliver at most one copy of each
received bundle to the application. If the option is not chosen, the node
SHOULD, subject to policy, deliver all bundles.</t>
<t>To enforce this the node MUST look at the source/timestamp pair value of
each complete (reassembled, if necessary) bundle received and determine if this
pair, which uniquely identifies a bundle, has been previously received.
If it has, then the bundle is a duplicate.
If it has not, then the bundle is not a duplicate. The source/timestamp pair
SHALL be added to the list of pair values already received by that node. </t>
<t>Each node implementation MAY decide how long to maintain a table of
pair value state.</t>
<t>Additional discussion relevant to at-most-once-delivery is in the
DTN Retransmission Block specification <xref target="DTNRB"/>.</t>
</section>
<section title="Bundle Fragmentation and Reassembly" anchor="frag" toc="default">
<t>If it is necessary for a node to fragment a bundle and security
services have been applied to that bundle, the fragmentation rules
described in <xref target="DTNBP"/>
MUST be followed. As defined there and repeated here for completeness,
only the payload MAY be fragmented; security blocks, like all
extension blocks, can never be fragmented. In addition, the following
security-specific processing is REQUIRED:</t>
<t>The security policy requirements for a bundle MUST be applied
individually to all the bundles resulting from a fragmentation event.</t>
<t>If the original bundle contained a PIB, then each of the PIB instances
MUST be included in some fragment.</t>
<t>If the original bundle contained one or more PCBs, then any PCB instances
containing a key information item MUST have the "replicate in every fragment"
flag set, and thereby be replicated in every fragment. This is to ensure
that the canonical block-sequence can be recovered during reassembly.</t>
<t>If the original bundle contained one or more correlated PCBs not
containing a key information item, then each of these MUST be included in
some fragment, but SHOULD NOT be sent more than once.
They MUST be placed in a fragment in accordance with the fragmentation
rules described in <xref target="DTNBP"/>.</t>
<t>Note: various fragments MAY have additional security blocks added at this
or later stages and it is possible that correlators will collide. In order to
facilitate uniqueness, ciphersuites SHOULD include the fragment-offset of the
fragment as a high-order component of the correlator.</t>
</section>
<section title="Reactive fragmentation" anchor="reactive" toc="default">
<t>When a partial bundle
has been received, the receiving node SHALL consult its security policy to
determine if it MAY fragment the bundle, converting the received portion
into a bundle fragment for further forwarding. Whether or not
reactive fragmentation is permitted SHALL depend on the security policy
and the ciphersuite used to calculate the BAB authentication information,
if required. (Some BAB ciphersuites, i.e., the mandatory BAB-HMAC
ciphersuite defined in <xref target="BABhmac"/>,
do not accommodate reactive fragmentation because
the security result in the BAB requires that the entire bundle be signed.
It is conceivable, however, that a BAB ciphersuite could be defined such that
multiple security results are calculated, each on a different segment of a
bundle, and that these security results could be interspersed between bundle
payload segments such that reactive fragmentation could be accommodated.)</t>
<t>If the bundle is reactively fragmented by the intermediate receiver
and the BAB-ciphersuite is of an appropriate type (e.g. with multiple security
results embedded in the payload), the bundle MUST be fragmented immediately
after the last security result value in the partial payload that is received.
Any data received after the last security result value MUST be dropped. </t>
<t>If a partial bundle is received at the intermediate receiver and is
reactively fragmented and forwarded, only the part of the bundle that was not
received MUST be retransmitted, though more of the bundle MAY be retransmitted.
Before retransmitting a portion of the bundle, it SHALL be changed into a
fragment and, if the original bundle included a BAB, the fragmented bundle
MUST also, and its BAB SHALL be recalculated. </t>
<t>This specification does not currently define any ciphersuite which
can handle this reactive fragmentation case.</t>
<t>An interesting possibility is a ciphersuite definition such that the
transmission of a follow-up fragment would be accompanied by the signature
for the payload up to the restart point.</t>
</section>
</section>
<section title="Mandatory Ciphersuites" toc="default" anchor="ciphersuites">
<t>This section defines the mandatory ciphersuites for this specification.
There is currently one mandatory ciphersuite for use with each of the
security block types BAB, PIB, PCB and ESB.
The BAB ciphersuite is based on shared secrets using HMAC. The PIB
ciphersuite is based on digital signatures using RSA with SHA256. The
PCB and ESB ciphersuites are based on using RSA for key transport and
AES for bulk encryption.</t>
<t>The key transport mechanisms defined in Cryptographic Message Syntax
<xref target="RFC5652"/> are suitable for the ciphersuites, with only minor
adjustment as required by the ciphersuite characteristics. </t>
<section title="BAB-HMAC" toc="default" anchor="BABhmac">
<t>The BAB-HMAC ciphersuite has ciphersuite ID value 0x001.</t>
<t>BAB-HMAC uses the strict canonicalisation algorithm in
<xref target="strictC14N"/>.</t>
<t>Strict canonicalization supports digesting of a fragment-bundle.
It does not permit the digesting of only a subset of the
payload, but only the complete contents of the payload of the
current bundle, which might be a fragment.
The "fragment range" item for security-parameters is not
used to indicate a fragment, as this information is digested
within the primary block. </t>
<t>The variant of HMAC to be used is HMAC-SHA1 as defined in
<xref target="RFC2104"/>.</t>
<t>This ciphersuite requires the use of two related instances of the BAB. It
involves placing the first BAB instance (as defined in
<xref target="sec.BAB"/>) just after the primary block. The second
(correlated) instance of the BAB MUST be placed after all other blocks
(except possibly other BAB blocks) in the bundle.</t>
<t>This means that normally, the BAB will be the second and last blocks of the
bundle. If a forwarder wishes to apply more than one correlated BAB pair, then
this can be done. There is no requirement that each application "wrap" the
others, but the forwarder MUST insert all the "up front" BABs, and their "at back"
"partners" (without any security result), before canonicalising.</t>
<t>Inserting more than one correlated BAB pair would be useful if the bundle
could be routed to more than one potential "next-hop" or if both an old or
a new key were valid at sending time, with no certainty about the situation
that will obtain at reception time.</t>
<t>The security result is the output of the HMAC-SHA1 calculation with input
being the result of running the entire bundle through the strict
canonicalisation algorithm. Both required BAB instances MUST be included in the
bundle before canonicalisation.</t>
<t>Security parameters are optional with this scheme, but if
used then the only field that can be present is key information
(see <xref target="sec.PRF"/>). </t>
<t>Implementations MUST support use of "AuthenticatedData" type as defined
in <xref target="RFC5652"/> section 9.1, with RecipientInfo type
KeyTransRecipientInfo containing the issuer and serial number of a suitable
certificate. They MAY support additional RecipientInfo types.
They MAY additionally use the "SignedData" type described in
<xref target="RFC5652"/> section 5.1. In either case, the optional
"eContent" field in EncapsulatedContentInfo MUST be omitted. That is, the data
itself is external, being the canonicalized form of the bundle. </t>
<t>Because this ciphersuite requires that the security result be in the
second, correlated BAB, the content of the "MessageAuthenticationCode"
field in AuthenticatedData is ignored, although the field has to be
present. </t>
<t>In the absence of key information the receiver is expected to be able
to find the correct key based on the sending identity.
The sending identity MAY be known from the security-source field or
the content of a previous-hop block in the bundle. It MAY also be
determined using implementation-specific means such as the
convergence layer. </t>
</section>
<section title="PIB-RSA-SHA256" toc="default" anchor="PIBrsasha">
<t>The PIB-RSA-SHA256 ciphersuite has ciphersuite ID value 0x02.</t>
<t>If the bundle being signed has been fragmented before signing, then
we have to specify which bytes were signed in case the signed bundle
is subsequently fragmented for a second time. If the bundle is a
fragment, then the ciphersuite parameters MUST include a fragment-range
field, as described in <xref target="sec.PRF"/>,
specifying the offset and length of the signed fragment.
If the entire bundle is signed then these numbers MUST be omitted.</t>
<t>Implementations MUST support use of "SignedData" type as defined
in <xref target="RFC5652"/> section 5.1, with SignerInfo type
SignerIdentifier containing the issuer and serial number of a suitable
certificate. The optional
"eContent" field in EncapsulatedContentInfo MUST be omitted. That is, the data
itself is external, being the canonicalized form of the bundle. </t>
<t>Because the signature field in SignedData SignatureValue is a
security-result field, the entire key information item MUST be
placed in the block's security-result field, rather than
security-parameters. </t>
<t>PIB-RSA-SHA256 uses the mutable canonicalisation algorithm
<xref target="mutableC14N"/>, with the security-result data field for only
the "current" block being excluded from the canonical form. The resulting
canonical form of the bundle is the input to the signing process.
This ciphersuite requires the use of a single instance of the PIB.</t>
<t>RSA is used with SHA256 as specified for the id-sha256 PKCSv2.1
signature scheme in <xref target="RFC4055" />. The output
of the signing process is the SignatureValue field for the PIB.</t>
<t>"Commensurate strength" cryptography is generally held to be a good idea. A
combination of RSA with SHA256 is reckoned to require a 3076 bit RSA key
according to this logic. Few implementations will choose this length by default
(and probably some just won't support such long keys). Since this is an
experimental protocol, we expect that 1024 or 2048 bit RSA keys will be used in
many cases, and that that will be fine since we also expect that the hash
function "issues" will be resolved before any standard would be derived from
this protocol.</t>
</section>
<section title="PCB-RSA-AES128-PAYLOAD-PIB-PCB" toc="default" anchor="rsaaes">
<t>The PCB-RSA-AES128-PAYLOAD-PIB-PCB ciphersuite has ciphersuite ID value 0x003.</t>
<t>This scheme encrypts PIBs, PCBs and the payload.
The key size for this ciphersuite is 128 bits.</t>
<t>Encryption is done using the AES algorithm in Galois/Counter Mode (GCM)
as described in <xref target="RFC5084"/> [Note:
parts of the following description are borrowed from RFC 4106]. </t>
<t>The choice of GCM avoids expansion of the payload, which causes
problems with fragmentation/reassembly and custody transfer.
GCM also includes authentication, essential in
preventing attacks that can alter the decrypted plaintext or even
recover the encryption key. </t>
<t>GCM is a block cipher mode of operation providing both
confidentiality and data origin authentication. The GCM
authenticated encryption operation has four inputs: a secret key,
an initialization vector (IV), a plaintext, and an input for
additional authenticated data (AAD) which is not used here.
It has two outputs, a ciphertext whose length is identical to
the plaintext, and an authentication tag, also known as
the Integrity Check Value (ICV). </t>
<t>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 has the
following layout </t>
<figure anchor="nonce">
<preamble>
</preamble>
<artwork>
+----------------+----------------+----------------+----------------+
| salt |
+----------------+----------------+----------------+----------------+
| |
| initialization vector |
| |
+----------------+----------------+----------------+----------------+
</artwork>
<postamble>
Nonce format.
</postamble>
</figure>
<t>The salt field is a four-octet value, usually chosen at random.
It MUST be the same for all PCBs which have the same correlator value.
The salt need not be kept secret.</t>
<t>The initialization vector (IV) is an eight-octet value, usually
chosen at random. It MUST be different for all PCBs which have the
same correlator value. The value need not be kept secret. </t>
<t>The key (bundle encryption key, BEK) is a sixteen-octet (128 bits)
value, usually chosen at random.
The value MUST be kept secret, as described below. </t>
<t>The integrity check value is a sixteen-octet value used
to verify that the protected data has not been altered.
The value need not be kept secret. </t>
<t>This ciphersuite requires the use of a single PCB instance
to deal with payload confidentiality. If the bundle already contains PIBs
or PCBs then the ciphersuite will create additional correlated blocks
to protect these PIBs and PCBs. These "additional" blocks replace the
original blocks on a one-for-one basis, so the number of blocks remains
unchanged. All these related blocks MUST have
the same correlator value. The term "first PCB" in this section
refers to the single PCB if there is only one or, if there are several,
then to the one containing the key information.
This MUST be the first of the set. </t>
<t>First PCB - the first PCB MAY contain a correlator value, and MAY
specify security-source and/or security-destination in the eid-list.
If not specified, the bundle-source and bundle-destination respectively
are used for these values, as with other ciphersuites. The block MUST
contain security-parameters and security-result fields. Each field MAY
contain several items formatted as described in <xref target="sec.PRF"/>.</t>
<t>Security-parameters</t>
<t> <list>
<t>key information</t>
<t>salt</t>
<t>IV (this instance applies only to payload)</t>
<t>fragment offset and length, if bundle is a fragment</t>
</list> </t>
<t>Security-result</t>
<t> <list>
<t>ICV</t>
</list> </t>
<t>Subsequent PCBs MUST contain a correlator value to link them
to the first PCB. Security-source and security-destination are
implied from the first PCB, however see the discussion in
<xref target="sec.PCB"/> concerning eid-list entries.
They MUST contain security-parameters and security-result
fields as follows:</t>
<t>Security-parameters</t>
<t> <list>
<t>IV for this specific block</t>
</list> </t>
<t>Security-result</t>
<t> <list>
<t>encapsulated block</t>
</list> </t>
<t>The security-parameters and security-result fields in the
subsequent PCBs MUST NOT contain any items other than
these two. Items such as key and salt are supplied in the
first PCB and MUST NOT be repeated. </t>
<t>Implementations MUST support use of "Enveloped-data" type as defined
in <xref target="RFC5652"/> section 6, with RecipientInfo type
KeyTransRecipientInfo containing the issuer and serial number of a suitable
certificate. They MAY support additional RecipientInfo types.
The optional "eContent" field in EncryptedContentInfo MUST be omitted.
That is, the data itself is external, being the payload of the bundle. </t>
<t>The Integrity Check Value from the AES-GCM encryption of the payload
is placed in the security-result field of the first PCB. </t>
<t>If the bundle being encrypted is a fragment-bundle
we have to specify which bytes are encrypted in case the bundle
is subsequently fragmented again. If the bundle is a fragment
the ciphersuite parameters MUST include a fragment-range
field, as described in <xref target="sec.PRF"/>,
specifying the offset and length of the encrypted fragment.
Note that this is not the same pair of fields which appear in the
primary block as "offset and length". The "length" in this case
is the length of the fragment, not the original length.
If the bundle is not a fragment then this field MUST be omitted.</t>
<t>The confidentiality processing for payload and other blocks is
different, mainly because the payload might be fragmented later
at some other node. </t>
<t>For the payload, only the bytes of the bundle payload field are
affected, being replaced by ciphertext. The salt, IV and key values
specified in the first PCB are used to encrypt the payload, and the
resultant authentication tag (ICV) is placed in an ICV item
in the security-result field of that first PCB. The other bytes
of the payload block, such as type, flags and length, are not
modified. </t>
<t>For each PIB or PCB to be protected, the entire original block is
encapsulated in a "replacing" PCB. This replacing PCB is placed in
the outgoing bundle in the same position as the original block,
PIB or PCB. As mentioned above, this is one-for-one replacement and
there is no consolidation of blocks or mixing of data in any way. </t>
<t>The encryption process uses AES-GCM with the salt and key values
from the first PCB, and an IV unique to this PCB. The process creates
ciphertext for the entire original block, and an authentication tag
for validation at the security destination. For this encapsulation
process, unlike the processing of the bundle payload, the
authentication tag is appended to the ciphertext for the block and
the combination is stored into the "encapsulated block" item in
security-result. </t>
<t>The replacing block, of course, also has the same correlator value
as the first PCB with which it is associated. It also contains the
block-specific IV in security-parameters, and the combination of
original-block-ciphertext and authentication tag, stored as an
"encapsulated block" item in security-result. </t>
<t>If the payload was fragmented after encryption then all those
fragments MUST be present and reassembled before decryption.
This process might be repeated several times at different
destinations if multiple fragmentation actions have occurred. </t>
<t>The size of the GCM counter field limits the payload size to
2^39 - 256 bytes, about half a terabyte. A future revision of
this specification will address the issue of handling payloads
in excess of this size. </t>
</section>
<section title="ESB-RSA-AES128-EXT" toc="default" anchor="ESBrsaaes">
<t>The ESB-RSA-AES128-EXT ciphersuite has ciphersuite ID value 0x004.</t>
<t>This scheme encrypts non-payload-related blocks. It MUST NOT be used
to encrypt PIBs, PCBs or primary or payload blocks.
The key size for this ciphersuite is 128 bits.</t>
<t>Encryption is done using the AES algorithm in Galois/Counter Mode (GCM)
as described in <xref target="RFC5084"/> [Note:
parts of the following description are borrowed from RFC 4106]. </t>
<t>GCM is a block cipher mode of operation providing both
confidentiality and data origin authentication. The GCM
authenticated encryption operation has four inputs: a secret key,
an initialization vector (IV), a plaintext, and an input for
additional authenticated data (AAD) which is not used here.
It has two outputs, a ciphertext whose length is identical to
the plaintext, and an authentication tag, also known as
the Integrity Check Value (ICV). </t>
<t>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 has the
following layout </t>
<figure anchor="nonceESB">
<preamble>
</preamble>
<artwork>
+----------------+----------------+---------------------------------+
| salt |
+----------------+----------------+---------------------------------+
| |
| initialization vector |
| |
+----------------+----------------+---------------------------------+
</artwork>
<postamble>
Nonce format.
</postamble>
</figure>
<t>The salt field is a four-octet value, usually chosen at random.
It MUST be the same for all ESBs which have the same correlator value.
The salt need not be kept secret.</t>
<t>The initialization vector (IV) is an eight-octet value, usually
chosen at random. It MUST be different for all ESBs which have the
same correlator value. The value need not be kept secret. </t>
<t>The data encryption key is a sixteen-octet (128 bits)
value, usually chosen at random.
The value MUST be kept secret, as described below. </t>
<t>The integrity check value is a sixteen-octet value used
to verify that the protected data has not been altered.
The value need not be kept secret. </t>
<t>This ciphersuite replaces each BP extension block to be protected
with a "replacing" ESB, and each can be individually specified. </t>
<t>If a number of related BP extension blocks are to be protected they
can be grouped as a correlated set and protected using a single key.
These blocks replace the original blocks on a one-for-one basis, so
the number of blocks remains unchanged. All these related blocks MUST
have the same correlator value. The term "first ESB" in this section
refers to the single ESB if there is only one or, if there are several,
then to the one containing the key or key-identifier.
This MUST be the first of the set. If the blocks are individually
specified then there is no correlated set and each block is its own
"first ESB".</t>
<t>First ESB - the first ESB MAY contain a correlator value, and MAY
specify security-source and/or security-destination in the eid-list.
If not specified, the bundle-source and bundle-destination respectively
are used for these values, as with other ciphersuites. The block MUST
contain security-parameters and security-result fields. Each field MAY
contain several items formatted as described in <xref target="sec.PRF"/>.</t>
<t>Security-parameters</t>
<t> <list>
<t>key information</t>
<t>salt</t>
<t>IV for this specific block</t>
</list> </t>
<t>Security-result</t>
<t> <list>
<t>encapsulated block</t>
</list> </t>
<t>Subsequent ESBs MUST contain a correlator value to link them
to the first ESB. Security-source and security-destination are
implied from the first ESB, however see the discussion in
<xref target="sec.PCB"/> concerning eid-list entries.
They MUST contain security-parameters and security-result
fields as follows:</t>
<t>Security-parameters</t>
<t> <list>
<t>IV for this specific block</t>
</list> </t>
<t>Security-result</t>
<t> <list>
<t>encapsulated block</t>
</list> </t>
<t>The security-parameters and security-result fields in the
subsequent ESBs MUST NOT contain any items other than
these two. Items such as key and salt are supplied in the
first ESB and MUST NOT be repeated. </t>
<t>Implementations MUST support use of "Enveloped-data" type as defined
in <xref target="RFC5652"/> section 6, with RecipientInfo type
KeyTransRecipientInfo containing the issuer and serial number of a suitable
certificate. They MAY support additional RecipientInfo types.
The optional "eContent" field in EncryptedContentInfo MUST be omitted.
That is, the data itself is external, being the content of the
block being protected. </t>
<t>For each block to be protected, the entire original block is
encapsulated in a "replacing" ESB. This replacing ESB is placed in
the outgoing bundle in the same position as the original block.
As mentioned above, this is one-for-one replacement and
there is no consolidation of blocks or mixing of data in any way. </t>
<t>The encryption process uses AES-GCM with the salt and key values
from the first ESB, and an IV unique to this ESB. The process creates
ciphertext for the entire original block, and an authentication tag
for validation at the security destination. The
authentication tag is appended to the ciphertext for the block and
the combination is stored into the "encapsulated block" item in
security-result. </t>
<t>The replacing block, of course, also has the same correlator value
as the first ESB with which it is associated. It also contains the
block-specific IV in security-parameters, and the combination of
original-block-ciphertext and authentication tag, stored as an
"encapsulated block" item in security-result. </t>
</section>
</section>
<section title="Key Management" toc="default" anchor="sec.keymgmt">
<t>Key management in delay tolerant networks is recognized as a
difficult topic and is one that this specification does not attempt
to solve. However, solely in order to support implementation and
testing,implementations SHOULD support:</t>
<t> <list>
<t>- The use of well-known RSA public keys for all ciphersuites.</t>
<t>- Long-term pre-shared-symmetric keys for the BAB-HMAC ciphersuite.</t>
</list> </t>
<t>Since endpoint IDs are URIs and URIs can be placed in X.509
<xref target="RFC3280"/> public key certificates (in
the subjectAltName extension) implementations SHOULD support this way of
distributing public keys. Implementations SHOULD NOT be very strict in how they
process X.509 though, for example, it would probably not be correct to insist
on Certificate Revocation List (CRL) checking in many DTN contexts.</t>
</section>
<section title="Default Security Policy" toc="default" anchor="sec.Defaults">
<t>Every node serves as a Policy Enforcement Point insofar as it enforces
some policy that controls the forwarding and delivery of bundles via one or
more convergence layer protocol implementation. Consequently, every node SHALL
have and operate according to
its own configurable security policy, whether the policy be explicit or
default. The policy SHALL specify: </t>
<t> <list>
<t>Under what conditions received bundles SHALL be forwarded. </t>
<t>Under what conditions received bundles SHALL be required to include valid
BABs. </t>
<t>Under what conditions the authentication information provided in a bundle's
BAB SHALL be deemed adequate to authenticate the bundle. </t>
<t>Under what conditions received bundles SHALL be required to have valid PIBs and/or PCBs.
</t>
<t>Under what conditions the authentication information provided in a bundle's
PIB SHALL be deemed adequate to authenticate the bundle. </t>
<t>Under what conditions a BAB SHALL be added to a received bundle before that
bundle is forwarded. </t>
<t>Under what conditions a PIB SHALL be added to a received bundle before that
bundle is forwarded. </t>
<t>Under what conditions a PCB SHALL be added to a received bundle before that
bundle is forwarded. </t>
<t>Under what conditions an ESB SHALL be applied to one or more blocks in
a received bundle before that bundle is forwarded. </t>
<t>The actions that SHALL be taken in the event that a received bundle does not
meet the receiving node's security policy criteria. </t>
</list> </t>
<t>This specification does not address how security policies get distributed to
nodes. It only REQUIRES that nodes have and enforce security policies. </t>
<t>If no security policy is specified at a given node, or if a security policy
is only partially specified, that node's default policy regarding unspecified
criteria SHALL consist of the following:</t>
<t> <list>
<t>Bundles that are not well-formed do not meet the security policy criteria.
</t>
<t>The mandatory ciphersuites MUST be used.</t>
<t>All bundles received MUST have a BAB which MUST be
verified to contain a valid security result. If the bundle does not have a BAB,
then the bundle MUST be discarded
and processed no further; a bundle status report indicating the authentication
failure MAY be generated. </t>
<t>No received bundles SHALL be required to have a PIB; if a received bundle
does have a PIB, however, the PIB can be ignored unless the receiving
node is the PIB-dest, in which case the PIB MUST be verified. </t>
<t>No received bundles SHALL be required to have a PCB; if a received bundle
does have a PCB, however, the PCB can be ignored unless the receiving
node is the PCB-dest, in which case the PCB MUST be processed.
If processing of a PCB yields a PIB, that PIB SHALL be processed
by the node according to the node's security policy. </t>
<t>A PIB SHALL NOT be added to a bundle before sourcing or forwarding it.</t>
<t>A PCB SHALL NOT be added to a bundle before sourcing or forwarding it.</t>
<t>A BAB MUST always be added to a bundle before that bundle is forwarded.
</t>
<t>If a destination node receives a bundle that has a PIB-dest but
the value in that PIB-dest is not the EID of the destination node,
the bundle SHALL be delivered at that destination node.
</t>
<t>If a destination node receives a bundle that has an ESB-dest but
the value in that ESB-dest is not the EID of the destination node,
the bundle SHALL be delivered at that destination node.
</t>
<t>If a received bundle does not satisfy the node's security policy for any
reason, then the bundle MUST be discarded and processed no further; in this
case, a bundle deletion status report (see the Bundle Protocol
<xref target="DTNBP"/>) indicating the failure MAY be generated. </t>
</list> </t>
</section>
<section title="Security Considerations">
<t>If a BAB ciphersuite uses digital signatures but doesn't include
the security destination (which for a BAB is the next host), then this allows
the bundle to be sent to some node other than the intended adjacent node.
Because the BAB will still authenticate, the receiving node might erroneously accept
and forward the bundle. When asymmetric BAB ciphersuites are used, the security
destination field SHOULD therefore be included in the BAB.</t>
<t>If a bundle's PIB-dest is not the same as its destination, then some node
other than the destination (the node identified as the PIB-dest) is expected to
validate the PIB security result while the bundle is en route. However, if for
some reason the PIB is not validated, there is no way for the destination to
become aware of this. Typically, a PIB-dest will remove the PIB from the bundle
after verifying the PIB and before forwarding it. However, if there is a
possibility that the PIB will also be verified at a downstream node, the
PIB-dest will leave the PIB in the bundle. Therefore, if a destination receives
a bundle with a PIB that has a PIB-dest (which isn't the destination), this
might, but does not necessarily, indicate a possible problem.</t>
<t>If a bundle is fragmented after being forwarded by its PIB-source but before
being received by its PIB-dest, the payload in the bundle MUST be reassembled
before validating the PIB security result in order for the security result to
validate correctly. Therefore, if the PIB-dest is not capable of performing
payload reassembly, its utility as a PIB-dest will be limited to validating
only those bundles that have not been fragmented since being forwarded from
the PIB-source. Similarly, if a bundle is fragmented after being forwarded
by its PIB-source but before being received by its PIB-dest, all fragments
MUST be received at that PIB-dest in order for the bundle payload to be able
to be reassembled. If not all fragments are received at the PIB-dest node,
the bundle will not be able to be authenticated, and will therefore never
be forwarded by this PIB-dest node.</t>
<t>Specification of a security-destination other than the bundle destination
creates a routing requirement that the bundle somehow be directed to the
security-destination node on its way to the final destination.
This requirement is presently private to the ciphersuite, since routing
nodes are not required to implement security processing.</t>
</section>
<section title="Conformance" toc="conf">
<t>As indicated above, this document describes both BSP and ciphersuites.
A conformant implementation MUST implement both BSP support and the four
ciphersuites described in <xref target="ciphersuites"/>. It MAY also
support other ciphersuites.</t>
<t>Implementations that support BSP but not all four mandatory
ciphersuites MUST claim only "restricted compliance" with this specification,
even if they provide other ciphersuites.</t>
<t>All implementations are strongly RECOMMENDED to provide at least a
BAB ciphersuite. A relay node, for example, might not deal with end-to-end
confidentiality and data integrity but it SHOULD exclude
unauthorized traffic and perform hop-by-hop bundle verification.</t>
</section>
<section title="IANA Considerations">
<t>None at this time. If the bundle protocol becomes a standards track
protocol, then we may want to consider having IANA establish a register of
block types, and in particular for this specification a separate register of
ciphersuite specifications.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country>
</postal>
<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<author initials="J." surname="Reynolds" fullname="Joyce K. Reynolds">
<organization abbrev="ISI">USC/Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>
<phone>+1 310 822 1511</phone>
<facsimile>+1 310 823 6714</facsimile>
<email>jkrey@isi.edu</email>
</address>
</author>
<date month="October" year="1997"/>
</front>
<seriesInfo name="RFC" value="2119"/>
</reference>
<reference anchor="DTNBP">
<front>
<title>Bundle Protocol Specification</title>
<author initials="K." surname="Scott" fullname="Dr. Keith L. Scott">
<organization>The MITRE Corporation</organization>
<address>
<postal>
<street>7515 Colshire Drive</street>
<city>McLean</city>
<region>VA</region>
<code>22102</code>
<country>US</country>
</postal>
<phone>+1 703-983-6547</phone>
<email>kscott@mitre.org</email>
</address>
</author>
<author initials="S." surname="Burleigh" fullname="Scott C. Burleigh">
<organization/>
</author>
<date month="November" year="2007"/>
</front>
<seriesInfo name="RFC" value="5050"/>
</reference>
<reference anchor="DTNMD">
<front>
<title>Delay-Tolerant Networking Metadata Extension Block</title>
<author initials="S.F." surname="Symington" fullname="Susan Flynn Symington">
<organization>The MITRE Corporation</organization>
<address>
<postal>
<street>7515 Colshire Drive</street>
<city>McLean</city>
<region>VA</region>
<code>22102</code>
<country>US</country>
</postal>
<phone>+1 (703) 983-7209</phone>
<email>susan@mitre.org</email>
<uri>http://mitre.org/</uri>
</address>
</author>
<date month="June" year="2007"/>
</front>
<seriesInfo name="draft-irtf-dtnrg-bundle-metadata-block-00.txt" value=""/>
</reference>
<reference anchor="RFC2104">
<front>
<title abbrev="HMAC">HMAC: Keyed-Hashing for Message Authentication</title>
<author initials="H." surname="Krawczyk" fullname="Hugo Krawczyk">
<organization>IBM, T.J. Watson Research Center</organization>
<address>
<postal>
<street>P.O.Box 704</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>
<email>hugo@watson.ibm.com</email>
</address>
</author>
<author initials="M." surname="Bellare" fullname="Mihir Bellare">
<organization>
University of California at San Diego, Dept of Computer Science and Engineering
</organization>
<address>
<postal>
<street>9500 Gilman Drive</street>
<street>Mail Code 0114</street>
<city>La Jolla</city>
<region>CA</region>
<code>92093</code>
<country>US</country>
</postal>
<email>mihir@cs.ucsd.edu</email>
</address>
</author>
<author initials="R." surname="Canetti" fullname="Ran Canetti">
<organization>IBM T.J. Watson Research Center</organization>
<address>
<postal>
<street>P.O.Box 704</street>
<city>Yorktown Heights</city>
<region>NY</region>
<code>10598</code>
<country>US</country>
</postal>
<email>canetti@watson.ibm.com</email>
</address>
</author>
<date year="1997" month="February"/>
<abstract>
<t>
This document describes HMAC, a mechanism for message authentication using cryptographic
hash functions. HMAC can be used with any iterative cryptographic hash function, e.g.,
MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of
HMAC depends on the properties of the underlying hash function.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2104"/>
<format type="TXT" octets="22297" target="ftp://ftp.isi.edu/in-notes/rfc2104.txt"/>
</reference>
<reference anchor="RFC3280">
<front>
<title>
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
</title>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization/>
</author>
<author initials="W." surname="Polk" fullname="W. Polk">
<organization/>
</author>
<author initials="W." surname="Ford" fullname="W. Ford">
<organization/>
</author>
<author initials="D." surname="Solo" fullname="D. Solo">
<organization/>
</author>
<date year="2002" month="April"/>
</front>
<seriesInfo name="RFC" value="3280"/>
</reference>
<reference anchor="RFC5652">
<front>
<title>Cryptographic Message Syntax (CMS)</title>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization/>
</author>
<date year="2004" month="July"/>
</front>
<seriesInfo name="RFC" value="3852"/>
</reference>
<reference anchor="RFC3370">
<front>
<title>Cryptographic Message Syntax (CMS) Algorithms</title>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization/>
</author>
<date year="2002" month="August"/>
</front>
<seriesInfo name="RFC" value="3370"/>
</reference>
<reference anchor="RFC4055">
<front>
<title>
Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
</title>
<author initials="J." surname="Schaad" fullname="J. Schaad">
<organization/>
</author>
<author initials="B." surname="Kaliski" fullname="B. Kaliski">
<organization/>
</author>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization/>
</author>
<date year="2005" month="June"/>
</front>
<seriesInfo name="RFC" value="4055"/>
<format type="TXT" octets="57479" target="ftp://ftp.isi.edu/in-notes/rfc4055.txt"/>
</reference>
<reference anchor="RFC4106">
<front>
<title>The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)</title>
<author initials="J." surname="Viega" fullname="J. Viega"><organization/></author>
<author initials="D." surname="McGrew" fullname="D. McGrew"><organization/></author>
<date year="2005" month="June"/>
</front>
<seriesInfo name="RFC" value="4106"/>
<format type="TXT" octets="51001" target="ftp://ftp.isi.edu/in-notes/rfc4106.txt"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="DTNarch">
<front>
<title>Delay-Tolerant Network Architecture</title>
<author initials="V." surname="Cerf" fullname="Dr. Vinton G. Cerf">
<organization abbrev="Google">Google, Inc.</organization>
<address>
<postal>
<street>1818 Library Street</street>
<street>Suite 400</street>
<city>Reston</city>
<region>VA</region>
<code>20190</code>
<country>US</country>
</postal>
<phone>+ 1 202-370-5637</phone>
<email>vint@google.com</email>
</address>
</author>
<author initials="S." surname="Burleigh" fullname="Scott C. Burleigh">
<organization/>
</author>
<author initials="R." surname="Durst" fullname="Robert C. Durst">
<organization/>
</author>
<author initials="K." surname="Fall" fullname="Dr. Kevin Fall">
<organization/>
</author>
<author initials="A." surname="Hooke" fullname="Adrian J. Hooke">
<organization/>
</author>
<author initials="K." surname="Scott" fullname="Dr. Keith L. Scott">
<organization/>
</author>
<author initials="L." surname="Torgerson" fullname="Leigh Torgerson">
<organization/>
</author>
<author initials="H." surname="Weiss" fullname="Howard S. Weiss">
<organization/>
</author>
<date month="April" year="2007"/>
</front>
<seriesInfo name="RFC" value="4838"/>
<format type="TXT" octets="89265" target="ftp://ftp.rfc-editor.org/in-notes/rfc4838.txt"/>
</reference>
<reference anchor="DTNRB">
<front>
<title>Delay-Tolerant Network Retransmission Block</title>
<author initials="S." surname="Symington" fullname="Susan Symington">
<organization>The MITRE Corporation</organization>
<address>
<postal>
<street>7515 Colshire Drive</street>
<city>McLean</city>
<region>VA</region>
<code>22102</code>
<country>US</country>
</postal>
<phone>+1 703-983-7209</phone>
<email>susan@mitre.org</email>
</address>
</author>
<date month="April" year="2007"/>
</front>
<seriesInfo name="draft-irtf-dtnrg-bundle-retrans-00.txt," value="work-in-progress"/>
</reference>
<reference anchor="RFC5084">
<front>
<title>Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)</title>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization/>
</author>
<date year="2007" month="November"/>
</front>
<seriesInfo name="RFC" value="5084"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:22:41 |