idnits 2.17.1 draft-irtf-dtnrg-bundle-security-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The sequence is maintained in the ordering of security blocks in the bundle. It is for this reason that blocks MUST not be rearranged at forwarding nodes, whether they support the security protocols or not. The only blocks that participate in this ordering are the primary and payload blocks, and the PIB and PCB security blocks themselves. All other extension blocks, including ESBs, are ignored for purposes of determining the processing order. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 21, 2010) is 5210 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3370' is defined on line 2495, but no explicit reference was found in the text == Unused Reference: 'RFC4106' is defined on line 2504, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 5050 (ref. 'DTNBP') == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-bundle-metadata-block-00 ** Downref: Normative reference to an Experimental draft: draft-irtf-dtnrg-bundle-metadata-block (ref. 'DTNMD') ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3852 (ref. 'RFC5652') (Obsoleted by RFC 5652) -- No information found for draft-irtf-dtnrg-bundle-retrans - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DTN Research Group S. Symington 3 Internet-Draft The MITRE Corporation 4 Expires: July 25, 2010 S. Farrell 5 Trinity College Dublin 6 H. Weiss 7 P. Lovell 8 SPARTA, Inc. 9 January 21, 2010 11 Bundle Security Protocol Specification 12 draft-irtf-dtnrg-bundle-security-13 14 Abstract 16 This document defines the bundle security protocol, which provides 17 data integrity and confidentiality services for the bundle protocol. 18 Separate capabilities are provided to protect the bundle payload and 19 additional data that may be included within the bundle. We also 20 describe various bundle security considerations including policy 21 options. 23 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 to IETF 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), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 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 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on July 25, 2010. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1. Related Documents . . . . . . . . . . . . . . . . . . . . 5 81 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 82 2. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 8 83 2.1. Abstract Security Block . . . . . . . . . . . . . . . . . 9 84 2.2. Bundle Authentication Block . . . . . . . . . . . . . . . 13 85 2.3. Payload Integrity Block . . . . . . . . . . . . . . . . . 14 86 2.4. Payload Confidentiality Block . . . . . . . . . . . . . . 16 87 2.5. Extension Security Block . . . . . . . . . . . . . . . . . 19 88 2.6. Parameters and Result Fields . . . . . . . . . . . . . . . 21 89 2.7. Key Transport . . . . . . . . . . . . . . . . . . . . . . 23 90 2.8. PIB and PCB combinations . . . . . . . . . . . . . . . . . 23 91 3. Security Processing . . . . . . . . . . . . . . . . . . . . . 26 92 3.1. Nodes as policy enforcement points . . . . . . . . . . . . 26 93 3.2. Processing order of security blocks . . . . . . . . . . . 26 94 3.3. Security Regions . . . . . . . . . . . . . . . . . . . . . 29 95 3.4. Canonicalisation of bundles . . . . . . . . . . . . . . . 31 96 3.5. Endpoint ID confidentiality . . . . . . . . . . . . . . . 37 97 3.6. Bundles received from other nodes . . . . . . . . . . . . 37 98 3.7. The At-Most-Once-Delivery Option . . . . . . . . . . . . . 39 99 3.8. Bundle Fragmentation and Reassembly . . . . . . . . . . . 40 100 3.9. Reactive fragmentation . . . . . . . . . . . . . . . . . . 41 101 3.10. Attack Model . . . . . . . . . . . . . . . . . . . . . . . 41 102 4. Mandatory Ciphersuites . . . . . . . . . . . . . . . . . . . . 43 103 4.1. BAB-HMAC . . . . . . . . . . . . . . . . . . . . . . . . . 43 104 4.2. PIB-RSA-SHA256 . . . . . . . . . . . . . . . . . . . . . . 44 105 4.3. PCB-RSA-AES128-PAYLOAD-PIB-PCB . . . . . . . . . . . . . . 45 106 4.4. ESB-RSA-AES128-EXT . . . . . . . . . . . . . . . . . . . . 49 107 5. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 53 108 6. Default Security Policy . . . . . . . . . . . . . . . . . . . 54 109 7. Security Considerations . . . . . . . . . . . . . . . . . . . 56 110 8. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 57 111 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 112 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 113 10.1. Normative References . . . . . . . . . . . . . . . . . . . 59 114 10.2. Informative References . . . . . . . . . . . . . . . . . . 59 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 117 1. Introduction 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 This document defines security features for the bundle protocol 124 [DTNBP] intended for use in delay tolerant networks, in order to 125 provide DTN security services. 127 The bundle protocol is used in DTNs which overlay multiple networks, 128 some of which may be challenged by limitations such as intermittent 129 and possibly unpredictable loss of connectivity, long or variable 130 delay, asymmetric data rates, and high error rates. The purpose of 131 the bundle protocol is to support interoperability across such 132 stressed networks. The bundle protocol is layered on top of 133 underlay-network-specific convergence layers, on top of network- 134 specific lower layers, to enable an application in one network to 135 communicate with an application in another network, both of which are 136 spanned by the DTN. 138 Security will be important for the bundle protocol. The stressed 139 environment of the underlying networks over which the bundle protocol 140 will operate makes it important for the DTN to be protected from 141 unauthorized use, and this stressed environment poses unique 142 challenges for the mechanisms needed to secure the bundle protocol. 143 Furthermore, DTNs may very likely be deployed in environments where a 144 portion of the network might become compromised, posing the usual 145 security challenges related to confidentiality, integrity and 146 availability. 148 Different security processing applies to the payload and extension 149 blocks that may accompany it in a bundle, and different rules apply 150 to various extension blocks. 152 This document describes both the base Bundle Security Protocol (BSP) 153 and a set of mandatory ciphersuites. A ciphersuite is a specific 154 collection of various cryptographic algorithms and implementation 155 rules that are used together to provide certain security services. 157 The Bundle Security Protocol applies, by definition, only to those 158 nodes that implement it, known as "security-aware" nodes. There MAY 159 be other nodes in the DTN that do not implement BSP. All nodes can 160 interoperate with the exception that BSP security operations can only 161 happen at security-aware nodes. 163 1.1. Related Documents 165 This document is best read and understood within the context of the 166 following other DTN documents: 168 The Delay-Tolerant Network Architecture [DTNarch] defines the 169 architecture for delay-tolerant networks, but does not discuss 170 security at any length. 172 The DTN Bundle Protocol [DTNBP] defines the format and processing 173 of the blocks used to implement the bundle protocol, excluding the 174 security-specific blocks defined here. 176 1.2. Terminology 178 We introduce the following terminology for purposes of clarity: 180 source - the bundle node from which a bundle originates 182 destination - the bundle node to which a bundle is ultimately 183 destined 185 forwarder - the bundle node that forwarded the bundle on its most 186 recent hop 188 intermediate receiver or "next hop" - the neighboring bundle node 189 to which a forwarder forwards a bundle. 191 path - the ordered sequence of nodes through which a bundle passes 192 on its way from source to destination 194 In the figure below, which is adapted from figure 1 in the Bundle 195 Protocol Specification, four bundle nodes (denoted BN1, BN2, BN3, and 196 BN4) reside above some transport layer(s). Three distinct transport 197 and network protocols (denoted T1/N1, T2/N2, and T3/N3) are also 198 shown. 200 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 201 | BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 | 202 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 203 | T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 | 204 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 205 | N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 | 206 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 207 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 208 +-----------+ +------------+ +-------------+ +-----------+ 209 | | | | 210 |<-- An Internet --->| |<--- An Internet --->| 211 | | | | 213 BN = "Bundle Node" as defined in the Bundle Protocol Specification 215 Bundle Nodes Sit at the Application layer of the Internet Model. 217 Figure 1 219 Bundle node BN1 originates a bundle that it forwards to BN2. BN2 220 forwards the bundle to BN3, and BN3 forwards the bundle to BN4. BN1 221 is the source of the bundle and BN4 is the destination of the bundle. 222 BN1 is the first forwarder, and BN2 is the first intermediate 223 receiver; BN2 then becomes the forwarder, and BN3 the intermediate 224 receiver; BN3 then becomes the last forwarder, and BN4 the last 225 intermediate receiver, as well as the destination. 227 If node BN2 originates a bundle (for example, a bundle status report 228 or a custodial signal), which is then forwarded on to BN3, and then 229 to BN4, then BN2 is the source of the bundle (as well as being the 230 first forwarder of the bundle) and BN4 is the destination of the 231 bundle (as well as being the final intermediate receiver). 233 We introduce the following security-specific DTN terminology: 235 security-source - a bundle node that adds a security block to a 236 bundle 238 security-destination - a bundle node that processes a security 239 block of a bundle 241 security path - the ordered sequence of security-aware nodes 242 through which a bundle passes on its way from the security-source 243 to the security-destination 245 Referring to Figure 1 again: 247 If the bundle that originates at BN1 as source is given a security 248 block by BN1, then BN1 is the security-source of this bundle with 249 respect to that security block, as well as being the source of the 250 bundle. 252 If the bundle that originates at BN1 as source is given a security 253 block by BN2, then BN2 is the security-source of this bundle with 254 respect to that security block, even though BN1 is the source. 256 If the bundle that originates at BN1 as source is given a security 257 block by BN1 that is intended to be processed by BN3, then BN1 is the 258 security-source and BN3 is the security destination with respect to 259 this security block. The security path for this block is BN1 to BN3. 261 A bundle MAY have multiple security blocks. The security-source of a 262 bundle with respect to a given security block in the bundle MAY be 263 the same as or different from the security-source of the bundle with 264 respect to a different security block in the bundle. Similarly, the 265 security-destination of a bundle with respect to each of that 266 bundle's security blocks MAY be the same or different. Therefore the 267 security paths for various blocks MAY be and often will be different. 269 If the bundle that originates at BN1 as source is given a security 270 block by BN1 that is intended to be processed by BN3, and BN2 adds a 271 security block with security-destination BN4, the security paths for 272 the two blocks overlap but not completely. This problem is discussed 273 further in Section 3.3. 275 As required in [DTNBP], forwarding nodes MUST transmit blocks in a 276 bundle in the same order in which they were received. This 277 requirement applies to all DTN nodes, not just ones which implement 278 security processing. Blocks in a bundle MAY be added or deleted 279 according to the applicable specification, but those blocks which are 280 both received and transmitted MUST be transmitted in the same order 281 that they were received. 283 If a node is not security-aware then it forwards the security blocks 284 in the bundle unchanged unless the bundle's block processing flags 285 specify otherwise. If a network has some nodes that are not 286 security-aware then the block processing flags SHOULD be set such 287 that security blocks are not discarded at those nodes solely because 288 they can not be processed there. Except for this, the non-security- 289 aware nodes are transparent relay points and are invisible as far as 290 security processing is concerned. 292 The block sequence also indicates the order in which certain 293 significant actions have affected the bundle, and therefore the 294 sequence in which actions MUST occur in order to produce the bundle 295 at its destination. 297 2. Security Blocks 299 There are four types of security block that MAY be included in a 300 bundle. These are the Bundle Authentication Block (BAB), the Payload 301 Integrity Block (PIB), the Payload Confidentiality Block (PCB) and 302 the Extension Security Block (ESB). 304 The BAB is used to assure the authenticity and integrity of the 305 bundle along a single hop from forwarder to intermediate receiver. 306 Since security blocks are only processed at security-aware nodes, 307 a "single hop" from a security-aware forwarder to the next 308 security-aware intermediate receiver might be more than one actual 309 hop. This situation is discussed further below Section 2.2. 311 The PIB is used to assure the authenticity and integrity of the 312 payload from the PIB security-source, which creates the PIB, to 313 the PIB security-destination, which verifies the PIB 314 authenticator. The authentication information in the PIB MAY (if 315 the ciphersuite allows) be verified by any node in between the PIB 316 security-source and the PIB security-destination that has access 317 to the cryptographic keys and revocation status information 318 required to do so. 320 Since a BAB protects a bundle on a "hop-by-hop" basis and other 321 security blocks MAY be protecting over several hops or end-to-end, 322 whenever both are present the BAB MUST form the "outer" layer of 323 protection - that is, the BAB MUST always be calculated and added 324 to the bundle after all other security blocks have been calculated 325 and added to the bundle. 327 The PCB indicates that the payload has been encrypted, in whole or 328 in part, at the PCB security-source in order to protect the bundle 329 content while in transit to the PCB security-destination. 331 PIB and PCB protect the payload and are regarded as "payload- 332 related" for purposes of the security discussion in this document. 333 Other blocks are regarded as "non-payload" blocks. Of course, the 334 primary block is unique and has separate rules. 336 The ESB provides security for non-payload blocks in a bundle. ESB 337 therefore is not applied to PIB or PCBs, and of course is not 338 appropriate for either the payload block or primary block. 340 Each of the security blocks uses the Canonical Bundle Block Format as 341 defined in the Bundle Protocol Specification. That is, each security 342 block is comprised of the following elements: 344 - Block type code 346 - Block processing control flags 348 - Block EID reference list (optional) 350 - Block data length 352 - Block-type-specific data fields 354 Since the four security blocks have most fields in common, we can 355 shorten the description of the Block-type-specific data fields of 356 each security block if we first define an abstract security block 357 (ASB) and then specify each of the real blocks in terms of the fields 358 which are present/absent in an ASB. Note that no bundle ever 359 contains an actual ASB, which is simply a specification artifact. 361 2.1. Abstract Security Block 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 379 the Bundle Protocol [DTNBP]). SDNV encoding is described in the 380 bundle protocol. There are no general constraints on the use of 381 the block processing flags, and some specific requirements are 382 discussed later. 384 - EID references - composite field defined in [DTNBP] containing 385 references to one or two EIDs. Presence of the EID-reference 386 field is indicated by the setting of the "block contains an EID- 387 reference field" (EID_REF) bit of the block processing control 388 flags. If one or more references is present, flags in the 389 ciphersuite ID field, described below, specify which. 391 If no EID fields are present then the composite field itself MUST 392 be omitted entirely and the EID_REF bit MUST be unset. A count 393 field of zero is not permitted. 395 The possible EIDs are: 397 - (optional) Security-source - specifies the security source 398 for the block. If this is omitted, then the source of the 399 bundle is assumed to be the security-source unless otherwise 400 indicated. 402 - (optional) Security-destination - specifies the security 403 destination for the block. If this is omitted, then the 404 destination of the bundle is assumed to be the security- 405 destination unless otherwise indicated. 407 If two EIDs are present, security-source is first and security- 408 destination comes second. 410 - Block data length (SDNV) - as in all bundle protocol blocks 411 except the primary bundle block. SDNV encoding is described in 412 the bundle protocol. 414 - Block-type-specific data fields as follows: 416 - Ciphersuite ID (SDNV) 418 - Ciphersuite flags (SDNV) 420 - (optional) Correlator - when more than one related block is 421 inserted then this field MUST have the same value in each 422 related block instance. This is encoded as an SDNV. See note 423 in Section 3.8 with regard to correlator values in bundle 424 fragments. 426 - (optional) Ciphersuite parameters - compound field of next 427 two items 429 - Ciphersuite parameters length - specifies the length of 430 the following Ciphersuite parameters data field and is 431 encoded as an SDNV. 433 - Ciphersuite parameters data - parameters to be used with 434 the ciphersuite in use, e.g. a key identifier or 435 initialization vector (IV). See Section 2.6 for a list of 436 potential parameters and their encoding rules. The 437 particular set of parameters that are included in this field 438 are defined as part of the ciphersuite specification. 440 - (optional) Security result - compound field of next two items 442 - Security result length - contains the length of the next 443 field and is encoded as an SDNV. 445 - Security result data - contains the results of the 446 appropriate ciphersuite-specific calculation (e.g., a 447 signature, MAC or ciphertext block key). 449 Although the diagram hints at a 32-bit layout this is purely for the 450 purpose of exposition. Except for the "type" field, all fields are 451 variable in length. 453 +----------------+----------------+----------------+----------------+ 454 | type | flags (SDNV) | EID ref list(comp) | 455 +----------------+----------------+----------------+----------------+ 456 | length (SDNV) | ciphersuite (SDNV) | 457 +----------------+----------------+----------------+----------------+ 458 | ciphersuite flags (SDNV) | correlator (SDNV) | 459 +----------------+----------------+----------------+----------------+ 460 |params len(SDNV)| ciphersuite params data | 461 +----------------+----------------+----------------+----------------+ 462 |res-len (SDNV) | security result data | 463 +----------------+----------------+----------------+----------------+ 465 The structure of an abstract security block. 467 Figure 2 469 Some ciphersuites are specified in Section 4, which also specifies 470 the rules which MUST be satisfied by ciphersuite specifications. 471 Additional ciphersuites MAY be defined in separate specifications. 472 Ciphersuite IDs not specified are reserved. Implementations of the 473 bundle security protocol decide which ciphersuites to support, 474 subject to the requirements of Section 4. It is RECOMMENDED that 475 implementations that allow additional ciphersuites permit ciphersuite 476 ID values at least up to and including 127, and they MAY decline to 477 allow larger ID values. 479 The structure of the ciphersuite flags field is shown in Figure 3. 480 In each case the presence of an optional field is indicated by 481 setting the value of the corresponding flag to one. A value of zero 482 indicates the corresponding optional field is missing. Presently 483 there are five flags defined for the field and for convenience these 484 are shown as they would be extracted from a single-byte SDNV. Future 485 additions may cause the field to grow to the left so, as with the 486 flags fields defined in [DTNBP], the description below numbers the 487 bit positions from the right rather than the standard RFC definition 488 which numbers bits from the left. 490 src - bit 4 indicates whether the EID-reference field of the ASB 491 contains the optional reference to the security-source. 493 dest - bit 3 indicates whether the EID-reference field of the ASB 494 contains the optional reference to the security-destination. 496 parm - bit 2 indicates whether the ciphersuite-parameters-length 497 and ciphersuite parameters data fields are present or not. 499 corr - bit 1 indicates whether or not the ASB contains an optional 500 correlator. 502 res - bit 0 indicates whether or not the ASB contains the security 503 result length and security result data fields. 505 bits 5-6 are reserved for future use. 507 Ciphersuite flags 508 Bit Bit Bit Bit Bit Bit Bit 509 6 5 4 3 2 1 0 510 +-----+-----+-----+-----+-----+-----+-----+ 511 | reserved |src |dest |parm |corr |res | 512 +-----+-----+-----+-----+-----+-----+-----+ 514 Figure 3 516 A little bit more terminology: if the block is a PIB then when we 517 refer to the "PIB-source", we mean the security source for the PIB as 518 represented by the EID reference in the EID-references field. 519 Similarly we may refer to the PCB-dest, meaning the security- 520 destination of the PCB, again as represented by an EID reference. 521 For example, referring to Figure 1 again, if the bundle that 522 originates at BN1 as source is given a Confidentiality Block (PCB) by 523 BN1 that is protected using a key held by BN3 and it is given a 524 Payload Integrity Block (PIB) by BN1, then BN1 is both the PCB-source 525 and the PIB-source of the bundle, and BN3 is the PCB-dest of the 526 bundle. 528 The correlator field is used to associate several related instances 529 of a security block. This can be used to place a BAB that contains 530 the ciphersuite information at the "front" of a (probably large) 531 bundle, and another correlated BAB that contains the security result 532 at the "end" of the bundle. This allows even very memory-constrained 533 nodes to be able to process the bundle and verify the BAB. There are 534 similar use cases for multiple related instances of PIB and PCB as 535 will be seen below. 537 The ciphersuite specification MUST make it clear whether or not 538 multiple block instances are allowed, and if so, under what 539 conditions. Some ciphersuites can of course leave flexibility to the 540 implementation, whereas others might mandate a fixed number of 541 instances. 543 For convenience, we use the term "first block" to refer to the 544 initial block in a group of correlated blocks, or to the single block 545 if there are no others in the set. Obviously there can be several 546 unrelated groups in a bundle, each containing only one block or more 547 than one, and each has its own "first block". 549 2.2. Bundle Authentication Block 551 In this section we describe typical BAB field values for two 552 scenarios - where a single instance of the BAB contains all the 553 information and where two related instances are used, one "up front" 554 which contains the ciphersuite and another following the payload 555 which contains the security result (e.g. a MAC). 557 For the case where a single BAB is used: 559 The block-type code field value MUST be 0x02. 561 The block processing control flags value can be set to whatever 562 values are required by local policy. Ciphersuite designers should 563 carefully consider the effect of setting flags that either discard 564 the block or delete the bundle in the event that this block cannot 565 be processed. 567 The ciphersuite ID MUST be documented as a hop-by-hop 568 authentication-ciphersuite which requires one instance of the BAB. 570 The correlator field MUST NOT be present. 572 The ciphersuite parameters field MAY be present, if so specified 573 in the ciphersuite specification. 575 An EID reference to the security-source MAY be present. The 576 security-source can also be specified as part of key information 577 described in Section 2.6 or another block such as the Previous Hop 578 Insertion Block. The security-source might also be inferred from 579 some implementation-specific means such as the convergence layer. 581 An EID reference to the security-destination MAY be present and is 582 useful to ensure that the bundle has been forwarded to the correct 583 next-hop node. 585 The security result MUST be present as it is effectively the 586 "output" from the ciphersuite calculation (e.g. the MAC or 587 signature) applied to the (relevant parts of) the bundle (as 588 specified in the ciphersuite definition). 590 For the case using two related BAB instances, the first instance is 591 as defined above, except the ciphersuite ID MUST be documented as a 592 hop-by-hop authentication ciphersuite that requires two instances of 593 the BAB. In addition, the correlator MUST be present and the 594 security result length and security result fields MUST be absent. 595 The second instance of the BAB MUST have the same correlator value 596 present and MUST contain security result length and security result 597 data fields. The other optional fields MUST NOT be present. 598 Typically, this second instance of a BAB will be the last block of 599 the bundle. 601 The details of key transport for BAB are specified by the particular 602 ciphersuite. In the absence of conflicting requirements, the 603 following should be noted by implementors: 605 - the key information item Section 2.6 is optional, and if not 606 provided then the key should be inferred from the source- 607 destination tuple, being the previous key used, a key created from 608 a key-derivation function, or a pre-shared key 610 - if all the nodes are security-aware, the capabilities of the 611 underlying convergence layer might be useful for identifying the 612 security-source 614 - depending upon the key mechanism used, bundles can be signed by 615 the sender, or authenticated for one or more recipients, or both. 617 2.3. Payload Integrity Block 619 A PIB is an ASB with the following additional restrictions: 621 The block type code value MUST be 0x03. 623 The block processing control flags value can be set to whatever 624 values are required by local policy. Ciphersuite designers should 625 carefully consider the effect of setting flags that either discard 626 the block or delete the bundle in the event that this block cannot 627 be processed. 629 The ciphersuite ID MUST be documented as an end-to-end 630 authentication-ciphersuite or as an end-to-end error-detection- 631 ciphersuite. 633 The correlator MUST be present if the ciphersuite requires more 634 than one related instance of a PIB be present in the bundle. The 635 correlator MUST NOT be present if the ciphersuite only requires 636 one instance of the PIB in the bundle. 638 The ciphersuite parameters field MAY be present. 640 An EID reference to the security-source MAY be present. The 641 security-source can also be specified as part of key information 642 described in Section 2.6. 644 An EID reference to the security-destination MAY be present. 646 The security result is effectively the "output" from the 647 ciphersuite calculation (e.g. the MAC or signature) applied to the 648 (relevant parts of) the bundle. As in the case of the BAB, this 649 field MUST be present if the correlator is absent. If more than 650 one related instance of the PIB is required then this is handled 651 in the same way as described for the BAB above. 653 The ciphersuite MAY process less than the entire original bundle 654 payload. This might be because it is defined to process some 655 subset of the bundle, or perhaps because the the current payload 656 is a fragment of an original bundle. For whatever reason, if the 657 ciphersuite processes less than the complete, original bundle 658 payload, the ciphersuite parameters of this block MUST specify 659 which bytes of the bundle payload are protected. 661 For some ciphersuites, (e.g. those using asymmetric keying to produce 662 signatures or those using symmetric keying with a group key), the 663 security information can be checked at any hop on the way to the 664 security destination that has access to the required keying 665 information. This possibility is further discussed in Section 3.6 666 below. 668 The use of a generally-available key is RECOMMENDED if custodial 669 transfer is employed and all nodes SHOULD verify the bundle before 670 accepting custody. 672 Most asymmetric PIB-ciphersuites will use the PIB-source to indicate 673 the signer and will not require the PIB-dest field because the key 674 needed to verify the PIB authenticator will be a public key 675 associated with the PIB-source. 677 2.4. Payload Confidentiality Block 679 A typical confidentiality ciphersuite will encrypt the payload using 680 a randomly generated bundle encrypting key (BEK) and will use a key 681 information item in the PCB security parameters to carry the BEK 682 encrypted with some long term key encryption key (KEK) or well-known 683 public key. If neither the destination nor security-destination 684 resolves the key to use for decryption, the key information item in 685 the ciphersuite parameters field can also be used to indicate the 686 decryption key with which the BEK can be recovered. If the bundle 687 already contains PIBs and/or PCBs these SHOULD also be encrypted 688 using this same BEK, as described just below for "super-encryption". 689 The encrypted block is encapsulated into a new PCB that replaces the 690 original block at the same place in the bundle. 692 It is strongly RECOMMENDED that a data integrity mechanism be used in 693 conjunction with confidentiality, and that encryption-only 694 ciphersuites NOT be used. AES-GCM satisfies this requirement. The 695 "authentication tag" or "integrity check value" is stored into 696 security-result rather than being appended to the payload as is 697 common in some protocols since, as described below, it is important 698 that there be no change in the size of the payload. 700 The payload is encrypted "in-place", that is, following encryption, 701 the payload block payload field contains ciphertext, not plaintext. 702 The payload block processing flags are unmodified. 704 The "in-place" encryption of payload bytes is to allow bundle payload 705 fragmentation and re-assembly, and custody transfer, to operate 706 without knowledge of whether or not encryption has occurred and, if 707 so, how many times. 709 Fragmentation and reassembly and custody transfer are adversely 710 affected by a change in size of the payload due to ambiguity about 711 what byte range of the original payload is actually in any particular 712 fragment. Ciphersuites SHOULD place any payload expansion, such as 713 authentication tags (integrity check values) and any padding 714 generated by a block-mode cipher, into an "integrity check value" 715 item in the security-result field (see Section 2.6) of the 716 confidentiality block. 718 Payload super-encryption is allowed; that is, encrypting a payload 719 that has already been encrypted, perhaps more than once. 720 Ciphersuites SHOULD define super-encryption such that, as well as re- 721 encrypting the payload, it also protects the parameters of earlier 722 encryption. Failure to do so may represent a vulnerability in some 723 circumstances. 725 Confidentiality is normally applied to the payload, and possibly to 726 additional blocks. It is RECOMMENDED to apply a Payload 727 Confidentiality ciphersuite to non-payload blocks only if these 728 should be super-encrypted with the payload. If super-encryption of 729 the block is not desired then protection of the block should be done 730 using the Extension Security Block mechanism rather than PCB. 732 Multiple related PCB instances are required if both the payload and 733 PIBs and PCBs in the bundle are to be encrypted. These multiple PCB 734 instances require correlators to associate them with each other since 735 the key information is provided only in the first PCB. 737 There are situations where more than one PCB instance is required but 738 the instances are not "related" in the sense which requires 739 correlators. One example is where a payload is encrypted for more 740 than one security-destination so as to be robust in the face of 741 routing uncertainties. In this scenario the payload is encrypted 742 using a BEK. Several PCBs contain the BEK encrypted using different 743 KEKs, one for each destination. These multiple PCB instances, are 744 not "related" and should not contain correlators. 746 The ciphersuite MAY apply different rules to confidentiality for non- 747 payload blocks. 749 A PCB is an ASB with the following additional restrictions: 751 The block type code value MUST be 0x04. 753 The block processing control flags value can be set to whatever 754 values are required by local policy, except that a PCB "first 755 block" MUST have the "replicate in every fragment" flag set. This 756 flag SHOULD NOT be set otherwise. Ciphersuite designers should 757 carefully consider the effect of setting flags that either discard 758 the block or delete the bundle in the event that this block cannot 759 be processed. 761 The ciphersuite ID MUST be documented as a confidentiality- 762 ciphersuite. 764 The correlator MUST be present if there is more than one related 765 PCB instance. The correlator MUST NOT be present if there are no 766 related PCB instances. 768 If a correlator is present, the key information MUST be placed in 769 the PCB "first block". 771 Any additional bytes generated as a result of encryption and/or 772 authentication processing of the payload SHOULD be placed in an 773 "integrity check value" field (see Section 2.6) in the security- 774 result of the first PCB. 776 The ciphersuite parameters field MAY be present. 778 An EID reference to the security-source MAY be present. The 779 security-source can also be specified as part of key information 780 described in Section 2.6. 782 An EID reference to the security-destination MAY be present. 784 The security result MAY be present and normally contains fields 785 such as an encrypted bundle encryption key, authentication tag or 786 the encrypted versions of bundle blocks other than the payload 787 block. 789 The ciphersuite MAY process less than the entire original bundle 790 payload, either because the current payload is a fragment of the 791 original bundle or just because it is defined to process some subset. 792 For whatever reason, if the ciphersuite processes less than the 793 complete, original bundle payload the "first" PCB MUST specify, as 794 part of the ciphersuite parameters, which bytes of the bundle payload 795 are protected. 797 PCB ciphersuites MUST specify which blocks are to be encrypted. The 798 specification MAY be flexible and be dependent upon block type, 799 security policy, various data values and other inputs but it MUST be 800 deterministic. The determination of whether a block is to be 801 encrypted or not MUST NOT be ambiguous. 803 As was the case for the BAB and PIB, if the ciphersuite requires more 804 than one instance of the PCB, then the "first block" MUST contain any 805 optional fields (e.g., security destination etc.) that apply to all 806 instances with this correlator. These MUST be contained in the first 807 instance and MUST NOT be repeated in other correlated blocks. Fields 808 that are specific to a particular instance of the PCB MAY appear in 809 that PCB. For example, security result fields MAY (and probably 810 will) be included in multiple related PCB instances, with each result 811 being specific to that particular block. Similarly, several PCBs 812 might each contain a ciphersuite parameters field with an IV specific 813 to that PCB instance. 815 Put another way: when confidentiality will generate multiple blocks, 816 it MUST create a "first" PCB with the required ciphersuite ID, 817 parameters etc. as specified above. Typically, this PCB will appear 818 early in the bundle. This "first" PCB contains the parameters that 819 apply to the payload and also to the other correlated PCBs. The 820 correlated PCBs follow the "first" PCB and MUST NOT repeat the 821 ciphersuite parameters, security-source, or security-destination 822 fields from the first PCB. These correlated PCBs need not follow 823 immediately after the "first" PCB, and probably will not do so. Each 824 correlated block, encapsulating an encrypted PIB or PCB, is at the 825 same place in the bundle as the original PIB or PCB. 827 A ciphersuite MUST NOT mix payload data and a non-payload block in a 828 single PCB. 830 Even if a to-be-encrypted block has the "discard" flag set, whether 831 or not the PCB's "discard" flag is set is an implementation/policy 832 decision for the encrypting node. (The "discard" flag is more 833 properly called the "discard if block cannot be processed" flag.) 835 Any existing EID-list in the to-be-encapsulated original block 836 remains exactly as-is, and is copied to become the EID-list for the 837 replacing block. The encapsulation process MUST NOT replace or 838 remove the existing EID-list entries. This is critically important 839 for correct updating of entries at the security-destination. 841 At the security-destination, either specific destination or the 842 bundle destination, the processes described above are reversed. The 843 payload is decrypted in-place using the salt, IV and key values in 844 the first PCB, including verification using the ICV. These values 845 are described below in Section 2.6. Each correlated PCB is also 846 processed at the same destination, using the salt and key values from 847 the first PCB and the block-specific IV item. The "encapsulated 848 block" item in the security-result is decrypted and validated, using 849 also the tag which SHOULD have been appended to the ciphertext of the 850 original block data. Assuming the validation succeeds, the resultant 851 plaintext, which is the entire content of the original block, 852 replaces the PCB at the same place in the bundle. The block type 853 reverts to that of the original block prior to encapsulation, and the 854 other block-specific data fields also return to their original 855 values. Implementors are cautioned that this "replacement" process 856 requires delicate stitchery, as the EID-list contents in the 857 decapsulated block are invalid. As noted above, the EID-list 858 references in the original block were preserved in the replacing PCB, 859 and will have been updated as necessary as the bundle has toured the 860 dtn. The references from the PCB MUST replace the references within 861 the EID-list of the newly-decapsulated block. Caveat implementor. 863 2.5. Extension Security Block 865 Extension security blocks provide protection for non-payload-related 866 portions of a bundle. ESBs MUST NOT be used for the primary block or 867 payload, including payload-related security blocks (PIBs and PCBs). 869 It is sometimes desirable to protect certain parts of a bundle in 870 ways other than those applied to the bundle payload. One such 871 example is bundle metadata that might specify the kind of data in the 872 payload but not the actual payload detail, as described in [DTNMD]. 874 ESBs are typically used to apply confidentiality protection. While 875 it is possible to create an integrity-only ciphersuite, the block 876 protection is not transparent and makes access to the data more 877 difficult. For simplicity, this discussion describes use of a 878 confidentiality ciphersuite. 880 The protection mechanisms in ESBs are similar to other security 881 blocks with two important differences: 883 - different key values are used (using same key as for payload 884 would defeat the purpose) 886 - the block is not encrypted or super-encrypted with the payload 888 A typical ESB ciphersuite will encrypt the extension block using a 889 randomly generated ephemeral key and will use the key information 890 item in the security parameters field to carry the key encrypted with 891 some long term key encryption key (KEK) or well-known public key. If 892 neither the destination nor security-destination resolves the key to 893 use for decryption, the key information item in the ciphersuite 894 parameters field can be used also to indicate the decryption key with 895 which the BEK can be recovered. 897 It is strongly RECOMMENDED that a data integrity mechanism be used in 898 conjunction with confidentiality, and that encryption-only 899 ciphersuites NOT be used. AES-GCM satisfies this requirement. 901 The ESB is placed in the bundle in the same position as the block 902 being protected. That is, the entire original block is processed 903 (encrypted, etc) and encapsulated in a "replacing" ESB-type block, 904 and this appears in the bundle at the same sequential position as the 905 original block. The processed data is placed in the security-result 906 field. 908 The process is reversed at the security destination with the 909 recovered plaintext block replacing the ESB that had encapsulated it. 910 Processing of EID-list entries, if any, is described above in 911 Section 2.4 and this MUST be followed in order to correctly recover 912 EIDs. 914 An ESB is an ASB with the following additional restrictions: 916 Block type is 0x09. 918 Ciphersuite flags indicate which fields are present in this block. 919 Ciphersuite designers should carefully consider the effect of 920 setting flags that either discard the block or delete the bundle 921 in the event that this block cannot be processed. 923 EID references MUST be stored in the EID reference list. 925 Security-source MAY be present. The security-source can also be 926 specified as part of key information described in Section 2.6. If 927 neither is present then the bundle-source is used as the security- 928 source. 930 Security-destination MAY be present. If not present, then the 931 bundle-destination is used as the security-destination. 933 The security-parameters MAY optionally contain a block-type field to 934 indicate the type of the encapsulated block. Since this replicates a 935 field in the encrypted portion of the block, it is a slight security 936 risk and its use is therefore OPTIONAL. 938 2.6. Parameters and Result Fields 940 Various ciphersuites include several items in the security-parameters 941 and/or security-result fields. Which items MAY appear is defined by 942 the particular ciphersuite description. A ciphersuite MAY support 943 several instances of the same type within a single block. 945 Each item is represented as type-length-value. Type is a single byte 946 indicating which item this is. Length is the count of data bytes to 947 follow, and is an SDNV-encoded integer. Value is the data content of 948 the item. 950 Item types are 952 0: reserved 954 1: initialization vector (IV) 956 2: reserved 958 3: key information 960 4: fragment range (offset and length as a pair of SDNVs) 962 5: integrity signature 963 6: reserved 965 7: salt 967 8: PCB integrity check value (ICV) 969 9: reserved 971 10: encapsulated block 973 11: block type of encapsulated block 975 12 - 191: reserved 977 192 - 250: private use 979 251 - 255: reserved 981 The folowing descriptions apply to usage of these items for all 982 ciphersuites. Additional characteristics are noted in the discussion 983 for specific suites. 985 - initialization vector(IV): random value, typically eight to 986 sixteen bytes 988 - key information: key material encoded or protected by the key 989 management system, and used to transport an ephemeral key 990 protected by a long-term key. This item is discussed further 991 below in Section 2.7 993 - fragment range: pair of SDNV values (offset then length) 994 specifying the range of payload bytes to which a particular 995 operation applies. This is termed "fragment range" since that is 996 its typical use, even though sometimes it describes a subset range 997 that is not a fragment. The offset value MUST be the offset 998 within the original bundle, which might not be the offset within 999 the current bundle if the current bundle is already a fragment 1001 - integrity signature: result of BA or PI digest or signing 1002 operation. This item is discussed further below in Section 2.7 1004 - salt: an IV-like value used by certain confidentiality suites 1006 - PCB integrity check value(ICV): output from certain 1007 confidentiality ciphersuite operations to be used at the 1008 destination to verify that the protected data has not been 1009 modified 1010 - encapsulated block: result of confidentiality operation on 1011 certain blocks, contains the ciphertext of the block and MAY also 1012 contain an integrity check value appended to the ciphertext; MAY 1013 also contain padding if required by the encryption mode; used for 1014 non-payload blocks only 1016 - block type of encapsulated block: block type code for a block 1017 that has been encapsulated in ESB 1019 2.7. Key Transport 1021 This specification endeavours to maintain separation between the 1022 security protocol and key management. However, these two interact in 1023 the transfer of key information, etc., from security-source to 1024 security-destination. The intent of the separation is to facilitate 1025 use of a variety of key management systems without a necessity to 1026 tailor a ciphersuite to each individually. 1028 The key management process deals with such things as long-term keys, 1029 specifiers for long-term keys, certificates for long-term keys and 1030 integrity signatures using long-term keys. The ciphersuite itself 1031 should not require a knowledge of these, and separation is improved 1032 if it treats these as opaque entities, to be handled by the key 1033 management process. 1035 The key management process deals specifically with the content of two 1036 of the items defined above in Section 2.6:- key information (item 1037 type 3) and integrity signature (item type 5). The ciphersuite MUST 1038 define the details and format for these items. To facilitate 1039 interoperability, it is strongly RECOMMENDED that the implementations 1040 use the appropriate definitions from Cryptographic Message Syntax 1041 (CMS) [RFC5652] and related RFCs. 1043 Many situations will require several pieces of key information. 1044 Again, ciphersuites MUST define whether they accept these packed into 1045 a single key information item and/or separated into multiple 1046 instances of key information. For interoperability, it is 1047 RECOMMENDED that ciphersuites accept these packed into a single key- 1048 information item, and that they MAY additionally choose to accept 1049 them sent as separate items. 1051 2.8. PIB and PCB combinations 1053 Given the above definitions, nodes are free to combine applications 1054 of PIB and PCB in any way they wish - the correlator value allows for 1055 multiple applications of security services to be handled separately. 1056 Since PIB and PCB apply to the payload and ESB to non-payload blocks, 1057 combinations of ESB with PIB and/or PCB are not considered. 1059 There are some obvious security problems that could arise when 1060 applying multiple services. For example, if we encrypted a payload 1061 but left a PIB security result containing a signature in the clear, 1062 payload guesses could be confirmed. 1064 We cannot, in general, prevent all such problems since we cannot 1065 assume that every ciphersuite definition takes account of every other 1066 ciphersuite definition. However, we can limit the potential for such 1067 problems by requiring that any ciphersuite which applies to one 1068 instance of a PIB or PCB, MUST be applied to all instances with the 1069 same correlator. 1071 We now list the PIB and PCB combinations which we envisage as being 1072 useful to support: 1074 Encrypted tunnels - a single bundle MAY be encrypted many times 1075 en-route to its destination. Clearly it has to be decrypted an 1076 equal number of times, but we can imagine each encryption as 1077 representing the entry into yet another layer of tunnel. This is 1078 supported by using multiple instances of PCB, but with the payload 1079 encrypted multiple times, "in-place". Depending upon the 1080 ciphersuite defintion, other blocks can and should be encrypted, 1081 as discussed above and in Section 2.4 to ensure that parameters 1082 are protected in the case of super-encryption. 1084 Multiple parallel authenticators - a single security source might 1085 wish to protect the integrity of a bundle in multiple ways. This 1086 could be required if the bundle's path is unpredictable, and if 1087 various nodes might be involved as security destinations. 1088 Similarly, if the security source cannot determine in advance 1089 which algorithms to use, then using all might be reasonable. This 1090 would result in uses of PIB which presumably all protect the 1091 payload, and which cannot in general protect one another. Note 1092 that this logic can also apply to a BAB, if the unpredictable 1093 routing happens in the convergence layer, so we also envisage 1094 support for multiple parallel uses of BAB. 1096 Multiple sequential authenticators - if some security destination 1097 requires assurance about the route that bundles have taken, then 1098 it might insist that each forwarding node add its own PIB. More 1099 likely, however would be that outbound "bastion" nodes would be 1100 configured to sign bundles as a way of allowing the sending 1101 "domain" to take accountability for the bundle. In this case, the 1102 various PIBs will likely be layered, so that each protects the 1103 earlier applications of PIB. 1105 Authenticated and encrypted bundles - a single bundle MAY require 1106 both authentication and confidentiality. Some specifications 1107 first apply the authenticator and follow this by encrypting the 1108 payload and authenticator. As noted previously in the case where 1109 the authenticator is a signature, there are security reasons for 1110 this ordering. (See the PCB-RSA-AES128-PAYLOAD-PIB-PCB 1111 ciphersuite defined later in Section 4.3.) Others apply the 1112 authenticator after encryption, that is, to the ciphertext. This 1113 ordering is generally recommended and minimizes attacks which, in 1114 some cases, can lead to recovery of the encryption key. 1116 There are no doubt other valid ways to combine PIB and PCB instances, 1117 but these are the "core" set supported in this specification. Having 1118 said that, as will be seen, the mandatory ciphersuites defined here 1119 are quite specific and restrictive in terms of limiting the 1120 flexibility offered by the correlator mechanism. This is primarily 1121 designed to keep this specification as simple as possible, while at 1122 the same time supporting the above scenarios. 1124 3. Security Processing 1126 This section describes the security aspects of bundle processing. 1128 3.1. Nodes as policy enforcement points 1130 All nodes are REQUIRED to have and enforce their own configurable 1131 security policies, whether these policies be explicit or default, as 1132 defined in Section 6. 1134 All nodes serve as Policy Enforcement Points (PEP) insofar as they 1135 enforce polices that MAY restrict the permissions of bundle nodes to 1136 inject traffic into the network. Policies MAY apply to traffic 1137 originating at the current node, traffic terminating at the current 1138 node and traffic to be forwarded by the current node to other nodes. 1139 If a particular transmission request, originating either locally or 1140 remotely, satisfies the node's policy or policies and is therefore 1141 accepted, then an outbound bundle can be created and dispatched. If 1142 not, then in its role as a PEP, the node will not create or forward a 1143 bundle. Error handling for such cases is currently considered out of 1144 scope of this document. 1146 Policy enforcing code MAY override all other processing steps 1147 described here and elsewhere in this document. For example, it is 1148 valid to implement a node which always attempts to attach a PIB. 1149 Similarly it is also valid to implement a node which always rejects 1150 all requests which imply the use of a PIB. 1152 Nodes MUST consult their security policy to determine the criteria 1153 that a received bundle ought to meet before it will be forwarded. 1154 These criteria MUST include a determination of whether or not the 1155 received bundle MUST include a valid BAB, PIB, PCB or ESB. If the 1156 bundle does not meet the node's policy criteria, then the bundle MUST 1157 be discarded and processed no further; in this case, a bundle status 1158 report indicating the failure MAY be generated. 1160 The node's policy MAY call for the node to add or subtract some 1161 security blocks. For example, it might require the node attempt to 1162 encrypt (parts of) the bundle for some security-destination, or that 1163 it add a PIB. If the node's policy requires a BAB to be added to the 1164 bundle, it MUST be added last so that the calculation of its security 1165 result MAY take into consideration the values of all other blocks in 1166 the bundle. 1168 3.2. Processing order of security blocks 1170 The processing order of security actions for a bundle is critically 1171 important for the actions to complete successfully. In general, the 1172 actions performed at the originating node MUST be executed in the 1173 reverse sequence at the destination. There are variations and 1174 exceptions, and these are noted below. 1176 The sequence is maintained in the ordering of security blocks in the 1177 bundle. It is for this reason that blocks MUST not be rearranged at 1178 forwarding nodes, whether they support the security protocols or not. 1179 The only blocks that participate in this ordering are the primary and 1180 payload blocks, and the PIB and PCB security blocks themselves. All 1181 other extension blocks, including ESBs, are ignored for purposes of 1182 determining the processing order. 1184 The security blocks are added to and removed from a bundle in a last- 1185 in-first-out (LIFO) manner, with the top of the stack immediately 1186 after the primary block. A newly-created bundle has just the primary 1187 and payload blocks, and the stack is empty. As security actions are 1188 requested for the bundle, security blocks are pushed onto the stack 1189 immediately after the primary block. The early actions have security 1190 blocks close to the payload, later actions have blocks nearer to the 1191 primary block. The actions deal with only those blocks in the bundle 1192 at the time so, for example, the first to be added processes only the 1193 payload and primary blocks, the next might process the first if it 1194 chooses and the payload and primary, and so on. The last block to be 1195 added can process all the blocks. 1197 When the bundle is received, this process is reversed and security 1198 processing begins at the top of the stack, immediately after the 1199 primary block. The security actions are performed and the block is 1200 popped from the stack. Processing continues with the next security 1201 block until finally only the payload and primary blocks remain. 1203 The simplicity of this description is undermined by various real- 1204 world requirements. Nonetheless it serves as a helpful initial 1205 framework for understanding the bundle security process. 1207 The first issue is a very common one and easy to handle. The bundle 1208 may be sent indirectly to its destination, requiring several 1209 forwarding hops to finally arrive there. Security processing happens 1210 at each node, assuming that the node supports bundle security. For 1211 the following discussion, we assume that a bundle is created and that 1212 confidentiality, then payload integrity and finally bundle 1213 authentication are applied to it. The block sequence would therefore 1214 be primary-BAB-PIB-PCB-payload. Traveling from source to destination 1215 requires going through one intermediate node, so the trip consists of 1216 two hops. 1218 When the bundle is received at the intermediate node, the receive 1219 processing validates the BAB and pops it from the stack. However the 1220 PIBs and PCBs have the final destination as their security 1221 destination, so these can't be processed and removed. The 1222 intermediate node then begins the send process with the four 1223 remaining blocks in the bundle. The outbound processing adds any 1224 security blocks required by local policy, and these are pushed on the 1225 stack immediately after the primary block, ahead of the PIB. In this 1226 example, the intermediate node adds a PIB as a signature that the 1227 bundle has passed through the node. 1229 The receive processing at the destination first handles the 1230 intermediate node's PIB and pops it, next is the originator's PIB, 1231 also popped, and finally the originator's confidentiality block which 1232 allows the payload to be decrypted and the bundle handled for 1233 delivery. 1235 DTNs in practice are likely to be more complex. The security policy 1236 for a node specifies the security requirements for a bundle. The 1237 policy will possibly cause one or more security operations to be 1238 applied to the bundle at the current node, each with its own 1239 security-destination. Application of policy at subsequent nodes 1240 might cause additional security operations, each with a security- 1241 destination. The list of security-destinations in the security 1242 blocks (BAB, PIB and PCB, not ESB) creates a partial-ordering of 1243 nodes that MUST be visited en route to the bundle destination. 1245 The bundle security scheme does not deal with security paths that 1246 overlap partially but not completely. The security policy for a node 1247 MUST avoid specifying for a bundle a security-destination that causes 1248 a conflict with any existing security-destination in that bundle. 1249 This is discussed further below in Section 3.3. 1251 The second issue relates to the reversibility of certain security 1252 process actions. In general, the actions fall into two categories: 1253 those which do not affect other parts of the bundle, and those which 1254 are fully reversible. Creating a bundle signature, for example, does 1255 not change the bundle content except for the result. The encryption 1256 performed as part of the confidentiality processing does change the 1257 bundle, but the reverse processing at the destination restores the 1258 original content. 1260 The third category is the one where the bundle content has changed 1261 slightly and in a non-destructive way, but there is no mechanism to 1262 reverse the change. The simplest example is the addition of an EID- 1263 reference to a security block. The addition of the reference causes 1264 the text to be added to the bundle's dictionary. The text may be 1265 used also by other references so removal of the block and this 1266 specific EID-reference does not cause removal of the text from the 1267 dictionary. This shortcoming is of no impact to the "sequential" or 1268 "wrapping" security schemes described above, but does cause failures 1269 with "parallel" authentication mechanisms. Solutions for this 1270 problem are implementation-specific and typically involve multi-pass 1271 processing such that blocks are added at one stage and the security 1272 results calculated at a later stage of the overall process. 1274 Certain ciphersuites have sequence requirements for their correct 1275 operation, most notably the bundle authentication ciphersuites. 1276 Processing for bundle authentication is required to happen after all 1277 other sending operations, and prior to any receive operations at the 1278 next hop node. It follows therefore that BA blocks MUST always be 1279 pushed onto the stack after all others. 1281 Although we describe the security block list as a stack, there are 1282 some blocks which are placed after the payload and therefore are not 1283 part of the stack. The BundleAuthentication ciphersuite #1 ("BA1") 1284 requires a second, correlated block to contain the security-result 1285 and this block is placed after the payload, usually as the last block 1286 in the bundle. We can apply the stack rules even to these blocks by 1287 specifying that they be added to the end of the bundle at the same 1288 time that their "owner" or "parent" block is pushed on the stack. In 1289 fact, they form a stack beginning at the payload but growing in the 1290 other direction. Also, not all blocks in the main stack have a 1291 corresponding entry in the trailing stack. The only blocks which 1292 MUST follow the payload are those mandated by ciphersuites as 1293 correlated blocks for holding a security-result. No other blocks are 1294 required to follow the payload block and it is RECOMMENDED that they 1295 NOT do so. 1297 ESBs are effectively placeholders for the blocks they encapsulate 1298 and, since those do not form part of the processing sequence 1299 described above, ESBs themselves do not either. ESBs MAY be 1300 correlated, however, so the "no reordering" requirement applies to 1301 them as well. 1303 3.3. Security Regions 1305 Each security block has a security path, as described in the 1306 discussion for Figure 1, and the paths for various blocks are often 1307 different. 1309 BA blocks are always for a single hop and these restricted paths 1310 never cause conflict. 1312 The paths for PIBs and PCBs are often from bundle source to bundle 1313 destination, to provide end-to-end protection. A bundle-source-to- 1314 bundle-destination path likewise never causes a problem. 1316 Another common scenario is for gateway-to-gateway protection of 1317 traffic between two sub-networks ("tunnel-mode"). 1319 Looking at Figure 1 and the simplified version shown in Figure 4, we 1320 can regard BN2 and BN3 as gateways connecting the two subnetworks 1321 labeled "An internet". As long as they provide security for the BN2- 1322 BN3 path, all is well. Problems begin, for example, when BN2 adds 1323 blocks with BN4 as the security-destination, and originating node BN1 1324 has created blocks with BN3 as security-destination. We now have two 1325 paths and neither is a subset of the other. 1327 This scenario should be prevented by node BN2's security policy being 1328 aware of the already-existing block with BN3 as the security 1329 destination. This policy SHOULD NOT specify a security-dest that is 1330 further distant than any existing security-dest. 1332 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 1333 | BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 | 1334 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 1335 >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ 1337 <------------- BN1 to BN3 path ------------> 1339 <------------- BN2 to BN4 path ------------> 1341 Overlapping security paths 1343 Figure 4 1345 Consider the case where the security concern is for data integrity, 1346 so the blocks are PIBs. BN1 creates one ("PIa") along with the new 1347 bundle, and BN2 pushes its own PIB "PIb" on the stack, with security- 1348 destination BN4. When this bundle arrives at BN3, the bundle blocks 1349 are 1351 primary - PIb - PIa - payload 1353 Block PIb is not destined for this node BN3 so has to be forwarded. 1354 This is the security-destination for block PIa so, after validation, 1355 it should be removed from the bundle. But that will invalidate the 1356 PIb signature when the block is checked at the final destination. 1357 The PIb signature includes the primary block, PIb itself, PIa and the 1358 payload block, so PIa MUST remain in the bundle. This is why 1359 security blocks are treated as a stack and add/remove operations are 1360 permitted only at the top-of-stack. 1362 The situation would be worse if the security concern is 1363 confidentiality, and PCBs are employed, using the confidentiality 1364 ciphersuite #3 ("PC3") described in Section 4.3. In this scenario, 1365 BN1 would encrypt the bundle with BN3 as security-destination, BN2 1366 would create an overlapping security path by super-encrypting the 1367 payload and encapsulating the PC3 block for security-destination BN4. 1368 BN3 forwards all the blocks without change. BN4 decrypts the payload 1369 from its super-encryption and decapsulates the PC3 block, only to 1370 find that it should have been processed earlier. Assuming that BN4 1371 has no access to BN3's key store, BN4 has no way to decrypt the 1372 bundle and recover the original content. 1374 As mentioned above, authors of security policy need to use care to 1375 ensure that their policies do not cause overlaps. These guidelines 1376 should prove helpful: 1378 the originator of a bundle can always specify the bundle-dest as 1379 the security-dest, and should be cautious about doing otherwise 1381 in the "tunnel-mode" scenario where two sub-networks are connected 1382 by a tunnel through a network, the gateways can each specify the 1383 other as security-dest, and should be cautious about doing 1384 otherwise 1386 BAB is never a problem because it is always only a single hop 1388 PIB for a bundle without PCB will usually specify the bundle 1389 destination as security-dest 1391 PIB for a bundle containing a PCB should specify as its security- 1392 dest the security-dest of the PCB (outermost PCB if there are more 1393 than one) 1395 3.4. Canonicalisation of bundles 1397 In order to verify a signature or MAC on a bundle the exact same 1398 bits, in the exact same order, MUST be input to the calculation upon 1399 verification as were input upon initial computation of the original 1400 signature or MAC value. Consequently, a node MUST NOT change the 1401 encoding of any URI in the dictionary field, e.g., changing the DNS 1402 part of some HTTP URL from lower case to upper case. Because bundles 1403 MAY be modified while in transit (either correctly or due to 1404 implementation errors), a canonical form of any given bundle (that 1405 contains a BAB or PIB) MUST be defined. 1407 This section defines bundle canonicalisation algorithms used in the 1408 Section 4.1 and Section 4.2 ciphersuites. Other ciphersuites can use 1409 these or define their own canonicalization procedures. 1411 3.4.1. Strict canonicalisation 1413 The first algorithm that can be used permits no changes at all to the 1414 bundle between the security-source and the security-destination. It 1415 is mainly intended for use in BAB ciphersuites. This algorithm 1416 conceptually catenates all blocks in the order presented, but omits 1417 all security result data fields in blocks of this ciphersuite type. 1418 That is, when a BA ciphersuite specifies this algorithm then we omit 1419 all BAB security results for all BA ciphersuites, when a PIB 1420 ciphersuite specifies this algorithm then we omit all PIB security 1421 results for all PI ciphersuites. All security result length fields 1422 are included, even though their corresponding security result data 1423 fields are omitted. 1425 Notes: 1427 - In the above we specify that security result data is omitted. 1428 This means that no bytes of the security result data are input. 1429 We do not set the security result length to zero. Rather, we 1430 assume that the security result length will be known to the module 1431 that implements the ciphersuite before the security result is 1432 calculated, and require that this value be in the security result 1433 length field even though the security result data itself will be 1434 omitted. 1436 - The 'res' bit of the ciphersuite ID, which indicates whether or 1437 not the security result length and security result data field are 1438 present, is part of the canonical form. 1440 - The value of the block data length field, which indicates the 1441 length of the block, is also part of the canonical form. Its 1442 value indicates the length of the entire bundle when the bundle 1443 includes the security result data field. 1445 - BABs are always added to bundles after PIBs, so when a PIB 1446 ciphersuite specifies this strict canonicalisation algorithm and 1447 the PIB is received with a bundle that also includes one or more 1448 BABs, application of strict canonicalisation as part of the PIB 1449 security result verification process requires that all BABs in the 1450 bundle be ignored entirely. 1452 3.4.2. Mutable canonicalisation 1454 This algorithm is intended to protect parts of the bundle which 1455 should not be changed in-transit. Hence it omits the mutable parts 1456 of the bundle. 1458 The basic approach is to define a canonical form of the primary block 1459 and catenate it with the security (PIBs and PCBs only) and payload 1460 blocks in the order that they will be transmitted. This algorithm 1461 ignores all other blocks, including ESBs, because it cannot be 1462 determined whether or not they will change as the bundle transits the 1463 network. In short, this canonicalization protects the payload, 1464 payload-related security blocks and parts of the primary block. 1466 Many fields in various blocks are stored as variable-length SDNVs. 1467 These are canonicalized in unpacked form, as eight-byte fixed-width 1468 fields in network byte order. The size of eight bytes is chosen 1469 because implementations MAY handle larger values as invalid, as noted 1470 in [DTNBP]. 1472 The canonical form of the primary block is shown in Figure 5. 1473 Essentially, it de-references the dictionary block, adjusts lengths 1474 where necessary and ignores flags that MAY change in transit. 1476 +----------------+----------------+----------------+----------------+ 1477 | Version | Processing flags (incl. COS and SRR) | 1478 +----------------+----------------+---------------------------------+ 1479 | Canonical primary block length | 1480 +----------------+----------------+---------------------------------+ 1481 | Destination endpoint ID length | 1482 +----------------+----------------+---------------------------------+ 1483 | | 1484 | Destination endpoint ID | 1485 | | 1486 +----------------+----------------+---------------------------------+ 1487 | Source endpoint ID length | 1488 +----------------+----------------+----------------+----------------+ 1489 | | 1490 | Source endpoint ID | 1491 | | 1492 +----------------+----------------+---------------------------------+ 1493 | Report-to endpoint ID length | 1494 +----------------+----------------+----------------+----------------+ 1495 | | 1496 | Report-to endpoint ID | 1497 | | 1498 +----------------+----------------+----------------+----------------+ 1499 | | 1500 + Creation Timestamp (2 x SDNV) + 1501 | | 1502 +---------------------------------+---------------------------------+ 1503 | Lifetime | 1504 +----------------+----------------+----------------+----------------+ 1506 The canonical form of the primary bundle block. 1508 Figure 5 1510 The fields shown in Figure 5 are: 1512 Version is the single-byte value in the primary block. 1514 Processing flags in the primary block is an SDNV, and includes the 1515 class-of-service (COS) and status report request (SRR) fields. 1516 For purposes of canonicalization, the SDNV is unpacked into a 1517 fixed-width field and some bits are masked out. The unpacked 1518 field is ANDed with mask 0x0000 0000 0007 C1BE to set to zero all 1519 reserved bits and the "bundle is a fragment" bit. 1521 Length - a four-byte value containing the length (in bytes) of 1522 this structure, in network byte order. 1524 Destination endpoint ID length and value - are the length (as a 1525 four byte value in network byte order) and value of the 1526 destination endpoint ID from the primary bundle block. The URI is 1527 simply copied from the relevant part(s) of the dictionary block 1528 and is not itself canonicalised. Although the dictionary entries 1529 contain null-terminators, the null-terminators are not included in 1530 the length or the canonicalization. 1532 Source endpoint ID length and value are handled similarly to the 1533 destination. 1535 Report-to endpoint ID length and value are handled similarly to 1536 the destination. 1538 Creation time (2 x SDNV) and Lifetime (SDNV) are simply copied 1539 from the primary block, with the SDNV values being represented as 1540 eight-byte unpacked values. 1542 Fragment offset and Total application data unit length are 1543 ignored, as is the case for the "bundle is a fragment" bit 1544 mentioned above. If the payload data to be canonicalized is less 1545 than the complete, original bundle payload, the offset and length 1546 are specified in the security-parameters. 1548 For non-primary blocks being included in the canonicalization, the 1549 block processing flags value used for canonicalization is the 1550 unpacked SDNV value with reserved and mutable bits masked to zero. 1551 The unpacked value is ANDed with mask 0x0000 0000 0000 0077 to zero 1552 reserved bits and the "last block" flag. The "last block" flag is 1553 ignored because BABs and other security blocks MAY be added for some 1554 parts of the journey but not others so the setting of this bit might 1555 change from hop to hop. 1557 Endpoint ID references in security blocks are canonicalized using the 1558 de-referenced text form in place of the reference pair. The 1559 reference count is not included, nor is the length of the endpoint ID 1560 text. 1562 The block-length is canonicalized as an eight-byte unpacked value in 1563 network byte order. If the payload data to be canonicalized is less 1564 than the complete, original bundle payload, this field contain the 1565 size of the data being canonicalized (the "effective block") rather 1566 that the actual size of the block. 1568 Payload blocks are generally canonicalized as-is with the exception 1569 that in some instances only a portion of the payload data is to be 1570 protected. In such a case, only those bytes are included in the 1571 canonical form, and additional ciphersuite parameters are required to 1572 specify which part of the payload is protected, as discussed further 1573 below. 1575 Security blocks are handled likewise, except that the ciphersuite 1576 will likely specify that the "current" security block security result 1577 field not be considered part of the canonical form. This differs 1578 from the strict canonicalisation case since we might use the mutable 1579 canonicalisation algorithm to handle sequential signatures such that 1580 signatures cover earlier ones. 1582 ESBs MUST NOT be included in the canonicalization. 1584 Notes: 1586 - The canonical form of the bundle is not transmitted. It is 1587 simply an artifact used as input to digesting. 1589 - We omit the reserved flags because we cannot determine if they 1590 will change in transit. The masks specified above will have to be 1591 revised if additional flags are defined and they need to be 1592 protected. 1594 - Our URI encoding does not preserve the "null-termination" 1595 convention from the dictionary field, nor do we separate the 1596 scheme and the scheme-specific part (SSP) as is done there. 1598 - The URI encoding will cause errors if any node rewrites the 1599 dictionary content (e.g. changing the DNS part of an HTTP URL from 1600 lower-case to upper case). This could happen transparently when a 1601 bundle is synched to disk using one set of software and then read 1602 from disk and forwarded by a second set of software. Because 1603 there are no general rules for canonicalising URIs (or IRIs), this 1604 problem may be an unavoidable source of integrity failures. 1606 - All SDNV fields here are canonicalized as eight-byte unpacked 1607 values in network byte order. Length fields are canonicalized as 1608 four-byte values in network byte order. Encoding does not need 1609 optimization since the values are never sent over the network. 1611 If a bundle is fragmented before the PIB is applied then the PIB 1612 applies to a fragment and not the entire bundle. However, the 1613 protected fragment could be subsequently further fragmented, which 1614 would leave the verifier unable to know which bytes were protected 1615 by the PIB. Even in the absence of fragmentation the same 1616 situation applies if the ciphersuite is defined to allow 1617 protection of less than the entire, original bundle payload. 1619 For this reason, PIB ciphersuites which support applying a PIB to 1620 less than the complete, original bundle payload MUST specify, as 1621 part of the ciphersuite parameters, which bytes of the bundle 1622 payload are protected. When verification occurs, only the 1623 specified range of the payload bytes are input to PIB 1624 verification. It is valid for a ciphersuite to be specified so as 1625 to only apply to entire bundles and not to fragments. A 1626 ciphersuite MAY be specified to apply to only a portion of the 1627 payload, regardless of whether the payload is a fragment or the 1628 complete original bundle payload. 1630 The same fragmentation issue applies equally to PCB ciphersuites. 1631 Ciphersuites which support applying confidentiality to fragments 1632 MUST specify, as part of the ciphersuite parameters, which bytes 1633 of the bundle payload are protected. When decrypting a fragment, 1634 only the specified bytes are processed. It is also valid for a 1635 confidentiality ciphersuite to be specified so as to only apply to 1636 entire bundles and not to fragments. 1638 This definition of mutable canonicalization assumes that endpoint IDs 1639 themselves are immutable and is unsuitable for use in environments 1640 where that assumption might be violated. 1642 The canonicalization applies to a specific bundle and not a specific 1643 payload. If a bundle is forwarded in some way, the recipient is not 1644 able to verify the original integrity signature since the the source 1645 EID will be different, and possibly other fields. 1647 The solution for either of these issues is to define and use a PIB 1648 ciphersuite having an alternate version of mutable canonicalization 1649 any fields from the primary block. 1651 3.5. Endpoint ID confidentiality 1653 Every bundle MUST contain a primary block that contains the source 1654 and destinations endpoint IDs, and others, and that cannot be 1655 encrypted. If endpoint ID confidentiality is required, then bundle- 1656 in-bundle encapsulation can solve this problem in some instances. 1658 Similarly, confidentiality requirements MAY also apply to other parts 1659 of the primary block (e.g. the current-custodian) and that is 1660 supported in the same manner. 1662 3.6. Bundles received from other nodes 1664 Nodes implementing this specification SHALL consult their security 1665 policy to determine whether or not a received bundle is required by 1666 policy to include a BAB. If the bundle has no BAB and one is not 1667 required then BAB processing on the received bundle is complete and 1668 the bundle is ready to be further processed for PIB/PCB/ESB handling 1669 or delivery or forwarding. 1671 If the bundle is required to have a BAB but does not, then the bundle 1672 MUST be discarded and processed no further. If the bundle is 1673 required to have a BAB but all of its BABs identify a different node 1674 other than the receiving node as the BAB security destination, then 1675 the bundle MUST be discarded and processed no further. 1677 If the bundle is required to have a BAB and has one or more BABs that 1678 identify the receiving node as the BAB security destination, or for 1679 which there is no security destination, then the value in the 1680 security result field(s) of the BAB(s) MUST be verified according to 1681 the ciphersuite specification. If for all such BABs in the bundle 1682 either the BAB security source cannot be determined or the security 1683 result value check fails, the bundle has failed to authenticate and 1684 the bundle MUST be discarded and processed no further. If any of the 1685 BABs present verify, or if a BAB is not required, the bundle is ready 1686 for further processing as determined by extension blocks and/or 1687 policy. 1689 BABs received in a bundle MUST be stripped before the bundle is 1690 forwarded. New BABs MAY be added as required by policy. This MAY 1691 require correcting the "last block" field of the to-be-forwarded 1692 bundle. 1694 Further processing of the bundle MUST take place in the order 1695 indicated by the various blocks from the primary block to the payload 1696 block, except as defined by an applicable specification. 1698 If the bundle has a PCB and the receiving node is the PCB destination 1699 for the bundle (either because the node is listed as the bundle's 1700 PCB-dest or because the node is listed as the bundle's destination 1701 and there is no PCB-dest), the node MUST decrypt the relevant parts 1702 of the bundle in accordance with the ciphersuite specification. The 1703 PCB SHALL be deleted. If the relevant parts of the bundle cannot be 1704 decrypted (i.e. the decryption key cannot be deduced or decryption 1705 fails), then the bundle MUST be discarded and processed no further; 1706 in this case a bundle deletion status report (see the Bundle Protocol 1707 [DTNBP]) indicating the decryption failure MAY be generated. If the 1708 PCB security result included the ciphertext of a block other than the 1709 payload block, the recovered plaintext block MUST be placed in the 1710 bundle at the location from which the PCB was deleted. 1712 If the bundle has one or more PIBs for which the receiving node is 1713 the bundle's PIB destination (either because the node is listed in 1714 the bundle's PIB-dest or because the node is listed as the bundle's 1715 destination and there is no PIB-dest), the node MUST verify the value 1716 in the PIB security result field(s) in accordance with the 1717 ciphersuite specification. If all the checks fail, the bundle has 1718 failed to authenticate and the bundle SHALL be processed according to 1719 the security policy. A bundle status report indicating the failure 1720 MAY be generated. Otherwise, if the PIB verifies, the bundle is 1721 ready to be processed for either delivery or forwarding. Before 1722 forwarding the bundle, the node SHOULD remove the PIB from the 1723 bundle, subject to the requirements of Section 3.2, unless it is 1724 likely that some downstream node will also be able to verify the PIB. 1726 If the bundle has a PIB and the receiving node is not the bundle's 1727 PIB-dest the receiving node MAY attempt to verify the value in the 1728 security result field. If it is able to check and the check fails, 1729 the node SHALL discard the bundle and it MAY send a bundle status 1730 report indicating the failure. 1732 If the bundle has an ESB and the receiving node is the ESB 1733 destination for the bundle (either because the node is listed as the 1734 bundle's ESB-dest or because the node is listed as the bundle's 1735 destination and there is no ESB-dest), the node MUST decrypt and/or 1736 decapsulate the encapsulated block in accordance with the ciphersuite 1737 specification. The decapsulated block replaces the ESB in the bundle 1738 block sequence, and the ESB is thereby deleted. If the content 1739 cannot be decrypted (i.e., the decryption key cannot be deduced or 1740 decryption fails), then the bundle MAY be discarded and processed no 1741 further unless the security policy specifies otherwise. In this case 1742 a bundle deletion status report (see the Bundle Protocol [DTNBP]) 1743 indicating the decryption failure MAY be generated. 1745 3.7. The At-Most-Once-Delivery Option 1747 An application MAY request (in an implementation specific manner) 1748 that a node be registered as a member of an endpoint and that 1749 received bundles destined for that endpoint be delivered to that 1750 application. 1752 An option for use in such cases is known as "at-most-once-delivery". 1753 If this option is chosen, the application indicates that it wants the 1754 node to check for duplicate bundles, discard duplicates, and deliver 1755 at most one copy of each received bundle to the application. If this 1756 option is not chosen, the application indicates that it wants the 1757 node to deliver all received bundle copies to the application. If 1758 this option is chosen, the node SHALL deliver at most one copy of 1759 each received bundle to the application. If the option is not 1760 chosen, the node SHOULD, subject to policy, deliver all bundles. 1762 To enforce this the node MUST look at the source/timestamp pair value 1763 of each complete (reassembled, if necessary) bundle received and 1764 determine if this pair, which uniquely identifies a bundle, has been 1765 previously received. If it has, then the bundle is a duplicate. If 1766 it has not, then the bundle is not a duplicate. The source/timestamp 1767 pair SHALL be added to the list of pair values already received by 1768 that node. 1770 Each node implementation MAY decide how long to maintain a table of 1771 pair value state. 1773 Additional discussion relevant to at-most-once-delivery is in the DTN 1774 Retransmission Block specification [DTNRB]. 1776 3.8. Bundle Fragmentation and Reassembly 1778 If it is necessary for a node to fragment a bundle and security 1779 services have been applied to that bundle, the fragmentation rules 1780 described in [DTNBP] MUST be followed. As defined there and repeated 1781 here for completeness, only the payload MAY be fragmented; security 1782 blocks, like all extension blocks, can never be fragmented. In 1783 addition, the following security-specific processing is REQUIRED: 1785 The security policy requirements for a bundle MUST be applied 1786 individually to all the bundles resulting from a fragmentation event. 1788 If the original bundle contained a PIB, then each of the PIB 1789 instances MUST be included in some fragment. 1791 If the original bundle contained one or more PCBs, then any PCB 1792 instances containing a key information item MUST have the "replicate 1793 in every fragment" flag set, and thereby be replicated in every 1794 fragment. This is to ensure that the canonical block-sequence can be 1795 recovered during reassembly. 1797 If the original bundle contained one or more correlated PCBs not 1798 containing a key information item, then each of these MUST be 1799 included in some fragment, but SHOULD NOT be sent more than once. 1800 They MUST be placed in a fragment in accordance with the 1801 fragmentation rules described in [DTNBP]. 1803 Note: various fragments MAY have additional security blocks added at 1804 this or later stages and it is possible that correlators will 1805 collide. In order to facilitate uniqueness, ciphersuites SHOULD 1806 include the fragment-offset of the fragment as a high-order component 1807 of the correlator. 1809 3.9. Reactive fragmentation 1811 When a partial bundle has been received, the receiving node SHALL 1812 consult its security policy to determine if it MAY fragment the 1813 bundle, converting the received portion into a bundle fragment for 1814 further forwarding. Whether or not reactive fragmentation is 1815 permitted SHALL depend on the security policy and the ciphersuite 1816 used to calculate the BAB authentication information, if required. 1817 (Some BAB ciphersuites, i.e., the mandatory BAB-HMAC ciphersuite 1818 defined in Section 4.1, do not accommodate reactive fragmentation 1819 because the security result in the BAB requires that the entire 1820 bundle be signed. It is conceivable, however, that a BAB ciphersuite 1821 could be defined such that multiple security results are calculated, 1822 each on a different segment of a bundle, and that these security 1823 results could be interspersed between bundle payload segments such 1824 that reactive fragmentation could be accommodated.) 1826 If the bundle is reactively fragmented by the intermediate receiver 1827 and the BAB-ciphersuite is of an appropriate type (e.g. with multiple 1828 security results embedded in the payload), the bundle MUST be 1829 fragmented immediately after the last security result value in the 1830 partial payload that is received. Any data received after the last 1831 security result value MUST be dropped. 1833 If a partial bundle is received at the intermediate receiver and is 1834 reactively fragmented and forwarded, only the part of the bundle that 1835 was not received MUST be retransmitted, though more of the bundle MAY 1836 be retransmitted. Before retransmitting a portion of the bundle, it 1837 SHALL be changed into a fragment and, if the original bundle included 1838 a BAB, the fragmented bundle MUST also, and its BAB SHALL be 1839 recalculated. 1841 This specification does not currently define any ciphersuite which 1842 can handle this reactive fragmentation case. 1844 An interesting possibility is a ciphersuite definition such that the 1845 transmission of a follow-up fragment would be accompanied by the 1846 signature for the payload up to the restart point. 1848 3.10. Attack Model 1850 An evaluation of resilience to cryptographic attack necessarily 1851 depends upon the algorithms chosen for bulk data protection and for 1852 key transport. The mandatory ciphersuites described in the following 1853 section use AES, RSA and SHA algorithms in ways that are believed to 1854 be reasonably secure against ciphertext-only, chosen-ciphertext, 1855 known-plaintext and chosen-plaintext attacks. 1857 The design has been careful to preserve the resilience of the 1858 algorithms against attack. For example, if a message is encrypted 1859 then any message integrity signature is also encrypted so that 1860 guesses cannot be confirmed. 1862 4. Mandatory Ciphersuites 1864 This section defines the mandatory ciphersuites for this 1865 specification. There is currently one mandatory ciphersuite for use 1866 with each of the security block types BAB, PIB, PCB and ESB. The BAB 1867 ciphersuite is based on shared secrets using HMAC. The PIB 1868 ciphersuite is based on digital signatures using RSA with SHA256. 1869 The PCB and ESB ciphersuites are based on using RSA for key transport 1870 and AES for bulk encryption. 1872 The key transport mechanisms defined in Cryptographic Message Syntax 1873 [RFC5652] are suitable for the ciphersuites, with only minor 1874 adjustment as required by the ciphersuite characteristics. 1876 The cryptographic algorithms used in the mandatory ciphersuites are 1877 believed to be free of intellectual property restrictions on their 1878 use. Because there is controversy regarding patent claims with 1879 regard to Elliptic Curve Crytography (ECC), the mandatory 1880 ciphersuites do not use these techniques. Implementations may choose 1881 to define additional ciphersuites using ECC and other cryptographic 1882 algorithms. 1884 4.1. BAB-HMAC 1886 The BAB-HMAC ciphersuite has ciphersuite ID value 0x001. 1888 BAB-HMAC uses the strict canonicalisation algorithm in Section 3.4.1. 1890 Strict canonicalization supports digesting of a fragment-bundle. It 1891 does not permit the digesting of only a subset of the payload, but 1892 only the complete contents of the payload of the current bundle, 1893 which might be a fragment. The "fragment range" item for security- 1894 parameters is not used to indicate a fragment, as this information is 1895 digested within the primary block. 1897 The variant of HMAC to be used is HMAC-SHA1 as defined in [RFC2104]. 1899 This ciphersuite requires the use of two related instances of the 1900 BAB. It involves placing the first BAB instance (as defined in 1901 Section 2.2) just after the primary block. The second (correlated) 1902 instance of the BAB MUST be placed after all other blocks (except 1903 possibly other BAB blocks) in the bundle. 1905 This means that normally, the BAB will be the second and last blocks 1906 of the bundle. If a forwarder wishes to apply more than one 1907 correlated BAB pair, then this can be done. There is no requirement 1908 that each application "wrap" the others, but the forwarder MUST 1909 insert all the "up front" BABs, and their "at back" "partners" 1910 (without any security result), before canonicalising. 1912 Inserting more than one correlated BAB pair would be useful if the 1913 bundle could be routed to more than one potential "next-hop" or if 1914 both an old or a new key were valid at sending time, with no 1915 certainty about the situation that will obtain at reception time. 1917 The security result is the output of the HMAC-SHA1 calculation with 1918 input being the result of running the entire bundle through the 1919 strict canonicalisation algorithm. Both required BAB instances MUST 1920 be included in the bundle before canonicalisation. 1922 Security parameters are optional with this scheme, but if used then 1923 the only field that can be present is key information (see 1924 Section 2.6). 1926 Implementations MUST support use of "AuthenticatedData" type as 1927 defined in [RFC5652] section 9.1, with RecipientInfo type 1928 KeyTransRecipientInfo containing the issuer and serial number of a 1929 suitable certificate. They MAY support additional RecipientInfo 1930 types. They MAY additionally use the "SignedData" type described in 1931 [RFC5652] Section 5.1. In either case, the optional "eContent" field 1932 in EncapsulatedContentInfo MUST be omitted. That is, the data itself 1933 is external, being the canonicalized form of the bundle. 1935 Because this ciphersuite requires that the security result be in the 1936 second, correlated BAB, the content of the 1937 "MessageAuthenticationCode" field in AuthenticatedData is ignored, 1938 although the field has to be present. 1940 In the absence of key information the receiver is expected to be able 1941 to find the correct key based on the sending identity. The sending 1942 identity MAY be known from the security-source field or the content 1943 of a previous-hop block in the bundle. It MAY also be determined 1944 using implementation-specific means such as the convergence layer. 1946 4.2. PIB-RSA-SHA256 1948 The PIB-RSA-SHA256 ciphersuite has ciphersuite ID value 0x02. 1950 If the bundle being signed has been fragmented before signing, then 1951 we have to specify which bytes were signed in case the signed bundle 1952 is subsequently fragmented for a second time. If the bundle is a 1953 fragment, then the ciphersuite parameters MUST include a fragment- 1954 range field, as described in Section 2.6, specifying the offset and 1955 length of the signed fragment. If the entire bundle is signed then 1956 these numbers MUST be omitted. 1958 Implementations MUST support use of "SignedData" type as defined in 1959 [RFC5652] section 5.1, with SignerInfo type SignerIdentifier 1960 containing the issuer and serial number of a suitable certificate. 1961 The optional "eContent" field in EncapsulatedContentInfo MUST be 1962 omitted. That is, the data itself is external, being the 1963 canonicalized form of the bundle. 1965 Because the signature field in SignedData SignatureValue is a 1966 security-result field, the entire key information item MUST be placed 1967 in the block's security-result field, rather than security- 1968 parameters. 1970 PIB-RSA-SHA256 uses the mutable canonicalisation algorithm 1971 Section 3.4.2, with the security-result data field for only the 1972 "current" block being excluded from the canonical form. The 1973 resulting canonical form of the bundle is the input to the signing 1974 process. This ciphersuite requires the use of a single instance of 1975 the PIB. 1977 RSA is used with SHA256 as specified for the id-sha256 PKCSv2.1 1978 signature scheme in [RFC4055]. The output of the signing process is 1979 the SignatureValue field for the PIB. 1981 "Commensurate strength" cryptography is generally held to be a good 1982 idea. A combination of RSA with SHA256 is reckoned to require a 3076 1983 bit RSA key according to this logic. Few implementations will choose 1984 this length by default (and probably some just won't support such 1985 long keys). Since this is an experimental protocol, we expect that 1986 1024 or 2048 bit RSA keys will be used in many cases, and that that 1987 will be fine since we also expect that the hash function "issues" 1988 will be resolved before any standard would be derived from this 1989 protocol. 1991 4.3. PCB-RSA-AES128-PAYLOAD-PIB-PCB 1993 The PCB-RSA-AES128-PAYLOAD-PIB-PCB ciphersuite has ciphersuite ID 1994 value 0x003. 1996 This scheme encrypts PIBs, PCBs and the payload. The key size for 1997 this ciphersuite is 128 bits. 1999 Encryption is done using the AES algorithm in Galois/Counter Mode 2000 (GCM) as described in [RFC5084] [Note: parts of the following 2001 description are borrowed from RFC 4106]. 2003 The choice of GCM avoids expansion of the payload, which causes 2004 problems with fragmentation/reassembly and custody transfer. GCM 2005 also includes authentication, essential in preventing attacks that 2006 can alter the decrypted plaintext or even recover the encryption key. 2008 GCM is a block cipher mode of operation providing both 2009 confidentiality and data integrity. The GCM encryption operation has 2010 four inputs: a secret key, an initialization vector (IV), a 2011 plaintext, and an input for additional authenticated data (AAD) which 2012 is not used here. It has two outputs, a ciphertext whose length is 2013 identical to the plaintext, and an authentication tag, also known as 2014 the Integrity Check Value (ICV). 2016 For consistency with the description in [RFC5084], we refer to the 2017 GCM IV as a nonce. The same key and nonce combination MUST NOT be 2018 used more than once. The nonce has the following layout 2020 +----------------+----------------+----------------+----------------+ 2021 | salt | 2022 +----------------+----------------+----------------+----------------+ 2023 | | 2024 | initialization vector | 2025 | | 2026 +----------------+----------------+----------------+----------------+ 2028 Nonce format. 2030 Figure 6 2032 The salt field is a four-octet value, usually chosen at random. It 2033 MUST be the same for all PCBs which have the same correlator value. 2034 The salt need not be kept secret. 2036 The initialization vector (IV) is an eight-octet value, usually 2037 chosen at random. It MUST be different for all PCBs which have the 2038 same correlator value. The value need not be kept secret. 2040 The key (bundle encryption key, BEK) is a sixteen-octet (128 bits) 2041 value, usually chosen at random. The value MUST be kept secret, as 2042 described below. 2044 The integrity check value is a sixteen-octet value used to verify 2045 that the protected data has not been altered. The value need not be 2046 kept secret. 2048 This ciphersuite requires the use of a single PCB instance to deal 2049 with payload confidentiality. If the bundle already contains PIBs or 2050 PCBs then the ciphersuite will create additional correlated blocks to 2051 protect these PIBs and PCBs. These "additional" blocks replace the 2052 original blocks on a one-for-one basis, so the number of blocks 2053 remains unchanged. All these related blocks MUST have the same 2054 correlator value. The term "first PCB" in this section refers to the 2055 single PCB if there is only one or, if there are several, then to the 2056 one containing the key information. This MUST be the first of the 2057 set. 2059 First PCB - the first PCB MAY contain a correlator value, and MAY 2060 specify security-source and/or security-destination in the EID-list. 2061 If not specified, the bundle-source and bundle-destination 2062 respectively are used for these values, as with other ciphersuites. 2063 The block MUST contain security-parameters and security-result 2064 fields. Each field MAY contain several items formatted as described 2065 in Section 2.6. 2067 Security-parameters 2069 key information 2071 salt 2073 IV (this instance applies only to payload) 2075 fragment offset and length, if bundle is a fragment 2077 Security-result 2079 ICV 2081 Subsequent PCBs MUST contain a correlator value to link them to the 2082 first PCB. Security-source and security-destination are implied from 2083 the first PCB, however see the discussion in Section 2.4 concerning 2084 EID-list entries. They MUST contain security-parameters and 2085 security-result fields as follows: 2087 Security-parameters 2089 IV for this specific block 2091 Security-result 2093 encapsulated block 2095 The security-parameters and security-result fields in the subsequent 2096 PCBs MUST NOT contain any items other than these two. Items such as 2097 key and salt are supplied in the first PCB and MUST NOT be repeated. 2099 Implementations MUST support use of "Enveloped-data" type as defined 2100 in [RFC5652] section 6, with RecipientInfo type KeyTransRecipientInfo 2101 containing the issuer and serial number of a suitable certificate. 2102 They MAY support additional RecipientInfo types. The optional 2103 "eContent" field in EncryptedContentInfo MUST be omitted. That is, 2104 the data itself is external, being the payload of the bundle. 2106 The Integrity Check Value from the AES-GCM encryption of the payload 2107 is placed in the security-result field of the first PCB. 2109 If the bundle being encrypted is a fragment-bundle we have to specify 2110 which bytes are encrypted in case the bundle is subsequently 2111 fragmented again. If the bundle is a fragment the ciphersuite 2112 parameters MUST include a fragment-range field, as described in 2113 Section 2.6, specifying the offset and length of the encrypted 2114 fragment. Note that this is not the same pair of fields which appear 2115 in the primary block as "offset and length". The "length" in this 2116 case is the length of the fragment, not the original length. If the 2117 bundle is not a fragment then this field MUST be omitted. 2119 The confidentiality processing for payload and other blocks is 2120 different, mainly because the payload might be fragmented later at 2121 some other node. 2123 For the payload, only the bytes of the bundle payload field are 2124 affected, being replaced by ciphertext. The salt, IV and key values 2125 specified in the first PCB are used to encrypt the payload, and the 2126 resultant authentication tag (ICV) is placed in an ICV item in the 2127 security-result field of that first PCB. The other bytes of the 2128 payload block, such as type, flags and length, are not modified. 2130 For each PIB or PCB to be protected, the entire original block is 2131 encapsulated in a "replacing" PCB. This replacing PCB is placed in 2132 the outgoing bundle in the same position as the original block, PIB 2133 or PCB. As mentioned above, this is one-for-one replacement and 2134 there is no consolidation of blocks or mixing of data in any way. 2136 The encryption process uses AES-GCM with the salt and key values from 2137 the first PCB, and an IV unique to this PCB. The process creates 2138 ciphertext for the entire original block, and an authentication tag 2139 for validation at the security destination. For this encapsulation 2140 process, unlike the processing of the bundle payload, the 2141 authentication tag is appended to the ciphertext for the block and 2142 the combination is stored into the "encapsulated block" item in 2143 security-result. 2145 The replacing block, of course, also has the same correlator value as 2146 the first PCB with which it is associated. It also contains the 2147 block-specific IV in security-parameters, and the combination of 2148 original-block-ciphertext and authentication tag, stored as an 2149 "encapsulated block" item in security-result. 2151 If the payload was fragmented after encryption then all those 2152 fragments MUST be present and reassembled before decryption. This 2153 process might be repeated several times at different destinations if 2154 multiple fragmentation actions have occurred. 2156 The size of the GCM counter field limits the payload size to 2^39 - 2157 256 bytes, about half a terabyte. A future revision of this 2158 specification will address the issue of handling payloads in excess 2159 of this size. 2161 4.4. ESB-RSA-AES128-EXT 2163 The ESB-RSA-AES128-EXT ciphersuite has ciphersuite ID value 0x004. 2165 This scheme encrypts non-payload-related blocks. It MUST NOT be used 2166 to encrypt PIBs, PCBs or primary or payload blocks. The key size for 2167 this ciphersuite is 128 bits. 2169 Encryption is done using the AES algorithm in Galois/Counter Mode 2170 (GCM) as described in [RFC5084] [Note: parts of the following 2171 description are borrowed from RFC 4106]. 2173 GCM is a block cipher mode of operation providing both 2174 confidentiality and data origin authentication. The GCM 2175 authenticated encryption operation has four inputs: a secret key, an 2176 initialization vector (IV), a plaintext, and an input for additional 2177 authenticated data (AAD) which is not used here. It has two outputs, 2178 a ciphertext whose length is identical to the plaintext, and an 2179 authentication tag, also known as the Integrity Check Value (ICV). 2181 For consistency with the description in [RFC5084], we refer to the 2182 GCM IV as a nonce. The same key and nonce combination MUST NOT be 2183 used more than once. The nonce has the following layout 2184 +----------------+----------------+---------------------------------+ 2185 | salt | 2186 +----------------+----------------+---------------------------------+ 2187 | | 2188 | initialization vector | 2189 | | 2190 +----------------+----------------+---------------------------------+ 2192 Nonce format. 2194 Figure 7 2196 The salt field is a four-octet value, usually chosen at random. It 2197 MUST be the same for all ESBs which have the same correlator value. 2198 The salt need not be kept secret. 2200 The initialization vector (IV) is an eight-octet value, usually 2201 chosen at random. It MUST be different for all ESBs which have the 2202 same correlator value. The value need not be kept secret. 2204 The data encryption key is a sixteen-octet (128 bits) value, usually 2205 chosen at random. The value MUST be kept secret, as described below. 2207 The integrity check value is a sixteen-octet value used to verify 2208 that the protected data has not been altered. The value need not be 2209 kept secret. 2211 This ciphersuite replaces each BP extension block to be protected 2212 with a "replacing" ESB, and each can be individually specified. 2214 If a number of related BP extension blocks are to be protected they 2215 can be grouped as a correlated set and protected using a single key. 2216 These blocks replace the original blocks on a one-for-one basis, so 2217 the number of blocks remains unchanged. All these related blocks 2218 MUST have the same correlator value. The term "first ESB" in this 2219 section refers to the single ESB if there is only one or, if there 2220 are several, then to the one containing the key or key-identifier. 2221 This MUST be the first of the set. If the blocks are individually 2222 specified then there is no correlated set and each block is its own 2223 "first ESB". 2225 First ESB - the first ESB MAY contain a correlator value, and MAY 2226 specify security-source and/or security-destination in the EID-list. 2227 If not specified, the bundle-source and bundle-destination 2228 respectively are used for these values, as with other ciphersuites. 2229 The block MUST contain security-parameters and security-result 2230 fields. Each field MAY contain several items formatted as described 2231 in Section 2.6. 2233 Security-parameters 2235 key information 2237 salt 2239 IV for this specific block 2241 block type of encapsulated block (optional) 2243 Security-result 2245 encapsulated block 2247 Subsequent ESBs MUST contain a correlator value to link them to the 2248 first ESB. Security-source and security-destination are implied from 2249 the first ESB, however see the discussion in Section 2.4 concerning 2250 EID-list entries. Subsequent ESBs MUST contain security-parameters 2251 and security-result fields as follows: 2253 Security-parameters 2255 IV for this specific block 2257 block type of encapsulated block (optional) 2259 Security-result 2261 encapsulated block 2263 The security-parameters and security-result fields in the subsequent 2264 ESBs MUST NOT contain any items other than those listed. Items such 2265 as key and salt are supplied in the first ESB and MUST NOT be 2266 repeated. 2268 Implementations MUST support use of "Enveloped-data" type as defined 2269 in [RFC5652] section 6, with RecipientInfo type KeyTransRecipientInfo 2270 containing the issuer and serial number of a suitable certificate. 2271 They MAY support additional RecipientInfo types. The optional 2272 "eContent" field in EncryptedContentInfo MUST be omitted. That is, 2273 the data itself is external, being the content of the block being 2274 protected. 2276 For each block to be protected, the entire original block is 2277 encapsulated in a "replacing" ESB. This replacing ESB is placed in 2278 the outgoing bundle in the same position as the original block. As 2279 mentioned above, this is one-for-one replacement and there is no 2280 consolidation of blocks or mixing of data in any way. 2282 The encryption process uses AES-GCM with the salt and key values from 2283 the first ESB, and an IV unique to this ESB. The process creates 2284 ciphertext for the entire original block, and an authentication tag 2285 for validation at the security destination. The authentication tag 2286 is appended to the ciphertext for the block and the combination is 2287 stored into the "encapsulated block" item in security-result. 2289 The replacing block, of course, also has the same correlator value as 2290 the first ESB with which it is associated. It also contains the 2291 block-specific IV in security-parameters, and the combination of 2292 original-block-ciphertext and authentication tag, stored as an 2293 "encapsulated block" item in security-result. 2295 5. Key Management 2297 Key management in delay tolerant networks is recognized as a 2298 difficult topic and is one that this specification does not attempt 2299 to solve. However, solely in order to support implementation and 2300 testing, implementations SHOULD support: 2302 - The use of well-known RSA public keys for all ciphersuites. 2304 - Long-term pre-shared-symmetric keys for the BAB-HMAC 2305 ciphersuite. 2307 Since endpoint IDs are URIs and URIs can be placed in X.509 [RFC3280] 2308 public key certificates (in the subjectAltName extension) 2309 implementations SHOULD support this way of distributing public keys. 2310 Implementations SHOULD NOT be very strict in how they process X.509 2311 though, for example, it would probably not be correct to insist on 2312 Certificate Revocation List (CRL) checking in many DTN contexts. 2314 6. Default Security Policy 2316 Every node serves as a Policy Enforcement Point insofar as it 2317 enforces some policy that controls the forwarding and delivery of 2318 bundles via one or more convergence layer protocol implementation. 2319 Consequently, every node SHALL have and operate according to its own 2320 configurable security policy, whether the policy be explicit or 2321 default. The policy SHALL specify: 2323 Under what conditions received bundles SHALL be forwarded. 2325 Under what conditions received bundles SHALL be required to 2326 include valid BABs. 2328 Under what conditions the authentication information provided in a 2329 bundle's BAB SHALL be deemed adequate to authenticate the bundle. 2331 Under what conditions received bundles SHALL be required to have 2332 valid PIBs and/or PCBs. 2334 Under what conditions the authentication information provided in a 2335 bundle's PIB SHALL be deemed adequate to authenticate the bundle. 2337 Under what conditions a BAB SHALL be added to a received bundle 2338 before that bundle is forwarded. 2340 Under what conditions a PIB SHALL be added to a received bundle 2341 before that bundle is forwarded. 2343 Under what conditions a PCB SHALL be added to a received bundle 2344 before that bundle is forwarded. 2346 Under what conditions an ESB SHALL be applied to one or more 2347 blocks in a received bundle before that bundle is forwarded. 2349 The actions that SHALL be taken in the event that a received 2350 bundle does not meet the receiving node's security policy 2351 criteria. 2353 This specification does not address how security policies get 2354 distributed to nodes. It only REQUIRES that nodes have and enforce 2355 security policies. 2357 If no security policy is specified at a given node, or if a security 2358 policy is only partially specified, that node's default policy 2359 regarding unspecified criteria SHALL consist of the following: 2361 Bundles that are not well-formed do not meet the security policy 2362 criteria. 2364 The mandatory ciphersuites MUST be used. 2366 All bundles received MUST have a BAB which MUST be verified to 2367 contain a valid security result. If the bundle does not have a 2368 BAB, then the bundle MUST be discarded and processed no further; a 2369 bundle status report indicating the authentication failure MAY be 2370 generated. 2372 No received bundles SHALL be required to have a PIB; if a received 2373 bundle does have a PIB, however, the PIB can be ignored unless the 2374 receiving node is the PIB-dest, in which case the PIB MUST be 2375 verified. 2377 No received bundles SHALL be required to have a PCB; if a received 2378 bundle does have a PCB, however, the PCB can be ignored unless the 2379 receiving node is the PCB-dest, in which case the PCB MUST be 2380 processed. If processing of a PCB yields a PIB, that PIB SHALL be 2381 processed by the node according to the node's security policy. 2383 A PIB SHALL NOT be added to a bundle before sourcing or forwarding 2384 it. 2386 A PCB SHALL NOT be added to a bundle before sourcing or forwarding 2387 it. 2389 A BAB MUST always be added to a bundle before that bundle is 2390 forwarded. 2392 If a destination node receives a bundle that has a PIB-dest but 2393 the value in that PIB-dest is not the EID of the destination node, 2394 the bundle SHALL be delivered at that destination node. 2396 If a destination node receives a bundle that has an ESB-dest but 2397 the value in that ESB-dest is not the EID of the destination node, 2398 the bundle SHALL be delivered at that destination node. 2400 If a received bundle does not satisfy the node's security policy 2401 for any reason, then the bundle MUST be discarded and processed no 2402 further; in this case, a bundle deletion status report (see the 2403 Bundle Protocol [DTNBP]) indicating the failure MAY be generated. 2405 7. Security Considerations 2407 If a BAB ciphersuite uses digital signatures but doesn't include the 2408 security destination (which for a BAB is the next host), then this 2409 allows the bundle to be sent to some node other than the intended 2410 adjacent node. Because the BAB will still authenticate, the 2411 receiving node might erroneously accept and forward the bundle. When 2412 asymmetric BAB ciphersuites are used, the security destination field 2413 SHOULD therefore be included in the BAB. 2415 If a bundle's PIB-dest is not the same as its destination, then some 2416 node other than the destination (the node identified as the PIB-dest) 2417 is expected to validate the PIB security result while the bundle is 2418 en route. However, if for some reason the PIB is not validated, 2419 there is no way for the destination to become aware of this. 2420 Typically, a PIB-dest will remove the PIB from the bundle after 2421 verifying the PIB and before forwarding it. However, if there is a 2422 possibility that the PIB will also be verified at a downstream node, 2423 the PIB-dest will leave the PIB in the bundle. Therefore, if a 2424 destination receives a bundle with a PIB that has a PIB-dest (which 2425 isn't the destination), this might, but does not necessarily, 2426 indicate a possible problem. 2428 If a bundle is fragmented after being forwarded by its PIB-source but 2429 before being received by its PIB-dest, the payload in the bundle MUST 2430 be reassembled before validating the PIB security result in order for 2431 the security result to validate correctly. Therefore, if the PIB- 2432 dest is not capable of performing payload reassembly, its utility as 2433 a PIB-dest will be limited to validating only those bundles that have 2434 not been fragmented since being forwarded from the PIB-source. 2435 Similarly, if a bundle is fragmented after being forwarded by its 2436 PIB-source but before being received by its PIB-dest, all fragments 2437 MUST be received at that PIB-dest in order for the bundle payload to 2438 be able to be reassembled. If not all fragments are received at the 2439 PIB-dest node, the bundle will not be able to be authenticated, and 2440 will therefore never be forwarded by this PIB-dest node. 2442 Specification of a security-destination other than the bundle 2443 destination creates a routing requirement that the bundle somehow be 2444 directed to the security-destination node on its way to the final 2445 destination. This requirement is presently private to the 2446 ciphersuite, since routing nodes are not required to implement 2447 security processing. 2449 8. Conformance 2451 As indicated above, this document describes both BSP and 2452 ciphersuites. A conformant implementation MUST implement both BSP 2453 support and the four ciphersuites described in Section 4. It MAY 2454 also support other ciphersuites. 2456 Implementations that support BSP but not all four mandatory 2457 ciphersuites MUST claim only "restricted compliance" with this 2458 specification, even if they provide other ciphersuites. 2460 All implementations are strongly RECOMMENDED to provide at least a 2461 BAB ciphersuite. A relay node, for example, might not deal with end- 2462 to-end confidentiality and data integrity but it SHOULD exclude 2463 unauthorized traffic and perform hop-by-hop bundle verification. 2465 9. IANA Considerations 2467 None at this time. If the bundle protocol becomes a standards track 2468 protocol, then we may want to consider having IANA establish a 2469 register of block types, and in particular for this specification a 2470 separate register of ciphersuite specifications. 2472 10. References 2474 10.1. Normative References 2476 [DTNBP] Scott, K. and S. Burleigh, "Bundle Protocol 2477 Specification", RFC 5050, November 2007. 2479 [DTNMD] Symington, S., "Delay-Tolerant Networking Metadata 2480 Extension Block", 2481 draft-irtf-dtnrg-bundle-metadata-block-00.txt , June 2007. 2483 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2484 Hashing for Message Authentication", RFC 2104, 2485 February 1997. 2487 [RFC2119] Bradner, S. and J. Reynolds, "Key words for use in RFCs to 2488 Indicate Requirement Levels", RFC 2119, October 1997. 2490 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 2491 X.509 Public Key Infrastructure Certificate and 2492 Certificate Revocation List (CRL) Profile", RFC 3280, 2493 April 2002. 2495 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 2496 Algorithms", RFC 3370, August 2002. 2498 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 2499 Algorithms and Identifiers for RSA Cryptography for use in 2500 the Internet X.509 Public Key Infrastructure Certificate 2501 and Certificate Revocation List (CRL) Profile", RFC 4055, 2502 June 2005. 2504 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 2505 (GCM) in IPsec Encapsulating Security Payload (ESP)", 2506 RFC 4106, June 2005. 2508 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 2509 RFC 3852, July 2004. 2511 10.2. Informative References 2513 [DTNRB] Symington, S., "Delay-Tolerant Network Retransmission 2514 Block", 2515 draft-irtf-dtnrg-bundle-retrans-00.txt, work-in-progress, 2516 April 2007. 2518 [DTNarch] Cerf, V., Burleigh, S., Durst, R., Fall, K., Hooke, A., 2519 Scott, K., Torgerson, L., and H. Weiss, "Delay-Tolerant 2520 Network Architecture", RFC 4838, April 2007. 2522 [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated 2523 Encryption in the Cryptographic Message Syntax (CMS)", 2524 RFC 5084, November 2007. 2526 Authors' Addresses 2528 Susan Flynn Symington 2529 The MITRE Corporation 2530 7515 Colshire Drive 2531 McLean, VA 22102 2532 US 2534 Phone: +1 (703) 983-7209 2535 Email: susan@mitre.org 2536 URI: http://mitre.org/ 2538 Stephen Farrell 2539 Trinity College Dublin 2540 Distributed Systems Group 2541 Department of Computer Science 2542 Trinity College 2543 Dublin 2 2544 Ireland 2546 Phone: +353-1-608-1539 2547 Email: stephen.farrell@cs.tcd.ie 2549 Howard Weiss 2550 SPARTA, Inc. 2551 7110 Samuel Morse Drive 2552 Columbia, MD 21046 2553 US 2555 Phone: +1-443-430-8089 2556 Email: hsw@sparta.com 2558 Peter Lovell 2559 SPARTA, Inc. 2560 7110 Samuel Morse Drive 2561 Columbia, MD 21046 2562 US 2564 Phone: +1-443-430-8052 2565 Email: peter.lovell@sparta.com