idnits 2.17.1 draft-irtf-dtnrg-bundle-security-06.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 2173. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2184. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2191. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2197. 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 == Line 2067 has weird spacing: '...uential encry...' -- 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 (November 1, 2008) is 5647 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: '8' is defined on line 2027, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 5050 (ref. '2') ** Obsolete normative reference: RFC 3369 (ref. '3') (Obsoleted by RFC 3852) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '4') ** Obsolete normative reference: RFC 3280 (ref. '7') (Obsoleted by RFC 5280) == Outdated reference: A later version (-06) exists of draft-irtf-dtnrg-sec-overview-04 -- No information found for draft-irtf-dtnrg-bundle-retrans - is the name correct? Summary: 5 errors (**), 0 flaws (~~), 5 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: May 5, 2009 S. Farrell 5 Trinity College Dublin 6 H. Weiss 7 P. Lovell 8 SPARTA, Inc. 9 November 1, 2008 11 Bundle Security Protocol Specification 12 draft-irtf-dtnrg-bundle-security-06 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 May 5, 2009. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 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 . . . . . . . . . . . . . . . . . . . . . . . 7 55 2.1. Abstract Security Block . . . . . . . . . . . . . . . . . 8 56 2.2. Bundle Authentication Block . . . . . . . . . . . . . . . 12 57 2.3. Payload Integrity Block . . . . . . . . . . . . . . . . . 13 58 2.4. Payload Confidentiality Block . . . . . . . . . . . . . . 14 59 2.5. Parameters and Result Fields . . . . . . . . . . . . . . . 17 60 2.6. Key Transport . . . . . . . . . . . . . . . . . . . . . . 18 61 2.7. PIB and PCB combinations . . . . . . . . . . . . . . . . . 19 62 3. Security Processing . . . . . . . . . . . . . . . . . . . . . 21 63 3.1. Nodes as policy enforcement points . . . . . . . . . . . . 21 64 3.2. Processing order of security blocks . . . . . . . . . . . 21 65 3.3. Security Zones . . . . . . . . . . . . . . . . . . . . . . 24 66 3.4. Canonicalisation of bundles . . . . . . . . . . . . . . . 25 67 3.5. Endpoint ID confidentiality . . . . . . . . . . . . . . . 31 68 3.6. Bundles received from other nodes . . . . . . . . . . . . 31 69 3.7. The At-Most-Once-Delivery Option . . . . . . . . . . . . . 33 70 3.8. Bundle Fragmentation and Reassembly . . . . . . . . . . . 33 71 3.9. Reactive fragmentation . . . . . . . . . . . . . . . . . . 34 72 4. Mandatory Ciphersuites . . . . . . . . . . . . . . . . . . . . 36 73 4.1. BAB-HMAC . . . . . . . . . . . . . . . . . . . . . . . . . 36 74 4.2. PIB-RSA-SHA256 . . . . . . . . . . . . . . . . . . . . . . 37 75 4.3. PCB-RSA-AES128-PAYLOAD-PIB-PCB . . . . . . . . . . . . . . 38 76 5. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 43 77 6. Default Security Policy . . . . . . . . . . . . . . . . . . . 44 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 46 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 48 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 48 83 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 85 Intellectual Property and Copyright Statements . . . . . . . . . . 53 87 1. Introduction 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [1]. 93 This document defines security features for the bundle protocol [2] 94 intended for use in delay tolerant networks, in order to provide the 95 DTN security services as described in the DTN Security Overview and 96 Motivations document [9]. 98 The bundle protocol is used in DTNs which overlay multiple networks, 99 some of which may be challenged by limitations such as intermittent 100 and possibly unpredictable loss of connectivity, long or variable 101 delay, asymmetric data rates, and high error rates. The purpose of 102 the bundle protocol is to support interoperability across such 103 stressed networks. The bundle protocol is layered on top of 104 underlay-network-specific convergence layers, on top of network- 105 specific lower layers, to enable an application in one network to 106 communicate with an application in another network, both of which are 107 spanned by the DTN. 109 Security will be important for the bundle protocol. The stressed 110 environment of the underlying networks over which the bundle protocol 111 will operate makes it important that the DTN be protected from 112 unauthorized use, and this stressed environment poses unique 113 challenges on the mechanisms needed to secure the bundle protocol. 114 Furthermore, DTNs may very likely be deployed in environments where a 115 portion of the network might become compromised, posing the usual 116 security challenges related to confidentiality, integrity and 117 availability. 119 1.1. Related Documents 121 This document is best read and understood within the context of the 122 following other DTN documents: 124 The Delay-Tolerant Network Architecture [10] defines the 125 architecture for delay-tolerant networks, but does not discuss 126 security at any length. 128 The DTN Bundle Protocol [2] defines the format and processing of 129 the blocks used to implement the bundle protocol, excluding the 130 security-specific blocks defined here. 132 The Delay-Tolerant Networking Security Overview [9] provides an 133 informative overview and high-level description of DTN security. 135 1.2. Terminology 137 We introduce the following terminology for purposes of clarity: 139 source - the bundle node from which a bundle originates 141 destination - the bundle node to which a bundle is ultimately 142 destined 144 forwarder - the bundle node that forwarded the bundle on its most 145 recent hop 147 intermediate receiver or "next hop" - the neighboring bundle node 148 to which a forwarder forwards a bundle. 150 In the figure below, which is adapted from figure 1 in the Bundle 151 Protocol Specification, four bundle nodes (denoted BN1, BN2, BN3, and 152 BN4) reside above some transport layer(s). Three distinct transport 153 and network protocols (denoted T1/N1, T2/N2, and T3/N3) are also 154 shown. 156 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 157 | BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 | 158 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 159 | T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 | 160 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 161 | N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 | 162 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 163 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 164 +-----------+ +------------+ +-------------+ +-----------+ 165 | | | | 166 |<-- An Internet --->| |<--- An Internet --->| 167 | | | | 169 BN = "Bundle Node" (as defined in the Bundle Protocol Specification 171 Bundle Nodes Sit at the Application layer of the Internet Model. 173 Figure 1 175 Bundle node BN1 originates a bundle that it forwards to BN2. BN2 176 forwards the bundle to BN3, and BN3 forwards the bundle to BN4. BN1 177 is the source of the bundle and BN4 is the destination of the bundle. 178 BN1 is the first forwarder, and BN2 is the first intermediate 179 receiver; BN2 then becomes the forwarder, and BN3 the intermediate 180 receiver; BN3 then becomes the last forwarder, and BN4 the last 181 intermediate receiver, as well as the destination. 183 If node BN2 originates a bundle (for example, a bundle status report 184 or a custodial signal), which is then forwarded on to BN3, and then 185 to BN4, then BN2 is the source of the bundle (as well as being the 186 first forwarder of the bundle) and BN4 is the destination of the 187 bundle (as well as being the final intermediate receiver). 189 We introduce the following security-specific DTN terminology: 191 security-source - a bundle node that adds a security block to a 192 bundle 194 security-destination - a bundle node that processes a security 195 block of a bundle 197 security zone - that part of the network path from the security- 198 source to the security-destination 200 Referring to Figure 1 again: 202 If the bundle that originates at BN1 as source is given a security 203 block by BN1, then BN1 is the security-source of this bundle with 204 respect to that security block, as well as being the source of the 205 bundle. 207 If the bundle that originates at BN1 as source is given a security 208 block by BN2, then BN2 is the security-source of this bundle with 209 respect to that security block, even though BN1 is the source. 211 If the bundle that originates at BN1 as source is given a security 212 block by BN1 that is intended to be processed by BN3, then BN1 is the 213 security-source and BN3 is the security destination with respect to 214 this security block. The security zone for this block is BN1 to BN3. 216 A bundle may have multiple security blocks. The security-source of a 217 bundle with respect to a given security block in the bundle may be 218 the same as or different from the security-source of the bundle with 219 respect to a different security block in the bundle. Similarly, the 220 security-destination of a bundle with respect to each of that 221 bundle's security blocks may be the same or different. Therefore the 222 security zones for various blocks may be and often will be different. 224 If the bundle that originates at BN1 as source is given a security 225 block by BN1 that is intended to be processed by BN3, and BN2 adds a 226 security block with security-destination BN4, the security zones for 227 the two blocks overlap but not completely. This problem is discussed 228 further in Section 3.3. 230 Forwarding nodes MUST transmit blocks in the same order as they were 231 received. This requirement applies to all dtn nodes, not just ones 232 which implement security processing. Blocks in a bundle may be added 233 or deleted according to the applicable specification, but those 234 blocks which are both received and transmitted MUST be transmitted in 235 the same order that they were received. 237 The block sequence also indicates the order in which certain 238 significant actions have affected the bundle, and therefore the 239 sequence in which actions must occur in order to produce the bundle 240 at its destination. 242 2. Security Blocks 244 There are three types of security block that MAY be included in a 245 bundle. These are the Bundle Authentication Block (BAB), the Payload 246 Integrity Block (PIB), and the Payload Confidentiality Block (PCB). 248 The BAB is used to assure the authenticity and integrity of the 249 bundle along a single hop from forwarder to intermediate receiver. 251 The PIB is used to assure the authenticity and integrity of the 252 bundle from the PIB security-source, which creates the PIB, to the 253 PIB security-destination, which verifies the PIB authenticator. 254 The authentication information in the PIB may (if the ciphersuite 255 allows) be verified by any node inbetween the PIB security-source 256 and the PIB security-destination that has access to the 257 cryptographic keys and revocation status information required to 258 do so. 260 Since a BAB protects a bundle on a "hop-by-hop" basis and a PIB 261 protects on a (sort of) "end-to-end" basis, whenever both are 262 present the BAB MUST form the "outer" layer of protection - that 263 is, the BAB MUST always be calculated and added to the bundle 264 after the PIB has been calculated and added to the bundle. 266 The PCB indicates that some parts of the bundle have been 267 encrypted at the PCB security-source in order to protect the 268 bundle content while in transit to the PCB security-destination. 270 Each of the security blocks uses the Canonical Bundle Block Format as 271 defined in the Bundle Protocol Specification. That is, each security 272 block is comprised of the following elements: 274 - Block type code 276 - Block processing control flags 278 - Block EID reference list (optional) 280 - Block data length 282 - Block-type-specific data fields 284 Since the three security blocks have most fields in common, we can 285 shorten the description of the Block-type-specific data fields of 286 each security block if we first define an abstract security block 287 (ASB) and then specify each of the real blocks in terms of the fields 288 which are present/absent in an ASB. Note that no bundle ever 289 contains an ASB, which is simply a specification artifact. 291 2.1. Abstract Security Block 293 An ASB consists of the following mandatory and optional fields: 295 - Block-type code (one byte) - as in all bundle protocol blocks 296 except the primary bundle block. The block types codes for the 297 security blocks are: 299 BundleAuthentication Block - BAB: 0x02 301 PayloadIntegrity Block - PIB: 0x03 303 PayloadConfidentiality Block - PCB: 0x04 305 - Block processing control flags (SDNV) - defined as in all bundle 306 protocol blocks except the primary bundle block (as described in 307 the Bundle Protocol [2]). SDNV encoding is described in the 308 bundle protocol. There are no general constraints on the use of 309 the block processing flags, and some specific requirements are 310 discussed later.[Comment.1][Comment.2] 312 - EID references - composite field defined in [2] containing 313 references to one or two EIDs. Presence of the EID-reference 314 field is indicated by the setting of the "block contains an EID- 315 reference field" (EID_REF) bit of the block processing control 316 flags. If one or more references is present, flags in the 317 ciphersuite ID field, described below, specify which. 319 If no EID fields are present then the composite field itself is 320 omitted entirely, rather than containing a count field of zero, 321 since such a representation is not permitted. The EID_REF bit is 322 not set. 324 The possible EIDs are:- 326 - (optional) Security-source - specifies the security source 327 for the service. If this is omitted, then the source of the 328 bundle is assumed to be the security-source. 330 - (optional) Security-destination - specifies the security 331 destination for the service. If this is omitted, then the 332 destination of the bundle is assumed to be the security- 333 destination. 335 If two EIDs are present, security-source is first and security- 336 destination comes second. 338 - Block data length (SDNV) - as in all bundle protocol blocks 339 except the primary bundle block. SDNV encoding is described in 340 the bundle protocol. 342 - Block-type-specific data fields as follows: 344 - Ciphersuite ID (SDNV) 346 - Ciphersuite flags (SDNV) 348 - (optional) Correlator - when more than one related block is 349 inserted then this field MUST have the same value in each 350 related block instance. This is encoded as an SDNV. See note 351 in Section 3.8 with regard to correlator values in bundle 352 fragments. 354 - (optional) Ciphersuite parameters - compound field of next 355 two items 357 - Ciphersuite parameters length - specifies the length of 358 the following Ciphersuite parameters data field and is 359 encoded as an SDNV. 361 - Ciphersuite parameters data - parameters to be used with 362 the ciphersuite in use, e.g. a key identifier or 363 initialization vector (IV). See Section 2.5 for a list of 364 potential parameters and their encoding rules. The 365 particular set of parameters that are included in this field 366 are defined as part of the ciphersuite specification. 368 - (optional) Security result - compound field of next two items 370 - Security result length - contains the length of the next 371 field and is encoded as an SDNV. 373 - Security result data - contains the results of the 374 appropriate ciphersuite-specific calculation (e.g. a 375 signature, MAC or ciphertext block key). 377 +----------------+----------------+----------------+----------------+ 378 | type | flags (SDNV) | EID ref list(comp) | 379 +----------------+----------------+----------------+----------------+ 380 | length (SDNV) | ciphersuite (SDNV) | 381 +----------------+----------------+----------------+----------------+ 382 | ciphersuite flags (SDNV) | correlator (SDNV) | 383 +----------------+----------------+----------------+----------------+ 384 |params len(SDNV)| ciphersuite params data | 385 +----------------+----------------+----------------+----------------+ 386 |res-len (SDNV) | security result data | 387 +----------------+----------------+----------------+----------------+ 389 The structure of an abstract security block 391 Figure 2 393 Some ciphersuites are specified in Section 4, which also specifies 394 the rules which MUST be satisfied by ciphersuite specifications. 395 Additional ciphersuites MAY be defined in separate specifications. 396 Ciphersuite IDs not specified are reserved. Implementations of the 397 bundle security protocol decide which ciphersuites to support, 398 subject to the requirements of section Section 4. It is RECOMMENDED 399 that implementations that allow additional ciphersuites permit 400 ciphersuite ID values at least up to and including 127, and they MAY 401 decline to allow larger ID values. 403 The structure of the ciphersuite flags field is shown in Figure 3. 404 In each case the presence of an optional field is indicated by 405 setting the value of the corresponding flag to one. A value of zero 406 indicates the corresponding optional field is missing. Presently 407 there are five flags defined for the field and for convenience these 408 are shown as they would be extracted from a single-byte SDNV. Future 409 additions may cause the field to grow to the left so, as with the 410 flags fields defined in [2], the description below numbers the bit 411 positions from the right rather than the standard RFC definition 412 which numbers bits from the left. 414 src - bit 4 indicates whether the EID-reference field of the ASB 415 contains the optional reference to the security-source. 417 dest - bit 3 indicates whether the EID-reference field of the ASB 418 contains the optional reference to the security-destination. 420 parm - bit 2 indicates whether the ciphersuite-parameters-length 421 and ciphersuite parameters data fields are present or not. 423 corr - bit 1 indicates whether or not the ASB contains an optional 424 correlator. 426 res - bit 0 indicates whether or not the ASB contains the security 427 result length and security result data fields. 429 bits 5-6 are reserved for future use. 431 Ciphersuite flags 432 Bit Bit Bit Bit Bit Bit Bit 433 6 5 4 3 2 1 0 434 +-----+-----+-----+-----+-----+-----+-----+ 435 | reserved |src |dest |parm |corr |res | 436 +-----+-----+-----+-----+-----+-----+-----+ 438 Figure 3 440 A little bit more terminology: if the block is a PIB then when we 441 refer to the "PIB-source", we mean the security source for the PIB as 442 represented by the EID reference in the EID-references field. 443 Similarly we may refer to the PCB-dest, meaning the security- 444 destination of the PCB, again as represented by an EID reference. 445 For example, referring to Figure 1 again, if the bundle that 446 originates at BN1 as source is given a Confidentiality Block (PCB) by 447 BN1 that is protected using a key held by BN3 and it is given a 448 Payload Integrity Block (PIB) by BN1, then BN1 is both the PCB-source 449 and the PIB-source of the bundle, and BN3 is the PCB-dest of the 450 bundle. 452 The correlator field is used to associate several related instances 453 of a security block. This can be used to place a BAB that contains 454 the ciphersuite information at the "front" of a (probably large) 455 bundle, and another correlated BAB that contains the security result 456 at the "end" of the bundle. This allows even very memory-constrained 457 nodes to be able to process the bundle and verify the BAB. There are 458 similar use cases for multiple related instances of PIB and PCB as 459 will be seen below. 461 The ciphersuite specification MUST make it clear whether or not 462 multiple block instances are allowed, and if so, under what 463 conditions. Some ciphersuites can of course leave flexibility to the 464 implementation, whereas others might mandate a fixed number of 465 instances. 467 For convenience, we use the term "first block" to refer to the 468 initial block in a group of correlated blocks, or to the single block 469 if there are no others in the set. Obviously there can be several 470 unrelated groups in a bundle, each containing only one block or more 471 than one, and each has its own "first block". 473 2.2. Bundle Authentication Block 475 In this section we describe typical BAB field values for two 476 scenarios - where a single instance of the BAB contains all the 477 information and where two related instances are used, one "up front" 478 which contains the ciphersuite and another following the payload 479 which contains the security result (e.g. a MAC). 481 For the case where a single BAB is used: 483 The block-type code field value MUST be 0x02. 485 The block processing control flags value can be set to whatever 486 values are required by local policy. 488 The ciphersuite ID MUST be documented as a hop-by-hop 489 authentication-ciphersuite which requires one instance of the BAB. 491 The correlator field MUST NOT be present. 493 The ciphersuite parameters field MAY be present, if so specified 494 in the ciphersuite specification. 496 An EID reference to the security-source SHOULD be present and, if 497 so, it MUST identify the forwarder of the bundle. (If the 498 forwarding node is identified in another block of the bundle that 499 the next hop supports, e.g., the Previous Hop Insertion Block, the 500 forwarding node need not be identified in the BAB. Similarly, if 501 the forwarding node is known through other implementation-specific 502 means, such as from the convergence layer, an EID reference need 503 not be included.) 505 An EID reference to the security-destination SHOULD NOT be present 506 unless the ciphersuite requires this information (since the first 507 node receiving the bundle ought be the one to validate the BAB). 509 The security result MUST be present as it is effectively the 510 "output" from the ciphersuite calculation (e.g. the MAC or 511 signature) applied to the (relevant parts of) the bundle (as 512 specified in the ciphersuite definition). 514 For the case using two related BAB instances, the first instance is 515 as defined above, except the ciphersuite ID MUST be documented as a 516 hop-by-hop authentication ciphersuite that requires two instances of 517 the BAB. In addition, the correlator MUST be present and the 518 security result length and security result fields MUST be absent. 519 The second instance of the BAB MUST have the same correlator value 520 present and MUST contain security result length and security result 521 data fields. The other optional fields MUST NOT be present. 522 Typically, this second instance of a BAB will be the last block of 523 the bundle. 525 2.3. Payload Integrity Block 527 A PIB is an ASB with the following additional restrictions: 529 The block type code value MUST be 0x03. 531 The block processing control flags value can be set to whatever 532 values are required by local policy. 534 The ciphersuite ID MUST be documented as an end-to-end 535 authentication-ciphersuite or as an end-to-end error-detection- 536 ciphersuite. 538 The correlator MUST be present if the ciphersuite requires more 539 than one related instance of a PIB be present in the bundle. The 540 correlator MUST NOT be present if the ciphersuite only requires 541 one instance of the PIB in the bundle. 543 The ciphersuite parameters field MAY be present. 545 An EID reference to the security-source MAY be present. 547 An EID reference to the security-destination MAY be present. 549 The security result is effectively the "output" from the 550 ciphersuite calculation (e.g. the MAC or signature) applied to the 551 (relevant parts of) the bundle. As in the case of the BAB, this 552 field MUST be present if the correlator is absent. If more than 553 one related instance of the PIB is required then this is handled 554 in the same way as described for the BAB above. 556 The ciphersuite may process less than the entire original bundle 557 payload, either because the current payload is a fragment of the 558 original bundle or just becuase it is defined to process some 559 subset. For whatever reason, if the ciphersuite processes less 560 than the complete, original bundle payload MUST specify, as part 561 of the ciphersuite parameters, which bytes of the bundle payload 562 are protected. 564 For some ciphersuites, (e.g. those using asymmetric keying to produce 565 signatures or those using symmetric keying with a group key), the 566 security information can be checked at any hop on the way to the 567 destination that has access to the required keying information. This 568 possibility is further discussed in Section 3.6 below. 570 Most asymmetric PIB-ciphersuites will use the PIB-source to indicate 571 the signer and will not require the PIB-dest field because the key 572 needed to verify the PIB authenticator will be a public key 573 associated with the PIB-source. 575 2.4. Payload Confidentiality Block 577 A typical confidentiality ciphersuite will encrypt the payload using 578 a randomly generated bundle encrypting key (BEK) and will use a PCB 579 security result to carry the BEK encrypted with some long term key 580 encryption key (KEK) or well-known public key. If neither the 581 destination nor security-destination resolves the key to use for 582 decryption, the ciphersuite parameters field can be used to indicate 583 the decryption key with which the BEK can be recovered. Subsequent 584 PCB security results will contain blocks encrypted using the BEK if 585 non-payload blocks are to be encrypted. 587 It is STRONGLY RECOMMENDED that a data integrity mechanism be used in 588 conjunction with confidentiality, and that encryption-only 589 ciphersuites NOT be used. The "authentication tag" or "integrity 590 check value" is stored into security-result rather than being 591 appended to the payload as is common in some protocols since, as 592 described below, it is important that there be no change in the size 593 of the payload. 595 The payload is encrypted "in-place", that is, following encryption, 596 the payload block payload field contains ciphertext, not plaintext. 597 The payload block processing flags are unmodified.[Comment.3] 599 The "in-place" encryption of payload bytes is to allow bundle payload 600 fragmentation and re-assembly, and custody transfer, to operate 601 without knowledge of whether or not encryption has occurred and, if 602 so, how many times. 604 Fragmentation and reassembly and custody transfer are adversely 605 affected by a change in size of the payload due to ambiguity about 606 what byte range of the original payload is actually in any particular 607 fragment. Ciphersuites SHOULD place any payload expansion, such as 608 authentication tags (integrity check values) and any padding 609 generated by a block-mode cipher, into an "integrity check value" 610 item in the security-result field (see Section 2.5) of the 611 confidentiality block. 613 Payload super-encryption is allowed. The second application of 614 confidentiality does not generally protect the parameters of the 615 first which represent a vulnerability in some circumstances. 616 Ciphersuites SHOULD define super-encryption such that it protects the 617 parameters of earlier encryption. 619 Confidentiality can be applied to blocks other than the payload and 620 in some cases this is recommended. The ciphersuite may apply 621 different rules to confidentiality for non-payload blocks. 623 For example, multiple related PCB instances are required if both the 624 payload and the PS blocks in the bundle are to be encrypted. These 625 multiple PCB instances require correlators to associate them with 626 each other. 628 Confidentiality is normally applied to the payload, and possibly to 629 additional blocks. It is RECOMMENDED to apply a Payload 630 Confidentiality ciphersuite to non-payload blocks only if these 631 should be super-encrypted with the payload. If super-encryption if 632 the block is not desired then protection of the block should be done 633 by means other than a Payload Confidentiality ciphersuite. 635 There are situations where more than one PCB instance is required but 636 the instances are not "related" in the sense which requires 637 correlators. One example is where a payload is encrypted for more 638 than one security-destination so as to be robust in the face of 639 routing uncertainties. These multiple PCB instances, are not 640 "related" and should not contain correlators. [Comment.4] 642 A PCB is an ASB with the following additional restrictions: 644 The block type code value MUST be 0x04. 646 The block processing control flags value can be set to whatever 647 values are required by local policy, except that a PCB "first 648 block" MUST have the "replicate in every fragment" flag set. This 649 flag SHOULD NOT be set otherwise. 651 The ciphersuite ID MUST be documented as a confidentiality- 652 ciphersuite. 654 The correlator MUST be present if there is more than one related 655 PCB instance. The correlator MUST NOT be present if there are no 656 related PCB instances. 658 If a correlator is present, the key information MUST be placed in 659 the PCB "first block". 661 Any additional bytes generated as a result of encryption and/or 662 authentication processing of the payload SHOULD be placed in an 663 "integrity check value" field (see Section 2.5) in the security- 664 result of the first PCB. 666 The ciphersuite parameters field MAY be present. 668 An EID reference to the security-source MAY be present. 670 An EID reference to the security-destination MAY be present. 672 The security result MAY be present and normally contains fields 673 such as an encrypted bundle encryption key, authentication tag or 674 the encrypted versions of bundle blocks other than the payload 675 block. 677 As was the case for the BAB and PIB, if the ciphersuite requires more 678 than one instance of the PCB, then the "first block" MUST contain any 679 optional fields (e.g. security destination etc.) that apply to all 680 instances with this correlator. These MUST be contained in the first 681 instance and MUST NOT be repeated in other correlated blocks. Fields 682 that are specific to a particular instance of the PCB MAY appear in 683 that PCB. For example, security result fields MAY (and probably 684 will) be included in multiple related PCB instances, with each result 685 being specific to that particular block. Similarly, several PCBs 686 might each contain a ciphersuite parameters field with an IV specific 687 to that PCB instance. 689 Put another way: when confidentiality will generate multiple blocks, 690 it MUST first create a PCB with the required ciphersuite ID, 691 parameters etc. as specified above. Typically, this PCB will appear 692 "early" in the bundle. If this "first" PCB doesn't contain all of 693 the ciphertext, then it may be followed by other, correlated PCBs 694 which MUST NOT repeat the ciphersuite parameters, security-source, or 695 security-destination fields from the first PCB. 697 A PCB ciphersuite may, or may not, specify which blocks are to be 698 encrypted. If the ciphersuite doesn't specify this, then the node is 699 free to encrypt whichever blocks it wishes. If a PCB ciphersuite 700 does specify which blocks are to be encrypted, then doing otherwise 701 is an error. 703 The ciphersuite may process less than the entire original bundle 704 payload, either because the current payload is a fragment of the 705 original bundle or just becuase it is defined to process some subset. 706 For whatever reason, if the ciphersuite processes less than the 707 complete, original bundle payload MUST specify, as part of the 708 ciphersuite parameters, which bytes of the bundle payload are 709 protected. 711 After decryption the recovered plaintext should then replace the PCB 712 in the bundle for further processing (e.g. PIB verification). This 713 recovered plaintext MUST contain all the appropriate block type, 714 processing flags and length information. In other words delete the 715 PCB in question and place the recovered plaintext, which consists of 716 some complete non-payload block, in the bundle at the location from 717 which the PCB was deleted. 719 A ciphersuite MUST NOT mix payload data and a non-payload block in a 720 single PCB. 722 Even if a to-be-encrypted block has the "discard" flag set, whether 723 or not the PCB's "discard" flag is set is an implementation/policy 724 decision for the encrypting node. (The "discard" flag is more 725 properly called the "discard if block cannot be processed" flag.) 727 2.5. Parameters and Result Fields 729 Various ciphersuites include several items in the security-parameters 730 and/or security-result fields. Which fields may appear is defined by 731 the particular ciphersuite description. 733 Each field is represented as type-length-value. Type is a single 734 byte indicating which item this is. Length is the count of data 735 bytes to follow, and is an SDNV-encoded integer. Value is the data 736 content of the item. 738 Item types are 740 0: reserved 742 1: initialization vector (IV) 744 2: reserved 746 3: key information 748 4: fragment range (offset and length as a pair of SDNVs) 750 5: integrity signature 752 6: reserved 754 7: PC block salt 756 8: PC block integrity check value (ICV) 758 9: reserved 760 10: encapsulated block 761 11: reserved 763 12 - 191: reserved 765 192 - 250: private use 767 251 - 255: reserved 769 The folowing descriptions apply to usage of these items for all 770 ciphersuites. Additional characteristics are noted in the discussion 771 for specific suites. 773 - initialization vector(IV): random value, typically eight to 774 sixteen bytes 776 - key information: key material encoded or protected by the key 777 management system. This item is discussed further below 778 Section 2.6 780 - fragment range: pair of SDNV values (offset then length) 781 specifying the range of payload bytes to which a particular 782 operation applies. This is termed "fragment range" since that is 783 its typical use, even though sometimes it may describe a subset 784 range that is not a fragment 786 - integrity signature: result of BA or PS digest or signing 787 operation. This item is discussed further below Section 2.6 789 - C block salt: an IV-like value used by certain confidentiality 790 suites 792 - C block integrity check value(ICV): output from certain 793 confidentiality ciphersuite operations to be used at the 794 destination to verify that the protected data has not been 795 modified 797 - encapsulated block: result of confidentiality operation on 798 certain blocks, contains the ciphertext of the block and may also 799 contain an integrity check value appended to the ciphertext; may 800 also contain padding if required by the encryption mode; used for 801 non-payload blocks only 803 2.6. Key Transport 805 This specification endeavours to maintain separation between the 806 security protocol and key management. However these two interact in 807 the transfer of key information etc from security-source to security- 808 destination. In this discussion, "key information" includes keys, 809 key identifiers, integrity signatures and other similar information 810 protected by a key. It excludes payload, metadata and similar blocks 811 even though these may be protected by a key. 813 The exact representation of "key information" and "integrity 814 signature" in their respective item types is currently a topic of 815 discussion. The general intent is that they should be ASN.1-encoded 816 as described in RFC 3369 [3] and related RFCs. 818 2.7. PIB and PCB combinations 820 Given the above definitions, nodes are free to combine applications 821 of PIB and PCB in any way they wish - the correlator value allows for 822 multiple applications of security services to be handled separately. 824 However, there are some clear security problems that could arise when 825 applying multiple services. For example, if we encrypted a payload 826 but left a PIB security result containing a signature in the clear, 827 payload guesses could be confirmed. 829 We cannot, in general, prevent all such problems since we cannot 830 assume that every ciphersuite definition takes account of every other 831 ciphersuite definition. However, we can limit the potential for such 832 problems by requiring that any ciphersuite which applies to one 833 instance of a PIB or PCB, must be applied to all instances with the 834 same correlator. 836 We now list the PIB and PCB combinations which we envisage as being 837 useful to support: 839 Encrypted tunnels - a single bundle may be encrypted many times 840 en-route to its destination. Clearly it must be decrypted an 841 equal number of times, but we can imagine each encryption as 842 representing the entry into yet another layer of tunnel. This is 843 supported by using multiple instances of PCB, but with the payload 844 encrypted multiple times, "in-place". Depending upon the 845 ciphersuite defintion, other blocks can and should be encrypted, 846 as discussed above and in Section 2.4 to ensure that parameters 847 are protected in the case of super-encryption. 849 Multiple parallel authenticators - a single security source might 850 wish to protect the integrity of a bundle in multiple ways. This 851 could be required if the bundle's path is unpredictable, and if 852 various nodes might be involved as security destinations. 853 Similarly, if the security source cannot determine in advance 854 which algorithms to use, then using all might be reasonable. This 855 would result in uses of PIB which presumably all protect the 856 payload, and which cannot in general protect one another. Note 857 that this logic can also apply to a BAB, if the unpredictable 858 routing happens in the convergence layer, so we also envisage 859 support for multiple parallel uses of BAB. 861 Multiple sequential authenticators - if some security destination 862 requires assurance about the route that bundles have taken, then 863 it might insist that each forwarding node add its own PIB. More 864 likely, however would be that outbound "bastion" nodes would be 865 configured to sign bundles as a way of allowing the sending 866 "domain" to take accountability for the bundle. In this case, the 867 various PIBs will likely be layered, so that each protects the 868 earlier applications of PIB. 870 Authenticated and encrypted bundles - a single bundle may require 871 both authentication and confidentiality. Some specifications 872 first apply the authenticator and follow this by encrypting the 873 payload and authenticator. As noted previously in the case where 874 the authenticator is a signature, there are security reasons for 875 this ordering. (See the PCB-RSA-AES128-PAYLOAD-PIB-PCB 876 ciphersuite defined later in Section 4.3.) Others apply the 877 authenticator after encryption, that is, to the ciphertext. This 878 ordering is generally recommended and minimizes attacks which, in 879 some cases, can lead to recovery of the encryption key. 881 There are no doubt other valid ways to combine PIB and PCB instances, 882 but these are the "core" set supported in this specification. Having 883 said that, as will be seen, the mandatory ciphersuites defined here 884 are quite specific and restrictive in terms of limiting the 885 flexibility offered by the correlator mechanism. This is primarily 886 in order to keep this specification as simple as possible, while at 887 the same time supporting the above scenarios. 889 3. Security Processing 891 This section describes the security aspects of bundle processing. 893 3.1. Nodes as policy enforcement points 895 All nodes are REQUIRED to have and enforce their own configurable 896 security policies, whether these policies be explicit or default, as 897 defined in Section 6. 899 All nodes serve as Policy Enforcement Points (PEP) insofar as they 900 enforce polices that may restrict the permissions of bundle nodes to 901 inject traffic into the network. Policies may apply to traffic 902 originating at the current node, traffic terminating at the current 903 node and traffic to be forwarded by the current node to other nodes. 904 If a particular transmission request, originating either locally or 905 remotely, satisfies the node's policy or policies and is therefore 906 accepted, then an outbound bundle can be created and dispatched. If 907 not, then in its role as a PEP, the node will not create or forward a 908 bundle. Error handling for such cases is currently considered out of 909 scope of this document.[Comment.5] 911 Policy enforcing code MAY override all other processing steps 912 described here and elsewhere in this document. For example, it is 913 valid to implement a node which always attempts to attach a PIB. 914 Similarly it is also valid to implement a node which always rejects 915 all requests which imply the use of a PIB. 917 Nodes MUST consult their security policy to determine the criteria 918 that a received bundle ought to meet before it will be forwarded. 919 These criteria MUST include a determination of whether or not the 920 received bundle must include a valid BAB, PIB or PCB. If the bundle 921 does not meet the node's policy criteria, then the bundle MUST be 922 discarded and processed no further; in this case, a bundle status 923 report indicating the failure MAY be generated.[Comment.6] 925 The node's policy MAY call for the node to add or subtract some 926 security blocks, for example, requiring the node attempt to encrypt 927 (parts of) the bundle for some security-destination, or requiring 928 that the node add a PIB. If the node's policy requires a BAB to be 929 added to the bundle, it MUST be added last so that the calculation of 930 its security result may take into consideration the values of all 931 other blocks in the bundle. 933 3.2. Processing order of security blocks 935 The processing order of security actions for a bundle is critically 936 important for the actions to complete successfully. In general, the 937 actions performed at the originating node must be executed in the 938 reverse sequence at the destination. There are variations and 939 exceptions, and these are noted below. 941 The sequence is maintained in the ordering of security blocks in the 942 bundle. It is for this reason that blocks may not be rearranged at 943 forwarding nodes, whether they support the security protocols or not. 944 The only blocks that participate in this ordering are the primary and 945 payload blocks, and the security blocks themselves. All other 946 extension blocks are ignored for purposes of determining the 947 processing order. 949 The security blocks are added to and removed from a bundle in a last- 950 in-first-out (LIFO) manner, with the top of the stack immediately 951 after the primary block. A newly-created bundle has just the primary 952 and payload blocks, and the stack is empty. As security actions are 953 requested for the bundle, security blocks are pushed onto the stack 954 immediately after the primary block. The early actions have security 955 blocks close to the payload, later actions have blocks nearer to the 956 primary block. The actions deal with only those blocks in the bundle 957 at the time so, for example, the first to be added processes only the 958 payload and primary blocks, the next might process the first if it 959 chooses and the payload and primary, and so on. The last block to be 960 added can process all the blocks. 962 When the bundle is received, this process is reversed and security 963 processing begins at the top of the stack, immediately after the 964 primary block. The security actions are performed and the block is 965 popped from the stack. Processing continues with the next security 966 block until finally only the payload and primary blocks remain. 968 The simplicity of this description is undermined by various real- 969 world requirements. Nonetheless it serves as a helpful initial 970 framework for understanding the bundle security process. 972 The first issue is a very common one and easy to handle. The bundle 973 may be sent indirectly to its destination, requiring several 974 forwarding hops to finally arrive there. Security processing happens 975 at each node, assuming that the node supports bundle security. For 976 the following discussion, we assume that a bundle is created and that 977 confidentiality, then payload integrity and finally bundle 978 authentication are applied to it. The block sequence would therefore 979 be primary-BA-PS-PC-payload. Traveling from source to destination 980 requires going through one intermediate node, so the trip consists of 981 two hops. 983 When the bundle is received at the intermediate node, the receive 984 processing validates the BA block and pops it from the stack. 986 However the PS and PC blocks have the final destination as their 987 security destination, so these can't be processed and removed. The 988 intermediate node then begins the send process with the four 989 remaining blocks in the bundle. The outbound processing adds any 990 security blocks required by local policy, and these are pushed on the 991 stack immediately after the primary block, ahead of the PS block. In 992 this example, the intermediate node adds a PS block as a signature 993 that the bundle has passed through the node. 995 The receive processing at the destination first handles the 996 intermediate node's PS block and pops it, next is the originator's PS 997 block, also popped, and finally the originator's confidentiality 998 block which allows the payload to be decrypted and the bundle handled 999 for delivery. 1001 This simple scheme can easily be extended to very complex networks. 1002 It cannot deal with security zones that overlap partially but not 1003 completely and these are discussed further below Section 3.3. 1004 Administrators SHOULD NOT configure security-sources and security- 1005 destinations in a network such that overlapping security zones are 1006 created. 1008 The second issue relates to the reversibility of certain security 1009 process actions. In general, the actions fall into two categories: 1010 those which do not affect other parts of the bundle, and those which 1011 are fully reversible. Creating a bundle signature, for example, does 1012 not change the bundle content except for the result. The encryption 1013 performed as part of the confidentiality processing does change the 1014 bundle, but the reverse processing at the destination restores the 1015 original content. 1017 The third category is the one where the bundle content has changed 1018 slightly and in a non-destructive way, but there is no mechanism to 1019 reverse the change. The simplest example is the addition of an EID- 1020 reference to a security block. The addition of the reference causes 1021 the text to be added to the bundle's dictionary. The text may be 1022 used also by other references so removal of the block and this 1023 specific eid-reference does not cause removal of the text from the 1024 dictionary. This shortcoming is of no impact to the "sequential" or 1025 "wrapping" security schemes described above, but does cause failures 1026 with "parallel" authentication mechanisms. Solutions for this 1027 problem are implementation-specific and typically involve multi-pass 1028 processing such that blocks are added at one stage and the security 1029 results calculated at a later stage of the overall process. 1031 Certain ciphersuites have sequence requirements for their correct 1032 operation, most notably the BundleAuthentication ciphersuites. 1033 Processing for BundleAuthentication is required to happen after all 1034 other sending operations, and prior to any receive operations at the 1035 next hop node. It follows therefore that BA blocks must always be 1036 pushed onto the stack after all others. 1038 Although we describe the security block list as a stack, there are 1039 some blocks which are placed after the payload and therefore are not 1040 part of the stack. The BundleAuthentication ciphersuite #1 ("BA1") 1041 requires a second, correlated block to contain the security-result 1042 and this block is placed after the payload, usually as the last block 1043 in the bundle. We can apply the stack rules even to these blocks by 1044 specifying that they be added to the end of the bundle at the same 1045 time that their "owner" or "parent" block is pushed on the stack. In 1046 fact, they form a stack beginning at the payload but growing in the 1047 other direction. Also, not all blocks in the main stack have a 1048 corresponding entry in the trailing stack. The only blocks which 1049 MUST follow the payload are those mandated by ciphersuites as 1050 correlated blocks for holding a security-result. No other blocks are 1051 required to follow the payload block and it is RECOMMENDED that they 1052 NOT do so. 1054 3.3. Security Zones 1056 Each security block has a security zone, as described in the 1057 discussion for Figure 1, and the zones for various blocks are often 1058 different. 1060 BA blocks are always for a single hop and these restricted zones 1061 never cause conflict. 1063 The zones for PS and C blocks are often from bundle source to bundle 1064 destination, to provide end-to-end protection. A bundle-source-to- 1065 bundle-destination zone likewise never causes a problem. 1067 Another common scenario is for gateway-to-gateway protection of 1068 traffic between two sub-networks. 1070 Looking at Figure 1 and the simplified version shown in Figure 4, we 1071 can regard BN2 and BN3 as gateways connecting the two subnetworks 1072 labeled "An Internet". As long as they provide security for the BN2- 1073 BN3 zone, all is well. Problems begin, for example, when BN2 adds 1074 blocks with BN4 as the security-destination, and originating node BN1 1075 has created blocks with BN3 as security-destination. We now have two 1076 zones and neither is a subset of the other. 1078 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 1079 | BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 | 1080 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 1081 >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ 1083 <------------- BN1 to BN3 zone ------------> 1085 <------------- BN2 to BN4 zone ------------> 1087 Overlapping security zones 1089 Figure 4 1091 Consider the case where the security concern is for data integrity, 1092 so the blocks are PayloadIntegrity. BN1 creates one ("PSa") along 1093 with the new bundle, and BN2 pushes its own PS block "PSb" on the 1094 stack, with security-destination BN4. When this bundle arrives at 1095 BN3, the bundle blocks are 1097 primary - PSb - PSa - payload 1099 Block PSb is not destined for this node BN3 so must be forwarded. 1100 This is the security-destination for block PSa so, after validation, 1101 it should be removed from the bundle. But that will invalidate the 1102 PSb signature when the block is checked at the final destination. 1103 The PSb signature includes the primary block, PSb itself, PSa and the 1104 payload block, so PSa MUST remain in the bundle. This is why 1105 security blocks are treated as a stack and add/remove operations are 1106 permitted only at the top-of-stack. 1108 The situation would be worse if the security concern is 1109 confidentiality, so PC blocks are employed, such as the 1110 confidentiality ciphersuite #3 ("PC3") described in Section 4.3. In 1111 this scenario, BN1 would encrypt the bundle with BN3 as security- 1112 destination, BN2 would super-encrypt the payload and encapsulate the 1113 PC3 block for security-destination BN4. BN3 forwards all the blocks 1114 without change. BN4 decrypts the payload from its super-encryption 1115 and decapsulates the PC3 block, only to find that it should have been 1116 processed earlier. Assuming that BN4 has no access to BN3's key 1117 store, BN4 has no way to decrypt the bundle and recover the original 1118 content. 1120 3.4. Canonicalisation of bundles 1122 In order to verify a signature or MAC on a bundle the exact same 1123 bits, in the exact same order, must be input to the calculation upon 1124 verification as were input upon initial computation of the original 1125 signature or MAC value. Consequently, a node MUST NOT change the 1126 encoding of any URI in the dictionary field, e.g., changing the DNS 1127 part of some HTTP URL from lower case to upper case. Because bundles 1128 may be modified while in transit (either correctly or due to 1129 implementation errors), a canonical form of any given bundle (that 1130 contains a BAB or PIB) must be defined. 1132 This section defines two bundle canonicalisation algorithms which can 1133 be used by various ciphersuites. 1135 3.4.1. Strict canonicalisation 1137 The first algorithm that can be used permits no changes at all to the 1138 bundle between the security-source and the security-destination. It 1139 is mainly intended for use in BAB ciphersuites. This algorithm 1140 conceptually catenates all blocks in the order presented, but omits 1141 all security result data fields in blocks of this ciphersuite type. 1142 That is, when a BA ciphersuite specifies this algorithm then we omit 1143 all BAB security results for all BA ciphersuites, when a PIB 1144 ciphersuite specifies this algorithm then we omit all PIB security 1145 results for all PS ciphersuites. All security result length fields 1146 are included, even though their corresponding security result data 1147 fields are omitted. 1149 Notes: 1151 - In the above we specify that security result data is omitted. 1152 This means that no bytes of the security result data are input. 1153 We do not set the security result length to zero. Rather, we 1154 assume that the security result length will be known to the module 1155 that implements the ciphersuite before the security result is 1156 calculated, and require that this value be in the security result 1157 length field even though the security result data itself will be 1158 omitted. 1160 - The 'res' bit of the ciphersuite ID, which indicates whether or 1161 not the security result length and security result data field are 1162 present, is part of the canonical form. 1164 -The value of the block data length field, which indicates the 1165 length of the block, is also part of the canonical form. Its 1166 value indicates the length of the entire bundle when the bundle 1167 includes the security result data field. 1169 -BABs are always added to bundles after PIBs, so when a PIB 1170 ciphersuite specifies this strict canonicalisation algorithm and 1171 the PIB is received with a bundle that also includes one or more 1172 BABs, application of strict canonicalisation as part of the PIB 1173 security result verification process requires that all BABs in the 1174 bundle be ignored entirely. 1176 3.4.2. Mutable canonicalisation 1178 This algorithm is intended to protect parts of the bundle which 1179 should not be changed in-transit. Hence it omits the mutable parts 1180 of the bundle. 1182 The basic approach is to define a canonical form of the primary block 1183 and catenate it with the security and payload blocks in the order 1184 that they will be transmitted. This algorithm ignores all other 1185 blocks because it cannot be determined whether or not they will 1186 change as the bundle transits the network. 1188 Many fields in various blocks are stored as variable-length SDNVs. 1189 These are canonicalized in unpacked form, as eight-byte fixed-width 1190 fields in network byte order. The size of eight bytes is chosen 1191 because implementations may handle larger values as invalid, as noted 1192 in [2]. 1194 The canonical form of the primary block is shown in Figure 5. 1195 Essentially, it de-references the dictionary block, adjusts lengths 1196 where necessary and ignores flags that may change in transit. 1198 +----------------+----------------+----------------+----------------+ 1199 | Version | Processing flags (incl. COS and SRR) | 1200 +----------------+----------------+---------------------------------+ 1201 | Canonical primary block length | 1202 +----------------+----------------+---------------------------------+ 1203 | Destination endpoint ID length | 1204 +----------------+----------------+---------------------------------+ 1205 | | 1206 | Destination endpoint ID | 1207 | | 1208 +----------------+----------------+---------------------------------+ 1209 | Source endpoint ID length | 1210 +----------------+----------------+----------------+----------------+ 1211 | | 1212 | Source endpoint ID | 1213 | | 1214 +----------------+----------------+---------------------------------+ 1215 | Report-to endpoint ID length | 1216 +----------------+----------------+----------------+----------------+ 1217 | | 1218 | Report-to endpoint ID | 1219 | | 1220 +----------------+----------------+----------------+----------------+ 1221 | | 1222 + Creation Timestamp (2 x SDNV) + 1223 | | 1224 +---------------------------------+---------------------------------+ 1225 | Lifetime | 1226 +----------------+----------------+----------------+----------------+ 1228 The canonical form of the primary bundle block. 1230 Figure 5 1232 The fields shown in Figure 5 are: 1234 Version is the single-byte value in the primary block. 1236 Processing flags in the primary block is an SDNV, and includes the 1237 class-of-service (COS) and status report request (SRR) fields. 1238 For purposes of canonicalization, the SDNV is unpacked into a 1239 fixed-width field and some bits are masked out. The unpacked 1240 field is ANDed with mask 0x0000 0000 003E 031F to set to zero all 1241 reserved bits and the "bundle is a fragment" bit. 1243 Length - a four-byte value containing the length (in bytes) of 1244 this structure, in network byte order.[Comment.7] 1245 Destination endpoint ID length and value - are the length (as a 1246 four byte value in network byte order) and value of the 1247 destination endpoint ID from the primary bundle block. The URI is 1248 simply copied from the relevant part(s) of the dictionary block 1249 and is not itself canonicalised. Although the dictionary entries 1250 contain null-terminators, the null-terminators are not included in 1251 the length or the canonicalization. 1253 Source endpoint ID length and value are handled similarly to the 1254 destination. 1256 Report-to endpoint ID length and value are handled similarly to 1257 the destination. 1259 Creation time (2 x SDNV) and Lifetime (SDNV) are simply copied 1260 from the primary block, with the SDNV values being represented as 1261 eight-byte unpacked values. 1263 Fragment offset and Total application data unit length are 1264 ignored, as is the case for the "bundle is a fragment" bit 1265 mentioned above. If the payload data to be canonicalized is less 1266 than the complete, original bundle payload, the offset and length 1267 are specified in the security-parameters. 1269 For non-primary blocks being included in the canonicalization, the 1270 block processing flags value used for canonicalization is the 1271 unpacked SDNV value with reserved and mutable bits masked to zero. 1272 The unpacked value is ANDed with mask 0x0000 0000 0000 0057 to zero 1273 reserved bits and the "last block" flag. The "last block" flag is 1274 ignored because BABs and other security blocks may be added for some 1275 parts of the journey but not others so the setting of this bit might 1276 change from hop to hop. 1278 Endpoint ID references in security blocks are canonicalized using the 1279 de-referenced text form in place of the reference pair. The 1280 reference count is not included, nor is the length of the endpoint ID 1281 text. 1283 The block-length is canonicalized as an eight-byte unpacked value in 1284 network byte order. If the payload data to be canonicalized is less 1285 than the complete, original bundle payload, this field contain the 1286 size of the data being canonicalized (the "effective block") rather 1287 that the actual size of the block. 1289 Payload blocks are generally canonicalized as-is with the exception 1290 that in some instances only a portion of the payload data is to be 1291 protected. In such a case, only those bytes are included in the 1292 canonical form, and additional ciphersuite parameters are required to 1293 specify which part of the payload is protected, as discussed further 1294 below. 1296 Security blocks are handled likewise, except that the ciphersuite 1297 will likely specify that the "current" security block security result 1298 field not be considered part of the canonical form. This differs 1299 from the strict canonicalisation case since we might use the mutable 1300 canonicalisation algorithm to handle sequential signatures such that 1301 signatures cover earlier ones. 1303 Notes: 1305 - The canonical form of the bundle is not transmitted. It is 1306 simply an artifact used as input to digesting. 1308 - We omit the reserved flags because we cannot determine if they 1309 will change in transit. The masks specified above may have to be 1310 revised if additional flags are defined and they need to be 1311 protected. 1313 - Our URI encoding does not preserve the "null-termination" 1314 convention from the dictionary field, nor do we separate the 1315 scheme and ssp as is done there. 1317 - The URI encoding will cause errors if any node rewrites the 1318 dictionary content (e.g. changing the DNS part of an HTTP URL from 1319 lower-case to upper case). This could happen transparently when a 1320 bundle is synched to disk using one set of software and then read 1321 from disk and forwarded by a second set of software. Because 1322 there are no general rules for canonicalising URIs (or IRIs), this 1323 problem may be an unavoidable source of integrity failures. 1325 - All SDNV fields here are canonicalized as eight-byte unpacked 1326 values in network byte order. Length fields are canonicalized as 1327 four-byte values in network byte order. Encoding does not need 1328 optimization since the values are never sent over the network. 1330 If a bundle is fragmented before the PIB is applied then the PIB 1331 applies to a fragment and not the entire bundle. However, the 1332 protected fragment could be subsequently further fragmented, which 1333 would leave the verifier unable to know which bytes were protected 1334 by the PIB. Even in the absence of frgmentation the same 1335 situation applies if the ciphersuite is defined to allow 1336 protection of less than the entire, original bundle payload. 1338 For this reason, PIB ciphersuites which support applying a PIB to 1339 less than the complete, original bundle payload MUST specify, as 1340 part of the ciphersuite parameters, which bytes of the bundle 1341 payload are protected. When verification occurs, only the 1342 specified range of the payload bytes are input to PIB 1343 verification. It is valid for a ciphersuite to be specified so as 1344 to only apply to entire bundles and not to fragments. A 1345 ciphersuite may be specified to apply to only a portion of the 1346 payload, regardless of whether the payload is a fragment or the 1347 complete original bundle payload. 1349 The same fragmentation issue applies equally to PCB ciphersuites. 1350 Ciphersuites which support applying confidentiality to fragments 1351 MUST specify, as part of the ciphersuite parameters, which bytes 1352 of the bundle payload are protected. When decrypting a fragment, 1353 only the specified bytes are processed. It is also valid for a 1354 confidentiality ciphersuite to be specified so as to only apply to 1355 entire bundles and not to fragments. 1357 3.5. Endpoint ID confidentiality 1359 Every bundle MUST contain a primary block that cannot be encrypted 1360 which also contains the source and destinations endpoint IDs, and 1361 others. If endpoint ID confidentiality is required, then a fake 1362 primary block with false values for these fields must be constructed 1363 and with a new block type to contain the actual values. There is 1364 presently no mechanism defined that supports such a "fake block" or 1365 possibly "fake dictionary". Bundle-in-bundle encapsulation may solve 1366 this problem in some instances. 1368 Similarly, confidentiality requirements may also apply to other parts 1369 of the primary block (e.g. the current-custodian) and that is 1370 supported in the same manner. 1372 3.6. Bundles received from other nodes 1374 Nodes implementing this specification SHALL consult their security 1375 policy to determine whether or not a received bundle is required by 1376 policy to include a BAB. If the bundle is not required to have a 1377 BAB, then BAB processing on the received bundle is complete and the 1378 bundle is ready to be further processed for PCB/PIB handling or 1379 delivery or forwarding. 1381 If the bundle is required to have a BAB but does not, then the bundle 1382 MUST be discarded and processed no further. If the bundle is 1383 required to have a BAB but all of its BABs identify a different node 1384 other than the receiving node as the BAB security destination, then 1385 the bundle MUST be discarded and processed no further. 1387 If the bundle has one or more BABs that identify the receiving node 1388 as the BAB security destination, or for which there is no security 1389 destination, then the value in the security result field(s) of the 1390 BAB(s) MUST be verified according to the ciphersuite specification. 1391 If for all such BABs in the bundle either the BAB security source 1392 cannot be determined or the security result value check fails, the 1393 bundle has failed to authenticate and the bundle MUST be discarded 1394 and processed no further. Otherwise, if any of the BABs present 1395 verify, the bundle is ready for further processing as determined by 1396 extension blocks and/or policy. 1398 BABs received in a bundle MUST be stripped before the bundle is 1399 forwarded. New BABs MAY be added as required by policy. This may 1400 require correcting the "last block" field of the to-be-forwarded 1401 bundle. 1403 Further processing of the bundle must take place in the order 1404 indicated by the various blocks from the primary block to the payload 1405 block, except as defined by an applicable specification. 1407 If the bundle has a PCB and the receiving node is the PCB destination 1408 for the bundle (either because the node is listed as the bundle's 1409 PCB-dest or because the node is listed as the bundle's destination 1410 and there is no PCB-dest), the node MUST decrypt the relevant parts 1411 of the bundle in accordce with the ciphersuite specification. The 1412 PCB SHALL be deleted. If the relevant parts of the bundle cannot be 1413 decrypted (i.e., the decryption key cannot be deduced or decryption 1414 fails), then the bundle MUST be discarded and processed no further; 1415 in this case a bundle deletion status report (see the Bundle Protocol 1416 [2]) indicating the decryption failure MAY be generated. If the PCB 1417 security result included the ciphertext of a block other than the 1418 payload block, the recovered plaintext block MUST be placed in the 1419 bundle at the location from which the PCB was deleted.[Comment.8] 1421 If the bundle has one or more PIBs for which the receiving node is 1422 the bundle's PIB destination (either because the node is listed in 1423 the bundle's PIB-dest or because the node is listed as the bundle's 1424 destination and there is no PIB-dest), the node MUST verify the value 1425 in the PIB security result field(s) in accordance with the 1426 ciphersuite specification. If all the checks fail, the bundle has 1427 failed to authenticate and the bundle SHALL be processed according to 1428 the security policy. A bundle status report indicating the failure 1429 MAY be generated. Otherwise, if the PIB verifies, the bundle is 1430 ready to be processed for either delivery or forwarding. Before 1431 forwarding the bundle, the node SHOULD remove the PIB from the 1432 bundle, subject to the requirements of Section 3.2, unless it is 1433 likely that some downstream node will also be able to verify the PIB. 1435 If the bundle has a PIB and the receiving node is not the bundle's 1436 PIB-dest the receiving node MAY attempt to verify the value in the 1437 security result field. If it is able to check and the check fails, 1438 the node SHALL discard the bundle and it MAY send a bundle status 1439 report indicating the failure.[Comment.9][Comment.10] 1441 3.7. The At-Most-Once-Delivery Option 1443 An application may request (in an implementation specific manner) 1444 that a node be registered as a member of an endpoint and that 1445 received bundles destined for that endpoint be delivered to that 1446 application. 1448 An option for use in such cases is known as "at-most-once-delivery". 1449 If this option is chosen, the application indicates that it wants the 1450 node to check for duplicate bundles, discard duplicates, and deliver 1451 at most one copy of each received bundle to the application. If this 1452 option is not chosen, the application indicates that it wants the 1453 node to deliver all received bundle copies to the application. If 1454 this option is chosen, the node SHALL deliver at most one copy of 1455 each received bundle to the application. If the option is not 1456 chosen, the node SHOULD, subject to policy, deliver all bundles. 1458 To enforce this the node MUST look at the source/timestamp pair value 1459 of each complete (reassembled, if necessary) bundle received and 1460 determine if this pair, which uniquely identifies a bundle, has been 1461 previously received. If it has, then the bundle is a duplicate. If 1462 it has not, then the bundle is not a duplicate. The source/timestamp 1463 pair SHALL be added to the list of pair values already received by 1464 that node. 1466 Each node implementation may decide how long to maintain a table of 1467 pair value state. 1469 Additional discussion relevant to at-most-delivery is in the DTN 1470 Retransmission Block specification [11]. 1472 3.8. Bundle Fragmentation and Reassembly 1474 If it is necessary for a node to fragment a bundle and security 1475 services have been applied to that bundle, the fragmentation rules 1476 described in [2] MUST be followed. As defined there and repeated 1477 here for completeness, only the payload may be fragmented; security 1478 blocks, like all extension blocks, can never be fragmented. In 1479 addition, the following security-specific processing is REQUIRED: 1481 The security policy requirements for a bundle must be applied 1482 individually to all the bundles resulting from a fragmentation event. 1484 If the original bundle contained a PIB, then each of the PIB 1485 instances MUST be included in some fragment. 1487 If the original bundle contained one or more PCBs, then any PCB 1488 instances containing a BEK MUST have the "replicate in every 1489 fragment" flag set, and thereby be replicated in every fragment. 1490 This is to ensure that the canonical block-sequence can be recovered 1491 during reassembly. 1493 If the original bundle contained one or more correlated PCBs not 1494 containing a BEK, then each of these MUST be included in some 1495 fragment, but SHOULD NOT be sent more than once. They MUST be placed 1496 in a fragment in accordance with the fragmentation rules described in 1497 [2]. 1499 Note: various fragments may have additional security blocks added at 1500 this or later stages and it is possible that correlators may collide. 1501 In order to facilitate uniqueness, ciphersuites SHOULD include the 1502 fragment-offset of the fragment as a high-order component of the 1503 correlator. 1505 3.9. Reactive fragmentation 1507 When a partial bundle has been received, the receiving node SHALL 1508 consult its security policy to determine if it may fragment the 1509 bundle, converting the received portion into a bundle fragment for 1510 further forwarding. Whether or not reactive fragmentation is 1511 permitted SHALL depend on the security policy and the ciphersuite 1512 used to calculate the BAB authentication information, if required. 1513 (Some BAB ciphersuites, i.e., the mandatory BAB-HMAC ciphersuite 1514 defined in Section 4.1, do not accommodate reactive fragmentation 1515 because the security result in the BAB requires that the entire 1516 bundle be signed. It is conceivable, however, that a BAB ciphersuite 1517 could be defined such that multiple security results are calculated, 1518 each on a different segment of a bundle, and that these security 1519 results could be interspersed between bundle payload segments such 1520 that reactive fragmentation could be accommodated.) 1522 If the bundle is reactively fragmented by the intermediate receiver 1523 and the BAB-ciphersuite is of an appropriate type (e.g. with multiple 1524 security results embedded in the payload), the bundle MUST be 1525 fragmented immediately after the last security result value in the 1526 partial payload that is received. Any data received after the last 1527 security result value MUST be dropped. 1529 If a partial bundle is received at the intermediate receiver and is 1530 reactively fragmented and forwarded, only the part of the bundle that 1531 was not received MUST be retransmitted, though more of the bundle MAY 1532 be retransmitted. Before retransmitting a portion of the bundle, it 1533 SHALL be changed into a fragment and, if the original bundle included 1534 a BAB, the fragmented bundle MUST also, and its BAB SHALL be 1535 recalculated. 1537 This specification does not currently define any ciphersuite which 1538 can handle this reactive fragmentation case. 1540 An interesting possibility is a ciphersuite definition such that the 1541 transmission of a follow-up fragment would be accompanied by the 1542 signature for the payload up to the restart point. 1544 4. Mandatory Ciphersuites 1546 This section defines the mandatory ciphersuites for this 1547 specification. There is currently one mandatory ciphersuite for use 1548 with each security block type (BAB, PIB and PCB). The BAB 1549 ciphersuite is based on shared secrets using HMAC. The PIB 1550 ciphersuite is based on digital signatures using RSA with SHA256. 1551 The PCB ciphersuite is based on using RSA for key transport and AES 1552 for bulk encryption. 1554 4.1. BAB-HMAC 1556 The BAB-HMAC ciphersuite has ciphersuite ID value 0x001. 1558 Security parameters are optional with this scheme, but if used then 1559 the only field that can be present is key information (see 1560 Section 2.5). The exact type of key information to be used is an 1561 implementation issue. In the absence of key information the receiver 1562 is expected to be able to find the correct key based on the sending 1563 identity. The sending identity may be known from the security-source 1564 field or the content of a previous-hop block in the bundle. It may 1565 also be determined using implementation-specific means such as the 1566 convergence layer. 1568 BAB-HMAC uses the strict canonicalisation algorithm in Section 3.4.1. 1570 Strict canonicalization supports digesting of a fragment-bundle. It 1571 does not permit the digesting of only a subset of the payload, but 1572 only the complete contents of the payload of the current bundle, 1573 which might be a fragment. The "fragment range" item for security- 1574 parameters is not used to indicate a fragment, as this information is 1575 digested within the primary block. 1577 The variant of HMAC to be used is HMAC-SHA1 as defined in RFC 2104 1578 [4].[Comment.11] 1580 This ciphersuite requires the use of two related instances of the 1581 BAB. It involves placing the first BAB instance (as defined in 1582 Section 2.2) just after the primary block. The second (correlated) 1583 instance of the BAB MUST be placed after all other blocks (except 1584 possibly other BAB blocks) in the bundle. 1586 This means that normally, the BAB will be the second and last blocks 1587 of the bundle. If a forwarder wishes to apply more than one 1588 correlated BAB pair, then this can be done. There is no requirement 1589 that each application "wrap" the others, but the forwarder MUST 1590 insert all the "up front" BABs, and their "at back" "partners" 1591 (without any security result), before canonicalising. 1593 Inserting more than one correlated BAB pair would be useful if the 1594 bundle could be routed to more than one potential "next-hop" or if 1595 both an old or a new key were valid at sending time, with no 1596 certainty about the situation that will obtain at reception time. 1598 The security result is the output of the HMAC-SHA1 calculation with 1599 input being the result of running the entire bundle through the 1600 strict canonicalisation algorithm. Both required BAB instances MUST 1601 be included in the bundle before canonicalisation. 1603 4.2. PIB-RSA-SHA256 1605 The PIB-RSA-SHA256 ciphersuite has ciphersuite ID value 0x02. 1607 If the bundle being signed has been fragmented before signing, then 1608 we have to specify which bytes were signed in case the signed bundle 1609 is subsequently fragmented for a second time. If the bundle is a 1610 fragment, then the ciphersuite parameters MUST include a fragment- 1611 range field, as described in Section 2.5, specifying the offset and 1612 length of the signed fragment. If the entire bundle is signed then 1613 these numbers MUST be omitted. 1615 The ciphersuite parameters field MAY also contain a key information 1616 item. The exact type of key information to be used is an 1617 implementation issue. In the absence of a key identifier, the 1618 verifier of the PIB is expected to be able to use the security source 1619 (if supplied) or else the bundle source (if no security source is 1620 present) in order to determine the correct public key to use for PIB 1621 verification. 1623 PIB-RSA-SHA256 uses the mutable canonicalisation algorithm 1624 Section 3.4.2, with the security-result data field for only the 1625 "current" block being excluded from the canonical form. The 1626 resulting canonical form of the bundle is the input to the signing 1627 process. This ciphersuite requires the use of a single instance of 1628 the PIB. 1630 RSA is used with SHA256 as specified for the sha256WithRSAEncryption 1631 PKCSv1.5 signature scheme in RFC 4055 [5]. The output of the signing 1632 process is the security result item for the PIB. 1634 "Commensurate strength" cryptography is generally held to be a good 1635 idea. A combination of RSA with SHA256 is reckoned to require a 3076 1636 bit RSA key according to this logic. Few implementations will choose 1637 this length by default (and probably some just won't support such 1638 long keys). Since this is an experimental protocol, we expect that 1639 1024 or 2048 bit RSA keys will be used in many cases, and that that 1640 will be fine since we also expect that the hash function "issues" 1641 will be resolved before any standard would be derived from this 1642 protocol.[Comment.12] 1644 4.3. PCB-RSA-AES128-PAYLOAD-PIB-PCB 1645 [Comment.13] 1647 The PCB-RSA-AES128-PAYLOAD-PIB-PCB ciphersuite has ciphersuite ID 1648 value 0x003. 1650 This scheme encrypts PIBs, PCBs and the payload. The key size for 1651 this ciphersuite is 128 bits. 1653 Encryption is done using the AES algorithm in Galois/Counter Mode 1654 (GCM) as described in RFC 5084 [12] [Note: parts of the following 1655 description are borrowed from RFC 4106]. 1657 The choice of GCM avoids expansion of the payload, which causes 1658 problems with fragmentation/reassembly and custody transfer. GCM 1659 also includes authentication, essential in preventing attacks that 1660 can alter the decrypted plaintext or even recover the encryption key. 1662 GCM is a block cipher mode of operation providing both 1663 confidentiality and data origin authentication. The GCM 1664 authenticated encryption operation has four inputs: a secret key, an 1665 initialization vector (IV), a plaintext, and an input for additional 1666 authenticated data (AAD) which is not used here. It has two outputs, 1667 a ciphertext whose length is identical to the plaintext, and an 1668 authentication tag, also known as the Integrity Check Value (ICV). 1670 For consistency with the description in [12], we refer to the GCM IV 1671 as a nonce. The same key and nonce combination MUST NOT be used more 1672 than once. The nonce has the following layout 1674 +----------------+----------------+---------------------------------+ 1675 | salt | 1676 +----------------+----------------+---------------------------------+ 1677 | | 1678 | initialization vector | 1679 | | 1680 +----------------+----------------+---------------------------------+ 1682 Nonce format. 1684 Figure 6 1686 The salt field is a four-octet value, usually chosen at random. It 1687 MUST be the same for all PCBs which have the same correlator value. 1689 The salt need not be kept secret. 1691 The initialization vector (IV) is an eight-octet value, usually 1692 chosen at random. It MUST be different for all PCBs which have the 1693 same correlator value. The value need not be kept secret. 1695 The key (bundle encryption key, BEK) is a sixteen-octet (128 bits) 1696 value, usually chosen at random. The value MUST be kept secret, as 1697 described below. 1699 The integrity check value is a sixteen-octet value used to verify 1700 that the protected data has not been altered. The value need not be 1701 kept secret. 1703 This ciphersuite requires the use of a single PCB instance to deal 1704 with payload confidentiality. If the bundle already contains PIBs or 1705 PCBs then the ciphersuite will create additional correlated blocks to 1706 protect these PIBs and PCBs. These "additional" blocks replace the 1707 original blocks on a one-for-one basis, so the number of blocks 1708 remains unchanged. All these related blocks MUST have the same 1709 correlator value. The term "first PCB" in this section refers to the 1710 single PCB if there is only one or, if there are several, then to the 1711 one containing the key information. This MUST be the first of the 1712 set. 1714 First PCB - the first PCB may contain a correlator value, and may 1715 specify security-source and/or security-destination in the eid-list. 1716 If not specified, the bundle-source and bundle-destination 1717 respectively are used for these values, as with other ciphersuites. 1718 The block MUST contain security-parameters and security-result 1719 fields. Each field may contain several items formatted as described 1720 in Section 2.5. 1722 Security-parameters 1724 key information 1726 salt 1728 IV (this instance applies only to payload) 1730 fragment offset and length, if bundle is a fragment 1732 Security-result 1734 ICV 1736 Subsequent PCBs MUST contain a correlator value to link them to the 1737 first PCB. Security-source and security-destination are implied from 1738 the first PCB, however see the discussion below concerning eid-list 1739 entries. They MUST contain security-parameters and security-result 1740 fields as follows: 1742 Security-parameters 1744 IV for this specific block 1746 Security-result 1748 encapsulated block 1750 The security-parameters and security-result fields in the subsequent 1751 PCBs MUST NOT contain any items other than these two. Items such as 1752 key and salt are supplied in the first PCB and MUST NOT be repeated. 1754 Protection of the key is performed as defined in the Key Management 1755 Specification [tbd]. Key management for this ciphersuite MUST 1756 support PKCSv1.5 rsaEncryption as specified in RFC 3370 [6] and MAY 1757 support other schemes. The output from the key management protection 1758 scheme ("key information") is placed in the security-result field of 1759 the first PCB. 1761 If the bundle being encrypted is a fragment-bundle we have to specify 1762 which bytes are encrypted in case the bundle is subsequently 1763 fragmented again. If the bundle is a fragment the ciphersuite 1764 parameters MUST include a fragment-range field, as described in 1765 Section 2.5, specifying the offset and length of the encrypted 1766 fragment. Note that this is not the same pair of fields which appear 1767 in the primary block as "offset and length". The "length" in this 1768 case is the length of the fragment, not the original length. If the 1769 bundle is not a fragment then this field MUST be omitted. 1771 The confidentiality processing for payload and other blocks is 1772 different, mainly because the payload might be fragmented later at 1773 some other node. 1775 For the payload, only the bytes of the bundle payload field are 1776 affected, being replaced by ciphertext. The salt, IV and key values 1777 specified in the first PCB are used to encrypt the payload, and the 1778 resultant authentication tag (ICV) is placed in an ICV item in the 1779 security-result field of that first PCB. The other bytes of the 1780 payload block, such as type, flags and length, are not modified. 1782 For each PIB or PCB to be protected, the entire original block is 1783 encapsulated in a "replacing" PCB. This replacing PCB is placed in 1784 the outgoing bundle in the same position as the original block, PIB 1785 or PCB. As mentioned above, this is one-for-one replacement and 1786 there is no consolidation of blocks or mixing of data in any way. 1788 The encryption process uses AES-GCM with the salt and key values from 1789 the first PCB, and an IV unique to this PCB. The process creates 1790 ciphertext for the entire original block, and an authentication tag 1791 for validation at the security destination. For this encapsulation 1792 process, unlike the processing of the bundle payload, the 1793 authentication tag is appended to the ciphertext for the block and 1794 the combination is stored into the "encapsulated block" item in 1795 security-result. 1797 The replacing block, of course, also has the same correlator value as 1798 the first PCB with which it is associated. It also contains the 1799 block-specific IV in security-parameters, and the combination of 1800 original-block-ciphertext and authentication tag, stored as an 1801 "encapsulated block" item in security-result. 1803 Any existing eid-list in the to-be-encapsulated original block 1804 remains exactly as-is, and become the eid-list for the replacing 1805 block. The encapsulation process MUST NOT replace or remove the 1806 existing eid-list entries. This is critically important for correct 1807 updating of entries at the security-destination. 1809 At the security-destination, either specific destination or the 1810 bundle destination, the processes described above are reversed. The 1811 payload is decrypted in-place using the salt, IV and key values in 1812 the first PCB, including verification using the ICV. Each correlated 1813 PCB is also processed at the same destination, using the salt and key 1814 values from the first PCB and the block-specific IV item. The 1815 "encapsulated block" item in security-result is decrypted, and 1816 validated using the tag which was appended to the ciphertext of the 1817 original block data. Assuming the validation succeeds, the resultant 1818 plaintext, which is the entire content of the original block, 1819 replaces the PCB at the same place in the bundle. The block type 1820 reverts to that of the original block prior to encapsulation, and the 1821 other block-specific data fields also return to their original 1822 values. Implementors are cautioned that this "replacement" process 1823 requires delicate stitchery, as the eid-list contents in the 1824 decapsulated block are invalid. As noted above, the eid-list 1825 references in the original block were preserved in the replacing PCB, 1826 and will have been updated as necessary as the bundle has toured the 1827 dtnet. The references from the PCB MUST replace the references 1828 within the eid-list of the newly-decapsulated block. Caveat 1829 implementor. 1831 If the payload was fragmented after encryption then all those 1832 fragments MUST be present and reassembled before decryption. This 1833 process might be repeated several times at different destinations if 1834 multiple fragmentation actions have occurred. 1836 The size of the GCM counter field limits the payload size to 2^39 - 1837 256 bytes, about half a terabyte. A future revision of this 1838 specification will address the issue of handling payloads in excess 1839 of this size. 1841 5. Key Management 1843 Since key management in delay tolerant networks is still a research 1844 topic we cannot provide much in the way of useful key management 1845 here. However, solely in order to support implementation and 1846 testing, implementations SHOULD support: 1848 - Long-term pre-shared-symmetric keys for the BAB-HMAC 1849 ciphersuite. 1851 - The use of well-known RSA public keys for PIB-RSA-SHA256 and 1852 PCB-RSA-AES128-PAYLOAD-PIB-PCB ciphersuites. 1854 Since endpoint IDs are URIs and URIs can be placed in X.509 [7] 1855 public key certificates (in the subjectAltName extension) 1856 implementations SHOULD support this way of distributing public keys. 1857 Implementations SHOULD NOT be very strict in how they process X.509 1858 though, for example, it would probably not be correct to insist on 1859 Certificate Revocation List (CRL) checking in many DTN contexts. 1861 Other than that, key management is for future study. 1863 6. Default Security Policy 1865 Every node serves as a Policy Enforcement Point insofar as it 1866 enforces some policy that controls the forwarding and delivery of 1867 bundles via one or more convergence layer protocol implementation. 1868 Consequently, every node SHALL have and operate according to its own 1869 configurable security policy, whether the policy be explicit or 1870 default. The policy SHALL specify: 1872 Under what conditions received bundles SHALL be forwarded. 1874 Under what conditions received bundles SHALL be required to 1875 include valid BABs. 1877 Under what conditions the authentication information provided in a 1878 bundle's BAB SHALL be deemed adequate to authenticate the bundle. 1880 Under what conditions received bundles SHALL be required to have 1881 valid PIBs and/or PCBs. 1883 Under what conditions the authentication information provided in a 1884 bundle's PIB SHALL be deemed adequate to authenticate the bundle. 1886 Under what conditions a BAB SHALL be added to a received bundle 1887 before that bundle is forwarded. 1889 Under what conditions a PIB SHALL be added to a received bundle 1890 before that bundle is forwarded. 1892 Under what conditions a PCB SHALL be added to a received bundle 1893 before that bundle is forwarded. 1895 The actions that SHALL be taken in the event that a received 1896 bundle does not meet the receiving node's security policy 1897 criteria. 1899 This specification does not address how security policies get 1900 distributed to nodes. It only REQUIRES that nodes have and enforce 1901 security policies. [Comment.14] 1903 If no security policy is specified at a given node, or if a security 1904 policy is only partially specified, that node's default policy 1905 regarding unspecified criteria SHALL consist of the following: 1907 Bundles that are not well-formed do not meet the security policy 1908 criteria. 1910 The mandatory ciphersuites MUST be used. 1912 All bundles received MUST have a BAB which MUST be verified to 1913 contain a valid security result. If the bundle does not have a 1914 BAB, then the bundle MUST be discarded and processed no further; a 1915 bundle status report indicating the authentication failure MAY be 1916 generated. 1918 No received bundles SHALL be required to have a PIB; if a received 1919 bundle does have a PIB, however, the PIB can be ignored unless the 1920 receiving node is the PIB-dest, in which case the PIB MUST be 1921 verified. 1923 No received bundles SHALL be required to have a PCB; if a received 1924 bundle does have a PCB, however, the PCB can be ignored unless the 1925 receiving node is the PCB-dest, in which case the PCB MUST be 1926 processed. If processing of a PCB yields a PIB, that PIB SHALL be 1927 processed by the node according to the node's security policy. 1929 A PIB SHALL NOT be added to a bundle before sourcing or forwarding 1930 it. 1932 A PCB SHALL NOT be added to a bundle before sourcing or forwarding 1933 it. 1935 A BAB MUST always be added to a bundle before that bundle is 1936 forwarded. 1938 If a destination node receives a bundle that has a PIB-dest but 1939 the value in that PIB-dest is not the EID of the destination node, 1940 the bundle SHALL be delivered at that destination node. 1942 If a received bundle does not satisfy the node's security policy 1943 for any reason, then the bundle MUST be discarded and processed no 1944 further; in this case, a bundle deletion status report (see the 1945 Bundle Protocol [2]) indicating the failure MAY be generated. 1947 7. Security Considerations 1948 [Comment.15] 1950 If a BAB ciphersuite uses digital signatures but doesn't include the 1951 security destination (which for a BAB is the next host), then this 1952 allows the bundle to be sent to some node other than the intended 1953 adjacent node. Because the BAB will still authenticate, the 1954 receiving node may erroneously accept and forward the bundle. When 1955 asymmetric BAB ciphersuites are used, the security destination field 1956 SHOULD therefore be included in the BAB. 1958 If a bundle's PIB-dest is not the same as its destination, then some 1959 node other than the destination (the node identified as the PIB-dest) 1960 is expected to validate the PIB security result while the bundle is 1961 en route. However, if for some reason the PIB is not validated, 1962 there is no way for the destination to become aware of this. 1963 Typically, a PIB-dest will remove the PIB from the bundle after 1964 verifying the PIB and before forwarding it. However, if there is a 1965 possibility that the PIB will also be verified at a downstream node, 1966 the PIB-dest will leave the PIB in the bundle. Therefore, if a 1967 destination receives a bundle with a PIB that has a PIB-dest (which 1968 isn't the destination), this may, but does not necessarily, indicate 1969 a possible problem. 1971 If a bundle is fragmented after being forwarded by its PIB-source but 1972 before being received by its PIB-dest, the payload in the bundle MUST 1973 be reassembled before validating the PIB security result in order for 1974 the security result to validate correctly. Therefore, if the PIB- 1975 dest is not capable of performing payload reassembly, its utility as 1976 a PIB-dest will be limited to validating only those bundles that have 1977 not been fragmented since being forwarded from the PIB-source. 1978 Similarly, if a bundle is fragmented after being forwarded by its 1979 PIB-source but before being received by its PIB-dest, all fragments 1980 MUST be received at that PIB-dest in order for the bundle payload to 1981 be able to be reassembled. If not all fragments are received at the 1982 PIB-dest node, the bundle will not be able to be authenticated, and 1983 will therefore never be forwarded by this PIB-dest node. 1985 Specification of a security-destination other than the bundle 1986 destination creates a routing requirement that the bundle somehow be 1987 directed to the security-destination node on its way to the final 1988 destination. This requirement is presently private to the 1989 ciphersuite, since routing nodes are not required to implement 1990 security processing. 1992 8. IANA Considerations 1994 None at this time. If the bundle protocol becomes a standards track 1995 protocol, then we may want to consider having IANA establish a 1996 register of block types, and in particular for this specification a 1997 separate register of ciphersuite specifications. 1999 9. References 2001 9.1. Normative References 2003 [1] Bradner, S. and J. Reynolds, "Key words for use in RFCs to 2004 Indicate Requirement Levels", RFC 2119, October 1997. 2006 [2] Scott, K. and S. Burleigh, "Bundle Protocol Specification", 2007 RFC 5050, November 2007. 2009 [3] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, 2010 August 2002. 2012 [4] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 2013 for Message Authentication", RFC 2104, February 1997. 2015 [5] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms 2016 and Identifiers for RSA Cryptography for use in the Internet 2017 X.509 Public Key Infrastructure Certificate and Certificate 2018 Revocation List (CRL) Profile", RFC 4055, June 2005. 2020 [6] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", 2021 RFC 3370, August 2002. 2023 [7] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 2024 Public Key Infrastructure Certificate and Certificate 2025 Revocation List (CRL) Profile", RFC 3280, April 2002. 2027 [8] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) 2028 in IPsec Encapsulating Security Payload (ESP)", RFC 4106, 2029 June 2005. 2031 9.2. Informative References 2033 [9] Farrell, S., Symington, S., Weiss, H., and P. Lovell, "Delay- 2034 Tolerant Networking Security Overview", 2035 draft-irtf-dtnrg-sec-overview-04.txt, work-in-progress, 2036 February 2008. 2038 [10] Cerf, V., Burleigh, S., Durst, R., Fall, K., Hooke, A., Scott, 2039 K., Torgerson, L., and H. Weiss, "Delay-Tolerant Network 2040 Architecture", RFC 4838, April 2007. 2042 [11] Symington, S., "Delay-Tolerant Network Retransmission Block", 2043 draft-irtf-dtnrg-bundle-retrans-00.txt, work-in-progress, 2044 April 2007. 2046 [12] Housley, R., "Using AES-CCM and AES-GCM Authenticated 2047 Encryption in the Cryptographic Message Syntax (CMS)", 2048 RFC 5084, November 2007. 2050 Editorial Comments 2052 [Comment.1] Stephen: I guess there could be some weird corner case 2053 where a PCB ciphersuite using counter-mode would allow 2054 fragments to be individually decrypted, and in that 2055 case, we might want to set replication for each 2056 fragment. So we can't fully rule out setting that flag 2057 for all PIB/PCB. 2059 [Comment.2] plovell: in fact, we do need it set for C blocks (first 2060 only if a correlated set) in order to recover canonical 2061 processing order after fragmentation/reassembly 2063 [Comment.3] Stephen: This to be revisited! 2065 [Comment.4] Note: there is no ciphersuite definition which supports 2066 this "parallel" encryption scheme -- needs thought. All 2067 definitions so far are for sequential encryptors, and 2068 we don't have a way to indicate "parallel". Maybe it's 2069 just that the PCB-dest is different? I hate to think 2070 what the API would look like :) 2072 [Comment.5] Stephen: Do we need to specify error handling for the 2073 case where a node drops a bundle for policy reasons? 2074 Does/can it signal back to the source that its done so? 2076 [Comment.6] Howie: The security policy database will need to be 2077 discussed somewhere. Does it belong in this document, 2078 the bundle protocol spec., both, some other document? 2080 [Comment.7] Editors: Check that mask value at the very last moment 2081 (incl. during auth-48) to be sure its (still) correct. 2083 [Comment.8] plovell: do we generate a report even if the failure 2084 was a security failure? That's often regarded as poor 2085 practice. 2087 [Comment.9] plovell: should this be "SHALL discard" or "SHALL 2088 delete" ? 2090 [Comment.10] plovell: do we generate a report even if the failure 2091 was a security failure? That's often regarded as poor 2092 practice. 2094 [Comment.11] Editors: At the moment there appears to be no security 2095 reason to move away from HMAC-SHA1 since the HMAC 2096 construct is not as far as we know affected by 2097 collisions in the underlying digest algorithm (which 2098 are nearly practically computable for SHA-1). 2099 Nevertheless, since we use SHA-256 in the signature 2100 ciphersuite (since collisions do matter there), it may 2101 be desirable to move to HMAC-SHA-256 as specified in 2102 RFC 4321. So if you're writing code based on this...be 2103 warned! 2105 [Comment.12] Editors: There are currently unresolved "issues" with 2106 digest algorithms which might cause a change here prior 2107 to, but more likely, after, an RFC has issued. So 2108 expect change! 2110 [Comment.13] Editors: This section has progressed to Woodman status. 2112 [Comment.14] Howie: Eventually we will need to state where the 2113 security policy information/DB does get discussed/ 2114 specified. 2116 [Comment.15] Editors: Much more text is needed here no doubt. 2118 Authors' Addresses 2120 Susan Flynn Symington 2121 The MITRE Corporation 2122 7515 Colshire Drive 2123 McLean, VA 22102 2124 US 2126 Phone: +1 (703) 983-7209 2127 Email: susan@mitre.org 2128 URI: http://mitre.org/ 2130 Stephen Farrell 2131 Trinity College Dublin 2132 Distributed Systems Group 2133 Department of Computer Science 2134 Trinity College 2135 Dublin 2 2136 Ireland 2138 Phone: +353-1-608-1539 2139 Email: stephen.farrell@cs.tcd.ie 2141 Howard Weiss 2142 SPARTA, Inc. 2143 7110 Samuel Morse Drive 2144 Columbia, MD 21046 2145 US 2147 Phone: +1-443-430-8089 2148 Email: hsw@sparta.com 2150 Peter Lovell 2151 SPARTA, Inc. 2152 7110 Samuel Morse Drive 2153 Columbia, MD 21046 2154 US 2156 Phone: +1-443-430-8052 2157 Email: peter.lovell@sparta.com 2159 Full Copyright Statement 2161 Copyright (C) The IETF Trust (2008). 2163 This document is subject to the rights, licenses and restrictions 2164 contained in BCP 78, and except as set forth therein, the authors 2165 retain all their rights. 2167 This document and the information contained herein are provided on an 2168 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2169 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2170 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2171 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2172 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2173 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2175 Intellectual Property 2177 The IETF takes no position regarding the validity or scope of any 2178 Intellectual Property Rights or other rights that might be claimed to 2179 pertain to the implementation or use of the technology described in 2180 this document or the extent to which any license under such rights 2181 might or might not be available; nor does it represent that it has 2182 made any independent effort to identify any such rights. Information 2183 on the procedures with respect to rights in RFC documents can be 2184 found in BCP 78 and BCP 79. 2186 Copies of IPR disclosures made to the IETF Secretariat and any 2187 assurances of licenses to be made available, or the result of an 2188 attempt made to obtain a general license or permission for the use of 2189 such proprietary rights by implementers or users of this 2190 specification can be obtained from the IETF on-line IPR repository at 2191 http://www.ietf.org/ipr. 2193 The IETF invites any interested party to bring to its attention any 2194 copyrights, patents or patent applications, or other proprietary 2195 rights that may cover technology that may be required to implement 2196 this standard. Please address the information to the IETF at 2197 ietf-ipr@ietf.org. 2199 Acknowledgment 2201 Funding for the RFC Editor function is provided by the IETF 2202 Administrative Support Activity (IASA).