idnits 2.17.1 draft-irtf-dtnrg-bundle-security-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 -- 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 (October 22, 2009) is 5301 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 2393, but no explicit reference was found in the text == Unused Reference: 'RFC4106' is defined on line 2402, 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 (~~), 5 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: April 25, 2010 S. Farrell 5 Trinity College Dublin 6 H. Weiss 7 P. Lovell 8 SPARTA, Inc. 9 October 22, 2009 11 Bundle Security Protocol Specification 12 draft-irtf-dtnrg-bundle-security-09 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on April 25, 2010. 47 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 in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This document defines the bundle security protocol, which provides 60 data integrity and confidentiality services. We also describe 61 various bundle security considerations including policy options. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1. Related Documents . . . . . . . . . . . . . . . . . . . . 4 67 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 68 2. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 8 69 2.1. Abstract Security Block . . . . . . . . . . . . . . . . . 9 70 2.2. Bundle Authentication Block . . . . . . . . . . . . . . . 13 71 2.3. Payload Integrity Block . . . . . . . . . . . . . . . . . 14 72 2.4. Payload Confidentiality Block . . . . . . . . . . . . . . 16 73 2.5. Extension Security Block . . . . . . . . . . . . . . . . . 20 74 2.6. Parameters and Result Fields . . . . . . . . . . . . . . . 21 75 2.7. Key Transport . . . . . . . . . . . . . . . . . . . . . . 23 76 2.8. PIB and PCB combinations . . . . . . . . . . . . . . . . . 23 77 3. Security Processing . . . . . . . . . . . . . . . . . . . . . 26 78 3.1. Nodes as policy enforcement points . . . . . . . . . . . . 26 79 3.2. Processing order of security blocks . . . . . . . . . . . 26 80 3.3. Security Zones . . . . . . . . . . . . . . . . . . . . . . 29 81 3.4. Canonicalisation of bundles . . . . . . . . . . . . . . . 31 82 3.5. Endpoint ID confidentiality . . . . . . . . . . . . . . . 36 83 3.6. Bundles received from other nodes . . . . . . . . . . . . 36 84 3.7. The At-Most-Once-Delivery Option . . . . . . . . . . . . . 38 85 3.8. Bundle Fragmentation and Reassembly . . . . . . . . . . . 39 86 3.9. Reactive fragmentation . . . . . . . . . . . . . . . . . . 40 87 4. Mandatory Ciphersuites . . . . . . . . . . . . . . . . . . . . 41 88 4.1. BAB-HMAC . . . . . . . . . . . . . . . . . . . . . . . . . 41 89 4.2. PIB-RSA-SHA256 . . . . . . . . . . . . . . . . . . . . . . 42 90 4.3. PCB-RSA-AES128-PAYLOAD-PIB-PCB . . . . . . . . . . . . . . 43 91 4.4. ESB-RSA-AES128-EXT . . . . . . . . . . . . . . . . . . . . 47 92 5. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 50 93 6. Default Security Policy . . . . . . . . . . . . . . . . . . . 51 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 53 95 8. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 54 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 98 10.1. Normative References . . . . . . . . . . . . . . . . . . . 56 99 10.2. Informative References . . . . . . . . . . . . . . . . . . 56 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 102 1. Introduction 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 This document defines security features for the bundle protocol 109 [DTNBP] intended for use in delay tolerant networks, in order to 110 provide DTN security services. 112 The bundle protocol is used in DTNs which overlay multiple networks, 113 some of which may be challenged by limitations such as intermittent 114 and possibly unpredictable loss of connectivity, long or variable 115 delay, asymmetric data rates, and high error rates. The purpose of 116 the bundle protocol is to support interoperability across such 117 stressed networks. The bundle protocol is layered on top of 118 underlay-network-specific convergence layers, on top of network- 119 specific lower layers, to enable an application in one network to 120 communicate with an application in another network, both of which are 121 spanned by the DTN. 123 Security will be important for the bundle protocol. The stressed 124 environment of the underlying networks over which the bundle protocol 125 will operate makes it important that the DTN be protected from 126 unauthorized use, and this stressed environment poses unique 127 challenges on the mechanisms needed to secure the bundle protocol. 128 Furthermore, DTNs may very likely be deployed in environments where a 129 portion of the network might become compromised, posing the usual 130 security challenges related to confidentiality, integrity and 131 availability. 133 Separate security processing applies to the payload block and to the 134 various extension blocks that may accompany it in a bundle, as 135 varying security requirements may apply to them. 137 This document describes both the base Bundle Security Protocol (BSP) 138 and a set of mandatory ciphersuites. A ciphersuite is a specific 139 collection of various cryptographic algorithms and implementation 140 rules that are used together to provide certain security services. 142 1.1. Related Documents 144 This document is best read and understood within the context of the 145 following other DTN documents: 147 The Delay-Tolerant Network Architecture [DTNarch] defines the 148 architecture for delay-tolerant networks, but does not discuss 149 security at any length. 151 The DTN Bundle Protocol [DTNBP] defines the format and processing 152 of the blocks used to implement the bundle protocol, excluding the 153 security-specific blocks defined here. 155 The Delay-Tolerant Networking Security Overview [DTNsecOver] 156 provides an informative overview and high-level description of DTN 157 security. 159 1.2. Terminology 161 We introduce the following terminology for purposes of clarity: 163 source - the bundle node from which a bundle originates 165 destination - the bundle node to which a bundle is ultimately 166 destined 168 forwarder - the bundle node that forwarded the bundle on its most 169 recent hop 171 intermediate receiver or "next hop" - the neighboring bundle node 172 to which a forwarder forwards a bundle. 174 In the figure below, which is adapted from figure 1 in the Bundle 175 Protocol Specification, four bundle nodes (denoted BN1, BN2, BN3, and 176 BN4) reside above some transport layer(s). Three distinct transport 177 and network protocols (denoted T1/N1, T2/N2, and T3/N3) are also 178 shown. 180 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 181 | BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 | 182 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 183 | T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 | 184 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 185 | N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 | 186 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 187 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 188 +-----------+ +------------+ +-------------+ +-----------+ 189 | | | | 190 |<-- An Internet --->| |<--- An Internet --->| 191 | | | | 193 BN = "Bundle Node" (as defined in the Bundle Protocol Specification 195 Bundle Nodes Sit at the Application layer of the Internet Model. 197 Figure 1 199 Bundle node BN1 originates a bundle that it forwards to BN2. BN2 200 forwards the bundle to BN3, and BN3 forwards the bundle to BN4. BN1 201 is the source of the bundle and BN4 is the destination of the bundle. 202 BN1 is the first forwarder, and BN2 is the first intermediate 203 receiver; BN2 then becomes the forwarder, and BN3 the intermediate 204 receiver; BN3 then becomes the last forwarder, and BN4 the last 205 intermediate receiver, as well as the destination. 207 If node BN2 originates a bundle (for example, a bundle status report 208 or a custodial signal), which is then forwarded on to BN3, and then 209 to BN4, then BN2 is the source of the bundle (as well as being the 210 first forwarder of the bundle) and BN4 is the destination of the 211 bundle (as well as being the final intermediate receiver). 213 We introduce the following security-specific DTN terminology: 215 security-source - a bundle node that adds a security block to a 216 bundle 218 security-destination - a bundle node that processes a security 219 block of a bundle 221 security zone - that part of the network path from the security- 222 source to the security-destination 224 Referring to Figure 1 again: 226 If the bundle that originates at BN1 as source is given a security 227 block by BN1, then BN1 is the security-source of this bundle with 228 respect to that security block, as well as being the source of the 229 bundle. 231 If the bundle that originates at BN1 as source is given a security 232 block by BN2, then BN2 is the security-source of this bundle with 233 respect to that security block, even though BN1 is the source. 235 If the bundle that originates at BN1 as source is given a security 236 block by BN1 that is intended to be processed by BN3, then BN1 is the 237 security-source and BN3 is the security destination with respect to 238 this security block. The security zone for this block is BN1 to BN3. 240 A bundle may have multiple security blocks. The security-source of a 241 bundle with respect to a given security block in the bundle may be 242 the same as or different from the security-source of the bundle with 243 respect to a different security block in the bundle. Similarly, the 244 security-destination of a bundle with respect to each of that 245 bundle's security blocks may be the same or different. Therefore the 246 security zones for various blocks may be and often will be different. 248 If the bundle that originates at BN1 as source is given a security 249 block by BN1 that is intended to be processed by BN3, and BN2 adds a 250 security block with security-destination BN4, the security zones for 251 the two blocks overlap but not completely. This problem is discussed 252 further in Section 3.3. 254 As required in [DTNBP], forwarding nodes MUST transmit blocks in the 255 same order as they were received. This requirement applies to all 256 dtn nodes, not just ones which implement security processing. Blocks 257 in a bundle may be added or deleted according to the applicable 258 specification, but those blocks which are both received and 259 transmitted MUST be transmitted in the same order that they were 260 received. 262 The block sequence also indicates the order in which certain 263 significant actions have affected the bundle, and therefore the 264 sequence in which actions must occur in order to produce the bundle 265 at its destination. 267 2. Security Blocks 269 There are four types of security block that MAY be included in a 270 bundle. These are the Bundle Authentication Block (BAB), the Payload 271 Integrity Block (PIB), the Payload Confidentiality Block (PCB) and 272 the Extension Security Block (ESB). 274 The BAB is used to assure the authenticity and integrity of the 275 bundle along a single hop from forwarder to intermediate receiver. 277 The PIB is used to assure the authenticity and integrity of the 278 payload from the PIB security-source, which creates the PIB, to 279 the PIB security-destination, which verifies the PIB 280 authenticator. The authentication information in the PIB may (if 281 the ciphersuite allows) be verified by any node in between the PIB 282 security-source and the PIB security-destination that has access 283 to the cryptographic keys and revocation status information 284 required to do so. 286 Since a BAB protects a bundle on a "hop-by-hop" basis and other 287 security blocks may be protecting over several hops or end-to-end, 288 whenever both are present the BAB MUST form the "outer" layer of 289 protection - that is, the BAB MUST always be calculated and added 290 to the bundle after all other security bloacks have been 291 calculated and added to the bundle. 293 The PCB indicates that the payload has been encrypted, in whole or 294 in part, at the PCB security-source in order to protect the bundle 295 content while in transit to the PCB security-destination. 297 PIB and PCB protect the payload and are regarded as "payload- 298 related" for purposes of the security discussion in this document. 299 Other blocks are regarded as "non-payload" blocks. Of course, the 300 primary block is unique and has separate rules. 302 The ESB provides security for non-payload blocks in a bundle. ESB 303 therefore is not applied to PIB or PCBs, and of course is not 304 appropriate for either the payload block or primary block. 306 Each of the security blocks uses the Canonical Bundle Block Format as 307 defined in the Bundle Protocol Specification. That is, each security 308 block is comprised of the following elements: 310 - Block type code 312 - Block processing control flags 313 - Block EID reference list (optional) 315 - Block data length 317 - Block-type-specific data fields 319 Since the four security blocks have most fields in common, we can 320 shorten the description of the Block-type-specific data fields of 321 each security block if we first define an abstract security block 322 (ASB) and then specify each of the real blocks in terms of the fields 323 which are present/absent in an ASB. Note that no bundle ever 324 contains an actual ASB, which is simply a specification artifact. 326 2.1. Abstract Security Block 328 An ASB consists of the following mandatory and optional fields: 330 - Block-type code (one byte) - as in all bundle protocol blocks 331 except the primary bundle block. The block types codes for the 332 security blocks are: 334 BundleAuthentication Block - BAB: 0x02 336 PayloadIntegrity Block - PIB: 0x03 338 PayloadConfidentiality Block - PCB: 0x04 340 Extension Security Block - ESB: 0x09 342 - Block processing control flags (SDNV) - defined as in all bundle 343 protocol blocks except the primary bundle block (as described in 344 the Bundle Protocol [DTNBP]). SDNV encoding is described in the 345 bundle protocol. There are no general constraints on the use of 346 the block processing flags, and some specific requirements are 347 discussed later. 349 - EID references - composite field defined in [DTNBP] containing 350 references to one or two EIDs. Presence of the EID-reference 351 field is indicated by the setting of the "block contains an EID- 352 reference field" (EID_REF) bit of the block processing control 353 flags. If one or more references is present, flags in the 354 ciphersuite ID field, described below, specify which. 356 If no EID fields are present then the composite field itself is 357 omitted entirely, rather than containing a count field of zero, 358 since such a representation is not permitted. The EID_REF bit is 359 not set. 361 The possible EIDs are:- 363 - (optional) Security-source - specifies the security source 364 for the block. If this is omitted, then the source of the 365 bundle is assumed to be the security-source. 367 - (optional) Security-destination - specifies the security 368 destination for the block. If this is omitted, then the 369 destination of the bundle is assumed to be the security- 370 destination. 372 If two EIDs are present, security-source is first and security- 373 destination comes second. 375 - Block data length (SDNV) - as in all bundle protocol blocks 376 except the primary bundle block. SDNV encoding is described in 377 the bundle protocol. 379 - Block-type-specific data fields as follows: 381 - Ciphersuite ID (SDNV) 383 - Ciphersuite flags (SDNV) 385 - (optional) Correlator - when more than one related block is 386 inserted then this field MUST have the same value in each 387 related block instance. This is encoded as an SDNV. See note 388 in Section 3.8 with regard to correlator values in bundle 389 fragments. 391 - (optional) Ciphersuite parameters - compound field of next 392 two items 394 - Ciphersuite parameters length - specifies the length of 395 the following Ciphersuite parameters data field and is 396 encoded as an SDNV. 398 - Ciphersuite parameters data - parameters to be used with 399 the ciphersuite in use, e.g. a key identifier or 400 initialization vector (IV). See Section 2.6 for a list of 401 potential parameters and their encoding rules. The 402 particular set of parameters that are included in this field 403 are defined as part of the ciphersuite specification. 405 - (optional) Security result - compound field of next two items 407 - Security result length - contains the length of the next 408 field and is encoded as an SDNV. 410 - Security result data - contains the results of the 411 appropriate ciphersuite-specific calculation (e.g. a 412 signature, MAC or ciphertext block key). 414 +----------------+----------------+----------------+----------------+ 415 | type | flags (SDNV) | EID ref list(comp) | 416 +----------------+----------------+----------------+----------------+ 417 | length (SDNV) | ciphersuite (SDNV) | 418 +----------------+----------------+----------------+----------------+ 419 | ciphersuite flags (SDNV) | correlator (SDNV) | 420 +----------------+----------------+----------------+----------------+ 421 |params len(SDNV)| ciphersuite params data | 422 +----------------+----------------+----------------+----------------+ 423 |res-len (SDNV) | security result data | 424 +----------------+----------------+----------------+----------------+ 426 The structure of an abstract security block 428 Figure 2 430 Some ciphersuites are specified in Section 4, which also specifies 431 the rules which MUST be satisfied by ciphersuite specifications. 432 Additional ciphersuites MAY be defined in separate specifications. 433 Ciphersuite IDs not specified are reserved. Implementations of the 434 bundle security protocol decide which ciphersuites to support, 435 subject to the requirements of Section 4. It is RECOMMENDED that 436 implementations that allow additional ciphersuites permit ciphersuite 437 ID values at least up to and including 127, and they MAY decline to 438 allow larger ID values. 440 The structure of the ciphersuite flags field is shown in Figure 3. 441 In each case the presence of an optional field is indicated by 442 setting the value of the corresponding flag to one. A value of zero 443 indicates the corresponding optional field is missing. Presently 444 there are five flags defined for the field and for convenience these 445 are shown as they would be extracted from a single-byte SDNV. Future 446 additions may cause the field to grow to the left so, as with the 447 flags fields defined in [DTNBP], the description below numbers the 448 bit positions from the right rather than the standard RFC definition 449 which numbers bits from the left. 451 src - bit 4 indicates whether the EID-reference field of the ASB 452 contains the optional reference to the security-source. 454 dest - bit 3 indicates whether the EID-reference field of the ASB 455 contains the optional reference to the security-destination. 457 parm - bit 2 indicates whether the ciphersuite-parameters-length 458 and ciphersuite parameters data fields are present or not. 460 corr - bit 1 indicates whether or not the ASB contains an optional 461 correlator. 463 res - bit 0 indicates whether or not the ASB contains the security 464 result length and security result data fields. 466 bits 5-6 are reserved for future use. 468 Ciphersuite flags 469 Bit Bit Bit Bit Bit Bit Bit 470 6 5 4 3 2 1 0 471 +-----+-----+-----+-----+-----+-----+-----+ 472 | reserved |src |dest |parm |corr |res | 473 +-----+-----+-----+-----+-----+-----+-----+ 475 Figure 3 477 A little bit more terminology: if the block is a PIB then when we 478 refer to the "PIB-source", we mean the security source for the PIB as 479 represented by the EID reference in the EID-references field. 480 Similarly we may refer to the PCB-dest, meaning the security- 481 destination of the PCB, again as represented by an EID reference. 482 For example, referring to Figure 1 again, if the bundle that 483 originates at BN1 as source is given a Confidentiality Block (PCB) by 484 BN1 that is protected using a key held by BN3 and it is given a 485 Payload Integrity Block (PIB) by BN1, then BN1 is both the PCB-source 486 and the PIB-source of the bundle, and BN3 is the PCB-dest of the 487 bundle. 489 The correlator field is used to associate several related instances 490 of a security block. This can be used to place a BAB that contains 491 the ciphersuite information at the "front" of a (probably large) 492 bundle, and another correlated BAB that contains the security result 493 at the "end" of the bundle. This allows even very memory-constrained 494 nodes to be able to process the bundle and verify the BAB. There are 495 similar use cases for multiple related instances of PIB and PCB as 496 will be seen below. 498 The ciphersuite specification MUST make it clear whether or not 499 multiple block instances are allowed, and if so, under what 500 conditions. Some ciphersuites can of course leave flexibility to the 501 implementation, whereas others might mandate a fixed number of 502 instances. 504 For convenience, we use the term "first block" to refer to the 505 initial block in a group of correlated blocks, or to the single block 506 if there are no others in the set. Obviously there can be several 507 unrelated groups in a bundle, each containing only one block or more 508 than one, and each has its own "first block". 510 2.2. Bundle Authentication Block 512 In this section we describe typical BAB field values for two 513 scenarios - where a single instance of the BAB contains all the 514 information and where two related instances are used, one "up front" 515 which contains the ciphersuite and another following the payload 516 which contains the security result (e.g. a MAC). 518 For the case where a single BAB is used: 520 The block-type code field value MUST be 0x02. 522 The block processing control flags value can be set to whatever 523 values are required by local policy. Ciphersuite designers should 524 carefully consider the effect of setting flags that either discard 525 the block or delete the bundle in the event that this block cannot 526 be processed. 528 The ciphersuite ID MUST be documented as a hop-by-hop 529 authentication-ciphersuite which requires one instance of the BAB. 531 The correlator field MUST NOT be present. 533 The ciphersuite parameters field MAY be present, if so specified 534 in the ciphersuite specification. 536 An EID reference to the security-source SHOULD be present and, if 537 so, it MUST identify the forwarder of the bundle. (If the 538 forwarding node is identified in another block of the bundle that 539 the next hop supports, e.g., the Previous Hop Insertion Block, the 540 forwarding node need not be identified in the BAB. Similarly, if 541 the forwarding node is known through other implementation-specific 542 means, such as from the convergence layer, an EID reference need 543 not be included.) 545 An EID reference to the security-destination MAY be present and is 546 useful to ensure that the bundle has been forwarded to the correct 547 next-hop node. 549 The security result MUST be present as it is effectively the 550 "output" from the ciphersuite calculation (e.g. the MAC or 551 signature) applied to the (relevant parts of) the bundle (as 552 specified in the ciphersuite definition). 554 For the case using two related BAB instances, the first instance is 555 as defined above, except the ciphersuite ID MUST be documented as a 556 hop-by-hop authentication ciphersuite that requires two instances of 557 the BAB. In addition, the correlator MUST be present and the 558 security result length and security result fields MUST be absent. 559 The second instance of the BAB MUST have the same correlator value 560 present and MUST contain security result length and security result 561 data fields. The other optional fields MUST NOT be present. 562 Typically, this second instance of a BAB will be the last block of 563 the bundle. 565 The details of key transport for BAB are specified by the particular 566 ciphersuite. In the absence of conflicting requirements, the 567 following should be noted by implementors: 569 the key information item Section 2.6 is optional, and if not 570 provided then the key should be inferred from the source- 571 destination tuple, being the previous key used, a key created from 572 a key-derivation function, or a pre-shared key 574 since BAB is for a single hop, by definition, the capabilities of 575 the underlying convergence layer may be useful for key transport 577 depending upon the key mechanism used, bundles can be signed by 578 the sender, or authenticated for one or more recipients, or both. 580 2.3. Payload Integrity Block 582 A PIB is an ASB with the following additional restrictions: 584 The block type code value MUST be 0x03. 586 The block processing control flags value can be set to whatever 587 values are required by local policy. Ciphersuite designers should 588 carefully consider the effect of setting flags that either discard 589 the block or delete the bundle in the event that this block cannot 590 be processed. 592 The ciphersuite ID MUST be documented as an end-to-end 593 authentication-ciphersuite or as an end-to-end error-detection- 594 ciphersuite. 596 The correlator MUST be present if the ciphersuite requires more 597 than one related instance of a PIB be present in the bundle. The 598 correlator MUST NOT be present if the ciphersuite only requires 599 one instance of the PIB in the bundle. 601 The ciphersuite parameters field MAY be present. 603 An EID reference to the security-source MAY be present. 605 An EID reference to the security-destination MAY be present. 607 The security result is effectively the "output" from the 608 ciphersuite calculation (e.g. the MAC or signature) applied to the 609 (relevant parts of) the bundle. As in the case of the BAB, this 610 field MUST be present if the correlator is absent. If more than 611 one related instance of the PIB is required then this is handled 612 in the same way as described for the BAB above. 614 The ciphersuite may process less than the entire original bundle 615 payload, either because the current payload is a fragment of the 616 original bundle or just becuase it is defined to process some 617 subset. For whatever reason, if the ciphersuite processes less 618 than the complete, original bundle payload, the ciphersuite 619 parameters of this block MUST specify which bytes of the bundle 620 payload are protected. 622 For some ciphersuites, (e.g. those using asymmetric keying to produce 623 signatures or those using symmetric keying with a group key), the 624 security information can be checked at any hop on the way to the 625 security destination that has access to the required keying 626 information. This possibility is further discussed in Section 3.6 627 below. 629 The use of a generally-available key is RECOMMENDED if custodial 630 transfer is employed and all nodes SHOULD verify the bundle before 631 accepting custody. 633 Most asymmetric PIB-ciphersuites will use the PIB-source to indicate 634 the signer and will not require the PIB-dest field because the key 635 needed to verify the PIB authenticator will be a public key 636 associated with the PIB-source. 638 2.4. Payload Confidentiality Block 640 A typical confidentiality ciphersuite will encrypt the payload using 641 a randomly generated bundle encrypting key (BEK) and will use a ket 642 information item in PCB security parameters to carry the BEK 643 encrypted with some long term key encryption key (KEK) or well-known 644 public key. If neither the destination nor security-destination 645 resolves the key to use for decryption, the key information item in 646 the ciphersuite parameters field can be used also to indicate the 647 decryption key with which the BEK can be recovered. If the bundle 648 already contains PIBs and/or PCBs these SHOULD also be encrypted 649 using this same BEK, as described just below for "super-encryption". 651 It is STRONGLY RECOMMENDED that a data integrity mechanism be used in 652 conjunction with confidentiality, and that encryption-only 653 ciphersuites NOT be used. AES-GCM satisfies this requirement. The 654 "authentication tag" or "integrity check value" is stored into 655 security-result rather than being appended to the payload as is 656 common in some protocols since, as described below, it is important 657 that there be no change in the size of the payload. 659 The payload is encrypted "in-place", that is, following encryption, 660 the payload block payload field contains ciphertext, not plaintext. 661 The payload block processing flags are unmodified. 663 The "in-place" encryption of payload bytes is to allow bundle payload 664 fragmentation and re-assembly, and custody transfer, to operate 665 without knowledge of whether or not encryption has occurred and, if 666 so, how many times. 668 Fragmentation and reassembly and custody transfer are adversely 669 affected by a change in size of the payload due to ambiguity about 670 what byte range of the original payload is actually in any particular 671 fragment. Ciphersuites SHOULD place any payload expansion, such as 672 authentication tags (integrity check values) and any padding 673 generated by a block-mode cipher, into an "integrity check value" 674 item in the security-result field (see Section 2.6) of the 675 confidentiality block. 677 Payload super-encryption is allowed; that is, encrypting a payload 678 that has already been encrypted, perhaps more than once. 679 Ciphersuites SHOULD define super-encryption such that, as well as re- 680 ecrypting the payload, it also protects the parameters of earlier 681 encryption as failure to do do may represent a vulnerability in some 682 circumstances. 684 Confidentiality is normally applied to the payload, and possibly to 685 additional blocks. It is RECOMMENDED to apply a Payload 686 Confidentiality ciphersuite to non-payload blocks only if these 687 should be super-encrypted with the payload. If super-encryption of 688 the block is not desired then protection of the block should be done 689 using the Extension Security Block mechanism rather than PCB. 691 Multiple related PCB instances are required if both the payload and 692 PIBs and PCBs in the bundle are to be encrypted. These multiple PCB 693 instances require correlators to associate them with each other since 694 the key information is provided only in the first PCB. 696 There are situations where more than one PCB instance is required but 697 the instances are not "related" in the sense which requires 698 correlators. One example is where a payload is encrypted for more 699 than one security-destination so as to be robust in the face of 700 routing uncertainties. In this scenario the payload is encrypted 701 using a BEK. Several PCBs contain the BEK encrypted using different 702 KEKs, one for each destination. These multiple PCB instances, are 703 not "related" and should not contain correlators. 705 The ciphersuite MAY apply different rules to confidentiality for non- 706 payload blocks. 708 A PCB is an ASB with the following additional restrictions: 710 The block type code value MUST be 0x04. 712 The block processing control flags value can be set to whatever 713 values are required by local policy, except that a PCB "first 714 block" MUST have the "replicate in every fragment" flag set. This 715 flag SHOULD NOT be set otherwise. Ciphersuite designers should 716 carefully consider the effect of setting flags that either discard 717 the block or delete the bundle in the event that this block cannot 718 be processed. 720 The ciphersuite ID MUST be documented as a confidentiality- 721 ciphersuite. 723 The correlator MUST be present if there is more than one related 724 PCB instance. The correlator MUST NOT be present if there are no 725 related PCB instances. 727 If a correlator is present, the key information MUST be placed in 728 the PCB "first block". 730 Any additional bytes generated as a result of encryption and/or 731 authentication processing of the payload SHOULD be placed in an 732 "integrity check value" field (see Section 2.6) in the security- 733 result of the first PCB. 735 The ciphersuite parameters field MAY be present. 737 An EID reference to the security-source MAY be present. 739 An EID reference to the security-destination MAY be present. 741 The security result MAY be present and normally contains fields 742 such as an encrypted bundle encryption key, authentication tag or 743 the encrypted versions of bundle blocks other than the payload 744 block. 746 As was the case for the BAB and PIB, if the ciphersuite requires more 747 than one instance of the PCB, then the "first block" MUST contain any 748 optional fields (e.g. security destination etc.) that apply to all 749 instances with this correlator. These MUST be contained in the first 750 instance and MUST NOT be repeated in other correlated blocks. Fields 751 that are specific to a particular instance of the PCB MAY appear in 752 that PCB. For example, security result fields MAY (and probably 753 will) be included in multiple related PCB instances, with each result 754 being specific to that particular block. Similarly, several PCBs 755 might each contain a ciphersuite parameters field with an IV specific 756 to that PCB instance. 758 Put another way: when confidentiality will generate multiple blocks, 759 it MUST first create a PCB with the required ciphersuite ID, 760 parameters etc. as specified above. Typically, this PCB will appear 761 "early" in the bundle. If this "first" PCB doesn't contain all of 762 the ciphertext, then it may be followed by other, correlated PCBs 763 which MUST NOT repeat the ciphersuite parameters, security-source, or 764 security-destination fields from the first PCB. 766 PCB ciphersuites MUST specify which blocks are to be encrypted. The 767 specification MAY be flexible and be dependent upon block type, 768 security policy, various data values and other inputs but it MUST be 769 deterministic. The determination of whether a block is to be 770 encrypted or not MUST NOT be ambiguous. 772 The ciphersuite may process less than the entire original bundle 773 payload, either because the current payload is a fragment of the 774 original bundle or just becuase it is defined to process some subset. 775 For whatever reason, if the ciphersuite processes less than the 776 complete, original bundle payload the PCB MUST specify, as part of 777 the ciphersuite parameters, which bytes of the bundle payload are 778 protected. 780 After decryption the plaintext recovered from the security-result 781 field should then replace the PCB in the bundle for further 782 processing (e.g. PIB verification). This recovered plaintext MUST 783 contain all the appropriate block type, processing flags and length 784 information. In other words delete the PCB in question and place the 785 recovered plaintext, which consists of some complete non-payload 786 block, in the bundle at the location from which the PCB was deleted. 788 A ciphersuite MUST NOT mix payload data and a non-payload block in a 789 single PCB. 791 Even if a to-be-encrypted block has the "discard" flag set, whether 792 or not the PCB's "discard" flag is set is an implementation/policy 793 decision for the encrypting node. (The "discard" flag is more 794 properly called the "discard if block cannot be processed" flag.) 796 Any existing eid-list in the to-be-encapsulated original block 797 remains exactly as-is, and becomes the eid-list for the replacing 798 block. The encapsulation process MUST NOT replace or remove the 799 existing eid-list entries. This is critically important for correct 800 updating of entries at the security-destination. 802 At the security-destination, either specific destination or the 803 bundle destination, the processes described above are reversed. The 804 payload is decrypted in-place using the salt, IV and key values in 805 the first PCB, including verification using the ICV. These values 806 are described below in Section 2.6. Each correlated PCB is also 807 processed at the same destination, using the salt and key values from 808 the first PCB and the block-specific IV item. The "encapsulated 809 block" item in security-result is decrypted and validated, using also 810 the tag which SHOULD have been appended to the ciphertext of the 811 original block data. Assuming the validation succeeds, the resultant 812 plaintext, which is the entire content of the original block, 813 replaces the PCB at the same place in the bundle. The block type 814 reverts to that of the original block prior to encapsulation, and the 815 other block-specific data fields also return to their original 816 values. Implementors are cautioned that this "replacement" process 817 requires delicate stitchery, as the eid-list contents in the 818 decapsulated block are invalid. As noted above, the eid-list 819 references in the original block were preserved in the replacing PCB, 820 and will have been updated as necessary as the bundle has toured the 821 dtnet. The references from the PCB MUST replace the references 822 within the eid-list of the newly-decapsulated block. Caveat 823 implementor. 825 2.5. Extension Security Block 827 Extension security blocks provide protection for non-payload-related 828 portions of a bundle. They MUST NOT be used for the primary block or 829 payload, including payload-related security blocks (PIBs and PCBs). 831 It is sometimes desirable to protect certain parts of a bundle in 832 ways other than those applied to the bundle payload. One such 833 example is bundle metadata that might specify the kind of data in the 834 payload but not the actual payload detail, as described in [DTNMD]. 836 ESBs are typically used to apply confidentiality protection. While 837 it is possible to create an integrity-only ciphersuite, the block 838 protection is not transparent and makes access to the data more 839 difficult. For simplicity, this discussion describes use of a 840 confidentiality ciphersuite. 842 The protection mechanisms in ESBs are similar to other security 843 blocks with two important differences: 845 - different key values are used (using same key as for payload 846 would defeat the purpose) 848 - the block is not encrypted or super-encrypted with the payload 850 A typical ESB ciphersuite will encrypt the extension block using a 851 randomly generated ephemeral key and will use the key information 852 item in the security parameters field to carry the key encrypted with 853 some long term key encryption key (KEK) or well-known public key. If 854 neither the destination nor security-destination resolves the key to 855 use for decryption, the key information item in the ciphersuite 856 parameters field can be used also to indicate the decryption key with 857 which the BEK can be recovered. 859 It is STRONGLY RECOMMENDED that a data integrity mechanism be used in 860 conjunction with confidentiality, and that encryption-only 861 ciphersuites NOT be used. AES-GCM satisfies this requirement. 863 The ESB is placed in the bundle in the same position as the block 864 being protected. That is, the entire original block is processed 865 (encrypted etc) and encapsulated in a "replacing" ESB-type block, and 866 this appears in the bundle at the same sequential position as the 867 original block. The processed data is placed in the security-result 868 field. 870 The process is reversed at the security destination with the 871 recovered plaintext block replacing the ESB that had encapsulated it. 872 Processing of EID-list entries, if any, is described above in 873 Section 2.4 and this must be followed in order to correctly recover 874 EIDs. 876 An ESB is an ASB with the following additional restrictions: 878 Block type is 0x09. 880 Ciphersuite flags indicate which fields are present in this block. 881 Ciphersuite designers should carefully consider the effect of 882 setting flags that either discard the block or delete the bundle 883 in the event that this block cannot be processed. 885 EID references MUST be stored in the EID reference list. 887 Security-source MAY be present. If not present, then the bundle- 888 source is the security-source. 890 Security-destination MAY be present. If not present, then the 891 bundle-destination is the security-destination. 893 The security-parameters MAY optionally contain a block-type field to 894 indicate the type of the encapsulated block. Since this replicates a 895 field in the encrypted portion of the block, it is a slight security 896 risk and its use is therefore OPTIONAL. 898 2.6. Parameters and Result Fields 900 Various ciphersuites include several items in the security-parameters 901 and/or security-result fields. Which items may appear is defined by 902 the particular ciphersuite description. A ciphersuite MAY support 903 several instances of the same type within a single block. 905 Each item is represented as type-length-value. Type is a single byte 906 indicating which item this is. Length is the count of data bytes to 907 follow, and is an SDNV-encoded integer. Value is the data content of 908 the item. 910 Item types are 912 0: reserved 914 1: initialization vector (IV) 916 2: reserved 918 3: key information 919 4: fragment range (offset and length as a pair of SDNVs) 921 5: integrity signature 923 6: reserved 925 7: salt 927 8: PCB integrity check value (ICV) 929 9: reserved 931 10: encapsulated block 933 11: block type of encapsulated block 935 12 - 191: reserved 937 192 - 250: private use 939 251 - 255: reserved 941 The folowing descriptions apply to usage of these items for all 942 ciphersuites. Additional characteristics are noted in the discussion 943 for specific suites. 945 - initialization vector(IV): random value, typically eight to 946 sixteen bytes 948 - key information: key material encoded or protected by the key 949 management system, and used to transport an ephemeral key 950 protected by a long-term key. This item is discussed further 951 below in Section 2.7 953 - fragment range: pair of SDNV values (offset then length) 954 specifying the range of payload bytes to which a particular 955 operation applies. This is termed "fragment range" since that is 956 its typical use, even though sometimes it may describe a subset 957 range that is not a fragment 959 - integrity signature: result of BA or PI digest or signing 960 operation. This item is discussed further below in Section 2.7 962 - salt: an IV-like value used by certain confidentiality suites 964 - PCB integrity check value(ICV): output from certain 965 confidentiality ciphersuite operations to be used at the 966 destination to verify that the protected data has not been 967 modified 969 - encapsulated block: result of confidentiality operation on 970 certain blocks, contains the ciphertext of the block and may also 971 contain an integrity check value appended to the ciphertext; may 972 also contain padding if required by the encryption mode; used for 973 non-payload blocks only 975 - block type of encapsulated block: block type code for a block 976 that has been encapsulated in ESB 978 2.7. Key Transport 980 This specification endeavours to maintain separation between the 981 security protocol and key management. However these two interact in 982 the transfer of key information etc from security-source to security- 983 destination. The intent of the separation is to facilitate use of a 984 variety of key management systems without a necessity to tailor a 985 ciphersuite to each individually. 987 The key management process deals with such things as long-term keys, 988 specifiers for long-term keys, certificates for long-term keys and 989 integrity signatures using long-term keys. The ciphersuite itself 990 should not require a knowledge of these, and separation is improved 991 if it treats these as opaque entities, to be handled by the key 992 management process. 994 The key management process deals specifically with the content of two 995 of the items defined above in Section 2.6:- key information (item 996 type 3) and integrity signature (item type 5). The ciphersuite MUST 997 define the details and format for these items. To facilitate 998 interoperability, it is strongly RECOMMENDED that the implementations 999 use the appropriate definitions from Cryptographic Message Syntax 1000 (CMS) [RFC5652] and related RFCs. 1002 Many situations will require several pieces of key information. 1003 Again, ciphersuites MUST define whether they accept these packed into 1004 a single key information item and/or separated into multiple 1005 instances of key information. For interoperability, it is 1006 RECOMMENDED that ciphersuites accept these packed into a single key- 1007 information item, and that they MAY additionally choose to accept 1008 them sent as separate items. 1010 2.8. PIB and PCB combinations 1012 Given the above definitions, nodes are free to combine applications 1013 of PIB and PCB in any way they wish - the correlator value allows for 1014 multiple applications of security services to be handled separately. 1016 Since PIB and PCB apply to the payload and ESB to non-payload blocks, 1017 combinations of ESB with PIB and/or PCB are not considered. 1019 There are some obvious security problems that could arise when 1020 applying multiple services. For example, if we encrypted a payload 1021 but left a PIB security result containing a signature in the clear, 1022 payload guesses could be confirmed. 1024 We cannot, in general, prevent all such problems since we cannot 1025 assume that every ciphersuite definition takes account of every other 1026 ciphersuite definition. However, we can limit the potential for such 1027 problems by requiring that any ciphersuite which applies to one 1028 instance of a PIB or PCB, must be applied to all instances with the 1029 same correlator. 1031 We now list the PIB and PCB combinations which we envisage as being 1032 useful to support: 1034 Encrypted tunnels - a single bundle may be encrypted many times 1035 en-route to its destination. Clearly it must be decrypted an 1036 equal number of times, but we can imagine each encryption as 1037 representing the entry into yet another layer of tunnel. This is 1038 supported by using multiple instances of PCB, but with the payload 1039 encrypted multiple times, "in-place". Depending upon the 1040 ciphersuite defintion, other blocks can and should be encrypted, 1041 as discussed above and in Section 2.4 to ensure that parameters 1042 are protected in the case of super-encryption. 1044 Multiple parallel authenticators - a single security source might 1045 wish to protect the integrity of a bundle in multiple ways. This 1046 could be required if the bundle's path is unpredictable, and if 1047 various nodes might be involved as security destinations. 1048 Similarly, if the security source cannot determine in advance 1049 which algorithms to use, then using all might be reasonable. This 1050 would result in uses of PIB which presumably all protect the 1051 payload, and which cannot in general protect one another. Note 1052 that this logic can also apply to a BAB, if the unpredictable 1053 routing happens in the convergence layer, so we also envisage 1054 support for multiple parallel uses of BAB. 1056 Multiple sequential authenticators - if some security destination 1057 requires assurance about the route that bundles have taken, then 1058 it might insist that each forwarding node add its own PIB. More 1059 likely, however would be that outbound "bastion" nodes would be 1060 configured to sign bundles as a way of allowing the sending 1061 "domain" to take accountability for the bundle. In this case, the 1062 various PIBs will likely be layered, so that each protects the 1063 earlier applications of PIB. 1065 Authenticated and encrypted bundles - a single bundle may require 1066 both authentication and confidentiality. Some specifications 1067 first apply the authenticator and follow this by encrypting the 1068 payload and authenticator. As noted previously in the case where 1069 the authenticator is a signature, there are security reasons for 1070 this ordering. (See the PCB-RSA-AES128-PAYLOAD-PIB-PCB 1071 ciphersuite defined later in Section 4.3.) Others apply the 1072 authenticator after encryption, that is, to the ciphertext. This 1073 ordering is generally recommended and minimizes attacks which, in 1074 some cases, can lead to recovery of the encryption key. 1076 There are no doubt other valid ways to combine PIB and PCB instances, 1077 but these are the "core" set supported in this specification. Having 1078 said that, as will be seen, the mandatory ciphersuites defined here 1079 are quite specific and restrictive in terms of limiting the 1080 flexibility offered by the correlator mechanism. This is primarily 1081 in order to keep this specification as simple as possible, while at 1082 the same time supporting the above scenarios. 1084 3. Security Processing 1086 This section describes the security aspects of bundle processing. 1088 3.1. Nodes as policy enforcement points 1090 All nodes are REQUIRED to have and enforce their own configurable 1091 security policies, whether these policies be explicit or default, as 1092 defined in Section 6. 1094 All nodes serve as Policy Enforcement Points (PEP) insofar as they 1095 enforce polices that may restrict the permissions of bundle nodes to 1096 inject traffic into the network. Policies may apply to traffic 1097 originating at the current node, traffic terminating at the current 1098 node and traffic to be forwarded by the current node to other nodes. 1099 If a particular transmission request, originating either locally or 1100 remotely, satisfies the node's policy or policies and is therefore 1101 accepted, then an outbound bundle can be created and dispatched. If 1102 not, then in its role as a PEP, the node will not create or forward a 1103 bundle. Error handling for such cases is currently considered out of 1104 scope of this document. 1106 Policy enforcing code MAY override all other processing steps 1107 described here and elsewhere in this document. For example, it is 1108 valid to implement a node which always attempts to attach a PIB. 1109 Similarly it is also valid to implement a node which always rejects 1110 all requests which imply the use of a PIB. 1112 Nodes MUST consult their security policy to determine the criteria 1113 that a received bundle ought to meet before it will be forwarded. 1114 These criteria MUST include a determination of whether or not the 1115 received bundle must include a valid BAB, PIB, PCB or ESB. If the 1116 bundle does not meet the node's policy criteria, then the bundle MUST 1117 be discarded and processed no further; in this case, a bundle status 1118 report indicating the failure MAY be generated. 1120 The node's policy MAY call for the node to add or subtract some 1121 security blocks, for example, requiring the node attempt to encrypt 1122 (parts of) the bundle for some security-destination, or requiring 1123 that the node add a PIB. If the node's policy requires a BAB to be 1124 added to the bundle, it MUST be added last so that the calculation of 1125 its security result may take into consideration the values of all 1126 other blocks in the bundle. 1128 3.2. Processing order of security blocks 1130 The processing order of security actions for a bundle is critically 1131 important for the actions to complete successfully. In general, the 1132 actions performed at the originating node must be executed in the 1133 reverse sequence at the destination. There are variations and 1134 exceptions, and these are noted below. 1136 The sequence is maintained in the ordering of security blocks in the 1137 bundle. It is for this reason that blocks may not be rearranged at 1138 forwarding nodes, whether they support the security protocols or not. 1139 The only blocks that participate in this ordering are the primary and 1140 payload blocks, and the PIB and PCB security blocks themselves. All 1141 other extension blocks, including ESBs, are ignored for purposes of 1142 determining the processing order. 1144 The security blocks are added to and removed from a bundle in a last- 1145 in-first-out (LIFO) manner, with the top of the stack immediately 1146 after the primary block. A newly-created bundle has just the primary 1147 and payload blocks, and the stack is empty. As security actions are 1148 requested for the bundle, security blocks are pushed onto the stack 1149 immediately after the primary block. The early actions have security 1150 blocks close to the payload, later actions have blocks nearer to the 1151 primary block. The actions deal with only those blocks in the bundle 1152 at the time so, for example, the first to be added processes only the 1153 payload and primary blocks, the next might process the first if it 1154 chooses and the payload and primary, and so on. The last block to be 1155 added can process all the blocks. 1157 When the bundle is received, this process is reversed and security 1158 processing begins at the top of the stack, immediately after the 1159 primary block. The security actions are performed and the block is 1160 popped from the stack. Processing continues with the next security 1161 block until finally only the payload and primary blocks remain. 1163 The simplicity of this description is undermined by various real- 1164 world requirements. Nonetheless it serves as a helpful initial 1165 framework for understanding the bundle security process. 1167 The first issue is a very common one and easy to handle. The bundle 1168 may be sent indirectly to its destination, requiring several 1169 forwarding hops to finally arrive there. Security processing happens 1170 at each node, assuming that the node supports bundle security. For 1171 the following discussion, we assume that a bundle is created and that 1172 confidentiality, then payload integrity and finally bundle 1173 authentication are applied to it. The block sequence would therefore 1174 be primary-BAB-PIB-PCB-payload. Traveling from source to destination 1175 requires going through one intermediate node, so the trip consists of 1176 two hops. 1178 When the bundle is received at the intermediate node, the receive 1179 processing validates the BAB and pops it from the stack. However the 1180 PIBs and PCBs have the final destination as their security 1181 destination, so these can't be processed and removed. The 1182 intermediate node then begins the send process with the four 1183 remaining blocks in the bundle. The outbound processing adds any 1184 security blocks required by local policy, and these are pushed on the 1185 stack immediately after the primary block, ahead of the PIB. In this 1186 example, the intermediate node adds a PIB as a signature that the 1187 bundle has passed through the node. 1189 The receive processing at the destination first handles the 1190 intermediate node's PIB and pops it, next is the originator's PIB, 1191 also popped, and finally the originator's confidentiality block which 1192 allows the payload to be decrypted and the bundle handled for 1193 delivery. 1195 This simple scheme can easily be extended to very complex networks. 1196 It cannot deal with security zones that overlap partially but not 1197 completely and these are discussed further below in Section 3.3. 1198 Administrators SHOULD NOT configure security-sources and security- 1199 destinations in a network such that overlapping security zones are 1200 created. 1202 The second issue relates to the reversibility of certain security 1203 process actions. In general, the actions fall into two categories: 1204 those which do not affect other parts of the bundle, and those which 1205 are fully reversible. Creating a bundle signature, for example, does 1206 not change the bundle content except for the result. The encryption 1207 performed as part of the confidentiality processing does change the 1208 bundle, but the reverse processing at the destination restores the 1209 original content. 1211 The third category is the one where the bundle content has changed 1212 slightly and in a non-destructive way, but there is no mechanism to 1213 reverse the change. The simplest example is the addition of an EID- 1214 reference to a security block. The addition of the reference causes 1215 the text to be added to the bundle's dictionary. The text may be 1216 used also by other references so removal of the block and this 1217 specific eid-reference does not cause removal of the text from the 1218 dictionary. This shortcoming is of no impact to the "sequential" or 1219 "wrapping" security schemes described above, but does cause failures 1220 with "parallel" authentication mechanisms. Solutions for this 1221 problem are implementation-specific and typically involve multi-pass 1222 processing such that blocks are added at one stage and the security 1223 results calculated at a later stage of the overall process. 1225 Certain ciphersuites have sequence requirements for their correct 1226 operation, most notably the bundle authentication ciphersuites. 1227 Processing for bundle authentication is required to happen after all 1228 other sending operations, and prior to any receive operations at the 1229 next hop node. It follows therefore that BA blocks must always be 1230 pushed onto the stack after all others. 1232 Although we describe the security block list as a stack, there are 1233 some blocks which are placed after the payload and therefore are not 1234 part of the stack. The BundleAuthentication ciphersuite #1 ("BA1") 1235 requires a second, correlated block to contain the security-result 1236 and this block is placed after the payload, usually as the last block 1237 in the bundle. We can apply the stack rules even to these blocks by 1238 specifying that they be added to the end of the bundle at the same 1239 time that their "owner" or "parent" block is pushed on the stack. In 1240 fact, they form a stack beginning at the payload but growing in the 1241 other direction. Also, not all blocks in the main stack have a 1242 corresponding entry in the trailing stack. The only blocks which 1243 MUST follow the payload are those mandated by ciphersuites as 1244 correlated blocks for holding a security-result. No other blocks are 1245 required to follow the payload block and it is RECOMMENDED that they 1246 NOT do so. 1248 ESBs are effectively placeholders for the blocks they encapsulate 1249 and, since those do not form part of the processing sequence 1250 described above, ESBs themselves do not either. ESBs may be 1251 correlated, however, so the "no reordering" requirement applies to 1252 them as well. 1254 3.3. Security Zones 1256 Each security block has a security zone, as described in the 1257 discussion for Figure 1, and the zones for various blocks are often 1258 different. 1260 BA blocks are always for a single hop and these restricted zones 1261 never cause conflict. 1263 The zones for PIBs and PCBs are often from bundle source to bundle 1264 destination, to provide end-to-end protection. A bundle-source-to- 1265 bundle-destination zone likewise never causes a problem. 1267 Another common scenario is for gateway-to-gateway protection of 1268 traffic between two sub-networks. 1270 Looking at Figure 1 and the simplified version shown in Figure 4, we 1271 can regard BN2 and BN3 as gateways connecting the two subnetworks 1272 labeled "An Internet". As long as they provide security for the BN2- 1273 BN3 zone, all is well. Problems begin, for example, when BN2 adds 1274 blocks with BN4 as the security-destination, and originating node BN1 1275 has created blocks with BN3 as security-destination. We now have two 1276 zones and neither is a subset of the other. 1278 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 1279 | BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 | 1280 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 1281 >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ 1283 <------------- BN1 to BN3 zone ------------> 1285 <------------- BN2 to BN4 zone ------------> 1287 Overlapping security zones 1289 Figure 4 1291 Consider the case where the security concern is for data integrity, 1292 so the blocks are PIBs. BN1 creates one ("PIa") along with the new 1293 bundle, and BN2 pushes its own PIB "PIb" on the stack, with security- 1294 destination BN4. When this bundle arrives at BN3, the bundle blocks 1295 are 1297 primary - PIb - PIa - payload 1299 Block PIb is not destined for this node BN3 so must be forwarded. 1300 This is the security-destination for block PIa so, after validation, 1301 it should be removed from the bundle. But that will invalidate the 1302 PIb signature when the block is checked at the final destination. 1303 The PIb signature includes the primary block, PIb itself, PIa and the 1304 payload block, so PIa MUST remain in the bundle. This is why 1305 security blocks are treated as a stack and add/remove operations are 1306 permitted only at the top-of-stack. 1308 The situation would be worse if the security concern is 1309 confidentiality, so PCBs are employed, such as the confidentiality 1310 ciphersuite #3 ("PC3") described in Section 4.3. In this scenario, 1311 BN1 would encrypt the bundle with BN3 as security-destination, BN2 1312 would super-encrypt the payload and encapsulate the PC3 block for 1313 security-destination BN4. BN3 forwards all the blocks without 1314 change. BN4 decrypts the payload from its super-encryption and 1315 decapsulates the PC3 block, only to find that it should have been 1316 processed earlier. Assuming that BN4 has no access to BN3's key 1317 store, BN4 has no way to decrypt the bundle and recover the original 1318 content. 1320 3.4. Canonicalisation of bundles 1322 In order to verify a signature or MAC on a bundle the exact same 1323 bits, in the exact same order, must be input to the calculation upon 1324 verification as were input upon initial computation of the original 1325 signature or MAC value. Consequently, a node MUST NOT change the 1326 encoding of any URI in the dictionary field, e.g., changing the DNS 1327 part of some HTTP URL from lower case to upper case. Because bundles 1328 may be modified while in transit (either correctly or due to 1329 implementation errors), a canonical form of any given bundle (that 1330 contains a BAB or PIB) must be defined. 1332 This section defines bundle canonicalisation algorithms used in the 1333 Section 4.1 and Section 4.2 ciphersuites. Other ciphersuites can use 1334 these or define their own canonicalization procedures. 1336 3.4.1. Strict canonicalisation 1338 The first algorithm that can be used permits no changes at all to the 1339 bundle between the security-source and the security-destination. It 1340 is mainly intended for use in BAB ciphersuites. This algorithm 1341 conceptually catenates all blocks in the order presented, but omits 1342 all security result data fields in blocks of this ciphersuite type. 1343 That is, when a BA ciphersuite specifies this algorithm then we omit 1344 all BAB security results for all BA ciphersuites, when a PIB 1345 ciphersuite specifies this algorithm then we omit all PIB security 1346 results for all PI ciphersuites. All security result length fields 1347 are included, even though their corresponding security result data 1348 fields are omitted. 1350 Notes: 1352 - In the above we specify that security result data is omitted. 1353 This means that no bytes of the security result data are input. 1354 We do not set the security result length to zero. Rather, we 1355 assume that the security result length will be known to the module 1356 that implements the ciphersuite before the security result is 1357 calculated, and require that this value be in the security result 1358 length field even though the security result data itself will be 1359 omitted. 1361 - The 'res' bit of the ciphersuite ID, which indicates whether or 1362 not the security result length and security result data field are 1363 present, is part of the canonical form. 1365 -The value of the block data length field, which indicates the 1366 length of the block, is also part of the canonical form. Its 1367 value indicates the length of the entire bundle when the bundle 1368 includes the security result data field. 1370 -BABs are always added to bundles after PIBs, so when a PIB 1371 ciphersuite specifies this strict canonicalisation algorithm and 1372 the PIB is received with a bundle that also includes one or more 1373 BABs, application of strict canonicalisation as part of the PIB 1374 security result verification process requires that all BABs in the 1375 bundle be ignored entirely. 1377 3.4.2. Mutable canonicalisation 1379 This algorithm is intended to protect parts of the bundle which 1380 should not be changed in-transit. Hence it omits the mutable parts 1381 of the bundle. 1383 The basic approach is to define a canonical form of the primary block 1384 and catenate it with the security (PIBs and PCBs only) and payload 1385 blocks in the order that they will be transmitted. This algorithm 1386 ignores all other blocks, including ESBs, because it cannot be 1387 determined whether or not they will change as the bundle transits the 1388 network. In short, this canonicalization protects the payload, 1389 payload-related security blocks and parts of the primary block. 1391 Many fields in various blocks are stored as variable-length SDNVs. 1392 These are canonicalized in unpacked form, as eight-byte fixed-width 1393 fields in network byte order. The size of eight bytes is chosen 1394 because implementations may handle larger values as invalid, as noted 1395 in [DTNBP]. 1397 The canonical form of the primary block is shown in Figure 5. 1398 Essentially, it de-references the dictionary block, adjusts lengths 1399 where necessary and ignores flags that may change in transit. 1401 +----------------+----------------+----------------+----------------+ 1402 | Version | Processing flags (incl. COS and SRR) | 1403 +----------------+----------------+---------------------------------+ 1404 | Canonical primary block length | 1405 +----------------+----------------+---------------------------------+ 1406 | Destination endpoint ID length | 1407 +----------------+----------------+---------------------------------+ 1408 | | 1409 | Destination endpoint ID | 1410 | | 1411 +----------------+----------------+---------------------------------+ 1412 | Source endpoint ID length | 1413 +----------------+----------------+----------------+----------------+ 1414 | | 1415 | Source endpoint ID | 1416 | | 1417 +----------------+----------------+---------------------------------+ 1418 | Report-to endpoint ID length | 1419 +----------------+----------------+----------------+----------------+ 1420 | | 1421 | Report-to endpoint ID | 1422 | | 1423 +----------------+----------------+----------------+----------------+ 1424 | | 1425 + Creation Timestamp (2 x SDNV) + 1426 | | 1427 +---------------------------------+---------------------------------+ 1428 | Lifetime | 1429 +----------------+----------------+----------------+----------------+ 1431 The canonical form of the primary bundle block. 1433 Figure 5 1435 The fields shown in Figure 5 are: 1437 Version is the single-byte value in the primary block. 1439 Processing flags in the primary block is an SDNV, and includes the 1440 class-of-service (COS) and status report request (SRR) fields. 1441 For purposes of canonicalization, the SDNV is unpacked into a 1442 fixed-width field and some bits are masked out. The unpacked 1443 field is ANDed with mask 0x0000 0000 003E 031F to set to zero all 1444 reserved bits and the "bundle is a fragment" bit. 1446 Length - a four-byte value containing the length (in bytes) of 1447 this structure, in network byte order. 1449 Destination endpoint ID length and value - are the length (as a 1450 four byte value in network byte order) and value of the 1451 destination endpoint ID from the primary bundle block. The URI is 1452 simply copied from the relevant part(s) of the dictionary block 1453 and is not itself canonicalised. Although the dictionary entries 1454 contain null-terminators, the null-terminators are not included in 1455 the length or the canonicalization. 1457 Source endpoint ID length and value are handled similarly to the 1458 destination. 1460 Report-to endpoint ID length and value are handled similarly to 1461 the destination. 1463 Creation time (2 x SDNV) and Lifetime (SDNV) are simply copied 1464 from the primary block, with the SDNV values being represented as 1465 eight-byte unpacked values. 1467 Fragment offset and Total application data unit length are 1468 ignored, as is the case for the "bundle is a fragment" bit 1469 mentioned above. If the payload data to be canonicalized is less 1470 than the complete, original bundle payload, the offset and length 1471 are specified in the security-parameters. 1473 For non-primary blocks being included in the canonicalization, the 1474 block processing flags value used for canonicalization is the 1475 unpacked SDNV value with reserved and mutable bits masked to zero. 1476 The unpacked value is ANDed with mask 0x0000 0000 0000 0057 to zero 1477 reserved bits and the "last block" flag. The "last block" flag is 1478 ignored because BABs and other security blocks may be added for some 1479 parts of the journey but not others so the setting of this bit might 1480 change from hop to hop. 1482 Endpoint ID references in security blocks are canonicalized using the 1483 de-referenced text form in place of the reference pair. The 1484 reference count is not included, nor is the length of the endpoint ID 1485 text. 1487 The block-length is canonicalized as an eight-byte unpacked value in 1488 network byte order. If the payload data to be canonicalized is less 1489 than the complete, original bundle payload, this field contain the 1490 size of the data being canonicalized (the "effective block") rather 1491 that the actual size of the block. 1493 Payload blocks are generally canonicalized as-is with the exception 1494 that in some instances only a portion of the payload data is to be 1495 protected. In such a case, only those bytes are included in the 1496 canonical form, and additional ciphersuite parameters are required to 1497 specify which part of the payload is protected, as discussed further 1498 below. 1500 Security blocks are handled likewise, except that the ciphersuite 1501 will likely specify that the "current" security block security result 1502 field not be considered part of the canonical form. This differs 1503 from the strict canonicalisation case since we might use the mutable 1504 canonicalisation algorithm to handle sequential signatures such that 1505 signatures cover earlier ones. 1507 ESBs MUST NOT be included in the canonicalization. 1509 Notes: 1511 - The canonical form of the bundle is not transmitted. It is 1512 simply an artifact used as input to digesting. 1514 - We omit the reserved flags because we cannot determine if they 1515 will change in transit. The masks specified above may have to be 1516 revised if additional flags are defined and they need to be 1517 protected. 1519 - Our URI encoding does not preserve the "null-termination" 1520 convention from the dictionary field, nor do we separate the 1521 scheme and ssp as is done there. 1523 - The URI encoding will cause errors if any node rewrites the 1524 dictionary content (e.g. changing the DNS part of an HTTP URL from 1525 lower-case to upper case). This could happen transparently when a 1526 bundle is synched to disk using one set of software and then read 1527 from disk and forwarded by a second set of software. Because 1528 there are no general rules for canonicalising URIs (or IRIs), this 1529 problem may be an unavoidable source of integrity failures. 1531 - All SDNV fields here are canonicalized as eight-byte unpacked 1532 values in network byte order. Length fields are canonicalized as 1533 four-byte values in network byte order. Encoding does not need 1534 optimization since the values are never sent over the network. 1536 If a bundle is fragmented before the PIB is applied then the PIB 1537 applies to a fragment and not the entire bundle. However, the 1538 protected fragment could be subsequently further fragmented, which 1539 would leave the verifier unable to know which bytes were protected 1540 by the PIB. Even in the absence of frgmentation the same 1541 situation applies if the ciphersuite is defined to allow 1542 protection of less than the entire, original bundle payload. 1544 For this reason, PIB ciphersuites which support applying a PIB to 1545 less than the complete, original bundle payload MUST specify, as 1546 part of the ciphersuite parameters, which bytes of the bundle 1547 payload are protected. When verification occurs, only the 1548 specified range of the payload bytes are input to PIB 1549 verification. It is valid for a ciphersuite to be specified so as 1550 to only apply to entire bundles and not to fragments. A 1551 ciphersuite may be specified to apply to only a portion of the 1552 payload, regardless of whether the payload is a fragment or the 1553 complete original bundle payload. 1555 The same fragmentation issue applies equally to PCB ciphersuites. 1556 Ciphersuites which support applying confidentiality to fragments 1557 MUST specify, as part of the ciphersuite parameters, which bytes 1558 of the bundle payload are protected. When decrypting a fragment, 1559 only the specified bytes are processed. It is also valid for a 1560 confidentiality ciphersuite to be specified so as to only apply to 1561 entire bundles and not to fragments. 1563 This definition of mutable canonicalization assumes that endpoint IDs 1564 themselves are immutable and is unsuitable for use in environments 1565 where that assumption might be violated. 1567 Since the canonicalization applies to a specific bundle rather than a 1568 payload, an originator's signature cannot be verified if a payload is 1569 forwarded, as the forwarded bundle will have a different source. 1571 The solution for either of these issues is to define and use a PIB 1572 ciphersuite having an alternate version of mutable canonicalization 1573 any fields from the primary block. 1575 3.5. Endpoint ID confidentiality 1577 Every bundle MUST contain a primary block that contains the source 1578 and destinations endpoint IDs, and others, and that cannot be 1579 encrypted. If endpoint ID confidentiality is required, then bundle- 1580 in-bundle encapsulation may solve this problem in some instances. 1582 Similarly, confidentiality requirements may also apply to other parts 1583 of the primary block (e.g. the current-custodian) and that is 1584 supported in the same manner. 1586 3.6. Bundles received from other nodes 1588 Nodes implementing this specification SHALL consult their security 1589 policy to determine whether or not a received bundle is required by 1590 policy to include a BAB. If the bundle has no BAB and one is not 1591 required then BAB processing on the received bundle is complete and 1592 the bundle is ready to be further processed for PIB/PCB/ESB handling 1593 or delivery or forwarding. 1595 If the bundle is required to have a BAB but does not, then the bundle 1596 MUST be discarded and processed no further. If the bundle is 1597 required to have a BAB but all of its BABs identify a different node 1598 other than the receiving node as the BAB security destination, then 1599 the bundle MUST be discarded and processed no further. 1601 If the bundle is required to have a BAB and has one or more BABs that 1602 identify the receiving node as the BAB security destination, or for 1603 which there is no security destination, then the value in the 1604 security result field(s) of the BAB(s) MUST be verified according to 1605 the ciphersuite specification. If for all such BABs in the bundle 1606 either the BAB security source cannot be determined or the security 1607 result value check fails, the bundle has failed to authenticate and 1608 the bundle MUST be discarded and processed no further. If any of the 1609 BABs present verify, or if a BAB is not required, the bundle is ready 1610 for further processing as determined by extension blocks and/or 1611 policy. 1613 BABs received in a bundle MUST be stripped before the bundle is 1614 forwarded. New BABs MAY be added as required by policy. This may 1615 require correcting the "last block" field of the to-be-forwarded 1616 bundle. 1618 Further processing of the bundle must take place in the order 1619 indicated by the various blocks from the primary block to the payload 1620 block, except as defined by an applicable specification. 1622 If the bundle has a PCB and the receiving node is the PCB destination 1623 for the bundle (either because the node is listed as the bundle's 1624 PCB-dest or because the node is listed as the bundle's destination 1625 and there is no PCB-dest), the node MUST decrypt the relevant parts 1626 of the bundle in accordce with the ciphersuite specification. The 1627 PCB SHALL be deleted. If the relevant parts of the bundle cannot be 1628 decrypted (i.e. the decryption key cannot be deduced or decryption 1629 fails), then the bundle MUST be discarded and processed no further; 1630 in this case a bundle deletion status report (see the Bundle Protocol 1631 [DTNBP]) indicating the decryption failure MAY be generated. If the 1632 PCB security result included the ciphertext of a block other than the 1633 payload block, the recovered plaintext block MUST be placed in the 1634 bundle at the location from which the PCB was deleted. 1636 If the bundle has one or more PIBs for which the receiving node is 1637 the bundle's PIB destination (either because the node is listed in 1638 the bundle's PIB-dest or because the node is listed as the bundle's 1639 destination and there is no PIB-dest), the node MUST verify the value 1640 in the PIB security result field(s) in accordance with the 1641 ciphersuite specification. If all the checks fail, the bundle has 1642 failed to authenticate and the bundle SHALL be processed according to 1643 the security policy. A bundle status report indicating the failure 1644 MAY be generated. Otherwise, if the PIB verifies, the bundle is 1645 ready to be processed for either delivery or forwarding. Before 1646 forwarding the bundle, the node SHOULD remove the PIB from the 1647 bundle, subject to the requirements of Section 3.2, unless it is 1648 likely that some downstream node will also be able to verify the PIB. 1650 If the bundle has a PIB and the receiving node is not the bundle's 1651 PIB-dest the receiving node MAY attempt to verify the value in the 1652 security result field. If it is able to check and the check fails, 1653 the node SHALL discard the bundle and it MAY send a bundle status 1654 report indicating the failure. 1656 If the bundle has an ESB and the receiving node is the ESB 1657 destination for the bundle (either because the node is listed as the 1658 bundle's ESB-dest or because the node is listed as the bundle's 1659 destination and there is no ESB-dest), the node MUST decrypt and/or 1660 decapsulate the encapsulated block in accordance with the ciphersuite 1661 specification. The decapsulated block replaces the ESB in the bundle 1662 block sequence, and the ESB is thereby deleted. If the content 1663 cannot be decrypted (i.e., the decryption key cannot be deduced or 1664 decryption fails), then the bundle MAY be discarded and processed no 1665 further unless the security policy specifies otherwise. In this case 1666 a bundle deletion status report (see the Bundle Protocol [DTNBP]) 1667 indicating the decryption failure MAY be generated. 1669 3.7. The At-Most-Once-Delivery Option 1671 An application may request (in an implementation specific manner) 1672 that a node be registered as a member of an endpoint and that 1673 received bundles destined for that endpoint be delivered to that 1674 application. 1676 An option for use in such cases is known as "at-most-once-delivery". 1677 If this option is chosen, the application indicates that it wants the 1678 node to check for duplicate bundles, discard duplicates, and deliver 1679 at most one copy of each received bundle to the application. If this 1680 option is not chosen, the application indicates that it wants the 1681 node to deliver all received bundle copies to the application. If 1682 this option is chosen, the node SHALL deliver at most one copy of 1683 each received bundle to the application. If the option is not 1684 chosen, the node SHOULD, subject to policy, deliver all bundles. 1686 To enforce this the node MUST look at the source/timestamp pair value 1687 of each complete (reassembled, if necessary) bundle received and 1688 determine if this pair, which uniquely identifies a bundle, has been 1689 previously received. If it has, then the bundle is a duplicate. If 1690 it has not, then the bundle is not a duplicate. The source/timestamp 1691 pair SHALL be added to the list of pair values already received by 1692 that node. 1694 Each node implementation may decide how long to maintain a table of 1695 pair value state. 1697 Additional discussion relevant to at-most-once-delivery is in the DTN 1698 Retransmission Block specification [DTNRB]. 1700 3.8. Bundle Fragmentation and Reassembly 1702 If it is necessary for a node to fragment a bundle and security 1703 services have been applied to that bundle, the fragmentation rules 1704 described in [DTNBP] MUST be followed. As defined there and repeated 1705 here for completeness, only the payload may be fragmented; security 1706 blocks, like all extension blocks, can never be fragmented. In 1707 addition, the following security-specific processing is REQUIRED: 1709 The security policy requirements for a bundle must be applied 1710 individually to all the bundles resulting from a fragmentation event. 1712 If the original bundle contained a PIB, then each of the PIB 1713 instances MUST be included in some fragment. 1715 If the original bundle contained one or more PCBs, then any PCB 1716 instances containing a key information item MUST have the "replicate 1717 in every fragment" flag set, and thereby be replicated in every 1718 fragment. This is to ensure that the canonical block-sequence can be 1719 recovered during reassembly. 1721 If the original bundle contained one or more correlated PCBs not 1722 containing a key information item, then each of these MUST be 1723 included in some fragment, but SHOULD NOT be sent more than once. 1724 They MUST be placed in a fragment in accordance with the 1725 fragmentation rules described in [DTNBP]. 1727 Note: various fragments may have additional security blocks added at 1728 this or later stages and it is possible that correlators may collide. 1729 In order to facilitate uniqueness, ciphersuites SHOULD include the 1730 fragment-offset of the fragment as a high-order component of the 1731 correlator. 1733 3.9. Reactive fragmentation 1735 When a partial bundle has been received, the receiving node SHALL 1736 consult its security policy to determine if it may fragment the 1737 bundle, converting the received portion into a bundle fragment for 1738 further forwarding. Whether or not reactive fragmentation is 1739 permitted SHALL depend on the security policy and the ciphersuite 1740 used to calculate the BAB authentication information, if required. 1741 (Some BAB ciphersuites, i.e., the mandatory BAB-HMAC ciphersuite 1742 defined in Section 4.1, do not accommodate reactive fragmentation 1743 because the security result in the BAB requires that the entire 1744 bundle be signed. It is conceivable, however, that a BAB ciphersuite 1745 could be defined such that multiple security results are calculated, 1746 each on a different segment of a bundle, and that these security 1747 results could be interspersed between bundle payload segments such 1748 that reactive fragmentation could be accommodated.) 1750 If the bundle is reactively fragmented by the intermediate receiver 1751 and the BAB-ciphersuite is of an appropriate type (e.g. with multiple 1752 security results embedded in the payload), the bundle MUST be 1753 fragmented immediately after the last security result value in the 1754 partial payload that is received. Any data received after the last 1755 security result value MUST be dropped. 1757 If a partial bundle is received at the intermediate receiver and is 1758 reactively fragmented and forwarded, only the part of the bundle that 1759 was not received MUST be retransmitted, though more of the bundle MAY 1760 be retransmitted. Before retransmitting a portion of the bundle, it 1761 SHALL be changed into a fragment and, if the original bundle included 1762 a BAB, the fragmented bundle MUST also, and its BAB SHALL be 1763 recalculated. 1765 This specification does not currently define any ciphersuite which 1766 can handle this reactive fragmentation case. 1768 An interesting possibility is a ciphersuite definition such that the 1769 transmission of a follow-up fragment would be accompanied by the 1770 signature for the payload up to the restart point. 1772 4. Mandatory Ciphersuites 1774 This section defines the mandatory ciphersuites for this 1775 specification. There is currently one mandatory ciphersuite for use 1776 with each of the security block types BAB, PIB, PCB and ESB. The BAB 1777 ciphersuite is based on shared secrets using HMAC. The PIB 1778 ciphersuite is based on digital signatures using RSA with SHA256. 1779 The PCB and ESB ciphersuites are based on using RSA for key transport 1780 and AES for bulk encryption. 1782 The key transport mechanisms defined in Cryptographic Message Syntax 1783 [RFC5652] are suitable for the ciphersuites, with only minor 1784 adjustment as required by the ciphersuite characteristics. 1786 4.1. BAB-HMAC 1788 The BAB-HMAC ciphersuite has ciphersuite ID value 0x001. 1790 BAB-HMAC uses the strict canonicalisation algorithm in Section 3.4.1. 1792 Strict canonicalization supports digesting of a fragment-bundle. It 1793 does not permit the digesting of only a subset of the payload, but 1794 only the complete contents of the payload of the current bundle, 1795 which might be a fragment. The "fragment range" item for security- 1796 parameters is not used to indicate a fragment, as this information is 1797 digested within the primary block. 1799 The variant of HMAC to be used is HMAC-SHA1 as defined in [RFC2104]. 1801 This ciphersuite requires the use of two related instances of the 1802 BAB. It involves placing the first BAB instance (as defined in 1803 Section 2.2) just after the primary block. The second (correlated) 1804 instance of the BAB MUST be placed after all other blocks (except 1805 possibly other BAB blocks) in the bundle. 1807 This means that normally, the BAB will be the second and last blocks 1808 of the bundle. If a forwarder wishes to apply more than one 1809 correlated BAB pair, then this can be done. There is no requirement 1810 that each application "wrap" the others, but the forwarder MUST 1811 insert all the "up front" BABs, and their "at back" "partners" 1812 (without any security result), before canonicalising. 1814 Inserting more than one correlated BAB pair would be useful if the 1815 bundle could be routed to more than one potential "next-hop" or if 1816 both an old or a new key were valid at sending time, with no 1817 certainty about the situation that will obtain at reception time. 1819 The security result is the output of the HMAC-SHA1 calculation with 1820 input being the result of running the entire bundle through the 1821 strict canonicalisation algorithm. Both required BAB instances MUST 1822 be included in the bundle before canonicalisation. 1824 Security parameters are optional with this scheme, but if used then 1825 the only field that can be present is key information (see 1826 Section 2.6). 1828 Implementations MUST support use of "AuthenticatedData" type as 1829 defined in [RFC5652] section 9.1, with RecipientInfo type 1830 KeyTransRecipientInfo containing the issuer and serial number of a 1831 suitable certificate. They MAY support additional RecipientInfo 1832 types. They MAY additionally use the "SignedData" type described in 1833 [RFC5652] section 5.1. In either case, the optional "eContent" field 1834 in EncapsulatedContentInfo MUST be omitted. That is, the data itself 1835 is external, being the canonicalized form of the bundle. 1837 Because this ciphersuite requires that the security result be in the 1838 second, correlated BAB, the content of the 1839 "MessageAuthenticationCode" field in AuthenticatedData is ignored, 1840 although the field must be present. 1842 In the absence of key information the receiver is expected to be able 1843 to find the correct key based on the sending identity. The sending 1844 identity may be known from the security-source field or the content 1845 of a previous-hop block in the bundle. It may also be determined 1846 using implementation-specific means such as the convergence layer. 1848 4.2. PIB-RSA-SHA256 1850 The PIB-RSA-SHA256 ciphersuite has ciphersuite ID value 0x02. 1852 If the bundle being signed has been fragmented before signing, then 1853 we have to specify which bytes were signed in case the signed bundle 1854 is subsequently fragmented for a second time. If the bundle is a 1855 fragment, then the ciphersuite parameters MUST include a fragment- 1856 range field, as described in Section 2.6, specifying the offset and 1857 length of the signed fragment. If the entire bundle is signed then 1858 these numbers MUST be omitted. 1860 Implementations MUST support use of "SignedData" type as defined in 1861 [RFC5652] section 5.1, with SignerInfo type SignerIdentifier 1862 containing the issuer and serial number of a suitable certificate. 1863 The optional "eContent" field in EncapsulatedContentInfo MUST be 1864 omitted. That is, the data itself is external, being the 1865 canonicalized form of the bundle. 1867 Because the signature field in SignedData SignatureValue is a 1868 security-result field, the entire key information item MUST be placed 1869 in the block's security-result field, rather than security- 1870 parameters. 1872 PIB-RSA-SHA256 uses the mutable canonicalisation algorithm 1873 Section 3.4.2, with the security-result data field for only the 1874 "current" block being excluded from the canonical form. The 1875 resulting canonical form of the bundle is the input to the signing 1876 process. This ciphersuite requires the use of a single instance of 1877 the PIB. 1879 RSA is used with SHA256 as specified for the id-sha256 PKCSv2.1 1880 signature scheme in [RFC4055]. The output of the signing process is 1881 the SignatureValue field for the PIB. 1883 "Commensurate strength" cryptography is generally held to be a good 1884 idea. A combination of RSA with SHA256 is reckoned to require a 3076 1885 bit RSA key according to this logic. Few implementations will choose 1886 this length by default (and probably some just won't support such 1887 long keys). Since this is an experimental protocol, we expect that 1888 1024 or 2048 bit RSA keys will be used in many cases, and that that 1889 will be fine since we also expect that the hash function "issues" 1890 will be resolved before any standard would be derived from this 1891 protocol. 1893 4.3. PCB-RSA-AES128-PAYLOAD-PIB-PCB 1895 The PCB-RSA-AES128-PAYLOAD-PIB-PCB ciphersuite has ciphersuite ID 1896 value 0x003. 1898 This scheme encrypts PIBs, PCBs and the payload. The key size for 1899 this ciphersuite is 128 bits. 1901 Encryption is done using the AES algorithm in Galois/Counter Mode 1902 (GCM) as described in [RFC5084] [Note: parts of the following 1903 description are borrowed from RFC 4106]. 1905 The choice of GCM avoids expansion of the payload, which causes 1906 problems with fragmentation/reassembly and custody transfer. GCM 1907 also includes authentication, essential in preventing attacks that 1908 can alter the decrypted plaintext or even recover the encryption key. 1910 GCM is a block cipher mode of operation providing both 1911 confidentiality and data origin authentication. The GCM 1912 authenticated encryption operation has four inputs: a secret key, an 1913 initialization vector (IV), a plaintext, and an input for additional 1914 authenticated data (AAD) which is not used here. It has two outputs, 1915 a ciphertext whose length is identical to the plaintext, and an 1916 authentication tag, also known as the Integrity Check Value (ICV). 1918 For consistency with the description in [RFC5084], we refer to the 1919 GCM IV as a nonce. The same key and nonce combination MUST NOT be 1920 used more than once. The nonce has the following layout 1922 +----------------+----------------+---------------------------------+ 1923 | salt | 1924 +----------------+----------------+---------------------------------+ 1925 | | 1926 | initialization vector | 1927 | | 1928 +----------------+----------------+---------------------------------+ 1930 Nonce format. 1932 Figure 6 1934 The salt field is a four-octet value, usually chosen at random. It 1935 MUST be the same for all PCBs which have the same correlator value. 1936 The salt need not be kept secret. 1938 The initialization vector (IV) is an eight-octet value, usually 1939 chosen at random. It MUST be different for all PCBs which have the 1940 same correlator value. The value need not be kept secret. 1942 The key (bundle encryption key, BEK) is a sixteen-octet (128 bits) 1943 value, usually chosen at random. The value MUST be kept secret, as 1944 described below. 1946 The integrity check value is a sixteen-octet value used to verify 1947 that the protected data has not been altered. The value need not be 1948 kept secret. 1950 This ciphersuite requires the use of a single PCB instance to deal 1951 with payload confidentiality. If the bundle already contains PIBs or 1952 PCBs then the ciphersuite will create additional correlated blocks to 1953 protect these PIBs and PCBs. These "additional" blocks replace the 1954 original blocks on a one-for-one basis, so the number of blocks 1955 remains unchanged. All these related blocks MUST have the same 1956 correlator value. The term "first PCB" in this section refers to the 1957 single PCB if there is only one or, if there are several, then to the 1958 one containing the key information. This MUST be the first of the 1959 set. 1961 First PCB - the first PCB may contain a correlator value, and may 1962 specify security-source and/or security-destination in the eid-list. 1964 If not specified, the bundle-source and bundle-destination 1965 respectively are used for these values, as with other ciphersuites. 1966 The block MUST contain security-parameters and security-result 1967 fields. Each field may contain several items formatted as described 1968 in Section 2.6. 1970 Security-parameters 1972 key information 1974 salt 1976 IV (this instance applies only to payload) 1978 fragment offset and length, if bundle is a fragment 1980 Security-result 1982 ICV 1984 Subsequent PCBs MUST contain a correlator value to link them to the 1985 first PCB. Security-source and security-destination are implied from 1986 the first PCB, however see the discussion in Section 2.4 concerning 1987 eid-list entries. They MUST contain security-parameters and 1988 security-result fields as follows: 1990 Security-parameters 1992 IV for this specific block 1994 Security-result 1996 encapsulated block 1998 The security-parameters and security-result fields in the subsequent 1999 PCBs MUST NOT contain any items other than these two. Items such as 2000 key and salt are supplied in the first PCB and MUST NOT be repeated. 2002 Implementations MUST support use of "Enveloped-data" type as defined 2003 in [RFC5652] section 6, with RecipientInfo type KeyTransRecipientInfo 2004 containing the issuer and serial number of a suitable certificate. 2005 They MAY support additional RecipientInfo types. The optional 2006 "eContent" field in EncryptedContentInfo MUST be omitted. That is, 2007 the data itself is external, being the payload of the bundle. 2009 The Integrity Check Value from the AES-GCM encryption of the payload 2010 is placed in the security-result field of the first PCB. 2012 If the bundle being encrypted is a fragment-bundle we have to specify 2013 which bytes are encrypted in case the bundle is subsequently 2014 fragmented again. If the bundle is a fragment the ciphersuite 2015 parameters MUST include a fragment-range field, as described in 2016 Section 2.6, specifying the offset and length of the encrypted 2017 fragment. Note that this is not the same pair of fields which appear 2018 in the primary block as "offset and length". The "length" in this 2019 case is the length of the fragment, not the original length. If the 2020 bundle is not a fragment then this field MUST be omitted. 2022 The confidentiality processing for payload and other blocks is 2023 different, mainly because the payload might be fragmented later at 2024 some other node. 2026 For the payload, only the bytes of the bundle payload field are 2027 affected, being replaced by ciphertext. The salt, IV and key values 2028 specified in the first PCB are used to encrypt the payload, and the 2029 resultant authentication tag (ICV) is placed in an ICV item in the 2030 security-result field of that first PCB. The other bytes of the 2031 payload block, such as type, flags and length, are not modified. 2033 For each PIB or PCB to be protected, the entire original block is 2034 encapsulated in a "replacing" PCB. This replacing PCB is placed in 2035 the outgoing bundle in the same position as the original block, PIB 2036 or PCB. As mentioned above, this is one-for-one replacement and 2037 there is no consolidation of blocks or mixing of data in any way. 2039 The encryption process uses AES-GCM with the salt and key values from 2040 the first PCB, and an IV unique to this PCB. The process creates 2041 ciphertext for the entire original block, and an authentication tag 2042 for validation at the security destination. For this encapsulation 2043 process, unlike the processing of the bundle payload, the 2044 authentication tag is appended to the ciphertext for the block and 2045 the combination is stored into the "encapsulated block" item in 2046 security-result. 2048 The replacing block, of course, also has the same correlator value as 2049 the first PCB with which it is associated. It also contains the 2050 block-specific IV in security-parameters, and the combination of 2051 original-block-ciphertext and authentication tag, stored as an 2052 "encapsulated block" item in security-result. 2054 If the payload was fragmented after encryption then all those 2055 fragments MUST be present and reassembled before decryption. This 2056 process might be repeated several times at different destinations if 2057 multiple fragmentation actions have occurred. 2059 The size of the GCM counter field limits the payload size to 2^39 - 2060 256 bytes, about half a terabyte. A future revision of this 2061 specification will address the issue of handling payloads in excess 2062 of this size. 2064 4.4. ESB-RSA-AES128-EXT 2066 The ESB-RSA-AES128-EXT ciphersuite has ciphersuite ID value 0x004. 2068 This scheme encrypts non-payload-related blocks. It MUST NOT be used 2069 to encrypt PIBs, PCBs or primary or payload blocks. The key size for 2070 this ciphersuite is 128 bits. 2072 Encryption is done using the AES algorithm in Galois/Counter Mode 2073 (GCM) as described in [RFC5084] [Note: parts of the following 2074 description are borrowed from RFC 4106]. 2076 GCM is a block cipher mode of operation providing both 2077 confidentiality and data origin authentication. The GCM 2078 authenticated encryption operation has four inputs: a secret key, an 2079 initialization vector (IV), a plaintext, and an input for additional 2080 authenticated data (AAD) which is not used here. It has two outputs, 2081 a ciphertext whose length is identical to the plaintext, and an 2082 authentication tag, also known as the Integrity Check Value (ICV). 2084 For consistency with the description in [RFC5084], we refer to the 2085 GCM IV as a nonce. The same key and nonce combination MUST NOT be 2086 used more than once. The nonce has the following layout 2088 +----------------+----------------+---------------------------------+ 2089 | salt | 2090 +----------------+----------------+---------------------------------+ 2091 | | 2092 | initialization vector | 2093 | | 2094 +----------------+----------------+---------------------------------+ 2096 Nonce format. 2098 Figure 7 2100 The salt field is a four-octet value, usually chosen at random. It 2101 MUST be the same for all ESBs which have the same correlator value. 2102 The salt need not be kept secret. 2104 The initialization vector (IV) is an eight-octet value, usually 2105 chosen at random. It MUST be different for all ESBs which have the 2106 same correlator value. The value need not be kept secret. 2108 The data encryption key is a sixteen-octet (128 bits) value, usually 2109 chosen at random. The value MUST be kept secret, as described below. 2111 The integrity check value is a sixteen-octet value used to verify 2112 that the protected data has not been altered. The value need not be 2113 kept secret. 2115 This ciphersuite replaces each BP extension block to be protected 2116 with a "replacing" ESB, and each can be individually specified. 2118 If a number of related BP extension blocks are to be protected they 2119 can be grouped as a correlated set and protected using a single key. 2120 These blocks replace the original blocks on a one-for-one basis, so 2121 the number of blocks remains unchanged. All these related blocks 2122 MUST have the same correlator value. The term "first ESB" in this 2123 section refers to the single ESB if there is only one or, if there 2124 are several, then to the one containing the key or key-identifier. 2125 This MUST be the first of the set. If the blocks are individually 2126 specified then there is no correlated set and each block is its own 2127 "first ESB". 2129 First ESB - the first ESB may contain a correlator value, and may 2130 specify security-source and/or security-destination in the eid-list. 2131 If not specified, the bundle-source and bundle-destination 2132 respectively are used for these values, as with other ciphersuites. 2133 The block MUST contain security-parameters and security-result 2134 fields. Each field may contain several items formatted as described 2135 in Section 2.6. 2137 Security-parameters 2139 key information 2141 salt 2143 IV for this specific block 2145 Security-result 2147 encapsulated block 2149 Subsequent ESBs MUST contain a correlator value to link them to the 2150 first ESB. Security-source and security-destination are implied from 2151 the first ESB, however see the discussion in Section 2.4 concerning 2152 eid-list entries. They MUST contain security-parameters and 2153 security-result fields as follows: 2155 Security-parameters 2156 IV for this specific block 2158 Security-result 2160 encapsulated block 2162 The security-parameters and security-result fields in the subsequent 2163 ESBs MUST NOT contain any items other than these two. Items such as 2164 key and salt are supplied in the first ESB and MUST NOT be repeated. 2166 Implementations MUST support use of "Enveloped-data" type as defined 2167 in [RFC5652] section 6, with RecipientInfo type KeyTransRecipientInfo 2168 containing the issuer and serial number of a suitable certificate. 2169 They MAY support additional RecipientInfo types. The optional 2170 "eContent" field in EncryptedContentInfo MUST be omitted. That is, 2171 the data itself is external, being the content of the block being 2172 protected. 2174 For each block to be protected, the entire original block is 2175 encapsulated in a "replacing" ESB. This replacing ESB is placed in 2176 the outgoing bundle in the same position as the original block. As 2177 mentioned above, this is one-for-one replacement and there is no 2178 consolidation of blocks or mixing of data in any way. 2180 The encryption process uses AES-GCM with the salt and key values from 2181 the first ESB, and an IV unique to this ESB. The process creates 2182 ciphertext for the entire original block, and an authentication tag 2183 for validation at the security destination. The authentication tag 2184 is appended to the ciphertext for the block and the combination is 2185 stored into the "encapsulated block" item in security-result. 2187 The replacing block, of course, also has the same correlator value as 2188 the first ESB with which it is associated. It also contains the 2189 block-specific IV in security-parameters, and the combination of 2190 original-block-ciphertext and authentication tag, stored as an 2191 "encapsulated block" item in security-result. 2193 5. Key Management 2195 Key management in delay tolerant networks is recognized as a 2196 difficult topic and is one that this specification does not attempt 2197 to solve. However, solely in order to support implementation and 2198 testing,implementations SHOULD support: 2200 - The use of well-known RSA public keys for all ciphersuites. 2202 - Long-term pre-shared-symmetric keys for the BAB-HMAC 2203 ciphersuite. 2205 Since endpoint IDs are URIs and URIs can be placed in X.509 [RFC3280] 2206 public key certificates (in the subjectAltName extension) 2207 implementations SHOULD support this way of distributing public keys. 2208 Implementations SHOULD NOT be very strict in how they process X.509 2209 though, for example, it would probably not be correct to insist on 2210 Certificate Revocation List (CRL) checking in many DTN contexts. 2212 6. Default Security Policy 2214 Every node serves as a Policy Enforcement Point insofar as it 2215 enforces some policy that controls the forwarding and delivery of 2216 bundles via one or more convergence layer protocol implementation. 2217 Consequently, every node SHALL have and operate according to its own 2218 configurable security policy, whether the policy be explicit or 2219 default. The policy SHALL specify: 2221 Under what conditions received bundles SHALL be forwarded. 2223 Under what conditions received bundles SHALL be required to 2224 include valid BABs. 2226 Under what conditions the authentication information provided in a 2227 bundle's BAB SHALL be deemed adequate to authenticate the bundle. 2229 Under what conditions received bundles SHALL be required to have 2230 valid PIBs and/or PCBs. 2232 Under what conditions the authentication information provided in a 2233 bundle's PIB SHALL be deemed adequate to authenticate the bundle. 2235 Under what conditions a BAB SHALL be added to a received bundle 2236 before that bundle is forwarded. 2238 Under what conditions a PIB SHALL be added to a received bundle 2239 before that bundle is forwarded. 2241 Under what conditions a PCB SHALL be added to a received bundle 2242 before that bundle is forwarded. 2244 Under what conditions an ESB SHALL be applied to one or more 2245 blocks in a received bundle before that bundle is forwarded. 2247 The actions that SHALL be taken in the event that a received 2248 bundle does not meet the receiving node's security policy 2249 criteria. 2251 This specification does not address how security policies get 2252 distributed to nodes. It only REQUIRES that nodes have and enforce 2253 security policies. 2255 If no security policy is specified at a given node, or if a security 2256 policy is only partially specified, that node's default policy 2257 regarding unspecified criteria SHALL consist of the following: 2259 Bundles that are not well-formed do not meet the security policy 2260 criteria. 2262 The mandatory ciphersuites MUST be used. 2264 All bundles received MUST have a BAB which MUST be verified to 2265 contain a valid security result. If the bundle does not have a 2266 BAB, then the bundle MUST be discarded and processed no further; a 2267 bundle status report indicating the authentication failure MAY be 2268 generated. 2270 No received bundles SHALL be required to have a PIB; if a received 2271 bundle does have a PIB, however, the PIB can be ignored unless the 2272 receiving node is the PIB-dest, in which case the PIB MUST be 2273 verified. 2275 No received bundles SHALL be required to have a PCB; if a received 2276 bundle does have a PCB, however, the PCB can be ignored unless the 2277 receiving node is the PCB-dest, in which case the PCB MUST be 2278 processed. If processing of a PCB yields a PIB, that PIB SHALL be 2279 processed by the node according to the node's security policy. 2281 A PIB SHALL NOT be added to a bundle before sourcing or forwarding 2282 it. 2284 A PCB SHALL NOT be added to a bundle before sourcing or forwarding 2285 it. 2287 A BAB MUST always be added to a bundle before that bundle is 2288 forwarded. 2290 If a destination node receives a bundle that has a PIB-dest but 2291 the value in that PIB-dest is not the EID of the destination node, 2292 the bundle SHALL be delivered at that destination node. 2294 If a destination node receives a bundle that has an ESB-dest but 2295 the value in that ESB-dest is not the EID of the destination node, 2296 the bundle SHALL be delivered at that destination node. 2298 If a received bundle does not satisfy the node's security policy 2299 for any reason, then the bundle MUST be discarded and processed no 2300 further; in this case, a bundle deletion status report (see the 2301 Bundle Protocol [DTNBP]) indicating the failure MAY be generated. 2303 7. Security Considerations 2305 If a BAB ciphersuite uses digital signatures but doesn't include the 2306 security destination (which for a BAB is the next host), then this 2307 allows the bundle to be sent to some node other than the intended 2308 adjacent node. Because the BAB will still authenticate, the 2309 receiving node may erroneously accept and forward the bundle. When 2310 asymmetric BAB ciphersuites are used, the security destination field 2311 SHOULD therefore be included in the BAB. 2313 If a bundle's PIB-dest is not the same as its destination, then some 2314 node other than the destination (the node identified as the PIB-dest) 2315 is expected to validate the PIB security result while the bundle is 2316 en route. However, if for some reason the PIB is not validated, 2317 there is no way for the destination to become aware of this. 2318 Typically, a PIB-dest will remove the PIB from the bundle after 2319 verifying the PIB and before forwarding it. However, if there is a 2320 possibility that the PIB will also be verified at a downstream node, 2321 the PIB-dest will leave the PIB in the bundle. Therefore, if a 2322 destination receives a bundle with a PIB that has a PIB-dest (which 2323 isn't the destination), this may, but does not necessarily, indicate 2324 a possible problem. 2326 If a bundle is fragmented after being forwarded by its PIB-source but 2327 before being received by its PIB-dest, the payload in the bundle MUST 2328 be reassembled before validating the PIB security result in order for 2329 the security result to validate correctly. Therefore, if the PIB- 2330 dest is not capable of performing payload reassembly, its utility as 2331 a PIB-dest will be limited to validating only those bundles that have 2332 not been fragmented since being forwarded from the PIB-source. 2333 Similarly, if a bundle is fragmented after being forwarded by its 2334 PIB-source but before being received by its PIB-dest, all fragments 2335 MUST be received at that PIB-dest in order for the bundle payload to 2336 be able to be reassembled. If not all fragments are received at the 2337 PIB-dest node, the bundle will not be able to be authenticated, and 2338 will therefore never be forwarded by this PIB-dest node. 2340 Specification of a security-destination other than the bundle 2341 destination creates a routing requirement that the bundle somehow be 2342 directed to the security-destination node on its way to the final 2343 destination. This requirement is presently private to the 2344 ciphersuite, since routing nodes are not required to implement 2345 security processing. 2347 8. Conformance 2349 As indicated above, this document describes both BSP and 2350 ciphersuites. A conformant implementation MUST implement both BSP 2351 support and the four ciphersuites described in Section 4. It MAY 2352 also support other ciphersuites. 2354 Implementations that support BSP but not all four mandatory 2355 ciphersuites may claim only "restricted compliance" with this 2356 specification, even if they provide other ciphersuites. 2358 All implementations are strongly RECOMMENDED to provide at least a 2359 BAB ciphersuite. A relay node, for example, might not deal with end- 2360 to-end confidentiality and data integrity but it SHOULD exclude 2361 unauthorized traffic and perform hop-by-hop bundle verification. 2363 9. IANA Considerations 2365 None at this time. If the bundle protocol becomes a standards track 2366 protocol, then we may want to consider having IANA establish a 2367 register of block types, and in particular for this specification a 2368 separate register of ciphersuite specifications. 2370 10. References 2372 10.1. Normative References 2374 [DTNBP] Scott, K. and S. Burleigh, "Bundle Protocol 2375 Specification", RFC 5050, November 2007. 2377 [DTNMD] Symington, S., "Delay-Tolerant Networking Metadata 2378 Extension Block", 2379 draft-irtf-dtnrg-bundle-metadata-block-00.txt , June 2007. 2381 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2382 Hashing for Message Authentication", RFC 2104, 2383 February 1997. 2385 [RFC2119] Bradner, S. and J. Reynolds, "Key words for use in RFCs to 2386 Indicate Requirement Levels", RFC 2119, October 1997. 2388 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 2389 X.509 Public Key Infrastructure Certificate and 2390 Certificate Revocation List (CRL) Profile", RFC 3280, 2391 April 2002. 2393 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 2394 Algorithms", RFC 3370, August 2002. 2396 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 2397 Algorithms and Identifiers for RSA Cryptography for use in 2398 the Internet X.509 Public Key Infrastructure Certificate 2399 and Certificate Revocation List (CRL) Profile", RFC 4055, 2400 June 2005. 2402 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 2403 (GCM) in IPsec Encapsulating Security Payload (ESP)", 2404 RFC 4106, June 2005. 2406 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 2407 RFC 3852, July 2004. 2409 10.2. Informative References 2411 [DTNRB] Symington, S., "Delay-Tolerant Network Retransmission 2412 Block", 2413 draft-irtf-dtnrg-bundle-retrans-00.txt, work-in-progress, 2414 April 2007. 2416 [DTNarch] Cerf, V., Burleigh, S., Durst, R., Fall, K., Hooke, A., 2417 Scott, K., Torgerson, L., and H. Weiss, "Delay-Tolerant 2418 Network Architecture", RFC 4838, April 2007. 2420 [DTNsecOver] 2421 Farrell, S., Symington, S., Weiss, H., and P. Lovell, 2422 "Delay-Tolerant Networking Security Overview", 2423 draft-irtf-dtnrg-sec-overview-06.txt, work-in-progress, 2424 March 2009. 2426 [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated 2427 Encryption in the Cryptographic Message Syntax (CMS)", 2428 RFC 5084, November 2007. 2430 Authors' Addresses 2432 Susan Flynn Symington 2433 The MITRE Corporation 2434 7515 Colshire Drive 2435 McLean, VA 22102 2436 US 2438 Phone: +1 (703) 983-7209 2439 Email: susan@mitre.org 2440 URI: http://mitre.org/ 2442 Stephen Farrell 2443 Trinity College Dublin 2444 Distributed Systems Group 2445 Department of Computer Science 2446 Trinity College 2447 Dublin 2 2448 Ireland 2450 Phone: +353-1-608-1539 2451 Email: stephen.farrell@cs.tcd.ie 2453 Howard Weiss 2454 SPARTA, Inc. 2455 7110 Samuel Morse Drive 2456 Columbia, MD 21046 2457 US 2459 Phone: +1-443-430-8089 2460 Email: hsw@sparta.com 2462 Peter Lovell 2463 SPARTA, Inc. 2464 7110 Samuel Morse Drive 2465 Columbia, MD 21046 2466 US 2468 Phone: +1-443-430-8052 2469 Email: peter.lovell@sparta.com