idnits 2.17.1 draft-irtf-dtnrg-bundle-security-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 11, 2009) is 5279 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3370' is defined on line 2432, but no explicit reference was found in the text == Unused Reference: 'RFC4106' is defined on line 2441, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 5050 (ref. 'DTNBP') == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-bundle-metadata-block-00 ** Downref: Normative reference to an Experimental draft: draft-irtf-dtnrg-bundle-metadata-block (ref. 'DTNMD') ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3852 (ref. 'RFC5652') (Obsoleted by RFC 5652) -- No information found for draft-irtf-dtnrg-bundle-retrans - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DTN Research Group S. Symington 3 Internet-Draft The MITRE Corporation 4 Expires: May 15, 2010 S. Farrell 5 Trinity College Dublin 6 H. Weiss 7 P. Lovell 8 SPARTA, Inc. 9 November 11, 2009 11 Bundle Security Protocol Specification 12 draft-irtf-dtnrg-bundle-security-10 14 Abstract 16 This document defines the bundle security protocol, which provides 17 data integrity and confidentiality services for the bundle protocol. 18 Separate capabilities are provided to protect the bundle payload and 19 additional data that may be included within the bundle. We also 20 describe various bundle security considerations including policy 21 options. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on May 15, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Related Documents . . . . . . . . . . . . . . . . . . . . 3 77 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 78 2. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 7 79 2.1. Abstract Security Block . . . . . . . . . . . . . . . . . 8 80 2.2. Bundle Authentication Block . . . . . . . . . . . . . . . 12 81 2.3. Payload Integrity Block . . . . . . . . . . . . . . . . . 13 82 2.4. Payload Confidentiality Block . . . . . . . . . . . . . . 15 83 2.5. Extension Security Block . . . . . . . . . . . . . . . . . 18 84 2.6. Parameters and Result Fields . . . . . . . . . . . . . . . 20 85 2.7. Key Transport . . . . . . . . . . . . . . . . . . . . . . 22 86 2.8. PIB and PCB combinations . . . . . . . . . . . . . . . . . 22 87 3. Security Processing . . . . . . . . . . . . . . . . . . . . . 25 88 3.1. Nodes as policy enforcement points . . . . . . . . . . . . 25 89 3.2. Processing order of security blocks . . . . . . . . . . . 25 90 3.3. Security Regions . . . . . . . . . . . . . . . . . . . . . 28 91 3.4. Canonicalisation of bundles . . . . . . . . . . . . . . . 30 92 3.5. Endpoint ID confidentiality . . . . . . . . . . . . . . . 36 93 3.6. Bundles received from other nodes . . . . . . . . . . . . 36 94 3.7. The At-Most-Once-Delivery Option . . . . . . . . . . . . . 38 95 3.8. Bundle Fragmentation and Reassembly . . . . . . . . . . . 39 96 3.9. Reactive fragmentation . . . . . . . . . . . . . . . . . . 40 97 4. Mandatory Ciphersuites . . . . . . . . . . . . . . . . . . . . 41 98 4.1. BAB-HMAC . . . . . . . . . . . . . . . . . . . . . . . . . 41 99 4.2. PIB-RSA-SHA256 . . . . . . . . . . . . . . . . . . . . . . 42 100 4.3. PCB-RSA-AES128-PAYLOAD-PIB-PCB . . . . . . . . . . . . . . 43 101 4.4. ESB-RSA-AES128-EXT . . . . . . . . . . . . . . . . . . . . 47 102 5. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 50 103 6. Default Security Policy . . . . . . . . . . . . . . . . . . . 51 104 7. Security Considerations . . . . . . . . . . . . . . . . . . . 53 105 8. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 54 106 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 108 10.1. Normative References . . . . . . . . . . . . . . . . . . . 56 109 10.2. Informative References . . . . . . . . . . . . . . . . . . 56 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 112 1. Introduction 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 This document defines security features for the bundle protocol 119 [DTNBP] intended for use in delay tolerant networks, in order to 120 provide DTN security services. 122 The bundle protocol is used in DTNs which overlay multiple networks, 123 some of which may be challenged by limitations such as intermittent 124 and possibly unpredictable loss of connectivity, long or variable 125 delay, asymmetric data rates, and high error rates. The purpose of 126 the bundle protocol is to support interoperability across such 127 stressed networks. The bundle protocol is layered on top of 128 underlay-network-specific convergence layers, on top of network- 129 specific lower layers, to enable an application in one network to 130 communicate with an application in another network, both of which are 131 spanned by the DTN. 133 Security will be important for the bundle protocol. The stressed 134 environment of the underlying networks over which the bundle protocol 135 will operate makes it important for the DTN to be protected from 136 unauthorized use, and this stressed environment poses unique 137 challenges for the mechanisms needed to secure the bundle protocol. 138 Furthermore, DTNs may very likely be deployed in environments where a 139 portion of the network might become compromised, posing the usual 140 security challenges related to confidentiality, integrity and 141 availability. 143 Different security processing applies to the payload and extension 144 blocks that may accompany it in a bundle, and different rules apply 145 to various extension blocks. 147 This document describes both the base Bundle Security Protocol (BSP) 148 and a set of mandatory ciphersuites. A ciphersuite is a specific 149 collection of various cryptographic algorithms and implementation 150 rules that are used together to provide certain security services. 152 1.1. Related Documents 154 This document is best read and understood within the context of the 155 following other DTN documents: 157 The Delay-Tolerant Network Architecture [DTNarch] defines the 158 architecture for delay-tolerant networks, but does not discuss 159 security at any length. 161 The DTN Bundle Protocol [DTNBP] defines the format and processing 162 of the blocks used to implement the bundle protocol, excluding the 163 security-specific blocks defined here. 165 1.2. Terminology 167 We introduce the following terminology for purposes of clarity: 169 source - the bundle node from which a bundle originates 171 destination - the bundle node to which a bundle is ultimately 172 destined 174 forwarder - the bundle node that forwarded the bundle on its most 175 recent hop 177 intermediate receiver or "next hop" - the neighboring bundle node 178 to which a forwarder forwards a bundle. 180 In the figure below, which is adapted from figure 1 in the Bundle 181 Protocol Specification, four bundle nodes (denoted BN1, BN2, BN3, and 182 BN4) reside above some transport layer(s). Three distinct transport 183 and network protocols (denoted T1/N1, T2/N2, and T3/N3) are also 184 shown. 186 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 187 | BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 | 188 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 189 | T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 | 190 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 191 | N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 | 192 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 193 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 194 +-----------+ +------------+ +-------------+ +-----------+ 195 | | | | 196 |<-- An Internet --->| |<--- An Internet --->| 197 | | | | 199 BN = "Bundle Node" (as defined in the Bundle Protocol Specification 201 Bundle Nodes Sit at the Application layer of the Internet Model. 203 Figure 1 205 Bundle node BN1 originates a bundle that it forwards to BN2. BN2 206 forwards the bundle to BN3, and BN3 forwards the bundle to BN4. BN1 207 is the source of the bundle and BN4 is the destination of the bundle. 208 BN1 is the first forwarder, and BN2 is the first intermediate 209 receiver; BN2 then becomes the forwarder, and BN3 the intermediate 210 receiver; BN3 then becomes the last forwarder, and BN4 the last 211 intermediate receiver, as well as the destination. 213 If node BN2 originates a bundle (for example, a bundle status report 214 or a custodial signal), which is then forwarded on to BN3, and then 215 to BN4, then BN2 is the source of the bundle (as well as being the 216 first forwarder of the bundle) and BN4 is the destination of the 217 bundle (as well as being the final intermediate receiver). 219 We introduce the following security-specific DTN terminology: 221 security-source - a bundle node that adds a security block to a 222 bundle 224 security-destination - a bundle node that processes a security 225 block of a bundle 227 security region - that part of the network path from the security- 228 source to the security-destination 230 Referring to Figure 1 again: 232 If the bundle that originates at BN1 as source is given a security 233 block by BN1, then BN1 is the security-source of this bundle with 234 respect to that security block, as well as being the source of the 235 bundle. 237 If the bundle that originates at BN1 as source is given a security 238 block by BN2, then BN2 is the security-source of this bundle with 239 respect to that security block, even though BN1 is the source. 241 If the bundle that originates at BN1 as source is given a security 242 block by BN1 that is intended to be processed by BN3, then BN1 is the 243 security-source and BN3 is the security destination with respect to 244 this security block. The security region for this block is BN1 to 245 BN3. 247 A bundle MAY have multiple security blocks. The security-source of a 248 bundle with respect to a given security block in the bundle MAY be 249 the same as or different from the security-source of the bundle with 250 respect to a different security block in the bundle. Similarly, the 251 security-destination of a bundle with respect to each of that 252 bundle's security blocks MAY be the same or different. Therefore the 253 security regions for various blocks MAY be and often will be 254 different. 256 If the bundle that originates at BN1 as source is given a security 257 block by BN1 that is intended to be processed by BN3, and BN2 adds a 258 security block with security-destination BN4, the security regions 259 for the two blocks overlap but not completely. This problem is 260 discussed further in Section 3.3. 262 As required in [DTNBP], forwarding nodes MUST transmit blocks in a 263 bundle in the same order in which they were received. This 264 requirement applies to all dtn nodes, not just ones which implement 265 security processing. Blocks in a bundle MAY be added or deleted 266 according to the applicable specification, but those blocks which are 267 both received and transmitted MUST be transmitted in the same order 268 that they were received. 270 The block sequence also indicates the order in which certain 271 significant actions have affected the bundle, and therefore the 272 sequence in which actions MUST occur in order to produce the bundle 273 at its destination. 275 2. Security Blocks 277 There are four types of security block that MAY be included in a 278 bundle. These are the Bundle Authentication Block (BAB), the Payload 279 Integrity Block (PIB), the Payload Confidentiality Block (PCB) and 280 the Extension Security Block (ESB). 282 The BAB is used to assure the authenticity and integrity of the 283 bundle along a single hop from forwarder to intermediate receiver. 285 The PIB is used to assure the authenticity and integrity of the 286 payload from the PIB security-source, which creates the PIB, to 287 the PIB security-destination, which verifies the PIB 288 authenticator. The authentication information in the PIB MAY (if 289 the ciphersuite allows) be verified by any node in between the PIB 290 security-source and the PIB security-destination that has access 291 to the cryptographic keys and revocation status information 292 required to do so. 294 Since a BAB protects a bundle on a "hop-by-hop" basis and other 295 security blocks MAY be protecting over several hops or end-to-end, 296 whenever both are present the BAB MUST form the "outer" layer of 297 protection - that is, the BAB MUST always be calculated and added 298 to the bundle after all other security bloacks have been 299 calculated and added to the bundle. 301 The PCB indicates that the payload has been encrypted, in whole or 302 in part, at the PCB security-source in order to protect the bundle 303 content while in transit to the PCB security-destination. 305 PIB and PCB protect the payload and are regarded as "payload- 306 related" for purposes of the security discussion in this document. 307 Other blocks are regarded as "non-payload" blocks. Of course, the 308 primary block is unique and has separate rules. 310 The ESB provides security for non-payload blocks in a bundle. ESB 311 therefore is not applied to PIB or PCBs, and of course is not 312 appropriate for either the payload block or primary block. 314 Each of the security blocks uses the Canonical Bundle Block Format as 315 defined in the Bundle Protocol Specification. That is, each security 316 block is comprised of the following elements: 318 - Block type code 320 - Block processing control flags 321 - Block EID reference list (optional) 323 - Block data length 325 - Block-type-specific data fields 327 Since the four security blocks have most fields in common, we can 328 shorten the description of the Block-type-specific data fields of 329 each security block if we first define an abstract security block 330 (ASB) and then specify each of the real blocks in terms of the fields 331 which are present/absent in an ASB. Note that no bundle ever 332 contains an actual ASB, which is simply a specification artifact. 334 2.1. Abstract Security Block 336 An ASB consists of the following mandatory and optional fields: 338 - Block-type code (one byte) - as in all bundle protocol blocks 339 except the primary bundle block. The block types codes for the 340 security blocks are: 342 BundleAuthenticationBlock - BAB: 0x02 344 PayloadIntegrityBlock - PIB: 0x03 346 PayloadConfidentialityBlock - PCB: 0x04 348 ExtensionSecurityBlock - ESB: 0x09 350 - Block processing control flags (SDNV) - defined as in all bundle 351 protocol blocks except the primary bundle block (as described in 352 the Bundle Protocol [DTNBP]). SDNV encoding is described in the 353 bundle protocol. There are no general constraints on the use of 354 the block processing flags, and some specific requirements are 355 discussed later. 357 - EID references - composite field defined in [DTNBP] containing 358 references to one or two EIDs. Presence of the EID-reference 359 field is indicated by the setting of the "block contains an EID- 360 reference field" (EID_REF) bit of the block processing control 361 flags. If one or more references is present, flags in the 362 ciphersuite ID field, described below, specify which. 364 If no EID fields are present then the composite field itself is 365 omitted entirely, rather than containing a count field of zero, 366 since such a representation is not permitted. The EID_REF bit is 367 not set. 369 The possible EIDs are:- 371 - (optional) Security-source - specifies the security source 372 for the block. If this is omitted, then the source of the 373 bundle is assumed to be the security-source. 375 - (optional) Security-destination - specifies the security 376 destination for the block. If this is omitted, then the 377 destination of the bundle is assumed to be the security- 378 destination. 380 If two EIDs are present, security-source is first and security- 381 destination comes second. 383 - Block data length (SDNV) - as in all bundle protocol blocks 384 except the primary bundle block. SDNV encoding is described in 385 the bundle protocol. 387 - Block-type-specific data fields as follows: 389 - Ciphersuite ID (SDNV) 391 - Ciphersuite flags (SDNV) 393 - (optional) Correlator - when more than one related block is 394 inserted then this field MUST have the same value in each 395 related block instance. This is encoded as an SDNV. See note 396 in Section 3.8 with regard to correlator values in bundle 397 fragments. 399 - (optional) Ciphersuite parameters - compound field of next 400 two items 402 - Ciphersuite parameters length - specifies the length of 403 the following Ciphersuite parameters data field and is 404 encoded as an SDNV. 406 - Ciphersuite parameters data - parameters to be used with 407 the ciphersuite in use, e.g. a key identifier or 408 initialization vector (IV). See Section 2.6 for a list of 409 potential parameters and their encoding rules. The 410 particular set of parameters that are included in this field 411 are defined as part of the ciphersuite specification. 413 - (optional) Security result - compound field of next two items 415 - Security result length - contains the length of the next 416 field and is encoded as an SDNV. 418 - Security result data - contains the results of the 419 appropriate ciphersuite-specific calculation (e.g. a 420 signature, MAC or ciphertext block key). 422 +----------------+----------------+----------------+----------------+ 423 | type | flags (SDNV) | EID ref list(comp) | 424 +----------------+----------------+----------------+----------------+ 425 | length (SDNV) | ciphersuite (SDNV) | 426 +----------------+----------------+----------------+----------------+ 427 | ciphersuite flags (SDNV) | correlator (SDNV) | 428 +----------------+----------------+----------------+----------------+ 429 |params len(SDNV)| ciphersuite params data | 430 +----------------+----------------+----------------+----------------+ 431 |res-len (SDNV) | security result data | 432 +----------------+----------------+----------------+----------------+ 434 The structure of an abstract security block 436 Figure 2 438 Some ciphersuites are specified in Section 4, which also specifies 439 the rules which MUST be satisfied by ciphersuite specifications. 440 Additional ciphersuites MAY be defined in separate specifications. 441 Ciphersuite IDs not specified are reserved. Implementations of the 442 bundle security protocol decide which ciphersuites to support, 443 subject to the requirements of Section 4. It is RECOMMENDED that 444 implementations that allow additional ciphersuites permit ciphersuite 445 ID values at least up to and including 127, and they MAY decline to 446 allow larger ID values. 448 The structure of the ciphersuite flags field is shown in Figure 3. 449 In each case the presence of an optional field is indicated by 450 setting the value of the corresponding flag to one. A value of zero 451 indicates the corresponding optional field is missing. Presently 452 there are five flags defined for the field and for convenience these 453 are shown as they would be extracted from a single-byte SDNV. Future 454 additions may cause the field to grow to the left so, as with the 455 flags fields defined in [DTNBP], the description below numbers the 456 bit positions from the right rather than the standard RFC definition 457 which numbers bits from the left. 459 src - bit 4 indicates whether the EID-reference field of the ASB 460 contains the optional reference to the security-source. 462 dest - bit 3 indicates whether the EID-reference field of the ASB 463 contains the optional reference to the security-destination. 465 parm - bit 2 indicates whether the ciphersuite-parameters-length 466 and ciphersuite parameters data fields are present or not. 468 corr - bit 1 indicates whether or not the ASB contains an optional 469 correlator. 471 res - bit 0 indicates whether or not the ASB contains the security 472 result length and security result data fields. 474 bits 5-6 are reserved for future use. 476 Ciphersuite flags 477 Bit Bit Bit Bit Bit Bit Bit 478 6 5 4 3 2 1 0 479 +-----+-----+-----+-----+-----+-----+-----+ 480 | reserved |src |dest |parm |corr |res | 481 +-----+-----+-----+-----+-----+-----+-----+ 483 Figure 3 485 A little bit more terminology: if the block is a PIB then when we 486 refer to the "PIB-source", we mean the security source for the PIB as 487 represented by the EID reference in the EID-references field. 488 Similarly we may refer to the PCB-dest, meaning the security- 489 destination of the PCB, again as represented by an EID reference. 490 For example, referring to Figure 1 again, if the bundle that 491 originates at BN1 as source is given a Confidentiality Block (PCB) by 492 BN1 that is protected using a key held by BN3 and it is given a 493 Payload Integrity Block (PIB) by BN1, then BN1 is both the PCB-source 494 and the PIB-source of the bundle, and BN3 is the PCB-dest of the 495 bundle. 497 The correlator field is used to associate several related instances 498 of a security block. This can be used to place a BAB that contains 499 the ciphersuite information at the "front" of a (probably large) 500 bundle, and another correlated BAB that contains the security result 501 at the "end" of the bundle. This allows even very memory-constrained 502 nodes to be able to process the bundle and verify the BAB. There are 503 similar use cases for multiple related instances of PIB and PCB as 504 will be seen below. 506 The ciphersuite specification MUST make it clear whether or not 507 multiple block instances are allowed, and if so, under what 508 conditions. Some ciphersuites can of course leave flexibility to the 509 implementation, whereas others might mandate a fixed number of 510 instances. 512 For convenience, we use the term "first block" to refer to the 513 initial block in a group of correlated blocks, or to the single block 514 if there are no others in the set. Obviously there can be several 515 unrelated groups in a bundle, each containing only one block or more 516 than one, and each has its own "first block". 518 2.2. Bundle Authentication Block 520 In this section we describe typical BAB field values for two 521 scenarios - where a single instance of the BAB contains all the 522 information and where two related instances are used, one "up front" 523 which contains the ciphersuite and another following the payload 524 which contains the security result (e.g. a MAC). 526 For the case where a single BAB is used: 528 The block-type code field value MUST be 0x02. 530 The block processing control flags value can be set to whatever 531 values are required by local policy. Ciphersuite designers should 532 carefully consider the effect of setting flags that either discard 533 the block or delete the bundle in the event that this block cannot 534 be processed. 536 The ciphersuite ID MUST be documented as a hop-by-hop 537 authentication-ciphersuite which requires one instance of the BAB. 539 The correlator field MUST NOT be present. 541 The ciphersuite parameters field MAY be present, if so specified 542 in the ciphersuite specification. 544 An EID reference to the security-source MAY be present and, if so, 545 it MUST identify the forwarder of the bundle. The security-source 546 can also be specified as part of key information described in 547 Section 2.6 or another block such as the Previous Hop Insertion 548 Block. The security-source might also be inferred from some 549 implementation-specific means such as the convergence layer. 551 An EID reference to the security-destination MAY be present and is 552 useful to ensure that the bundle has been forwarded to the correct 553 next-hop node. 555 The security result MUST be present as it is effectively the 556 "output" from the ciphersuite calculation (e.g. the MAC or 557 signature) applied to the (relevant parts of) the bundle (as 558 specified in the ciphersuite definition). 560 For the case using two related BAB instances, the first instance is 561 as defined above, except the ciphersuite ID MUST be documented as a 562 hop-by-hop authentication ciphersuite that requires two instances of 563 the BAB. In addition, the correlator MUST be present and the 564 security result length and security result fields MUST be absent. 565 The second instance of the BAB MUST have the same correlator value 566 present and MUST contain security result length and security result 567 data fields. The other optional fields MUST NOT be present. 568 Typically, this second instance of a BAB will be the last block of 569 the bundle. 571 The details of key transport for BAB are specified by the particular 572 ciphersuite. In the absence of conflicting requirements, the 573 following should be noted by implementors: 575 the key information item Section 2.6 is optional, and if not 576 provided then the key should be inferred from the source- 577 destination tuple, being the previous key used, a key created from 578 a key-derivation function, or a pre-shared key 580 since BAB is for a single hop, by definition, the capabilities of 581 the underlying convergence layer might be useful for key transport 583 depending upon the key mechanism used, bundles can be signed by 584 the sender, or authenticated for one or more recipients, or both. 586 2.3. Payload Integrity Block 588 A PIB is an ASB with the following additional restrictions: 590 The block type code value MUST be 0x03. 592 The block processing control flags value can be set to whatever 593 values are required by local policy. Ciphersuite designers should 594 carefully consider the effect of setting flags that either discard 595 the block or delete the bundle in the event that this block cannot 596 be processed. 598 The ciphersuite ID MUST be documented as an end-to-end 599 authentication-ciphersuite or as an end-to-end error-detection- 600 ciphersuite. 602 The correlator MUST be present if the ciphersuite requires more 603 than one related instance of a PIB be present in the bundle. The 604 correlator MUST NOT be present if the ciphersuite only requires 605 one instance of the PIB in the bundle. 607 The ciphersuite parameters field MAY be present. 609 An EID reference to the security-source MAY be present. 611 An EID reference to the security-destination MAY be present. 613 The security result is effectively the "output" from the 614 ciphersuite calculation (e.g. the MAC or signature) applied to the 615 (relevant parts of) the bundle. As in the case of the BAB, this 616 field MUST be present if the correlator is absent. If more than 617 one related instance of the PIB is required then this is handled 618 in the same way as described for the BAB above. 620 The ciphersuite MAY process less than the entire original bundle 621 payload, either because the current payload is a fragment of the 622 original bundle or just becuase it is defined to process some 623 subset. For whatever reason, if the ciphersuite processes less 624 than the complete, original bundle payload, the ciphersuite 625 parameters of this block MUST specify which bytes of the bundle 626 payload are protected. 628 For some ciphersuites, (e.g. those using asymmetric keying to produce 629 signatures or those using symmetric keying with a group key), the 630 security information can be checked at any hop on the way to the 631 security destination that has access to the required keying 632 information. This possibility is further discussed in Section 3.6 633 below. 635 The use of a generally-available key is RECOMMENDED if custodial 636 transfer is employed and all nodes SHOULD verify the bundle before 637 accepting custody. 639 Most asymmetric PIB-ciphersuites will use the PIB-source to indicate 640 the signer and will not require the PIB-dest field because the key 641 needed to verify the PIB authenticator will be a public key 642 associated with the PIB-source. 644 2.4. Payload Confidentiality Block 646 A typical confidentiality ciphersuite will encrypt the payload using 647 a randomly generated bundle encrypting key (BEK) and will use a key 648 information item in the PCB security parameters to carry the BEK 649 encrypted with some long term key encryption key (KEK) or well-known 650 public key. If neither the destination nor security-destination 651 resolves the key to use for decryption, the key information item in 652 the ciphersuite parameters field can also be used to indicate the 653 decryption key with which the BEK can be recovered. If the bundle 654 already contains PIBs and/or PCBs these SHOULD also be encrypted 655 using this same BEK, as described just below for "super-encryption". 657 It is strongly RECOMMENDED that a data integrity mechanism be used in 658 conjunction with confidentiality, and that encryption-only 659 ciphersuites NOT be used. AES-GCM satisfies this requirement. The 660 "authentication tag" or "integrity check value" is stored into 661 security-result rather than being appended to the payload as is 662 common in some protocols since, as described below, it is important 663 that there be no change in the size of the payload. 665 The payload is encrypted "in-place", that is, following encryption, 666 the payload block payload field contains ciphertext, not plaintext. 667 The payload block processing flags are unmodified. 669 The "in-place" encryption of payload bytes is to allow bundle payload 670 fragmentation and re-assembly, and custody transfer, to operate 671 without knowledge of whether or not encryption has occurred and, if 672 so, how many times. 674 Fragmentation and reassembly and custody transfer are adversely 675 affected by a change in size of the payload due to ambiguity about 676 what byte range of the original payload is actually in any particular 677 fragment. Ciphersuites SHOULD place any payload expansion, such as 678 authentication tags (integrity check values) and any padding 679 generated by a block-mode cipher, into an "integrity check value" 680 item in the security-result field (see Section 2.6) of the 681 confidentiality block. 683 Payload super-encryption is allowed; that is, encrypting a payload 684 that has already been encrypted, perhaps more than once. 685 Ciphersuites SHOULD define super-encryption such that, as well as re- 686 encrypting the payload, it also protects the parameters of earlier 687 encryption. Failure to do do may represent a vulnerability in some 688 circumstances. 690 Confidentiality is normally applied to the payload, and possibly to 691 additional blocks. It is RECOMMENDED to apply a Payload 692 Confidentiality ciphersuite to non-payload blocks only if these 693 should be super-encrypted with the payload. If super-encryption of 694 the block is not desired then protection of the block should be done 695 using the Extension Security Block mechanism rather than PCB. 697 Multiple related PCB instances are required if both the payload and 698 PIBs and PCBs in the bundle are to be encrypted. These multiple PCB 699 instances require correlators to associate them with each other since 700 the key information is provided only in the first PCB. 702 There are situations where more than one PCB instance is required but 703 the instances are not "related" in the sense which requires 704 correlators. One example is where a payload is encrypted for more 705 than one security-destination so as to be robust in the face of 706 routing uncertainties. In this scenario the payload is encrypted 707 using a BEK. Several PCBs contain the BEK encrypted using different 708 KEKs, one for each destination. These multiple PCB instances, are 709 not "related" and should not contain correlators. 711 The ciphersuite MAY apply different rules to confidentiality for non- 712 payload blocks. 714 A PCB is an ASB with the following additional restrictions: 716 The block type code value MUST be 0x04. 718 The block processing control flags value can be set to whatever 719 values are required by local policy, except that a PCB "first 720 block" MUST have the "replicate in every fragment" flag set. This 721 flag SHOULD NOT be set otherwise. Ciphersuite designers should 722 carefully consider the effect of setting flags that either discard 723 the block or delete the bundle in the event that this block cannot 724 be processed. 726 The ciphersuite ID MUST be documented as a confidentiality- 727 ciphersuite. 729 The correlator MUST be present if there is more than one related 730 PCB instance. The correlator MUST NOT be present if there are no 731 related PCB instances. 733 If a correlator is present, the key information MUST be placed in 734 the PCB "first block". 736 Any additional bytes generated as a result of encryption and/or 737 authentication processing of the payload SHOULD be placed in an 738 "integrity check value" field (see Section 2.6) in the security- 739 result of the first PCB. 741 The ciphersuite parameters field MAY be present. 743 An EID reference to the security-source MAY be present. 745 An EID reference to the security-destination MAY be present. 747 The security result MAY be present and normally contains fields 748 such as an encrypted bundle encryption key, authentication tag or 749 the encrypted versions of bundle blocks other than the payload 750 block. 752 As was the case for the BAB and PIB, if the ciphersuite requires more 753 than one instance of the PCB, then the "first block" MUST contain any 754 optional fields (e.g., security destination etc.) that apply to all 755 instances with this correlator. These MUST be contained in the first 756 instance and MUST NOT be repeated in other correlated blocks. Fields 757 that are specific to a particular instance of the PCB MAY appear in 758 that PCB. For example, security result fields MAY (and probably 759 will) be included in multiple related PCB instances, with each result 760 being specific to that particular block. Similarly, several PCBs 761 might each contain a ciphersuite parameters field with an IV specific 762 to that PCB instance. 764 Put another way: when confidentiality will generate multiple blocks, 765 it MUST first create a PCB with the required ciphersuite ID, 766 parameters etc. as specified above. Typically, this PCB will appear 767 "early" in the bundle. If this "first" PCB doesn't contain all of 768 the ciphertext, then it MAY be followed by other, correlated PCBs 769 which MUST NOT repeat the ciphersuite parameters, security-source, or 770 security-destination fields from the first PCB. 772 PCB ciphersuites MUST specify which blocks are to be encrypted. The 773 specification MAY be flexible and be dependent upon block type, 774 security policy, various data values and other inputs but it MUST be 775 deterministic. The determination of whether a block is to be 776 encrypted or not MUST NOT be ambiguous. 778 The ciphersuite MAY process less than the entire original bundle 779 payload, either because the current payload is a fragment of the 780 original bundle or just becuase it is defined to process some subset. 781 For whatever reason, if the ciphersuite processes less than the 782 complete, original bundle payload the PCB MUST specify, as part of 783 the ciphersuite parameters, which bytes of the bundle payload are 784 protected. 786 After decryption the plaintext recovered from the security-result 787 field should then replace the PCB in the bundle for further 788 processing (e.g. PIB verification). This recovered plaintext MUST 789 contain all the appropriate block type, processing flags and length 790 information. In other words delete the PCB in question and place the 791 recovered plaintext, which consists of some complete non-payload 792 block, in the bundle at the location from which the PCB was deleted. 794 A ciphersuite MUST NOT mix payload data and a non-payload block in a 795 single PCB. 797 Even if a to-be-encrypted block has the "discard" flag set, whether 798 or not the PCB's "discard" flag is set is an implementation/policy 799 decision for the encrypting node. (The "discard" flag is more 800 properly called the "discard if block cannot be processed" flag.) 802 Any existing eid-list in the to-be-encapsulated original block 803 remains exactly as-is, and becomes the eid-list for the replacing 804 block. The encapsulation process MUST NOT replace or remove the 805 existing eid-list entries. This is critically important for correct 806 updating of entries at the security-destination. 808 At the security-destination, either specific destination or the 809 bundle destination, the processes described above are reversed. The 810 payload is decrypted in-place using the salt, IV and key values in 811 the first PCB, including verification using the ICV. These values 812 are described below in Section 2.6. Each correlated PCB is also 813 processed at the same destination, using the salt and key values from 814 the first PCB and the block-specific IV item. The "encapsulated 815 block" item in security-result is decrypted and validated, using also 816 the tag which SHOULD have been appended to the ciphertext of the 817 original block data. Assuming the validation succeeds, the resultant 818 plaintext, which is the entire content of the original block, 819 replaces the PCB at the same place in the bundle. The block type 820 reverts to that of the original block prior to encapsulation, and the 821 other block-specific data fields also return to their original 822 values. Implementors are cautioned that this "replacement" process 823 requires delicate stitchery, as the eid-list contents in the 824 decapsulated block are invalid. As noted above, the eid-list 825 references in the original block were preserved in the replacing PCB, 826 and will have been updated as necessary as the bundle has toured the 827 dtn. The references from the PCB MUST replace the references within 828 the eid-list of the newly-decapsulated block. Caveat implementor. 830 2.5. Extension Security Block 832 Extension security blocks provide protection for non-payload-related 833 portions of a bundle. They MUST NOT be used for the primary block or 834 payload, including payload-related security blocks (PIBs and PCBs). 836 It is sometimes desirable to protect certain parts of a bundle in 837 ways other than those applied to the bundle payload. One such 838 example is bundle metadata that might specify the kind of data in the 839 payload but not the actual payload detail, as described in [DTNMD]. 841 ESBs are typically used to apply confidentiality protection. While 842 it is possible to create an integrity-only ciphersuite, the block 843 protection is not transparent and makes access to the data more 844 difficult. For simplicity, this discussion describes use of a 845 confidentiality ciphersuite. 847 The protection mechanisms in ESBs are similar to other security 848 blocks with two important differences: 850 - different key values are used (using same key as for payload 851 would defeat the purpose) 853 - the block is not encrypted or super-encrypted with the payload 855 A typical ESB ciphersuite will encrypt the extension block using a 856 randomly generated ephemeral key and will use the key information 857 item in the security parameters field to carry the key encrypted with 858 some long term key encryption key (KEK) or well-known public key. If 859 neither the destination nor security-destination resolves the key to 860 use for decryption, the key information item in the ciphersuite 861 parameters field can be used also to indicate the decryption key with 862 which the BEK can be recovered. 864 It is strongly RECOMMENDED that a data integrity mechanism be used in 865 conjunction with confidentiality, and that encryption-only 866 ciphersuites NOT be used. AES-GCM satisfies this requirement. 868 The ESB is placed in the bundle in the same position as the block 869 being protected. That is, the entire original block is processed 870 (encrypted, etc) and encapsulated in a "replacing" ESB-type block, 871 and this appears in the bundle at the same sequential position as the 872 original block. The processed data is placed in the security-result 873 field. 875 The process is reversed at the security destination with the 876 recovered plaintext block replacing the ESB that had encapsulated it. 877 Processing of EID-list entries, if any, is described above in 878 Section 2.4 and this MUST be followed in order to correctly recover 879 EIDs. 881 An ESB is an ASB with the following additional restrictions: 883 Block type is 0x09. 885 Ciphersuite flags indicate which fields are present in this block. 886 Ciphersuite designers should carefully consider the effect of 887 setting flags that either discard the block or delete the bundle 888 in the event that this block cannot be processed. 890 EID references MUST be stored in the EID reference list. 892 Security-source MAY be present. If not present, then the bundle- 893 source is used as the security-source. 895 Security-destination MAY be present. If not present, then the 896 bundle-destination is used as the security-destination. 898 The security-parameters MAY optionally contain a block-type field to 899 indicate the type of the encapsulated block. Since this replicates a 900 field in the encrypted portion of the block, it is a slight security 901 risk and its use is therefore OPTIONAL. 903 2.6. Parameters and Result Fields 905 Various ciphersuites include several items in the security-parameters 906 and/or security-result fields. Which items MAY appear is defined by 907 the particular ciphersuite description. A ciphersuite MAY support 908 several instances of the same type within a single block. 910 Each item is represented as type-length-value. Type is a single byte 911 indicating which item this is. Length is the count of data bytes to 912 follow, and is an SDNV-encoded integer. Value is the data content of 913 the item. 915 Item types are 917 0: reserved 919 1: initialization vector (IV) 921 2: reserved 923 3: key information 925 4: fragment range (offset and length as a pair of SDNVs) 927 5: integrity signature 929 6: reserved 930 7: salt 932 8: PCB integrity check value (ICV) 934 9: reserved 936 10: encapsulated block 938 11: block type of encapsulated block 940 12 - 191: reserved 942 192 - 250: private use 944 251 - 255: reserved 946 The folowing descriptions apply to usage of these items for all 947 ciphersuites. Additional characteristics are noted in the discussion 948 for specific suites. 950 - initialization vector(IV): random value, typically eight to 951 sixteen bytes 953 - key information: key material encoded or protected by the key 954 management system, and used to transport an ephemeral key 955 protected by a long-term key. This item is discussed further 956 below in Section 2.7 958 - fragment range: pair of SDNV values (offset then length) 959 specifying the range of payload bytes to which a particular 960 operation applies. This is termed "fragment range" since that is 961 its typical use, even though sometimes it describes a subset range 962 that is not a fragment 964 - integrity signature: result of BA or PI digest or signing 965 operation. This item is discussed further below in Section 2.7 967 - salt: an IV-like value used by certain confidentiality suites 969 - PCB integrity check value(ICV): output from certain 970 confidentiality ciphersuite operations to be used at the 971 destination to verify that the protected data has not been 972 modified 974 - encapsulated block: result of confidentiality operation on 975 certain blocks, contains the ciphertext of the block and MAY also 976 contain an integrity check value appended to the ciphertext; MAY 977 also contain padding if required by the encryption mode; used for 978 non-payload blocks only 980 - block type of encapsulated block: block type code for a block 981 that has been encapsulated in ESB 983 2.7. Key Transport 985 This specification endeavours to maintain separation between the 986 security protocol and key management. However, these two interact in 987 the transfer of key information, etc., from security-source to 988 security-destination. The intent of the separation is to facilitate 989 use of a variety of key management systems without a necessity to 990 tailor a ciphersuite to each individually. 992 The key management process deals with such things as long-term keys, 993 specifiers for long-term keys, certificates for long-term keys and 994 integrity signatures using long-term keys. The ciphersuite itself 995 should not require a knowledge of these, and separation is improved 996 if it treats these as opaque entities, to be handled by the key 997 management process. 999 The key management process deals specifically with the content of two 1000 of the items defined above in Section 2.6:- key information (item 1001 type 3) and integrity signature (item type 5). The ciphersuite MUST 1002 define the details and format for these items. To facilitate 1003 interoperability, it is strongly RECOMMENDED that the implementations 1004 use the appropriate definitions from Cryptographic Message Syntax 1005 (CMS) [RFC5652] and related RFCs. 1007 Many situations will require several pieces of key information. 1008 Again, ciphersuites MUST define whether they accept these packed into 1009 a single key information item and/or separated into multiple 1010 instances of key information. For interoperability, it is 1011 RECOMMENDED that ciphersuites accept these packed into a single key- 1012 information item, and that they MAY additionally choose to accept 1013 them sent as separate items. 1015 2.8. PIB and PCB combinations 1017 Given the above definitions, nodes are free to combine applications 1018 of PIB and PCB in any way they wish - the correlator value allows for 1019 multiple applications of security services to be handled separately. 1020 Since PIB and PCB apply to the payload and ESB to non-payload blocks, 1021 combinations of ESB with PIB and/or PCB are not considered. 1023 There are some obvious security problems that could arise when 1024 applying multiple services. For example, if we encrypted a payload 1025 but left a PIB security result containing a signature in the clear, 1026 payload guesses could be confirmed. 1028 We cannot, in general, prevent all such problems since we cannot 1029 assume that every ciphersuite definition takes account of every other 1030 ciphersuite definition. However, we can limit the potential for such 1031 problems by requiring that any ciphersuite which applies to one 1032 instance of a PIB or PCB, MUST be applied to all instances with the 1033 same correlator. 1035 We now list the PIB and PCB combinations which we envisage as being 1036 useful to support: 1038 Encrypted tunnels - a single bundle MAY be encrypted many times 1039 en-route to its destination. Clearly it has to be be decrypted an 1040 equal number of times, but we can imagine each encryption as 1041 representing the entry into yet another layer of tunnel. This is 1042 supported by using multiple instances of PCB, but with the payload 1043 encrypted multiple times, "in-place". Depending upon the 1044 ciphersuite defintion, other blocks can and should be encrypted, 1045 as discussed above and in Section 2.4 to ensure that parameters 1046 are protected in the case of super-encryption. 1048 Multiple parallel authenticators - a single security source might 1049 wish to protect the integrity of a bundle in multiple ways. This 1050 could be required if the bundle's path is unpredictable, and if 1051 various nodes might be involved as security destinations. 1052 Similarly, if the security source cannot determine in advance 1053 which algorithms to use, then using all might be reasonable. This 1054 would result in uses of PIB which presumably all protect the 1055 payload, and which cannot in general protect one another. Note 1056 that this logic can also apply to a BAB, if the unpredictable 1057 routing happens in the convergence layer, so we also envisage 1058 support for multiple parallel uses of BAB. 1060 Multiple sequential authenticators - if some security destination 1061 requires assurance about the route that bundles have taken, then 1062 it might insist that each forwarding node add its own PIB. More 1063 likely, however would be that outbound "bastion" nodes would be 1064 configured to sign bundles as a way of allowing the sending 1065 "domain" to take accountability for the bundle. In this case, the 1066 various PIBs will likely be layered, so that each protects the 1067 earlier applications of PIB. 1069 Authenticated and encrypted bundles - a single bundle MAY require 1070 both authentication and confidentiality. Some specifications 1071 first apply the authenticator and follow this by encrypting the 1072 payload and authenticator. As noted previously in the case where 1073 the authenticator is a signature, there are security reasons for 1074 this ordering. (See the PCB-RSA-AES128-PAYLOAD-PIB-PCB 1075 ciphersuite defined later in Section 4.3.) Others apply the 1076 authenticator after encryption, that is, to the ciphertext. This 1077 ordering is generally recommended and minimizes attacks which, in 1078 some cases, can lead to recovery of the encryption key. 1080 There are no doubt other valid ways to combine PIB and PCB instances, 1081 but these are the "core" set supported in this specification. Having 1082 said that, as will be seen, the mandatory ciphersuites defined here 1083 are quite specific and restrictive in terms of limiting the 1084 flexibility offered by the correlator mechanism. This is primarily 1085 designed to keep this specification as simple as possible, while at 1086 the same time supporting the above scenarios. 1088 3. Security Processing 1090 This section describes the security aspects of bundle processing. 1092 3.1. Nodes as policy enforcement points 1094 All nodes are REQUIRED to have and enforce their own configurable 1095 security policies, whether these policies be explicit or default, as 1096 defined in Section 6. 1098 All nodes serve as Policy Enforcement Points (PEP) insofar as they 1099 enforce polices that MAY restrict the permissions of bundle nodes to 1100 inject traffic into the network. Policies MAY apply to traffic 1101 originating at the current node, traffic terminating at the current 1102 node and traffic to be forwarded by the current node to other nodes. 1103 If a particular transmission request, originating either locally or 1104 remotely, satisfies the node's policy or policies and is therefore 1105 accepted, then an outbound bundle can be created and dispatched. If 1106 not, then in its role as a PEP, the node will not create or forward a 1107 bundle. Error handling for such cases is currently considered out of 1108 scope of this document. 1110 Policy enforcing code MAY override all other processing steps 1111 described here and elsewhere in this document. For example, it is 1112 valid to implement a node which always attempts to attach a PIB. 1113 Similarly it is also valid to implement a node which always rejects 1114 all requests which imply the use of a PIB. 1116 Nodes MUST consult their security policy to determine the criteria 1117 that a received bundle ought to meet before it will be forwarded. 1118 These criteria MUST include a determination of whether or not the 1119 received bundle MUST include a valid BAB, PIB, PCB or ESB. If the 1120 bundle does not meet the node's policy criteria, then the bundle MUST 1121 be discarded and processed no further; in this case, a bundle status 1122 report indicating the failure MAY be generated. 1124 The node's policy MAY call for the node to add or subtract some 1125 security blocks, for example, requiring the node attempt to encrypt 1126 (parts of) the bundle for some security-destination, or requiring 1127 that the node add a PIB. If the node's policy requires a BAB to be 1128 added to the bundle, it MUST be added last so that the calculation of 1129 its security result MAY take into consideration the values of all 1130 other blocks in the bundle. 1132 3.2. Processing order of security blocks 1134 The processing order of security actions for a bundle is critically 1135 important for the actions to complete successfully. In general, the 1136 actions performed at the originating node MUST be executed in the 1137 reverse sequence at the destination. There are variations and 1138 exceptions, and these are noted below. 1140 The sequence is maintained in the ordering of security blocks in the 1141 bundle. It is for this reason that blocks MUST not be rearranged at 1142 forwarding nodes, whether they support the security protocols or not. 1143 The only blocks that participate in this ordering are the primary and 1144 payload blocks, and the PIB and PCB security blocks themselves. All 1145 other extension blocks, including ESBs, are ignored for purposes of 1146 determining the processing order. 1148 The security blocks are added to and removed from a bundle in a last- 1149 in-first-out (LIFO) manner, with the top of the stack immediately 1150 after the primary block. A newly-created bundle has just the primary 1151 and payload blocks, and the stack is empty. As security actions are 1152 requested for the bundle, security blocks are pushed onto the stack 1153 immediately after the primary block. The early actions have security 1154 blocks close to the payload, later actions have blocks nearer to the 1155 primary block. The actions deal with only those blocks in the bundle 1156 at the time so, for example, the first to be added processes only the 1157 payload and primary blocks, the next might process the first if it 1158 chooses and the payload and primary, and so on. The last block to be 1159 added can process all the blocks. 1161 When the bundle is received, this process is reversed and security 1162 processing begins at the top of the stack, immediately after the 1163 primary block. The security actions are performed and the block is 1164 popped from the stack. Processing continues with the next security 1165 block until finally only the payload and primary blocks remain. 1167 The simplicity of this description is undermined by various real- 1168 world requirements. Nonetheless it serves as a helpful initial 1169 framework for understanding the bundle security process. 1171 The first issue is a very common one and easy to handle. The bundle 1172 may be sent indirectly to its destination, requiring several 1173 forwarding hops to finally arrive there. Security processing happens 1174 at each node, assuming that the node supports bundle security. For 1175 the following discussion, we assume that a bundle is created and that 1176 confidentiality, then payload integrity and finally bundle 1177 authentication are applied to it. The block sequence would therefore 1178 be primary-BAB-PIB-PCB-payload. Traveling from source to destination 1179 requires going through one intermediate node, so the trip consists of 1180 two hops. 1182 When the bundle is received at the intermediate node, the receive 1183 processing validates the BAB and pops it from the stack. However the 1184 PIBs and PCBs have the final destination as their security 1185 destination, so these can't be processed and removed. The 1186 intermediate node then begins the send process with the four 1187 remaining blocks in the bundle. The outbound processing adds any 1188 security blocks required by local policy, and these are pushed on the 1189 stack immediately after the primary block, ahead of the PIB. In this 1190 example, the intermediate node adds a PIB as a signature that the 1191 bundle has passed through the node. 1193 The receive processing at the destination first handles the 1194 intermediate node's PIB and pops it, next is the originator's PIB, 1195 also popped, and finally the originator's confidentiality block which 1196 allows the payload to be decrypted and the bundle handled for 1197 delivery. 1199 DTNs in practice are likely to be more complex. The security policy 1200 for a node specifies the security requirements for a bundle. The 1201 policy will possibly cause one or more security operations to be 1202 applied to the bundle at the current node, each with its own 1203 security-destination. Application of policy at subsequent nodes 1204 might cause additional security operations, each with a security- 1205 destination. The list of security-destinations in the security 1206 blocks (BAB, PIB and PCB, not ESB) creates a partial-ordering of 1207 nodes that MUST be visited en route to the bundle destination. 1209 The bundle security scheme does not deal with security regions that 1210 overlap partially but not completely. The security policy for a node 1211 MUST avoid specifying for a bundle a security-destination that causes 1212 a conflict with any existing security-destination in that bundle. 1213 This discussed further below in Section 3.3. 1215 The second issue relates to the reversibility of certain security 1216 process actions. In general, the actions fall into two categories: 1217 those which do not affect other parts of the bundle, and those which 1218 are fully reversible. Creating a bundle signature, for example, does 1219 not change the bundle content except for the result. The encryption 1220 performed as part of the confidentiality processing does change the 1221 bundle, but the reverse processing at the destination restores the 1222 original content. 1224 The third category is the one where the bundle content has changed 1225 slightly and in a non-destructive way, but there is no mechanism to 1226 reverse the change. The simplest example is the addition of an EID- 1227 reference to a security block. The addition of the reference causes 1228 the text to be added to the bundle's dictionary. The text may be 1229 used also by other references so removal of the block and this 1230 specific eid-reference does not cause removal of the text from the 1231 dictionary. This shortcoming is of no impact to the "sequential" or 1232 "wrapping" security schemes described above, but does cause failures 1233 with "parallel" authentication mechanisms. Solutions for this 1234 problem are implementation-specific and typically involve multi-pass 1235 processing such that blocks are added at one stage and the security 1236 results calculated at a later stage of the overall process. 1238 Certain ciphersuites have sequence requirements for their correct 1239 operation, most notably the bundle authentication ciphersuites. 1240 Processing for bundle authentication is required to happen after all 1241 other sending operations, and prior to any receive operations at the 1242 next hop node. It follows therefore that BA blocks MUST always be 1243 pushed onto the stack after all others. 1245 Although we describe the security block list as a stack, there are 1246 some blocks which are placed after the payload and therefore are not 1247 part of the stack. The BundleAuthentication ciphersuite #1 ("BA1") 1248 requires a second, correlated block to contain the security-result 1249 and this block is placed after the payload, usually as the last block 1250 in the bundle. We can apply the stack rules even to these blocks by 1251 specifying that they be added to the end of the bundle at the same 1252 time that their "owner" or "parent" block is pushed on the stack. In 1253 fact, they form a stack beginning at the payload but growing in the 1254 other direction. Also, not all blocks in the main stack have a 1255 corresponding entry in the trailing stack. The only blocks which 1256 MUST follow the payload are those mandated by ciphersuites as 1257 correlated blocks for holding a security-result. No other blocks are 1258 required to follow the payload block and it is RECOMMENDED that they 1259 NOT do so. 1261 ESBs are effectively placeholders for the blocks they encapsulate 1262 and, since those do not form part of the processing sequence 1263 described above, ESBs themselves do not either. ESBs MAY be 1264 correlated, however, so the "no reordering" requirement applies to 1265 them as well. 1267 3.3. Security Regions 1269 Each security block has a security region, as described in the 1270 discussion for Figure 1, and the regions for various blocks are often 1271 different. 1273 BA blocks are always for a single hop and these restricted regions 1274 never cause conflict. 1276 The regions for PIBs and PCBs are often from bundle source to bundle 1277 destination, to provide end-to-end protection. A bundle-source-to- 1278 bundle-destination region likewise never causes a problem. 1280 Another common scenario is for gateway-to-gateway protection of 1281 traffic between two sub-networks ("tunnel-mode"). 1283 Looking at Figure 1 and the simplified version shown in Figure 4, we 1284 can regard BN2 and BN3 as gateways connecting the two subnetworks 1285 labeled "An internet". As long as they provide security for the BN2- 1286 BN3 region, all is well. Problems begin, for example, when BN2 adds 1287 blocks with BN4 as the security-destination, and originating node BN1 1288 has created blocks with BN3 as security-destination. We now have two 1289 regions and neither is a subset of the other. 1291 This scenario should be prevented by node BN2's security policy being 1292 aware of the already-existing block with BN3 as the security 1293 destination. This policy SHOULD NOT specify a security-dest that is 1294 further distant than any existing security-dest. 1296 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 1297 | BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 | 1298 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 1299 >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ 1301 <------------- BN1 to BN3 region ------------> 1303 <------------- BN2 to BN4 region ------------> 1305 Overlapping security regions 1307 Figure 4 1309 Consider the case where the security concern is for data integrity, 1310 so the blocks are PIBs. BN1 creates one ("PIa") along with the new 1311 bundle, and BN2 pushes its own PIB "PIb" on the stack, with security- 1312 destination BN4. When this bundle arrives at BN3, the bundle blocks 1313 are 1315 primary - PIb - PIa - payload 1317 Block PIb is not destined for this node BN3 so has to be forwarded. 1318 This is the security-destination for block PIa so, after validation, 1319 it should be removed from the bundle. But that will invalidate the 1320 PIb signature when the block is checked at the final destination. 1321 The PIb signature includes the primary block, PIb itself, PIa and the 1322 payload block, so PIa MUST remain in the bundle. This is why 1323 security blocks are treated as a stack and add/remove operations are 1324 permitted only at the top-of-stack. 1326 The situation would be worse if the security concern is 1327 confidentiality, so PCBs are employed, such as the confidentiality 1328 ciphersuite #3 ("PC3") described in Section 4.3. In this scenario, 1329 BN1 would encrypt the bundle with BN3 as security-destination, BN2 1330 would super-encrypt the payload and encapsulate the PC3 block for 1331 security-destination BN4. BN3 forwards all the blocks without 1332 change. BN4 decrypts the payload from its super-encryption and 1333 decapsulates the PC3 block, only to find that it should have been 1334 processed earlier. Assuming that BN4 has no access to BN3's key 1335 store, BN4 has no way to decrypt the bundle and recover the original 1336 content. 1338 As mentioned above, authors of security policy need to use care to 1339 ensure that their policies do not cause overlaps. These guidelines 1340 should prove helpful: 1342 the originator of a bundle can always specify the bundle-dest as 1343 the security-dest, and should be cautious about doing otherwise 1345 in the "tunnel-mode" scenario where two sub-networks are connected 1346 by a tunnel through a network, the gateways can each specify the 1347 other as security-dest, and should be cautious about doing 1348 otherwise 1350 BAB is never a problem because it is always only a single hop 1352 PIB for a bundle without PCB will usually specify the bundle 1353 destination as security-dest 1355 PIB for a bundle containing a PCB should specify as its security- 1356 dest the security-dest of the PCB (outermost PCB if there are more 1357 than one) 1359 3.4. Canonicalisation of bundles 1361 In order to verify a signature or MAC on a bundle the exact same 1362 bits, in the exact same order, MUST be input to the calculation upon 1363 verification as were input upon initial computation of the original 1364 signature or MAC value. Consequently, a node MUST NOT change the 1365 encoding of any URI in the dictionary field, e.g., changing the DNS 1366 part of some HTTP URL from lower case to upper case. Because bundles 1367 MAY be modified while in transit (either correctly or due to 1368 implementation errors), a canonical form of any given bundle (that 1369 contains a BAB or PIB) MUST be defined. 1371 This section defines bundle canonicalisation algorithms used in the 1372 Section 4.1 and Section 4.2 ciphersuites. Other ciphersuites can use 1373 these or define their own canonicalization procedures. 1375 3.4.1. Strict canonicalisation 1377 The first algorithm that can be used permits no changes at all to the 1378 bundle between the security-source and the security-destination. It 1379 is mainly intended for use in BAB ciphersuites. This algorithm 1380 conceptually catenates all blocks in the order presented, but omits 1381 all security result data fields in blocks of this ciphersuite type. 1382 That is, when a BA ciphersuite specifies this algorithm then we omit 1383 all BAB security results for all BA ciphersuites, when a PIB 1384 ciphersuite specifies this algorithm then we omit all PIB security 1385 results for all PI ciphersuites. All security result length fields 1386 are included, even though their corresponding security result data 1387 fields are omitted. 1389 Notes: 1391 - In the above we specify that security result data is omitted. 1392 This means that no bytes of the security result data are input. 1393 We do not set the security result length to zero. Rather, we 1394 assume that the security result length will be known to the module 1395 that implements the ciphersuite before the security result is 1396 calculated, and require that this value be in the security result 1397 length field even though the security result data itself will be 1398 omitted. 1400 - The 'res' bit of the ciphersuite ID, which indicates whether or 1401 not the security result length and security result data field are 1402 present, is part of the canonical form. 1404 -The value of the block data length field, which indicates the 1405 length of the block, is also part of the canonical form. Its 1406 value indicates the length of the entire bundle when the bundle 1407 includes the security result data field. 1409 -BABs are always added to bundles after PIBs, so when a PIB 1410 ciphersuite specifies this strict canonicalisation algorithm and 1411 the PIB is received with a bundle that also includes one or more 1412 BABs, application of strict canonicalisation as part of the PIB 1413 security result verification process requires that all BABs in the 1414 bundle be ignored entirely. 1416 3.4.2. Mutable canonicalisation 1418 This algorithm is intended to protect parts of the bundle which 1419 should not be changed in-transit. Hence it omits the mutable parts 1420 of the bundle. 1422 The basic approach is to define a canonical form of the primary block 1423 and catenate it with the security (PIBs and PCBs only) and payload 1424 blocks in the order that they will be transmitted. This algorithm 1425 ignores all other blocks, including ESBs, because it cannot be 1426 determined whether or not they will change as the bundle transits the 1427 network. In short, this canonicalization protects the payload, 1428 payload-related security blocks and parts of the primary block. 1430 Many fields in various blocks are stored as variable-length SDNVs. 1431 These are canonicalized in unpacked form, as eight-byte fixed-width 1432 fields in network byte order. The size of eight bytes is chosen 1433 because implementations MAY handle larger values as invalid, as noted 1434 in [DTNBP]. 1436 The canonical form of the primary block is shown in Figure 5. 1437 Essentially, it de-references the dictionary block, adjusts lengths 1438 where necessary and ignores flags that MAY change in transit. 1440 +----------------+----------------+----------------+----------------+ 1441 | Version | Processing flags (incl. COS and SRR) | 1442 +----------------+----------------+---------------------------------+ 1443 | Canonical primary block length | 1444 +----------------+----------------+---------------------------------+ 1445 | Destination endpoint ID length | 1446 +----------------+----------------+---------------------------------+ 1447 | | 1448 | Destination endpoint ID | 1449 | | 1450 +----------------+----------------+---------------------------------+ 1451 | Source endpoint ID length | 1452 +----------------+----------------+----------------+----------------+ 1453 | | 1454 | Source endpoint ID | 1455 | | 1456 +----------------+----------------+---------------------------------+ 1457 | Report-to endpoint ID length | 1458 +----------------+----------------+----------------+----------------+ 1459 | | 1460 | Report-to endpoint ID | 1461 | | 1462 +----------------+----------------+----------------+----------------+ 1463 | | 1464 + Creation Timestamp (2 x SDNV) + 1465 | | 1466 +---------------------------------+---------------------------------+ 1467 | Lifetime | 1468 +----------------+----------------+----------------+----------------+ 1470 The canonical form of the primary bundle block. 1472 Figure 5 1474 The fields shown in Figure 5 are: 1476 Version is the single-byte value in the primary block. 1478 Processing flags in the primary block is an SDNV, and includes the 1479 class-of-service (COS) and status report request (SRR) fields. 1480 For purposes of canonicalization, the SDNV is unpacked into a 1481 fixed-width field and some bits are masked out. The unpacked 1482 field is ANDed with mask 0x0000 0000 003E 031F to set to zero all 1483 reserved bits and the "bundle is a fragment" bit. 1485 Length - a four-byte value containing the length (in bytes) of 1486 this structure, in network byte order. 1488 Destination endpoint ID length and value - are the length (as a 1489 four byte value in network byte order) and value of the 1490 destination endpoint ID from the primary bundle block. The URI is 1491 simply copied from the relevant part(s) of the dictionary block 1492 and is not itself canonicalised. Although the dictionary entries 1493 contain null-terminators, the null-terminators are not included in 1494 the length or the canonicalization. 1496 Source endpoint ID length and value are handled similarly to the 1497 destination. 1499 Report-to endpoint ID length and value are handled similarly to 1500 the destination. 1502 Creation time (2 x SDNV) and Lifetime (SDNV) are simply copied 1503 from the primary block, with the SDNV values being represented as 1504 eight-byte unpacked values. 1506 Fragment offset and Total application data unit length are 1507 ignored, as is the case for the "bundle is a fragment" bit 1508 mentioned above. If the payload data to be canonicalized is less 1509 than the complete, original bundle payload, the offset and length 1510 are specified in the security-parameters. 1512 For non-primary blocks being included in the canonicalization, the 1513 block processing flags value used for canonicalization is the 1514 unpacked SDNV value with reserved and mutable bits masked to zero. 1515 The unpacked value is ANDed with mask 0x0000 0000 0000 0057 to zero 1516 reserved bits and the "last block" flag. The "last block" flag is 1517 ignored because BABs and other security blocks MAY be added for some 1518 parts of the journey but not others so the setting of this bit might 1519 change from hop to hop. 1521 Endpoint ID references in security blocks are canonicalized using the 1522 de-referenced text form in place of the reference pair. The 1523 reference count is not included, nor is the length of the endpoint ID 1524 text. 1526 The block-length is canonicalized as an eight-byte unpacked value in 1527 network byte order. If the payload data to be canonicalized is less 1528 than the complete, original bundle payload, this field contain the 1529 size of the data being canonicalized (the "effective block") rather 1530 that the actual size of the block. 1532 Payload blocks are generally canonicalized as-is with the exception 1533 that in some instances only a portion of the payload data is to be 1534 protected. In such a case, only those bytes are included in the 1535 canonical form, and additional ciphersuite parameters are required to 1536 specify which part of the payload is protected, as discussed further 1537 below. 1539 Security blocks are handled likewise, except that the ciphersuite 1540 will likely specify that the "current" security block security result 1541 field not be considered part of the canonical form. This differs 1542 from the strict canonicalisation case since we might use the mutable 1543 canonicalisation algorithm to handle sequential signatures such that 1544 signatures cover earlier ones. 1546 ESBs MUST NOT be included in the canonicalization. 1548 Notes: 1550 - The canonical form of the bundle is not transmitted. It is 1551 simply an artifact used as input to digesting. 1553 - We omit the reserved flags because we cannot determine if they 1554 will change in transit. The masks specified above will have to be 1555 revised if additional flags are defined and they need to be 1556 protected. 1558 - Our URI encoding does not preserve the "null-termination" 1559 convention from the dictionary field, nor do we separate the 1560 scheme and ssp as is done there. 1562 - The URI encoding will cause errors if any node rewrites the 1563 dictionary content (e.g. changing the DNS part of an HTTP URL from 1564 lower-case to upper case). This could happen transparently when a 1565 bundle is synched to disk using one set of software and then read 1566 from disk and forwarded by a second set of software. Because 1567 there are no general rules for canonicalising URIs (or IRIs), this 1568 problem may be an unavoidable source of integrity failures. 1570 - All SDNV fields here are canonicalized as eight-byte unpacked 1571 values in network byte order. Length fields are canonicalized as 1572 four-byte values in network byte order. Encoding does not need 1573 optimization since the values are never sent over the network. 1575 If a bundle is fragmented before the PIB is applied then the PIB 1576 applies to a fragment and not the entire bundle. However, the 1577 protected fragment could be subsequently further fragmented, which 1578 would leave the verifier unable to know which bytes were protected 1579 by the PIB. Even in the absence of frgmentation the same 1580 situation applies if the ciphersuite is defined to allow 1581 protection of less than the entire, original bundle payload. 1583 For this reason, PIB ciphersuites which support applying a PIB to 1584 less than the complete, original bundle payload MUST specify, as 1585 part of the ciphersuite parameters, which bytes of the bundle 1586 payload are protected. When verification occurs, only the 1587 specified range of the payload bytes are input to PIB 1588 verification. It is valid for a ciphersuite to be specified so as 1589 to only apply to entire bundles and not to fragments. A 1590 ciphersuite MAY be specified to apply to only a portion of the 1591 payload, regardless of whether the payload is a fragment or the 1592 complete original bundle payload. 1594 The same fragmentation issue applies equally to PCB ciphersuites. 1595 Ciphersuites which support applying confidentiality to fragments 1596 MUST specify, as part of the ciphersuite parameters, which bytes 1597 of the bundle payload are protected. When decrypting a fragment, 1598 only the specified bytes are processed. It is also valid for a 1599 confidentiality ciphersuite to be specified so as to only apply to 1600 entire bundles and not to fragments. 1602 This definition of mutable canonicalization assumes that endpoint IDs 1603 themselves are immutable and is unsuitable for use in environments 1604 where that assumption might be violated. 1606 Since the canonicalization applies to a specific bundle rather than a 1607 payload, an originator's signature cannot be verified if a payload is 1608 forwarded, as the forwarded bundle will have a different source. 1610 The solution for either of these issues is to define and use a PIB 1611 ciphersuite having an alternate version of mutable canonicalization 1612 any fields from the primary block. 1614 3.5. Endpoint ID confidentiality 1616 Every bundle MUST contain a primary block that contains the source 1617 and destinations endpoint IDs, and others, and that cannot be 1618 encrypted. If endpoint ID confidentiality is required, then bundle- 1619 in-bundle encapsulation can solve this problem in some instances. 1621 Similarly, confidentiality requirements MAY also apply to other parts 1622 of the primary block (e.g. the current-custodian) and that is 1623 supported in the same manner. 1625 3.6. Bundles received from other nodes 1627 Nodes implementing this specification SHALL consult their security 1628 policy to determine whether or not a received bundle is required by 1629 policy to include a BAB. If the bundle has no BAB and one is not 1630 required then BAB processing on the received bundle is complete and 1631 the bundle is ready to be further processed for PIB/PCB/ESB handling 1632 or delivery or forwarding. 1634 If the bundle is required to have a BAB but does not, then the bundle 1635 MUST be discarded and processed no further. If the bundle is 1636 required to have a BAB but all of its BABs identify a different node 1637 other than the receiving node as the BAB security destination, then 1638 the bundle MUST be discarded and processed no further. 1640 If the bundle is required to have a BAB and has one or more BABs that 1641 identify the receiving node as the BAB security destination, or for 1642 which there is no security destination, then the value in the 1643 security result field(s) of the BAB(s) MUST be verified according to 1644 the ciphersuite specification. If for all such BABs in the bundle 1645 either the BAB security source cannot be determined or the security 1646 result value check fails, the bundle has failed to authenticate and 1647 the bundle MUST be discarded and processed no further. If any of the 1648 BABs present verify, or if a BAB is not required, the bundle is ready 1649 for further processing as determined by extension blocks and/or 1650 policy. 1652 BABs received in a bundle MUST be stripped before the bundle is 1653 forwarded. New BABs MAY be added as required by policy. This MAY 1654 require correcting the "last block" field of the to-be-forwarded 1655 bundle. 1657 Further processing of the bundle MUST take place in the order 1658 indicated by the various blocks from the primary block to the payload 1659 block, except as defined by an applicable specification. 1661 If the bundle has a PCB and the receiving node is the PCB destination 1662 for the bundle (either because the node is listed as the bundle's 1663 PCB-dest or because the node is listed as the bundle's destination 1664 and there is no PCB-dest), the node MUST decrypt the relevant parts 1665 of the bundle in accordce with the ciphersuite specification. The 1666 PCB SHALL be deleted. If the relevant parts of the bundle cannot be 1667 decrypted (i.e. the decryption key cannot be deduced or decryption 1668 fails), then the bundle MUST be discarded and processed no further; 1669 in this case a bundle deletion status report (see the Bundle Protocol 1670 [DTNBP]) indicating the decryption failure MAY be generated. If the 1671 PCB security result included the ciphertext of a block other than the 1672 payload block, the recovered plaintext block MUST be placed in the 1673 bundle at the location from which the PCB was deleted. 1675 If the bundle has one or more PIBs for which the receiving node is 1676 the bundle's PIB destination (either because the node is listed in 1677 the bundle's PIB-dest or because the node is listed as the bundle's 1678 destination and there is no PIB-dest), the node MUST verify the value 1679 in the PIB security result field(s) in accordance with the 1680 ciphersuite specification. If all the checks fail, the bundle has 1681 failed to authenticate and the bundle SHALL be processed according to 1682 the security policy. A bundle status report indicating the failure 1683 MAY be generated. Otherwise, if the PIB verifies, the bundle is 1684 ready to be processed for either delivery or forwarding. Before 1685 forwarding the bundle, the node SHOULD remove the PIB from the 1686 bundle, subject to the requirements of Section 3.2, unless it is 1687 likely that some downstream node will also be able to verify the PIB. 1689 If the bundle has a PIB and the receiving node is not the bundle's 1690 PIB-dest the receiving node MAY attempt to verify the value in the 1691 security result field. If it is able to check and the check fails, 1692 the node SHALL discard the bundle and it MAY send a bundle status 1693 report indicating the failure. 1695 If the bundle has an ESB and the receiving node is the ESB 1696 destination for the bundle (either because the node is listed as the 1697 bundle's ESB-dest or because the node is listed as the bundle's 1698 destination and there is no ESB-dest), the node MUST decrypt and/or 1699 decapsulate the encapsulated block in accordance with the ciphersuite 1700 specification. The decapsulated block replaces the ESB in the bundle 1701 block sequence, and the ESB is thereby deleted. If the content 1702 cannot be decrypted (i.e., the decryption key cannot be deduced or 1703 decryption fails), then the bundle MAY be discarded and processed no 1704 further unless the security policy specifies otherwise. In this case 1705 a bundle deletion status report (see the Bundle Protocol [DTNBP]) 1706 indicating the decryption failure MAY be generated. 1708 3.7. The At-Most-Once-Delivery Option 1710 An application MAY request (in an implementation specific manner) 1711 that a node be registered as a member of an endpoint and that 1712 received bundles destined for that endpoint be delivered to that 1713 application. 1715 An option for use in such cases is known as "at-most-once-delivery". 1716 If this option is chosen, the application indicates that it wants the 1717 node to check for duplicate bundles, discard duplicates, and deliver 1718 at most one copy of each received bundle to the application. If this 1719 option is not chosen, the application indicates that it wants the 1720 node to deliver all received bundle copies to the application. If 1721 this option is chosen, the node SHALL deliver at most one copy of 1722 each received bundle to the application. If the option is not 1723 chosen, the node SHOULD, subject to policy, deliver all bundles. 1725 To enforce this the node MUST look at the source/timestamp pair value 1726 of each complete (reassembled, if necessary) bundle received and 1727 determine if this pair, which uniquely identifies a bundle, has been 1728 previously received. If it has, then the bundle is a duplicate. If 1729 it has not, then the bundle is not a duplicate. The source/timestamp 1730 pair SHALL be added to the list of pair values already received by 1731 that node. 1733 Each node implementation MAY decide how long to maintain a table of 1734 pair value state. 1736 Additional discussion relevant to at-most-once-delivery is in the DTN 1737 Retransmission Block specification [DTNRB]. 1739 3.8. Bundle Fragmentation and Reassembly 1741 If it is necessary for a node to fragment a bundle and security 1742 services have been applied to that bundle, the fragmentation rules 1743 described in [DTNBP] MUST be followed. As defined there and repeated 1744 here for completeness, only the payload MAY be fragmented; security 1745 blocks, like all extension blocks, can never be fragmented. In 1746 addition, the following security-specific processing is REQUIRED: 1748 The security policy requirements for a bundle MUST be applied 1749 individually to all the bundles resulting from a fragmentation event. 1751 If the original bundle contained a PIB, then each of the PIB 1752 instances MUST be included in some fragment. 1754 If the original bundle contained one or more PCBs, then any PCB 1755 instances containing a key information item MUST have the "replicate 1756 in every fragment" flag set, and thereby be replicated in every 1757 fragment. This is to ensure that the canonical block-sequence can be 1758 recovered during reassembly. 1760 If the original bundle contained one or more correlated PCBs not 1761 containing a key information item, then each of these MUST be 1762 included in some fragment, but SHOULD NOT be sent more than once. 1763 They MUST be placed in a fragment in accordance with the 1764 fragmentation rules described in [DTNBP]. 1766 Note: various fragments MAY have additional security blocks added at 1767 this or later stages and it is possible that correlators will 1768 collide. In order to facilitate uniqueness, ciphersuites SHOULD 1769 include the fragment-offset of the fragment as a high-order component 1770 of the correlator. 1772 3.9. Reactive fragmentation 1774 When a partial bundle has been received, the receiving node SHALL 1775 consult its security policy to determine if it MAY fragment the 1776 bundle, converting the received portion into a bundle fragment for 1777 further forwarding. Whether or not reactive fragmentation is 1778 permitted SHALL depend on the security policy and the ciphersuite 1779 used to calculate the BAB authentication information, if required. 1780 (Some BAB ciphersuites, i.e., the mandatory BAB-HMAC ciphersuite 1781 defined in Section 4.1, do not accommodate reactive fragmentation 1782 because the security result in the BAB requires that the entire 1783 bundle be signed. It is conceivable, however, that a BAB ciphersuite 1784 could be defined such that multiple security results are calculated, 1785 each on a different segment of a bundle, and that these security 1786 results could be interspersed between bundle payload segments such 1787 that reactive fragmentation could be accommodated.) 1789 If the bundle is reactively fragmented by the intermediate receiver 1790 and the BAB-ciphersuite is of an appropriate type (e.g. with multiple 1791 security results embedded in the payload), the bundle MUST be 1792 fragmented immediately after the last security result value in the 1793 partial payload that is received. Any data received after the last 1794 security result value MUST be dropped. 1796 If a partial bundle is received at the intermediate receiver and is 1797 reactively fragmented and forwarded, only the part of the bundle that 1798 was not received MUST be retransmitted, though more of the bundle MAY 1799 be retransmitted. Before retransmitting a portion of the bundle, it 1800 SHALL be changed into a fragment and, if the original bundle included 1801 a BAB, the fragmented bundle MUST also, and its BAB SHALL be 1802 recalculated. 1804 This specification does not currently define any ciphersuite which 1805 can handle this reactive fragmentation case. 1807 An interesting possibility is a ciphersuite definition such that the 1808 transmission of a follow-up fragment would be accompanied by the 1809 signature for the payload up to the restart point. 1811 4. Mandatory Ciphersuites 1813 This section defines the mandatory ciphersuites for this 1814 specification. There is currently one mandatory ciphersuite for use 1815 with each of the security block types BAB, PIB, PCB and ESB. The BAB 1816 ciphersuite is based on shared secrets using HMAC. The PIB 1817 ciphersuite is based on digital signatures using RSA with SHA256. 1818 The PCB and ESB ciphersuites are based on using RSA for key transport 1819 and AES for bulk encryption. 1821 The key transport mechanisms defined in Cryptographic Message Syntax 1822 [RFC5652] are suitable for the ciphersuites, with only minor 1823 adjustment as required by the ciphersuite characteristics. 1825 4.1. BAB-HMAC 1827 The BAB-HMAC ciphersuite has ciphersuite ID value 0x001. 1829 BAB-HMAC uses the strict canonicalisation algorithm in Section 3.4.1. 1831 Strict canonicalization supports digesting of a fragment-bundle. It 1832 does not permit the digesting of only a subset of the payload, but 1833 only the complete contents of the payload of the current bundle, 1834 which might be a fragment. The "fragment range" item for security- 1835 parameters is not used to indicate a fragment, as this information is 1836 digested within the primary block. 1838 The variant of HMAC to be used is HMAC-SHA1 as defined in [RFC2104]. 1840 This ciphersuite requires the use of two related instances of the 1841 BAB. It involves placing the first BAB instance (as defined in 1842 Section 2.2) just after the primary block. The second (correlated) 1843 instance of the BAB MUST be placed after all other blocks (except 1844 possibly other BAB blocks) in the bundle. 1846 This means that normally, the BAB will be the second and last blocks 1847 of the bundle. If a forwarder wishes to apply more than one 1848 correlated BAB pair, then this can be done. There is no requirement 1849 that each application "wrap" the others, but the forwarder MUST 1850 insert all the "up front" BABs, and their "at back" "partners" 1851 (without any security result), before canonicalising. 1853 Inserting more than one correlated BAB pair would be useful if the 1854 bundle could be routed to more than one potential "next-hop" or if 1855 both an old or a new key were valid at sending time, with no 1856 certainty about the situation that will obtain at reception time. 1858 The security result is the output of the HMAC-SHA1 calculation with 1859 input being the result of running the entire bundle through the 1860 strict canonicalisation algorithm. Both required BAB instances MUST 1861 be included in the bundle before canonicalisation. 1863 Security parameters are optional with this scheme, but if used then 1864 the only field that can be present is key information (see 1865 Section 2.6). 1867 Implementations MUST support use of "AuthenticatedData" type as 1868 defined in [RFC5652] section 9.1, with RecipientInfo type 1869 KeyTransRecipientInfo containing the issuer and serial number of a 1870 suitable certificate. They MAY support additional RecipientInfo 1871 types. They MAY additionally use the "SignedData" type described in 1872 [RFC5652] section 5.1. In either case, the optional "eContent" field 1873 in EncapsulatedContentInfo MUST be omitted. That is, the data itself 1874 is external, being the canonicalized form of the bundle. 1876 Because this ciphersuite requires that the security result be in the 1877 second, correlated BAB, the content of the 1878 "MessageAuthenticationCode" field in AuthenticatedData is ignored, 1879 although the field has to be present. 1881 In the absence of key information the receiver is expected to be able 1882 to find the correct key based on the sending identity. The sending 1883 identity MAY be known from the security-source field or the content 1884 of a previous-hop block in the bundle. It MAY also be determined 1885 using implementation-specific means such as the convergence layer. 1887 4.2. PIB-RSA-SHA256 1889 The PIB-RSA-SHA256 ciphersuite has ciphersuite ID value 0x02. 1891 If the bundle being signed has been fragmented before signing, then 1892 we have to specify which bytes were signed in case the signed bundle 1893 is subsequently fragmented for a second time. If the bundle is a 1894 fragment, then the ciphersuite parameters MUST include a fragment- 1895 range field, as described in Section 2.6, specifying the offset and 1896 length of the signed fragment. If the entire bundle is signed then 1897 these numbers MUST be omitted. 1899 Implementations MUST support use of "SignedData" type as defined in 1900 [RFC5652] section 5.1, with SignerInfo type SignerIdentifier 1901 containing the issuer and serial number of a suitable certificate. 1902 The optional "eContent" field in EncapsulatedContentInfo MUST be 1903 omitted. That is, the data itself is external, being the 1904 canonicalized form of the bundle. 1906 Because the signature field in SignedData SignatureValue is a 1907 security-result field, the entire key information item MUST be placed 1908 in the block's security-result field, rather than security- 1909 parameters. 1911 PIB-RSA-SHA256 uses the mutable canonicalisation algorithm 1912 Section 3.4.2, with the security-result data field for only the 1913 "current" block being excluded from the canonical form. The 1914 resulting canonical form of the bundle is the input to the signing 1915 process. This ciphersuite requires the use of a single instance of 1916 the PIB. 1918 RSA is used with SHA256 as specified for the id-sha256 PKCSv2.1 1919 signature scheme in [RFC4055]. The output of the signing process is 1920 the SignatureValue field for the PIB. 1922 "Commensurate strength" cryptography is generally held to be a good 1923 idea. A combination of RSA with SHA256 is reckoned to require a 3076 1924 bit RSA key according to this logic. Few implementations will choose 1925 this length by default (and probably some just won't support such 1926 long keys). Since this is an experimental protocol, we expect that 1927 1024 or 2048 bit RSA keys will be used in many cases, and that that 1928 will be fine since we also expect that the hash function "issues" 1929 will be resolved before any standard would be derived from this 1930 protocol. 1932 4.3. PCB-RSA-AES128-PAYLOAD-PIB-PCB 1934 The PCB-RSA-AES128-PAYLOAD-PIB-PCB ciphersuite has ciphersuite ID 1935 value 0x003. 1937 This scheme encrypts PIBs, PCBs and the payload. The key size for 1938 this ciphersuite is 128 bits. 1940 Encryption is done using the AES algorithm in Galois/Counter Mode 1941 (GCM) as described in [RFC5084] [Note: parts of the following 1942 description are borrowed from RFC 4106]. 1944 The choice of GCM avoids expansion of the payload, which causes 1945 problems with fragmentation/reassembly and custody transfer. GCM 1946 also includes authentication, essential in preventing attacks that 1947 can alter the decrypted plaintext or even recover the encryption key. 1949 GCM is a block cipher mode of operation providing both 1950 confidentiality and data origin authentication. The GCM 1951 authenticated encryption operation has four inputs: a secret key, an 1952 initialization vector (IV), a plaintext, and an input for additional 1953 authenticated data (AAD) which is not used here. It has two outputs, 1954 a ciphertext whose length is identical to the plaintext, and an 1955 authentication tag, also known as the Integrity Check Value (ICV). 1957 For consistency with the description in [RFC5084], we refer to the 1958 GCM IV as a nonce. The same key and nonce combination MUST NOT be 1959 used more than once. The nonce has the following layout 1961 +----------------+----------------+----------------+----------------+ 1962 | salt | 1963 +----------------+----------------+----------------+----------------+ 1964 | | 1965 | initialization vector | 1966 | | 1967 +----------------+----------------+----------------+----------------+ 1969 Nonce format. 1971 Figure 6 1973 The salt field is a four-octet value, usually chosen at random. It 1974 MUST be the same for all PCBs which have the same correlator value. 1975 The salt need not be kept secret. 1977 The initialization vector (IV) is an eight-octet value, usually 1978 chosen at random. It MUST be different for all PCBs which have the 1979 same correlator value. The value need not be kept secret. 1981 The key (bundle encryption key, BEK) is a sixteen-octet (128 bits) 1982 value, usually chosen at random. The value MUST be kept secret, as 1983 described below. 1985 The integrity check value is a sixteen-octet value used to verify 1986 that the protected data has not been altered. The value need not be 1987 kept secret. 1989 This ciphersuite requires the use of a single PCB instance to deal 1990 with payload confidentiality. If the bundle already contains PIBs or 1991 PCBs then the ciphersuite will create additional correlated blocks to 1992 protect these PIBs and PCBs. These "additional" blocks replace the 1993 original blocks on a one-for-one basis, so the number of blocks 1994 remains unchanged. All these related blocks MUST have the same 1995 correlator value. The term "first PCB" in this section refers to the 1996 single PCB if there is only one or, if there are several, then to the 1997 one containing the key information. This MUST be the first of the 1998 set. 2000 First PCB - the first PCB MAY contain a correlator value, and MAY 2001 specify security-source and/or security-destination in the eid-list. 2003 If not specified, the bundle-source and bundle-destination 2004 respectively are used for these values, as with other ciphersuites. 2005 The block MUST contain security-parameters and security-result 2006 fields. Each field MAY contain several items formatted as described 2007 in Section 2.6. 2009 Security-parameters 2011 key information 2013 salt 2015 IV (this instance applies only to payload) 2017 fragment offset and length, if bundle is a fragment 2019 Security-result 2021 ICV 2023 Subsequent PCBs MUST contain a correlator value to link them to the 2024 first PCB. Security-source and security-destination are implied from 2025 the first PCB, however see the discussion in Section 2.4 concerning 2026 eid-list entries. They MUST contain security-parameters and 2027 security-result fields as follows: 2029 Security-parameters 2031 IV for this specific block 2033 Security-result 2035 encapsulated block 2037 The security-parameters and security-result fields in the subsequent 2038 PCBs MUST NOT contain any items other than these two. Items such as 2039 key and salt are supplied in the first PCB and MUST NOT be repeated. 2041 Implementations MUST support use of "Enveloped-data" type as defined 2042 in [RFC5652] section 6, with RecipientInfo type KeyTransRecipientInfo 2043 containing the issuer and serial number of a suitable certificate. 2044 They MAY support additional RecipientInfo types. The optional 2045 "eContent" field in EncryptedContentInfo MUST be omitted. That is, 2046 the data itself is external, being the payload of the bundle. 2048 The Integrity Check Value from the AES-GCM encryption of the payload 2049 is placed in the security-result field of the first PCB. 2051 If the bundle being encrypted is a fragment-bundle we have to specify 2052 which bytes are encrypted in case the bundle is subsequently 2053 fragmented again. If the bundle is a fragment the ciphersuite 2054 parameters MUST include a fragment-range field, as described in 2055 Section 2.6, specifying the offset and length of the encrypted 2056 fragment. Note that this is not the same pair of fields which appear 2057 in the primary block as "offset and length". The "length" in this 2058 case is the length of the fragment, not the original length. If the 2059 bundle is not a fragment then this field MUST be omitted. 2061 The confidentiality processing for payload and other blocks is 2062 different, mainly because the payload might be fragmented later at 2063 some other node. 2065 For the payload, only the bytes of the bundle payload field are 2066 affected, being replaced by ciphertext. The salt, IV and key values 2067 specified in the first PCB are used to encrypt the payload, and the 2068 resultant authentication tag (ICV) is placed in an ICV item in the 2069 security-result field of that first PCB. The other bytes of the 2070 payload block, such as type, flags and length, are not modified. 2072 For each PIB or PCB to be protected, the entire original block is 2073 encapsulated in a "replacing" PCB. This replacing PCB is placed in 2074 the outgoing bundle in the same position as the original block, PIB 2075 or PCB. As mentioned above, this is one-for-one replacement and 2076 there is no consolidation of blocks or mixing of data in any way. 2078 The encryption process uses AES-GCM with the salt and key values from 2079 the first PCB, and an IV unique to this PCB. The process creates 2080 ciphertext for the entire original block, and an authentication tag 2081 for validation at the security destination. For this encapsulation 2082 process, unlike the processing of the bundle payload, the 2083 authentication tag is appended to the ciphertext for the block and 2084 the combination is stored into the "encapsulated block" item in 2085 security-result. 2087 The replacing block, of course, also has the same correlator value as 2088 the first PCB with which it is associated. It also contains the 2089 block-specific IV in security-parameters, and the combination of 2090 original-block-ciphertext and authentication tag, stored as an 2091 "encapsulated block" item in security-result. 2093 If the payload was fragmented after encryption then all those 2094 fragments MUST be present and reassembled before decryption. This 2095 process might be repeated several times at different destinations if 2096 multiple fragmentation actions have occurred. 2098 The size of the GCM counter field limits the payload size to 2^39 - 2099 256 bytes, about half a terabyte. A future revision of this 2100 specification will address the issue of handling payloads in excess 2101 of this size. 2103 4.4. ESB-RSA-AES128-EXT 2105 The ESB-RSA-AES128-EXT ciphersuite has ciphersuite ID value 0x004. 2107 This scheme encrypts non-payload-related blocks. It MUST NOT be used 2108 to encrypt PIBs, PCBs or primary or payload blocks. The key size for 2109 this ciphersuite is 128 bits. 2111 Encryption is done using the AES algorithm in Galois/Counter Mode 2112 (GCM) as described in [RFC5084] [Note: parts of the following 2113 description are borrowed from RFC 4106]. 2115 GCM is a block cipher mode of operation providing both 2116 confidentiality and data origin authentication. The GCM 2117 authenticated encryption operation has four inputs: a secret key, an 2118 initialization vector (IV), a plaintext, and an input for additional 2119 authenticated data (AAD) which is not used here. It has two outputs, 2120 a ciphertext whose length is identical to the plaintext, and an 2121 authentication tag, also known as the Integrity Check Value (ICV). 2123 For consistency with the description in [RFC5084], we refer to the 2124 GCM IV as a nonce. The same key and nonce combination MUST NOT be 2125 used more than once. The nonce has the following layout 2127 +----------------+----------------+---------------------------------+ 2128 | salt | 2129 +----------------+----------------+---------------------------------+ 2130 | | 2131 | initialization vector | 2132 | | 2133 +----------------+----------------+---------------------------------+ 2135 Nonce format. 2137 Figure 7 2139 The salt field is a four-octet value, usually chosen at random. It 2140 MUST be the same for all ESBs which have the same correlator value. 2141 The salt need not be kept secret. 2143 The initialization vector (IV) is an eight-octet value, usually 2144 chosen at random. It MUST be different for all ESBs which have the 2145 same correlator value. The value need not be kept secret. 2147 The data encryption key is a sixteen-octet (128 bits) value, usually 2148 chosen at random. The value MUST be kept secret, as described below. 2150 The integrity check value is a sixteen-octet value used to verify 2151 that the protected data has not been altered. The value need not be 2152 kept secret. 2154 This ciphersuite replaces each BP extension block to be protected 2155 with a "replacing" ESB, and each can be individually specified. 2157 If a number of related BP extension blocks are to be protected they 2158 can be grouped as a correlated set and protected using a single key. 2159 These blocks replace the original blocks on a one-for-one basis, so 2160 the number of blocks remains unchanged. All these related blocks 2161 MUST have the same correlator value. The term "first ESB" in this 2162 section refers to the single ESB if there is only one or, if there 2163 are several, then to the one containing the key or key-identifier. 2164 This MUST be the first of the set. If the blocks are individually 2165 specified then there is no correlated set and each block is its own 2166 "first ESB". 2168 First ESB - the first ESB MAY contain a correlator value, and MAY 2169 specify security-source and/or security-destination in the eid-list. 2170 If not specified, the bundle-source and bundle-destination 2171 respectively are used for these values, as with other ciphersuites. 2172 The block MUST contain security-parameters and security-result 2173 fields. Each field MAY contain several items formatted as described 2174 in Section 2.6. 2176 Security-parameters 2178 key information 2180 salt 2182 IV for this specific block 2184 Security-result 2186 encapsulated block 2188 Subsequent ESBs MUST contain a correlator value to link them to the 2189 first ESB. Security-source and security-destination are implied from 2190 the first ESB, however see the discussion in Section 2.4 concerning 2191 eid-list entries. They MUST contain security-parameters and 2192 security-result fields as follows: 2194 Security-parameters 2195 IV for this specific block 2197 Security-result 2199 encapsulated block 2201 The security-parameters and security-result fields in the subsequent 2202 ESBs MUST NOT contain any items other than these two. Items such as 2203 key and salt are supplied in the first ESB and MUST NOT be repeated. 2205 Implementations MUST support use of "Enveloped-data" type as defined 2206 in [RFC5652] section 6, with RecipientInfo type KeyTransRecipientInfo 2207 containing the issuer and serial number of a suitable certificate. 2208 They MAY support additional RecipientInfo types. The optional 2209 "eContent" field in EncryptedContentInfo MUST be omitted. That is, 2210 the data itself is external, being the content of the block being 2211 protected. 2213 For each block to be protected, the entire original block is 2214 encapsulated in a "replacing" ESB. This replacing ESB is placed in 2215 the outgoing bundle in the same position as the original block. As 2216 mentioned above, this is one-for-one replacement and there is no 2217 consolidation of blocks or mixing of data in any way. 2219 The encryption process uses AES-GCM with the salt and key values from 2220 the first ESB, and an IV unique to this ESB. The process creates 2221 ciphertext for the entire original block, and an authentication tag 2222 for validation at the security destination. The authentication tag 2223 is appended to the ciphertext for the block and the combination is 2224 stored into the "encapsulated block" item in security-result. 2226 The replacing block, of course, also has the same correlator value as 2227 the first ESB with which it is associated. It also contains the 2228 block-specific IV in security-parameters, and the combination of 2229 original-block-ciphertext and authentication tag, stored as an 2230 "encapsulated block" item in security-result. 2232 5. Key Management 2234 Key management in delay tolerant networks is recognized as a 2235 difficult topic and is one that this specification does not attempt 2236 to solve. However, solely in order to support implementation and 2237 testing,implementations SHOULD support: 2239 - The use of well-known RSA public keys for all ciphersuites. 2241 - Long-term pre-shared-symmetric keys for the BAB-HMAC 2242 ciphersuite. 2244 Since endpoint IDs are URIs and URIs can be placed in X.509 [RFC3280] 2245 public key certificates (in the subjectAltName extension) 2246 implementations SHOULD support this way of distributing public keys. 2247 Implementations SHOULD NOT be very strict in how they process X.509 2248 though, for example, it would probably not be correct to insist on 2249 Certificate Revocation List (CRL) checking in many DTN contexts. 2251 6. Default Security Policy 2253 Every node serves as a Policy Enforcement Point insofar as it 2254 enforces some policy that controls the forwarding and delivery of 2255 bundles via one or more convergence layer protocol implementation. 2256 Consequently, every node SHALL have and operate according to its own 2257 configurable security policy, whether the policy be explicit or 2258 default. The policy SHALL specify: 2260 Under what conditions received bundles SHALL be forwarded. 2262 Under what conditions received bundles SHALL be required to 2263 include valid BABs. 2265 Under what conditions the authentication information provided in a 2266 bundle's BAB SHALL be deemed adequate to authenticate the bundle. 2268 Under what conditions received bundles SHALL be required to have 2269 valid PIBs and/or PCBs. 2271 Under what conditions the authentication information provided in a 2272 bundle's PIB SHALL be deemed adequate to authenticate the bundle. 2274 Under what conditions a BAB SHALL be added to a received bundle 2275 before that bundle is forwarded. 2277 Under what conditions a PIB SHALL be added to a received bundle 2278 before that bundle is forwarded. 2280 Under what conditions a PCB SHALL be added to a received bundle 2281 before that bundle is forwarded. 2283 Under what conditions an ESB SHALL be applied to one or more 2284 blocks in a received bundle before that bundle is forwarded. 2286 The actions that SHALL be taken in the event that a received 2287 bundle does not meet the receiving node's security policy 2288 criteria. 2290 This specification does not address how security policies get 2291 distributed to nodes. It only REQUIRES that nodes have and enforce 2292 security policies. 2294 If no security policy is specified at a given node, or if a security 2295 policy is only partially specified, that node's default policy 2296 regarding unspecified criteria SHALL consist of the following: 2298 Bundles that are not well-formed do not meet the security policy 2299 criteria. 2301 The mandatory ciphersuites MUST be used. 2303 All bundles received MUST have a BAB which MUST be verified to 2304 contain a valid security result. If the bundle does not have a 2305 BAB, then the bundle MUST be discarded and processed no further; a 2306 bundle status report indicating the authentication failure MAY be 2307 generated. 2309 No received bundles SHALL be required to have a PIB; if a received 2310 bundle does have a PIB, however, the PIB can be ignored unless the 2311 receiving node is the PIB-dest, in which case the PIB MUST be 2312 verified. 2314 No received bundles SHALL be required to have a PCB; if a received 2315 bundle does have a PCB, however, the PCB can be ignored unless the 2316 receiving node is the PCB-dest, in which case the PCB MUST be 2317 processed. If processing of a PCB yields a PIB, that PIB SHALL be 2318 processed by the node according to the node's security policy. 2320 A PIB SHALL NOT be added to a bundle before sourcing or forwarding 2321 it. 2323 A PCB SHALL NOT be added to a bundle before sourcing or forwarding 2324 it. 2326 A BAB MUST always be added to a bundle before that bundle is 2327 forwarded. 2329 If a destination node receives a bundle that has a PIB-dest but 2330 the value in that PIB-dest is not the EID of the destination node, 2331 the bundle SHALL be delivered at that destination node. 2333 If a destination node receives a bundle that has an ESB-dest but 2334 the value in that ESB-dest is not the EID of the destination node, 2335 the bundle SHALL be delivered at that destination node. 2337 If a received bundle does not satisfy the node's security policy 2338 for any reason, then the bundle MUST be discarded and processed no 2339 further; in this case, a bundle deletion status report (see the 2340 Bundle Protocol [DTNBP]) indicating the failure MAY be generated. 2342 7. Security Considerations 2344 If a BAB ciphersuite uses digital signatures but doesn't include the 2345 security destination (which for a BAB is the next host), then this 2346 allows the bundle to be sent to some node other than the intended 2347 adjacent node. Because the BAB will still authenticate, the 2348 receiving node might erroneously accept and forward the bundle. When 2349 asymmetric BAB ciphersuites are used, the security destination field 2350 SHOULD therefore be included in the BAB. 2352 If a bundle's PIB-dest is not the same as its destination, then some 2353 node other than the destination (the node identified as the PIB-dest) 2354 is expected to validate the PIB security result while the bundle is 2355 en route. However, if for some reason the PIB is not validated, 2356 there is no way for the destination to become aware of this. 2357 Typically, a PIB-dest will remove the PIB from the bundle after 2358 verifying the PIB and before forwarding it. However, if there is a 2359 possibility that the PIB will also be verified at a downstream node, 2360 the PIB-dest will leave the PIB in the bundle. Therefore, if a 2361 destination receives a bundle with a PIB that has a PIB-dest (which 2362 isn't the destination), this might, but does not necessarily, 2363 indicate a possible problem. 2365 If a bundle is fragmented after being forwarded by its PIB-source but 2366 before being received by its PIB-dest, the payload in the bundle MUST 2367 be reassembled before validating the PIB security result in order for 2368 the security result to validate correctly. Therefore, if the PIB- 2369 dest is not capable of performing payload reassembly, its utility as 2370 a PIB-dest will be limited to validating only those bundles that have 2371 not been fragmented since being forwarded from the PIB-source. 2372 Similarly, if a bundle is fragmented after being forwarded by its 2373 PIB-source but before being received by its PIB-dest, all fragments 2374 MUST be received at that PIB-dest in order for the bundle payload to 2375 be able to be reassembled. If not all fragments are received at the 2376 PIB-dest node, the bundle will not be able to be authenticated, and 2377 will therefore never be forwarded by this PIB-dest node. 2379 Specification of a security-destination other than the bundle 2380 destination creates a routing requirement that the bundle somehow be 2381 directed to the security-destination node on its way to the final 2382 destination. This requirement is presently private to the 2383 ciphersuite, since routing nodes are not required to implement 2384 security processing. 2386 8. Conformance 2388 As indicated above, this document describes both BSP and 2389 ciphersuites. A conformant implementation MUST implement both BSP 2390 support and the four ciphersuites described in Section 4. It MAY 2391 also support other ciphersuites. 2393 Implementations that support BSP but not all four mandatory 2394 ciphersuites MUST claim only "restricted compliance" with this 2395 specification, even if they provide other ciphersuites. 2397 All implementations are strongly RECOMMENDED to provide at least a 2398 BAB ciphersuite. A relay node, for example, might not deal with end- 2399 to-end confidentiality and data integrity but it SHOULD exclude 2400 unauthorized traffic and perform hop-by-hop bundle verification. 2402 9. IANA Considerations 2404 None at this time. If the bundle protocol becomes a standards track 2405 protocol, then we may want to consider having IANA establish a 2406 register of block types, and in particular for this specification a 2407 separate register of ciphersuite specifications. 2409 10. References 2411 10.1. Normative References 2413 [DTNBP] Scott, K. and S. Burleigh, "Bundle Protocol 2414 Specification", RFC 5050, November 2007. 2416 [DTNMD] Symington, S., "Delay-Tolerant Networking Metadata 2417 Extension Block", 2418 draft-irtf-dtnrg-bundle-metadata-block-00.txt , June 2007. 2420 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2421 Hashing for Message Authentication", RFC 2104, 2422 February 1997. 2424 [RFC2119] Bradner, S. and J. Reynolds, "Key words for use in RFCs to 2425 Indicate Requirement Levels", RFC 2119, October 1997. 2427 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 2428 X.509 Public Key Infrastructure Certificate and 2429 Certificate Revocation List (CRL) Profile", RFC 3280, 2430 April 2002. 2432 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 2433 Algorithms", RFC 3370, August 2002. 2435 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 2436 Algorithms and Identifiers for RSA Cryptography for use in 2437 the Internet X.509 Public Key Infrastructure Certificate 2438 and Certificate Revocation List (CRL) Profile", RFC 4055, 2439 June 2005. 2441 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 2442 (GCM) in IPsec Encapsulating Security Payload (ESP)", 2443 RFC 4106, June 2005. 2445 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 2446 RFC 3852, July 2004. 2448 10.2. Informative References 2450 [DTNRB] Symington, S., "Delay-Tolerant Network Retransmission 2451 Block", 2452 draft-irtf-dtnrg-bundle-retrans-00.txt, work-in-progress, 2453 April 2007. 2455 [DTNarch] Cerf, V., Burleigh, S., Durst, R., Fall, K., Hooke, A., 2456 Scott, K., Torgerson, L., and H. Weiss, "Delay-Tolerant 2457 Network Architecture", RFC 4838, April 2007. 2459 [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated 2460 Encryption in the Cryptographic Message Syntax (CMS)", 2461 RFC 5084, November 2007. 2463 Authors' Addresses 2465 Susan Flynn Symington 2466 The MITRE Corporation 2467 7515 Colshire Drive 2468 McLean, VA 22102 2469 US 2471 Phone: +1 (703) 983-7209 2472 Email: susan@mitre.org 2473 URI: http://mitre.org/ 2475 Stephen Farrell 2476 Trinity College Dublin 2477 Distributed Systems Group 2478 Department of Computer Science 2479 Trinity College 2480 Dublin 2 2481 Ireland 2483 Phone: +353-1-608-1539 2484 Email: stephen.farrell@cs.tcd.ie 2486 Howard Weiss 2487 SPARTA, Inc. 2488 7110 Samuel Morse Drive 2489 Columbia, MD 21046 2490 US 2492 Phone: +1-443-430-8089 2493 Email: hsw@sparta.com 2495 Peter Lovell 2496 SPARTA, Inc. 2497 7110 Samuel Morse Drive 2498 Columbia, MD 21046 2499 US 2501 Phone: +1-443-430-8052 2502 Email: peter.lovell@sparta.com