idnits 2.17.1 draft-irtf-dtnrg-bundle-security-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1510. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 771 has weird spacing: '... Source endpo...' == Line 1381 has weird spacing: '...s to be indiv...' == Line 1426 has weird spacing: '... digest algor...' -- 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 (March 3, 2006) is 6627 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) -- Looks like a reference, but probably isn't: 'SDNV' on line 1175 == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-bundle-spec-04 ** Downref: Normative reference to an Experimental draft: draft-irtf-dtnrg-bundle-spec (ref. '2') == Outdated reference: A later version (-08) exists of draft-irtf-dtnrg-arch-04 ** Downref: Normative reference to an Informational draft: draft-irtf-dtnrg-arch (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '4') ** Obsolete normative reference: RFC 3280 (ref. '8') (Obsoleted by RFC 5280) == Outdated reference: A later version (-06) exists of draft-irtf-dtnrg-sec-overview-01 Summary: 7 errors (**), 0 flaws (~~), 8 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: September 4, 2006 S. Farrell 5 Trinity College Dublin 6 H. Weiss 7 SPARTA, Inc. 8 March 3, 2006 10 Bundle Security Protocol Specification 11 draft-irtf-dtnrg-bundle-security-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 4, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document defines the bundle security protocol, which provides 45 data integrity and confidentiality services. We also describe 46 various bundle security considerations including policy options. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Related Documents . . . . . . . . . . . . . . . . . . . . 3 52 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Security Headers . . . . . . . . . . . . . . . . . . . . . . . 6 54 2.1. Abstract Security Header . . . . . . . . . . . . . . . . . 7 55 2.2. Bundle Authentication Header . . . . . . . . . . . . . . . 10 56 2.3. Payload Security Header . . . . . . . . . . . . . . . . . 11 57 2.4. Confidentiality Header . . . . . . . . . . . . . . . . . . 11 58 2.5. PSH and CH combinations . . . . . . . . . . . . . . . . . 14 59 3. Security Processing . . . . . . . . . . . . . . . . . . . . . 16 60 3.1. Nodes as policy enforcement points . . . . . . . . . . . . 16 61 3.2. Canonicalisation of bundles . . . . . . . . . . . . . . . 16 62 3.3. Source confidentiality . . . . . . . . . . . . . . . . . . 20 63 3.4. Bundles received from other nodes . . . . . . . . . . . . 21 64 3.5. The At-Most-Once-Delivery Option . . . . . . . . . . . . . 22 65 3.6. Bundle Fragmentation and Reassembly . . . . . . . . . . . 23 66 3.7. Reactive fragmentation . . . . . . . . . . . . . . . . . . 23 67 4. Mandatory Ciphersuites . . . . . . . . . . . . . . . . . . . . 25 68 4.1. BAH-HMAC . . . . . . . . . . . . . . . . . . . . . . . . . 25 69 4.2. PSH-RSA-SHA256 . . . . . . . . . . . . . . . . . . . . . . 26 70 4.3. CH-RSA-AES-PAYLOAD-PSH . . . . . . . . . . . . . . . . . . 26 71 5. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 28 72 6. Default Security Policy . . . . . . . . . . . . . . . . . . . 29 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 33 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 33 78 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 80 Intellectual Property and Copyright Statements . . . . . . . . . . 37 82 1. Introduction 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [1]. 88 This document defines security features for the bundle protocol [2] 89 intended for use in delay tolerant networks, in order to provide the 90 DTN security services as described in the DTN Security Overview and 91 Motivations document [9]. 93 The bundle protocol is used in DTNs which overlay multiple networks, 94 some of which may be challenged by limitations such as intermittent 95 and possibly unpredictable loss of connectivity, long or variable 96 delay, asymmetric data rates, and high error rates. The purpose of 97 the bundle protocol is to support interoperability across such 98 stressed networks. The bundle protocol is layered on top of 99 underlay-network-specific convergence layers, on top of network- 100 specific lower layers, to enable an application in one network to 101 communicate with an application in another network, both of which are 102 spanned by the DTN. 104 Security will be important for the bundle protocol. The stressed 105 environment of the underlying networks over which the bundle protocol 106 will operate makes it important that the DTN be protected from 107 unauthorized use, and this stressed environment poses unique 108 challenges on the mechanisms needed to secure the bundle protocol. 109 Furthermore, DTNs may very likely be deployed in environments where a 110 portion of the network might become compromised, posing the usual 111 security challenges related to confidentiality, integrity and 112 availability. 114 1.1. Related Documents 116 This document is best read and understood within the context of the 117 following other DTN documents: 119 The Delay-Tolerant Network Architecture [3] defines the 120 architecture for delay-tolerant networks, but does not discuss 121 security at any length. 123 The DTN Bundle Protocol [2] defines the format and processing of 124 the headers used to implement the bundle protocol, excluding the 125 security-specific headers defined here. 127 The Delay-Tolerant Networking Security Overview [9] provides an 128 informative overview and high-level description of DTN security. 130 1.2. Terminology 132 We introduce the following terminology for purposes of clarity: 134 source - the bundle node from which a bundle originates 136 destination - the bundle node to which a bundle is ultimately 137 destined 139 forwarder - the bundle node that forwarded the bundle on its most 140 recent hop 142 intermediate receiver or "next hop" - the neighboring bundle node 143 to which a forwarder forwards a bundle. 145 [Comment.1] 147 In the figure below, which is adapted from figure 1 in the Bundle 148 Protocol Specification, four bundle nodes (denoted BN1, BN2, BN3, and 149 BN4) reside above some transport layer(s). Three distinct transport 150 and network protocols (denoted T1/N1, T2/N2, and T3/N3) are also 151 shown. 153 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 154 |BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 | 155 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 156 |Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 | 157 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 158 |Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 | 159 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 160 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 161 +-----------+ +------------+ +-------------+ +-----------+ 162 | | | | 163 |<-- An Internet --->| |<--- An Internet --->| 164 | | | | 166 BN = "Bundle Node" (as defined in the Bundle Protocol Specification 168 Bundle Nodes Sit at the Application layer of the Internet Model. 170 Figure 1 172 Bundle node BN1 originates a bundle that it forwards to BN2. BN2 173 forwards the bundle to BN3, and BN3 forwards the bundle to BN4. BN1 174 is the source of the bundle and BN4 is the destination of the bundle. 176 BN1 is the first forwarder, and BN2 is the first intermediate 177 receiver; BN2 then becomes the forwarder, and BN3 the intermediate 178 receiver; BN3 then becomes the last forwarder, and BPA4 the last 179 intermediate receiver, as well as the destination. 181 If node BN2 originates a bundle (for example, a bundle status report 182 or a custodial signal), which is then forwarded on to BN3, and then 183 to BN4, then BN2 is the source of the bundle (as well as being the 184 first forwarder of the bundle) and BN4 is the destination of the 185 bundle (as well as being the final intermediate receiver). 187 We introduce the following security-specific DTN terminology: 189 security-source - a bundle node that adds a security header to a 190 bundle 192 security-destination - a bundle node that processes a security 193 header of a bundle 195 Referring to figure 1 again: 197 If the bundle that originates at BN1 as source is given a security 198 header by BN1, then BN1 is the security-source of this bundle with 199 respect to that security header, as well as being the source of the 200 bundle. 202 If the bundle that originates at BN1 as source is given a security 203 header by BN2, then BN2 is the security-source of this bundle with 204 respect to that security header, even though BN1 is the source. 206 If the bundle that originates at BN1 as source is given a security 207 header by BN1 that is intended to be processed by BN3, then BN1 is 208 the security-source and BN3 is the security destination with respect 209 to this security header. 211 A bundle may have multiple security headers. The security-source of 212 a bundle with respect to a given security header in the bundle may be 213 the same as or different from the security-source of the bundle with 214 respect to a different security header in the bundle. Similarly, the 215 security-destination of a bundle with respect to each of that 216 bundle's security headers may be the same or different. 218 2. Security Headers 220 There are three types of security headers that MAY be included in a 221 bundle. These are the Bundle Authentication Header (BAH), the 222 Payload Security Header (PSH), and the Confidentiality Header (CH). 224 The BAH is used to assure the authenticity of the bundle along a 225 single hop from forwarder to intermediate receiver. 227 The PSH is used to assure the authenticity of the bundle from the 228 PSH security-source, which creates the PSH, to the PSH security- 229 destination, which verifies the PSH authenticator. The 230 authentication information in the PSH may (if the ciphersuite 231 allows) be verified by any node in between the PSH security-source 232 and the PSH security-destination that has access to the 233 cryptographic keys and revocation status information required to 234 do so. 236 Since a BAH protects on a "hop-by-hop" basis and a PSH protects on 237 a (sort of) "end-to-end" basis, whenever both are present the BAH 238 MUST form the "outer" layer of protection - that is, the BAH MUST 239 always be calculated and added to the bundle after the PSH has 240 been calculated and added to the bundle. 242 The CH indicates that some parts of the bundle have been encrypted 243 while en route between the CH security-source and the CH security- 244 destination. 246 Each of the security headers uses the Canonical Bundle Header Format 247 as defined in the Bundle Protocol Specification. That is, each 248 security header is comprised of the following elements: 250 - Header type code 252 - Header processing control flags 254 - Header data length 256 - Header-type-specific data fields 258 Since the three security headers have most fields in common, we can 259 shorten the description of the Header-type-specific data fields of 260 each security header if we first define an abstract security header 261 (ASH) and then specify each of the real headers in terms of the 262 fields which are present/absent in an ASH. Note that no bundle ever 263 contains an ASH, which is simply a specification artifact 265 2.1. Abstract Security Header 267 An ASH consists of the following mandatory and optional fields: 269 - Header-type code (one byte) - as in all bundle protocol headers 270 except the primary bundle header. The header types codes for the 271 security headers are: 273 BAH: 0x02 275 PSH: 0x03 277 CH: 0x04 279 - Header processing control flags (one byte) - as in all bundle 280 protocol headers except the primary bundle header. There are no 281 major constraints on the use of the header processing flags, 282 however, we would expect that the BAH would not have the "transmit 283 status report" bit set since it is only present on a hop-by-hop 284 basis. 286 For a PSH, or CH, we would not expect the "replicate in every 287 fragment" bit to be set.[Comment.2] 289 - Header data length (SDNV) - as in all bundle protocol headers 290 except the primary bundle header. SDNV encoding is described in 291 the bundle protocol. 293 - Header-type-specific data fields as follows: 295 - Ciphersuite ID - identifies the ciphersuite in use. This is 296 two bytes long, though the top five bits are used to indicate 297 the presence or absence of the optional fields below. 299 - (optional) Correlator - when more than one related header is 300 inserted then this field must have the same value in each 301 related header instance. This is encoded as an SDNV. 303 - (optional) Ciphersuite parameters - parameters to be used 304 with the ciphersuite in use, e.g. a key identifier or 305 initialization vector (IV). This is encoded as an SDNV. The 306 encoding rules for this are defined as part of the ciphersuite 307 specification. 309 - (optional) Security-source-length - specifies the length of 310 the following security source field. 312 - (optional) Security-source - specifies the security source 313 for the service. If this is omitted, then the source of the 314 bundle is assumed to be the security-source. The length of 315 this field in octets is the value of the security-source-length 316 field. 318 - (optional) Security-destination-length - specifies the length 319 of the following security destination field. 321 - (optional) Security-destination - specifies the security 322 destination for the service. If this is omitted, then the 323 destination of the bundle is assumed to be the security- 324 destination. The length of this field in octets is the value 325 of the security-destination-length field. 327 - (optional) Security result length - contains the length of 328 the next field and is encoded as an SDNV. 330 - (optional) Security result - contains the results of the 331 appropriate ciphersuite-specific calculation (e.g. a signature, 332 MAC or ciphertext block key). 334 +--------+--------+--------+--------+---------+------------+-------+ 335 |type |flags |len | ciphersuite |correlator | params| 336 +--------+--------+--------+--------+---------+------------+-------+ 337 | src-len | security source | 338 +-----------------+------------------------------------------------+ 339 | dest-len | security destination | 340 +--------+--------+------------------------------------------------+ 341 | res-len | security result | 342 +--------+--------+------------------------------------------------+ 344 The structure of an abstract security header 346 Figure 2 348 The ciphersuite ID is a 16-bit value with the top five bits 349 indicating which of the optional fields are present (value = "1") or 350 absent (value="0"). The remaining 11 bits indicate the ciphersuite. 352 Some ciphersuites are specified in Section 4, which also specifies 353 the rules which MUST be satisfied by ciphersuite specifications. 354 Additional ciphersuites MAY be defined in separate specifications. 356 The structure of the ciphersuite ID bytes is shown in Figure 3. In 357 each case the presence of an optional field is indicated by setting 358 the value of the corresponding flag to one. A value of zero 359 indicates the corresponding optional field is missing. 361 src - the most significant bit (bit 15) indicates whether the ASH 362 contains the optional security-source-length and security-source 363 fields. 365 dest - bit 14 indicates whether the security-destination-length 366 and security-destination fields are present or not. 368 parm - bit 13 indicates whether the ASH contains optional 369 ciphersuite parameters or not. 371 corr - bit 12 indicates whether or not the ASH contains an 372 optional correlator. 374 res - bit 11 indicates whether or not the ASH contains security 375 result length and security result fields. 377 bits 10-0 represent the ciphersuite number, giving a maxium of 378 2048 different ciphersuites. 380 Ciphersuite ID 381 Bit Bit Bit Bit Bit Bit Bit Bit 382 15 14 13 12 11 10 ... 1 0 383 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 384 |src |dest |parm |corr |res | ciphersuite ID | 385 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 387 Figure 3 389 A little bit more terminology: when the header is a PSH then we refer 390 to the PSH-source when we mean the security source field in the PSH. 391 Similarly we may refer to the CH-dest, meaning the security- 392 destination field of the CH. For example, referring to Figure 1 393 again, if the bundle that originates at BN1 as source is given a 394 Confidentiality Header (CH) by BN1 that is protected using a key held 395 by BN3 and it is given a Payload Security Header (PSH) by BN1, then 396 BN1 is both the CH-source and the PSH-source of the bundle, and BN3 397 is the CH-dest of the bundle. 399 The correlator field is used to associate several related instances 400 of a security header. This can be used to place a BAH that contains 401 the ciphersuite information at the "front" of a (probably large) 402 bundle , and another correlated BAH that contains the security result 403 at the "end" of the bundle. This allows even very memory-constrained 404 nodes to be able to process the bundle and verify the BAH. There are 405 similar use cases for multiple related instances of PSH and CH as 406 will be seen below. 408 The ciphersuite specification MUST make it clear whether or not 409 multiple header instances are allowed, and if so, under what 410 conditions. Some ciphersuites can of course leave flexibility to the 411 implementation, whereas others might madate a fixed number of 412 instances. 414 2.2. Bundle Authentication Header 416 In this section we describe typical BAH field values for two 417 scenarios - where a single instance of the BAH contains all the 418 information and where two related instances are used, one "up front" 419 which contains the ciphersuite and another following the payload 420 which contains the security result (e.g. a MAC). 422 For the case where a single BAH is used: 424 The header-type code field value MUST be 0x02. 426 The header processing control flags value can be set to whatever 427 values are required by local policy. 429 The ciphersuite ID MUST be documented as a hop-by-hop 430 authentication-ciphersuite which requires one instance of the BAH. 432 The correlator field MUST NOT be present. 434 The ciphersuite parameters field MAY be present, if so specified 435 in the ciphersuite specification. 437 The security-source field MUST be present and MUST identify the 438 forwarder of the bundle. 440 The security-destination field SHOULD NOT be present unless the 441 ciphersuite requires this information (since the first node 442 receiving the bundle ought be the one to validate the BAH). 444 The security result MUST be present as it is effectively the 445 "output" from the ciphersuite calculation (e.g. the MAC or 446 signature) applied to the (relevant parts of) the bundle (as 447 specified in the ciphersuite definition). 449 For the case using two related BAH instances, the first instance is 450 as defined above, except the correlator MUST be present and the 451 security result MUST be absent. The second instance of the BAH MUST 452 have the same correlator value present and MUST contain a security 453 result. The other optional fields MUST NOT be present. Typically, 454 this second instance of a BAH will be the last header of the bundle. 456 2.3. Payload Security Header 458 A PSH is an ASH with the following additional restrictions: 460 The header type code value MUST be 0x03. 462 The header processing control flags value can be set to whatever 463 values are required by local policy. 465 The ciphersuite ID MUST be documented as an end-to-end 466 authentication-ciphersuite or as an end-to-end error-detection- 467 ciphersuite. 469 The correlator MUST be present if the ciphersuite requires more 470 than one related instance of a PSH be present in the bundle. The 471 correlator MUST NOT be present if the ciphersuite only requires 472 one instance of the PSH in the bundle. 474 The ciphersuite parameters field MAY be present. 476 The security-source field MAY be present. 478 The security-destination field MAY be present. 480 The security result is effectively the "output" from the 481 ciphersuite calculation (e.g. the MAC or signature) applied to the 482 (relevant parts of) the bundle. As in the case of the BAH, this 483 field MUST be present if the correlator is absent. If more than 484 one related instance of the PSH is required then this is handled 485 in the same way as described for the BAH above. 487 For some ciphersuites, (e.g. those using asymmetric keying to produce 488 signatures or those using symmetric keying with a group key), the 489 security information can be checked at any hop on the way to the 490 destination that has access to the required keying information. 492 Most asymmetric PSH-ciphersuites will use the PSH-source to indicate 493 the signer and will not require the PSH-dest field because the key 494 needed to verify the PSH authenticator will be a public key 495 associated with the PSH-source. 497 2.4. Confidentiality Header 499 A typical confidentiality ciphersuite will encrypt the payload using 500 a randomly generated bundle encrypting key (BEK) and will use a CH 501 security result to carry the BEK encrypted with some long term key 502 encryption key (KEK). or well-known public key. If neither the 503 destination or security-destination resolves the key to use for 504 decryption, the ciphersuite parameters field can be used to indicate 505 the decryption key with which the BEK can be recovered. Subsequent 506 CH security results will contain headers encrypted using the BEK if 507 non-payload headers are to be encrypted. 509 The payload is encrypted "in-place", that is, following encryption, 510 the payload header payload field contains ciphertext, not plaintext. 511 The payload header processing flags are unmodified.[Comment.3] 513 Payload super-encryption is allowed. If a CH ciphersuite supports 514 such super-encryption, then the ciphersuite MUST provide an 515 unambiguous way to do the decryption operations in the correct order 516 (e.g. by encoding the "layer" information as a ciphersuite 517 parameter). This "in-place" encryption of payload bytes is so as to 518 allow bundle payload fragmentation and re-assembly to operate without 519 knowledge of whether encryption has occurred. A side-effect of this 520 "in-place" encryption is that the payload will typically be expanded 521 by up-to a ciphertext blocksize if the bulk cipher is a block cipher. 522 Another is that the 2nd application of confidentiality does not 523 generally protect the parameters of the first which represent a 524 vulnerability in some circumstances. 526 A CH is an ASH with the following additional restrictions: 528 The header type code value MUST be 0x04. 530 The header processing control flags value can be set to whatever 531 values are required by local policy. 533 The ciphersuite ID MUST be documented as a confidentiality- 534 ciphersuite. 536 The correlator MUST be present if more than one related CH 537 instance is required. More than one CH instance might be required 538 if the payload is to be encrypted for more than one security- 539 destination so as to be robust in the face of routing 540 uncertainties. These multiple CH instances, however, would not be 541 related and would therefore not require correlators. On the other 542 hand, multiple related CH instances would be required if both the 543 payload and the PSH headers in the bundle were to be encrypted. 544 These multiple CH instances would require correlators to associate 545 them with each other. 547 The ciphersuite parameters field MAY be present 548 The security-source field MAY be present. 550 The security-destination field MAY be present (and typically will 551 be). 553 The security result MAY be present and normally represents an 554 encrypted bundle encryption key or encrypted versions of bundle 555 headers other than the payload header. 557 As was the case for the BAH and PSH, if the ciphersuite requires more 558 than one instance of the CH, then the first occurrence MUST contain 559 most of the optional fields, (e.g. security destination etc.) and 560 subsequent instances MUST NOT contain those same fields. Unlike the 561 case for the BAH and PSH, however, the security result field MAY (and 562 probably will) be included in multiple related CH instances. 564 Put another way: when a node is encrypting some (non-payload) 565 headers, it MUST first create a CH with the required ciphersuite ID, 566 parameters etc. as specified above. Typically, this CH will appear 567 "early" in the bundle. If this "first" CH doesn't contain all of the 568 ciphertext, then it may be followed by other (correlated) CH, which 569 MUST NOT repeat the ciphersuite or other information from the first 570 CH. 572 A CH ciphersuite may, or may not, specify which headers are to be 573 encrypted. If the ciphersuite doesn't specify this, then the node is 574 free to encrypt whichever headers it wishes. If a CH ciphersuite 575 does specify which headers are to be encrypted, then doing otherwise 576 is an error. 578 Since a single CH security result can contain the ciphertext for 579 multiple (non-payload) plaintext headers, the node simply catenates 580 these plaintext headers prior to encryption. After decryption the 581 recovered plaintext should then replace the CH in the bundle for 582 futher processing (e.g. PSH verification). This recovered plaintext 583 MUST contain all the appropriate header type, processing flags and 584 length information. In other words delete the CH in question and 585 place the recovered plaintext, which consists of additional (non- 586 payload) headers, in the bundle at the location from which the CH was 587 deleted. 589 Even if a to-be-encrypted header has the "discard" flag set, whether 590 or not the CH's "discard" flag is set is an implementation/policy 591 decision for the encrypting node. (The "discard" flag is more 592 properly called the "discard if header cannot be processed" 593 flag.)[Comment.4] 595 2.5. PSH and CH combinations 597 Given the above definitions, nodes are free to combine applications 598 of PSH and CH in any way they wish - the correlator value allows for 599 multiple applications of security services to be handled separately. 601 However, there are some clear security problems that could arise when 602 applying multiple services, for example, if we encrypted a payload 603 but left a PSH security result containing a signature in clear, this 604 would allow payload guesses to be confirmed. 606 We cannot, in general, prevent all such problems since we cannot 607 assume that every ciphersuite definition takes account of every other 608 ciphersuite definition. However, we can limit the potential for such 609 problems by requiring that any ciphersuite which applies to one 610 instance of a PSH or CH, must be applied to all instances with the 611 same correlator. 613 We now list the PSH and CH combinations which we envisage as being 614 useful to support: 616 Encrypted tunnels - a single bundle may be encrypted many times 617 en-route to its destination. Clearly it must be decrypted an 618 equal number of times, but we can imagine each encryption as 619 representing the entry into yet another layer of tunnel. This is 620 supported by using multiple instances of CH, but with the payload 621 encrypted multiple times, "in-place". 623 Multiple parallel authenticators - a single security source might 624 wish to integrity protect a bundle in multiple ways, in the hope 625 that one of them will be useful. This could be required if the 626 path the bundle will take is unpredictable, and if various nodes 627 might be involved as security destinations. Similarly, if the 628 security source cannot determine in advance which algorithms to 629 use, then using all might be reasonable. This would result in 630 uses of PSH which presumably all protect the payload, and which 631 cannot in general protect one another. Note that this logic can 632 also apply to a BAH, if the unpredictable routing happens in the 633 convergence layer, so we also envisage support for multiple 634 parallel uses of BAH. 636 Multiple sequential authenticators - if some security destination 637 requires assurance about the route that bundles have taken, then 638 it might insist on each forwarding node adding its own PSH. More 639 likely however would be that outbound "bastion" nodes would be 640 configured to sign bundles as a way of allowing the sending 641 "domain" to take accountability for the bundle. In this case, the 642 various PSH's will likely be layered, so that each protects the 643 earlier applications of PSH. 645 Authenticated and encrypted bundles - a single bundle may require 646 both authenticity and confidentiality. In this case, most 647 specifications first apply the authenticator and follow this by 648 encrypting the payload and authenticator. As noted previously in 649 the case where the authenticator is a signature, there are 650 security reasons for this ordering.[Comment.5] 652 There are no doubt other valid ways to combine PSH and CH instances, 653 but these are the "core" set we wish to support. Having said that, 654 as will be seen, the mandatory ciphersuites defined here are quite 655 specific and restrictive in terms of limiting the flexibility offered 656 by the correlator mechanism. This is primarily in order to keep this 657 specification as simple as possible, while at the same time 658 supporting the above scenarios. 660 3. Security Processing 662 This section describes the security aspects of bundle processing. 664 3.1. Nodes as policy enforcement points 666 All nodes are REQUIRED to have and enforce their own configurable 667 security policies, whether these policies be explicit or default, as 668 defined in Section 6. 670 All nodes serve as Policy Enforcement Points (PEP) insofar as they 671 enforce polices that may restrict the permissions of bundle nodes to 672 inject traffic into the network. If a particular transmission 673 request satisfies the node's policy and is therefore accepted, then 674 an outbound bundle can be created and dispatched. If not, then in 675 its role as a PEP, the node will not create or forward a bundle. 676 Error handling for such cases is currently considered out of scope of 677 this document.[Comment.6] 679 Policy enforcing code MAY override all other processing steps 680 described here and elsewhere in this document. For example, it is 681 valid to implement a node which always attempts to attach a PSH. 682 Similarly it is also valid to implement a node which always rejects 683 all requests which imply the use of a PSH. 685 Nodes MUST consult their security policy to determine the criteria 686 that a received bundle ought to meet before it will be forwarded. 687 These criteria MAY include a determination of whether or not the 688 received bundle must include valid BAH, PSH or CH. If the bundle 689 does not meet the node's policy criteria, then the bundle MUST be 690 discarded and processed no further; in this case, a bundle status 691 report indicating the failure MAY be generated, destined for the 692 forwarding node's own endpoint.[Comment.7] 694 The node's policy MAY call for the node to add or subtract some 695 security headers, for example, requiring the node attempt to encrypt 696 (parts of) the bundle for some security-destination, or requiring 697 that the node add a PSH. If the node's policy requires a BAH to be 698 added to the bundle, it MUST be added last so that the calculation of 699 its security result may take into consideration the values of all 700 other headers in the bundle. 702 3.2. Canonicalisation of bundles 704 In order to verify a signature or MAC on a bundle the exact same 705 bits, in the exact same order, must be input to the calculation upon 706 verification as were input upon initial computation of the original 707 signature or MAC value. Because bundles may be modified while in 708 transit (either correctly or due to implementation errors), a 709 canonical form of any given bundle (that contains a BAH or PSH) must 710 be defined. 712 This section defines two bundle canonicalisation algorithms which can 713 be used by various ciphersuites. [Comment.8] 715 3.2.1. Strict canonicalisation 717 The first algorithm which can be used basically permits no changes at 718 all to the bundle between when it is forwarded at the security-source 719 and when it is received at the security-destination and is mainly 720 intended for use in BAH ciphersuites. This algorithm simply involves 721 catenating all headers in the order presented, but omits all security 722 result fields which are present in headers of the ciphersuite type in 723 question - that is, when a BAH ciphersuite specifies this algorithm 724 then we omit all BAH security results, when a PSH ciphersuite 725 specifies this algorithm then we omit all PSH security results. 727 Notes: 729 - In the above we call for security results to be omitted, this 730 means that no bytes at all are input - we do not set the security 731 result length to zero or any equivalent. 733 - The 'res' bit of the ciphersuite ID which indicates that a 734 security value will be present is part of the canonical form. 736 -BAHs are always added to bundles after PSHs, so when a PSH 737 ciphersuite specifies this strict canonicalisation algorithm and 738 the PSH is received with a bundle that also includes one or more 739 BAHs, application of strict canonicalisation as part of the PSH 740 security result verification process requires that all BAHs in the 741 bundle be ignored entirely. 743 3.2.2. Mutable canonicalisation 745 This algorithm is mainly intended to protect parts of the bundle 746 which should not be changed in-transit, and hence it omits the 747 mutable parts of the bundle. 749 The basic approach is to define a canonical form for the primary 750 header, and catenate that with the security and payload headers in 751 the order that they will be transmitted. This algorithm ignores all 752 other headers on the basis that we cannot tell whether or not they 753 are liable to change as the bundle transits the network. 755 The canoncial form of the primary header is shown below. 757 Essentially, it de-references the dictionary header, adjusts lengths 758 where necessary and ignores flags that may change in transit. 760 +----------------+----------------+----------------+----------------+ 761 | Version | Proc. Flags | COS Flags | SRR Flags | 762 +----------------+----------------+---------------------------------+ 763 | Canonical primary header length | 764 +----------------+----------------+---------------------------------+ 765 | Destination endpoint ID length | 766 +----------------+----------------+---------------------------------+ 767 | | 768 | Destination endpoint ID | 769 | | 770 +----------------+----------------+---------------------------------+ 771 | Source endpoint ID length | 772 +----------------+----------------+----------------+----------------+ 773 | | 774 | Source endpoint ID | 775 | | 776 +----------------+----------------+---------------------------------+ 777 | Report-to endpoint ID length | 778 +----------------+----------------+----------------+----------------+ 779 | | 780 | Report-to endpoint ID | 781 | | 782 +----------------+----------------+----------------+----------------+ 783 | | 784 + Creation Timestamp (8 bytes) + 785 | | 786 +---------------------------------+---------------------------------+ 787 | Lifetime | 788 +----------------+----------------+----------------+----------------+ 789 | Fragment offset (optional) | 790 +----------------+----------------+---------------------------------+ 791 | Total application data unit length (optional) | 792 +----------------+----------------+---------------------------------+ 794 The canonical form of the primary bundle header. 796 Figure 4 798 The fields shown are: 800 Version, Processing Flags, COS, SRR - are all copied from the 801 first four bytes of the primary header and will contain the 802 version and the immutable flag values from the primary header. 803 Formed by copying the processing, COS and SRR flag fields from the 804 primary header and then subequently setting all of the mutable 805 bits to zero. This requires ANDing with the (four byte) value 806 0xFF1E031F so that the mutable and reserved bits are set to zero. 807 The only currently mutable bit masked out here is the "bundle is a 808 fragment" bit - all others are reserved bits. 810 There is an issue here which PSH ciphersuites MUST tackle. If a 811 bundle is fragmented before the PSH is applied then the PSH 812 applies to a fragment and not the entire bundle. However, the 813 protected fragment could be subsequently further fragmented, which 814 would leave the verifier unable to know which bytes were protected 815 by the PSH. For this reason, PSH ciphersuites which support 816 applying a PSH to fragments MUST specify which bytes of the bundle 817 payload are protected as part of the security parameters. When 818 verifying such a fragment only the bytes from the fragment are 819 input to the PSH verification. Of course, if is also valid for a 820 ciphersuite to be specified so as to only apply to entire bundles 821 and not to fragments. 823 Length - a four-byte value containing the length (in bytes) of 824 this structure.[Comment.9] 826 Destination endpoint ID length and value - are the length (as a 827 four byte value) and value of the destination endpoint ID from the 828 primary bundle header. The URI is simply copied from the relevant 829 part(s) of the dictionary header and is not itself canonicalised. 831 Source endpoint ID length and value are handled similarly to the 832 destination. 834 Report-to endpoint ID length and value are handled similarly to 835 the destination. 837 Creation time and Lifetime are simply copied from the primary 838 header. 840 Fragment offset and Total application data unit length are copied 841 from the primary header if they are present there (which is 842 controlled by one of the flags). 844 Payload headers are generally copied as-is, with the exception that 845 the processing flags value in the canonical version MUST be ANDed 846 with 0x17 to ensure that currently "reserved" bits are clear, but 847 that the "last header" flag is ignored. The reason to ignore the 848 "last header" flag is that if I create a bundle with both PSH and 849 BAH, then the next hop will remove BAH instances, and if one of those 850 was the last header, it may set the "last header" flag of e.g. a PSH 851 instance. The "last header" is therefore a mutable bit and should be 852 omitted from the canonical form. 854 Another exception occurs in cases where only a fragment of the 855 payload was protected, when only those bytes of the payload header 856 payload field are considered part of the canonical form. 858 Security headers are handled likewise, with the exception that the 859 ciphersuite will likely specify that the "current" security header 860 security result field not be considered part of the canonical form. 861 This differs from the case in strict canonicalisation since we might 862 use the mutable canonicalisation algorithm to handle sequential 863 signatures, where later signatures should cover earlier ones. 865 Notes: 867 - The canonical form of the bundle is not what is transmitted. It 868 is simply an artefact that is used as input to digesting. 870 - We omit the reserved flags on the basis that we cannot determine 871 whether or not they will change in transit. This means that this 872 algorithm may have to be revised if those flags are given a 873 definition and if we want to protect them. 875 - Our URI encoding does not preserve the "null-termination" 876 convention from the dictionary field, nor do we separate the 877 scheme and ssp as is done there. 879 - Note that the URI encoding above will be a cause for errors if 880 any node rewrites the dictionary for example changing the DNS part 881 of some HTTP URL from lower-case to upper case. Since there are 882 no exact general rules for canonicalising URIs (or even worse 883 IRIs), we simply have to live with this problem. 885 - All length fields here are four byte values in network byte 886 order. We do not need to optimise the encoding since the values 887 are never sent over the network. 889 3.3. Source confidentiality 891 Since every bundle MUST contain a primary header that cannot be 892 encrypted, and which contains the source endpoint ID (and others), if 893 we want to provide source confidentiality, then we have to invent a 894 fake primary header with false values for these fields and then a new 895 header type to contain the actual values. 897 Similarly, there may be confidentiality requirements applying to 898 other parts of the primary header (e.g. the current-custodian) and we 899 support these in the same way. 901 Since we don't know if we'll do this...details are TBD:-)[Comment.10] 903 3.4. Bundles received from other nodes 905 Nodes implementing this specification SHALL consult their security 906 policy to determine whether or not a received bundle is required by 907 policy to include a BAH. If the bundle is not required to have a 908 BAH, then BAH processing on the received bundle is complete and the 909 bundle is ready to be further processed for CH/PSH handling or 910 delivery or forwarding. 912 If the bundle is required to have a BAH but it does not, then the 913 bundle MUST be discarded and processed no further; in this case a 914 bundle status report indicating the authentication failure MAY be 915 generated, destined for the receiving node's own endpoint. 917 Otherwise, if the bundle does have a BAH, then the value in the 918 security result field of the BAH of the received bundle MUST be 919 verified according to the ciphersuite specification. If the check 920 fails for all BAHs in the bundle, the bundle has failed to 921 authenticate and the bundle SHALL be discarded and processed no 922 further; in this case, a bundle status report indicating the 923 authentication failure MAY be generated, destined for the 924 intermediate receiver's own endpoint. Otherwise, if any of the BAHs 925 present verify, the bundle is ready to have its CH processed (if it 926 includes one). 928 When forwarding a bundle that included some BAHs when it was 929 received, these BAHs MUST be stripped from the bundle. New BAHs MAY 930 be added as required by policy. This might require correcting the 931 "last header" field of the to-be-forwarded bundle. 933 If the bundle has a CH and the receiving node is the CH destination 934 for the bundle (either because the node is listed in the bundle's CH- 935 dest field or because the node is listed as the bundle's destination 936 and there is no CH-dest field), the node MUST decrypt the relevant 937 parts of the bundle according to the ciphersuite specification and 938 delete the CH in question. If the CH security result included the 939 ciphertext of anything other than an encrypted BEK that was used to 940 encrypt the bundle payload, the recovered plaintext headers MUST be 941 placed in the bundle at the location from which the CH was deleted. 943 If the bundle has a PSH and the receiving node is the PSH destination 944 for the bundle (either because the node is listed in the bundle's 945 PSH-dest field or because the node is listed as the bundle's 946 destination and there is no PSH-dest field), the node MUST verify the 947 value in the security result field of the PSH according to the 948 ciphersuite specification. If the check fails, the bundle has failed 949 to authenticate and the bundle SHALL be discarded and processed no 950 further; a bundle status report indicating the failure MAY be 951 generated, destined for the receiving node's own endpoint. 952 Otherwise, if the PSH verifies, the bundle is ready to be processed 953 for either delivery or forwarding. Before forwarding the bundle, the 954 node SHOULD remove the PSH from the bundle, unless there is the 955 likelihood that some downstream node will also be able to verify the 956 PSH. 958 If the bundle has a PSH and the receiving node is not the PSH-dest 959 for the bundle but the ciphersuite allows, the receiving node MAY, if 960 it is able, verify the value in the security result field. If the 961 check fails, the node SHALL discard the bundle and it MAY send a 962 bundle status report indicating the failure to the receiving node's 963 own endpoint. 965 3.5. The At-Most-Once-Delivery Option 967 An application may request (in some implementation specific manner) 968 that a node be registered as a member of an endpoint and that 969 received bundles destined for that endpoint be delivered to that 970 application. 972 We define a new option for use in such cases, known as "at-most-once- 973 delivery". If this option is chosen, then the application is 974 indicating that the node node SHALL check for replayed bundles, 975 discard duplicates, and deliver at most one copy of each received 976 bundle to the application. If this option is not chosen, the 977 application is indicating that node SHALL deliver all received bundle 978 copies to the application. If this option is not chosen, the node 979 MAY (subject to policy) deliver all bundles or else behave as if the 980 option had been chosen. 982 To enforce this the node MUST look at the (source, timestamp) pair 983 value of each complete (reassembled, if necessary) bundle received 984 and determine if this pair, which should uniquely identify a bundle, 985 has been received before. If it has, then the bundle is a duplicate. 986 If it has not, then the bundle is not a duplicate. The (source, 987 timestamp) pair SHALL be added to the list of pair values already 988 received by that node. 990 The duration for which a node maintains entries on such a list is an 991 implementation matter. 993 If any application has indicated that it wants a node to use the "at 994 most once" delivery option for a particular destination endpoint ID 995 that is in a bundle, then the node MUST compare the (source, 996 timestamp) pair values of the bundle with the local list of such 997 values of already-received bundles. 999 3.6. Bundle Fragmentation and Reassembly 1001 If it is necessary for a node to fragment a bundle and security is 1002 being used on that bundle, the following security-specific processing 1003 is REQUIRED: 1005 Firstly, a BAH, PSH or CH MUST NOT be fragmented. At this time, only 1006 the payload field of the payload header MAY be fragmented. 1008 If the bundle is required by the security policy to have a BAH before 1009 being forwarded, all fragments resulting from that bundle MUST 1010 contain individual BAH values. 1012 If the original bundle had a PSH, then each of the PSH instances MUST 1013 be included in some fragment. A single PSH instance MUST NOT be sent 1014 more than once. 1016 If the original bundle had a CH, then the each of the CH instances 1017 MUST be included in some fragment. A single CH instance MUST NOT be 1018 sent more than once. 1020 3.7. Reactive fragmentation 1022 When original bundle transmission is terminated before the entire 1023 bundle has been transmitted, the receiving node SHALL consult its 1024 security policy to determine whether it is permitted to transform the 1025 received portion of the bundle into a bundle fragment for further 1026 forwarding. Whether or not such reactive fragmentation is permitted 1027 SHALL be dependent on the security policy in combination with the 1028 ciphersuite used to calculate the BAH authentication information if 1029 required. 1031 In such cases, if the original bundle is fragmented by the 1032 intermediate receiver (reactively), and the BAH-ciphersuite is of an 1033 appropriate type (e.g. with multiple security results embedded in the 1034 payload), the bundle MUST be fragmented immediately after the last 1035 security result value in the partial payload that is received. Any 1036 data received after the last security result value MUST be dropped. 1038 If an original bundle transmission is terminated before the entire 1039 bundle has been transmitted, if the truncated bundle arriving at the 1040 intermediate receiver is reactively fragmented and forwarded, only 1041 the part of the bundle that was not received MUST be retransmitted. 1042 Before retransmitting this portion of the bundle, it SHALL be changed 1043 into a fragment and, if the original bundle included a BAH, the 1044 fragmented bundle MUST also, and its BAH SHALL be recalculated. 1046 This specification does not currently define any ciphersuite which 1047 can handle this reactive fragmentation case well. 1049 4. Mandatory Ciphersuites 1051 This section defines the mandatory ciphersuites for this 1052 specification. There is currently one mandatory ciphersuite for each 1053 of BAH, PSH and CH. The BAH ciphersuite is based on shared secrets 1054 using HMAC. The PSH ciphersuite is based on digital signatures using 1055 RSA with SHA256. The CH ciphersuite is based on using RSA for key 1056 transport and AES for bulk encryption. 1058 4.1. BAH-HMAC 1060 The BAH-HMAC ciphersuite has ciphersuite ID value 0x001. 1062 Security parameters are optional with this scheme, but if used then 1063 the value of the security parameter MUST be used as a key identifier. 1064 In the absence of a key identifier the intermediate receiver is 1065 expected to be able to find the correct key based on the sending 1066 identity (from the security-source and/or convergence layer). 1068 BAH-HMAC uses the strict canonicalisation algorithm in Section 3.2.1. 1070 The variant of HMAC to be used is HMAC-SHA1 as defined in RFC 2104 1071 [4].[Comment.11] 1073 This ciphersuite requires the use of two related instances of the 1074 BAH. It involves placing the first BAH instance (as defined in 1075 Section 2.2) just after the primary header. The second (correlated) 1076 instance of the BAH MUST be placed after all other headers (except 1077 possibly other BAH headers) in the bundle. 1079 This means that normally, the BAH will be the second and last headers 1080 of the bundle. If a forwarder wishes to apply more than one 1081 correlated BAH pair, then this can be done. There is no requirement 1082 that each application "wrap" the others, but the forwarder MUST 1083 insert all the "up front" BAHs, and their "at back" "partners" 1084 (without any security result), before canonicalising. 1086 Inserting more than one correlated BAH pair would be useful if the 1087 bundle could be routed to more than one potential "next-hop" or if 1088 both an old or a new key were valid at sending time, with no 1089 certainty about the situation that will obtain at reception time. 1091 The security result is the output of the HMAC-SHA1 calculation with 1092 input being the result of running the entire bundle through the 1093 strict canonicalisation algorithm. Both required BAH instances MUST 1094 be included in the bundle before canonicalisation. 1096 4.2. PSH-RSA-SHA256 1098 The PSH-RSA-SHA256 ciphersuite has ciphersuite ID value 0x002. 1100 If the bundle being signed has been fragemented before signing, then 1101 we have to specify which bytes were signed, in case the signed bundle 1102 is subequently fragmented for a second time. So, if the bundle is a 1103 fragment, then the security parameters MUST include two SDNV encoded 1104 numbers, representing the offset and length of the signed fragment. 1105 If the entire bundle is signed then these numbers MUST be omitted. 1107 The security parameters field MAY also contain a key identifier. The 1108 exact type of key identifier to be used is an implementation issue. 1109 In the absence of a key identifier the verifier of the PSH is 1110 expected to be able to use the security source (if supplied) or else 1111 the bundle source (if no security source is present) in order to 1112 determine the correct public key to use for PSH verification. 1114 PSH-RSA-SHA256 uses the mutable canonicalisation algorithm 1115 Section 3.2.2. The resulting canonical form of the bundle is the 1116 input to the signing process. This ciphersuite requires the use of a 1117 single instance of the PSH. 1119 RSA is used with SHA256 as specified for the sha256WithRSAEncryption 1120 PKCSv1.5 signature scheme in RFC 4055 [5]. The output of the signing 1121 process is the security result for the PSH. 1123 "Commensurate strength" cryptography is generally held to be a good 1124 idea. A combination of RSA with SHA256 is reckoned to require a 3076 1125 bit RSA key according to this logic. Few implementations will choose 1126 this length by default (and probably some just won't support such 1127 long keys). Since this is an experimental protocol, we expect that 1128 1024 or 2048 bit RSA keys will be used in many cases, and that that 1129 will be fine since we also expect that the hash function "issues" 1130 will be resolved before any standard would be derived from this 1131 protocol.[Comment.12] 1133 4.3. CH-RSA-AES-PAYLOAD-PSH 1134 [Comment.13] 1136 The CH-RSA-AES-PAYLOAD-PSH ciphersuite has cipersuite ID value 0x003. 1138 This scheme only allows for payload and PSH encryption and involves 1139 encrypting every instance of a PSH as well as the payload. 1141 This ciphersuite requires the use of a single CH instance if the 1142 bundle does not contain a PSH, and multiple CH instances if the 1143 bundle includes one or more PSHs. A first CH is created which 1144 contains the encrypted bundle encryption key (BEK). Thereafter each 1145 PSH and the payload bytes are encrypted using a key derived from the 1146 BEK. 1148 For the first CH, there MUST be a security parameter which contains a 1149 16 byte IV, optionally followed by a key identifier (whose format is 1150 again out of scope here). The security result contains the BEK 1151 encrypted using PKCSv1.5 rsaEncryption as specified in RFC 3370 [6]. 1153 For each subsequent PSH, the entire header is replaced by a CH that 1154 is correlated with the first CH and whose security result is the 1155 ciphertext form of the PSH, including the header type, etc. 1157 For the payload, only the bytes of the bundle payload field are 1158 affected, being replaced by ciphertext. 1160 Since we are separately encrypting the payload and all of the PSH 1161 headers present, we would like to use different keys for each 1162 encryption. We do this using a key derivation function (KDF) which 1163 takes a different input for each header (or part of the header, as in 1164 the case of payload encryption) that is to be encrypted. The input 1165 to the KDF is the BEK catenated with the following values: 1167 - The IV from the security parameter. [16 bytes] 1169 - The "header number" (counting the primary header as 1, the next 1170 as 2 etc regardless of the header type). [ 1 octet] 1172 - The header type. [1 octet] 1174 - If the header is a PSH (i.e., if it is not the Bundle Payload 1175 Header), then the correlator field value. [SDNV] 1177 Note: Identifying the right KDF here is stil TBD. Plan is to see 1178 what happens with the recent NIST KDF paper (which is in conflict 1179 with KDF's used in various Internet protocols). Expect change. 1181 The output from the KDF is called the result encryption key (REK) and 1182 is used to encrypt the payload or PSH bytes. 1184 The REK uses the AES algorithm in CBC mode as specified by the id- 1185 aes-cbc object identifier in RFC 3565 [7] [Comment.14][Comment.15] 1187 5. Key Management 1189 Since key management in delay tolerant networks is still a research 1190 topic we cannot provide much in the way of useful key management 1191 here. However, solely in order to support implementation and 1192 testing, implementations SHOULD support: 1194 - Long-term pre-shared-symmetric keys for the BAH-HMAC 1195 ciphersuite. 1197 - The use of well-known RSA public keys for PSH-RSA-SHA256 and CH- 1198 RSA-AES-PAYLOAD-PSH ciphersuites. 1200 Since endpoint IDs are URIs and URIs can be placed in X.509 [8] 1201 public key certificates (in the subjectAltName extension) 1202 implementations SHOULD support this way of distributing public keys. 1203 Implementations SHOULD NOT be very strict in how they process X.509 1204 though, for example, it would probably not be correct to insist on 1205 Certificate Revocation List (CRL) checking in many DTN contexts. 1207 Other than that, key management is for future study. 1209 6. Default Security Policy 1211 Every node serves as a Policy Enforcement Point (PEP) insofar as it 1212 enforces some policy that controls the forwarding and delivery of 1213 bundles via one or more convergence layer protocol implementation. 1214 Consequently, every node SHALL have and operate according to its own 1215 configurable security policy, whether the policy be explicit or 1216 default. The policy SHALL specify: 1218 Under what conditions received bundles SHALL be forwarded. 1220 Under what conditions received bundles SHALL be required to 1221 include valid BAHs. 1223 Under what conditions the authentication information provided in a 1224 bundle's BAH SHALL be deemed adequate to authenticate the bundle. 1226 Under what conditions received bundles SHALL be required to have 1227 valid PSHs and/or CHs. 1229 Under what conditions the authentication information provided in a 1230 bundle's PSH SHALL be deemed adequate to authenticate the bundle. 1232 Under what conditions a BAH SHALL be added to a received bundle 1233 before that bundle is forwarded. 1235 Under what conditions a PSH SHALL be added to a received bundle 1236 before that bundle is forwarded. 1238 Under what conditions a CH SHALL be added to a received bundle 1239 before that bundle is forwarded. 1241 The actions that SHALL be taken in the event that a received 1242 bundle does not meet the receiving node's security policy 1243 criteria. 1245 This specification does not address how security policies get 1246 distributed to nodes. It only REQUIRES that nodes have and enforce 1247 security policies. [Comment.16] 1249 If no security policy is specified at a given node, or if a security 1250 policy is only partially specified, that node's default policy 1251 regarding unspecified criteria SHALL consist of the following: 1253 Bundles that are not well-formed do not meet the security policy 1254 criteria. 1256 The mandatory ciphersuites MUST be used. 1258 All bundles received MUST have a BAH which MUST be verified to 1259 contain a valid security result. If the bundle does not have a 1260 BAH, then the bundle MUST be discarded and processed no further; a 1261 bundle status report indicating the authentication failure MAY be 1262 generated, destined for the receiving node's own endpoint. 1264 No received bundles SHALL be required to have a PSH; if a received 1265 bundle does have a PSH, however, the PSH can be ignored unless the 1266 receiving node is the PSH-dest, in which case the PSH MUST be 1267 verified. 1269 No received bundles SHALL be required to have a CH; if a received 1270 bundle does have a CH, however, the CH can be ignored unless the 1271 receiving node is the CH-dest, in which case the CH MUST be 1272 processed. If processing of a CH yields a PSH, that PSH SHALL be 1273 processed by the node according to the node's security policy. 1275 A PSH SHALL NOT be added to a bundle before sourcing or forwarding 1276 it. 1278 A CH SHALL NOT be added to a bundle before sourcing or forwarding 1279 it. 1281 A BAH MUST always be added to a bundle before that bundle is 1282 forwarded. 1284 If a received bundle does not satisfy the node's security policy 1285 for any reason, then the bundle MUST be discarded and processed no 1286 further; in this case, a bundle status report indicating the 1287 failure SHOULD be generated, destined for the receiving node's own 1288 endpoint. 1290 7. Security Considerations 1291 [Comment.17] 1293 If a BAH ciphersuite uses digital signatures but doesn't include the 1294 security destination (which for a BAH is the next host), then this 1295 allows the bundle to be sent to some node other than the intended 1296 adjacent node. Because the BAH will still authenticate, the 1297 receiving node may erronously accept and forward the bundle. When 1298 asymmetric BAH ciphersuites are used, the security destination field 1299 SHOULD therefore be included in the BAH. 1301 If a bundle's PSH-dest is not the same as its destination, then some 1302 node other than the destination (the node identified as the PSH-dest) 1303 is expected to validate the PSH security result while the bundle is 1304 en route. However, if for some reason the PSH is not validated, 1305 there is no way for the destination to become aware of this. 1306 Typically, a PSH-dest will remove the PSH from the bundle after 1307 verifying the PSH and before forwarding it. However, if there is a 1308 possibility that the PSH will also be verified at a downstream node, 1309 the PSH-dest will leave the PSH in the bundle. Therefore, if a 1310 destination receives a bundle with a PSH that has a PSH-dest (which 1311 isn't the destination), this may, but does not necessarily, indicate 1312 a possible problem. 1314 If a bundle is fragmented after being forwarded by its PSH-source but 1315 before being received by its PSH-dest, the payload in the bundle MUST 1316 be reassembled before validating the PSH security result in order for 1317 the security result to validate correctly. Therefore, if the PSH- 1318 dest is not capable of performing payload reassembly, its utility as 1319 a PSH-dest will be limited to validating only those bundles that have 1320 not been fragmented since being forwarded from the PSH-source. 1321 Similarly, if a bundle is fragmented after being forwarded by its 1322 PSH-source but before being received by its PSH-dest, all fragments 1323 MUST be received at that PSH-dest in order for the bundle payload to 1324 be able to be reassembled. If not all fragments are received at the 1325 PSH-dest node, the bundle will not be able to be authenticated, and 1326 will therefore never be forwarded by this PSH-dest node. 1328 8. IANA Considerations 1330 None at this time. If the bundle protocol becomes a standards track 1331 protocol, then we may want to consider having IANA establish a 1332 register of header types, and in particular for this specification a 1333 separate register of ciphersuite specifications. 1335 9. References 1337 9.1. Normative References 1339 [1] Bradner, S. and J. Reynolds, "Key words for use in RFCs to 1340 Indicate Requirement Levels", RFC 2119, October 1997. 1342 [2] Scott, K., "Bundle Protocol Specification", 1343 draft-irtf-dtnrg-bundle-spec-04.txt , December 2005. 1345 [3] Cerf, V., "Delay-Tolerant Network Architecture", 1346 draft-irtf-dtnrg-arch-04.txt , December 2005, 1347 . 1349 [4] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 1350 for Message Authentication", RFC 2104, February 1997. 1352 [5] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms 1353 and Identifiers for RSA Cryptography for use in the Internet 1354 X.509 Public Key Infrastructure Certificate and Certificate 1355 Revocation List (CRL) Profile", RFC 4055, June 2005. 1357 [6] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", 1358 RFC 3370, August 2002. 1360 [7] Schaad, J., "Use of the Advanced Encryption Standard (AES) 1361 Encryption Algorithm in Cryptographic Message Syntax (CMS)", 1362 RFC 3565, July 2003. 1364 [8] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 1365 Public Key Infrastructure Certificate and Certificate Revocation 1366 List (CRL) Profile", RFC 3280, April 2002. 1368 9.2. Informative References 1370 [9] Farrell, S., Symington, S., and H. Weiss, "Delay-Tolerant 1371 Network Security Overview", 1372 draft-irtf-dtnrg-sec-overview-01.txt , March 2006. 1374 Editorial Comments 1376 [Comment.1] Editors: There may be some (valid) question marks over 1377 this terminology. We weren't entirely sure ourselves. 1379 [Comment.2] Stephen: I guess there could be some weird corner case 1380 where a CH ciphersuite using counter-mode would allow 1381 fragments to be individually decrypted, and in that 1382 case, we might want to set replication for each 1383 fragment. So we can't fully rule out setting that flag 1384 for all PSH/CH. 1386 [Comment.3] Stephen: This to be revisited! 1388 [Comment.4] Howie: It may be nice to be able to signal both 1389 confidentiality and authentication using only one 1390 header instead of using two separate headers (PSH and 1391 CH). 1393 [Comment.5] Add approppriate forward references to ciphersuites 1394 defined later. 1396 [Comment.6] Stephen: Do we need to specify error handling for the 1397 case where a node drops a bundle for policy reasons? 1398 Does/can it signal back to the source that its done so? 1399 I dunno. 1401 [Comment.7] Howie: The security policy database will need to be 1402 discussed somewhere. Does it belong in this document, 1403 the bundle protocol spec., both, some other document? 1405 [Comment.8] Stephen: This is a fairly big new section and so 1406 probably contains errors! 1408 [Comment.9] Editors: Check that mask value at the very last moment 1409 (incl. during auth-48) to be sure its (still) correct. 1411 [Comment.10] Stephen: Should we support source confidentiality? 1412 Might complicate PSH which is the downside IMO. 1414 [Comment.11] Editors: At the moment there appears to be no security 1415 reason to move away from HMAC-SHA1 since the HMAC 1416 construct is not as far as we know affected by 1417 collisions in the underlying digest algorithm (which 1418 are nearly practically computable for SHA-1). 1419 Nevertheless, since we use SHA-256 in the signature 1420 ciphersuite (since collisions do matter there), it may 1421 be desirable to move to HMAC-SHA-256 as specified in 1422 RFC 4321. So if you're writing code based on this...be 1423 warned! 1425 [Comment.12] Editors: There are currently unresolved "issues" with 1426 digest algorithms which might cause a change here 1427 prior to, but more likely, after, an RFC has issued. So 1428 expect change! 1430 [Comment.13] Editors: This entire section is to be treated as a 1431 strawman for the present. 1433 [Comment.14] Speculation: There would be an interesting possibility 1434 opened up were we to use a stream cipher with the REK. 1435 That is that we could then encrypt and decrypt 1436 independently - Alice could encrypt for Bob, then 1437 Charlie could encrypt for Dessie, then Bob could 1438 decrypt, then Dessie. Better in terms of not adding 1439 padding but worse in that it trivially allows known 1440 plaintext manipulation if there's no PSH. 1442 [Comment.15] Editors: Another option might also be to switch to 1443 using counter mode rather than CBC which would have the 1444 benefit of allowing some fragments to be decrypted even 1445 if not all fragments arrive. While that seems nice 1446 enough to do, it would of course require us to think 1447 more about fragments and so is for the next version if 1448 at all. 1450 [Comment.16] Howie: Eventually we will need to state where the 1451 security policy information/DB does get discussed/ 1452 specified. 1454 [Comment.17] Editors: Much more text is needed here no doubt. 1456 Authors' Addresses 1458 Susan Flynn Symington 1459 The MITRE Corporation 1460 7515 Colshire Drive 1461 McLean, VA 22102 1462 US 1464 Phone: +1 (703) 983-7209 1465 Email: susan@mitre.org 1466 URI: http://mitre.org/ 1468 Stephen Farrell 1469 Trinity College Dublin 1470 Distributed Systems Group 1471 Department of Computer Science 1472 Trinity College 1473 Dublin 2 1474 Ireland 1476 Phone: +353-1-608-1539 1477 Email: stephen.farrell@cs.tcd.ie 1479 Howard Weiss 1480 SPARTA, Inc. 1481 7075 Samuel Morse Drive 1482 Columbia, MD 21046 1483 US 1485 Phone: +1-410-872-1515 x201 1486 Email: hsw@sparta.com 1488 Intellectual Property Statement 1490 The IETF takes no position regarding the validity or scope of any 1491 Intellectual Property Rights or other rights that might be claimed to 1492 pertain to the implementation or use of the technology described in 1493 this document or the extent to which any license under such rights 1494 might or might not be available; nor does it represent that it has 1495 made any independent effort to identify any such rights. Information 1496 on the procedures with respect to rights in RFC documents can be 1497 found in BCP 78 and BCP 79. 1499 Copies of IPR disclosures made to the IETF Secretariat and any 1500 assurances of licenses to be made available, or the result of an 1501 attempt made to obtain a general license or permission for the use of 1502 such proprietary rights by implementers or users of this 1503 specification can be obtained from the IETF on-line IPR repository at 1504 http://www.ietf.org/ipr. 1506 The IETF invites any interested party to bring to its attention any 1507 copyrights, patents or patent applications, or other proprietary 1508 rights that may cover technology that may be required to implement 1509 this standard. Please address the information to the IETF at 1510 ietf-ipr@ietf.org. 1512 Disclaimer of Validity 1514 This document and the information contained herein are provided on an 1515 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1516 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1517 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1518 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1519 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1520 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1522 Copyright Statement 1524 Copyright (C) The Internet Society (2006). This document is subject 1525 to the rights, licenses and restrictions contained in BCP 78, and 1526 except as set forth therein, the authors retain all their rights. 1528 Acknowledgment 1530 Funding for the RFC Editor function is currently provided by the 1531 Internet Society.