idnits 2.17.1 draft-irtf-dtnrg-bundle-security-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1610. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1621. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1628. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1634. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 24, 2007) is 6211 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) == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-bundle-spec-09 ** Downref: Normative reference to an Experimental draft: draft-irtf-dtnrg-bundle-spec (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '3') ** Obsolete normative reference: RFC 3280 (ref. '7') (Obsoleted by RFC 5280) == Outdated reference: A later version (-06) exists of draft-irtf-dtnrg-sec-overview-03 -- No information found for draft-irtf-dtnrg-bundle-retrans - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 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: October 26, 2007 S. Farrell 5 Trinity College Dublin 6 H. Weiss 7 P. Lovell 8 SPARTA, Inc. 9 April 24, 2007 11 Bundle Security Protocol Specification 12 draft-irtf-dtnrg-bundle-security-03 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on October 26, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document defines the bundle security protocol, which provides 46 data integrity and confidentiality services. We also describe 47 various bundle security considerations including policy options. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Related Documents . . . . . . . . . . . . . . . . . . . . 3 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 6 55 2.1. Abstract Security Block . . . . . . . . . . . . . . . . . 7 56 2.2. Bundle Authentication Block . . . . . . . . . . . . . . . 10 57 2.3. Payload Security Block . . . . . . . . . . . . . . . . . . 11 58 2.4. Confidentiality Block . . . . . . . . . . . . . . . . . . 12 59 2.5. PSB and CB combinations . . . . . . . . . . . . . . . . . 14 60 3. Security Processing . . . . . . . . . . . . . . . . . . . . . 16 61 3.1. Nodes as policy enforcement points . . . . . . . . . . . . 16 62 3.2. Canonicalisation of bundles . . . . . . . . . . . . . . . 16 63 3.3. Endpoint ID confidentiality . . . . . . . . . . . . . . . 22 64 3.4. Bundles received from other nodes . . . . . . . . . . . . 22 65 3.5. The At-Most-Once-Delivery Option . . . . . . . . . . . . . 24 66 3.6. Bundle Fragmentation and Reassembly . . . . . . . . . . . 24 67 3.7. Reactive fragmentation . . . . . . . . . . . . . . . . . . 25 68 4. Mandatory Ciphersuites . . . . . . . . . . . . . . . . . . . . 27 69 4.1. BAB-HMAC . . . . . . . . . . . . . . . . . . . . . . . . . 27 70 4.2. PSB-RSA-SHA256 . . . . . . . . . . . . . . . . . . . . . . 28 71 4.3. CB-RSA-AES128-PAYLOAD-PSB . . . . . . . . . . . . . . . . 28 72 5. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 30 73 6. Default Security Policy . . . . . . . . . . . . . . . . . . . 31 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 35 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 35 79 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 81 Intellectual Property and Copyright Statements . . . . . . . . . . 39 83 1. Introduction 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [1]. 89 This document defines security features for the bundle protocol [2] 90 intended for use in delay tolerant networks, in order to provide the 91 DTN security services as described in the DTN Security Overview and 92 Motivations document [8]. 94 The bundle protocol is used in DTNs which overlay multiple networks, 95 some of which may be challenged by limitations such as intermittent 96 and possibly unpredictable loss of connectivity, long or variable 97 delay, asymmetric data rates, and high error rates. The purpose of 98 the bundle protocol is to support interoperability across such 99 stressed networks. The bundle protocol is layered on top of 100 underlay-network-specific convergence layers, on top of network- 101 specific lower layers, to enable an application in one network to 102 communicate with an application in another network, both of which are 103 spanned by the DTN. 105 Security will be important for the bundle protocol. The stressed 106 environment of the underlying networks over which the bundle protocol 107 will operate makes it important that the DTN be protected from 108 unauthorized use, and this stressed environment poses unique 109 challenges on the mechanisms needed to secure the bundle protocol. 110 Furthermore, DTNs may very likely be deployed in environments where a 111 portion of the network might become compromised, posing the usual 112 security challenges related to confidentiality, integrity and 113 availability. 115 1.1. Related Documents 117 This document is best read and understood within the context of the 118 following other DTN documents: 120 The Delay-Tolerant Network Architecture [9] defines the 121 architecture for delay-tolerant networks, but does not discuss 122 security at any length. 124 The DTN Bundle Protocol [2] defines the format and processing of 125 the blocks used to implement the bundle protocol, excluding the 126 security-specific blocks defined here. 128 The Delay-Tolerant Networking Security Overview [8] provides an 129 informative overview and high-level description of DTN security. 131 1.2. Terminology 133 We introduce the following terminology for purposes of clarity: 135 source - the bundle node from which a bundle originates 137 destination - the bundle node to which a bundle is ultimately 138 destined 140 forwarder - the bundle node that forwarded the bundle on its most 141 recent hop 143 intermediate receiver or "next hop" - the neighboring bundle node 144 to which a forwarder forwards a bundle. 146 In the figure below, which is adapted from figure 1 in the Bundle 147 Protocol Specification, four bundle nodes (denoted BN1, BN2, BN3, and 148 BN4) reside above some transport layer(s). Three distinct transport 149 and network protocols (denoted T1/N1, T2/N2, and T3/N3) are also 150 shown. 152 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 153 |BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 | 154 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 155 |Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 | 156 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 157 |Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 | 158 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 159 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 160 +-----------+ +------------+ +-------------+ +-----------+ 161 | | | | 162 |<-- An Internet --->| |<--- An Internet --->| 163 | | | | 165 BN = "Bundle Node" (as defined in the Bundle Protocol Specification 167 Bundle Nodes Sit at the Application layer of the Internet Model. 169 Figure 1 171 Bundle node BN1 originates a bundle that it forwards to BN2. BN2 172 forwards the bundle to BN3, and BN3 forwards the bundle to BN4. BN1 173 is the source of the bundle and BN4 is the destination of the bundle. 174 BN1 is the first forwarder, and BN2 is the first intermediate 175 receiver; BN2 then becomes the forwarder, and BN3 the intermediate 176 receiver; BN3 then becomes the last forwarder, and BN4 the last 177 intermediate receiver, as well as the destination. 179 If node BN2 originates a bundle (for example, a bundle status report 180 or a custodial signal), which is then forwarded on to BN3, and then 181 to BN4, then BN2 is the source of the bundle (as well as being the 182 first forwarder of the bundle) and BN4 is the destination of the 183 bundle (as well as being the final intermediate receiver). 185 We introduce the following security-specific DTN terminology: 187 security-source - a bundle node that adds a security block to a 188 bundle 190 security-destination - a bundle node that processes a security 191 block of a bundle 193 Referring to figure 1 again: 195 If the bundle that originates at BN1 as source is given a security 196 block by BN1, then BN1 is the security-source of this bundle with 197 respect to that security block, as well as being the source of the 198 bundle. 200 If the bundle that originates at BN1 as source is given a security 201 block by BN2, then BN2 is the security-source of this bundle with 202 respect to that security block, even though BN1 is the source. 204 If the bundle that originates at BN1 as source is given a security 205 block by BN1 that is intended to be processed by BN3, then BN1 is the 206 security-source and BN3 is the security destination with respect to 207 this security block. 209 A bundle may have multiple security blocks. The security-source of a 210 bundle with respect to a given security block in the bundle may be 211 the same as or different from the security-source of the bundle with 212 respect to a different security block in the bundle. Similarly, the 213 security-destination of a bundle with respect to each of that 214 bundle's security blocks may be the same or different. 216 Forwarding nodes MUST transmit blocks in the same order as they were 217 received. This requirement applies to all dtn nodes, not just ones 218 which implement security processing. Blocks in a bundle may be added 219 or deleted according to the applicable specification, but blocks 220 which are received and then transmitted MUST remain in the same 221 relative order. 223 2. Security Blocks 225 There are three types of security blocks that MAY be included in a 226 bundle. These are the Bundle Authentication Block (BAB), the Payload 227 Security Block (PSB), and the Confidentiality Block (CB). 229 The BAB is used to assure the authenticity of the bundle along a 230 single hop from forwarder to intermediate receiver. 232 The PSB is used to assure the authenticity of the bundle from the 233 PSB security-source, which creates the PSB, to the PSB security- 234 destination, which verifies the PSB authenticator. The 235 authentication information in the PSB may (if the ciphersuite 236 allows) be verified by any node in between the PSB security-source 237 and the PSB security-destination that has access to the 238 cryptographic keys and revocation status information required to 239 do so. 241 Since a BAB protects on a "hop-by-hop" basis and a PSB protects on 242 a (sort of) "end-to-end" basis, whenever both are present the BAB 243 MUST form the "outer" layer of protection - that is, the BAB MUST 244 always be calculated and added to the bundle after the PSB has 245 been calculated and added to the bundle. 247 The CB indicates that some parts of the bundle have been encrypted 248 while en route between the CB security-source and the CB security- 249 destination. 251 Each of the security blocks uses the Canonical Bundle Block Format as 252 defined in the Bundle Protocol Specification. That is, each security 253 block is comprised of the following elements: 255 - Block type code 257 - Block processing control flags 259 - Block EID reference list (optional) 261 - Block data length 263 - Block-type-specific data fields 265 Since the three security blocks have most fields in common, we can 266 shorten the description of the Block-type-specific data fields of 267 each security block if we first define an abstract security block 268 (ASB) and then specify each of the real blocks in terms of the fields 269 which are present/absent in an ASB. Note that no bundle ever 270 contains an ASB, which is simply a specification artifact. 272 2.1. Abstract Security Block 274 An ASB consists of the following mandatory and optional fields: 276 - Block-type code (one byte) - as in all bundle protocol blocks 277 except the primary bundle block. The block types codes for the 278 security blocks are: 280 BAB: 0x02 282 PSB: 0x03 284 CB: 0x04 286 - Block processing control flags (SDNV) - defined as in all bundle 287 protocol blocks except the primary bundle block (as described in 288 the Bundle Protocol [2]). SDNV encoding is described in the 289 bundle protocol. There are no constraints on the use of the block 290 processing flags.[Comment.1] 292 - EID references - composite field defined in [2] containing 293 references to one or two EIDs. Presence of EIDs is indicated by 294 by the setting of bit 6 ("block contains an EID-reference field") 295 of the block processing control flags. If one or more is present, 296 flags in the ciphersuite ID field, described below, specify which. 297 The possible EIDs are, in order:- 299 - (optional) Security-source - specifies the security source for 300 the service. If this is omitted, then the source of the bundle is 301 assumed to be the security-source. 303 - (optional) Security-destination - specifies the security 304 destination for the service. If this is omitted, then the 305 destination of the bundle is assumed to be the security- 306 destination. 308 Both EID fields may be omitted, in which case the composite field 309 itself is empty, as defined in [2]. In this case neither count 310 nor references appear, and bit 6 is not set. 312 - Block data length (SDNV) - as in all bundle protocol blocks 313 except the primary bundle block. SDNV encoding is described in 314 the bundle protocol. 316 - Block-type-specific data fields as follows: 318 - Ciphersuite ID - identifies the ciphersuite in use. This is 319 two bytes long, though the top five bits are used to indicate 320 the presence or absence of the optional fields below. 322 - (optional) Correlator - when more than one related block is 323 inserted then this field must have the same value in each 324 related block instance. This is encoded as an SDNV. See note 325 in Section 3.6 with regard to correlator values in bundle 326 fragments. 328 - (optional) Ciphersuite parameters - compound field of next 329 two items 331 - Ciphersuite parameters length - specifies the length of 332 the following Ciphersuite parameters data field and is 333 encoded as an SDNV. 335 - Ciphersuite parameters data - parameters to be used with 336 the ciphersuite in use, e.g. a key identifier or 337 initialization vector (IV). The encoding rules for this 338 field are defined as part of the ciphersuite specification. 340 - (optional) Security result - compound field of next two items 342 - Security result length - contains the length of the next 343 field and is encoded as an SDNV. 345 - Security result data - contains the results of the 346 appropriate ciphersuite-specific calculation (e.g. a 347 signature, MAC or ciphertext block key). 349 +----------------+----------------+----------------+----------------+ 350 | type | flags (SDNV) | EID ref list(comp) | 351 +----------------+----------------+----------------+----------------+ 352 | length (SDNV) | 353 +----------------+----------------+----------------+----------------+ 354 | ciphersuite | correlator (SDNV) | 355 +----------------+----------------+----------------+----------------+ 356 |params len(SDNV)| ciphersuite params data | 357 +----------------+----------------+----------------+----------------+ 358 |res-len (SDNV) | security result data | 359 +----------------+----------------+----------------+----------------+ 361 The structure of an abstract security block 363 Figure 2 365 The ciphersuite ID is a 16-bit value with the top five bits 366 indicating which of the optional fields are present (value = "1") or 367 absent (value="0"). The remaining 11 bits indicate the ciphersuite. 369 Some ciphersuites are specified in Section 4, which also specifies 370 the rules which MUST be satisfied by ciphersuite specifications. 371 Additional ciphersuites MAY be defined in separate specifications. 373 The structure of the ciphersuite ID bytes is shown in Figure 3. In 374 each case the presence of an optional field is indicated by setting 375 the value of the corresponding flag to one. A value of zero 376 indicates the corresponding optional field is missing. 378 src - the most significant bit (bit 0) indicates whether the ASB 379 contains the optional security-source-length and security-source 380 fields. 382 dest - bit 1 indicates whether the security-destination-length and 383 security-destination fields are present or not. 385 parm - bit 2 indicates whether the ciphersuite-parameters-length 386 and ciphersuite parameters data fields are present or not. 388 corr - bit 3 indicates whether or not the ASB contains an optional 389 correlator. 391 res - bit 4 indicates whether or not the ASB contains the security 392 result length and security result data fields. 394 bits 5-15 represent the ciphersuite number, giving a maximum of 395 2048 different ciphersuites. 397 Ciphersuite ID 398 Bit Bit Bit Bit Bit Bit Bit Bit 399 0 1 2 3 4 5 ... 15 400 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 401 |src |dest |parm |corr |res | ciphersuite ID | 402 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 404 Figure 3 406 A little bit more terminology: when the block is a PSB then we refer 407 to the PSB-source when we mean the security source field in the PSB. 408 Similarly we may refer to the CB-dest, meaning the security- 409 destination field of the CB. For example, referring to Figure 1 410 again, if the bundle that originates at BN1 as source is given a 411 Confidentiality Block (CB) by BN1 that is protected using a key held 412 by BN3 and it is given a Payload Security Block (PSB) by BN1, then 413 BN1 is both the CB-source and the PSB-source of the bundle, and BN3 414 is the CB-dest of the bundle. 416 The correlator field is used to associate several related instances 417 of a security block. This can be used to place a BAB that contains 418 the ciphersuite information at the "front" of a (probably large) 419 bundle , and another correlated BAB that contains the security result 420 at the "end" of the bundle. This allows even very memory-constrained 421 nodes to be able to process the bundle and verify the BAB. There are 422 similar use cases for multiple related instances of PSB and CB as 423 will be seen below. 425 The ciphersuite specification MUST make it clear whether or not 426 multiple block instances are allowed, and if so, under what 427 conditions. Some ciphersuites can of course leave flexibility to the 428 implementation, whereas others might mandate a fixed number of 429 instances. 431 2.2. Bundle Authentication Block 433 In this section we describe typical BAB field values for two 434 scenarios - where a single instance of the BAB contains all the 435 information and where two related instances are used, one "up front" 436 which contains the ciphersuite and another following the payload 437 which contains the security result (e.g. a MAC). 439 For the case where a single BAB is used: 441 The block-type code field value MUST be 0x02. 443 The block processing control flags value can be set to whatever 444 values are required by local policy. 446 The ciphersuite ID MUST be documented as a hop-by-hop 447 authentication-ciphersuite which requires one instance of the BAB. 449 The correlator field MUST NOT be present. 451 The ciphersuite parameters field MAY be present, if so specified 452 in the ciphersuite specification. 454 The security-source field SHOULD be present and, if it is present, 455 it MUST identify the forwarder of the bundle. (If the forwarding 456 node is identified in another block of the bundle that the next 457 hop supports, e.g., the Previous Hop Insertion Block, the 458 forwarding node need not be identified in the BAB.) 459 The security-destination field SHOULD NOT be present unless the 460 ciphersuite requires this information (since the first node 461 receiving the bundle ought be the one to validate the BAB). 463 The security result MUST be present as it is effectively the 464 "output" from the ciphersuite calculation (e.g. the MAC or 465 signature) applied to the (relevant parts of) the bundle (as 466 specified in the ciphersuite definition). 468 For the case using two related BAB instances, the first instance is 469 as defined above, except the ciphersuite ID MUST be documented as a 470 hop-by-hop authentication ciphersuite that requires two instances of 471 the BAB. In addition, the correlator MUST be present and the 472 security result length and security result fields MUST be absent. 473 The second instance of the BAB MUST have the same correlator value 474 present and MUST contain security result length and a security result 475 fields. The other optional fields MUST NOT be present. Typically, 476 this second instance of a BAB will be the last block of the bundle. 478 2.3. Payload Security Block 480 A PSB is an ASB with the following additional restrictions: 482 The block type code value MUST be 0x03. 484 The block processing control flags value can be set to whatever 485 values are required by local policy. 487 The ciphersuite ID MUST be documented as an end-to-end 488 authentication-ciphersuite or as an end-to-end error-detection- 489 ciphersuite. 491 The correlator MUST be present if the ciphersuite requires more 492 than one related instance of a PSB be present in the bundle. The 493 correlator MUST NOT be present if the ciphersuite only requires 494 one instance of the PSB in the bundle. 496 The ciphersuite parameters field MAY be present. 498 The security-source field MAY be present. 500 The security-destination field MAY be present. 502 The security result is effectively the "output" from the 503 ciphersuite calculation (e.g. the MAC or signature) applied to the 504 (relevant parts of) the bundle. As in the case of the BAB, this 505 field MUST be present if the correlator is absent. If more than 506 one related instance of the PSB is required then this is handled 507 in the same way as described for the BAB above. 509 For some ciphersuites, (e.g. those using asymmetric keying to produce 510 signatures or those using symmetric keying with a group key), the 511 security information can be checked at any hop on the way to the 512 destination that has access to the required keying information. 514 Most asymmetric PSB-ciphersuites will use the PSB-source to indicate 515 the signer and will not require the PSB-dest field because the key 516 needed to verify the PSB authenticator will be a public key 517 associated with the PSB-source. 519 2.4. Confidentiality Block 521 A typical confidentiality ciphersuite will encrypt the payload using 522 a randomly generated bundle encrypting key (BEK) and will use a CB 523 security result to carry the BEK encrypted with some long term key 524 encryption key (KEK). or well-known public key. If neither the 525 destination or security-destination resolves the key to use for 526 decryption, the ciphersuite parameters field can be used to indicate 527 the decryption key with which the BEK can be recovered. Subsequent 528 CB security results will contain blocks encrypted using the BEK if 529 non-payload blocks are to be encrypted. 531 The payload is encrypted "in-place", that is, following encryption, 532 the payload block payload field contains ciphertext, not plaintext. 533 The payload block processing flags are unmodified.[Comment.2] 535 Payload super-encryption is allowed. If a CB ciphersuite supports 536 such super-encryption, then the ciphersuite MUST provide an 537 unambiguous way to do the decryption operations in the correct order 538 (e.g. by encoding the "layer" information as a ciphersuite 539 parameter). This "in-place" encryption of payload bytes is so as to 540 allow bundle payload fragmentation and re-assembly to operate without 541 knowledge of whether encryption has occurred. A side-effect of this 542 "in-place" encryption is that the payload will typically be expanded 543 by up-to a ciphertext blocksize if the bulk cipher is a block cipher. 544 Another is that the 2nd application of confidentiality does not 545 generally protect the parameters of the first which represent a 546 vulnerability in some circumstances. 548 A CB is an ASB with the following additional restrictions: 550 The block type code value MUST be 0x04. 552 The block processing control flags value can be set to whatever 553 values are required by local policy. 555 The ciphersuite ID MUST be documented as a confidentiality- 556 ciphersuite. 558 The correlator MUST be present if more than one related CB 559 instance is required. More than one CB instance might be required 560 if the payload is to be encrypted for more than one security- 561 destination so as to be robust in the face of routing 562 uncertainties. These multiple CB instances, however, would not be 563 related and would therefore not require correlators. On the other 564 hand, multiple related CB instances would be required if both the 565 payload and the PSB blocks in the bundle were to be encrypted. 566 These multiple CB instances would require correlators to associate 567 them with each other. The correlator MUST NOT be present if there 568 are no related CB instances. 570 The ciphersuite parameters field MAY be present 572 The security-source field MAY be present. 574 The security-destination field MAY be present (and typically will 575 be). 577 The security result MAY be present and normally represents an 578 encrypted bundle encryption key or encrypted versions of bundle 579 blocks other than the payload block. 581 As was the case for the BAB and PSB, if the ciphersuite requires more 582 than one instance of the CB, then the first occurrence MUST contain 583 any optional fields (e.g. security destination etc.) that apply to 584 all instances with this correlator. These MUST be contained in the 585 first instance and MUST NOT be repeated in other correlated blocks. 586 Fields that are specific to a particular instance of the CB MAY 587 appear in that CB. For example, the security result field MAY (and 588 probably will) be included in multiple related CB instances. 589 Similarly, subsequent CBs might each contain a ciphersuite parameters 590 field with an IV specific to that CB instance. 592 Put another way: when a node is encrypting some (non-payload) blocks, 593 it MUST first create a CB with the required ciphersuite ID, 594 parameters etc. as specified above. Typically, this CB will appear 595 "early" in the bundle. If this "first" CB doesn't contain all of the 596 ciphertext, then it may be followed by other (correlated) CB, which 597 MUST NOT repeat the ciphersuite parameters, security-source, or 598 security-destination fields from the first CB. 600 A CB ciphersuite may, or may not, specify which blocks are to be 601 encrypted. If the ciphersuite doesn't specify this, then the node is 602 free to encrypt whichever blocks it wishes. If a CB ciphersuite does 603 specify which blocks are to be encrypted, then doing otherwise is an 604 error. 606 Since a single CB security result can contain the ciphertext for 607 multiple (non-payload) plaintext blocks, the node simply catenates 608 these plaintext blocks prior to encryption. After decryption the 609 recovered plaintext should then replace the CB in the bundle for 610 further processing (e.g. PSB verification). This recovered 611 plaintext MUST contain all the appropriate block type, processing 612 flags and length information. In other words delete the CB in 613 question and place the recovered plaintext, which consists of 614 additional (non-payload) blocks, in the bundle at the location from 615 which the CB was deleted. 617 Even if a to-be-encrypted block has the "discard" flag set, whether 618 or not the CB's "discard" flag is set is an implementation/policy 619 decision for the encrypting node. (The "discard" flag is more 620 properly called the "discard if block cannot be processed" flag.) 622 2.5. PSB and CB combinations 624 Given the above definitions, nodes are free to combine applications 625 of PSB and CB in any way they wish - the correlator value allows for 626 multiple applications of security services to be handled separately. 628 However, there are some clear security problems that could arise when 629 applying multiple services, for example, if we encrypted a payload 630 but left a PSB security result containing a signature in clear, this 631 would allow payload guesses to be confirmed. 633 We cannot, in general, prevent all such problems since we cannot 634 assume that every ciphersuite definition takes account of every other 635 ciphersuite definition. However, we can limit the potential for such 636 problems by requiring that any ciphersuite which applies to one 637 instance of a PSB or CB, must be applied to all instances with the 638 same correlator. 640 We now list the PSB and CB combinations which we envisage as being 641 useful to support: 643 Encrypted tunnels - a single bundle may be encrypted many times 644 en-route to its destination. Clearly it must be decrypted an 645 equal number of times, but we can imagine each encryption as 646 representing the entry into yet another layer of tunnel. This is 647 supported by using multiple instances of CB, but with the payload 648 encrypted multiple times, "in-place". 650 Multiple parallel authenticators - a single security source might 651 wish to integrity protect a bundle in multiple ways, in the hope 652 that one of them will be useful. This could be required if the 653 path the bundle will take is unpredictable, and if various nodes 654 might be involved as security destinations. Similarly, if the 655 security source cannot determine in advance which algorithms to 656 use, then using all might be reasonable. This would result in 657 uses of PSB which presumably all protect the payload, and which 658 cannot in general protect one another. Note that this logic can 659 also apply to a BAB, if the unpredictable routing happens in the 660 convergence layer, so we also envisage support for multiple 661 parallel uses of BAB. 663 Multiple sequential authenticators - if some security destination 664 requires assurance about the route that bundles have taken, then 665 it might insist on each forwarding node adding its own PSB. More 666 likely however would be that outbound "bastion" nodes would be 667 configured to sign bundles as a way of allowing the sending 668 "domain" to take accountability for the bundle. In this case, the 669 various PSBs will likely be layered, so that each protects the 670 earlier applications of PSB. 672 Authenticated and encrypted bundles - a single bundle may require 673 both authenticity and confidentiality. In this case, most 674 specifications first apply the authenticator and follow this by 675 encrypting the payload and authenticator. As noted previously in 676 the case where the authenticator is a signature, there are 677 security reasons for this ordering. (See the CB-RSA-AES128- 678 PAYLOAD-PSB ciphersuite defined later in Section 4.3.) 680 There are no doubt other valid ways to combine PSB and CB instances, 681 but these are the "core" set we wish to support. Having said that, 682 as will be seen, the mandatory ciphersuites defined here are quite 683 specific and restrictive in terms of limiting the flexibility offered 684 by the correlator mechanism. This is primarily in order to keep this 685 specification as simple as possible, while at the same time 686 supporting the above scenarios. 688 3. Security Processing 690 This section describes the security aspects of bundle processing. 692 3.1. Nodes as policy enforcement points 694 All nodes are REQUIRED to have and enforce their own configurable 695 security policies, whether these policies be explicit or default, as 696 defined in Section 6. 698 All nodes serve as Policy Enforcement Points (PEP) insofar as they 699 enforce polices that may restrict the permissions of bundle nodes to 700 inject traffic into the network. If a particular transmission 701 request satisfies the node's policy and is therefore accepted, then 702 an outbound bundle can be created and dispatched. If not, then in 703 its role as a PEP, the node will not create or forward a bundle. 704 Error handling for such cases is currently considered out of scope of 705 this document.[Comment.3] 707 Policy enforcing code MAY override all other processing steps 708 described here and elsewhere in this document. For example, it is 709 valid to implement a node which always attempts to attach a PSB. 710 Similarly it is also valid to implement a node which always rejects 711 all requests which imply the use of a PSB. 713 Nodes MUST consult their security policy to determine the criteria 714 that a received bundle ought to meet before it will be forwarded. 715 These criteria MUST include a determination of whether or not the 716 received bundle must include valid BAB, PSB or CB. If the bundle 717 does not meet the node's policy criteria, then the bundle MUST be 718 discarded and processed no further; in this case, a bundle status 719 report indicating the failure MAY be generated, destined for the 720 forwarding node's own endpoint.[Comment.4] 722 The node's policy MAY call for the node to add or subtract some 723 security blocks, for example, requiring the node attempt to encrypt 724 (parts of) the bundle for some security-destination, or requiring 725 that the node add a PSB. If the node's policy requires a BAB to be 726 added to the bundle, it MUST be added last so that the calculation of 727 its security result may take into consideration the values of all 728 other blocks in the bundle. 730 3.2. Canonicalisation of bundles 732 In order to verify a signature or MAC on a bundle the exact same 733 bits, in the exact same order, must be input to the calculation upon 734 verification as were input upon initial computation of the original 735 signature or MAC value. Consequently, a node SHOULD NOT change the 736 encoding of any URI in the dictionary field, e.g., changing the DNS 737 part of some HTTP URL from lower case to upper case. Because bundles 738 may be modified while in transit (either correctly or due to 739 implementation errors), a canonical form of any given bundle (that 740 contains a BAB or PSB) must be defined. 742 This section defines two bundle canonicalisation algorithms which can 743 be used by various ciphersuites. 745 3.2.1. Strict canonicalisation 747 The first algorithm which can be used basically permits no changes at 748 all to the bundle between when it is forwarded at the security-source 749 and when it is received at the security-destination and is mainly 750 intended for use in BAB ciphersuites. This algorithm simply involves 751 catenating all blocks in the order presented, but omits all security 752 result fields which are present in blocks of the ciphersuite type in 753 question - that is, when a BAB ciphersuite specifies this algorithm 754 then we omit all BAB security results, when a PSB ciphersuite 755 specifies this algorithm then we omit all PSB security results. (All 756 security result length fields are included, even though their 757 corresponding security result length fields may be omitted.) 759 Notes: 761 - In the above we call for security results to be omitted. This 762 means that no bytes at all of the security result are input. We 763 do not set the security result length to zero. Rather, we are 764 assuming that the security result length will be known to the 765 module that implements the ciphersuite before the security result 766 is calculated, and that this value will be in the security result 767 length field even though the security result itself will be 768 omitted. 770 - The 'res' bit of the ciphersuite ID, which indicates whether or 771 not the security result length and security result data field are 772 present, is part of the canonical form. 774 -The value of the block data length field, which indicates the 775 length of the block, is also part of the canonical form. Its 776 value indicates the length of the entire bundle when the bundle 777 includes the security result field. 779 -BABs are always added to bundles after PSBs, so when a PSB 780 ciphersuite specifies this strict canonicalisation algorithm and 781 the PSB is received with a bundle that also includes one or more 782 BABs, application of strict canonicalisation as part of the PSB 783 security result verification process requires that all BABs in the 784 bundle be ignored entirely. 786 3.2.2. Mutable canonicalisation 788 This algorithm is mainly intended to protect parts of the bundle 789 which should not be changed in-transit, and hence it omits the 790 mutable parts of the bundle. 792 The basic approach is to define a canonical form for the primary 793 block, and catenate that with the security and payload blocks in the 794 order that they will be transmitted. This algorithm ignores all 795 other blocks on the basis that we cannot tell whether or not they are 796 liable to change as the bundle transits the network. 798 Endpoint ID references in security blocks are canonicalized using the 799 de-referenced text form in place of the reference pair. The 800 reference count is not included. 802 The canoncial form of the primary block is shown below. Essentially, 803 it de-references the dictionary block, adjusts lengths where 804 necessary and ignores flags that may change in transit. 806 +----------------+----------------+----------------+----------------+ 807 | Version | Proc. Flags | COS Flags | SRR Flags | 808 +----------------+----------------+---------------------------------+ 809 | Canonical primary block length | 810 +----------------+----------------+---------------------------------+ 811 | Destination endpoint ID length | 812 +----------------+----------------+---------------------------------+ 813 | | 814 | Destination endpoint ID | 815 | | 816 +----------------+----------------+---------------------------------+ 817 | Source endpoint ID length | 818 +----------------+----------------+----------------+----------------+ 819 | | 820 | Source endpoint ID | 821 | | 822 +----------------+----------------+---------------------------------+ 823 | Report-to endpoint ID length | 824 +----------------+----------------+----------------+----------------+ 825 | | 826 | Report-to endpoint ID | 827 | | 828 +----------------+----------------+----------------+----------------+ 829 | | 830 + Creation Timestamp (2 x SDNV) + 831 | | 832 +---------------------------------+---------------------------------+ 833 | Lifetime | 834 +----------------+----------------+----------------+----------------+ 835 | Fragment offset (optional) | 836 +----------------+----------------+---------------------------------+ 837 | Total application data unit length (optional) | 838 +----------------+----------------+---------------------------------+ 840 The canonical form of the primary bundle block. 842 Figure 4 844 The fields shown are: 846 Version, Processing Flags, COS, SRR - are all copied from the 847 first four bytes of the primary block and will contain the version 848 and the immutable flag values from the primary block. Formed by 849 copying the processing, COS and SRR flag fields from the primary 850 block and then subsequently setting all of the mutable bits to 851 zero. This requires ANDing with the (four byte) value 0xFF3E031F 852 so that the mutable and reserved bits are set to zero. The only 853 currently mutable bit masked out here is the "bundle is a 854 fragment" bit - all others are reserved bits. Note also that, 855 since the flags fields are packed into an SDNV, adding a bit might 856 change its length and thereby invalidate the signature even though 857 the extra bit is not included in the canonicalization. To prevent 858 this error, canonicalization uses the non-SDNV form of the flags 859 field, along with the appropriate mask. As described in [2], the 860 maximum size supported for SDNV encoding is 64 bits. 861 Canonicalization therefore uses the 64-bit decoded value, masked 862 as described above. 864 There is an issue here which PSB ciphersuites MUST tackle. If a 865 bundle is fragmented before the PSB is applied then the PSB 866 applies to a fragment and not the entire bundle. However, the 867 protected fragment could be subsequently further fragmented, which 868 would leave the verifier unable to know which bytes were protected 869 by the PSB. For this reason, PSB ciphersuites which support 870 applying a PSB to fragments MUST specify which bytes of the bundle 871 payload are protected as part of the ciphersuite parameters. When 872 verifying such a fragment only the bytes from the fragment are 873 input to the PSB verification. Of course, if is also valid for a 874 ciphersuite to be specified so as to only apply to entire bundles 875 and not to fragments. 877 Length - a four-byte value containing the length (in bytes) of 878 this structure.[Comment.5] 880 Destination endpoint ID length and value - are the length (as a 881 four byte value) and value of the destination endpoint ID from the 882 primary bundle block. The URI is simply copied from the relevant 883 part(s) of the dictionary block and is not itself canonicalised. 885 Source endpoint ID length and value are handled similarly to the 886 destination. 888 Report-to endpoint ID length and value are handled similarly to 889 the destination. 891 Creation time and Lifetime are simply copied from the primary 892 block. 894 Fragment offset and Total application data unit length are copied 895 from the primary block if they are present there (which is 896 controlled by one of the flags). 898 Payload blocks are generally copied as-is, with the exception that 899 the processing flags value in the canonical version MUST be ANDed 900 with 0x37 to ensure that currently "reserved" flags are clear and 901 that the "last block" flag is ignored. The reason to ignore the 902 "last block" flag is that if a bundle is created with both PSB and 903 BAB, then the next hop will remove the BAB instances, and if one of 904 those was the last block, it may set the "last block" flag of, e.g., 905 a PSB instance. The "last block" flag is therefore a mutable bit and 906 should be omitted from the canonical form. Note that the "Block was 907 forwarded without being processed" flag is included in the canonical 908 form of the Payload Block because this flag is never expected to be 909 set by any node; all nodes are required to be able to process the 910 Payload Block. The SDNV considerations described above for the 911 primary block flags field apply also to the flags field of the 912 payload and other non-primary blocks. 914 Another exception occurs in cases where only a fragment of the 915 payload was protected, when only those bytes of the payload block 916 payload field are considered part of the canonical form. 918 Security blocks are handled likewise, with two exceptions: 920 - the "Block was forwarded without being processed" flag MUST be 921 omitted from the canonical form of the PSB and the CB because this 922 flag may be set by a node located between the security-source and 923 the security-destination. Therefore, the processing flags value 924 of the PSB and the CB in the canonical version MUST be ANDed with 925 0x17 to ensure that the mutable "Block was forwarded without being 926 processed" flag is ignored during canonicalization of these 927 blocks. 929 - the ciphersuite will likely specify that the "current" security 930 block security result field not be considered part of the 931 canonical form. This differs from the case in strict 932 canonicalisation since we might use the mutable canonicalisation 933 algorithm to handle sequential signatures, where later signatures 934 should cover earlier ones. 936 Notes: 938 - The canonical form of the bundle is not what is transmitted. It 939 is simply an artifact that is used as input to digesting. 941 - We omit the reserved flags on the basis that we cannot determine 942 whether or not they will change in transit. This means that this 943 algorithm may have to be revised if those flags are given a 944 definition and if we want to protect them. 946 - Our URI encoding does not preserve the "null-termination" 947 convention from the dictionary field, nor do we separate the 948 scheme and ssp as is done there. 950 - Note that the URI encoding above will be a cause for errors if 951 any node rewrites the dictionary for example changing the DNS part 952 of some HTTP URL from lower-case to upper case. This could happen 953 transparently, for example, when a bundle is synched to disk using 954 one set of software and then read from disk and forwarded by a 955 second set of software. Because there are no exact general rules 956 for canonicalising URIs (or even worse IRIs), this problem may be 957 an unavoidable source of integrity failures. 959 - All length fields here are four byte values in network byte 960 order. We do not need to optimize the encoding since the values 961 are never sent over the network. 963 3.3. Endpoint ID confidentiality 965 Since every bundle MUST contain a primary block that cannot be 966 encrypted, and which contains the source endpoint ID (and others), if 967 we want to provide endpoint ID confidentiality, then we have to 968 invent a fake primary block with false values for these fields and 969 then a new block type to contain the actual values. 971 Similarly, there may be confidentiality requirements applying to 972 other parts of the primary block (e.g. the current-custodian) and we 973 support these in the same way. 975 Since we don't know if we'll do this...details are TBD:-)[Comment.6] 977 3.4. Bundles received from other nodes 979 Nodes implementing this specification SHALL consult their security 980 policy to determine whether or not a received bundle is required by 981 policy to include a BAB. If the bundle is not required to have a 982 BAB, then BAB processing on the received bundle is complete and the 983 bundle is ready to be further processed for CB/PSB handling or 984 delivery or forwarding. 986 If the bundle is required to have a BAB but it does not, then the 987 bundle MUST be discarded and processed no further. If the bundle is 988 required to have a BAB but all of its BABs identify a different node 989 other than the receiving node as the BAB security destination, then 990 the bundle MUST be discarded and processed no further. 992 Otherwise, if the bundle does have a BAB that either does not have a 993 security destination field or that identifies the receiving node as 994 the BAB security destination, then the value in the security result 995 field of the BAB MUST be verified according to the ciphersuite 996 specification. If for all such BABs in the bundle either the BAB 997 security source cannot be determined or the security result value 998 check fails, the bundle has failed to authenticate and the bundle 999 SHALL be discarded and processed no further. Otherwise, if any of 1000 the BABs present verify, the bundle is ready to have its CB processed 1001 (if it includes one). 1003 When forwarding a bundle that included some BABs when it was 1004 received, these BABs MUST be stripped from the bundle. New BABs MAY 1005 be added as required by policy. This might require correcting the 1006 "last block" field of the to-be-forwarded bundle. 1008 If the bundle has a CB and the receiving node is the CB destination 1009 for the bundle (either because the node is listed in the bundle's CB- 1010 dest field or because the node is listed as the bundle's destination 1011 and there is no CB-dest field), the node MUST decrypt the relevant 1012 parts of the bundle according to the ciphersuite specification and 1013 delete the CB in question. If the relevant parts of the bundle 1014 cannot be decrypted (i.e., the decryption key cannot be deduced or 1015 decryption fails), then the bundle MUST be discarded and processed no 1016 further; in this case a bundle deletion status report (see the Bundle 1017 Protocol [2]) indicating the decryption failure MAY be generated, 1018 destined for the receiving node's own endpoint. If the CB security 1019 result included the ciphertext of anything other than an encrypted 1020 BEK that was used to encrypt the bundle payload, the recovered 1021 plaintext blocks MUST be placed in the bundle at the location from 1022 which the CB was deleted. 1024 If the bundle has a PSB and the receiving node is the PSB destination 1025 for the bundle (either because the node is listed in the bundle's 1026 PSB-dest field or because the node is listed as the bundle's 1027 destination and there is no PSB-dest field), the node MUST verify the 1028 value in the security result field of the PSB according to the 1029 ciphersuite specification. If the check fails, the bundle has failed 1030 to authenticate and the bundle SHALL be discarded and processed no 1031 further; a bundle status report indicating the failure MAY be 1032 generated, destined for the receiving node's own endpoint. 1033 Otherwise, if the PSB verifies, the bundle is ready to be processed 1034 for either delivery or forwarding. Before forwarding the bundle, the 1035 node SHOULD remove the PSB from the bundle, unless there is the 1036 likelihood that some downstream node will also be able to verify the 1037 PSB. 1039 If the bundle has a PSB and the receiving node is not the PSB-dest 1040 for the bundle but the ciphersuite allows, the receiving node MAY, if 1041 it is able, verify the value in the security result field. If the 1042 check fails, the node SHALL discard the bundle and it MAY send a 1043 bundle status report indicating the failure to the receiving node's 1044 own endpoint. 1046 3.5. The At-Most-Once-Delivery Option 1048 An application may request (in some implementation specific manner) 1049 that a node be registered as a member of an endpoint and that 1050 received bundles destined for that endpoint be delivered to that 1051 application. 1053 We define a new option for use in such cases, known as "at-most-once- 1054 delivery". If this option is chosen, then the application is 1055 indicating that it wants the node to check for duplicate bundles, 1056 discard duplicates, and deliver at most one copy of each received 1057 bundle to the application. If this option is not chosen, the 1058 application is indicating that it wants the node to deliver all 1059 received bundle copies to the application. If this option is chosen, 1060 the node SHALL deliver at most one copy of each received bundle to 1061 the application. If the option is not chosen, the node SHOULD 1062 (subject to policy) deliver all bundles. 1064 To enforce this the node MUST look at the (source, timestamp) pair 1065 value of each complete (reassembled, if necessary) bundle received 1066 and determine if this pair, which should uniquely identify a bundle, 1067 has been received before. If it has, then the bundle is a duplicate. 1068 If it has not, then the bundle is not a duplicate. The (source, 1069 timestamp) pair SHALL be added to the list of pair values already 1070 received by that node. 1072 The duration for which a node maintains entries on such a list is an 1073 implementation matter. 1075 If any application has indicated that it wants a node to use the "at 1076 most once" delivery option for a particular destination endpoint ID 1077 that is in a bundle, then the node MUST compare the (source, 1078 timestamp, fragment offset, fragment length) values of the bundle 1079 with the local list of such values of already-received bundles. 1081 Additional discussion relevant to at-most-delivery is in the DTN 1082 Retransmission Block specification [10]. 1084 3.6. Bundle Fragmentation and Reassembly 1086 If it is necessary for a node to fragment a bundle and security is 1087 being used on that bundle, the following security-specific processing 1088 is REQUIRED: 1090 Firstly, a BAB, PSB or CB MUST NOT be fragmented. At this time, only 1091 the payload field of the payload block MAY be fragmented. 1093 If the bundle is required by the security policy to have a BAB before 1094 being forwarded, all fragments resulting from that bundle MUST 1095 contain individual BAB values. 1097 If the original bundle had a PSB, then each of the PSB instances MUST 1098 be included in some fragment. A single PSB instance MUST NOT be sent 1099 more than once. 1101 If the original bundle had a CB, then the each of the CB instances 1102 MUST be included in some fragment. A single CB instance MUST NOT be 1103 sent more than once. 1105 Note: various fragments may have additional security blocks added at 1106 this or later stages and it is possible that correlators may collide. 1107 In order to facilitate uniqueness, ciphersuites SHOULD include the 1108 fragment-offset of the fragment as a high-order component of the 1109 correlator. 1111 3.7. Reactive fragmentation 1113 When original bundle transmission is terminated before the entire 1114 bundle has been transmitted, the receiving node SHALL consult its 1115 security policy to determine whether it is permitted to transform the 1116 received portion of the bundle into a bundle fragment for further 1117 forwarding. Whether or not such reactive fragmentation is permitted 1118 SHALL be dependent on the security policy in combination with the 1119 ciphersuite used to calculate the BAB authentication information if 1120 required. (Some BAB ciphersuites, i.e., the mandatory BAB-HMAC 1121 ciphersuite defined in Section 4.1, do not accommodate reactive 1122 fragmentation because the security result in the BAB requires that 1123 the entire bundle be signed. It is conceivable, however, that a BAB 1124 ciphersuite could be defined such that multiple security results are 1125 calculated, each on a different segment of a bundle, and that these 1126 security results could be interspersed between bundle payload 1127 segments such that reactive fragmentation could be accommodated.) 1129 If the original bundle is fragmented by the intermediate receiver 1130 (reactively), and the BAB-ciphersuite is of an appropriate type (e.g. 1131 with multiple security results embedded in the payload), the bundle 1132 MUST be fragmented immediately after the last security result value 1133 in the partial payload that is received. Any data received after the 1134 last security result value MUST be dropped. 1136 If an original bundle transmission is terminated before the entire 1137 bundle has been transmitted, if the truncated bundle arriving at the 1138 intermediate receiver is reactively fragmented and forwarded, only 1139 the part of the bundle that was not received MUST be retransmitted, 1140 though more of the bundle MAY be retransmitted. Before 1141 retransmitting a portion of the bundle, it SHALL be changed into a 1142 fragment and, if the original bundle included a BAB, the fragmented 1143 bundle MUST also, and its BAB SHALL be recalculated. 1145 This specification does not currently define any ciphersuite which 1146 can handle this reactive fragmentation case well. 1148 4. Mandatory Ciphersuites 1150 This section defines the mandatory ciphersuites for this 1151 specification. There is currently one mandatory ciphersuite for each 1152 of BAB, PSB and CB. The BAB ciphersuite is based on shared secrets 1153 using HMAC. The PSB ciphersuite is based on digital signatures using 1154 RSA with SHA256. The CB ciphersuite is based on using RSA for key 1155 transport and AES for bulk encryption. 1157 4.1. BAB-HMAC 1159 The BAB-HMAC ciphersuite has ciphersuite ID value 0x001. 1161 Security parameters are optional with this scheme, but if used then 1162 the value of the ciphersuite parameter MUST be used as a key 1163 identifier. The exact type of key identifier to be used is an 1164 implementation issue. In the absence of a key identifier the 1165 intermediate receiver is expected to be able to find the correct key 1166 based on the sending identity (from the security-source and/or 1167 convergence layer). 1169 BAB-HMAC uses the strict canonicalisation algorithm in Section 3.2.1. 1171 The variant of HMAC to be used is HMAC-SHA1 as defined in RFC 2104 1172 [3].[Comment.7] 1174 This ciphersuite requires the use of two related instances of the 1175 BAB. It involves placing the first BAB instance (as defined in 1176 Section 2.2) just after the primary block. The second (correlated) 1177 instance of the BAB MUST be placed after all other blocks (except 1178 possibly other BAB blocks) in the bundle. 1180 This means that normally, the BAB will be the second and last blocks 1181 of the bundle. If a forwarder wishes to apply more than one 1182 correlated BAB pair, then this can be done. There is no requirement 1183 that each application "wrap" the others, but the forwarder MUST 1184 insert all the "up front" BABs, and their "at back" "partners" 1185 (without any security result), before canonicalising. 1187 Inserting more than one correlated BAB pair would be useful if the 1188 bundle could be routed to more than one potential "next-hop" or if 1189 both an old or a new key were valid at sending time, with no 1190 certainty about the situation that will obtain at reception time. 1192 The security result is the output of the HMAC-SHA1 calculation with 1193 input being the result of running the entire bundle through the 1194 strict canonicalisation algorithm. Both required BAB instances MUST 1195 be included in the bundle before canonicalisation. 1197 4.2. PSB-RSA-SHA256 1199 The PSB-RSA-SHA256 ciphersuite has ciphersuite ID value 0x002. 1201 If the bundle being signed has been fragmented before signing, then 1202 we have to specify which bytes were signed, in case the signed bundle 1203 is subsequently fragmented for a second time. So, if the bundle is a 1204 fragment, then the ciphersuite parameters MUST include two SDNV 1205 encoded numbers, representing the offset and length of the signed 1206 fragment. If the entire bundle is signed then these numbers MUST be 1207 omitted. 1209 The ciphersuite parameters field MAY also contain a key identifier. 1210 The exact type of key identifier to be used is an implementation 1211 issue. In the absence of a key identifier the verifier of the PSB is 1212 expected to be able to use the security source (if supplied) or else 1213 the bundle source (if no security source is present) in order to 1214 determine the correct public key to use for PSB verification. 1216 PSB-RSA-SHA256 uses the mutable canonicalisation algorithm 1217 Section 3.2.2. The resulting canonical form of the bundle is the 1218 input to the signing process. This ciphersuite requires the use of a 1219 single instance of the PSB. 1221 RSA is used with SHA256 as specified for the sha256WithRSAEncryption 1222 PKCSv1.5 signature scheme in RFC 4055 [4]. The output of the signing 1223 process is the security result for the PSB. 1225 "Commensurate strength" cryptography is generally held to be a good 1226 idea. A combination of RSA with SHA256 is reckoned to require a 3076 1227 bit RSA key according to this logic. Few implementations will choose 1228 this length by default (and probably some just won't support such 1229 long keys). Since this is an experimental protocol, we expect that 1230 1024 or 2048 bit RSA keys will be used in many cases, and that that 1231 will be fine since we also expect that the hash function "issues" 1232 will be resolved before any standard would be derived from this 1233 protocol.[Comment.8] 1235 4.3. CB-RSA-AES128-PAYLOAD-PSB 1236 [Comment.9] 1238 The CB-RSA-AES128-PAYLOAD-PSB ciphersuite has ciphersuite ID value 1239 0x003. 1241 This scheme only allows for payload and PSB encryption and involves 1242 encrypting every instance of a PSB as well as the payload. 1244 This ciphersuite requires the use of a single CB instance if the 1245 bundle does not contain a PSB, and multiple CB instances if the 1246 bundle includes one or more PSBs. A first CB is created which 1247 contains the encrypted bundle encryption key (BEK). The key size for 1248 this ciphersuite is 128 bits. 1250 For the first CB, there MUST be a ciphersuite parameter which 1251 contains a 16 byte IV, optionally followed by a key identifier (whose 1252 format is again out of scope here). (If the ciphersuite parameters 1253 length field has a value equal to 16, then the parameters data field 1254 consists of only a 16-bye IV. If the ciphersuite parameters length 1255 field has a value greater than 16, then the ciphersuite parameters 1256 data field consists of a 16-byte IV followed by a key identifier, and 1257 the length of that key identifier is the value in the ciphersuite 1258 parameters length field minus 16.) The security result contains the 1259 BEK encrypted using PKCSv1.5 rsaEncryption as specified in RFC 3370 1260 [5]. 1262 For each subsequent PSB, the entire block is replaced by a CB that is 1263 correlated with the first CB and whose security result is the 1264 ciphertext form of the PSB, including the block type, etc. The 1265 parameters field contains a 16-byte IV specific to this block. 1267 For the payload, only the bytes of the bundle payload field are 1268 affected, being replaced by ciphertext. 1270 We separately encrypt the payload and each of the PSB blocks, using 1271 the BEK and a different IV. The IV for the payload is contained in 1272 the first CB, the IV for each of the PSBs is in the parameter field 1273 of the replacement C block. 1275 The BEK uses the AES algorithm in CBC mode as specified by the id- 1276 aes-cbc object identifier in RFC 3565 [6] 1277 [Comment.10][Comment.11][Comment.12] 1279 5. Key Management 1281 Since key management in delay tolerant networks is still a research 1282 topic we cannot provide much in the way of useful key management 1283 here. However, solely in order to support implementation and 1284 testing, implementations SHOULD support: 1286 - Long-term pre-shared-symmetric keys for the BAB-HMAC 1287 ciphersuite. 1289 - The use of well-known RSA public keys for PSB-RSA-SHA256 and CB- 1290 RSA-AES128-PAYLOAD-PSB ciphersuites. 1292 Since endpoint IDs are URIs and URIs can be placed in X.509 [7] 1293 public key certificates (in the subjectAltName extension) 1294 implementations SHOULD support this way of distributing public keys. 1295 Implementations SHOULD NOT be very strict in how they process X.509 1296 though, for example, it would probably not be correct to insist on 1297 Certificate Revocation List (CRL) checking in many DTN contexts. 1299 Other than that, key management is for future study. 1301 6. Default Security Policy 1303 Every node serves as a Policy Enforcement Point (PEP) insofar as it 1304 enforces some policy that controls the forwarding and delivery of 1305 bundles via one or more convergence layer protocol implementation. 1306 Consequently, every node SHALL have and operate according to its own 1307 configurable security policy, whether the policy be explicit or 1308 default. The policy SHALL specify: 1310 Under what conditions received bundles SHALL be forwarded. 1312 Under what conditions received bundles SHALL be required to 1313 include valid BABs. 1315 Under what conditions the authentication information provided in a 1316 bundle's BAB SHALL be deemed adequate to authenticate the bundle. 1318 Under what conditions received bundles SHALL be required to have 1319 valid PSBs and/or CBs. 1321 Under what conditions the authentication information provided in a 1322 bundle's PSB SHALL be deemed adequate to authenticate the bundle. 1324 Under what conditions a BAB SHALL be added to a received bundle 1325 before that bundle is forwarded. 1327 Under what conditions a PSB SHALL be added to a received bundle 1328 before that bundle is forwarded. 1330 Under what conditions a CB SHALL be added to a received bundle 1331 before that bundle is forwarded. 1333 The actions that SHALL be taken in the event that a received 1334 bundle does not meet the receiving node's security policy 1335 criteria. 1337 This specification does not address how security policies get 1338 distributed to nodes. It only REQUIRES that nodes have and enforce 1339 security policies. [Comment.13] 1341 If no security policy is specified at a given node, or if a security 1342 policy is only partially specified, that node's default policy 1343 regarding unspecified criteria SHALL consist of the following: 1345 Bundles that are not well-formed do not meet the security policy 1346 criteria. 1348 The mandatory ciphersuites MUST be used. 1350 All bundles received MUST have a BAB which MUST be verified to 1351 contain a valid security result. If the bundle does not have a 1352 BAB, then the bundle MUST be discarded and processed no further; a 1353 bundle status report indicating the authentication failure MAY be 1354 generated, destined for the receiving node's own endpoint. 1356 No received bundles SHALL be required to have a PSB; if a received 1357 bundle does have a PSB, however, the PSB can be ignored unless the 1358 receiving node is the PSB-dest, in which case the PSB MUST be 1359 verified. 1361 No received bundles SHALL be required to have a CB; if a received 1362 bundle does have a CB, however, the CB can be ignored unless the 1363 receiving node is the CB-dest, in which case the CB MUST be 1364 processed. If processing of a CB yields a PSB, that PSB SHALL be 1365 processed by the node according to the node's security policy. 1367 A PSB SHALL NOT be added to a bundle before sourcing or forwarding 1368 it. 1370 A CB SHALL NOT be added to a bundle before sourcing or forwarding 1371 it. 1373 A BAB MUST always be added to a bundle before that bundle is 1374 forwarded. 1376 If a destination node receives a bundle that has a PSB-destination 1377 field but the value in that PSB-destination field is not the EID 1378 of the destination node, the bundle SHALL be delivered at that 1379 destination node. 1381 If a received bundle does not satisfy the node's security policy 1382 for any reason, then the bundle MUST be discarded and processed no 1383 further; in this case, a bundle deletion status report (see the 1384 Bundle Protocol [2]) indicating the failure SHOULD be generated, 1385 destined for the receiving node's own endpoint. 1387 7. Security Considerations 1388 [Comment.14] 1390 If a BAB ciphersuite uses digital signatures but doesn't include the 1391 security destination (which for a BAB is the next host), then this 1392 allows the bundle to be sent to some node other than the intended 1393 adjacent node. Because the BAB will still authenticate, the 1394 receiving node may erroneously accept and forward the bundle. When 1395 asymmetric BAB ciphersuites are used, the security destination field 1396 SHOULD therefore be included in the BAB. 1398 If a bundle's PSB-dest is not the same as its destination, then some 1399 node other than the destination (the node identified as the PSB-dest) 1400 is expected to validate the PSB security result while the bundle is 1401 en route. However, if for some reason the PSB is not validated, 1402 there is no way for the destination to become aware of this. 1403 Typically, a PSB-dest will remove the PSB from the bundle after 1404 verifying the PSB and before forwarding it. However, if there is a 1405 possibility that the PSB will also be verified at a downstream node, 1406 the PSB-dest will leave the PSB in the bundle. Therefore, if a 1407 destination receives a bundle with a PSB that has a PSB-dest (which 1408 isn't the destination), this may, but does not necessarily, indicate 1409 a possible problem. 1411 If a bundle is fragmented after being forwarded by its PSB-source but 1412 before being received by its PSB-dest, the payload in the bundle MUST 1413 be reassembled before validating the PSB security result in order for 1414 the security result to validate correctly. Therefore, if the PSB- 1415 dest is not capable of performing payload reassembly, its utility as 1416 a PSB-dest will be limited to validating only those bundles that have 1417 not been fragmented since being forwarded from the PSB-source. 1418 Similarly, if a bundle is fragmented after being forwarded by its 1419 PSB-source but before being received by its PSB-dest, all fragments 1420 MUST be received at that PSB-dest in order for the bundle payload to 1421 be able to be reassembled. If not all fragments are received at the 1422 PSB-dest node, the bundle will not be able to be authenticated, and 1423 will therefore never be forwarded by this PSB-dest node. 1425 Specification of a security-destination other than the bundle 1426 destination creates a routing requirement that the bundle somehow be 1427 directed to the security-destination node on its way to the final 1428 destination. This requirement is presently private to the 1429 ciphersuite, since routing nodes are not required to implement 1430 security processing. 1432 8. IANA Considerations 1434 None at this time. If the bundle protocol becomes a standards track 1435 protocol, then we may want to consider having IANA establish a 1436 register of block types, and in particular for this specification a 1437 separate register of ciphersuite specifications. 1439 9. References 1441 9.1. Normative References 1443 [1] Bradner, S. and J. Reynolds, "Key words for use in RFCs to 1444 Indicate Requirement Levels", RFC 2119, October 1997. 1446 [2] Scott, K. and S. Burleigh, "Bundle Protocol Specification", 1447 draft-irtf-dtnrg-bundle-spec-09.txt, work-in-progress, 1448 April 2007. 1450 [3] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 1451 for Message Authentication", RFC 2104, February 1997. 1453 [4] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms 1454 and Identifiers for RSA Cryptography for use in the Internet 1455 X.509 Public Key Infrastructure Certificate and Certificate 1456 Revocation List (CRL) Profile", RFC 4055, June 2005. 1458 [5] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", 1459 RFC 3370, August 2002. 1461 [6] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1462 Encryption Algorithm in Cryptographic Message Syntax (CMS)", 1463 RFC 3565, July 2003. 1465 [7] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 1466 Public Key Infrastructure Certificate and Certificate 1467 Revocation List (CRL) Profile", RFC 3280, April 2002. 1469 9.2. Informative References 1471 [8] Farrell, S., Symington, S., and H. Weiss, "Delay-Tolerant 1472 Network Security Overview", 1473 draft-irtf-dtnrg-sec-overview-03.txt, work-in-progress, 1474 April 2007. 1476 [9] Cerf, V., Burleigh, S., Durst, R., Fall, K., Hooke, A., Scott, 1477 K., Torgerson, L., and H. Weiss, "Delay-Tolerant Network 1478 Architecture", RFC 4838, April 2007. 1480 [10] Symington, S., "Delay-Tolerant Network Retransmission Block", 1481 draft-irtf-dtnrg-bundle-retrans-00.txt, work-in-progress, 1482 April 2007. 1484 Editorial Comments 1486 [Comment.1] Stephen: I guess there could be some weird corner case 1487 where a CB ciphersuite using counter-mode would allow 1488 fragments to be individually decrypted, and in that 1489 case, we might want to set replication for each 1490 fragment. So we can't fully rule out setting that flag 1491 for all PSB/CB. 1493 [Comment.2] Stephen: This to be revisited! 1495 [Comment.3] Stephen: Do we need to specify error handling for the 1496 case where a node drops a bundle for policy reasons? 1497 Does/can it signal back to the source that its done so? 1499 [Comment.4] Howie: The security policy database will need to be 1500 discussed somewhere. Does it belong in this document, 1501 the bundle protocol spec., both, some other document? 1503 [Comment.5] Editors: Check that mask value at the very last moment 1504 (incl. during auth-48) to be sure its (still) correct. 1506 [Comment.6] Stephen: Should we support source confidentiality? 1507 Might complicate PSB which is the downside IMO. 1509 [Comment.7] Editors: At the moment there appears to be no security 1510 reason to move away from HMAC-SHA1 since the HMAC 1511 construct is not as far as we know affected by 1512 collisions in the underlying digest algorithm (which 1513 are nearly practically computable for SHA-1). 1514 Nevertheless, since we use SHA-256 in the signature 1515 ciphersuite (since collisions do matter there), it may 1516 be desirable to move to HMAC-SHA-256 as specified in 1517 RFC 4321. So if you're writing code based on this...be 1518 warned! 1520 [Comment.8] Editors: There are currently unresolved "issues" with 1521 digest algorithms which might cause a change here prior 1522 to, but more likely, after, an RFC has issued. So 1523 expect change! 1525 [Comment.9] Editors: This entire section is to be treated as a 1526 strawman for the present. 1528 [Comment.10] Speculation: There would be an interesting possibility 1529 opened up were we to use a stream cipher with the REK. 1530 That is that we could then encrypt and decrypt 1531 independently - Alice could encrypt for Bob, then 1532 Charlie could encrypt for Dessie, then Bob could 1533 decrypt, then Dessie. Better in terms of not adding 1534 padding but worse in that it trivially allows known 1535 plaintext manipulation if there's no PSB. 1537 [Comment.11] Editors: Another option might also be to switch to 1538 using counter mode rather than CBC which would have the 1539 benefit of allowing some fragments to be decrypted even 1540 if not all fragments arrive. While that seems nice 1541 enough to do, it would of course require us to think 1542 more about fragments and so is for the next version if 1543 at all. 1545 [Comment.12] Peter: there does not seem to be a suitable CTR mode 1546 implementation for AES but perhaps CFB (also stream 1547 mode) would be suitable. It also avoids padding. 1549 [Comment.13] Howie: Eventually we will need to state where the 1550 security policy information/DB does get discussed/ 1551 specified. 1553 [Comment.14] Editors: Much more text is needed here no doubt. 1555 Authors' Addresses 1557 Susan Flynn Symington 1558 The MITRE Corporation 1559 7515 Colshire Drive 1560 McLean, VA 22102 1561 US 1563 Phone: +1 (703) 983-7209 1564 Email: susan@mitre.org 1565 URI: http://mitre.org/ 1567 Stephen Farrell 1568 Trinity College Dublin 1569 Distributed Systems Group 1570 Department of Computer Science 1571 Trinity College 1572 Dublin 2 1573 Ireland 1575 Phone: +353-1-608-1539 1576 Email: stephen.farrell@cs.tcd.ie 1578 Howard Weiss 1579 SPARTA, Inc. 1580 7110 Samuel Morse Drive 1581 Columbia, MD 21046 1582 US 1584 Phone: +1-443-430-8089 1585 Email: hsw@sparta.com 1587 Peter Lovell 1588 SPARTA, Inc. 1589 7110 Samuel Morse Drive 1590 Columbia, MD 21046 1591 US 1593 Phone: +1-443-430-8052 1594 Email: peter.lovell@sparta.com 1596 Full Copyright Statement 1598 Copyright (C) The IETF Trust (2007). 1600 This document is subject to the rights, licenses and restrictions 1601 contained in BCP 78, and except as set forth therein, the authors 1602 retain all their rights. 1604 This document and the information contained herein are provided on an 1605 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1606 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1607 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1608 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1609 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1610 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1612 Intellectual Property 1614 The IETF takes no position regarding the validity or scope of any 1615 Intellectual Property Rights or other rights that might be claimed to 1616 pertain to the implementation or use of the technology described in 1617 this document or the extent to which any license under such rights 1618 might or might not be available; nor does it represent that it has 1619 made any independent effort to identify any such rights. Information 1620 on the procedures with respect to rights in RFC documents can be 1621 found in BCP 78 and BCP 79. 1623 Copies of IPR disclosures made to the IETF Secretariat and any 1624 assurances of licenses to be made available, or the result of an 1625 attempt made to obtain a general license or permission for the use of 1626 such proprietary rights by implementers or users of this 1627 specification can be obtained from the IETF on-line IPR repository at 1628 http://www.ietf.org/ipr. 1630 The IETF invites any interested party to bring to its attention any 1631 copyrights, patents or patent applications, or other proprietary 1632 rights that may cover technology that may be required to implement 1633 this standard. Please address the information to the IETF at 1634 ietf-ipr@ietf.org. 1636 Acknowledgment 1638 Funding for the RFC Editor function is provided by the IETF 1639 Administrative Support Activity (IASA).