idnits 2.17.1 draft-irtf-dtnrg-bundle-security-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (March 11, 2011) is 4757 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-bundle-metadata-block-00 == Outdated reference: A later version (-02) exists of draft-irtf-dtnrg-iana-bp-registries-00 == Outdated reference: A later version (-12) exists of draft-irtf-dtnrg-bundle-previous-hop-block-11 -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 0 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 Intended status: Experimental S. Farrell 5 Expires: September 12, 2011 Trinity College Dublin 6 H. Weiss 7 P. Lovell 8 SPARTA, Inc. 9 March 11, 2011 11 Bundle Security Protocol Specification 12 draft-irtf-dtnrg-bundle-security-19 14 Abstract 16 This document defines the bundle security protocol, which provides 17 data integrity and confidentiality services for the bundle protocol. 18 Separate capabilities are provided to protect the bundle payload and 19 additional data that may be included within the bundle. We also 20 describe various security considerations including some policy 21 options. 23 This document is a product of the Delay Tolerant Networking Research 24 Group and has been reviewed by that group. No objections to its 25 publication as an RFC were raised. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 12, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1. Related Documents . . . . . . . . . . . . . . . . . . . . 5 75 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 76 2. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 8 77 2.1. Abstract Security Block . . . . . . . . . . . . . . . . . 9 78 2.2. Bundle Authentication Block . . . . . . . . . . . . . . . 13 79 2.3. Payload Integrity Block . . . . . . . . . . . . . . . . . 14 80 2.4. Payload Confidentiality Block . . . . . . . . . . . . . . 15 81 2.5. Extension Security Block . . . . . . . . . . . . . . . . . 19 82 2.6. Parameters and Result Fields . . . . . . . . . . . . . . . 21 83 2.7. Key Transport . . . . . . . . . . . . . . . . . . . . . . 23 84 2.8. PIB and PCB combinations . . . . . . . . . . . . . . . . . 23 85 3. Security Processing . . . . . . . . . . . . . . . . . . . . . 26 86 3.1. Nodes as policy enforcement points . . . . . . . . . . . . 26 87 3.2. Processing order of security blocks . . . . . . . . . . . 26 88 3.3. Security Regions . . . . . . . . . . . . . . . . . . . . . 29 89 3.4. Canonicalisation of bundles . . . . . . . . . . . . . . . 31 90 3.5. Endpoint ID confidentiality . . . . . . . . . . . . . . . 37 91 3.6. Bundles received from other nodes . . . . . . . . . . . . 37 92 3.7. The At-Most-Once-Delivery Option . . . . . . . . . . . . . 39 93 3.8. Bundle Fragmentation and Reassembly . . . . . . . . . . . 40 94 3.9. Reactive fragmentation . . . . . . . . . . . . . . . . . . 40 95 3.10. Attack Model . . . . . . . . . . . . . . . . . . . . . . . 41 96 4. Mandatory Ciphersuites . . . . . . . . . . . . . . . . . . . . 42 97 4.1. BAB-HMAC . . . . . . . . . . . . . . . . . . . . . . . . . 42 98 4.2. PIB-RSA-SHA256 . . . . . . . . . . . . . . . . . . . . . . 43 99 4.3. PCB-RSA-AES128-PAYLOAD-PIB-PCB . . . . . . . . . . . . . . 44 100 4.4. ESB-RSA-AES128-EXT . . . . . . . . . . . . . . . . . . . . 48 101 5. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 51 102 6. Default Security Policy . . . . . . . . . . . . . . . . . . . 52 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 54 104 8. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 56 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 106 9.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . . 57 107 9.2. Ciphersuite Numbers . . . . . . . . . . . . . . . . . . . 57 108 9.3. Ciphersuite Flags . . . . . . . . . . . . . . . . . . . . 58 109 9.4. Parameters and Results . . . . . . . . . . . . . . . . . . 58 110 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 111 10.1. Normative References . . . . . . . . . . . . . . . . . . . 60 112 10.2. Informative References . . . . . . . . . . . . . . . . . . 60 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 115 1. Introduction 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 This document defines security features for the bundle protocol 122 [DTNBP] intended for use in delay tolerant networks, in order to 123 provide Delay-Tolerant Networking (DTN) security services. 125 The bundle protocol is used in DTNs which overlay multiple networks, 126 some of which may be challenged by limitations such as intermittent 127 and possibly unpredictable loss of connectivity, long or variable 128 delay, asymmetric data rates, and high error rates. The purpose of 129 the bundle protocol is to support interoperability across such 130 stressed networks. The bundle protocol is layered on top of 131 underlay-network-specific convergence layers, on top of network- 132 specific lower layers, to enable an application in one network to 133 communicate with an application in another network, both of which are 134 spanned by the DTN. 136 Security will be important for the bundle protocol. The stressed 137 environment of the underlying networks over which the bundle protocol 138 will operate makes it important for the DTN to be protected from 139 unauthorized use, and this stressed environment poses unique 140 challenges for the mechanisms needed to secure the bundle protocol. 141 Furthermore, DTNs may very likely be deployed in environments where a 142 portion of the network might become compromised, posing the usual 143 security challenges related to confidentiality, integrity and 144 availability. 146 Different security processing applies to the payload and extension 147 blocks that may accompany it in a bundle, and different rules apply 148 to various extension blocks. 150 This document describes both the base Bundle Security Protocol (BSP) 151 and a set of mandatory ciphersuites. A ciphersuite is a specific 152 collection of various cryptographic algorithms and implementation 153 rules that are used together to provide certain security services. 155 The Bundle Security Protocol applies, by definition, only to those 156 nodes that implement it, known as "security-aware" nodes. There MAY 157 be other nodes in the DTN that do not implement BSP. All nodes can 158 interoperate with the exception that BSP security operations can only 159 happen at security-aware nodes. 161 1.1. Related Documents 163 This document is best read and understood within the context of the 164 following other DTN documents: 166 The Delay-Tolerant Network Architecture [DTNarch] defines the 167 architecture for delay-tolerant networks, but does not discuss 168 security at any length. 170 The DTN Bundle Protocol [DTNBP] defines the format and processing 171 of the blocks used to implement the bundle protocol, excluding the 172 security-specific blocks defined here. 174 1.2. Terminology 176 We introduce the following terminology for purposes of clarity: 178 source - the bundle node from which a bundle originates 180 destination - the bundle node to which a bundle is ultimately 181 destined 183 forwarder - the bundle node that forwarded the bundle on its most 184 recent hop 186 intermediate receiver or "next hop" - the neighboring bundle node 187 to which a forwarder forwards a bundle. 189 path - the ordered sequence of nodes through which a bundle passes 190 on its way from source to destination 192 In the figure below, which is adapted from figure 1 in the Bundle 193 Protocol Specification, four bundle nodes (denoted BN1, BN2, BN3, and 194 BN4) reside above some transport layer(s). Three distinct transport 195 and network protocols (denoted T1/N1, T2/N2, and T3/N3) are also 196 shown. 198 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 199 | BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 | 200 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 201 | T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 | 202 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 203 | N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 | 204 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 205 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 206 +-----------+ +------------+ +-------------+ +-----------+ 207 | | | | 208 |<-- An Internet --->| |<--- An Internet --->| 209 | | | | 211 BN = "Bundle Node" as defined in the Bundle Protocol Specification 213 Figure 1: Bundle Nodes Sit at the Application layer of the Internet 214 Model 216 Bundle node BN1 originates a bundle that it forwards to BN2. BN2 217 forwards the bundle to BN3, and BN3 forwards the bundle to BN4. BN1 218 is the source of the bundle and BN4 is the destination of the bundle. 219 BN1 is the first forwarder, and BN2 is the first intermediate 220 receiver; BN2 then becomes the forwarder, and BN3 the intermediate 221 receiver; BN3 then becomes the last forwarder, and BN4 the last 222 intermediate receiver, as well as the destination. 224 If node BN2 originates a bundle (for example, a bundle status report 225 or a custodial signal), which is then forwarded on to BN3, and then 226 to BN4, then BN2 is the source of the bundle (as well as being the 227 first forwarder of the bundle) and BN4 is the destination of the 228 bundle (as well as being the final intermediate receiver). 230 We introduce the following security-specific DTN terminology: 232 security-source - a bundle node that adds a security block to a 233 bundle 235 security-destination - a bundle node that processes a security 236 block of a bundle 238 security path - the ordered sequence of security-aware nodes 239 through which a bundle passes on its way from the security-source 240 to the security-destination 242 Referring to Figure 1 again: 244 If the bundle that originates at BN1 as source is given a security 245 block by BN1, then BN1 is the security-source of this bundle with 246 respect to that security block, as well as being the source of the 247 bundle. 249 If the bundle that originates at BN1 as source is given a security 250 block by BN2, then BN2 is the security-source of this bundle with 251 respect to that security block, even though BN1 is the source. 253 If the bundle that originates at BN1 as source is given a security 254 block by BN1 that is intended to be processed by BN3, then BN1 is the 255 security-source and BN3 is the security destination with respect to 256 this security block. The security path for this block is BN1 to BN3. 258 A bundle MAY have multiple security blocks. The security-source of a 259 bundle with respect to a given security block in the bundle MAY be 260 the same as or different from the security-source of the bundle with 261 respect to a different security block in the bundle. Similarly, the 262 security-destination of a bundle with respect to each of that 263 bundle's security blocks MAY be the same or different. Therefore the 264 security paths for various blocks MAY be and often will be different. 266 If the bundle that originates at BN1 as source is given a security 267 block by BN1 that is intended to be processed by BN3, and BN2 adds a 268 security block with security-destination BN4, the security paths for 269 the two blocks overlap but not completely. This problem is discussed 270 further in Section 3.3. 272 As required in [DTNBP], forwarding nodes MUST transmit blocks in a 273 bundle in the same order in which they were received. This 274 requirement applies to all DTN nodes, not just ones which implement 275 security processing. Blocks in a bundle MAY be added or deleted 276 according to the applicable specification, but those blocks which are 277 both received and transmitted MUST be transmitted in the same order 278 that they were received. 280 If a node is not security-aware then it forwards the security blocks 281 in the bundle unchanged unless the bundle's block processing flags 282 specify otherwise. If a network has some nodes that are not 283 security-aware then the block processing flags SHOULD be set such 284 that security blocks are not discarded at those nodes solely because 285 they can not be processed there. Except for this, the non-security- 286 aware nodes are transparent relay points and are invisible as far as 287 security processing is concerned. 289 The block sequence also indicates the order in which certain 290 significant actions have affected the bundle, and therefore the 291 sequence in which actions MUST occur in order to produce the bundle 292 at its destination. 294 2. Security Blocks 296 There are four types of security block that MAY be included in a 297 bundle. These are the Bundle Authentication Block (BAB), the Payload 298 Integrity Block (PIB), the Payload Confidentiality Block (PCB) and 299 the Extension Security Block (ESB). 301 The BAB is used to assure the authenticity and integrity of the 302 bundle along a single hop from forwarder to intermediate receiver. 303 Since security blocks are only processed at security-aware nodes, 304 a "single hop" from a security-aware forwarder to the next 305 security-aware intermediate receiver might be more than one actual 306 hop. This situation is discussed further below Section 2.2. 308 The PIB is used to assure the authenticity and integrity of the 309 payload from the PIB security-source, which creates the PIB, to 310 the PIB security-destination, which verifies the PIB 311 authenticator. The authentication information in the PIB MAY (if 312 the ciphersuite allows) be verified by any node in between the PIB 313 security-source and the PIB security-destination that has access 314 to the cryptographic keys and revocation status information 315 required to do so. 317 Since a BAB protects a bundle on a "hop-by-hop" basis and other 318 security blocks MAY be protecting over several hops or end-to-end, 319 whenever both are present the BAB MUST form the "outer" layer of 320 protection - that is, the BAB MUST always be calculated and added 321 to the bundle after all other security blocks have been calculated 322 and added to the bundle. 324 The PCB indicates that the payload has been encrypted, in whole or 325 in part, at the PCB security-source in order to protect the bundle 326 content while in transit to the PCB security-destination. 328 PIB and PCB protect the payload and are regarded as "payload- 329 related" for purposes of the security discussion in this document. 330 Other blocks are regarded as "non-payload" blocks. Of course, the 331 primary block is unique and has separate rules. 333 The ESB provides security for non-payload blocks in a bundle. ESB 334 therefore is not applied to PIB or PCBs, and of course is not 335 appropriate for either the payload block or primary block. 337 Each of the security blocks uses the Canonical Bundle Block Format as 338 defined in the Bundle Protocol Specification. That is, each security 339 block is comprised of the following elements: 341 - Block type code 343 - Block processing control flags 345 - Block EID reference list (OPTIONAL) 347 - Block data length 349 - Block-type-specific data fields 351 Since the four security blocks have most fields in common, we can 352 shorten the description of the Block-type-specific data fields of 353 each security block if we first define an abstract security block 354 (ASB) and then specify each of the real blocks in terms of the fields 355 which are present/absent in an ASB. Note that no bundle ever 356 contains an actual ASB, which is simply a specification artifact. 358 2.1. Abstract Security Block 360 Many of the fields below use the "SDNV" type defined in [DTNBP]. 361 SDNV stands for Self-Delimiting Numeric Value. 363 An ASB consists of the following mandatory and optional fields: 365 - Block-type code (one byte) - as in all bundle protocol blocks 366 except the primary bundle block. The block types codes for the 367 security blocks are: 369 BundleAuthenticationBlock - BAB: 0x02 371 PayloadIntegrityBlock - PIB: 0x03 373 PayloadConfidentialityBlock - PCB: 0x04 375 ExtensionSecurityBlock - ESB: 0x09 377 - Block processing control flags (SDNV) - defined as in all bundle 378 protocol blocks except the primary bundle block (as described in the 379 Bundle Protocol [DTNBP]). SDNV encoding is described in the bundle 380 protocol. There are no general constraints on the use of the block 381 processing flags, and some specific requirements are discussed later. 383 - EID references - composite field defined in [DTNBP] containing 384 references to one or two EIDs. Presence of the EID-reference field 385 is indicated by the setting of the "block contains an EID-reference 386 field" (EID_REF) bit of the block processing control flags. If one 387 or more references is present, flags in the ciphersuite ID field, 388 described below, specify which. 390 If no EID fields are present then the composite field itself MUST be 391 omitted entirely and the EID_REF bit MUST be unset. A count field of 392 zero is not permitted. 394 The possible EIDs are: 396 - (OPTIONAL) Security-source - specifies the security source for 397 the block. If this is omitted, then the source of the bundle is 398 assumed to be the security-source unless otherwise indicated. 400 - (OPTIONAL) Security-destination - specifies the security 401 destination for the block. If this is omitted, then the 402 destination of the bundle is assumed to be the security- 403 destination unless otherwise indicated. 405 If two EIDs are present, security-source is first and security- 406 destination comes second. 408 - Block data length (SDNV) - as in all bundle protocol blocks except 409 the primary bundle block. SDNV encoding is described in the bundle 410 protocol. 412 - Block-type-specific data fields as follows: 414 - Ciphersuite ID (SDNV) 416 - Ciphersuite flags (SDNV) 418 - (OPTIONAL) Correlator - when more than one related block is 419 inserted then this field MUST have the same value in each related 420 block instance. This is encoded as an SDNV. See note in 421 Section 3.8 with regard to correlator values in bundle fragments. 423 - (OPTIONAL) Ciphersuite parameters - compound field of next two 424 items 426 - Ciphersuite parameters length - specifies the length of the 427 following Ciphersuite parameters data field and is encoded as 428 an SDNV. 430 - Ciphersuite parameters data - parameters to be used with the 431 ciphersuite in use, e.g. a key identifier or initialization 432 vector (IV). See Section 2.6 for a list of potential 433 parameters and their encoding rules. The particular set of 434 parameters that are included in this field are defined as part 435 of the ciphersuite specification. 437 - (OPTIONAL) Security result - compound field of next two items 439 - Security result length - contains the length of the next 440 field and is encoded as an SDNV. 442 - Security result data - contains the results of the 443 appropriate ciphersuite-specific calculation (e.g., a 444 signature, MAC or ciphertext block key). 446 Although the diagram hints at a 32-bit layout this is purely for the 447 purpose of exposition. Except for the "type" field, all fields are 448 variable in length. 450 +----------------+----------------+----------------+----------------+ 451 | type | flags (SDNV) | EID ref list(comp) | 452 +----------------+----------------+----------------+----------------+ 453 | length (SDNV) | ciphersuite (SDNV) | 454 +----------------+----------------+----------------+----------------+ 455 | ciphersuite flags (SDNV) | correlator (SDNV) | 456 +----------------+----------------+----------------+----------------+ 457 |params len(SDNV)| ciphersuite params data | 458 +----------------+----------------+----------------+----------------+ 459 |res-len (SDNV) | security result data | 460 +----------------+----------------+----------------+----------------+ 462 Figure 2: Abstract Security Block Structure 464 Some ciphersuites are specified in Section 4, which also specifies 465 the rules which MUST be satisfied by ciphersuite specifications. 466 Additional ciphersuites MAY be defined in separate specifications. 467 Ciphersuite IDs not specified are reserved. Implementations of the 468 bundle security protocol decide which ciphersuites to support, 469 subject to the requirements of Section 4. It is RECOMMENDED that 470 implementations that allow additional ciphersuites permit ciphersuite 471 ID values at least up to and including 127, and they MAY decline to 472 allow larger ID values. 474 The structure of the ciphersuite flags field is shown in Figure 3. 475 In each case the presence of an optional field is indicated by 476 setting the value of the corresponding flag to one. A value of zero 477 indicates the corresponding optional field is missing. Presently 478 there are five flags defined for the field and for convenience these 479 are shown as they would be extracted from a single-byte SDNV. Future 480 additions may cause the field to grow to the left so, as with the 481 flags fields defined in [DTNBP], the description below numbers the 482 bit positions from the right rather than the standard RFC definition 483 which numbers bits from the left. 485 src - bit 4 indicates whether the EID-reference field of the ASB 486 contains the optional reference to the security-source. 488 dest - bit 3 indicates whether the EID-reference field of the ASB 489 contains the optional reference to the security-destination. 491 parm - bit 2 indicates whether the ciphersuite-parameters-length 492 and ciphersuite parameters data fields are present or not. 494 corr - bit 1 indicates whether or not the ASB contains an optional 495 correlator. 497 res - bit 0 indicates whether or not the ASB contains the security 498 result length and security result data fields. 500 bits 5-6 are reserved for future use. 502 Bit Bit Bit Bit Bit Bit Bit 503 6 5 4 3 2 1 0 504 +-----+-----+-----+-----+-----+-----+-----+ 505 | reserved | src |dest |parm |corr |res | 506 +-----+-----+-----+-----+-----+-----+-----+ 508 Figure 3: Ciphersuite Flags 510 A little bit more terminology: if the block is a PIB then when we 511 refer to the "PIB-source", we mean the security source for the PIB as 512 represented by the EID reference in the EID-references field. 513 Similarly we may refer to the PCB-dest, meaning the security- 514 destination of the PCB, again as represented by an EID reference. 515 For example, referring to Figure 1 again, if the bundle that 516 originates at BN1 as source is given a Confidentiality Block (PCB) by 517 BN1 that is protected using a key held by BN3 and it is given a 518 Payload Integrity Block (PIB) by BN1, then BN1 is both the PCB-source 519 and the PIB-source of the bundle, and BN3 is the PCB-dest of the 520 bundle. 522 The correlator field is used to associate several related instances 523 of a security block. This can be used to place a BAB that contains 524 the ciphersuite information at the "front" of a (probably large) 525 bundle, and another correlated BAB that contains the security result 526 at the "end" of the bundle. This allows even very memory-constrained 527 nodes to be able to process the bundle and verify the BAB. There are 528 similar use cases for multiple related instances of PIB and PCB as 529 will be seen below. 531 The ciphersuite specification MUST make it clear whether or not 532 multiple block instances are allowed, and if so, under what 533 conditions. Some ciphersuites can of course leave flexibility to the 534 implementation, whereas others might mandate a fixed number of 535 instances. 537 For convenience, we use the term "first block" to refer to the 538 initial block in a group of correlated blocks, or to the single block 539 if there are no others in the set. Obviously there can be several 540 unrelated groups in a bundle, each containing only one block or more 541 than one, and each has its own "first block". 543 2.2. Bundle Authentication Block 545 In this section we describe typical BAB field values for two 546 scenarios - where a single instance of the BAB contains all the 547 information and where two related instances are used, one "up front" 548 which contains the ciphersuite and another following the payload 549 which contains the security result (e.g. a MAC). 551 For the case where a single BAB is used: 553 The block-type code field value MUST be 0x02. 555 The block processing control flags value can be set to whatever 556 values are required by local policy. Ciphersuite designers should 557 carefully consider the effect of setting flags that either discard 558 the block or delete the bundle in the event that this block cannot 559 be processed. 561 The ciphersuite ID MUST be documented as a hop-by-hop 562 authentication-ciphersuite which requires one instance of the BAB. 564 The correlator field MUST NOT be present. 566 The ciphersuite parameters field MAY be present, if so specified 567 in the ciphersuite specification. 569 An EID reference to the security-source MAY be present. The 570 security-source can also be specified as part of key information 571 described in Section 2.6 or another block such as the Previous Hop 572 Insertion Block [PHIB]. The security-source might also be 573 inferred from some implementation-specific means such as the 574 convergence layer. 576 An EID reference to the security-destination MAY be present and is 577 useful to ensure that the bundle has been forwarded to the correct 578 next-hop node. 580 The security result MUST be present as it is effectively the 581 "output" from the ciphersuite calculation (e.g. the MAC or 582 signature) applied to the (relevant parts of) the bundle (as 583 specified in the ciphersuite definition). 585 For the case using two related BAB instances, the first instance is 586 as defined above, except the ciphersuite ID MUST be documented as a 587 hop-by-hop authentication ciphersuite that requires two instances of 588 the BAB. In addition, the correlator MUST be present and the 589 security result length and security result fields MUST be absent. 590 The second instance of the BAB MUST have the same correlator value 591 present and MUST contain security result length and security result 592 data fields. The other optional fields MUST NOT be present. 593 Typically, this second instance of a BAB will be the last block of 594 the bundle. 596 The details of key transport for BAB are specified by the particular 597 ciphersuite. In the absence of conflicting requirements, the 598 following should be noted by implementors: 600 - the key information item Section 2.6 is OPTIONAL, and if not 601 provided then the key SHOULD be inferred from the source-destination 602 tuple, being the previous key used, a key created from a key- 603 derivation function, or a pre-shared key 605 - if all the nodes are security-aware, the capabilities of the 606 underlying convergence layer might be useful for identifying the 607 security-source 609 - depending upon the key mechanism used, bundles can be signed by the 610 sender, or authenticated for one or more recipients, or both. 612 2.3. Payload Integrity Block 614 A PIB is an ASB with the following additional restrictions: 616 The block type code value MUST be 0x03. 618 The block processing control flags value can be set to whatever 619 values are required by local policy. Ciphersuite designers should 620 carefully consider the effect of setting flags that either discard 621 the block or delete the bundle in the event that this block cannot 622 be processed. 624 The ciphersuite ID MUST be documented as an end-to-end 625 authentication-ciphersuite or as an end-to-end error-detection- 626 ciphersuite. 628 The correlator MUST be present if the ciphersuite requires more 629 than one related instance of a PIB be present in the bundle. The 630 correlator MUST NOT be present if the ciphersuite only requires 631 one instance of the PIB in the bundle. 633 The ciphersuite parameters field MAY be present. 635 An EID reference to the security-source MAY be present. The 636 security-source can also be specified as part of key information 637 described in Section 2.6. 639 An EID reference to the security-destination MAY be present. 641 The security result is effectively the "output" from the 642 ciphersuite calculation (e.g. the MAC or signature) applied to the 643 (relevant parts of) the bundle. As in the case of the BAB, this 644 field MUST be present if the correlator is absent. If more than 645 one related instance of the PIB is required then this is handled 646 in the same way as described for the BAB above. 648 The ciphersuite MAY process less than the entire original bundle 649 payload. This might be because it is defined to process some 650 subset of the bundle, or perhaps because the the current payload 651 is a fragment of an original bundle. For whatever reason, if the 652 ciphersuite processes less than the complete, original bundle 653 payload, the ciphersuite parameters of this block MUST specify 654 which bytes of the bundle payload are protected. 656 For some ciphersuites, (e.g. those using asymmetric keying to produce 657 signatures or those using symmetric keying with a group key), the 658 security information can be checked at any hop on the way to the 659 security destination that has access to the required keying 660 information. This possibility is further discussed in Section 3.6 661 below. 663 The use of a generally-available key is RECOMMENDED if custodial 664 transfer is employed and all nodes SHOULD verify the bundle before 665 accepting custody. 667 Most asymmetric PIB-ciphersuites will use the PIB-source to indicate 668 the signer and will not require the PIB-dest field because the key 669 needed to verify the PIB authenticator will be a public key 670 associated with the PIB-source. 672 2.4. Payload Confidentiality Block 674 A typical confidentiality ciphersuite will encrypt the payload using 675 a randomly generated bundle encrypting key (BEK) and will use a key 676 information item in the PCB security parameters to carry the BEK 677 encrypted with some long term key encryption key (KEK) or well-known 678 public key. If neither the destination nor security-destination 679 resolves the key to use for decryption, the key information item in 680 the ciphersuite parameters field can also be used to indicate the 681 decryption key with which the BEK can be recovered. If the bundle 682 already contains PIBs and/or PCBs these SHOULD also be encrypted 683 using this same BEK, as described just below for "super-encryption". 684 The encrypted block is encapsulated into a new PCB that replaces the 685 original block at the same place in the bundle. 687 It is strongly RECOMMENDED that a data integrity mechanism be used in 688 conjunction with confidentiality, and that encryption-only 689 ciphersuites NOT be used. AES-GCM satisfies this requirement. The 690 "authentication tag" or "integrity check value" is stored into 691 security-result rather than being appended to the payload as is 692 common in some protocols since, as described below, it is important 693 that there be no change in the size of the payload. 695 The payload is encrypted "in-place", that is, following encryption, 696 the payload block payload field contains ciphertext, not plaintext. 697 The payload block processing flags are unmodified. 699 The "in-place" encryption of payload bytes is to allow bundle payload 700 fragmentation and re-assembly, and custody transfer, to operate 701 without knowledge of whether or not encryption has occurred and, if 702 so, how many times. 704 Fragmentation and reassembly and custody transfer are adversely 705 affected by a change in size of the payload due to ambiguity about 706 what byte range of the original payload is actually in any particular 707 fragment. Ciphersuites SHOULD place any payload expansion, such as 708 authentication tags (integrity check values) and any padding 709 generated by a block-mode cipher, into an "integrity check value" 710 item in the security-result field (see Section 2.6) of the 711 confidentiality block. 713 Payload super-encryption is allowed; that is, encrypting a payload 714 that has already been encrypted, perhaps more than once. 715 Ciphersuites SHOULD define super-encryption such that, as well as re- 716 encrypting the payload, it also protects the parameters of earlier 717 encryption. Failure to do so may represent a vulnerability in some 718 circumstances. 720 Confidentiality is normally applied to the payload, and possibly to 721 additional blocks. It is RECOMMENDED to apply a Payload 722 Confidentiality ciphersuite to non-payload blocks only if these 723 SHOULD be super-encrypted with the payload. If super-encryption of 724 the block is not desired then protection of the block SHOULD be done 725 using the Extension Security Block mechanism rather than PCB. 727 Multiple related PCB instances are required if both the payload and 728 PIBs and PCBs in the bundle are to be encrypted. These multiple PCB 729 instances require correlators to associate them with each other since 730 the key information is provided only in the first PCB. 732 There are situations where more than one PCB instance is required but 733 the instances are not "related" in the sense which requires 734 correlators. One example is where a payload is encrypted for more 735 than one security-destination so as to be robust in the face of 736 routing uncertainties. In this scenario the payload is encrypted 737 using a BEK. Several PCBs contain the BEK encrypted using different 738 KEKs, one for each destination. These multiple PCB instances, are 739 not "related" and SHOULD NOT contain correlators. 741 The ciphersuite MAY apply different rules to confidentiality for non- 742 payload blocks. 744 A PCB is an ASB with the following additional restrictions: 746 The block type code value MUST be 0x04. 748 The block processing control flags value can be set to whatever 749 values are required by local policy, except that a PCB "first 750 block" MUST have the "replicate in every fragment" flag set. This 751 flag SHOULD NOT be set otherwise. Ciphersuite designers should 752 carefully consider the effect of setting flags that either discard 753 the block or delete the bundle in the event that this block cannot 754 be processed. 756 The ciphersuite ID MUST be documented as a confidentiality- 757 ciphersuite. 759 The correlator MUST be present if there is more than one related 760 PCB instance. The correlator MUST NOT be present if there are no 761 related PCB instances. 763 If a correlator is present, the key information MUST be placed in 764 the PCB "first block". 766 Any additional bytes generated as a result of encryption and/or 767 authentication processing of the payload SHOULD be placed in an 768 "integrity check value" field (see Section 2.6) in the security- 769 result of the first PCB. 771 The ciphersuite parameters field MAY be present. 773 An EID reference to the security-source MAY be present. The 774 security-source can also be specified as part of key information 775 described in Section 2.6. 777 An EID reference to the security-destination MAY be present. 779 The security result MAY be present and normally contains fields 780 such as an encrypted bundle encryption key, authentication tag or 781 the encrypted versions of bundle blocks other than the payload 782 block. 784 The ciphersuite MAY process less than the entire original bundle 785 payload, either because the current payload is a fragment of the 786 original bundle or just because it is defined to process some subset. 787 For whatever reason, if the ciphersuite processes less than the 788 complete, original bundle payload the "first" PCB MUST specify, as 789 part of the ciphersuite parameters, which bytes of the bundle payload 790 are protected. 792 PCB ciphersuites MUST specify which blocks are to be encrypted. The 793 specification MAY be flexible and be dependent upon block type, 794 security policy, various data values and other inputs but it MUST be 795 deterministic. The determination of whether a block is to be 796 encrypted or not MUST NOT be ambiguous. 798 As was the case for the BAB and PIB, if the ciphersuite requires more 799 than one instance of the PCB, then the "first block" MUST contain any 800 optional fields (e.g., security destination etc.) that apply to all 801 instances with this correlator. These MUST be contained in the first 802 instance and MUST NOT be repeated in other correlated blocks. Fields 803 that are specific to a particular instance of the PCB MAY appear in 804 that PCB. For example, security result fields MAY (and probably 805 will) be included in multiple related PCB instances, with each result 806 being specific to that particular block. Similarly, several PCBs 807 might each contain a ciphersuite parameters field with an IV specific 808 to that PCB instance. 810 Put another way: when confidentiality will generate multiple blocks, 811 it MUST create a "first" PCB with the required ciphersuite ID, 812 parameters etc. as specified above. Typically, this PCB will appear 813 early in the bundle. This "first" PCB contains the parameters that 814 apply to the payload and also to the other correlated PCBs. The 815 correlated PCBs follow the "first" PCB and MUST NOT repeat the 816 ciphersuite parameters, security-source, or security-destination 817 fields from the first PCB. These correlated PCBs need not follow 818 immediately after the "first" PCB, and probably will not do so. Each 819 correlated block, encapsulating an encrypted PIB or PCB, is at the 820 same place in the bundle as the original PIB or PCB. 822 A ciphersuite MUST NOT mix payload data and a non-payload block in a 823 single PCB. 825 Even if a to-be-encrypted block has the "discard" flag set, whether 826 or not the PCB's "discard" flag is set is an implementation/policy 827 decision for the encrypting node. (The "discard" flag is more 828 properly called the "discard if block cannot be processed" flag.) 830 Any existing EID-list in the to-be-encapsulated original block 831 remains exactly as-is, and is copied to become the EID-list for the 832 replacing block. The encapsulation process MUST NOT replace or 833 remove the existing EID-list entries. This is critically important 834 for correct updating of entries at the security-destination. 836 At the security-destination, either specific destination or the 837 bundle destination, the processes described above are reversed. The 838 payload is decrypted in-place using the salt, IV and key values in 839 the first PCB, including verification using the ICV. These values 840 are described below in Section 2.6. Each correlated PCB is also 841 processed at the same destination, using the salt and key values from 842 the first PCB and the block-specific IV item. The "encapsulated 843 block" item in the security-result is decrypted and validated, using 844 also the tag which SHOULD have been appended to the ciphertext of the 845 original block data. Assuming the validation succeeds, the resultant 846 plaintext, which is the entire content of the original block, 847 replaces the PCB at the same place in the bundle. The block type 848 reverts to that of the original block prior to encapsulation, and the 849 other block-specific data fields also return to their original 850 values. Implementors are cautioned that this "replacement" process 851 requires delicate stitchery, as the EID-list contents in the 852 decapsulated block are invalid. As noted above, the EID-list 853 references in the original block were preserved in the replacing PCB, 854 and will have been updated as necessary as the bundle has toured the 855 dtn. The references from the PCB MUST replace the references within 856 the EID-list of the newly-decapsulated block. Caveat implementor. 858 2.5. Extension Security Block 860 Extension security blocks provide protection for non-payload-related 861 portions of a bundle. ESBs MUST NOT be used for the primary block or 862 payload, including payload-related security blocks (PIBs and PCBs). 864 It is sometimes desirable to protect certain parts of a bundle in 865 ways other than those applied to the bundle payload. One such 866 example is bundle metadata that might specify the kind of data in the 867 payload but not the actual payload detail, as described in [DTNMD]. 869 ESBs are typically used to apply confidentiality protection. While 870 it is possible to create an integrity-only ciphersuite, the block 871 protection is not transparent and makes access to the data more 872 difficult. For simplicity, this discussion describes use of a 873 confidentiality ciphersuite. 875 The protection mechanisms in ESBs are similar to other security 876 blocks with two important differences: 878 - different key values are used (using same key as for payload 879 would defeat the purpose) 881 - the block is not encrypted or super-encrypted with the payload 883 A typical ESB ciphersuite will encrypt the extension block using a 884 randomly generated ephemeral key and will use the key information 885 item in the security parameters field to carry the key encrypted with 886 some long term key encryption key (KEK) or well-known public key. If 887 neither the destination nor security-destination resolves the key to 888 use for decryption, the key information item in the ciphersuite 889 parameters field can be used also to indicate the decryption key with 890 which the BEK can be recovered. 892 It is strongly RECOMMENDED that a data integrity mechanism be used in 893 conjunction with confidentiality, and that encryption-only 894 ciphersuites NOT be used. AES-GCM satisfies this requirement. 896 The ESB is placed in the bundle in the same position as the block 897 being protected. That is, the entire original block is processed 898 (encrypted, etc) and encapsulated in a "replacing" ESB-type block, 899 and this appears in the bundle at the same sequential position as the 900 original block. The processed data is placed in the security-result 901 field. 903 The process is reversed at the security destination with the 904 recovered plaintext block replacing the ESB that had encapsulated it. 905 Processing of EID-list entries, if any, is described above in 906 Section 2.4 and this MUST be followed in order to correctly recover 907 EIDs. 909 An ESB is an ASB with the following additional restrictions: 911 Block type is 0x09. 913 Ciphersuite flags indicate which fields are present in this block. 914 Ciphersuite designers should carefully consider the effect of 915 setting flags that either discard the block or delete the bundle 916 in the event that this block cannot be processed. 918 EID references MUST be stored in the EID reference list. 920 Security-source MAY be present. The security-source can also be 921 specified as part of key information described in Section 2.6. If 922 neither is present then the bundle-source is used as the security- 923 source. 925 Security-destination MAY be present. If not present, then the 926 bundle-destination is used as the security-destination. 928 The security-parameters MAY optionally contain a block-type field to 929 indicate the type of the encapsulated block. Since this replicates a 930 field in the encrypted portion of the block, it is a slight security 931 risk and its use is therefore OPTIONAL. 933 2.6. Parameters and Result Fields 935 Various ciphersuites include several items in the security-parameters 936 and/or security-result fields. Which items MAY appear is defined by 937 the particular ciphersuite description. A ciphersuite MAY support 938 several instances of the same type within a single block. 940 Each item is represented as type-length-value. Type is a single byte 941 indicating which item this is. Length is the count of data bytes to 942 follow, and is an SDNV-encoded integer. Value is the data content of 943 the item. 945 Item types are 947 0: reserved 949 1: initialization vector (IV) 951 2: reserved 953 3: key information 955 4: fragment range (offset and length as a pair of SDNVs) 957 5: integrity signature 959 6: reserved 961 7: salt 962 8: PCB integrity check value (ICV) 964 9: reserved 966 10: encapsulated block 968 11: block type of encapsulated block 970 12 - 191: reserved 972 192 - 250: private use 974 251 - 255: reserved 976 The folowing descriptions apply to usage of these items for all 977 ciphersuites. Additional characteristics are noted in the discussion 978 for specific suites. 980 - initialization vector(IV): random value, typically eight to 981 sixteen bytes 983 - key information: key material encoded or protected by the key 984 management system, and used to transport an ephemeral key 985 protected by a long-term key. This item is discussed further 986 below in Section 2.7 988 - fragment range: pair of SDNV values (offset then length) 989 specifying the range of payload bytes to which a particular 990 operation applies. This is termed "fragment range" since that is 991 its typical use, even though sometimes it describes a subset range 992 that is not a fragment. The offset value MUST be the offset 993 within the original bundle, which might not be the offset within 994 the current bundle if the current bundle is already a fragment 996 - integrity signature: result of BAB or PIB digest or signing 997 operation. This item is discussed further below in Section 2.7 999 - salt: an IV-like value used by certain confidentiality suites 1001 - PCB integrity check value(ICV): output from certain 1002 confidentiality ciphersuite operations to be used at the 1003 destination to verify that the protected data has not been 1004 modified 1006 - encapsulated block: result of confidentiality operation on 1007 certain blocks, contains the ciphertext of the block and MAY also 1008 contain an integrity check value appended to the ciphertext; MAY 1009 also contain padding if required by the encryption mode; used for 1010 non-payload blocks only 1012 - block type of encapsulated block: block type code for a block 1013 that has been encapsulated in ESB 1015 2.7. Key Transport 1017 This specification endeavours to maintain separation between the 1018 security protocol and key management. However, these two interact in 1019 the transfer of key information, etc., from security-source to 1020 security-destination. The intent of the separation is to facilitate 1021 use of a variety of key management systems without a necessity to 1022 tailor a ciphersuite to each individually. 1024 The key management process deals with such things as long-term keys, 1025 specifiers for long-term keys, certificates for long-term keys and 1026 integrity signatures using long-term keys. The ciphersuite itself 1027 SHOULD NOT require a knowledge of these, and separation is improved 1028 if it treats these as opaque entities, to be handled by the key 1029 management process. 1031 The key management process deals specifically with the content of two 1032 of the items defined above in Section 2.6:- key information (item 1033 type 3) and integrity signature (item type 5). The ciphersuite MUST 1034 define the details and format for these items. To facilitate 1035 interoperability, it is strongly RECOMMENDED that the implementations 1036 use the appropriate definitions from Cryptographic Message Syntax 1037 (CMS) [RFC5652] and related RFCs. 1039 Many situations will require several pieces of key information. 1040 Again, ciphersuites MUST define whether they accept these packed into 1041 a single key information item and/or separated into multiple 1042 instances of key information. For interoperability, it is 1043 RECOMMENDED that ciphersuites accept these packed into a single key- 1044 information item, and that they MAY additionally choose to accept 1045 them sent as separate items. 1047 2.8. PIB and PCB combinations 1049 Given the above definitions, nodes are free to combine applications 1050 of PIB and PCB in any way they wish - the correlator value allows for 1051 multiple applications of security services to be handled separately. 1052 Since PIB and PCB apply to the payload and ESB to non-payload blocks, 1053 combinations of ESB with PIB and/or PCB are not considered. 1055 There are some obvious security problems that could arise when 1056 applying multiple services. For example, if we encrypted a payload 1057 but left a PIB security result containing a signature in the clear, 1058 payload guesses could be confirmed. 1060 We cannot, in general, prevent all such problems since we cannot 1061 assume that every ciphersuite definition takes account of every other 1062 ciphersuite definition. However, we can limit the potential for such 1063 problems by requiring that any ciphersuite which applies to one 1064 instance of a PIB or PCB, MUST be applied to all instances with the 1065 same correlator. 1067 We now list the PIB and PCB combinations which we envisage as being 1068 useful to support: 1070 Encrypted tunnels - a single bundle MAY be encrypted many times 1071 en-route to its destination. Clearly it has to be decrypted an 1072 equal number of times, but we can imagine each encryption as 1073 representing the entry into yet another layer of tunnel. This is 1074 supported by using multiple instances of PCB, but with the payload 1075 encrypted multiple times, "in-place". Depending upon the 1076 ciphersuite defintion, other blocks can and should be encrypted, 1077 as discussed above and in Section 2.4 to ensure that parameters 1078 are protected in the case of super-encryption. 1080 Multiple parallel authenticators - a single security source might 1081 wish to protect the integrity of a bundle in multiple ways. This 1082 could be required if the bundle's path is unpredictable, and if 1083 various nodes might be involved as security destinations. 1084 Similarly, if the security source cannot determine in advance 1085 which algorithms to use, then using all might be reasonable. This 1086 would result in uses of PIB which presumably all protect the 1087 payload, and which cannot in general protect one another. Note 1088 that this logic can also apply to a BAB, if the unpredictable 1089 routing happens in the convergence layer, so we also envisage 1090 support for multiple parallel uses of BAB. 1092 Multiple sequential authenticators - if some security destination 1093 requires assurance about the route that bundles have taken, then 1094 it might insist that each forwarding node add its own PIB. More 1095 likely, however would be that outbound "bastion" nodes would be 1096 configured to sign bundles as a way of allowing the sending 1097 "domain" to take accountability for the bundle. In this case, the 1098 various PIBs will likely be layered, so that each protects the 1099 earlier applications of PIB. 1101 Authenticated and encrypted bundles - a single bundle MAY require 1102 both authentication and confidentiality. Some specifications 1103 first apply the authenticator and follow this by encrypting the 1104 payload and authenticator. As noted previously in the case where 1105 the authenticator is a signature, there are security reasons for 1106 this ordering. (See the PCB-RSA-AES128-PAYLOAD-PIB-PCB 1107 ciphersuite defined later in Section 4.3.) Others apply the 1108 authenticator after encryption, that is, to the ciphertext. This 1109 ordering is generally RECOMMENDED and minimizes attacks which, in 1110 some cases, can lead to recovery of the encryption key. 1112 There are no doubt other valid ways to combine PIB and PCB instances, 1113 but these are the "core" set supported in this specification. Having 1114 said that, as will be seen, the mandatory ciphersuites defined here 1115 are quite specific and restrictive in terms of limiting the 1116 flexibility offered by the correlator mechanism. This is primarily 1117 designed to keep this specification as simple as possible, while at 1118 the same time supporting the above scenarios. 1120 3. Security Processing 1122 This section describes the security aspects of bundle processing. 1124 3.1. Nodes as policy enforcement points 1126 All nodes are REQUIRED to have and enforce their own configurable 1127 security policies, whether these policies be explicit or default, as 1128 defined in Section 6. 1130 All nodes serve as Policy Enforcement Points (PEP) insofar as they 1131 enforce polices that MAY restrict the permissions of bundle nodes to 1132 inject traffic into the network. Policies MAY apply to traffic 1133 originating at the current node, traffic terminating at the current 1134 node and traffic to be forwarded by the current node to other nodes. 1135 If a particular transmission request, originating either locally or 1136 remotely, satisfies the node's policy or policies and is therefore 1137 accepted, then an outbound bundle can be created and dispatched. If 1138 not, then in its role as a PEP, the node will not create or forward a 1139 bundle. Error handling for such cases is currently considered out of 1140 scope of this document. 1142 Policy enforcing code MAY override all other processing steps 1143 described here and elsewhere in this document. For example, it is 1144 valid to implement a node which always attempts to attach a PIB. 1145 Similarly it is also valid to implement a node which always rejects 1146 all requests which imply the use of a PIB. 1148 Nodes MUST consult their security policy to determine the criteria 1149 that a received bundle ought to meet before it will be forwarded. 1150 These criteria MUST include a determination of whether or not the 1151 received bundle MUST include a valid BAB, PIB, PCB or ESB. If the 1152 bundle does not meet the node's policy criteria, then the bundle MUST 1153 be discarded and processed no further; in this case, a bundle status 1154 report indicating the failure MAY be generated. 1156 The node's policy MAY call for the node to add or subtract some 1157 security blocks. For example, it might require the node attempt to 1158 encrypt (parts of) the bundle for some security-destination, or that 1159 it add a PIB. If the node's policy requires a BAB to be added to the 1160 bundle, it MUST be added last so that the calculation of its security 1161 result MAY take into consideration the values of all other blocks in 1162 the bundle. 1164 3.2. Processing order of security blocks 1166 The processing order of security actions for a bundle is critically 1167 important for the actions to complete successfully. In general, the 1168 actions performed at the originating node MUST be executed in the 1169 reverse sequence at the destination. There are variations and 1170 exceptions, and these are noted below. 1172 The sequence is maintained in the ordering of security blocks in the 1173 bundle. It is for this reason that blocks MUST NOT be rearranged at 1174 forwarding nodes, whether they support the security protocols or not. 1175 The only blocks that participate in this ordering are the primary and 1176 payload blocks, and the PIB and PCB security blocks themselves. All 1177 other extension blocks, including ESBs, are ignored for purposes of 1178 determining the processing order. 1180 The security blocks are added to and removed from a bundle in a last- 1181 in-first-out (LIFO) manner, with the top of the stack immediately 1182 after the primary block. A newly-created bundle has just the primary 1183 and payload blocks, and the stack is empty. As security actions are 1184 requested for the bundle, security blocks are pushed onto the stack 1185 immediately after the primary block. The early actions have security 1186 blocks close to the payload, later actions have blocks nearer to the 1187 primary block. The actions deal with only those blocks in the bundle 1188 at the time so, for example, the first to be added processes only the 1189 payload and primary blocks, the next might process the first if it 1190 chooses and the payload and primary, and so on. The last block to be 1191 added can process all the blocks. 1193 When the bundle is received, this process is reversed and security 1194 processing begins at the top of the stack, immediately after the 1195 primary block. The security actions are performed and the block is 1196 popped from the stack. Processing continues with the next security 1197 block until finally only the payload and primary blocks remain. 1199 The simplicity of this description is undermined by various real- 1200 world requirements. Nonetheless it serves as a helpful initial 1201 framework for understanding the bundle security process. 1203 The first issue is a very common one and easy to handle. The bundle 1204 may be sent indirectly to its destination, requiring several 1205 forwarding hops to finally arrive there. Security processing happens 1206 at each node, assuming that the node supports bundle security. For 1207 the following discussion, we assume that a bundle is created and that 1208 confidentiality, then payload integrity and finally bundle 1209 authentication are applied to it. The block sequence would therefore 1210 be primary-BAB-PIB-PCB-payload. Traveling from source to destination 1211 requires going through one intermediate node, so the trip consists of 1212 two hops. 1214 When the bundle is received at the intermediate node, the receive 1215 processing validates the BAB and pops it from the stack. However the 1216 PIBs and PCBs have the final destination as their security 1217 destination, so these can't be processed and removed. The 1218 intermediate node then begins the send process with the four 1219 remaining blocks in the bundle. The outbound processing adds any 1220 security blocks required by local policy, and these are pushed on the 1221 stack immediately after the primary block, ahead of the PIB. In this 1222 example, the intermediate node adds a PIB as a signature that the 1223 bundle has passed through the node. 1225 The receive processing at the destination first handles the 1226 intermediate node's PIB and pops it, next is the originator's PIB, 1227 also popped, and finally the originator's confidentiality block which 1228 allows the payload to be decrypted and the bundle handled for 1229 delivery. 1231 DTNs in practice are likely to be more complex. The security policy 1232 for a node specifies the security requirements for a bundle. The 1233 policy will possibly cause one or more security operations to be 1234 applied to the bundle at the current node, each with its own 1235 security-destination. Application of policy at subsequent nodes 1236 might cause additional security operations, each with a security- 1237 destination. The list of security-destinations in the security 1238 blocks (BAB, PIB and PCB, not ESB) creates a partial-ordering of 1239 nodes that MUST be visited en route to the bundle destination. 1241 The bundle security scheme does not deal with security paths that 1242 overlap partially but not completely. The security policy for a node 1243 MUST avoid specifying for a bundle a security-destination that causes 1244 a conflict with any existing security-destination in that bundle. 1245 This is discussed further below in Section 3.3. 1247 The second issue relates to the reversibility of certain security 1248 process actions. In general, the actions fall into two categories: 1249 those which do not affect other parts of the bundle, and those which 1250 are fully reversible. Creating a bundle signature, for example, does 1251 not change the bundle content except for the result. The encryption 1252 performed as part of the confidentiality processing does change the 1253 bundle, but the reverse processing at the destination restores the 1254 original content. 1256 The third category is the one where the bundle content has changed 1257 slightly and in a non-destructive way, but there is no mechanism to 1258 reverse the change. The simplest example is the addition of an EID- 1259 reference to a security block. The addition of the reference causes 1260 the text to be added to the bundle's dictionary. The text may be 1261 used also by other references so removal of the block and this 1262 specific EID-reference does not cause removal of the text from the 1263 dictionary. This shortcoming is of no impact to the "sequential" or 1264 "wrapping" security schemes described above, but does cause failures 1265 with "parallel" authentication mechanisms. Solutions for this 1266 problem are implementation-specific and typically involve multi-pass 1267 processing such that blocks are added at one stage and the security 1268 results calculated at a later stage of the overall process. 1270 Certain ciphersuites have sequence requirements for their correct 1271 operation, most notably the bundle authentication ciphersuites. 1272 Processing for bundle authentication is required to happen after all 1273 other sending operations, and prior to any receive operations at the 1274 next hop node. It follows therefore that BABs MUST always be pushed 1275 onto the stack after all others. 1277 Although we describe the security block list as a stack, there are 1278 some blocks which are placed after the payload and therefore are not 1279 part of the stack. The BundleAuthentication ciphersuite #1 ("BA1") 1280 requires a second, correlated block to contain the security-result 1281 and this block is placed after the payload, usually as the last block 1282 in the bundle. We can apply the stack rules even to these blocks by 1283 specifying that they be added to the end of the bundle at the same 1284 time that their "owner" or "parent" block is pushed on the stack. In 1285 fact, they form a stack beginning at the payload but growing in the 1286 other direction. Also, not all blocks in the main stack have a 1287 corresponding entry in the trailing stack. The only blocks which 1288 MUST follow the payload are those mandated by ciphersuites as 1289 correlated blocks for holding a security-result. No other blocks are 1290 required to follow the payload block and it is NOT RECOMMENDED that 1291 they do so. 1293 ESBs are effectively placeholders for the blocks they encapsulate 1294 and, since those do not form part of the processing sequence 1295 described above, ESBs themselves do not either. ESBs MAY be 1296 correlated, however, so the "no reordering" requirement applies to 1297 them as well. 1299 3.3. Security Regions 1301 Each security block has a security path, as described in the 1302 discussion for Figure 1, and the paths for various blocks are often 1303 different. 1305 BABs are always for a single hop and these restricted paths never 1306 cause conflict. 1308 The paths for PIBs and PCBs are often from bundle source to bundle 1309 destination, to provide end-to-end protection. A bundle-source-to- 1310 bundle-destination path likewise never causes a problem. 1312 Another common scenario is for gateway-to-gateway protection of 1313 traffic between two sub-networks ("tunnel-mode"). 1315 Looking at Figure 1 and the simplified version shown in Figure 4, we 1316 can regard BN2 and BN3 as gateways connecting the two subnetworks 1317 labeled "An internet". As long as they provide security for the BN2- 1318 BN3 path, all is well. Problems begin, for example, when BN2 adds 1319 blocks with BN4 as the security-destination, and originating node BN1 1320 has created blocks with BN3 as security-destination. We now have two 1321 paths and neither is a subset of the other. 1323 This scenario should be prevented by node BN2's security policy being 1324 aware of the already-existing block with BN3 as the security 1325 destination. This policy SHOULD NOT specify a security-dest that is 1326 further distant than any existing security-dest. 1328 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 1329 | BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 | 1330 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 1331 >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ 1333 <------------- BN1 to BN3 path ------------> 1335 <------------- BN2 to BN4 path ------------> 1337 Figure 4: Overlapping security paths 1339 Consider the case where the security concern is for data integrity, 1340 so the blocks are PIBs. BN1 creates one ("PIa") along with the new 1341 bundle, and BN2 pushes its own PIB "PIb" on the stack, with security- 1342 destination BN4. When this bundle arrives at BN3, the bundle blocks 1343 are 1345 primary - PIb - PIa - payload 1347 Block PIb is not destined for this node BN3 so has to be forwarded. 1348 This is the security-destination for block PIa so, after validation, 1349 it should be removed from the bundle. But that will invalidate the 1350 PIb signature when the block is checked at the final destination. 1351 The PIb signature includes the primary block, PIb itself, PIa and the 1352 payload block, so PIa MUST remain in the bundle. This is why 1353 security blocks are treated as a stack and add/remove operations are 1354 permitted only at the top-of-stack. 1356 The situation would be worse if the security concern is 1357 confidentiality, and PCBs are employed, using the confidentiality 1358 ciphersuite #3 ("PC3") described in Section 4.3. In this scenario, 1359 BN1 would encrypt the bundle with BN3 as security-destination, BN2 1360 would create an overlapping security path by super-encrypting the 1361 payload and encapsulating the PC3 block for security-destination BN4. 1362 BN3 forwards all the blocks without change. BN4 decrypts the payload 1363 from its super-encryption and decapsulates the PC3 block, only to 1364 find that it should have been processed earlier. Assuming that BN4 1365 has no access to BN3's key store, BN4 has no way to decrypt the 1366 bundle and recover the original content. 1368 As mentioned above, authors of security policy need to use care to 1369 ensure that their policies do not cause overlaps. These guidelines 1370 should prove helpful: 1372 the originator of a bundle can always specify the bundle-dest as 1373 the security-dest, and should be cautious about doing otherwise 1375 in the "tunnel-mode" scenario where two sub-networks are connected 1376 by a tunnel through a network, the gateways can each specify the 1377 other as security-dest, and should be cautious about doing 1378 otherwise 1380 BAB is never a problem because it is always only a single hop 1382 PIB for a bundle without PCB will usually specify the bundle 1383 destination as security-dest 1385 PIB for a bundle containing a PCB should specify as its security- 1386 dest the security-dest of the PCB (outermost PCB if there are more 1387 than one) 1389 3.4. Canonicalisation of bundles 1391 In order to verify a signature or MAC on a bundle the exact same 1392 bits, in the exact same order, MUST be input to the calculation upon 1393 verification as were input upon initial computation of the original 1394 signature or MAC value. Consequently, a node MUST NOT change the 1395 encoding of any URI [RFC3986] in the dictionary field, e.g., changing 1396 the DNS part of some HTTP URL from lower case to upper case. Because 1397 bundles MAY be modified while in transit (either correctly or due to 1398 implementation errors), a canonical form of any given bundle (that 1399 contains a BAB or PIB) MUST be defined. 1401 This section defines bundle canonicalisation algorithms used in the 1402 Section 4.1 and Section 4.2 ciphersuites. Other ciphersuites can use 1403 these or define their own canonicalization procedures. 1405 3.4.1. Strict canonicalisation 1407 The first algorithm that can be used permits no changes at all to the 1408 bundle between the security-source and the security-destination. It 1409 is mainly intended for use in BAB ciphersuites. This algorithm 1410 conceptually catenates all blocks in the order presented, but omits 1411 all security result data fields in blocks of this ciphersuite type. 1412 That is, when a BAB ciphersuite specifies this algorithm then we omit 1413 all BAB security results for all BAB ciphersuites, when a PIB 1414 ciphersuite specifies this algorithm then we omit all PIB security 1415 results for all PIB ciphersuites. All security result length fields 1416 are included, even though their corresponding security result data 1417 fields are omitted. 1419 Notes: 1421 - In the above we specify that security result data is omitted. 1422 This means that no bytes of the security result data are input. 1423 We do not set the security result length to zero. Rather, we 1424 assume that the security result length will be known to the module 1425 that implements the ciphersuite before the security result is 1426 calculated, and require that this value be in the security result 1427 length field even though the security result data itself will be 1428 omitted. 1430 - The 'res' bit of the ciphersuite ID, which indicates whether or 1431 not the security result length and security result data field are 1432 present, is part of the canonical form. 1434 - The value of the block data length field, which indicates the 1435 length of the block, is also part of the canonical form. Its 1436 value indicates the length of the entire bundle when the bundle 1437 includes the security result data field. 1439 - BABs are always added to bundles after PIBs, so when a PIB 1440 ciphersuite specifies this strict canonicalisation algorithm and 1441 the PIB is received with a bundle that also includes one or more 1442 BABs, application of strict canonicalisation as part of the PIB 1443 security result verification process requires that all BABs in the 1444 bundle be ignored entirely. 1446 3.4.2. Mutable canonicalisation 1448 This algorithm is intended to protect parts of the bundle which 1449 SHOULD NOT be changed in-transit. Hence it omits the mutable parts 1450 of the bundle. 1452 The basic approach is to define a canonical form of the primary block 1453 and catenate it with the security (PIBs and PCBs only) and payload 1454 blocks in the order that they will be transmitted. This algorithm 1455 ignores all other blocks, including ESBs, because it cannot be 1456 determined whether or not they will change as the bundle transits the 1457 network. In short, this canonicalization protects the payload, 1458 payload-related security blocks and parts of the primary block. 1460 Many fields in various blocks are stored as variable-length SDNVs. 1461 These are canonicalized in unpacked form, as eight-byte fixed-width 1462 fields in network byte order. The size of eight bytes is chosen 1463 because implementations MAY handle larger values as invalid, as noted 1464 in [DTNBP]. 1466 The canonical form of the primary block is shown in Figure 5. 1467 Essentially, it de-references the dictionary block, adjusts lengths 1468 where necessary and ignores flags that MAY change in transit. 1470 +----------------+----------------+----------------+----------------+ 1471 | Version | Processing flags (incl. COS and SRR) | 1472 +----------------+----------------+---------------------------------+ 1473 | Canonical primary block length | 1474 +----------------+----------------+---------------------------------+ 1475 | Destination endpoint ID length | 1476 +----------------+----------------+---------------------------------+ 1477 | | 1478 | Destination endpoint ID | 1479 | | 1480 +----------------+----------------+---------------------------------+ 1481 | Source endpoint ID length | 1482 +----------------+----------------+----------------+----------------+ 1483 | | 1484 | Source endpoint ID | 1485 | | 1486 +----------------+----------------+---------------------------------+ 1487 | Report-to endpoint ID length | 1488 +----------------+----------------+----------------+----------------+ 1489 | | 1490 | Report-to endpoint ID | 1491 | | 1492 +----------------+----------------+----------------+----------------+ 1493 | | 1494 + Creation Timestamp (2 x SDNV) + 1495 | | 1496 +---------------------------------+---------------------------------+ 1497 | Lifetime | 1498 +----------------+----------------+----------------+----------------+ 1500 Figure 5: The canonical form of the primary bundle block 1502 The fields shown in Figure 5 are: 1504 Version is the single-byte value in the primary block. 1506 Processing flags in the primary block is an SDNV, and includes the 1507 class-of-service (COS) and status report request (SRR) fields. 1508 For purposes of canonicalization, the SDNV is unpacked into a 1509 fixed-width field and some bits are masked out. The unpacked 1510 field is ANDed with mask 0x0000 0000 0007 C1BE to set to zero all 1511 reserved bits and the "bundle is a fragment" bit. 1513 Length - a four-byte value containing the length (in bytes) of 1514 this structure, in network byte order. 1516 Destination endpoint ID length and value - are the length (as a 1517 four byte value in network byte order) and value of the 1518 destination endpoint ID from the primary bundle block. The URI is 1519 simply copied from the relevant part(s) of the dictionary block 1520 and is not itself canonicalised. Although the dictionary entries 1521 contain null-terminators, the null-terminators are not included in 1522 the length or the canonicalization. 1524 Source endpoint ID length and value are handled similarly to the 1525 destination. 1527 Report-to endpoint ID length and value are handled similarly to 1528 the destination. 1530 Creation time (2 x SDNV) and Lifetime (SDNV) are simply copied 1531 from the primary block, with the SDNV values being represented as 1532 eight-byte unpacked values. 1534 Fragment offset and Total application data unit length are 1535 ignored, as is the case for the "bundle is a fragment" bit 1536 mentioned above. If the payload data to be canonicalized is less 1537 than the complete, original bundle payload, the offset and length 1538 are specified in the security-parameters. 1540 For non-primary blocks being included in the canonicalization, the 1541 block processing flags value used for canonicalization is the 1542 unpacked SDNV value with reserved and mutable bits masked to zero. 1543 The unpacked value is ANDed with mask 0x0000 0000 0000 0077 to zero 1544 reserved bits and the "last block" flag. The "last block" flag is 1545 ignored because BABs and other security blocks MAY be added for some 1546 parts of the journey but not others so the setting of this bit might 1547 change from hop to hop. 1549 Endpoint ID references in security blocks are canonicalized using the 1550 de-referenced text form in place of the reference pair. The 1551 reference count is not included, nor is the length of the endpoint ID 1552 text. 1554 The block-length is canonicalized as an eight-byte unpacked value in 1555 network byte order. If the payload data to be canonicalized is less 1556 than the complete, original bundle payload, this field contain the 1557 size of the data being canonicalized (the "effective block") rather 1558 that the actual size of the block. 1560 Payload blocks are generally canonicalized as-is with the exception 1561 that in some instances only a portion of the payload data is to be 1562 protected. In such a case, only those bytes are included in the 1563 canonical form, and additional ciphersuite parameters are required to 1564 specify which part of the payload is protected, as discussed further 1565 below. 1567 Security blocks are handled likewise, except that the ciphersuite 1568 will likely specify that the "current" security block security result 1569 field not be considered part of the canonical form. This differs 1570 from the strict canonicalisation case since we might use the mutable 1571 canonicalisation algorithm to handle sequential signatures such that 1572 signatures cover earlier ones. 1574 ESBs MUST NOT be included in the canonicalization. 1576 Notes: 1578 - The canonical form of the bundle is not transmitted. It is 1579 simply an artifact used as input to digesting. 1581 - We omit the reserved flags because we cannot determine if they 1582 will change in transit. The masks specified above will have to be 1583 revised if additional flags are defined and they need to be 1584 protected. 1586 - Our URI encoding does not preserve the "null-termination" 1587 convention from the dictionary field, nor do we separate the 1588 scheme and the scheme-specific part (SSP) as is done there. 1590 - The URI encoding will cause errors if any node rewrites the 1591 dictionary content (e.g. changing the DNS part of an HTTP URL from 1592 lower-case to upper case). This could happen transparently when a 1593 bundle is synched to disk using one set of software and then read 1594 from disk and forwarded by a second set of software. Because 1595 there are no general rules for canonicalising URIs (or IRIs), this 1596 problem may be an unavoidable source of integrity failures. 1598 - All SDNV fields here are canonicalized as eight-byte unpacked 1599 values in network byte order. Length fields are canonicalized as 1600 four-byte values in network byte order. Encoding does not need 1601 optimization since the values are never sent over the network. 1603 If a bundle is fragmented before the PIB is applied then the PIB 1604 applies to a fragment and not the entire bundle. However, the 1605 protected fragment could be subsequently further fragmented, which 1606 would leave the verifier unable to know which bytes were protected 1607 by the PIB. Even in the absence of fragmentation the same 1608 situation applies if the ciphersuite is defined to allow 1609 protection of less than the entire, original bundle payload. 1611 For this reason, PIB ciphersuites which support applying a PIB to 1612 less than the complete, original bundle payload MUST specify, as 1613 part of the ciphersuite parameters, which bytes of the bundle 1614 payload are protected. When verification occurs, only the 1615 specified range of the payload bytes are input to PIB 1616 verification. It is valid for a ciphersuite to be specified so as 1617 to only apply to entire bundles and not to fragments. A 1618 ciphersuite MAY be specified to apply to only a portion of the 1619 payload, regardless of whether the payload is a fragment or the 1620 complete original bundle payload. 1622 The same fragmentation issue applies equally to PCB ciphersuites. 1623 Ciphersuites which support applying confidentiality to fragments 1624 MUST specify, as part of the ciphersuite parameters, which bytes 1625 of the bundle payload are protected. When decrypting a fragment, 1626 only the specified bytes are processed. It is also valid for a 1627 confidentiality ciphersuite to be specified so as to only apply to 1628 entire bundles and not to fragments. 1630 This definition of mutable canonicalization assumes that endpoint IDs 1631 themselves are immutable and is unsuitable for use in environments 1632 where that assumption might be violated. 1634 The canonicalization applies to a specific bundle and not a specific 1635 payload. If a bundle is forwarded in some way, the recipient is not 1636 able to verify the original integrity signature since the the source 1637 EID will be different, and possibly other fields. 1639 The solution for either of these issues is to define and use a PIB 1640 ciphersuite having an alternate version of mutable canonicalization 1641 any fields from the primary block. 1643 3.5. Endpoint ID confidentiality 1645 Every bundle MUST contain a primary block that contains the source 1646 and destinations endpoint IDs, and others, and that cannot be 1647 encrypted. If endpoint ID confidentiality is required, then bundle- 1648 in-bundle encapsulation can solve this problem in some instances. 1650 Similarly, confidentiality requirements MAY also apply to other parts 1651 of the primary block (e.g. the current-custodian) and that is 1652 supported in the same manner. 1654 3.6. Bundles received from other nodes 1656 Nodes implementing this specification SHALL consult their security 1657 policy to determine whether or not a received bundle is required by 1658 policy to include a BAB. If the bundle has no BAB and one is not 1659 required then BAB processing on the received bundle is complete and 1660 the bundle is ready to be further processed for PIB/PCB/ESB handling 1661 or delivery or forwarding. 1663 If the bundle is required to have a BAB but does not, then the bundle 1664 MUST be discarded and processed no further. If the bundle is 1665 required to have a BAB but all of its BABs identify a different node 1666 other than the receiving node as the BAB security destination, then 1667 the bundle MUST be discarded and processed no further. 1669 If the bundle is required to have a BAB and has one or more BABs that 1670 identify the receiving node as the BAB security destination, or for 1671 which there is no security destination, then the value in the 1672 security result field(s) of the BAB(s) MUST be verified according to 1673 the ciphersuite specification. If for all such BABs in the bundle 1674 either the BAB security source cannot be determined or the security 1675 result value check fails, the bundle has failed to authenticate and 1676 the bundle MUST be discarded and processed no further. If any of the 1677 BABs present verify, or if a BAB is not required, the bundle is ready 1678 for further processing as determined by extension blocks and/or 1679 policy. 1681 BABs received in a bundle MUST be stripped before the bundle is 1682 forwarded. New BABs MAY be added as required by policy. This MAY 1683 require correcting the "last block" field of the to-be-forwarded 1684 bundle. 1686 Further processing of the bundle MUST take place in the order 1687 indicated by the various blocks from the primary block to the payload 1688 block, except as defined by an applicable specification. 1690 If the bundle has a PCB and the receiving node is the PCB destination 1691 for the bundle (either because the node is listed as the bundle's 1692 PCB-dest or because the node is listed as the bundle's destination 1693 and there is no PCB-dest), the node MUST decrypt the relevant parts 1694 of the bundle in accordance with the ciphersuite specification. The 1695 PCB SHALL be deleted. If the relevant parts of the bundle cannot be 1696 decrypted (i.e. the decryption key cannot be deduced or decryption 1697 fails), then the bundle MUST be discarded and processed no further; 1698 in this case a bundle deletion status report (see the Bundle Protocol 1699 [DTNBP]) indicating the decryption failure MAY be generated. If the 1700 PCB security result included the ciphertext of a block other than the 1701 payload block, the recovered plaintext block MUST be placed in the 1702 bundle at the location from which the PCB was deleted. 1704 If the bundle has one or more PIBs for which the receiving node is 1705 the bundle's PIB destination (either because the node is listed in 1706 the bundle's PIB-dest or because the node is listed as the bundle's 1707 destination and there is no PIB-dest), the node MUST verify the value 1708 in the PIB security result field(s) in accordance with the 1709 ciphersuite specification. If all the checks fail, the bundle has 1710 failed to authenticate and the bundle SHALL be processed according to 1711 the security policy. A bundle status report indicating the failure 1712 MAY be generated. Otherwise, if the PIB verifies, the bundle is 1713 ready to be processed for either delivery or forwarding. Before 1714 forwarding the bundle, the node SHOULD remove the PIB from the 1715 bundle, subject to the requirements of Section 3.2, unless it is 1716 likely that some downstream node will also be able to verify the PIB. 1718 If the bundle has a PIB and the receiving node is not the bundle's 1719 PIB-dest the receiving node MAY attempt to verify the value in the 1720 security result field. If it is able to check and the check fails, 1721 the node SHALL discard the bundle and it MAY send a bundle status 1722 report indicating the failure. 1724 If the bundle has an ESB and the receiving node is the ESB 1725 destination for the bundle (either because the node is listed as the 1726 bundle's ESB-dest or because the node is listed as the bundle's 1727 destination and there is no ESB-dest), the node MUST decrypt and/or 1728 decapsulate the encapsulated block in accordance with the ciphersuite 1729 specification. The decapsulated block replaces the ESB in the bundle 1730 block sequence, and the ESB is thereby deleted. If the content 1731 cannot be decrypted (i.e., the decryption key cannot be deduced or 1732 decryption fails), then the bundle MAY be discarded and processed no 1733 further unless the security policy specifies otherwise. In this case 1734 a bundle deletion status report (see the Bundle Protocol [DTNBP]) 1735 indicating the decryption failure MAY be generated. 1737 3.7. The At-Most-Once-Delivery Option 1739 An application MAY request (in an implementation specific manner) 1740 that a node be registered as a member of an endpoint and that 1741 received bundles destined for that endpoint be delivered to that 1742 application. 1744 An option for use in such cases is known as "at-most-once-delivery". 1745 If this option is chosen, the application indicates that it wants the 1746 node to check for duplicate bundles, discard duplicates, and deliver 1747 at most one copy of each received bundle to the application. If this 1748 option is not chosen, the application indicates that it wants the 1749 node to deliver all received bundle copies to the application. If 1750 this option is chosen, the node SHALL deliver at most one copy of 1751 each received bundle to the application. If the option is not 1752 chosen, the node SHOULD, subject to policy, deliver all bundles. 1754 To enforce this the node MUST look at the source/timestamp pair value 1755 of each complete (reassembled, if necessary) bundle received and 1756 determine if this pair, which uniquely identifies a bundle, has been 1757 previously received. If it has, then the bundle is a duplicate. If 1758 it has not, then the bundle is not a duplicate. The source/timestamp 1759 pair SHALL be added to the list of pair values already received by 1760 that node. 1762 Each node implementation MAY decide how long to maintain a table of 1763 pair value state. 1765 3.8. Bundle Fragmentation and Reassembly 1767 If it is necessary for a node to fragment a bundle and security 1768 services have been applied to that bundle, the fragmentation rules 1769 described in [DTNBP] MUST be followed. As defined there and repeated 1770 here for completeness, only the payload MAY be fragmented; security 1771 blocks, like all extension blocks, can never be fragmented. In 1772 addition, the following security-specific processing is REQUIRED: 1774 The security policy requirements for a bundle MUST be applied 1775 individually to all the bundles resulting from a fragmentation event. 1777 If the original bundle contained a PIB, then each of the PIB 1778 instances MUST be included in some fragment. 1780 If the original bundle contained one or more PCBs, then any PCB 1781 instances containing a key information item MUST have the "replicate 1782 in every fragment" flag set, and thereby be replicated in every 1783 fragment. This is to ensure that the canonical block-sequence can be 1784 recovered during reassembly. 1786 If the original bundle contained one or more correlated PCBs not 1787 containing a key information item, then each of these MUST be 1788 included in some fragment, but SHOULD NOT be sent more than once. 1789 They MUST be placed in a fragment in accordance with the 1790 fragmentation rules described in [DTNBP]. 1792 Note: various fragments MAY have additional security blocks added at 1793 this or later stages and it is possible that correlators will 1794 collide. In order to facilitate uniqueness, ciphersuites SHOULD 1795 include the fragment-offset of the fragment as a high-order component 1796 of the correlator. 1798 3.9. Reactive fragmentation 1800 When a partial bundle has been received, the receiving node SHALL 1801 consult its security policy to determine if it MAY fragment the 1802 bundle, converting the received portion into a bundle fragment for 1803 further forwarding. Whether or not reactive fragmentation is 1804 permitted SHALL depend on the security policy and the ciphersuite 1805 used to calculate the BAB authentication information, if required. 1806 (Some BAB ciphersuites, i.e., the mandatory BAB-HMAC ciphersuite 1807 defined in Section 4.1, do not accommodate reactive fragmentation 1808 because the security result in the BAB requires that the entire 1809 bundle be signed. It is conceivable, however, that a BAB ciphersuite 1810 could be defined such that multiple security results are calculated, 1811 each on a different segment of a bundle, and that these security 1812 results could be interspersed between bundle payload segments such 1813 that reactive fragmentation could be accommodated.) 1815 If the bundle is reactively fragmented by the intermediate receiver 1816 and the BAB-ciphersuite is of an appropriate type (e.g. with multiple 1817 security results embedded in the payload), the bundle MUST be 1818 fragmented immediately after the last security result value in the 1819 partial payload that is received. Any data received after the last 1820 security result value MUST be dropped. 1822 If a partial bundle is received at the intermediate receiver and is 1823 reactively fragmented and forwarded, only the part of the bundle that 1824 was not received MUST be retransmitted, though more of the bundle MAY 1825 be retransmitted. Before retransmitting a portion of the bundle, it 1826 SHALL be changed into a fragment and, if the original bundle included 1827 a BAB, the fragmented bundle MUST also, and its BAB SHALL be 1828 recalculated. 1830 This specification does not currently define any ciphersuite which 1831 can handle this reactive fragmentation case. 1833 An interesting possibility is a ciphersuite definition such that the 1834 transmission of a follow-up fragment would be accompanied by the 1835 signature for the payload up to the restart point. 1837 3.10. Attack Model 1839 An evaluation of resilience to cryptographic attack necessarily 1840 depends upon the algorithms chosen for bulk data protection and for 1841 key transport. The mandatory ciphersuites described in the following 1842 section use AES, RSA and SHA algorithms in ways that are believed to 1843 be reasonably secure against ciphertext-only, chosen-ciphertext, 1844 known-plaintext and chosen-plaintext attacks. 1846 The design has been careful to preserve the resilience of the 1847 algorithms against attack. For example, if a message is encrypted 1848 then any message integrity signature is also encrypted so that 1849 guesses cannot be confirmed. 1851 4. Mandatory Ciphersuites 1853 This section defines the mandatory ciphersuites for this 1854 specification. There is currently one mandatory ciphersuite for use 1855 with each of the security block types BAB, PIB, PCB and ESB. The BAB 1856 ciphersuite is based on shared secrets using HMAC. The PIB 1857 ciphersuite is based on digital signatures using RSA with SHA-256. 1858 The PCB and ESB ciphersuites are based on using RSA for key transport 1859 and AES for bulk encryption. 1861 In all uses of CMS eContent in this specification the relevant 1862 eContentType to be used is id-data as specified in [RFC5652] . 1864 The ciphersuites use the mechanisms defined in Cryptographic Message 1865 Syntax (CMS) [RFC5652] for packaging the keys, signatures, etc for 1866 transport in the appropriate security block. The data in the CMS 1867 object is not the bundle data, as would be the typical usage for CMS. 1868 Rather, the "message data" packaged by CMS is the ephemeral key, 1869 message digest, etc used in the core code of the ciphersuite. 1871 In all cases where we use CMS, implementations SHOULD NOT include 1872 additional attributes whether signed or unsigned, authenticated or 1873 unauthenticated. 1875 4.1. BAB-HMAC 1877 The BAB-HMAC ciphersuite has ciphersuite ID value 0x001. 1879 BAB-HMAC uses the strict canonicalisation algorithm in Section 3.4.1. 1881 Strict canonicalization supports digesting of a fragment-bundle. It 1882 does not permit the digesting of only a subset of the payload, but 1883 only the complete contents of the payload of the current bundle, 1884 which might be a fragment. The "fragment range" item for security- 1885 parameters is not used to indicate a fragment, as this information is 1886 digested within the primary block. 1888 The variant of HMAC to be used is HMAC-SHA1 as defined in [RFC2104]. 1890 This ciphersuite requires the use of two related instances of the 1891 BAB. It involves placing the first BAB instance (as defined in 1892 Section 2.2) just after the primary block. The second (correlated) 1893 instance of the BAB MUST be placed after all other blocks (except 1894 possibly other BAB blocks) in the bundle. 1896 This means that normally, the BAB will be the second and last blocks 1897 of the bundle. If a forwarder wishes to apply more than one 1898 correlated BAB pair, then this can be done. There is no requirement 1899 that each application "wrap" the others, but the forwarder MUST 1900 insert all the "up front" BABs, and their "at back" "partners" 1901 (without any security result), before canonicalising. 1903 Inserting more than one correlated BAB pair would be useful if the 1904 bundle could be routed to more than one potential "next-hop" or if 1905 both an old or a new key were valid at sending time, with no 1906 certainty about the situation that will obtain at reception time. 1908 The security result is the output of the HMAC-SHA1 calculation with 1909 input being the result of running the entire bundle through the 1910 strict canonicalisation algorithm. Both required BAB instances MUST 1911 be included in the bundle before canonicalisation. 1913 Security parameters are OPTIONAL with this scheme, but if used then 1914 the only field that can be present is key information (see 1915 Section 2.6). 1917 In the absence of key information the receiver is expected to be able 1918 to find the correct key based on the sending identity. The sending 1919 identity MAY be known from the security-source field or the content 1920 of a previous-hop block in the bundle. It MAY also be determined 1921 using implementation-specific means such as the convergence layer. 1923 4.2. PIB-RSA-SHA256 1925 The PIB-RSA-SHA256 ciphersuite has ciphersuite ID value 0x02. 1927 PIB-RSA-SHA256 uses the mutable canonicalisation algorithm 1928 Section 3.4.2, with the security-result data field for only the 1929 "current" block being excluded from the canonical form. The 1930 resulting canonical form of the bundle is the input to the signing 1931 process. This ciphersuite requires the use of a single instance of 1932 the PIB. 1934 Because the signature field in SignedData SignatureValue is a 1935 security-result field, the entire key information item MUST be placed 1936 in the block's security-result field, rather than security- 1937 parameters. 1939 If the bundle being signed has been fragmented before signing, then 1940 we have to specify which bytes were signed in case the signed bundle 1941 is subsequently fragmented for a second time. If the bundle is a 1942 fragment, then the ciphersuite parameters MUST include a fragment- 1943 range field, as described in Section 2.6, specifying the offset and 1944 length of the signed fragment. If the entire bundle is signed then 1945 these numbers MUST be omitted. 1947 Implementations MUST support use of "SignedData" type as defined in 1948 [RFC5652] section 5.1, with SignerInfo type SignerIdentifier 1949 containing the issuer and serial number of a suitable certificate. 1950 The data to be signed is the output of the SHA256 mutable 1951 canonicalization process. 1953 RSA is used with SHA256 as specified for the id-sha256 signature 1954 scheme in [RFC4055] Section 5. The output of the signing process is 1955 the SignatureValue field for the PIB. 1957 "Commensurate strength" cryptography is generally held to be a good 1958 idea. A combination of RSA with SHA-256 is reckoned to require a 1959 3076 bit RSA key according to this logic. Few implementations will 1960 choose this length by default (and probably some just won't support 1961 such long keys). Since this is an experimental protocol, we expect 1962 that 1024 or 2048 bit RSA keys will be used in many cases, and that 1963 that will be fine since we also expect that the hash function 1964 "issues" will be resolved before any standard would be derived from 1965 this protocol. 1967 4.3. PCB-RSA-AES128-PAYLOAD-PIB-PCB 1969 The PCB-RSA-AES128-PAYLOAD-PIB-PCB ciphersuite has ciphersuite ID 1970 value 0x003. 1972 This scheme encrypts PIBs, PCBs and the payload. The key size for 1973 this ciphersuite is 128 bits. 1975 Encryption is done using the AES algorithm in Galois/Counter Mode 1976 (GCM) as described in [RFC5084] Note: parts of the following 1977 description are borrowed from [RFC4106]. 1979 The choice of GCM avoids expansion of the payload, which causes 1980 problems with fragmentation/reassembly and custody transfer. GCM 1981 also includes authentication, essential in preventing attacks that 1982 can alter the decrypted plaintext or even recover the encryption key. 1984 GCM is a block cipher mode of operation providing both 1985 confidentiality and data integrity. The GCM encryption operation has 1986 four inputs: a secret key, an initialization vector (IV), a 1987 plaintext, and an input for additional authenticated data (AAD) which 1988 is not used here. It has two outputs, a ciphertext whose length is 1989 identical to the plaintext, and an authentication tag, also known as 1990 the Integrity Check Value (ICV). 1992 For consistency with the description in [RFC5084], we refer to the 1993 GCM IV as a nonce. The same key and nonce combination MUST NOT be 1994 used more than once. The nonce has the following layout 1995 +----------------+----------------+----------------+----------------+ 1996 | salt | 1997 +----------------+----------------+----------------+----------------+ 1998 | | 1999 | initialization vector | 2000 | | 2001 +----------------+----------------+----------------+----------------+ 2003 Figure 6: Nonce Format for PCB-RSA-AES128-PAYLOAD-PIB-PCB 2005 The salt field is a four-octet value, usually chosen at random. It 2006 MUST be the same for all PCBs which have the same correlator value. 2007 The salt need not be kept secret. 2009 The initialization vector (IV) is an eight-octet value, usually 2010 chosen at random. It MUST be different for all PCBs which have the 2011 same correlator value. The value need not be kept secret. 2013 The key (bundle encryption key, BEK) is a sixteen-octet (128 bits) 2014 value, usually chosen at random. The value MUST be kept secret, as 2015 described below. 2017 The integrity check value is a sixteen-octet value used to verify 2018 that the protected data has not been altered. The value need not be 2019 kept secret. 2021 This ciphersuite requires the use of a single PCB instance to deal 2022 with payload confidentiality. If the bundle already contains PIBs or 2023 PCBs then the ciphersuite will create additional correlated blocks to 2024 protect these PIBs and PCBs. These "additional" blocks replace the 2025 original blocks on a one-for-one basis, so the number of blocks 2026 remains unchanged. All these related blocks MUST have the same 2027 correlator value. The term "first PCB" in this section refers to the 2028 single PCB if there is only one or, if there are several, then to the 2029 one containing the key information. This MUST be the first of the 2030 set. 2032 First PCB - the first PCB MAY contain a correlator value, and MAY 2033 specify security-source and/or security-destination in the EID-list. 2034 If not specified, the bundle-source and bundle-destination 2035 respectively are used for these values, as with other ciphersuites. 2036 The block MUST contain security-parameters and security-result 2037 fields. Each field MAY contain several items formatted as described 2038 in Section 2.6. 2040 Security-parameters 2041 key information 2043 salt 2045 IV (this instance applies only to payload) 2047 fragment offset and length, if bundle is a fragment 2049 Security-result 2051 ICV 2053 Subsequent PCBs MUST contain a correlator value to link them to the 2054 first PCB. Security-source and security-destination are implied from 2055 the first PCB, however see the discussion in Section 2.4 concerning 2056 EID-list entries. They MUST contain security-parameters and 2057 security-result fields as follows: 2059 Security-parameters 2061 IV for this specific block 2063 Security-result 2065 encapsulated block 2067 The security-parameters and security-result fields in the subsequent 2068 PCBs MUST NOT contain any items other than these two. Items such as 2069 key and salt are supplied in the first PCB and MUST NOT be repeated. 2071 Implementations MUST support use of "Enveloped-data" type as defined 2072 in [RFC5652] section 6, with RecipientInfo type KeyTransRecipientInfo 2073 containing the issuer and serial number of a suitable certificate. 2074 They MAY support additional RecipientInfo types. The 2075 "encryptedContent" field in EncryptedContentInfo contains the 2076 encrypted BEK that protects the payload and certain security blocks 2077 of the bundle. 2079 The Integrity Check Value from the AES-GCM encryption of the payload 2080 is placed in the security-result field of the first PCB. 2082 If the bundle being encrypted is a fragment-bundle we have to specify 2083 which bytes are encrypted in case the bundle is subsequently 2084 fragmented again. If the bundle is a fragment the ciphersuite 2085 parameters MUST include a fragment-range field, as described in 2086 Section 2.6, specifying the offset and length of the encrypted 2087 fragment. Note that this is not the same pair of fields which appear 2088 in the primary block as "offset and length". The "length" in this 2089 case is the length of the fragment, not the original length. If the 2090 bundle is not a fragment then this field MUST be omitted. 2092 The confidentiality processing for payload and other blocks is 2093 different, mainly because the payload might be fragmented later at 2094 some other node. 2096 For the payload, only the bytes of the bundle payload field are 2097 affected, being replaced by ciphertext. The salt, IV and key values 2098 specified in the first PCB are used to encrypt the payload, and the 2099 resultant authentication tag (ICV) is placed in an ICV item in the 2100 security-result field of that first PCB. The other bytes of the 2101 payload block, such as type, flags and length, are not modified. 2103 For each PIB or PCB to be protected, the entire original block is 2104 encapsulated in a "replacing" PCB. This replacing PCB is placed in 2105 the outgoing bundle in the same position as the original block, PIB 2106 or PCB. As mentioned above, this is one-for-one replacement and 2107 there is no consolidation of blocks or mixing of data in any way. 2109 The encryption process uses AES-GCM with the salt and key values from 2110 the first PCB, and an IV unique to this PCB. The process creates 2111 ciphertext for the entire original block, and an authentication tag 2112 for validation at the security destination. For this encapsulation 2113 process, unlike the processing of the bundle payload, the 2114 authentication tag is appended to the ciphertext for the block and 2115 the combination is stored into the "encapsulated block" item in 2116 security-result. 2118 The replacing block, of course, also has the same correlator value as 2119 the first PCB with which it is associated. It also contains the 2120 block-specific IV in security-parameters, and the combination of 2121 original-block-ciphertext and authentication tag, stored as an 2122 "encapsulated block" item in security-result. 2124 If the payload was fragmented after encryption then all those 2125 fragments MUST be present and reassembled before decryption. This 2126 process might be repeated several times at different destinations if 2127 multiple fragmentation actions have occurred. 2129 The size of the GCM counter field limits the payload size to 2^39 - 2130 256 bytes, about half a terabyte. A future revision of this 2131 specification will address the issue of handling payloads in excess 2132 of this size. 2134 4.4. ESB-RSA-AES128-EXT 2136 The ESB-RSA-AES128-EXT ciphersuite has ciphersuite ID value 0x004. 2138 This scheme encrypts non-payload-related blocks. It MUST NOT be used 2139 to encrypt PIBs, PCBs or primary or payload blocks. The key size for 2140 this ciphersuite is 128 bits. 2142 Encryption is done using the AES algorithm in Galois/Counter Mode 2143 (GCM) as described in [RFC5084] Note: parts of the following 2144 description are borrowed from [RFC4106]. 2146 GCM is a block cipher mode of operation providing both 2147 confidentiality and data origin authentication. The GCM 2148 authenticated encryption operation has four inputs: a secret key, an 2149 initialization vector (IV), a plaintext, and an input for additional 2150 authenticated data (AAD) which is not used here. It has two outputs, 2151 a ciphertext whose length is identical to the plaintext, and an 2152 authentication tag, also known as the Integrity Check Value (ICV). 2154 For consistency with the description in [RFC5084], we refer to the 2155 GCM IV as a nonce. The same key and nonce combination MUST NOT be 2156 used more than once. The nonce has the following layout 2158 +----------------+----------------+---------------------------------+ 2159 | salt | 2160 +----------------+----------------+---------------------------------+ 2161 | | 2162 | initialization vector | 2163 | | 2164 +----------------+----------------+---------------------------------+ 2166 Figure 7: Nonce Format for ESB-RSA-AES128-EXT 2168 The salt field is a four-octet value, usually chosen at random. It 2169 MUST be the same for all ESBs which have the same correlator value. 2170 The salt need not be kept secret. 2172 The initialization vector (IV) is an eight-octet value, usually 2173 chosen at random. It MUST be different for all ESBs which have the 2174 same correlator value. The value need not be kept secret. 2176 The data encryption key is a sixteen-octet (128 bits) value, usually 2177 chosen at random. The value MUST be kept secret, as described below. 2179 The integrity check value is a sixteen-octet value used to verify 2180 that the protected data has not been altered. The value need not be 2181 kept secret. 2183 This ciphersuite replaces each BP extension block to be protected 2184 with a "replacing" ESB, and each can be individually specified. 2186 If a number of related BP extension blocks are to be protected they 2187 can be grouped as a correlated set and protected using a single key. 2188 These blocks replace the original blocks on a one-for-one basis, so 2189 the number of blocks remains unchanged. All these related blocks 2190 MUST have the same correlator value. The term "first ESB" in this 2191 section refers to the single ESB if there is only one or, if there 2192 are several, then to the one containing the key or key-identifier. 2193 This MUST be the first of the set. If the blocks are individually 2194 specified then there is no correlated set and each block is its own 2195 "first ESB". 2197 First ESB - the first ESB MAY contain a correlator value, and MAY 2198 specify security-source and/or security-destination in the EID-list. 2199 If not specified, the bundle-source and bundle-destination 2200 respectively are used for these values, as with other ciphersuites. 2201 The block MUST contain security-parameters and security-result 2202 fields. Each field MAY contain several items formatted as described 2203 in Section 2.6. 2205 Security-parameters 2207 key information 2209 salt 2211 IV for this specific block 2213 block type of encapsulated block (OPTIONAL) 2215 Security-result 2217 encapsulated block 2219 Subsequent ESBs MUST contain a correlator value to link them to the 2220 first ESB. Security-source and security-destination are implied from 2221 the first ESB, however see the discussion in Section 2.4 concerning 2222 EID-list entries. Subsequent ESBs MUST contain security-parameters 2223 and security-result fields as follows: 2225 Security-parameters 2227 IV for this specific block 2228 block type of encapsulated block (OPTIONAL) 2230 Security-result 2232 encapsulated block 2234 The security-parameters and security-result fields in the subsequent 2235 ESBs MUST NOT contain any items other than those listed. Items such 2236 as key and salt are supplied in the first ESB and MUST NOT be 2237 repeated. 2239 Implementations MUST support use of "Enveloped-data" type as defined 2240 in [RFC5652] section 6, with RecipientInfo type KeyTransRecipientInfo 2241 containing the issuer and serial number of a suitable certificate. 2242 They MAY support additional RecipientInfo types. The 2243 "encryptedContent" field in EncryptedContentInfo contains the 2244 encrypted BEK used to encrypt the content of the block being 2245 protected. 2247 For each block to be protected, the entire original block is 2248 encapsulated in a "replacing" ESB. This replacing ESB is placed in 2249 the outgoing bundle in the same position as the original block. As 2250 mentioned above, this is one-for-one replacement and there is no 2251 consolidation of blocks or mixing of data in any way. 2253 The encryption process uses AES-GCM with the salt and key values from 2254 the first ESB, and an IV unique to this ESB. The process creates 2255 ciphertext for the entire original block, and an authentication tag 2256 for validation at the security destination. The authentication tag 2257 is appended to the ciphertext for the block and the combination is 2258 stored into the "encapsulated block" item in security-result. 2260 The replacing block, of course, also has the same correlator value as 2261 the first ESB with which it is associated. It also contains the 2262 block-specific IV in security-parameters, and the combination of 2263 original-block-ciphertext and authentication tag, stored as an 2264 "encapsulated block" item in security-result. 2266 5. Key Management 2268 Key management in delay tolerant networks is recognized as a 2269 difficult topic and is one that this specification does not attempt 2270 to solve. However, solely in order to support implementation and 2271 testing, implementations SHOULD support: 2273 - The use of well-known RSA public keys for all ciphersuites. 2275 - Long-term pre-shared-symmetric keys for the BAB-HMAC 2276 ciphersuite. 2278 Since endpoint IDs are URIs and URIs can be placed in X.509 [RFC5280] 2279 public key certificates (in the subjectAltName extension) 2280 implementations SHOULD support this way of distributing public keys. 2281 RFC 5280 does not insist that implementations include revocation 2282 checking. In the context of a DTN, it is reasonably likely that some 2283 nodes would not be able to use revocation checking services (either 2284 CRLs or OCSP) and deployments SHOULD take this into account when 2285 planning any public key infrastructure to support this specification. 2287 6. Default Security Policy 2289 Every node serves as a Policy Enforcement Point insofar as it 2290 enforces some policy that controls the forwarding and delivery of 2291 bundles via one or more convergence layer protocol implementation. 2292 Consequently, every node SHALL have and operate according to its own 2293 configurable security policy, whether the policy be explicit or 2294 default. The policy SHALL specify: 2296 Under what conditions received bundles SHALL be forwarded. 2298 Under what conditions received bundles SHALL be required to 2299 include valid BABs. 2301 Under what conditions the authentication information provided in a 2302 bundle's BAB SHALL be deemed adequate to authenticate the bundle. 2304 Under what conditions received bundles SHALL be required to have 2305 valid PIBs and/or PCBs. 2307 Under what conditions the authentication information provided in a 2308 bundle's PIB SHALL be deemed adequate to authenticate the bundle. 2310 Under what conditions a BAB SHALL be added to a received bundle 2311 before that bundle is forwarded. 2313 Under what conditions a PIB SHALL be added to a received bundle 2314 before that bundle is forwarded. 2316 Under what conditions a PCB SHALL be added to a received bundle 2317 before that bundle is forwarded. 2319 Under what conditions an ESB SHALL be applied to one or more 2320 blocks in a received bundle before that bundle is forwarded. 2322 The actions that SHALL be taken in the event that a received 2323 bundle does not meet the receiving node's security policy 2324 criteria. 2326 This specification does not address how security policies get 2327 distributed to nodes. It only REQUIRES that nodes have and enforce 2328 security policies. 2330 If no security policy is specified at a given node, or if a security 2331 policy is only partially specified, that node's default policy 2332 regarding unspecified criteria SHALL consist of the following: 2334 Bundles that are not well-formed do not meet the security policy 2335 criteria. 2337 The mandatory ciphersuites MUST be used. 2339 All bundles received MUST have a BAB which MUST be verified to 2340 contain a valid security result. If the bundle does not have a 2341 BAB, then the bundle MUST be discarded and processed no further; a 2342 bundle status report indicating the authentication failure MAY be 2343 generated. 2345 No received bundles SHALL be required to have a PIB; if a received 2346 bundle does have a PIB, however, the PIB can be ignored unless the 2347 receiving node is the PIB-dest, in which case the PIB MUST be 2348 verified. 2350 No received bundles SHALL be required to have a PCB; if a received 2351 bundle does have a PCB, however, the PCB can be ignored unless the 2352 receiving node is the PCB-dest, in which case the PCB MUST be 2353 processed. If processing of a PCB yields a PIB, that PIB SHALL be 2354 processed by the node according to the node's security policy. 2356 A PIB SHALL NOT be added to a bundle before sourcing or forwarding 2357 it. 2359 A PCB SHALL NOT be added to a bundle before sourcing or forwarding 2360 it. 2362 A BAB MUST always be added to a bundle before that bundle is 2363 forwarded. 2365 If a destination node receives a bundle that has a PIB-dest but 2366 the value in that PIB-dest is not the EID of the destination node, 2367 the bundle SHALL be delivered at that destination node. 2369 If a destination node receives a bundle that has an ESB-dest but 2370 the value in that ESB-dest is not the EID of the destination node, 2371 the bundle SHALL be delivered at that destination node. 2373 If a received bundle does not satisfy the node's security policy 2374 for any reason, then the bundle MUST be discarded and processed no 2375 further; in this case, a bundle deletion status report (see the 2376 Bundle Protocol [DTNBP]) indicating the failure MAY be generated. 2378 7. Security Considerations 2380 The Bundle Security Protocol builds upon much work of others, in 2381 particular the Cryptographic Message Syntax (CMS) [RFC5652] and 2382 Internet X.509 Public Key Infrastructure Certificate and Certificate 2383 Revocation List (CRL) Profile [RFC5280]. The security considerations 2384 in these two documents apply here as well. 2386 Several documents specifically consider the use of Galois/Counter 2387 Mode(GCM) and of AES and are important to consider when building 2388 ciphersuites. These are The Use of Galois/Counter Mode (GCM) in 2389 IPsec Encapsulating Security Payload (ESP) [RFC4106] and Using AES- 2390 CCM and AES-GCM Authenticated Encryption in the Cryptographic Message 2391 Syntax (CMS) [RFC5084]. Although the BSP is not identical, many of 2392 the security issues considered in these documents also apply here. 2394 Certain applications of DTN need to both sign and encrypt a message 2395 and there are security issues to consider with this. 2397 If the intent is to provide an assurance that a message did in fact 2398 come from a specific source and has not been changed then it should 2399 be signed first and then encrypted. A signature on an encrypted 2400 message does not establish any relationship between the signer and 2401 the original plaintext message. 2403 On the other hand, if the intent is reduce the threat of denial-of- 2404 service attacks then signing the encrypted message is appropriate. A 2405 message that fails the signature check will not be processed through 2406 the computationally-intensive decryption pass. A more extensive 2407 discussion of these points is in S/MIME 3.2 Message Specification 2408 [RFC5751], especially in section 3.6. 2410 Additional details relating to these combinations can be found at 2411 Section 2.8 where it is RECOMMENDED that the encrypt-then-sign 2412 combination is usually appropriate for usage in a DTN. 2414 In a DTN encrypt-then-sign potentially allows intermediate nodes to 2415 verify a signature (over the ciphertext) and thereby apply policy to 2416 manage possibly scarce storage or other resources at intermediate 2417 nodes in the path the bundle takes from source to destination EID. 2419 An encrypt-then-sign scheme doesn't further expose identity in most 2420 cases since the BP mandates that the source EID (which is commonly 2421 expected to be the security-source) is already exposed in the primary 2422 block of the bundle. Should either exposure of the source EID or 2423 signerInfo be considered an interesting vulnerability, then some form 2424 of bundle-in-bundle encapsulation would be required as a mitigation. 2426 If a BAB ciphersuite uses digital signatures but doesn't include the 2427 security destination (which for a BAB is the next host), then this 2428 allows the bundle to be sent to some node other than the intended 2429 adjacent node. Because the BAB will still authenticate, the 2430 receiving node might erroneously accept and forward the bundle. When 2431 asymmetric BAB ciphersuites are used, the security destination field 2432 SHOULD therefore be included in the BAB. 2434 If a bundle's PIB-dest is not the same as its destination, then some 2435 node other than the destination (the node identified as the PIB-dest) 2436 is expected to validate the PIB security result while the bundle is 2437 en route. However, if for some reason the PIB is not validated, 2438 there is no way for the destination to become aware of this. 2439 Typically, a PIB-dest will remove the PIB from the bundle after 2440 verifying the PIB and before forwarding it. However, if there is a 2441 possibility that the PIB will also be verified at a downstream node, 2442 the PIB-dest will leave the PIB in the bundle. Therefore, if a 2443 destination receives a bundle with a PIB that has a PIB-dest (which 2444 isn't the destination), this might, but does not necessarily, 2445 indicate a possible problem. 2447 If a bundle is fragmented after being forwarded by its PIB-source but 2448 before being received by its PIB-dest, the payload in the bundle MUST 2449 be reassembled before validating the PIB security result in order for 2450 the security result to validate correctly. Therefore, if the PIB- 2451 dest is not capable of performing payload reassembly, its utility as 2452 a PIB-dest will be limited to validating only those bundles that have 2453 not been fragmented since being forwarded from the PIB-source. 2454 Similarly, if a bundle is fragmented after being forwarded by its 2455 PIB-source but before being received by its PIB-dest, all fragments 2456 MUST be received at that PIB-dest in order for the bundle payload to 2457 be able to be reassembled. If not all fragments are received at the 2458 PIB-dest node, the bundle will not be able to be authenticated, and 2459 will therefore never be forwarded by this PIB-dest node. 2461 Specification of a security-destination other than the bundle 2462 destination creates a routing requirement that the bundle somehow be 2463 directed to the security-destination node on its way to the final 2464 destination. This requirement is presently private to the 2465 ciphersuite, since routing nodes are not required to implement 2466 security processing. 2468 If a security target were to generate reports in the event that some 2469 security validation step fails, then that might leak information 2470 about the internal structure or policies of the DTN containing the 2471 security target. This is sometimes considered bad security practice 2472 so SHOULD only be done with care. 2474 8. Conformance 2476 As indicated above, this document describes both BSP and 2477 ciphersuites. A conformant implementation MUST implement both BSP 2478 support and the four ciphersuites described in Section 4. It MAY 2479 also support other ciphersuites. 2481 Implementations that support BSP but not all four mandatory 2482 ciphersuites MUST claim only "restricted compliance" with this 2483 specification, even if they provide other ciphersuites. 2485 All implementations are strongly RECOMMENDED to provide at least a 2486 BAB ciphersuite. A relay node, for example, might not deal with end- 2487 to-end confidentiality and data integrity but it SHOULD exclude 2488 unauthorized traffic and perform hop-by-hop bundle verification. 2490 9. IANA Considerations 2492 This protocol has fields requiring registries managed by IANA. 2494 9.1. Bundle Block Types 2496 This specification allocates four codepoints from the existing Bundle 2497 Block Type Codes registry defined in 2498 [I-D.irtf-dtnrg-iana-bp-registries]. 2500 Additional Entries for the Bundle Block Type Codes Registry: 2501 +-------+--------------------------------------+----------------+ 2502 | Value | Description | Reference | 2503 +-------+--------------------------------------+----------------+ 2504 | 2 | Bundle Authentication Block | This document | 2505 | 3 | Payload Integrity Block | This document | 2506 | 4 | Payload Confidentiality Block | This document | 2507 | 9 | Extension Security Block | This document | 2508 +-------+--------------------------------------+----------------+ 2510 9.2. Ciphersuite Numbers 2512 This Protocol has a ciphersuite number field and certain ciphersuites 2513 are defined. An IANA registry shall be set up as follows. 2515 The registration policy for this registry is: Specification Required 2517 The Value range is: Variable Length 2519 Ciphersuite Numbers Registry: 2520 +-------+--------------------------------------+----------------+ 2521 | Value | Description | Reference | 2522 +-------+--------------------------------------+----------------+ 2523 | 0 | unassigned | This document | 2524 | 1 | BAB-HMAC | This document | 2525 | 2 | PIB-RSA-SHA256 | This document | 2526 | 3 | PCB-RSA-AES128-PAYLOAD-PIB-PCB | This document | 2527 | 4 | ESB-RSA-AES128-EXT | This document | 2528 | >4 | Reserved | This document | 2529 +-------+--------------------------------------+----------------+ 2531 9.3. Ciphersuite Flags 2533 This Protocol has a ciphersuite flags field and certain flags are 2534 defined. An IANA registry shall be set up as follows. 2536 The registration policy for this registry is: Specification Required 2538 The Value range is: Variable Length 2540 Ciphersuite Flags Registry: 2541 +-----------------+----------------------------+----------------+ 2542 | Bit Position | Description | Reference | 2543 | (right to left) | | | 2544 +-----------------+----------------------------+----------------+ 2545 | 0 | Block contains result | This document | 2546 | 1 | Block contains correlator | This document | 2547 | 2 | Block contains parameters | This document | 2548 | 3 | Destination EIDref present | This document | 2549 | 4 | Source EIDref present | This document | 2550 | all others | Reserved | This document | 2551 +-----------------+----------------------------+----------------+ 2553 9.4. Parameters and Results 2555 This Protocol has fields for ciphersuite parameters and results. The 2556 field is a type-length-value triple and a registry is required for 2557 the "type" sub-field. The values for "type" apply to both the 2558 ciphersuite parameters and the ciphersuite results fields. Certain 2559 values are defined. An IANA registry shall be set up as follows. 2561 The registration policy for this registry is: Specification Required 2563 The Value range is: 8-bit unsigned integer 2564 Ciphersuite Parameters and Results Type Registry: 2565 +---------+------------------------------------+----------------+ 2566 | Value | Description | Reference | 2567 +---------+------------------------------------+----------------+ 2568 | 0 | reserved | This document | 2569 | 1 | initialization vector (IV) | This document | 2570 | 2 | reserved | This document | 2571 | 3 | key-information | This document | 2572 | 4 | fragment range (pair of SDNVs) | This document | 2573 | 5 | integrity signature | This document | 2574 | 6 | unassigned | This document | 2575 | 7 | salt | This document | 2576 | 8 | PCB integrity check value (ICV) | This document | 2577 | 9 | reserved | This document | 2578 | 10 | encapsulated block | This document | 2579 | 11 | block type of encapsulated block | This document | 2580 | 12-191 | reserved | This document | 2581 | 192-250 | private use | This document | 2582 | 251-255 | reserved | This document | 2583 +-------+--------------------------------------+----------------+ 2585 10. References 2587 10.1. Normative References 2589 [DTNBP] Scott, K. and S. Burleigh, "Bundle Protocol 2590 Specification", RFC 5050, November 2007. 2592 [DTNMD] Symington, S., "Delay-Tolerant Networking Metadata 2593 Extension Block", 2594 draft-irtf-dtnrg-bundle-metadata-block-00.txt , June 2007. 2596 [I-D.irtf-dtnrg-iana-bp-registries] 2597 Blanchet, M., "Delay-Tolerant Networks (DTN) Bundle 2598 Protocol IANA Registries", draft-irtf-dtnrg-iana-bp- 2599 registries-00.txt, work-in-progress, April 2010. 2601 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2602 Hashing for Message Authentication", RFC 2104, 2603 February 1997. 2605 [RFC2119] Bradner, S. and J. Reynolds, "Key words for use in RFCs to 2606 Indicate Requirement Levels", RFC 2119, October 1997. 2608 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 2609 Algorithms and Identifiers for RSA Cryptography for use in 2610 the Internet X.509 Public Key Infrastructure Certificate 2611 and Certificate Revocation List (CRL) Profile", RFC 4055, 2612 June 2005. 2614 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 2615 (GCM) in IPsec Encapsulating Security Payload (ESP)", 2616 RFC 4106, June 2005. 2618 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Polk, W., and W. 2619 Ford, "Internet X.509 Public Key Infrastructure 2620 Certificate and Certificate Revocation List (CRL) 2621 Profile", RFC 5280, May 2008. 2623 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 2624 RFC 5652, July 2004. 2626 10.2. Informative References 2628 [DTNarch] Cerf, V., Burleigh, S., Durst, R., Fall, K., Hooke, A., 2629 Scott, K., Torgerson, L., and H. Weiss, "Delay-Tolerant 2630 Network Architecture", RFC 4838, April 2007. 2632 [PHIB] Symington, S., "Delay-Tolerant Networking Previous Hop 2633 Insertion Block", draft-irtf-dtnrg-bundle-previous-hop- 2634 block-11.txt, work-in-progress, February 2010. 2636 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2637 Resource Identifier (URI): Generic Syntax", RFC 3986, 2638 January 2005. 2640 [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated 2641 Encryption in the Cryptographic Message Syntax (CMS)", 2642 RFC 5084, November 2007. 2644 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 2645 Mail Extensions (S/MIME) Version 3.2 Message 2646 Specification", RFC 5751, January 2010. 2648 Authors' Addresses 2650 Susan Flynn Symington 2651 The MITRE Corporation 2652 7515 Colshire Drive 2653 McLean, VA 22102 2654 US 2656 Phone: +1 (703) 983-7209 2657 Email: susan@mitre.org 2658 URI: http://mitre.org/ 2660 Stephen Farrell 2661 Trinity College Dublin 2662 Distributed Systems Group 2663 Department of Computer Science 2664 Trinity College 2665 Dublin 2 2666 Ireland 2668 Phone: +353-1-608-1539 2669 Email: stephen.farrell@cs.tcd.ie 2671 Howard Weiss 2672 SPARTA, Inc. 2673 7110 Samuel Morse Drive 2674 Columbia, MD 21046 2675 US 2677 Phone: +1-443-430-8089 2678 Email: howard.weiss@sparta.com 2680 Peter Lovell 2681 SPARTA, Inc. 2682 7110 Samuel Morse Drive 2683 Columbia, MD 21046 2684 US 2686 Phone: +1-443-430-8052 2687 Email: dtnbsp@gmail.com