DTN Research Group S. Symington
Internet-Draft The MITRE Corporation
Expires: December 10, 2005 S. Farrell
Trinity College Dublin
H. Weiss
SPARTA, Inc.
June 8, 2005
Bundle Security Protocol Specification
draft-irtf-dtnrg-bundle-security-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines the bundle security protocol, which provides
data integrity and confidentiality services. We also describe
various bundle security considerations including policy options.
Symington, et al. Expires December 10, 2005 [Page 1]
Internet-Draft Bundle Security Protocol June 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Related Documents . . . . . . . . . . . . . . . . . . . . 4
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Security-Specific Bundle Service Primitives and Parameters . 7
2.1 The Delivery Options Parameter . . . . . . . . . . . . . . 7
2.2 Data indications . . . . . . . . . . . . . . . . . . . . . 8
2.3 The At-Most-Once-Delivery Option . . . . . . . . . . . . . 8
3. Security Headers . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Abstract Security Header . . . . . . . . . . . . . . . . . 10
3.2 Bundle Authentication Header . . . . . . . . . . . . . . . 12
3.3 Payload Security Header . . . . . . . . . . . . . . . . . 13
3.4 Confidentiality Header . . . . . . . . . . . . . . . . . . 13
3.5 PSH and CH combinations . . . . . . . . . . . . . . . . . 14
4. Security Processing . . . . . . . . . . . . . . . . . . . . 15
4.1 Bundle Transmission Requests . . . . . . . . . . . . . . . 15
4.2 Canonicalisation of bundles . . . . . . . . . . . . . . . 17
4.3 Creating a Confidentiality Header . . . . . . . . . . . . 19
4.4 Creating the Payload Security Header . . . . . . . . . . . 19
4.5 Creating the Bundle Authentication Header . . . . . . . . 20
4.6 Bundles received from other bundle protocol agents . . . . 20
4.7 Local Bundle Delivery . . . . . . . . . . . . . . . . . . 20
4.8 Optionally checking for Replays . . . . . . . . . . . . . 21
4.9 Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 21
4.10 Bundle Fragmentation and Reassembly . . . . . . . . . . 22
4.11 Custodial Retransmission and Release . . . . . . . . . . 23
4.12 Bundle Status Report Status Flags . . . . . . . . . . . 23
4.13 Convergence Layer Security Services . . . . . . . . . . 24
5. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1 EntireBundleHMAC Ciphersuite . . . . . . . . . . . . . . . 25
5.2 HeadOfBundleHMAC Ciphersuite . . . . . . . . . . . . . . . 26
5.3 EntireBundleSig Ciphersuite . . . . . . . . . . . . . . . 26
5.4 HeadOfBundleSig Ciphersuite . . . . . . . . . . . . . . . 27
5.5 CombinationSig Ciphersuite . . . . . . . . . . . . . . . . 27
5.6 EntireBundleMAC . . . . . . . . . . . . . . . . . . . . . 28
5.7 TP-type Ciphersuites . . . . . . . . . . . . . . . . . . . 28
6. Default Values . . . . . . . . . . . . . . . . . . . . . . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1 Normative References . . . . . . . . . . . . . . . . . . . 35
9.2 Informative References . . . . . . . . . . . . . . . . . . 35
Editorial Comments . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40
Intellectual Property and Copyright Statements . . . . . . . 41
Symington, et al. Expires December 10, 2005 [Page 2]
Internet-Draft Bundle Security Protocol June 2005
1. Introduction
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 [1].
This document defines security features for the bundle protocol [2]
intended for use in delay tolerant networks, in order to provide the
DTN security services as described in the DTN Security Overview and
Motivations document [5].
The bundle protocol is used in DTNs which overlay on top of multiple
networks, some of which are 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.
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 that the DTN be protected from
unauthorized use, and this stressed environment poses unique
challenges on 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.
The security features described in this document are RECOMMENDED for
deployment with the Bundle Protocol. Bundle Protocol implementations
SHOULD support these features, except where they cannot, e.g. due to
processor or bandwidth constraints. [Comment.1]
Implementation of these security features is not mandatory because it
is recognized that some bundle nodes will be so constrained that they
are simply unable to use the mechanisms defined here. For example,
if a communications subsystem is limited to emitting 40-byte
segments, then we cannot use a 2048-bit RSA signature to secure such
segments.
The implications of omitting or not using these security features
however, need to be fully understood, especially with regard to the
ability of an implementation to interact with bundle protocol
implementations that do implement security and that may be configured
Symington, et al. Expires December 10, 2005 [Page 3]
Internet-Draft Bundle Security Protocol June 2005
to require that incoming bundles include specific security headers.
[Comment.2]
1.1 Related Documents
This document is best read and understood within the context of the
following other DTN documents: [Comment.3]
The Delay-Tolerant Network Architecture [3] defines the
architecture for delay-tolerant networks, but does not discuss
security at any length.
The DTN Bundle Protocol [2] defines the format and processing of
the headers used to implement the bundle protocol, excluding the
security-specific headers defined here.
The Delay-Tolerant Network Security Overview and Motivations [5]
document provides an informative overview and high-level
description of DTN security; it defines a security architecture
for DTNs by describing the aspects of the DTN architecture
requiring protection and the security mechanisms that can be used
to provide this protection, along with motivating rationale.
1.2 Terminology
We introduce the following terminology for purposes of clarity:
source - the bundle node (application, bundle protocol agent,
etc.) from which the application data unit originates
destination - the bundle node (application, bundle protocol agent,
etc.) to which the application data unit is ultimately destined
sender - the bundle protocol agent that forwarded the bundle on
its most recent hop
recipient or "next hop" - the neighboring bundle protocol agent to
which a sender forwards a bundle.
[]
In the figure below, which is adapted from figure 1 in the Bundle
Protocol Specification [2], four bundle protocol agents (denoted BPA
1, BPA 2, BPA 3, and BPA 4) that implement the bundle protocol reside
above some transport layer(s). Three distinct transport and network
protocols (denoted T1/N1, T2/N2, and T3/N3) are also shown. Bundle
protocol agents BPA 1 and BPA 4 expose the bundle service interface
Symington, et al. Expires December 10, 2005 [Page 4]
Internet-Draft Bundle Security Protocol June 2005
to BundleNodeX and BundleNodeY, respectively.
+-----------+ +-----------+
|BundleNodeX| |BundleNodeY|
+---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+
|BPA 1 v | | ^ BPA 2 v | | ^ BPA 3 v | | ^ BPA 4 |
+---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+
|Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 |
+---------v-+ +-^---------v-+ +-^---------v + +-^---------+
|Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 |
+---------v-+ +-^---------v + +-^---------v-+ +-^---------+
| >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ |
+-----------+ +------------+ +-------------+ +-----------+
| | | |
|<-- An Internet --->| |<--- An Internet --->|
| | | |
BPA = "Bundle Protocol Agent"--the implementation of the bundle
protocol at the bundle layer
The protocol stacks on four DTN nodes.
Figure 1
Bundle node "BundleNodeX" originates data that is sent to its
underlying bundle protocol agent BPA1. That data is formatted into a
bundle and forwarded to BPA2, BPA3, and BPA4 and then transmitted up
to bundle node "BundleNodeY". BundleNodeX is the source and
BundleNodeY is the destination for this data. BPA1 is the first
sender, and BPA2 is the first recipient; BPA2 then becomes the
sender, and BPA3 the recipient; BPA3 then becomes the last sender,
and BPA4 the last recipient.
If bundle protocol agent BPA1 originates data (for example, an
administrative payload such as a bundle status report or custodial
signal), which is then forwarded on to BPA2, BPA3, and finally BPA4,
then BPA1 is the source of the bundle (as well as being the first
sender of the bundle) and BPA4 is the destination of the bundle (as
well as being the final recipient).
We introduce the following security-specific DTN terminology:
[Comment.5][Comment.6]
security-source - a bundle node that adds an "end-to-end" security
header
Symington, et al. Expires December 10, 2005 [Page 5]
Internet-Draft Bundle Security Protocol June 2005
security-destination - a bundle node that processes an "end-to-
end" security header
Referring to figure 1 again:
If the bundle that originates at BundleNodeX as source is given a
Payload Security Header (PSH) by BPA1, then BPA1 is the security-
source of this bundle, even though BundleNodeX is its source.
If the bundle that originates at BundleNodeX as source is given a
Payload Security Header (PSH) by BPA2, then BPA2 is the security-
source of this bundle, even though BundleNodeX is its source.
If the bundle that originates at BundleNodeX as source is given a
Confidentiality Header (CH) by BPA1 protected using a key held by
BPA2, then the BPA1 is the security-source of this bundle, and BPA-2
is the security destination.
Symington, et al. Expires December 10, 2005 [Page 6]
Internet-Draft Bundle Security Protocol June 2005
2. Security-Specific Bundle Service Primitives and Parameters
2.1 The Delivery Options Parameter
[Comment.7][Comment.8]
The bundle service consumes a Send.request primitive that is used by
the bundle node to request transmission of an application data unit
from the source bundle endpoint to a destination bundle endpoint.
One of the parameters of this primitive is "delivery options".
The bundle service uses the Data.indication primitive to deliver the
content of a bundle to one or more bundle nodes indicated by the
bundle's destination endpoint. One of the parameters of this
primitive is also "delivery options".
The Delivery Options parameter indicates the optional security-
specific procedures to be followed when transmitting and delivering
the application data unit. Separate options MAY be specified for
each of the confidentiality, authentication and error detection
services. In each case, we use a ciphersuite ID to indicate how the
service is to be provided. The ciphersuite ID can be omitted,
leaving the decision up to the implementation. If the ciphersuite ID
is provided, the additional ciphersuite parameters MAY be provided.
The details of valid parameters are part of the definition of each of
the ciphersuites.
Even if the ciphersuite ID for a service is omitted, the
implementation MAY decide to apply that service, based on some policy
settings. However, if a ciphersuite ID is supplied, then the
implementation MUST NOT send the bundle without successfully applying
the required service.
The following service-specific parameters are defined:
Confidentiality - indicates that a CH header MUST be applied to
the bundle, and at least the bundle payload (and possibly other
bundle headers) MUST be encrypted appropriately[Comment.9]
Authentication - indicates that a PSH MUST be applied to the
bundle, and the (relevant parts of the) bundle digitally signed or
MACed appropriately
Error detection - indicates that a PSH MUST be applied to the
bundle and the (relevant parts of the) bundle digested
appropriately [Comment.10]
Notes:
Symington, et al. Expires December 10, 2005 [Page 7]
Internet-Draft Bundle Security Protocol June 2005
1) The above means that a given bundle can only use one of the
authentication or error detection services
2) Hop-by-hop authentication is not controlled using this
interface
3) Throughout this specification we use the standard security
usage of the acronym MAC - meaning "message authentication code"
2.2 Data indications
As with Send.request, Data.indication primitives SHOULD indicate the
security services which were applied to the message. In each case
the indication MUST contain a ciphersuite ID and MAY contain a
ciphersuite-specified ciphersuite parameters item. Note that the
ciphersuite parameters may differ between the Send.request and
Data.indication primitives, e.g. for a confidentiality item in a
Send.request, the security-destination will often be a parameter,
whereas the security-source is what is of interest for the
Data.indication (if the ciphersuite allows).
We define the following indications:
The presence of the Confidentiality item in the Data.indication
primitive indicates that the bundle contained a CH and that its
payload was encrypted. Note that it is possible that this bundle
protocol agent is not the CH security-destination, i.e. the
payload may have been decrypted by a bundle protocol agent earlier
in the route.
The presence of the Authentication Item in the Data.indication
primitive indicates that the bundle contained a PSH with an
authentication ciphersuite. Note that it is possible that this
bundle protocol agent is not the PSH security-destination, i.e.
the PSH MAY have been verified by a bundle protocol agent earlier
in the route.
The presence of the Error Detection item in the Data.indication
primitive indicates that the received bundle included a PSH with
an error detection ciphersuite.
2.3 The At-Most-Once-Delivery Option
The bundle service consumes a Register.request primitive that is used
to notify the bundle protocol agent of a bundle node's interest in
bundles destined for a specified bundle endpoint and of the action to
Symington, et al. Expires December 10, 2005 [Page 8]
Internet-Draft Bundle Security Protocol June 2005
take on the bundle node's behalf with regard to those bundles. One
of the parameters of this primitive is "at-most-once-delivery".
[Comment.11] If this parameter is set, then the bundle node
registering interest in receiving bundles is indicating that the
receiving bundle protocol agent SHALL check for replayed bundles,
discard duplicates, and deliver at most one copy of each received
bundle to the registering bundle node. If this parameter is not set,
the bundle node is indicating that the receiving bundle protocol
agent SHALL deliver all received bundle copies to the registering
bundle node. If this parameter is not set, the bundle protocol agent
MAY (subject to policy) deliver all bundles or else behave as if this
parameter had been set.[Comment.12]
A method that the receiving bundle protocol agent MAY [Comment.13]
use to detect duplicates is to look at the (source, timestamp) pair
value of each received bundle and determine if this pair value, which
uniquely identifies a bundle, has been received before. If it has,
then the bundle is a duplicate and SHALL be discarded. If it has
not, then the bundle SHALL be delivered to the bundle node and the
(source, timestamp) pair value SHALL be added to the list of pair
values already received by that bundle protocol agent.
Symington, et al. Expires December 10, 2005 [Page 9]
Internet-Draft Bundle Security Protocol June 2005
3. Security Headers
There are three security headers that MAY be included in a bundle as
listed in the Bundle Protocol [2]. These are the Bundle
Authentication Header (BAH), the Payload Security Header (PSH), and
the Confidentiality Header (CH).
The BAH is used to assure the authenticity of the bundle along a
single hop from sender to recipient.
The PSH is used to assure the authenticity of the bundle from the
PSH security-source, which creates the PSH, to the PSH security-
destination, which verifies the PSH authenticator. The
authentication information in the PSH may (if the ciphersuite
allows) be verified by any bundle protocol agent in between the
PSH security-source and the PSH security-destination that has
access to the cryptographic keys and revocation status information
required to do so.
The CH indicates that the bundle payload (and possibly other
bundle fields) has been encrypted while en route between the CH
security-source and the CH security-destination.
3.1 Abstract Security Header
Since the three security headers have most fields in common, we can
shorten the description of them if we first define an abstract
security header (ASH) and then specify each of the real headers in
terms of the fields which are present/absent in an ASH. Note that no
bundle ever contains an ASH, which is simply a specification artifact
An ASH consists of the following mandatory and optional fields:
[Comment.14]
Header-type - as in all bundle protocol headers except the primary
bundle header
Flags - as in all bundle protocol headers[Comment.15]
Length - the overall length of this header encoded as an SDNV-8
(see below). This includes the bytes required for the header type
and ciphersuite ID fields.
Ciphersuite ID - identifies the ciphersuite in use. This is one
byte long, though the top three bytes are used to indicate the
presence or absence of the three optional fields (see below).
Symington, et al. Expires December 10, 2005 [Page 10]
Internet-Draft Bundle Security Protocol June 2005
(optional) Ciphersuite parameters - parameters to be used with the
ciphersuite in use, e.g. a key identifier or initialization vector
(IV). This is encoded as an SDNV-8.
(optional) Security-source - specifies the security source for the
service. If this is omitted, then the source of the bundle is
assumed to be the security-source. This is encoded using the
normal bundle identity encoding scheme (see below).
(optional) Security-destination - specifies the security
destination for the service. If this is omitted, then the
destination of the bundle is assumed to be the security-
destination. This is encoded using the normal bundle identity
encoding scheme (see below).
Security result - contains the results of the appropriate
ciphersuite-specific calculation (e.g. a signature, or MAC or
encrypted session key). This is encoded as an SDNV-16.
The ciphersuite ID is an eight bit value with the top three bits
indicating which of the optional fields are present (value = "1") or
absent (value="0"). The remaining five bits indicate the
ciphersuite.
Some ciphersuites are specified in Section 5, which also specifies
the rules which MUST be satisfied by ciphersuite specifications.
Additional ciphersuites MAY be defined in separate specifications.
The structure of the ciphersuite ID byte is shown in Figure 2
src - the most significant bit (bit 7) indicates whether the ASH
contains an optional security source (value="1") or not
(value="0")
dest - the 2nd most significant bit (bit 6) indicates whether the
ASH contains an optional security destination (value="1") or not
(value="0")
parm - the 3rd most significant bit (bit 5) indicates whether the
ASH contains an optional ciphersuite parameters (value="1") or not
(value="0")
Symington, et al. Expires December 10, 2005 [Page 11]
Internet-Draft Bundle Security Protocol June 2005
Ciphersuite ID
Bit Bit Bit Bit Bit Bit Bit Bit
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+
|src |dest |parm | ciphersuite ID |
+-----+-----+-----+-----+-----+-----+-----+-----+
Figure 2
The Self-Delimiting Numeric Value (SDNV) scheme is a way of encoding
variable length values and is described in the Licklider Transmission
Protocol [4]. There are two variants described there: SDNV-8 and
SDNV-16 and we use both.
The security source and destination fields are encoded as are all
other bundle endpoint IDs using the schema/mark scheme specified in
the base Bundle Protocol Specification. [2]
A little bit more terminology: when the header is a PSH then we refer
to the PSH-source when we mean the security source field in the PSH.
Similarly we may refer to the CH-dest, meaning the security-
destination field of the CH.
3.2 Bundle Authentication Header
A BAH is an ASH with the following additional restrictions:
the header-type value MUST be 0x07 as defined in the Bundle
Protocol Specification [2]
the flags field MUST be present as defined in the Bundle Protocol
Specification
the ciphersuite ID MUST be documented as a hop-by-hop
authentication-ciphersuite
the ciphersuite parameters field MAY be present
the security-source field MUST NOT be present[Comment.16]
the security-destination field MUST NOT be present
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.
Symington, et al. Expires December 10, 2005 [Page 12]
Internet-Draft Bundle Security Protocol June 2005
3.3 Payload Security Header
A PSH is an ASH with the following additional restrictions:
the header-type value MUST be 0x08 as defined in the Bundle
Protocol Specification [2]
the flags field MUST be present as defined in the Bundle Protocol
Specification. It SHOULD indicate that the header does not need
to be duplicated on all fragments.
the ciphersuite ID MUST be documented as an end-to-end
authentication-ciphersuite or as an end-to-end error-detection-
ciphersuite; the type of protection provided by the PSH
(authentication versus error-detection) is indicated by the type
of ciphersuite used
the ciphersuite parameters field MAY be present
the security-source field MAY be present
the security-destination field MAY be present
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.
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
destination that has access to the required keying information.
Most symmetric PSH-ciphersuites will not require a PSH-source but
simply a PSH-destination to indicate which node has access to the key
needed to verify the PSH authenticator. Most asymmetric PSH-
ciphersuites will use the PSH-source to indicate the signer and will
not require the PSH-dest field because the key needed to verify the
PSH authenticator will be a public key associated with the PSH-
source.
3.4 Confidentiality Header
[Comment.17]
A CH is an ASH with the following additional restrictions:
the header-type value MUST be 0xTBD [Comment.18]
Symington, et al. Expires December 10, 2005 [Page 13]
Internet-Draft Bundle Security Protocol June 2005
the flags field MUST be present as defined in the Bundle Protocol
Specification. It SHOULD indicate that the header does not need
to be duplicated on all fragments.
the ciphersuite ID MUST be documented as a confidentiality-
ciphersuite
the ciphersuite parameters field MAY be present
the security-source field MAY be present
the security-destination field MAY be present
the security result normally represents an encrypted bundle
encryption key
A typical confidentiality ciphersuite will encrypt the payload using
a randomly generated payload encrypting key (PEK) and then use the
security result to carry the PEK encrypted with some long term key
encryption key (KEK). The CH-dest field will typically indicate the
decryption key with which the PEK can be recovered.[Comment.19]
3.5 PSH and CH combinations
[Comment.20]
Symington, et al. Expires December 10, 2005 [Page 14]
Internet-Draft Bundle Security Protocol June 2005
4. Security Processing
This section describes the security aspects of bundle processing.
The subsections here parallel the subsections of section 4, Bundle
Processing, in the Bundle Protocol Specification [2] to make it
easier for the reader to understand how the security steps described
herein fit into the Bundle Protocol. [Comment.21]
All Bundle Protocol Agents are required to have and enforce their own
configurable security policies, whether these policies be explicit or
default, as defined in Section 6.
4.1 Bundle Transmission Requests
As described in Section 4.1 of the Bundle protocol [2], which
enumerates the steps in processing a Send.request primitive, all
bundle protocol agents 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. If a particular
Send.request satisfies the bundle protocol agent's policy and is
therefore accepted, then an outbound bundle SHALL be created and
dispatched. The security-specific steps in processing a Send.request
primitive to create the outbound bundle are as follows:
For clarity, the text below ignores the fact that the policy
enforcing code MAY override all of the processing steps described.
For example, it is valid to implement a bundle protocol agent which
always attempts to attach a PSH. Similarly it is also valid to
implement a bundle protocol agent which always rejects all requests
which imply the use of a PSH. Basically, the policy code is allowed
to override the algorithm described below, except in the case in
which the Send.request asks for some service that is not allowed by
the policy code. In this case, the bundle protocol agent MUST NOT
send a bundle because to do so by sending a bundle without the
requested service would mean that the bundle protocol agent would be
transmitting data in a manner that is not as secure as was requested,
but without the bundle node's knowledge.
If the Send.request primitive includes a Delivery Options parameter
and that Delivery Options parameter includes a Payload Security
Requirements item, the following steps SHALL be taken, in order,
depending on the values of the Confidentiality, Authentication, and
Error-detection elements of the Payload Security Requirements item.
If the Send.request primitive does not include a Delivery Options
parameter with a Payload Security Requirements item, processing SHALL
proceed beginning at Section 4.5 below.
Symington, et al. Expires December 10, 2005 [Page 15]
Internet-Draft Bundle Security Protocol June 2005
Confidentiality
If the Confidentiality element is present in the Delivery
Options parameter of the Send.request primitive, this indicates
that the payload MUST be encrypted and a CH header MUST be
added to the bundle.
If the Confidentiality element is not present, a CH header
SHALL NOT be created for this bundle, unless indicated by local
policy.
Authentication
If the authentication element is present in the Delivery
Options parameter of the Send.request primitive a PSH SHALL be
created. (If both the authentication and error-detection
options are indicated in the Send.request primitive, the
authentication option takes precedence and authentication is
provided, because authentication encompasses both
authentication and error-detection.)
Error-detection
If the Error-detection element is present in the Delivery
Options parameter of the Send.request primitive but the
Authentication element is not present, a PSH SHALL be created.
If neither the Authentication nor the Error-detection elements
of the Delivery Options parameter of the Send.request primitive
are present, a Payload Security Header SHALL NOT be created for
this bundle, unless indicated by local policy.
Ciphersuites and Ciphersuite Parameters
The following rules hold for each of the confidentiality,
authentication, and error-detection elements:
If any element (confidentiality, authentication, or error-
detection) includes a ciphersuite ID then the corresponding
header (CH or PSH) and calculation MUST use this ciphersuite or
else the bundle MUST NOT be transmitted/forwarded. All rules
specified in the ciphersuite definition MUST be followed.
If any element does not include a ciphersuite ID then the
corresponding header and calculation MUST use the default
ciphersuite or else the bundle MUST NOT be transmitted/
forwarded. All rules specified in the default ciphersuite
definition MUST be followed.
Symington, et al. Expires December 10, 2005 [Page 16]
Internet-Draft Bundle Security Protocol June 2005
If ciphersuite parameters are provided they MUST be honored.
It is an error to emit a bundle using some other parameters.
If ciphersuite parameters are not provided then the default
parameters for that ciphersuite MUST be used.
4.2 Canonicalisation of bundles
In order to verify a signature or MAC on a bundle the exact same bits
must be input to the calculation upon verification as were input upon
initial computation of the original signature or MAC value. Since
bundles may be modified while in transit (either correctly or due to
implementation errors), a canonical form of any given bundle (that
contains a PSH) must be defined.
This section defines the default bundle canonicalisation
algorithm.[Comment.22]
In order for the PSH to be useful, all bundle information over which
the PSH is calculated at the source must be the same, and in the same
order, as all bundle information over which the PSH is calculated at
the point at which the PSH is being validated. Therefore, the
following transmission requirements SHALL hold:
Once any of the following headers are placed in a bundle, they MUST
both remain in the bundle and continue to be positioned in the same
order relative to one another in the bundle as the bundle travels
through the DTN to its destination. Neither the presence nor the
position of these headers relative to one another is allowed to
change at any time. If the bundle becomes fragmented, each of these
headers MUST be present in some fragment and they must continue to be
positioned in the same order following bundle re-assembly:
Primary Bundle Header
Dictionary Header
Override Report-to Header
Source Routing Header
Payload Security Header
Confidentiality Header
Bundle Payload Header
If a Payload Security Header is placed in a bundle, it MUST remain in
Symington, et al. Expires December 10, 2005 [Page 17]
Internet-Draft Bundle Security Protocol June 2005
the bundle and continue to be positioned in the same order relative
to the other bundle headers as the bundle travels throughout the DTN.
However, if the bundle becomes fragmented, at least the fragment
containing the initial portion of the original payload (that is, the
fragment that has a Fragment Offset field value of zero) MUST contain
the PSH and at least some fragment MUST contain the CH.
The following additional headers MAY be present in the bundle when it
arrives at a bundle protocol agent or at the destination, and if they
are present, they must be (logically) removed from the bundle before
the PSH is verified:
Custody related headers
Bundle Authentication Header
Bundle Fragment Header
Before the PSH is initially calculated and before it is verified by
applying the appropriate ciphersuite to the appropriate parts of the
bundle, the fields of the bundle that are mutable as the bundle
travels from source to destination must be temporarily made
irrelevant to the calculation by performing the following:
the BAH, if present, MUST be removed from the bundle
the offset values in the source, destination, reply-to endpoint,
sender, CH security-source (if present), CH security-destination
(if present), PSH security-source (if present), and PSH security-
destination (if present) fields must be used to obtain the
corresponding scheme/mark format of the endpoint IDs from the
dictionary header and these endpoint IDs MUST be substituted for
their corresponding fields in the concatenated bundle header for
purposes of calculating the PSH authenticator over the bundle.
Note that if additional bundle headers that contain offsets into
the dictionary header are defined (e.g., a source route header),
then the definition of the new header SHOULD specify whether or
not the referenced endpoint IDs should be substituted for the
corresponding offset fields in the new header when constructing
the canonical form of the bundle for purposes of computing the
PSH. If a new header is defined and its definition does not
specify whether or not the referenced endpoint IDs should be
substituted for the corresponding fields in the header, then by
default they SHALL be.
the portion of the dictionary header corresponding to the
custodian field (as indicated by the offset value in the custodian
field of the Primary Bundle Header) MUST be zeroed out
Symington, et al. Expires December 10, 2005 [Page 18]
Internet-Draft Bundle Security Protocol June 2005
the portion of the dictionary header corresponding to the sender
field (as indicated by the offset value in the sender field of the
Primary Bundle Header) MUST be zeroed out
the security information field of the PSH MUST be zeroed
out[Comment.23]
4.3 Creating a Confidentiality Header
This subsection describes the steps taken to create the CH and
populate it with the appropriate values as well as modify the payload
field of the Bundle Payload Header.
If the CH is being created by some entity other than the bundle
source, then a CH-source field MUST be placed in the CH and populated
with the endpoint ID of the entity creating the CH. [Comment.24]
The values of the CH MUST be populated as described in Section 3 and
according to the rules of the relevant ciphersuite described in
Section 5. All ciphersuites will require the input to the security
result calculation to include at least the bundle payload. Some
ciphersuites will require the input to include the bundle payload
concatenated with some canonical sequence of bundle header fields
(e.g., source, destination, portions of the dictionary header) for
which confidentiality will also be provided. Note that the security
result calculated will be placed in the payload field of the bundle
payload header. The CH does not include a field for the security
result.[Comment.25]
4.4 Creating the Payload Security Header
This subsection describes the steps taken to create the PSH and
populate it with the appropriate values.
A PSH MUST be created after all other bundle headers except for the
BAH have been added to the bundle and populated with their correct
values.
If the PSH is being created by some entity other than the bundle
source, then a PSH-source field MUST be placed in the PSH and
populated with the endpoint ID of the entity creating the PSH.
The values of the PSH MUST be populated as described in Section 3 and
according to the rules of the relevant ciphersuite described in
Section 5. Almost all ciphersuites will require the input to the
security result calculation to be the canonical form (see
Section 4.2) of the bundle.
Symington, et al. Expires December 10, 2005 [Page 19]
Internet-Draft Bundle Security Protocol June 2005
4.5 Creating the Bundle Authentication Header
Regardless of whether or not the Send.request primitive includes a
delivery options parameter, the bundle protocol agent SHALL consult
its security policy to determine whether or not the bundle MUST be
provided with a Bundle Authentication Header before being forwarded.
If the bundle does not need to be provided with a BAH, no additional
security-related processing is required.
The optional ciphersuite parameters field of the BAH SHOULD (if
bandwidth permits) be included in the BAH.
The authentication information field of the PSH SHALL be zeroed out
before the ciphersuite is applied to the (relevant parts of) the
bundle.
4.6 Bundles received from other bundle protocol agents
The security-specific steps in processing a bundle received from
another bundle protocol agent are as follows:
The receiving bundle protocol agent SHALL consult its security policy
to determine whether or not the bundle is required to include a BAH.
If the bundle is not required to have a BAH, then security processing
on the received bundle is complete and the bundle is ready to be
processed for either local delivery or forwarding.
If the bundle is required to have a BAH but it does not, then the
bundle MUST be discarded and processed no further; in this case a
bundle status report indicating the authentication failure MAY be
generated, destined for the receiving bundle protocol agent's own
endpoint.
Otherwise, if the bundle does have a BAH, then the value in the
authentication information field of the BAH of the received bundle
MUST be verified according to the ciphersuite specification. If the
check fails, the bundle has failed to authenticate and the bundle
SHALL be discarded and processed no further; in this case, a bundle
status report indicating the authentication failure MAY be generated,
destined for the receiving bundle protocol agent's own endpoint.
Otherwise, if the BAH verifies, it is ready to be processed for
either local delivery or forwarding.
4.7 Local Bundle Delivery
The security-specific steps in processing a bundle if one or more
bundle nodes have registered with the bundle protocol agent to
receive bundles sent to the bundle's destination endpoint ID are as
Symington, et al. Expires December 10, 2005 [Page 20]
Internet-Draft Bundle Security Protocol June 2005
follows:
These steps SHALL be performed after the payload of the original
bundle has been reassembled from the payloads of received fragments,
if necessary, to reconstruct the original bundle in its entirety.
If the bundle does not include a Payload Security Header, then
security processing on the received bundle should proceed from
Section 4.8 below. Otherwise, if the bundle does include a PSH, then
the value in the security results field of the PSH of the received
bundle MUST be verified according to the rules of the ciphersuite.
If the received value fails verification, the bundle has failed to
authenticate and the bundle SHALL be discarded and processed no
further; in this case, a bundle status report indicating the
authentication failure MAY be generated, destined for the receiving
bundle protocol agent's own endpoint. Otherwise, if the check
passes, the bundle has been authenticated as having been sent from
the claimed source and as not having been modified since being sent.
4.8 Optionally checking for Replays
If one or more bundle nodes have indicated that they want to use the
"at most once" delivery option when they registered with the bundle
protocol agent using the destination endpoint ID that is in the
bundle, then the bundle protocol agent MUST compare the (source,
timestamp) pair values of the bundle with the local list of such
values of already-received bundles.
If the pair value is a duplicate, the bundle MUST not be delivered
to any node that is registered using the "at most once" delivery
option.
If the pair value is unique, the pair MUST be added to the local
list.
4.9 Bundle Forwarding
The security-specific steps in processing a bundle if no bundle nodes
have registered with the bundle protocol agent to receive bundles
sent to the bundle's destination endpoint ID are as follows:
The bundle protocol agent SHALL determine the next hop for the
bundle.
The bundle protocol agent SHALL consult its security policy to
determine the criteria that the received bundle ought to meet before
Symington, et al. Expires December 10, 2005 [Page 21]
Internet-Draft Bundle Security Protocol June 2005
it will be forwarded. These criteria MAY include a determination of
whether or not the received bundle must include a valid BAH, PSH or
CH. If the bundle does not meet the bundle protocol agent'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, destined for the forwarding bundle protocol agent's own
endpoint. [Comment.26][Comment.27]
If the bundle does meet the bundle protocol agent's policy criteria,
then the bundle protocol agent's endpoint ID SHALL be inserted into
the Data Dictionary, if it is not already there, and a pointer to
this string SHALL be placed in the sender ID field of the Primary
Bundle Header.
If the bundle is not a bundle fragment, and if the bundle does not
already have a PSH, the bundle protocol agent SHALL consult its
security policy to determine whether or not it should add a PSH to
the bundle. If so, the PSH SHALL be created and have its fields
populated with all of the appropriate values as described in
"Creating the Payload Security Header" (see Section 4.4). In
particular, the forwarding bundle protocol agent MUST populate the
Security Source field of the PSH with its own endpoint ID.
Next, the bundle protocol agent SHALL consult its security policy to
determine whether or not the bundle needs to be given a BAH. If so,
the BAH SHALL be created and have its fields populated with all of
the appropriate values as described in "Creating the Bundle
Authentication Header" (Section 4.5).
If the bundle is to be fragmented before being forwarded, each of the
fragments MUST be given its own BAH that is specific to that
fragment.
At this point, the bundle is ready for forwarding.
4.10 Bundle Fragmentation and Reassembly
If it is necessary for a bundle protocol agent to fragment a bundle
and security is being used on that bundle, the following security-
specific processing is REQUIRED:
If the bundle is required by the security policy to have a BAH before
being forwarded, all fragments resulting from that bundle MUST
contain individual BAH values.
If the original bundle had a PSH, then the fragment that is given a
Fragment Offset field value of zero MUST include an exact copy of the
PSH that was in the original bundle.
Symington, et al. Expires December 10, 2005 [Page 22]
Internet-Draft Bundle Security Protocol June 2005
If the original bundle had a CH, then some fragment MUST include an
exact copy of the CH that was in the original bundle.
When original bundle transmission is terminated before the entire
payload has been transmitted, the receiving bundle protocol agent
SHALL consult its security policy to determine whether it is
permitted to transform the received portion of the bundle into a
bundle fragment for further forwarding. Whether or not such reactive
fragmentation is permitted SHALL be dependent on the security policy
in combination with the ciphersuite used to calculate the BAH
authentication information. [Comment.28]
In such cases, if the original bundle is fragmented by the recipient
(reactively), and the BAH-ciphersuite is a TP-ciphersuite (see
Section 5), the bundle MUST be fragmented immediately after the last
hash value in the partial payload that is received. Any data
received after the last hash value MUST be dropped.
If an original bundle transmission is terminated before the entire
payload has been transmitted, if the truncated bundle arriving at the
receiving bundle protocol agent is reactively fragmented and
forwarded, only the part of the bundle that was not received must be
retransmitted at the source (providing it has not yet expired).
Before retransmitting this portion of the bundle, it SHALL be changed
into a fragment and, if the original bundle included a BAH, the
fragmented bundle MUST also, and its BAH SHALL be recalculated. If a
TP-type ciphersuite is in use for this bundle, all of the hashes
interspersed in its payload shall be recalculated.
4.11 Custodial Retransmission and Release
No security-specific steps relating to the custodial retransmission
and release phase of bundle processing have yet been identified.
4.12 Bundle Status Report Status Flags
The following security-specific values for Bundle Status Report
Status Flags have been defined in addition to those already present
in Table 5 of the Bundle Protocol Specification [2]:
A source was found to lack the appropriate permissions to use the
requested COS
The security policy does not permit acceptance of a bundle is
received without a BAH.
A bundle failed the hop-by-hop bundle authentication check (using
the Bundle Authentication Header).
Symington, et al. Expires December 10, 2005 [Page 23]
Internet-Draft Bundle Security Protocol June 2005
A bundle failed the end-to-end authentication check (using the
Payload Security Header) at an intermediate DTN security policy
node.
A bundle was found to be an illegitimate replay at an intermediate
node. (Note that no method of detecting such replays has yet been
defined.)
A bundle failed the end-to-end authentication check (using the
Payload Security Header) at the destination host.
A bundle was found to be an illegitimate replay at the destination
host.
Received a payload longer than that defined by the preceding
bundle header.
The indicated BAH ciphersuite is not implemented.
The indicated PSH ciphersuite is not implemented.
the indicated CH ciphersuite is not implemented.
4.13 Convergence Layer Security Services
As discussed in the Bundle Protocol Specification [2], the
convergence layer SHALL deliver the Bundle.indication primitive to
the bundle protocol, and one of the parameters of this primitive,
Bundle Authenticity, is security-specific. The meaning of this
parameter and its possible values are defined in the Bundle Protocol
Specification [2].
Symington, et al. Expires December 10, 2005 [Page 24]
Internet-Draft Bundle Security Protocol June 2005
5. Ciphersuites
Four types of ciphersuites are defined:
hop-by-hop authentication ciphersuites for use in the BAH
end-to-end authentication ciphersuites for use in the PSH
end-to-end error-detection ciphersuites for use in the PSH
confidentiality ciphersuites
The ciphersuite field of the BAH, PSH and CH are 5-bit integer values
as defined below: [Comment.29]
EntireBundleHMAC - value 000
HeadOfBundleHMAC - value 001
EntireBundleSig - value 011
HeadOfBundleSig - value 010
CombinationSig - value 100
EntireBundleMAC - value 101
TP-HMAC - value 1111
TP-HSIG - value 1110
TP-DSS - value 1101[Comment.30]
5.1 EntireBundleHMAC Ciphersuite
This ciphersuite involves computing a MAC over the entire bundle
using HMAC-SHA1. It is both a hop-by-hop authentication ciphersuite
and an end-to-end authentication ciphersuite, so it may be used to
calculate the BAH security result and/or the PSH security result.
If used to calculate the BAH security result, the authentication
information field of the BAH MUST be zeroed out before the
ciphersuite is applied, and the ciphersuite MUST be applied to the
entire bundle.
If used to calculate the PSH security result, the bundle must be put
into canonical form as described in Section 4.2 before the
Symington, et al. Expires December 10, 2005 [Page 25]
Internet-Draft Bundle Security Protocol June 2005
ciphersuite is applied, and the ciphersuite MUST be applied to the
entire bundle.
5.1.1 Ciphersuite Parameters
This ciphersuite has one associated parameter, which identifies the
cryptographic key used in the HMAC computation. This parameter is
encoded in SDNV-8 format.
5.2 HeadOfBundleHMAC Ciphersuite
This ciphersuite involves computing a MAC over the entire bundle
except for the payload field of the Bundle Payload Header using HMAC-
SHA1. It is both a hop-by-hop authentication ciphersuite and an end-
to-end authentication ciphersuite, so it may be used to calculate the
BAH security result and/or the PSH security result.
If used to calculate the BAH security result, the authentication
information field of the BAH MUST be zeroed out before the
ciphersuite is applied, and the ciphersuite MUST be applied to the
entire bundle except for the payload field.
If used to calculate the PSH security result, the bundle must be put
into canonical form as described in Section 4.2 before the
ciphersuite is applied, and the ciphersuite MUST be applied to the
entire bundle except for the payload field.
5.2.1 Ciphersuite Parameters
This ciphersuite has one associated parameter, which identifies the
cryptographic key used in the HMAC computation. This parameter is
encoded in SDNV-8 format.
5.3 EntireBundleSig Ciphersuite
This ciphersuite involves using SHA-1 to compute a hash over the
entire bundle and then signing this hash by generating a Digital
Signature Standard (DSS) signature. It is both a hop-by-hop
authentication ciphersuite and an end-to-end authentication
ciphersuite, so it may be used to calculate the BAH security result
and/or the PSH security result.
If used to calculate the BAH security result, the authentication
information field of the BAH MUST be zeroed out before the
ciphersuite is applied, and the ciphersuite MUST be applied to the
entire bundle.
If used to calculate the PSH security result, the bundle must be put
Symington, et al. Expires December 10, 2005 [Page 26]
Internet-Draft Bundle Security Protocol June 2005
into canonical form as described in Section 4.2 before the
ciphersuite is applied, and the ciphersuite MUST be applied to the
entire bundle.
5.3.1 Ciphersuite Parameters
This ciphersuite has one associated parameter, which identifies the
cryptographic key used to create the signature. This parameter is
encoded in SDNV-8 format.
5.4 HeadOfBundleSig Ciphersuite
This ciphersuite involves using SHA-1 to compute a hash over the
entire bundle except for the payload field of the Bundle Payload
Header and then signing this hash by generating a DSS signature. It
is both a hop-by-hop authentication ciphersuite and an end-to-end
authentication ciphersuite, so it may be used to calculate the BAH
security result and/or the PSH security result.
If used to calculate the BAH security result, the authentication
information field of the BAH MUST be zeroed out before the
ciphersuite is applied, and the ciphersuite MUST be applied to the
entire bundle except for the payload field.
If used to calculate the PSH security result, the bundle must be put
into canonical form as described in Section 4.2 before the
ciphersuite is applied, and the ciphersuite MUST be applied to the
entire bundle except for the payload field.
5.4.1 Ciphersuite Parameters
This ciphersuite has one associated parameter, which identifies the
cryptographic key used to create the signature. This parameter is
encoded in SDNV-8 format.
5.5 CombinationSig Ciphersuite
[Comment.31]
This ciphersuite involves using SHA-1 to compute two hash values: a
hash over just the head of the bundle (the entire bundle except for
the payload field of the Bundle Payload Header), and a hash over the
entire bundle. These two hash values are concatenated (the hash of
the head of the bundle preceding the hash of the entire bundle) and
the concatenated result is signed by generating a DSS signature. It
is only a hop-by-hop authentication ciphersuite, so it may only be
used to calculate the BAH security result.
The authentication information field of the BAH MUST be zeroed out
Symington, et al. Expires December 10, 2005 [Page 27]
Internet-Draft Bundle Security Protocol June 2005
before this ciphersuite is applied.
5.5.1 Ciphersuite Parameters
This ciphersuite has one associated parameter, which identifies the
cryptographic key used to create the signature. This parameter is
encoded in SDNV-8 format.
5.6 EntireBundleMAC
This ciphersuite involves using SHA-1 to compute a hash value over
the entire bundle. No keys are involved. It is only an end-to-end
error-detection ciphersuite, so it may only be used to calculate the
PSH security result.
The bundle must be put into canonical form as described in
Section 4.2 before this ciphersuite is applied, and the ciphersuite
MUST be applied to the entire bundle.
5.6.1 Ciphersuite Parameters
This ciphersuite has no associated parameters, so no associated
parameters fields are included in the PSH when this ciphersuite is
used.
5.7 TP-type Ciphersuites
[Comment.32]
All TP-type ciphersuites involve breaking the bundle payload into
segments of a given size, computing authentication information for
the bundle header concatenated with that payload segment, and
inserting the authentication information for a given segment into the
payload itself right after the given segment. Therefore, the payload
of a bundle on which the TP Ciphersuite was used to calculate the
authentication information would be formatted as a sequence of
payload segments of a given size interspersed with authentication
information of a given size. [Comment.33]
There are several TP-type ciphersuites that have been defined. All
involve formatting the payload as fixed-length segments of payload
followed by fixed-length authentication information calculated over
the bundle header concatenated with the previous payload segment.
The only differences between the various TP-type ciphersuites is the
method used to calculate the authentication information.
[Comment.34]
We may define the following TP-ciphersuites:
Symington, et al. Expires December 10, 2005 [Page 28]
Internet-Draft Bundle Security Protocol June 2005
TP-HMAC Ciphersuites
TP-HSIG Ciphersuites
TP-DSS Ciphersuites
[]
5.7.1 Ciphersuite Parameters
The following two parameters must be included with TP-type
ciphersuites that use fixed-length payload and segment sizes:
segment-length, authenticator-length. These two fields MUST be
included in the BAH and PSH headers that use such TP-type
ciphersuites and they MUST be encoded in SDNV-8 format.
Symington, et al. Expires December 10, 2005 [Page 29]
Internet-Draft Bundle Security Protocol June 2005
6. Default Values
Several of the security headers include optional fields that MAY
contain ciphersuite parameter information. If a bundle includes a
security header that does not contain one of these optional fields,
then the default value for that field SHALL be used. The default
values are as follows:
BAH Ciphersuite ID: EntireBundleSig [Comment.36]
BAH EntireBundleSig parameters: The key associated with the endpoint
indicated in the sender field of the Primary Bundle Header. If this
value is not valid, use the key associated with the endpoint ID that
was passed up as a parameter of the Bundle.Indication primitive.
PSH Ciphersuite ID when Authentication is being used: TBD
PSH Ciphersuite ID when Error Detection is being used: TBD
PSH ciphersuite parameters: If the PSH includes an optional PSH
Security-Source field, use the key associated with the endpoint
indicated in this field. Otherwise, use the key associated with the
endpoint indicated by the source field of the primary bundle header.
CH ciphersuite ID: TBD
CH ciphersuite parameter: If the CH includes an optional CH Security-
Source field, use the key associated with the endpoint indicated in
this field. Otherwise, use the key associated with the endpoint
indicated by the source field of the primary bundle header.
Default Security Policy. Every bundle protocol agent serves as a
Policy Enforcement Point (PEP) insofar as it enforces some policy
that controls the forwarding and delivery of bundles via one or more
interfaces. Consequently, every bundle protocol agent SHALL have and
operate according to its own configurable security policy, whether
the policy be explicit or default. The policy SHALL specify:
Under what conditions received bundles SHALL be forwarded.
Under what conditions received bundles SHALL be required to
include valid BAHs.
Under what conditions the authentication information provided in a
bundle's BAH SHALL be deemed adequate to authenticate the bundle.
Under what conditions received bundles SHALL be required to have
valid PSHs.
Symington, et al. Expires December 10, 2005 [Page 30]
Internet-Draft Bundle Security Protocol June 2005
Under what conditions the authentication information provided in a
bundle's PSH SHALL be deemed adequate to authenticate the bundle.
Under what conditions a BAH SHALL be added to a received bundle
before that bundle is forwarded.
Under what conditions a PSH SHALL be added to a received bundle
before that bundle is forwarded.
The actions that SHALL be taken in the event that a received
bundle does not meet the receiving bundle protocol agent's
security policy criteria.
This specification does not address how security policies get
distributed to bundle protocol agents. It only REQUIRES that bundle
protocol agents have and enforce security policies. [Comment.37]
If no security policy is specified at a given bundle protocol agent,
or if a security policy is only partially specified, that bundle
protocol agent's default policy regarding unspecified criteria SHALL
consist of the following:
Bundles that are not well-formed do not meet the security policy
criteria.
All bundles received MUST either have their authenticity asserted
by the convergence layer or by valid authentication information
present in a BAH. If the value of the Bundle Authenticity
parameter of the convergence layer Bundle.indication primitive is
"Bundle authenticity is asserted", then bundle authentication is
complete. If the value of the Bundle Authenticity parameter is
"Bundle authenticity is denied", or "Bundle authenticity is
unknown", then the bundle MUST have a BAH and the value of the
authentication information field of the BAH must be verified. In
this case, if the bundle does not have a BAH, then the bundle must
be discarded and processed no further; a bundle status report
indicating the authentication failure may be generated, destined
for the receiving bundle protocol agent's own endpoint. If the
bundle does have a BAH, then the value in its authentication
information field SHALL be verified.
The authentication information value in the BAH MUST be calculated
using the YADA-YADA-YADA ciphersuite; that is, the value MUST be
calculated over the entire/head/specific segmented portion of the
bundle, using the yada-yada-yada algorithms.
No received bundles SHALL be required to have a PSH; if a received
bundle does have a PSH, however, that can be ignored unless the
Symington, et al. Expires December 10, 2005 [Page 31]
Internet-Draft Bundle Security Protocol June 2005
receiving protocol agent is the destination bundle protocol agent,
in which case the PSH MUST be verified.
The security information value in the PSH MUST be calculated using
the YADA-YADA-YADA ciphersuite; that is, the value MUST be
calculated over the entire/head of the bundle, using the yada-
yada-yada algorithms.
A PSH SHALL NOT be added to a bundle before sourcing or forwarding
it.
A BAH MUST always be added to a bundle before that bundle is
forwarded.
If a received bundle does not satisfy the bundle protocol agent's
security policy for any reason, then the bundle MUST be discarded
and processed no further; in this case, a bundle status report
indicating the failure SHOULD be generated, destined for the
receiving bundle protocol agent's own endpoint.
Symington, et al. Expires December 10, 2005 [Page 32]
Internet-Draft Bundle Security Protocol June 2005
7. Security Considerations
TBD. We have to add text here describing the downside of using these
mechanisms (e.g. new DoS opportunities), issues with key mgmt,
implementation hints, ciphersuite strength considerations etc. etc.
Ok to do it a bit later though, but we should start collecting items
now.
Symington, et al. Expires December 10, 2005 [Page 33]
Internet-Draft Bundle Security Protocol June 2005
8. IANA Considerations
TBD. We may want to have IANA register ciphersuites.
Symington, et al. Expires December 10, 2005 [Page 34]
Internet-Draft Bundle Security Protocol June 2005
9. References
9.1 Normative References
[1] Bradner, S. and J. Reynolds, "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119, October 1997.
[2] Scott, K., "Bundle Protocol Specification",
draft-irtf-dtnrg-bundle-spec-02.txt , September 2004.
[3] Cerf, V., "Delay-Tolerant Network Architecture",
draft-irtf-dtnrg-arch-02.txt , July 2004,
<draft-irtf-dtnrg-arch-02.txt>.
[4] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
Transmission Protocol", draft-irtf-dtnrg-ltp-02.txt ,
December 2004.
9.2 Informative References
[5] Symington, S., "Delay-Tolerant Network Security Overview and
Motivation", draft-irtf-dtnrg-securityOverview-spec-01.txt ,
March 2005.
[6] Warthman, F., "Delay-Tolerant Networks (DTNs) A Tutorial",
http://www.dtnrg.org/ , March 2003.
[7] Durst, R., "An Infrastructure Security Model for Delay Tolerant
Networks", http://www.dtnrg.org/ , July 2002.
Symington, et al. Expires December 10, 2005 [Page 35]
Internet-Draft Bundle Security Protocol June 2005
Editorial Comments
[] Editors: Actually, the "bundle security is RECOMMENDED"
statement needs to be in the core Bundle Protocol spec
and not here. But for now, let's put it here until we
get agreement with the larger group.
[] Editors: We're using the xml2rfc tools so embedded
comments are marked like this.
[] Editors: This is the first informative reference. We
should, if we want to look like a standards-track RFC,
distinguish between normative and informative but I'm
not sure how to with this tool yet.
[] Editors: There may be some (valid) question marks over
this terminology. We weren't entirely sure ourselves.
[] Editors: There is still work to be done on how to
handle potential combinations of security services
(e.g., confidentiality with authenticity).
[] Editors: We discussed whether to model e.g. the
"signer" as the bundle node or the bundle protocol
agent that provides the bundle service to the bundle
node. In the end, we didn't care too much and are happy
to allow either term. The main reasons we didn't care
were a) due to the fact that there's mainly no real
security difference since a suitable API that properly
isolates which layer is trusting which other layer for
what is at least very hard, and b) the destination
mostly doesn't care which layer of the cake signed in
any case.
[] Editors: This section needs to be coordinated with the
Bundle Protocol Spec.
[] Editors: The extent to which the interfaces defined in
this section should reflect a 1:1 correspondence with
the protocol data units is to be determined. The issue
is that we want to allow policy code below the
interface to influence matters, so, e.g. if the
interface omits to specify, or defaults, an algorithm
parameter then the implementation could select
anything, presumably after running some policy code.
The net effect is that the PDUs reflect some
combination of the interface inputs and the policy
settings.
Symington, et al. Expires December 10, 2005 [Page 36]
Internet-Draft Bundle Security Protocol June 2005
[] Editors: Basic confidentiality requires that the
payload be encrypted; we may also want to define a
confidentiality service that also keeps certain fields
like source and destination confidential. It is not
clear if we should define specific ciphersuites to
provide specific types of confidentiality or if we
should specify that a tunnel be created and used to
provide confidentiality of the entire bundle. Note that
encrypting certain fields like source and destination
would not be sufficient, given that these fields only
contain offsets into the Dictionary Header. Appropriate
portions of the dictionary header would have to be
encrypted as well.
[] Editors: This might be done this way or else changed to
not use the PSH in order to make it clearer that we're
not getting data integrity from this service (alone).
The reason to do it this way is that it provides a nice
debugging option to verify much of the non-key
management code in a bundle-security stack. That may,
or may not be considered sufficient benefit for the
potential confusion caused.
[] Editors: Note, this parameter still has to be added to
the Bundle Spec.
[] Editors: there's definitely more to be said about
replay, so consider this as a placeholder until
decisions on replay get made.
[] Editors: This can't be a MAY. There has to be some MUST
somewhere.
[] Editors: Details of this encoding scheme will change.
The next-header mightn't become header-type; depending
on how the sources are encoded (a moving target
elsewhere) we may need to include an offset to point to
the start of those and 32 is really a factor of ~3 too
small for specifying all standard ciphersuites ever.
[] This flags field is brand new; we still have to
discuss how the sittings of its various bits get
selected (Send.Request interface parameters, possibly
overridden by security policy) as well as how it is
treated. Security policy will take precedence. Will the
flags be obeyed if the policy is silent?
[] Editors: This is assuming that the primary bundle
Symington, et al. Expires December 10, 2005 [Page 37]
Internet-Draft Bundle Security Protocol June 2005
header has a "sender" field, as has been discussed. If
not, the security source field MUST be present.
Requires coordination with the Bundle Protocol Spec.
[] Editors: Note that we are defining a new
Confidentiality Header and its type has to be added to
Table 1 of the Bundle Protocol.
[] Editors: Note that we are defining a new
Confidentiality Header and its type has to be added to
Table 1 of the Bundle Protocol.
[] Howie: It may be nice to be able to signal both
confidentiality and authentication using only one
header instead of using two separate headers (PSH and
CH).
[] Editors: As you can see - this is TBD!
[] Editors: Not sure if paralleling the bundle spec. will
be a good or bad idea - it might be simpler to just do
our own thing here. I guess we'll see.
[] Editors: ...but is still mainly tbd
[] Editors: These instruction for canonicalisation may not
be exactly correct, but we think they're on the right
track.
[] Susan: What drives the inclusion of a CH (or PSH)
security destination in the CH (or PSH), and where does
this value come from? Is it security-policy driven?
Should there be a parameter in the Send.Request service
primitive to enable the bundle node to specify these
security destinations, if desired?
[] Susan: We will eventually want to say more about
possibly providing confidentiality for some bundle
header fields in addition to simply providing payload
confidentiality.
[] Howie: The security policy database will need to be
discussed somewhere. Does it belong in this document,
the bundle protocol spec., both, some other document?
[] Editors: The paragraph below should be elsewhere;
unfortunately it isn't anywhere else yet, because it
was a security discussion that brought up the need for
Symington, et al. Expires December 10, 2005 [Page 38]
Internet-Draft Bundle Security Protocol June 2005
a "sender" field. This field has not yet made it into
the Bundle protocol. We must coordinate with the Bundle
Protocol spec authors to insert this text into the
Bundle Protocol. I have it here for now so it is at
least somewhere.
[] Editors: These are initial thoughts and may be wrong,
or changed!
[] Editors: These are really placeholders; very sketchy at
this point.
[] Add DSS, with variations for entire bundle, head of
bundle... (should use of DSS be the default? Over
entire bundle or just front?)
[] Editors: this one is more efficient if we're not
pkcs1v1.5 compliant.
[] Editors: we need another name, or else have to explain
what TP expands to...:-)
[] This explanation needs to be more detailed, saying
exactly what parts of the canonical form of the bundle
each authenticator is calculated over.
[] Editors: It isn't clear what entity decides the size of
the payload segments and breaks the payload into these
segments--the source bundle node or the source bundle
protocol agent? If the source bundle node, why doesn't
it just send each of these segments as separate
bundles? if the source bundle node, then wouldn't the
send.Request primitive need to be modified to enable
the segment size to be specified? If the bundle
protocol agent decides the segment size, on what does
it base this decision?
[] Howie: Should the TP segments sizes be fixed or random
(smaller than some maximum)? If they are fixed, what
compelling argument is there that any of them will get
through? If they are random in size (and we define a
TLV format for conveying the appropriate information)
then maybe something will get through.
[] Editors: this still needs to be defined in the Bundle
Protocol.
[] Howie: Eventually we will need to state where the
Symington, et al. Expires December 10, 2005 [Page 39]
Internet-Draft Bundle Security Protocol June 2005
security policy information/DB does get discussed/
specified.
Authors' Addresses
Susan Flynn Symington
The MITRE Corporation
7515 Colshire Drive
McLean, VA 22102
US
Phone: +1 (703) 983-7209
Email: susan@mitre.org
URI: http://mitre.org/
Stephen Farrell
Trinity College Dublin
Distributed Systems Group
Department of Computer Science
Trinity College
Dublin 2
Ireland
Phone: +353-1-608-1539
Email: stephen.farrell@cs.tcd.ie
Howard Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
US
Phone: +1-410-872-1515 x201
Email: hsw@sparta.com
Symington, et al. Expires December 10, 2005 [Page 40]
Internet-Draft Bundle Security Protocol June 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Symington, et al. Expires December 10, 2005 [Page 41]
