idnits 2.17.1 draft-irtf-dtnrg-bundle-security-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2009) is 5521 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: 'RFC4106' is defined on line 2311, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 5050 (ref. 'DTNBP') == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-bundle-metadata-block-00 ** Downref: Normative reference to an Experimental draft: draft-irtf-dtnrg-bundle-metadata-block (ref. 'DTNMD') ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) -- No information found for draft-irtf-dtnrg-bundle-retrans - is the name correct? == Outdated reference: A later version (-06) exists of draft-irtf-dtnrg-sec-overview-04 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DTN Research Group S.F. Symington 3 Internet-Draft The MITRE Corporation 4 Expires: September 9, 2009 S. Farrell 5 Trinity College Dublin 6 H. Weiss 7 P. Lovell 8 SPARTA, Inc. 9 March 8, 2009 11 Bundle Security Protocol Specification 12 draft-irtf-dtnrg-bundle-security-07 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 9, 2009. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Abstract 63 This document defines the bundle security protocol, which provides 64 data integrity and confidentiality services. We also describe 65 various bundle security considerations including policy options. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.1. Related Documents . . . . . . . . . . . . . . . . . . . . 4 71 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 72 2. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 8 73 2.1. Abstract Security Block . . . . . . . . . . . . . . . . . 9 74 2.2. Bundle Authentication Block . . . . . . . . . . . . . . . 13 75 2.3. Payload Integrity Block . . . . . . . . . . . . . . . . . 14 76 2.4. Payload Confidentiality Block . . . . . . . . . . . . . . 15 77 2.5. Extension Security Block . . . . . . . . . . . . . . . . . 18 78 2.6. Parameters and Result Fields . . . . . . . . . . . . . . . 20 79 2.7. Key Transport . . . . . . . . . . . . . . . . . . . . . . 22 80 2.8. PIB and PCB combinations . . . . . . . . . . . . . . . . . 22 81 3. Security Processing . . . . . . . . . . . . . . . . . . . . . 25 82 3.1. Nodes as policy enforcement points . . . . . . . . . . . . 25 83 3.2. Processing order of security blocks . . . . . . . . . . . 25 84 3.3. Security Zones . . . . . . . . . . . . . . . . . . . . . . 28 85 3.4. Canonicalisation of bundles . . . . . . . . . . . . . . . 30 86 3.5. Endpoint ID confidentiality . . . . . . . . . . . . . . . 35 87 3.6. Bundles received from other nodes . . . . . . . . . . . . 36 88 3.7. The At-Most-Once-Delivery Option . . . . . . . . . . . . . 37 89 3.8. Bundle Fragmentation and Reassembly . . . . . . . . . . . 38 90 3.9. Reactive fragmentation . . . . . . . . . . . . . . . . . . 39 91 4. Mandatory Ciphersuites . . . . . . . . . . . . . . . . . . . . 40 92 4.1. BAB-HMAC . . . . . . . . . . . . . . . . . . . . . . . . . 40 93 4.2. PIB-RSA-SHA256 . . . . . . . . . . . . . . . . . . . . . . 41 94 4.3. PCB-RSA-AES128-PAYLOAD-PIB-PCB . . . . . . . . . . . . . . 42 95 4.4. ESB-RSA-AES128-EXT . . . . . . . . . . . . . . . . . . . . 45 96 5. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 49 97 6. Default Security Policy . . . . . . . . . . . . . . . . . . . 50 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 52 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 101 9.1. Normative References . . . . . . . . . . . . . . . . . . . 54 102 9.2. Informative References . . . . . . . . . . . . . . . . . . 54 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 105 1. Introduction 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 This document defines security features for the bundle protocol 112 [DTNBP] intended for use in delay tolerant networks, in order to 113 provide the DTN security services as described in the DTN Security 114 Overview and Motivations document [DTNsecOver]. 116 The bundle protocol is used in DTNs which overlay multiple networks, 117 some of which may be challenged by limitations such as intermittent 118 and possibly unpredictable loss of connectivity, long or variable 119 delay, asymmetric data rates, and high error rates. The purpose of 120 the bundle protocol is to support interoperability across such 121 stressed networks. The bundle protocol is layered on top of 122 underlay-network-specific convergence layers, on top of network- 123 specific lower layers, to enable an application in one network to 124 communicate with an application in another network, both of which are 125 spanned by the DTN. 127 Security will be important for the bundle protocol. The stressed 128 environment of the underlying networks over which the bundle protocol 129 will operate makes it important that the DTN be protected from 130 unauthorized use, and this stressed environment poses unique 131 challenges on the mechanisms needed to secure the bundle protocol. 132 Furthermore, DTNs may very likely be deployed in environments where a 133 portion of the network might become compromised, posing the usual 134 security challenges related to confidentiality, integrity and 135 availability. 137 Separate security processing applies to the payload block and to the 138 various extension blocks that may accompany it in a bundle, as 139 varying security requirements may apply to them. 141 1.1. Related Documents 143 This document is best read and understood within the context of the 144 following other DTN documents: 146 The Delay-Tolerant Network Architecture [DTNarch] defines the 147 architecture for delay-tolerant networks, but does not discuss 148 security at any length. 150 The DTN Bundle Protocol [DTNBP] defines the format and processing 151 of the blocks used to implement the bundle protocol, excluding the 152 security-specific blocks defined here. 154 The Delay-Tolerant Networking Security Overview [DTNsecOver] 155 provides an informative overview and high-level description of DTN 156 security. 158 1.2. Terminology 160 We introduce the following terminology for purposes of clarity: 162 source - the bundle node from which a bundle originates 164 destination - the bundle node to which a bundle is ultimately 165 destined 167 forwarder - the bundle node that forwarded the bundle on its most 168 recent hop 170 intermediate receiver or "next hop" - the neighboring bundle node 171 to which a forwarder forwards a bundle. 173 In the figure below, which is adapted from figure 1 in the Bundle 174 Protocol Specification, four bundle nodes (denoted BN1, BN2, BN3, and 175 BN4) reside above some transport layer(s). Three distinct transport 176 and network protocols (denoted T1/N1, T2/N2, and T3/N3) are also 177 shown. 179 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 180 | BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 | 181 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 182 | T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 | 183 +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ 184 | N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 | 185 +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ 186 | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | 187 +-----------+ +------------+ +-------------+ +-----------+ 188 | | | | 189 |<-- An Internet --->| |<--- An Internet --->| 190 | | | | 192 BN = "Bundle Node" (as defined in the Bundle Protocol Specification 194 Bundle Nodes Sit at the Application layer of the Internet Model. 196 Figure 1 198 Bundle node BN1 originates a bundle that it forwards to BN2. BN2 199 forwards the bundle to BN3, and BN3 forwards the bundle to BN4. BN1 200 is the source of the bundle and BN4 is the destination of the bundle. 201 BN1 is the first forwarder, and BN2 is the first intermediate 202 receiver; BN2 then becomes the forwarder, and BN3 the intermediate 203 receiver; BN3 then becomes the last forwarder, and BN4 the last 204 intermediate receiver, as well as the destination. 206 If node BN2 originates a bundle (for example, a bundle status report 207 or a custodial signal), which is then forwarded on to BN3, and then 208 to BN4, then BN2 is the source of the bundle (as well as being the 209 first forwarder of the bundle) and BN4 is the destination of the 210 bundle (as well as being the final intermediate receiver). 212 We introduce the following security-specific DTN terminology: 214 security-source - a bundle node that adds a security block to a 215 bundle 217 security-destination - a bundle node that processes a security 218 block of a bundle 220 security zone - that part of the network path from the security- 221 source to the security-destination 223 Referring to Figure 1 again: 225 If the bundle that originates at BN1 as source is given a security 226 block by BN1, then BN1 is the security-source of this bundle with 227 respect to that security block, as well as being the source of the 228 bundle. 230 If the bundle that originates at BN1 as source is given a security 231 block by BN2, then BN2 is the security-source of this bundle with 232 respect to that security block, even though BN1 is the source. 234 If the bundle that originates at BN1 as source is given a security 235 block by BN1 that is intended to be processed by BN3, then BN1 is the 236 security-source and BN3 is the security destination with respect to 237 this security block. The security zone for this block is BN1 to BN3. 239 A bundle may have multiple security blocks. The security-source of a 240 bundle with respect to a given security block in the bundle may be 241 the same as or different from the security-source of the bundle with 242 respect to a different security block in the bundle. Similarly, the 243 security-destination of a bundle with respect to each of that 244 bundle's security blocks may be the same or different. Therefore the 245 security zones for various blocks may be and often will be different. 247 If the bundle that originates at BN1 as source is given a security 248 block by BN1 that is intended to be processed by BN3, and BN2 adds a 249 security block with security-destination BN4, the security zones for 250 the two blocks overlap but not completely. This problem is discussed 251 further in Section 3.3. 253 Forwarding nodes MUST transmit blocks in the same order as they were 254 received. This requirement applies to all dtn nodes, not just ones 255 which implement security processing. Blocks in a bundle may be added 256 or deleted according to the applicable specification, but those 257 blocks which are both received and transmitted MUST be transmitted in 258 the same order that they were received. 260 The block sequence also indicates the order in which certain 261 significant actions have affected the bundle, and therefore the 262 sequence in which actions must occur in order to produce the bundle 263 at its destination. 265 2. Security Blocks 267 There are four types of security block that MAY be included in a 268 bundle. These are the Bundle Authentication Block (BAB), the Payload 269 Integrity Block (PIB), the Payload Confidentiality Block (PCB) and 270 the Extension Security Block (ESB). 272 The BAB is used to assure the authenticity and integrity of the 273 bundle along a single hop from forwarder to intermediate receiver. 275 The PIB is used to assure the authenticity and integrity of the 276 payload from the PIB security-source, which creates the PIB, to 277 the PIB security-destination, which verifies the PIB 278 authenticator. The authentication information in the PIB may (if 279 the ciphersuite allows) be verified by any node inbetween the PIB 280 security-source and the PIB security-destination that has access 281 to the cryptographic keys and revocation status information 282 required to do so. 284 Since a BAB protects a bundle on a "hop-by-hop" basis and a PIB 285 protects on a (sort of) "end-to-end" basis, whenever both are 286 present the BAB MUST form the "outer" layer of protection - that 287 is, the BAB MUST always be calculated and added to the bundle 288 after the PIB has been calculated and added to the bundle. 290 The PCB indicates that the payload has been encrypted, in whole or 291 in part, at the PCB security-source in order to protect the bundle 292 content while in transit to the PCB security-destination. 294 The ESB provides security for non-payload blocks in a bundle, such 295 as metadata. PIB and PCB protect the payload and are regarded as 296 "part of" the payload rather than being "non-payload" blocks. ESB 297 therefore is not applied to PIB or PSBs. 299 Each of the security blocks uses the Canonical Bundle Block Format as 300 defined in the Bundle Protocol Specification. That is, each security 301 block is comprised of the following elements: 303 - Block type code 305 - Block processing control flags 307 - Block EID reference list (optional) 309 - Block data length 311 - Block-type-specific data fields 313 Since the four security blocks have most fields in common, we can 314 shorten the description of the Block-type-specific data fields of 315 each security block if we first define an abstract security block 316 (ASB) and then specify each of the real blocks in terms of the fields 317 which are present/absent in an ASB. Note that no bundle ever 318 contains an actual ASB, which is simply a specification artifact. 320 2.1. Abstract Security Block 322 An ASB consists of the following mandatory and optional fields: 324 - Block-type code (one byte) - as in all bundle protocol blocks 325 except the primary bundle block. The block types codes for the 326 security blocks are: 328 BundleAuthentication Block - BAB: 0x02 330 PayloadIntegrity Block - PIB: 0x03 332 PayloadConfidentiality Block - PCB: 0x04 334 Extension Security Block - ESB: 0x09 336 - Block processing control flags (SDNV) - defined as in all bundle 337 protocol blocks except the primary bundle block (as described in 338 the Bundle Protocol [DTNBP]). SDNV encoding is described in the 339 bundle protocol. There are no general constraints on the use of 340 the block processing flags, and some specific requirements are 341 discussed later. 343 - EID references - composite field defined in [DTNBP] containing 344 references to one or two EIDs. Presence of the EID-reference 345 field is indicated by the setting of the "block contains an EID- 346 reference field" (EID_REF) bit of the block processing control 347 flags. If one or more references is present, flags in the 348 ciphersuite ID field, described below, specify which. 350 If no EID fields are present then the composite field itself is 351 omitted entirely, rather than containing a count field of zero, 352 since such a representation is not permitted. The EID_REF bit is 353 not set. 355 The possible EIDs are:- 357 - (optional) Security-source - specifies the security source 358 for the service. If this is omitted, then the source of the 359 bundle is assumed to be the security-source. 361 - (optional) Security-destination - specifies the security 362 destination for the service. If this is omitted, then the 363 destination of the bundle is assumed to be the security- 364 destination. 366 If two EIDs are present, security-source is first and security- 367 destination comes second. 369 - Block data length (SDNV) - as in all bundle protocol blocks 370 except the primary bundle block. SDNV encoding is described in 371 the bundle protocol. 373 - Block-type-specific data fields as follows: 375 - Ciphersuite ID (SDNV) 377 - Ciphersuite flags (SDNV) 379 - (optional) Correlator - when more than one related block is 380 inserted then this field MUST have the same value in each 381 related block instance. This is encoded as an SDNV. See note 382 in Section 3.8 with regard to correlator values in bundle 383 fragments. 385 - (optional) Ciphersuite parameters - compound field of next 386 two items 388 - Ciphersuite parameters length - specifies the length of 389 the following Ciphersuite parameters data field and is 390 encoded as an SDNV. 392 - Ciphersuite parameters data - parameters to be used with 393 the ciphersuite in use, e.g. a key identifier or 394 initialization vector (IV). See Section 2.6 for a list of 395 potential parameters and their encoding rules. The 396 particular set of parameters that are included in this field 397 are defined as part of the ciphersuite specification. 399 - (optional) Security result - compound field of next two items 401 - Security result length - contains the length of the next 402 field and is encoded as an SDNV. 404 - Security result data - contains the results of the 405 appropriate ciphersuite-specific calculation (e.g. a 406 signature, MAC or ciphertext block key). 408 +----------------+----------------+----------------+----------------+ 409 | type | flags (SDNV) | EID ref list(comp) | 410 +----------------+----------------+----------------+----------------+ 411 | length (SDNV) | ciphersuite (SDNV) | 412 +----------------+----------------+----------------+----------------+ 413 | ciphersuite flags (SDNV) | correlator (SDNV) | 414 +----------------+----------------+----------------+----------------+ 415 |params len(SDNV)| ciphersuite params data | 416 +----------------+----------------+----------------+----------------+ 417 |res-len (SDNV) | security result data | 418 +----------------+----------------+----------------+----------------+ 420 The structure of an abstract security block 422 Figure 2 424 Some ciphersuites are specified in Section 4, which also specifies 425 the rules which MUST be satisfied by ciphersuite specifications. 426 Additional ciphersuites MAY be defined in separate specifications. 427 Ciphersuite IDs not specified are reserved. Implementations of the 428 bundle security protocol decide which ciphersuites to support, 429 subject to the requirements of section Section 4. It is RECOMMENDED 430 that implementations that allow additional ciphersuites permit 431 ciphersuite ID values at least up to and including 127, and they MAY 432 decline to allow larger ID values. 434 The structure of the ciphersuite flags field is shown in Figure 3. 435 In each case the presence of an optional field is indicated by 436 setting the value of the corresponding flag to one. A value of zero 437 indicates the corresponding optional field is missing. Presently 438 there are five flags defined for the field and for convenience these 439 are shown as they would be extracted from a single-byte SDNV. Future 440 additions may cause the field to grow to the left so, as with the 441 flags fields defined in [DTNBP], the description below numbers the 442 bit positions from the right rather than the standard RFC definition 443 which numbers bits from the left. 445 src - bit 4 indicates whether the EID-reference field of the ASB 446 contains the optional reference to the security-source. 448 dest - bit 3 indicates whether the EID-reference field of the ASB 449 contains the optional reference to the security-destination. 451 parm - bit 2 indicates whether the ciphersuite-parameters-length 452 and ciphersuite parameters data fields are present or not. 454 corr - bit 1 indicates whether or not the ASB contains an optional 455 correlator. 457 res - bit 0 indicates whether or not the ASB contains the security 458 result length and security result data fields. 460 bits 5-6 are reserved for future use. 462 Ciphersuite flags 463 Bit Bit Bit Bit Bit Bit Bit 464 6 5 4 3 2 1 0 465 +-----+-----+-----+-----+-----+-----+-----+ 466 | reserved |src |dest |parm |corr |res | 467 +-----+-----+-----+-----+-----+-----+-----+ 469 Figure 3 471 A little bit more terminology: if the block is a PIB then when we 472 refer to the "PIB-source", we mean the security source for the PIB as 473 represented by the EID reference in the EID-references field. 474 Similarly we may refer to the PCB-dest, meaning the security- 475 destination of the PCB, again as represented by an EID reference. 476 For example, referring to Figure 1 again, if the bundle that 477 originates at BN1 as source is given a Confidentiality Block (PCB) by 478 BN1 that is protected using a key held by BN3 and it is given a 479 Payload Integrity Block (PIB) by BN1, then BN1 is both the PCB-source 480 and the PIB-source of the bundle, and BN3 is the PCB-dest of the 481 bundle. 483 The correlator field is used to associate several related instances 484 of a security block. This can be used to place a BAB that contains 485 the ciphersuite information at the "front" of a (probably large) 486 bundle, and another correlated BAB that contains the security result 487 at the "end" of the bundle. This allows even very memory-constrained 488 nodes to be able to process the bundle and verify the BAB. There are 489 similar use cases for multiple related instances of PIB and PCB as 490 will be seen below. 492 The ciphersuite specification MUST make it clear whether or not 493 multiple block instances are allowed, and if so, under what 494 conditions. Some ciphersuites can of course leave flexibility to the 495 implementation, whereas others might mandate a fixed number of 496 instances. 498 For convenience, we use the term "first block" to refer to the 499 initial block in a group of correlated blocks, or to the single block 500 if there are no others in the set. Obviously there can be several 501 unrelated groups in a bundle, each containing only one block or more 502 than one, and each has its own "first block". 504 2.2. Bundle Authentication Block 506 In this section we describe typical BAB field values for two 507 scenarios - where a single instance of the BAB contains all the 508 information and where two related instances are used, one "up front" 509 which contains the ciphersuite and another following the payload 510 which contains the security result (e.g. a MAC). 512 For the case where a single BAB is used: 514 The block-type code field value MUST be 0x02. 516 The block processing control flags value can be set to whatever 517 values are required by local policy. 519 The ciphersuite ID MUST be documented as a hop-by-hop 520 authentication-ciphersuite which requires one instance of the BAB. 522 The correlator field MUST NOT be present. 524 The ciphersuite parameters field MAY be present, if so specified 525 in the ciphersuite specification. 527 An EID reference to the security-source SHOULD be present and, if 528 so, it MUST identify the forwarder of the bundle. (If the 529 forwarding node is identified in another block of the bundle that 530 the next hop supports, e.g., the Previous Hop Insertion Block, the 531 forwarding node need not be identified in the BAB. Similarly, if 532 the forwarding node is known through other implementation-specific 533 means, such as from the convergence layer, an EID reference need 534 not be included.) 536 An EID reference to the security-destination SHOULD NOT be present 537 unless the ciphersuite requires this information (since the first 538 node receiving the bundle ought be the one to validate the BAB). 540 The security result MUST be present as it is effectively the 541 "output" from the ciphersuite calculation (e.g. the MAC or 542 signature) applied to the (relevant parts of) the bundle (as 543 specified in the ciphersuite definition). 545 For the case using two related BAB instances, the first instance is 546 as defined above, except the ciphersuite ID MUST be documented as a 547 hop-by-hop authentication ciphersuite that requires two instances of 548 the BAB. In addition, the correlator MUST be present and the 549 security result length and security result fields MUST be absent. 550 The second instance of the BAB MUST have the same correlator value 551 present and MUST contain security result length and security result 552 data fields. The other optional fields MUST NOT be present. 553 Typically, this second instance of a BAB will be the last block of 554 the bundle. 556 2.3. Payload Integrity Block 558 A PIB is an ASB with the following additional restrictions: 560 The block type code value MUST be 0x03. 562 The block processing control flags value can be set to whatever 563 values are required by local policy. 565 The ciphersuite ID MUST be documented as an end-to-end 566 authentication-ciphersuite or as an end-to-end error-detection- 567 ciphersuite. 569 The correlator MUST be present if the ciphersuite requires more 570 than one related instance of a PIB be present in the bundle. The 571 correlator MUST NOT be present if the ciphersuite only requires 572 one instance of the PIB in the bundle. 574 The ciphersuite parameters field MAY be present. 576 An EID reference to the security-source MAY be present. 578 An EID reference to the security-destination MAY be present. 580 The security result is effectively the "output" from the 581 ciphersuite calculation (e.g. the MAC or signature) applied to the 582 (relevant parts of) the bundle. As in the case of the BAB, this 583 field MUST be present if the correlator is absent. If more than 584 one related instance of the PIB is required then this is handled 585 in the same way as described for the BAB above. 587 The ciphersuite may process less than the entire original bundle 588 payload, either because the current payload is a fragment of the 589 original bundle or just becuase it is defined to process some 590 subset. For whatever reason, if the ciphersuite processes less 591 than the complete, original bundle payload MUST specify, as part 592 of the ciphersuite parameters, which bytes of the bundle payload 593 are protected. 595 For some ciphersuites, (e.g. those using asymmetric keying to produce 596 signatures or those using symmetric keying with a group key), the 597 security information can be checked at any hop on the way to the 598 destination that has access to the required keying information. This 599 possibility is further discussed in Section 3.6 below. 601 Most asymmetric PIB-ciphersuites will use the PIB-source to indicate 602 the signer and will not require the PIB-dest field because the key 603 needed to verify the PIB authenticator will be a public key 604 associated with the PIB-source. 606 2.4. Payload Confidentiality Block 608 A typical confidentiality ciphersuite will encrypt the payload using 609 a randomly generated bundle encrypting key (BEK) and will use a PCB 610 security parameter to carry the BEK encrypted with some long term key 611 encryption key (KEK) or well-known public key. If neither the 612 destination nor security-destination resolves the key to use for 613 decryption, the ciphersuite parameters field can be used to indicate 614 the decryption key with which the BEK can be recovered. Subsequent 615 PCB security results will contain blocks encrypted using the BEK if 616 non-payload blocks are to be encrypted. 618 It is STRONGLY RECOMMENDED that a data integrity mechanism be used in 619 conjunction with confidentiality, and that encryption-only 620 ciphersuites NOT be used. The "authentication tag" or "integrity 621 check value" is stored into security-result rather than being 622 appended to the payload as is common in some protocols since, as 623 described below, it is important that there be no change in the size 624 of the payload. 626 The payload is encrypted "in-place", that is, following encryption, 627 the payload block payload field contains ciphertext, not plaintext. 628 The payload block processing flags are unmodified. 630 The "in-place" encryption of payload bytes is to allow bundle payload 631 fragmentation and re-assembly, and custody transfer, to operate 632 without knowledge of whether or not encryption has occurred and, if 633 so, how many times. 635 Fragmentation and reassembly and custody transfer are adversely 636 affected by a change in size of the payload due to ambiguity about 637 what byte range of the original payload is actually in any particular 638 fragment. Ciphersuites SHOULD place any payload expansion, such as 639 authentication tags (integrity check values) and any padding 640 generated by a block-mode cipher, into an "integrity check value" 641 item in the security-result field (see Section 2.6) of the 642 confidentiality block. 644 Payload super-encryption is allowed. The second application of 645 confidentiality does not generally protect the parameters of the 646 first which represent a vulnerability in some circumstances. 647 Ciphersuites SHOULD define super-encryption such that it protects the 648 parameters of earlier encryption. 650 Confidentiality can be applied to blocks other than the payload and 651 in some cases this is recommended. The ciphersuite may apply 652 different rules to confidentiality for non-payload blocks. 654 For example, multiple related PCB instances are required if both the 655 payload and the PS blocks in the bundle are to be encrypted. These 656 multiple PCB instances require correlators to associate them with 657 each other. 659 Confidentiality is normally applied to the payload, and possibly to 660 additional blocks. It is RECOMMENDED to apply a Payload 661 Confidentiality ciphersuite to non-payload blocks only if these 662 should be super-encrypted with the payload. If super-encryption if 663 the block is not desired then protection of the block should be done 664 using the Extension Security Block mechanism rather than PCB. 666 There are situations where more than one PCB instance is required but 667 the instances are not "related" in the sense which requires 668 correlators. One example is where a payload is encrypted for more 669 than one security-destination so as to be robust in the face of 670 routing uncertainties. These multiple PCB instances, are not 671 "related" and should not contain correlators. 673 A PCB is an ASB with the following additional restrictions: 675 The block type code value MUST be 0x04. 677 The block processing control flags value can be set to whatever 678 values are required by local policy, except that a PCB "first 679 block" MUST have the "replicate in every fragment" flag set. This 680 flag SHOULD NOT be set otherwise. 682 The ciphersuite ID MUST be documented as a confidentiality- 683 ciphersuite. 685 The correlator MUST be present if there is more than one related 686 PCB instance. The correlator MUST NOT be present if there are no 687 related PCB instances. 689 If a correlator is present, the key information MUST be placed in 690 the PCB "first block". 692 Any additional bytes generated as a result of encryption and/or 693 authentication processing of the payload SHOULD be placed in an 694 "integrity check value" field (see Section 2.6) in the security- 695 result of the first PCB. 697 The ciphersuite parameters field MAY be present. 699 An EID reference to the security-source MAY be present. 701 An EID reference to the security-destination MAY be present. 703 The security result MAY be present and normally contains fields 704 such as an encrypted bundle encryption key, authentication tag or 705 the encrypted versions of bundle blocks other than the payload 706 block. 708 As was the case for the BAB and PIB, if the ciphersuite requires more 709 than one instance of the PCB, then the "first block" MUST contain any 710 optional fields (e.g. security destination etc.) that apply to all 711 instances with this correlator. These MUST be contained in the first 712 instance and MUST NOT be repeated in other correlated blocks. Fields 713 that are specific to a particular instance of the PCB MAY appear in 714 that PCB. For example, security result fields MAY (and probably 715 will) be included in multiple related PCB instances, with each result 716 being specific to that particular block. Similarly, several PCBs 717 might each contain a ciphersuite parameters field with an IV specific 718 to that PCB instance. 720 Put another way: when confidentiality will generate multiple blocks, 721 it MUST first create a PCB with the required ciphersuite ID, 722 parameters etc. as specified above. Typically, this PCB will appear 723 "early" in the bundle. If this "first" PCB doesn't contain all of 724 the ciphertext, then it may be followed by other, correlated PCBs 725 which MUST NOT repeat the ciphersuite parameters, security-source, or 726 security-destination fields from the first PCB. 728 A PCB ciphersuite may, or may not, specify which blocks are to be 729 encrypted. If the ciphersuite doesn't specify this, then the node is 730 free to encrypt whichever blocks it wishes. If a PCB ciphersuite 731 does specify which blocks are to be encrypted, then doing otherwise 732 is an error. 734 The ciphersuite may process less than the entire original bundle 735 payload, either because the current payload is a fragment of the 736 original bundle or just becuase it is defined to process some subset. 737 For whatever reason, if the ciphersuite processes less than the 738 complete, original bundle payload MUST specify, as part of the 739 ciphersuite parameters, which bytes of the bundle payload are 740 protected. 742 After decryption the recovered plaintext should then replace the PCB 743 in the bundle for further processing (e.g. PIB verification). This 744 recovered plaintext MUST contain all the appropriate block type, 745 processing flags and length information. In other words delete the 746 PCB in question and place the recovered plaintext, which consists of 747 some complete non-payload block, in the bundle at the location from 748 which the PCB was deleted. 750 A ciphersuite MUST NOT mix payload data and a non-payload block in a 751 single PCB. 753 Even if a to-be-encrypted block has the "discard" flag set, whether 754 or not the PCB's "discard" flag is set is an implementation/policy 755 decision for the encrypting node. (The "discard" flag is more 756 properly called the "discard if block cannot be processed" flag.) 758 Any existing eid-list in the to-be-encapsulated original block 759 remains exactly as-is, and become the eid-list for the replacing 760 block. The encapsulation process MUST NOT replace or remove the 761 existing eid-list entries. This is critically important for correct 762 updating of entries at the security-destination. 764 At the security-destination, either specific destination or the 765 bundle destination, the processes described above are reversed. The 766 payload is decrypted in-place using the salt, IV and key values in 767 the first PCB, including verification using the ICV. Each correlated 768 PCB is also processed at the same destination, using the salt and key 769 values from the first PCB and the block-specific IV item. The 770 "encapsulated block" item in security-result is decrypted, and 771 validated using the tag which was appended to the ciphertext of the 772 original block data. Assuming the validation succeeds, the resultant 773 plaintext, which is the entire content of the original block, 774 replaces the PCB at the same place in the bundle. The block type 775 reverts to that of the original block prior to encapsulation, and the 776 other block-specific data fields also return to their original 777 values. Implementors are cautioned that this "replacement" process 778 requires delicate stitchery, as the eid-list contents in the 779 decapsulated block are invalid. As noted above, the eid-list 780 references in the original block were preserved in the replacing PCB, 781 and will have been updated as necessary as the bundle has toured the 782 dtnet. The references from the PCB MUST replace the references 783 within the eid-list of the newly-decapsulated block. Caveat 784 implementor. 786 2.5. Extension Security Block 788 Extension security blocks provide protection for non-payload portions 789 of a bundle. They MUST NOT be used for the primary block or payload, 790 including payload-related security blocks. 792 It is sometimes desirable to protect certain parts of a bundle in 793 ways other than those applied to the bundle payload. One such 794 example is bundle metadata that might specify the kind of data in the 795 payload but not the actual payload detail, as described in [DTNMD]. 797 ESBs are typically used to apply confidentiality protection. While 798 it is possible to create an integrity-only ciphersuite, the block 799 protection is not transparent and makes access to the data more 800 difficult. For simplicity, this discussion describes use of a 801 confidentiality ciphersulte. 803 The protection mechanisms in ESBs are similar to other security 804 blocks with two important differences: 806 different key values are used (using same key as for payload would 807 defeat the purpose) 809 the block is not encrypted or super-encrypted with the payload 811 A typical ESB ciphersuite will encrypt the payload using a randomly 812 generated bundle encrypting key (BEK) and will use the security 813 result to carry the BEK encrypted with some long term key encryption 814 key (KEK) or well-known public key. If neither the destination nor 815 security-destination resolves the key to use for decryption, the 816 ciphersuite parameters field can be used to indicate the decryption 817 key with which the BEK can be recovered. 819 It is STRONGLY RECOMMENDED that a data integrity mechanism be used in 820 conjunction with confidentiality, and that encryption-only 821 ciphersuites NOT be used. AES-GCM satisfies this requirement. 823 The ESB is placed in the bundle in the same position as the block 824 being protected. That is, the entire original block is processed 825 (encrypted etc) and encapsulated in a "replacing" ESB-type block, and 826 this appears in the bundle at the same sequential position as the 827 original block. The processed data is placed in the security-result 828 field. 830 The process is reversed at the security destination with the 831 recovered plaintext block replacing the ESB that had encapsulated it. 832 Processing of EID-list entries, if any, is described above in 833 Section 2.4 and this must be followed in order to correctly recover 834 EIDs. 836 An ESB is an ASB with the following additional restrictions: 838 Block type is 0x09. 840 Ciphersuite flags indicate which fields are present in this block. 842 EID references MUST be stored in the EID reference list. 844 Security-source MAY be present. If not present, then the bundle- 845 source is the security-source. 847 Security-destination MAY be present. If not present, then the 848 bundle-destination is the security-destination. 850 The security-parameters MAY optionally contain a block-type field to 851 indicate the type of the encapsulated block. Since this replicates a 852 field in the encrypted portion of the block, it is a slight security 853 risk and its use is therefore OPTIONAL. 855 2.6. Parameters and Result Fields 857 Various ciphersuites include several items in the security-parameters 858 and/or security-result fields. Which fields may appear is defined by 859 the particular ciphersuite description. 861 Each field is represented as type-length-value. Type is a single 862 byte indicating which item this is. Length is the count of data 863 bytes to follow, and is an SDNV-encoded integer. Value is the data 864 content of the item. 866 Item types are 868 0: reserved 870 1: initialization vector (IV) 872 2: reserved 874 3: key information 876 4: fragment range (offset and length as a pair of SDNVs) 878 5: integrity signature 880 6: reserved 882 7: salt 884 8: PC block integrity check value (ICV) 886 9: reserved 888 10: encapsulated block 889 11: block type of encapsulated block 891 12 - 191: reserved 893 192 - 250: private use 895 251 - 255: reserved 897 The folowing descriptions apply to usage of these items for all 898 ciphersuites. Additional characteristics are noted in the discussion 899 for specific suites. 901 - initialization vector(IV): random value, typically eight to 902 sixteen bytes 904 - key information: key material encoded or protected by the key 905 management system. This item is discussed further below 906 Section 2.7 908 - fragment range: pair of SDNV values (offset then length) 909 specifying the range of payload bytes to which a particular 910 operation applies. This is termed "fragment range" since that is 911 its typical use, even though sometimes it may describe a subset 912 range that is not a fragment 914 - integrity signature: result of BA or PS digest or signing 915 operation. This item is discussed further below Section 2.7 917 - salt: an IV-like value used by certain confidentiality suites 919 - PC block integrity check value(ICV): output from certain 920 confidentiality ciphersuite operations to be used at the 921 destination to verify that the protected data has not been 922 modified 924 - encapsulated block: result of confidentiality operation on 925 certain blocks, contains the ciphertext of the block and may also 926 contain an integrity check value appended to the ciphertext; may 927 also contain padding if required by the encryption mode; used for 928 non-payload blocks only 930 block type of encapsulated block: block type code for a block that 931 has been encapsulated in ESB 933 2.7. Key Transport 935 This specification endeavours to maintain separation between the 936 security protocol and key management. However these two interact in 937 the transfer of key information etc from security-source to security- 938 destination. The intent of the separation is to facilitate use of a 939 variety of key management systems without a necessity to tailor a 940 ciphersuite to each individually. 942 The key management process deals with such things as long-term keys, 943 specifiers for long-term keys, certificates for long-term keys and 944 integrity signatures using long-term keys. The ciphersuite itself 945 should not require a knowledge of these, and separation is improved 946 if it treats these as opaque entities, to be handled by the key 947 management process. 949 The key management process deals specifically with the content of two 950 of the items defined above Section 2.6:- key information (item type 951 3) and integrity signature (item type 5). The content of these items 952 MUST be ASN.1-encoded as described in RFC 3852 [RFC3852] and related 953 RFCs. 955 Many situations will require several pieces of key information. 956 Ciphersuites MUST accept these packed into a single key-information 957 item with ASN.1 encoding and MAY choose to accept them if sent as 958 separate items. 960 2.8. PIB and PCB combinations 962 Given the above definitions, nodes are free to combine applications 963 of PIB and PCB in any way they wish - the correlator value allows for 964 multiple applications of security services to be handled separately. 966 However, there are some clear security problems that could arise when 967 applying multiple services. For example, if we encrypted a payload 968 but left a PIB security result containing a signature in the clear, 969 payload guesses could be confirmed. 971 We cannot, in general, prevent all such problems since we cannot 972 assume that every ciphersuite definition takes account of every other 973 ciphersuite definition. However, we can limit the potential for such 974 problems by requiring that any ciphersuite which applies to one 975 instance of a PIB or PCB, must be applied to all instances with the 976 same correlator. 978 We now list the PIB and PCB combinations which we envisage as being 979 useful to support: 981 Encrypted tunnels - a single bundle may be encrypted many times 982 en-route to its destination. Clearly it must be decrypted an 983 equal number of times, but we can imagine each encryption as 984 representing the entry into yet another layer of tunnel. This is 985 supported by using multiple instances of PCB, but with the payload 986 encrypted multiple times, "in-place". Depending upon the 987 ciphersuite defintion, other blocks can and should be encrypted, 988 as discussed above and in Section 2.4 to ensure that parameters 989 are protected in the case of super-encryption. 991 Multiple parallel authenticators - a single security source might 992 wish to protect the integrity of a bundle in multiple ways. This 993 could be required if the bundle's path is unpredictable, and if 994 various nodes might be involved as security destinations. 995 Similarly, if the security source cannot determine in advance 996 which algorithms to use, then using all might be reasonable. This 997 would result in uses of PIB which presumably all protect the 998 payload, and which cannot in general protect one another. Note 999 that this logic can also apply to a BAB, if the unpredictable 1000 routing happens in the convergence layer, so we also envisage 1001 support for multiple parallel uses of BAB. 1003 Multiple sequential authenticators - if some security destination 1004 requires assurance about the route that bundles have taken, then 1005 it might insist that each forwarding node add its own PIB. More 1006 likely, however would be that outbound "bastion" nodes would be 1007 configured to sign bundles as a way of allowing the sending 1008 "domain" to take accountability for the bundle. In this case, the 1009 various PIBs will likely be layered, so that each protects the 1010 earlier applications of PIB. 1012 Authenticated and encrypted bundles - a single bundle may require 1013 both authentication and confidentiality. Some specifications 1014 first apply the authenticator and follow this by encrypting the 1015 payload and authenticator. As noted previously in the case where 1016 the authenticator is a signature, there are security reasons for 1017 this ordering. (See the PCB-RSA-AES128-PAYLOAD-PIB-PCB 1018 ciphersuite defined later in Section 4.3.) Others apply the 1019 authenticator after encryption, that is, to the ciphertext. This 1020 ordering is generally recommended and minimizes attacks which, in 1021 some cases, can lead to recovery of the encryption key. 1023 There are no doubt other valid ways to combine PIB and PCB instances, 1024 but these are the "core" set supported in this specification. Having 1025 said that, as will be seen, the mandatory ciphersuites defined here 1026 are quite specific and restrictive in terms of limiting the 1027 flexibility offered by the correlator mechanism. This is primarily 1028 in order to keep this specification as simple as possible, while at 1029 the same time supporting the above scenarios. 1031 3. Security Processing 1033 This section describes the security aspects of bundle processing. 1035 3.1. Nodes as policy enforcement points 1037 All nodes are REQUIRED to have and enforce their own configurable 1038 security policies, whether these policies be explicit or default, as 1039 defined in Section 6. 1041 All nodes serve as Policy Enforcement Points (PEP) insofar as they 1042 enforce polices that may restrict the permissions of bundle nodes to 1043 inject traffic into the network. Policies may apply to traffic 1044 originating at the current node, traffic terminating at the current 1045 node and traffic to be forwarded by the current node to other nodes. 1046 If a particular transmission request, originating either locally or 1047 remotely, satisfies the node's policy or policies and is therefore 1048 accepted, then an outbound bundle can be created and dispatched. If 1049 not, then in its role as a PEP, the node will not create or forward a 1050 bundle. Error handling for such cases is currently considered out of 1051 scope of this document. 1053 Policy enforcing code MAY override all other processing steps 1054 described here and elsewhere in this document. For example, it is 1055 valid to implement a node which always attempts to attach a PIB. 1056 Similarly it is also valid to implement a node which always rejects 1057 all requests which imply the use of a PIB. 1059 Nodes MUST consult their security policy to determine the criteria 1060 that a received bundle ought to meet before it will be forwarded. 1061 These criteria MUST include a determination of whether or not the 1062 received bundle must include a valid BAB, PIB or PCB. If the bundle 1063 does not meet the node's policy criteria, then the bundle MUST be 1064 discarded and processed no further; in this case, a bundle status 1065 report indicating the failure MAY be generated. 1067 The node's policy MAY call for the node to add or subtract some 1068 security blocks, for example, requiring the node attempt to encrypt 1069 (parts of) the bundle for some security-destination, or requiring 1070 that the node add a PIB. If the node's policy requires a BAB to be 1071 added to the bundle, it MUST be added last so that the calculation of 1072 its security result may take into consideration the values of all 1073 other blocks in the bundle. 1075 3.2. Processing order of security blocks 1077 The processing order of security actions for a bundle is critically 1078 important for the actions to complete successfully. In general, the 1079 actions performed at the originating node must be executed in the 1080 reverse sequence at the destination. There are variations and 1081 exceptions, and these are noted below. 1083 The sequence is maintained in the ordering of security blocks in the 1084 bundle. It is for this reason that blocks may not be rearranged at 1085 forwarding nodes, whether they support the security protocols or not. 1086 The only blocks that participate in this ordering are the primary and 1087 payload blocks, and the PIB and PCB security blocks themselves. All 1088 other extension blocks, including ESBs, are ignored for purposes of 1089 determining the processing order. 1091 The security blocks are added to and removed from a bundle in a last- 1092 in-first-out (LIFO) manner, with the top of the stack immediately 1093 after the primary block. A newly-created bundle has just the primary 1094 and payload blocks, and the stack is empty. As security actions are 1095 requested for the bundle, security blocks are pushed onto the stack 1096 immediately after the primary block. The early actions have security 1097 blocks close to the payload, later actions have blocks nearer to the 1098 primary block. The actions deal with only those blocks in the bundle 1099 at the time so, for example, the first to be added processes only the 1100 payload and primary blocks, the next might process the first if it 1101 chooses and the payload and primary, and so on. The last block to be 1102 added can process all the blocks. 1104 When the bundle is received, this process is reversed and security 1105 processing begins at the top of the stack, immediately after the 1106 primary block. The security actions are performed and the block is 1107 popped from the stack. Processing continues with the next security 1108 block until finally only the payload and primary blocks remain. 1110 The simplicity of this description is undermined by various real- 1111 world requirements. Nonetheless it serves as a helpful initial 1112 framework for understanding the bundle security process. 1114 The first issue is a very common one and easy to handle. The bundle 1115 may be sent indirectly to its destination, requiring several 1116 forwarding hops to finally arrive there. Security processing happens 1117 at each node, assuming that the node supports bundle security. For 1118 the following discussion, we assume that a bundle is created and that 1119 confidentiality, then payload integrity and finally bundle 1120 authentication are applied to it. The block sequence would therefore 1121 be primary-BA-PS-PC-payload. Traveling from source to destination 1122 requires going through one intermediate node, so the trip consists of 1123 two hops. 1125 When the bundle is received at the intermediate node, the receive 1126 processing validates the BA block and pops it from the stack. 1128 However the PS and PC blocks have the final destination as their 1129 security destination, so these can't be processed and removed. The 1130 intermediate node then begins the send process with the four 1131 remaining blocks in the bundle. The outbound processing adds any 1132 security blocks required by local policy, and these are pushed on the 1133 stack immediately after the primary block, ahead of the PS block. In 1134 this example, the intermediate node adds a PS block as a signature 1135 that the bundle has passed through the node. 1137 The receive processing at the destination first handles the 1138 intermediate node's PS block and pops it, next is the originator's PS 1139 block, also popped, and finally the originator's confidentiality 1140 block which allows the payload to be decrypted and the bundle handled 1141 for delivery. 1143 This simple scheme can easily be extended to very complex networks. 1144 It cannot deal with security zones that overlap partially but not 1145 completely and these are discussed further below Section 3.3. 1146 Administrators SHOULD NOT configure security-sources and security- 1147 destinations in a network such that overlapping security zones are 1148 created. 1150 The second issue relates to the reversibility of certain security 1151 process actions. In general, the actions fall into two categories: 1152 those which do not affect other parts of the bundle, and those which 1153 are fully reversible. Creating a bundle signature, for example, does 1154 not change the bundle content except for the result. The encryption 1155 performed as part of the confidentiality processing does change the 1156 bundle, but the reverse processing at the destination restores the 1157 original content. 1159 The third category is the one where the bundle content has changed 1160 slightly and in a non-destructive way, but there is no mechanism to 1161 reverse the change. The simplest example is the addition of an EID- 1162 reference to a security block. The addition of the reference causes 1163 the text to be added to the bundle's dictionary. The text may be 1164 used also by other references so removal of the block and this 1165 specific eid-reference does not cause removal of the text from the 1166 dictionary. This shortcoming is of no impact to the "sequential" or 1167 "wrapping" security schemes described above, but does cause failures 1168 with "parallel" authentication mechanisms. Solutions for this 1169 problem are implementation-specific and typically involve multi-pass 1170 processing such that blocks are added at one stage and the security 1171 results calculated at a later stage of the overall process. 1173 Certain ciphersuites have sequence requirements for their correct 1174 operation, most notably the BundleAuthentication ciphersuites. 1175 Processing for BundleAuthentication is required to happen after all 1176 other sending operations, and prior to any receive operations at the 1177 next hop node. It follows therefore that BA blocks must always be 1178 pushed onto the stack after all others. 1180 Although we describe the security block list as a stack, there are 1181 some blocks which are placed after the payload and therefore are not 1182 part of the stack. The BundleAuthentication ciphersuite #1 ("BA1") 1183 requires a second, correlated block to contain the security-result 1184 and this block is placed after the payload, usually as the last block 1185 in the bundle. We can apply the stack rules even to these blocks by 1186 specifying that they be added to the end of the bundle at the same 1187 time that their "owner" or "parent" block is pushed on the stack. In 1188 fact, they form a stack beginning at the payload but growing in the 1189 other direction. Also, not all blocks in the main stack have a 1190 corresponding entry in the trailing stack. The only blocks which 1191 MUST follow the payload are those mandated by ciphersuites as 1192 correlated blocks for holding a security-result. No other blocks are 1193 required to follow the payload block and it is RECOMMENDED that they 1194 NOT do so. 1196 ESBs are effectivelt placeholders for the blocks they encapsulate 1197 and, since those do not form part of the processing sequence 1198 described above, ESBs themselves do not either. ESBs may be 1199 correlated, however, so the "no reordering" requirement applies to 1200 them as well. 1202 3.3. Security Zones 1204 Each security block has a security zone, as described in the 1205 discussion for Figure 1, and the zones for various blocks are often 1206 different. 1208 BA blocks are always for a single hop and these restricted zones 1209 never cause conflict. 1211 The zones for PS and PC blocks are often from bundle source to bundle 1212 destination, to provide end-to-end protection. A bundle-source-to- 1213 bundle-destination zone likewise never causes a problem. 1215 Another common scenario is for gateway-to-gateway protection of 1216 traffic between two sub-networks. 1218 Looking at Figure 1 and the simplified version shown in Figure 4, we 1219 can regard BN2 and BN3 as gateways connecting the two subnetworks 1220 labeled "An Internet". As long as they provide security for the BN2- 1221 BN3 zone, all is well. Problems begin, for example, when BN2 adds 1222 blocks with BN4 as the security-destination, and originating node BN1 1223 has created blocks with BN3 as security-destination. We now have two 1224 zones and neither is a subset of the other. 1226 +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ 1227 | BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 | 1228 +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ 1229 >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ 1231 <------------- BN1 to BN3 zone ------------> 1233 <------------- BN2 to BN4 zone ------------> 1235 Overlapping security zones 1237 Figure 4 1239 Consider the case where the security concern is for data integrity, 1240 so the blocks are PayloadIntegrity. BN1 creates one ("PSa") along 1241 with the new bundle, and BN2 pushes its own PS block "PSb" on the 1242 stack, with security-destination BN4. When this bundle arrives at 1243 BN3, the bundle blocks are 1245 primary - PSb - PSa - payload 1247 Block PSb is not destined for this node BN3 so must be forwarded. 1248 This is the security-destination for block PSa so, after validation, 1249 it should be removed from the bundle. But that will invalidate the 1250 PSb signature when the block is checked at the final destination. 1251 The PSb signature includes the primary block, PSb itself, PSa and the 1252 payload block, so PSa MUST remain in the bundle. This is why 1253 security blocks are treated as a stack and add/remove operations are 1254 permitted only at the top-of-stack. 1256 The situation would be worse if the security concern is 1257 confidentiality, so PC blocks are employed, such as the 1258 confidentiality ciphersuite #3 ("PC3") described in Section 4.3. In 1259 this scenario, BN1 would encrypt the bundle with BN3 as security- 1260 destination, BN2 would super-encrypt the payload and encapsulate the 1261 PC3 block for security-destination BN4. BN3 forwards all the blocks 1262 without change. BN4 decrypts the payload from its super-encryption 1263 and decapsulates the PC3 block, only to find that it should have been 1264 processed earlier. Assuming that BN4 has no access to BN3's key 1265 store, BN4 has no way to decrypt the bundle and recover the original 1266 content. 1268 3.4. Canonicalisation of bundles 1270 In order to verify a signature or MAC on a bundle the exact same 1271 bits, in the exact same order, must be input to the calculation upon 1272 verification as were input upon initial computation of the original 1273 signature or MAC value. Consequently, a node MUST NOT change the 1274 encoding of any URI in the dictionary field, e.g., changing the DNS 1275 part of some HTTP URL from lower case to upper case. Because bundles 1276 may be modified while in transit (either correctly or due to 1277 implementation errors), a canonical form of any given bundle (that 1278 contains a BAB or PIB) must be defined. 1280 This section defines two bundle canonicalisation algorithms which can 1281 be used by various ciphersuites. 1283 3.4.1. Strict canonicalisation 1285 The first algorithm that can be used permits no changes at all to the 1286 bundle between the security-source and the security-destination. It 1287 is mainly intended for use in BAB ciphersuites. This algorithm 1288 conceptually catenates all blocks in the order presented, but omits 1289 all security result data fields in blocks of this ciphersuite type. 1290 That is, when a BA ciphersuite specifies this algorithm then we omit 1291 all BAB security results for all BA ciphersuites, when a PIB 1292 ciphersuite specifies this algorithm then we omit all PIB security 1293 results for all PS ciphersuites. All security result length fields 1294 are included, even though their corresponding security result data 1295 fields are omitted. 1297 Notes: 1299 - In the above we specify that security result data is omitted. 1300 This means that no bytes of the security result data are input. 1301 We do not set the security result length to zero. Rather, we 1302 assume that the security result length will be known to the module 1303 that implements the ciphersuite before the security result is 1304 calculated, and require that this value be in the security result 1305 length field even though the security result data itself will be 1306 omitted. 1308 - The 'res' bit of the ciphersuite ID, which indicates whether or 1309 not the security result length and security result data field are 1310 present, is part of the canonical form. 1312 -The value of the block data length field, which indicates the 1313 length of the block, is also part of the canonical form. Its 1314 value indicates the length of the entire bundle when the bundle 1315 includes the security result data field. 1317 -BABs are always added to bundles after PIBs, so when a PIB 1318 ciphersuite specifies this strict canonicalisation algorithm and 1319 the PIB is received with a bundle that also includes one or more 1320 BABs, application of strict canonicalisation as part of the PIB 1321 security result verification process requires that all BABs in the 1322 bundle be ignored entirely. 1324 3.4.2. Mutable canonicalisation 1326 This algorithm is intended to protect parts of the bundle which 1327 should not be changed in-transit. Hence it omits the mutable parts 1328 of the bundle. 1330 The basic approach is to define a canonical form of the primary block 1331 and catenate it with the security and payload blocks in the order 1332 that they will be transmitted. This algorithm ignores all other 1333 blocks because it cannot be determined whether or not they will 1334 change as the bundle transits the network. 1336 Many fields in various blocks are stored as variable-length SDNVs. 1337 These are canonicalized in unpacked form, as eight-byte fixed-width 1338 fields in network byte order. The size of eight bytes is chosen 1339 because implementations may handle larger values as invalid, as noted 1340 in [DTNBP]. 1342 The canonical form of the primary block is shown in Figure 5. 1343 Essentially, it de-references the dictionary block, adjusts lengths 1344 where necessary and ignores flags that may change in transit. 1346 +----------------+----------------+----------------+----------------+ 1347 | Version | Processing flags (incl. COS and SRR) | 1348 +----------------+----------------+---------------------------------+ 1349 | Canonical primary block length | 1350 +----------------+----------------+---------------------------------+ 1351 | Destination endpoint ID length | 1352 +----------------+----------------+---------------------------------+ 1353 | | 1354 | Destination endpoint ID | 1355 | | 1356 +----------------+----------------+---------------------------------+ 1357 | Source endpoint ID length | 1358 +----------------+----------------+----------------+----------------+ 1359 | | 1360 | Source endpoint ID | 1361 | | 1362 +----------------+----------------+---------------------------------+ 1363 | Report-to endpoint ID length | 1364 +----------------+----------------+----------------+----------------+ 1365 | | 1366 | Report-to endpoint ID | 1367 | | 1368 +----------------+----------------+----------------+----------------+ 1369 | | 1370 + Creation Timestamp (2 x SDNV) + 1371 | | 1372 +---------------------------------+---------------------------------+ 1373 | Lifetime | 1374 +----------------+----------------+----------------+----------------+ 1376 The canonical form of the primary bundle block. 1378 Figure 5 1380 The fields shown in Figure 5 are: 1382 Version is the single-byte value in the primary block. 1384 Processing flags in the primary block is an SDNV, and includes the 1385 class-of-service (COS) and status report request (SRR) fields. 1386 For purposes of canonicalization, the SDNV is unpacked into a 1387 fixed-width field and some bits are masked out. The unpacked 1388 field is ANDed with mask 0x0000 0000 003E 031F to set to zero all 1389 reserved bits and the "bundle is a fragment" bit. 1391 Length - a four-byte value containing the length (in bytes) of 1392 this structure, in network byte order. 1394 Destination endpoint ID length and value - are the length (as a 1395 four byte value in network byte order) and value of the 1396 destination endpoint ID from the primary bundle block. The URI is 1397 simply copied from the relevant part(s) of the dictionary block 1398 and is not itself canonicalised. Although the dictionary entries 1399 contain null-terminators, the null-terminators are not included in 1400 the length or the canonicalization. 1402 Source endpoint ID length and value are handled similarly to the 1403 destination. 1405 Report-to endpoint ID length and value are handled similarly to 1406 the destination. 1408 Creation time (2 x SDNV) and Lifetime (SDNV) are simply copied 1409 from the primary block, with the SDNV values being represented as 1410 eight-byte unpacked values. 1412 Fragment offset and Total application data unit length are 1413 ignored, as is the case for the "bundle is a fragment" bit 1414 mentioned above. If the payload data to be canonicalized is less 1415 than the complete, original bundle payload, the offset and length 1416 are specified in the security-parameters. 1418 For non-primary blocks being included in the canonicalization, the 1419 block processing flags value used for canonicalization is the 1420 unpacked SDNV value with reserved and mutable bits masked to zero. 1421 The unpacked value is ANDed with mask 0x0000 0000 0000 0057 to zero 1422 reserved bits and the "last block" flag. The "last block" flag is 1423 ignored because BABs and other security blocks may be added for some 1424 parts of the journey but not others so the setting of this bit might 1425 change from hop to hop. 1427 Endpoint ID references in security blocks are canonicalized using the 1428 de-referenced text form in place of the reference pair. The 1429 reference count is not included, nor is the length of the endpoint ID 1430 text. 1432 The block-length is canonicalized as an eight-byte unpacked value in 1433 network byte order. If the payload data to be canonicalized is less 1434 than the complete, original bundle payload, this field contain the 1435 size of the data being canonicalized (the "effective block") rather 1436 that the actual size of the block. 1438 Payload blocks are generally canonicalized as-is with the exception 1439 that in some instances only a portion of the payload data is to be 1440 protected. In such a case, only those bytes are included in the 1441 canonical form, and additional ciphersuite parameters are required to 1442 specify which part of the payload is protected, as discussed further 1443 below. 1445 Security blocks are handled likewise, except that the ciphersuite 1446 will likely specify that the "current" security block security result 1447 field not be considered part of the canonical form. This differs 1448 from the strict canonicalisation case since we might use the mutable 1449 canonicalisation algorithm to handle sequential signatures such that 1450 signatures cover earlier ones. 1452 ESBs MUST NOT be included in the canonicalization. 1454 Notes: 1456 - The canonical form of the bundle is not transmitted. It is 1457 simply an artifact used as input to digesting. 1459 - We omit the reserved flags because we cannot determine if they 1460 will change in transit. The masks specified above may have to be 1461 revised if additional flags are defined and they need to be 1462 protected. 1464 - Our URI encoding does not preserve the "null-termination" 1465 convention from the dictionary field, nor do we separate the 1466 scheme and ssp as is done there. 1468 - The URI encoding will cause errors if any node rewrites the 1469 dictionary content (e.g. changing the DNS part of an HTTP URL from 1470 lower-case to upper case). This could happen transparently when a 1471 bundle is synched to disk using one set of software and then read 1472 from disk and forwarded by a second set of software. Because 1473 there are no general rules for canonicalising URIs (or IRIs), this 1474 problem may be an unavoidable source of integrity failures. 1476 - All SDNV fields here are canonicalized as eight-byte unpacked 1477 values in network byte order. Length fields are canonicalized as 1478 four-byte values in network byte order. Encoding does not need 1479 optimization since the values are never sent over the network. 1481 If a bundle is fragmented before the PIB is applied then the PIB 1482 applies to a fragment and not the entire bundle. However, the 1483 protected fragment could be subsequently further fragmented, which 1484 would leave the verifier unable to know which bytes were protected 1485 by the PIB. Even in the absence of frgmentation the same 1486 situation applies if the ciphersuite is defined to allow 1487 protection of less than the entire, original bundle payload. 1489 For this reason, PIB ciphersuites which support applying a PIB to 1490 less than the complete, original bundle payload MUST specify, as 1491 part of the ciphersuite parameters, which bytes of the bundle 1492 payload are protected. When verification occurs, only the 1493 specified range of the payload bytes are input to PIB 1494 verification. It is valid for a ciphersuite to be specified so as 1495 to only apply to entire bundles and not to fragments. A 1496 ciphersuite may be specified to apply to only a portion of the 1497 payload, regardless of whether the payload is a fragment or the 1498 complete original bundle payload. 1500 The same fragmentation issue applies equally to PCB ciphersuites. 1501 Ciphersuites which support applying confidentiality to fragments 1502 MUST specify, as part of the ciphersuite parameters, which bytes 1503 of the bundle payload are protected. When decrypting a fragment, 1504 only the specified bytes are processed. It is also valid for a 1505 confidentiality ciphersuite to be specified so as to only apply to 1506 entire bundles and not to fragments. 1508 This definition of mutable canonicalization assumes that endpoint IDs 1509 themselves are immutable and is unsuitable for use in environments 1510 where that assumption might be violated. 1512 Since the canonicalization applies to a specific bundle rather than a 1513 payload, an originator's signature cannot be verified if a payload is 1514 forwarded, as the forwarded bundle will have a different source. 1516 The solution for either of these issues is to use a PIB ciphersuite 1517 having an alternate version of mutable canonicalization that does not 1518 include any fields from the primary block. 1520 3.5. Endpoint ID confidentiality 1522 Every bundle MUST contain a primary block that cannot be encrypted 1523 which also contains the source and destinations endpoint IDs, and 1524 others. If endpoint ID confidentiality is required, then a fake 1525 primary block with false values for these fields must be constructed 1526 and with a new block type to contain the actual values. There is 1527 presently no mechanism defined that supports such a "fake block" or 1528 possibly "fake dictionary". Bundle-in-bundle encapsulation may solve 1529 this problem in some instances. 1531 Similarly, confidentiality requirements may also apply to other parts 1532 of the primary block (e.g. the current-custodian) and that is 1533 supported in the same manner. 1535 3.6. Bundles received from other nodes 1537 Nodes implementing this specification SHALL consult their security 1538 policy to determine whether or not a received bundle is required by 1539 policy to include a BAB. If the bundle is not required to have a 1540 BAB, then BAB processing on the received bundle is complete and the 1541 bundle is ready to be further processed for PCB/PIB handling or 1542 delivery or forwarding. 1544 If the bundle is required to have a BAB but does not, then the bundle 1545 MUST be discarded and processed no further. If the bundle is 1546 required to have a BAB but all of its BABs identify a different node 1547 other than the receiving node as the BAB security destination, then 1548 the bundle MUST be discarded and processed no further. 1550 If the bundle has one or more BABs that identify the receiving node 1551 as the BAB security destination, or for which there is no security 1552 destination, then the value in the security result field(s) of the 1553 BAB(s) MUST be verified according to the ciphersuite specification. 1554 If for all such BABs in the bundle either the BAB security source 1555 cannot be determined or the security result value check fails, the 1556 bundle has failed to authenticate and the bundle MUST be discarded 1557 and processed no further. Otherwise, if any of the BABs present 1558 verify, the bundle is ready for further processing as determined by 1559 extension blocks and/or policy. 1561 BABs received in a bundle MUST be stripped before the bundle is 1562 forwarded. New BABs MAY be added as required by policy. This may 1563 require correcting the "last block" field of the to-be-forwarded 1564 bundle. 1566 Further processing of the bundle must take place in the order 1567 indicated by the various blocks from the primary block to the payload 1568 block, except as defined by an applicable specification. 1570 If the bundle has a PCB and the receiving node is the PCB destination 1571 for the bundle (either because the node is listed as the bundle's 1572 PCB-dest or because the node is listed as the bundle's destination 1573 and there is no PCB-dest), the node MUST decrypt the relevant parts 1574 of the bundle in accordce with the ciphersuite specification. The 1575 PCB SHALL be deleted. If the relevant parts of the bundle cannot be 1576 decrypted (i.e., the decryption key cannot be deduced or decryption 1577 fails), then the bundle MUST be discarded and processed no further; 1578 in this case a bundle deletion status report (see the Bundle Protocol 1579 [DTNBP]) indicating the decryption failure MAY be generated. If the 1580 PCB security result included the ciphertext of a block other than the 1581 payload block, the recovered plaintext block MUST be placed in the 1582 bundle at the location from which the PCB was deleted. 1584 If the bundle has one or more PIBs for which the receiving node is 1585 the bundle's PIB destination (either because the node is listed in 1586 the bundle's PIB-dest or because the node is listed as the bundle's 1587 destination and there is no PIB-dest), the node MUST verify the value 1588 in the PIB security result field(s) in accordance with the 1589 ciphersuite specification. If all the checks fail, the bundle has 1590 failed to authenticate and the bundle SHALL be processed according to 1591 the security policy. A bundle status report indicating the failure 1592 MAY be generated. Otherwise, if the PIB verifies, the bundle is 1593 ready to be processed for either delivery or forwarding. Before 1594 forwarding the bundle, the node SHOULD remove the PIB from the 1595 bundle, subject to the requirements of Section 3.2, unless it is 1596 likely that some downstream node will also be able to verify the PIB. 1598 If the bundle has a PIB and the receiving node is not the bundle's 1599 PIB-dest the receiving node MAY attempt to verify the value in the 1600 security result field. If it is able to check and the check fails, 1601 the node SHALL discard the bundle and it MAY send a bundle status 1602 report indicating the failure. 1604 If the bundle has an ESB and the receiving node is the ESB 1605 destination for the bundle (either because the node is listed as the 1606 bundle's ESB-dest or because the node is listed as the bundle's 1607 destination and there is no ESB-dest), the node MUST decrypt and/or 1608 decapsulate the encapsulated in accordance with the ciphersuite 1609 specification. The decapsulated block replaces the ESB in the bundle 1610 block sequence, and the ESB is thereby deleted. If the content 1611 cannot be decrypted (i.e., the decryption key cannot be deduced or 1612 decryption fails), then the bundle MUST be discarded and processed no 1613 further; in this case a bundle deletion status report (see the Bundle 1614 Protocol [DTNBP]) indicating the decryption failure MAY be generated. 1616 3.7. The At-Most-Once-Delivery Option 1618 An application may request (in an implementation specific manner) 1619 that a node be registered as a member of an endpoint and that 1620 received bundles destined for that endpoint be delivered to that 1621 application. 1623 An option for use in such cases is known as "at-most-once-delivery". 1624 If this option is chosen, the application indicates that it wants the 1625 node to check for duplicate bundles, discard duplicates, and deliver 1626 at most one copy of each received bundle to the application. If this 1627 option is not chosen, the application indicates that it wants the 1628 node to deliver all received bundle copies to the application. If 1629 this option is chosen, the node SHALL deliver at most one copy of 1630 each received bundle to the application. If the option is not 1631 chosen, the node SHOULD, subject to policy, deliver all bundles. 1633 To enforce this the node MUST look at the source/timestamp pair value 1634 of each complete (reassembled, if necessary) bundle received and 1635 determine if this pair, which uniquely identifies a bundle, has been 1636 previously received. If it has, then the bundle is a duplicate. If 1637 it has not, then the bundle is not a duplicate. The source/timestamp 1638 pair SHALL be added to the list of pair values already received by 1639 that node. 1641 Each node implementation may decide how long to maintain a table of 1642 pair value state. 1644 Additional discussion relevant to at-most-delivery is in the DTN 1645 Retransmission Block specification [DTNRB]. 1647 3.8. Bundle Fragmentation and Reassembly 1649 If it is necessary for a node to fragment a bundle and security 1650 services have been applied to that bundle, the fragmentation rules 1651 described in [DTNBP] MUST be followed. As defined there and repeated 1652 here for completeness, only the payload may be fragmented; security 1653 blocks, like all extension blocks, can never be fragmented. In 1654 addition, the following security-specific processing is REQUIRED: 1656 The security policy requirements for a bundle must be applied 1657 individually to all the bundles resulting from a fragmentation event. 1659 If the original bundle contained a PIB, then each of the PIB 1660 instances MUST be included in some fragment. 1662 If the original bundle contained one or more PCBs, then any PCB 1663 instances containing a BEK MUST have the "replicate in every 1664 fragment" flag set, and thereby be replicated in every fragment. 1665 This is to ensure that the canonical block-sequence can be recovered 1666 during reassembly. 1668 If the original bundle contained one or more correlated PCBs not 1669 containing a BEK, then each of these MUST be included in some 1670 fragment, but SHOULD NOT be sent more than once. They MUST be placed 1671 in a fragment in accordance with the fragmentation rules described in 1672 [DTNBP]. 1674 Note: various fragments may have additional security blocks added at 1675 this or later stages and it is possible that correlators may collide. 1676 In order to facilitate uniqueness, ciphersuites SHOULD include the 1677 fragment-offset of the fragment as a high-order component of the 1678 correlator. 1680 3.9. Reactive fragmentation 1682 When a partial bundle has been received, the receiving node SHALL 1683 consult its security policy to determine if it may fragment the 1684 bundle, converting the received portion into a bundle fragment for 1685 further forwarding. Whether or not reactive fragmentation is 1686 permitted SHALL depend on the security policy and the ciphersuite 1687 used to calculate the BAB authentication information, if required. 1688 (Some BAB ciphersuites, i.e., the mandatory BAB-HMAC ciphersuite 1689 defined in Section 4.1, do not accommodate reactive fragmentation 1690 because the security result in the BAB requires that the entire 1691 bundle be signed. It is conceivable, however, that a BAB ciphersuite 1692 could be defined such that multiple security results are calculated, 1693 each on a different segment of a bundle, and that these security 1694 results could be interspersed between bundle payload segments such 1695 that reactive fragmentation could be accommodated.) 1697 If the bundle is reactively fragmented by the intermediate receiver 1698 and the BAB-ciphersuite is of an appropriate type (e.g. with multiple 1699 security results embedded in the payload), the bundle MUST be 1700 fragmented immediately after the last security result value in the 1701 partial payload that is received. Any data received after the last 1702 security result value MUST be dropped. 1704 If a partial bundle is received at the intermediate receiver and is 1705 reactively fragmented and forwarded, only the part of the bundle that 1706 was not received MUST be retransmitted, though more of the bundle MAY 1707 be retransmitted. Before retransmitting a portion of the bundle, it 1708 SHALL be changed into a fragment and, if the original bundle included 1709 a BAB, the fragmented bundle MUST also, and its BAB SHALL be 1710 recalculated. 1712 This specification does not currently define any ciphersuite which 1713 can handle this reactive fragmentation case. 1715 An interesting possibility is a ciphersuite definition such that the 1716 transmission of a follow-up fragment would be accompanied by the 1717 signature for the payload up to the restart point. 1719 4. Mandatory Ciphersuites 1721 This section defines the mandatory ciphersuites for this 1722 specification. There is currently one mandatory ciphersuite for use 1723 with each of the security block types BAB, PIB and PCB. The BAB 1724 ciphersuite is based on shared secrets using HMAC. The PIB 1725 ciphersuite is based on digital signatures using RSA with SHA256. 1726 The PCB ciphersuite is based on using RSA for key transport and AES 1727 for bulk encryption. 1729 One ciphersuite is defined for security block type ESB. 1730 Implementation of this suite is OPTIONAL. 1732 4.1. BAB-HMAC 1734 The BAB-HMAC ciphersuite has ciphersuite ID value 0x001. 1736 Security parameters are optional with this scheme, but if used then 1737 the only field that can be present is key information (see 1738 Section 2.6). The exact type of key information to be used is an 1739 implementation issue. In the absence of key information the receiver 1740 is expected to be able to find the correct key based on the sending 1741 identity. The sending identity may be known from the security-source 1742 field or the content of a previous-hop block in the bundle. It may 1743 also be determined using implementation-specific means such as the 1744 convergence layer. 1746 BAB-HMAC uses the strict canonicalisation algorithm in Section 3.4.1. 1748 Strict canonicalization supports digesting of a fragment-bundle. It 1749 does not permit the digesting of only a subset of the payload, but 1750 only the complete contents of the payload of the current bundle, 1751 which might be a fragment. The "fragment range" item for security- 1752 parameters is not used to indicate a fragment, as this information is 1753 digested within the primary block. 1755 The variant of HMAC to be used is HMAC-SHA1 as defined in RFC 2104 1756 [RFC2104]. 1758 This ciphersuite requires the use of two related instances of the 1759 BAB. It involves placing the first BAB instance (as defined in 1760 Section 2.2) just after the primary block. The second (correlated) 1761 instance of the BAB MUST be placed after all other blocks (except 1762 possibly other BAB blocks) in the bundle. 1764 This means that normally, the BAB will be the second and last blocks 1765 of the bundle. If a forwarder wishes to apply more than one 1766 correlated BAB pair, then this can be done. There is no requirement 1767 that each application "wrap" the others, but the forwarder MUST 1768 insert all the "up front" BABs, and their "at back" "partners" 1769 (without any security result), before canonicalising. 1771 Inserting more than one correlated BAB pair would be useful if the 1772 bundle could be routed to more than one potential "next-hop" or if 1773 both an old or a new key were valid at sending time, with no 1774 certainty about the situation that will obtain at reception time. 1776 The security result is the output of the HMAC-SHA1 calculation with 1777 input being the result of running the entire bundle through the 1778 strict canonicalisation algorithm. Both required BAB instances MUST 1779 be included in the bundle before canonicalisation. 1781 4.2. PIB-RSA-SHA256 1783 The PIB-RSA-SHA256 ciphersuite has ciphersuite ID value 0x02. 1785 If the bundle being signed has been fragmented before signing, then 1786 we have to specify which bytes were signed in case the signed bundle 1787 is subsequently fragmented for a second time. If the bundle is a 1788 fragment, then the ciphersuite parameters MUST include a fragment- 1789 range field, as described in Section 2.6, specifying the offset and 1790 length of the signed fragment. If the entire bundle is signed then 1791 these numbers MUST be omitted. 1793 The ciphersuite parameters field MAY also contain a key information 1794 item. The exact type of key information to be used is an 1795 implementation issue. In the absence of a key identifier, the 1796 verifier of the PIB is expected to be able to use the security source 1797 (if supplied) or else the bundle source (if no security source is 1798 present) in order to determine the correct public key to use for PIB 1799 verification. 1801 PIB-RSA-SHA256 uses the mutable canonicalisation algorithm 1802 Section 3.4.2, with the security-result data field for only the 1803 "current" block being excluded from the canonical form. The 1804 resulting canonical form of the bundle is the input to the signing 1805 process. This ciphersuite requires the use of a single instance of 1806 the PIB. 1808 RSA is used with SHA256 as specified for the id-sha256 PKCSv2.1 1809 signature scheme in RFC 4055 [RFC4055]. The output of the signing 1810 process is the security result item for the PIB. 1812 "Commensurate strength" cryptography is generally held to be a good 1813 idea. A combination of RSA with SHA256 is reckoned to require a 3076 1814 bit RSA key according to this logic. Few implementations will choose 1815 this length by default (and probably some just won't support such 1816 long keys). Since this is an experimental protocol, we expect that 1817 1024 or 2048 bit RSA keys will be used in many cases, and that that 1818 will be fine since we also expect that the hash function "issues" 1819 will be resolved before any standard would be derived from this 1820 protocol. 1822 4.3. PCB-RSA-AES128-PAYLOAD-PIB-PCB 1824 The PCB-RSA-AES128-PAYLOAD-PIB-PCB ciphersuite has ciphersuite ID 1825 value 0x003. 1827 This scheme encrypts PIBs, PCBs and the payload. The key size for 1828 this ciphersuite is 128 bits. 1830 Encryption is done using the AES algorithm in Galois/Counter Mode 1831 (GCM) as described in RFC 5084 [RFC5084] [Note: parts of the 1832 following description are borrowed from RFC 4106]. 1834 The choice of GCM avoids expansion of the payload, which causes 1835 problems with fragmentation/reassembly and custody transfer. GCM 1836 also includes authentication, essential in preventing attacks that 1837 can alter the decrypted plaintext or even recover the encryption key. 1839 GCM is a block cipher mode of operation providing both 1840 confidentiality and data origin authentication. The GCM 1841 authenticated encryption operation has four inputs: a secret key, an 1842 initialization vector (IV), a plaintext, and an input for additional 1843 authenticated data (AAD) which is not used here. It has two outputs, 1844 a ciphertext whose length is identical to the plaintext, and an 1845 authentication tag, also known as the Integrity Check Value (ICV). 1847 For consistency with the description in [RFC5084], we refer to the 1848 GCM IV as a nonce. The same key and nonce combination MUST NOT be 1849 used more than once. The nonce has the following layout 1850 +----------------+----------------+---------------------------------+ 1851 | salt | 1852 +----------------+----------------+---------------------------------+ 1853 | | 1854 | initialization vector | 1855 | | 1856 +----------------+----------------+---------------------------------+ 1858 Nonce format. 1860 Figure 6 1862 The salt field is a four-octet value, usually chosen at random. It 1863 MUST be the same for all PCBs which have the same correlator value. 1864 The salt need not be kept secret. 1866 The initialization vector (IV) is an eight-octet value, usually 1867 chosen at random. It MUST be different for all PCBs which have the 1868 same correlator value. The value need not be kept secret. 1870 The key (bundle encryption key, BEK) is a sixteen-octet (128 bits) 1871 value, usually chosen at random. The value MUST be kept secret, as 1872 described below. 1874 The integrity check value is a sixteen-octet value used to verify 1875 that the protected data has not been altered. The value need not be 1876 kept secret. 1878 This ciphersuite requires the use of a single PCB instance to deal 1879 with payload confidentiality. If the bundle already contains PIBs or 1880 PCBs then the ciphersuite will create additional correlated blocks to 1881 protect these PIBs and PCBs. These "additional" blocks replace the 1882 original blocks on a one-for-one basis, so the number of blocks 1883 remains unchanged. All these related blocks MUST have the same 1884 correlator value. The term "first PCB" in this section refers to the 1885 single PCB if there is only one or, if there are several, then to the 1886 one containing the key information. This MUST be the first of the 1887 set. 1889 First PCB - the first PCB may contain a correlator value, and may 1890 specify security-source and/or security-destination in the eid-list. 1891 If not specified, the bundle-source and bundle-destination 1892 respectively are used for these values, as with other ciphersuites. 1893 The block MUST contain security-parameters and security-result 1894 fields. Each field may contain several items formatted as described 1895 in Section 2.6. 1897 Security-parameters 1898 key information 1900 salt 1902 IV (this instance applies only to payload) 1904 fragment offset and length, if bundle is a fragment 1906 Security-result 1908 ICV 1910 Subsequent PCBs MUST contain a correlator value to link them to the 1911 first PCB. Security-source and security-destination are implied from 1912 the first PCB, however see the discussion below concerning eid-list 1913 entries. They MUST contain security-parameters and security-result 1914 fields as follows: 1916 Security-parameters 1918 IV for this specific block 1920 Security-result 1922 encapsulated block 1924 The security-parameters and security-result fields in the subsequent 1925 PCBs MUST NOT contain any items other than these two. Items such as 1926 key and salt are supplied in the first PCB and MUST NOT be repeated. 1928 Protection of the key is performed as defined in the Key Management 1929 Specification [tbd]. Key management for this ciphersuite MUST 1930 support PKCSv2.1 rsaEncryption as specified in RFC 3370 [RFC3370] and 1931 MAY support other schemes. The output from the key management 1932 protection scheme ("key information") is placed in the security- 1933 parameters field of the first PCB. 1935 If the bundle being encrypted is a fragment-bundle we have to specify 1936 which bytes are encrypted in case the bundle is subsequently 1937 fragmented again. If the bundle is a fragment the ciphersuite 1938 parameters MUST include a fragment-range field, as described in 1939 Section 2.6, specifying the offset and length of the encrypted 1940 fragment. Note that this is not the same pair of fields which appear 1941 in the primary block as "offset and length". The "length" in this 1942 case is the length of the fragment, not the original length. If the 1943 bundle is not a fragment then this field MUST be omitted. 1945 The confidentiality processing for payload and other blocks is 1946 different, mainly because the payload might be fragmented later at 1947 some other node. 1949 For the payload, only the bytes of the bundle payload field are 1950 affected, being replaced by ciphertext. The salt, IV and key values 1951 specified in the first PCB are used to encrypt the payload, and the 1952 resultant authentication tag (ICV) is placed in an ICV item in the 1953 security-result field of that first PCB. The other bytes of the 1954 payload block, such as type, flags and length, are not modified. 1956 For each PIB or PCB to be protected, the entire original block is 1957 encapsulated in a "replacing" PCB. This replacing PCB is placed in 1958 the outgoing bundle in the same position as the original block, PIB 1959 or PCB. As mentioned above, this is one-for-one replacement and 1960 there is no consolidation of blocks or mixing of data in any way. 1962 The encryption process uses AES-GCM with the salt and key values from 1963 the first PCB, and an IV unique to this PCB. The process creates 1964 ciphertext for the entire original block, and an authentication tag 1965 for validation at the security destination. For this encapsulation 1966 process, unlike the processing of the bundle payload, the 1967 authentication tag is appended to the ciphertext for the block and 1968 the combination is stored into the "encapsulated block" item in 1969 security-result. 1971 The replacing block, of course, also has the same correlator value as 1972 the first PCB with which it is associated. It also contains the 1973 block-specific IV in security-parameters, and the combination of 1974 original-block-ciphertext and authentication tag, stored as an 1975 "encapsulated block" item in security-result. 1977 If the payload was fragmented after encryption then all those 1978 fragments MUST be present and reassembled before decryption. This 1979 process might be repeated several times at different destinations if 1980 multiple fragmentation actions have occurred. 1982 The size of the GCM counter field limits the payload size to 2^39 - 1983 256 bytes, about half a terabyte. A future revision of this 1984 specification will address the issue of handling payloads in excess 1985 of this size. 1987 4.4. ESB-RSA-AES128-EXT 1989 The ESB-RSA-AES128-EXT ciphersuite has ciphersuite ID value 0x004. 1991 This scheme encrypts non-payload blocks. The key size for this 1992 ciphersuite is 128 bits. 1994 Encryption is done using the AES algorithm in Galois/Counter Mode 1995 (GCM) as described in RFC 5084 [RFC5084] [Note: parts of the 1996 following description are borrowed from RFC 4106]. 1998 GCM is a block cipher mode of operation providing both 1999 confidentiality and data origin authentication. The GCM 2000 authenticated encryption operation has four inputs: a secret key, an 2001 initialization vector (IV), a plaintext, and an input for additional 2002 authenticated data (AAD) which is not used here. It has two outputs, 2003 a ciphertext whose length is identical to the plaintext, and an 2004 authentication tag, also known as the Integrity Check Value (ICV). 2006 For consistency with the description in [RFC5084], we refer to the 2007 GCM IV as a nonce. The same key and nonce combination MUST NOT be 2008 used more than once. The nonce has the following layout 2010 +----------------+----------------+---------------------------------+ 2011 | salt | 2012 +----------------+----------------+---------------------------------+ 2013 | | 2014 | initialization vector | 2015 | | 2016 +----------------+----------------+---------------------------------+ 2018 Nonce format. 2020 Figure 7 2022 The salt field is a four-octet value, usually chosen at random. It 2023 MUST be the same for all ESBs which have the same correlator value. 2024 The salt need not be kept secret. 2026 The initialization vector (IV) is an eight-octet value, usually 2027 chosen at random. It MUST be different for all ESBs which have the 2028 same correlator value. The value need not be kept secret. 2030 The key (bundle encryption key, BEK) is a sixteen-octet (128 bits) 2031 value, usually chosen at random. The value MUST be kept secret, as 2032 described below. 2034 The integrity check value is a sixteen-octet value used to verify 2035 that the protected data has not been altered. The value need not be 2036 kept secret. 2038 This ciphersuite replaces each block to be protected with a 2039 "replacing" ESB, and each can be individually specified. If a number 2040 of related blocks are to be protected they can be grouped as a 2041 correlated set. These blocks replace the original blocks on a one- 2042 for-one basis, so the number of blocks remains unchanged. All these 2043 related blocks MUST have the same correlator value. The term "first 2044 ESB" in this section refers to the single ESB if there is only one 2045 or, if there are several, then to the one containing the key or key- 2046 identifier. This MUST be the first of the set. If the blocks are 2047 individually specified then there is no correlated set and each block 2048 is its own "first ESB". 2050 First ESB - the first ESB may contain a correlator value, and may 2051 specify security-source and/or security-destination in the eid-list. 2052 If not specified, the bundle-source and bundle-destination 2053 respectively are used for these values, as with other ciphersuites. 2054 The block MUST contain security-parameters and security-result 2055 fields. Each field may contain several items formatted as described 2056 in Section 2.6. 2058 Security-parameters 2060 salt 2062 IV for this specific block 2064 Security-result 2066 key information 2068 encapsulated block 2070 Subsequent ESBs MUST contain a correlator value to link them to the 2071 first ESB. Security-source and security-destination are implied from 2072 the first ESB, however see the discussion below concerning eid-list 2073 entries. They MUST contain security-parameters and security-result 2074 fields as follows: 2076 Security-parameters 2078 IV for this specific block 2080 Security-result 2082 encapsulated block 2084 The security-parameters and security-result fields in the subsequent 2085 ESBs MUST NOT contain any items other than these two. Items such as 2086 key and salt are supplied in the first ESB and MUST NOT be repeated. 2088 Protection of the key is performed as defined in the Key Management 2089 Specification [tbd]. Key management for this ciphersuite MUST 2090 support PKCSv2.1 rsaEncryption as specified in RFC 3370 [RFC3370] and 2091 MAY support other schemes. The output from the key management 2092 protection scheme ("key information") is placed in the security- 2093 result field of the first ESB. 2095 For each block to be protected, the entire original block is 2096 encapsulated in a "replacing" ESB. This replacing ESB is placed in 2097 the outgoing bundle in the same position as the original block. As 2098 mentioned above, this is one-for-one replacement and there is no 2099 consolidation of blocks or mixing of data in any way. 2101 The encryption process uses AES-GCM with the salt and key values from 2102 the first ESB, and an IV unique to this ESB. The process creates 2103 ciphertext for the entire original block, and an authentication tag 2104 for validation at the security destination. The authentication tag 2105 is appended to the ciphertext for the block and the combination is 2106 stored into the "encapsulated block" item in security-result. 2108 The replacing block, of course, also has the same correlator value as 2109 the first ESB with which it is associated. It also contains the 2110 block-specific IV in security-parameters, and the combination of 2111 original-block-ciphertext and authentication tag, stored as an 2112 "encapsulated block" item in security-result. 2114 The size of the GCM counter field limits the payload size to 2^39 - 2115 256 bytes, about half a terabyte. A future revision of this 2116 specification will address the issue of handling payloads in excess 2117 of this size. 2119 5. Key Management 2121 Since key management in delay tolerant networks is still a research 2122 topic we cannot provide much in the way of useful key management 2123 here. However, solely in order to support implementation and 2124 testing, implementations SHOULD support: 2126 - Long-term pre-shared-symmetric keys for the BAB-HMAC 2127 ciphersuite. 2129 - The use of well-known RSA public keys for PIB-RSA-SHA256 and 2130 PCB-RSA-AES128-PAYLOAD-PIB-PCB ciphersuites. 2132 Since endpoint IDs are URIs and URIs can be placed in X.509 [RFC3280] 2133 public key certificates (in the subjectAltName extension) 2134 implementations SHOULD support this way of distributing public keys. 2135 Implementations SHOULD NOT be very strict in how they process X.509 2136 though, for example, it would probably not be correct to insist on 2137 Certificate Revocation List (CRL) checking in many DTN contexts. 2139 Other than that, key management is for future study. 2141 6. Default Security Policy 2143 Every node serves as a Policy Enforcement Point insofar as it 2144 enforces some policy that controls the forwarding and delivery of 2145 bundles via one or more convergence layer protocol implementation. 2146 Consequently, every node SHALL have and operate according to its own 2147 configurable security policy, whether the policy be explicit or 2148 default. The policy SHALL specify: 2150 Under what conditions received bundles SHALL be forwarded. 2152 Under what conditions received bundles SHALL be required to 2153 include valid BABs. 2155 Under what conditions the authentication information provided in a 2156 bundle's BAB SHALL be deemed adequate to authenticate the bundle. 2158 Under what conditions received bundles SHALL be required to have 2159 valid PIBs and/or PCBs. 2161 Under what conditions the authentication information provided in a 2162 bundle's PIB SHALL be deemed adequate to authenticate the bundle. 2164 Under what conditions a BAB SHALL be added to a received bundle 2165 before that bundle is forwarded. 2167 Under what conditions a PIB SHALL be added to a received bundle 2168 before that bundle is forwarded. 2170 Under what conditions a PCB SHALL be added to a received bundle 2171 before that bundle is forwarded. 2173 The actions that SHALL be taken in the event that a received 2174 bundle does not meet the receiving node's security policy 2175 criteria. 2177 This specification does not address how security policies get 2178 distributed to nodes. It only REQUIRES that nodes have and enforce 2179 security policies. 2181 If no security policy is specified at a given node, or if a security 2182 policy is only partially specified, that node's default policy 2183 regarding unspecified criteria SHALL consist of the following: 2185 Bundles that are not well-formed do not meet the security policy 2186 criteria. 2188 The mandatory ciphersuites MUST be used. 2190 All bundles received MUST have a BAB which MUST be verified to 2191 contain a valid security result. If the bundle does not have a 2192 BAB, then the bundle MUST be discarded and processed no further; a 2193 bundle status report indicating the authentication failure MAY be 2194 generated. 2196 No received bundles SHALL be required to have a PIB; if a received 2197 bundle does have a PIB, however, the PIB can be ignored unless the 2198 receiving node is the PIB-dest, in which case the PIB MUST be 2199 verified. 2201 No received bundles SHALL be required to have a PCB; if a received 2202 bundle does have a PCB, however, the PCB can be ignored unless the 2203 receiving node is the PCB-dest, in which case the PCB MUST be 2204 processed. If processing of a PCB yields a PIB, that PIB SHALL be 2205 processed by the node according to the node's security policy. 2207 A PIB SHALL NOT be added to a bundle before sourcing or forwarding 2208 it. 2210 A PCB SHALL NOT be added to a bundle before sourcing or forwarding 2211 it. 2213 A BAB MUST always be added to a bundle before that bundle is 2214 forwarded. 2216 If a destination node receives a bundle that has a PIB-dest but 2217 the value in that PIB-dest is not the EID of the destination node, 2218 the bundle SHALL be delivered at that destination node. 2220 If a received bundle does not satisfy the node's security policy 2221 for any reason, then the bundle MUST be discarded and processed no 2222 further; in this case, a bundle deletion status report (see the 2223 Bundle Protocol [DTNBP]) indicating the failure MAY be generated. 2225 7. Security Considerations 2227 If a BAB ciphersuite uses digital signatures but doesn't include the 2228 security destination (which for a BAB is the next host), then this 2229 allows the bundle to be sent to some node other than the intended 2230 adjacent node. Because the BAB will still authenticate, the 2231 receiving node may erroneously accept and forward the bundle. When 2232 asymmetric BAB ciphersuites are used, the security destination field 2233 SHOULD therefore be included in the BAB. 2235 If a bundle's PIB-dest is not the same as its destination, then some 2236 node other than the destination (the node identified as the PIB-dest) 2237 is expected to validate the PIB security result while the bundle is 2238 en route. However, if for some reason the PIB is not validated, 2239 there is no way for the destination to become aware of this. 2240 Typically, a PIB-dest will remove the PIB from the bundle after 2241 verifying the PIB and before forwarding it. However, if there is a 2242 possibility that the PIB will also be verified at a downstream node, 2243 the PIB-dest will leave the PIB in the bundle. Therefore, if a 2244 destination receives a bundle with a PIB that has a PIB-dest (which 2245 isn't the destination), this may, but does not necessarily, indicate 2246 a possible problem. 2248 If a bundle is fragmented after being forwarded by its PIB-source but 2249 before being received by its PIB-dest, the payload in the bundle MUST 2250 be reassembled before validating the PIB security result in order for 2251 the security result to validate correctly. Therefore, if the PIB- 2252 dest is not capable of performing payload reassembly, its utility as 2253 a PIB-dest will be limited to validating only those bundles that have 2254 not been fragmented since being forwarded from the PIB-source. 2255 Similarly, if a bundle is fragmented after being forwarded by its 2256 PIB-source but before being received by its PIB-dest, all fragments 2257 MUST be received at that PIB-dest in order for the bundle payload to 2258 be able to be reassembled. If not all fragments are received at the 2259 PIB-dest node, the bundle will not be able to be authenticated, and 2260 will therefore never be forwarded by this PIB-dest node. 2262 Specification of a security-destination other than the bundle 2263 destination creates a routing requirement that the bundle somehow be 2264 directed to the security-destination node on its way to the final 2265 destination. This requirement is presently private to the 2266 ciphersuite, since routing nodes are not required to implement 2267 security processing. 2269 8. IANA Considerations 2271 None at this time. If the bundle protocol becomes a standards track 2272 protocol, then we may want to consider having IANA establish a 2273 register of block types, and in particular for this specification a 2274 separate register of ciphersuite specifications. 2276 9. References 2278 9.1. Normative References 2280 [DTNBP] Scott, K. and S. Burleigh, "Bundle Protocol 2281 Specification", RFC 5050, November 2007. 2283 [DTNMD] Symington, S., "Delay-Tolerant Networking Metadata 2284 Extension Block", 2285 draft-irtf-dtnrg-bundle-metadata-block-00.txt , June 2007. 2287 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2288 Hashing for Message Authentication", RFC 2104, 2289 February 1997. 2291 [RFC2119] Bradner, S. and J. Reynolds, "Key words for use in RFCs to 2292 Indicate Requirement Levels", RFC 2119, October 1997. 2294 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 2295 X.509 Public Key Infrastructure Certificate and 2296 Certificate Revocation List (CRL) Profile", RFC 3280, 2297 April 2002. 2299 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 2300 Algorithms", RFC 3370, August 2002. 2302 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 2303 RFC 3852, July 2004. 2305 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 2306 Algorithms and Identifiers for RSA Cryptography for use in 2307 the Internet X.509 Public Key Infrastructure Certificate 2308 and Certificate Revocation List (CRL) Profile", RFC 4055, 2309 June 2005. 2311 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 2312 (GCM) in IPsec Encapsulating Security Payload (ESP)", 2313 RFC 4106, June 2005. 2315 9.2. Informative References 2317 [DTNRB] Symington, S., "Delay-Tolerant Network Retransmission 2318 Block", 2319 draft-irtf-dtnrg-bundle-retrans-00.txt, work-in-progress, 2320 April 2007. 2322 [DTNarch] Cerf, V., Burleigh, S., Durst, R., Fall, K., Hooke, A., 2323 Scott, K., Torgerson, L., and H. Weiss, "Delay-Tolerant 2324 Network Architecture", RFC 4838, April 2007. 2326 [DTNsecOver] 2327 Farrell, S., Symington, S., Weiss, H., and P. Lovell, 2328 "Delay-Tolerant Networking Security Overview", 2329 draft-irtf-dtnrg-sec-overview-04.txt, work-in-progress, 2330 February 2008. 2332 [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated 2333 Encryption in the Cryptographic Message Syntax (CMS)", 2334 RFC 5084, November 2007. 2336 Authors' Addresses 2338 Susan Flynn Symington 2339 The MITRE Corporation 2340 7515 Colshire Drive 2341 McLean, VA 22102 2342 US 2344 Phone: +1 (703) 983-7209 2345 Email: susan@mitre.org 2346 URI: http://mitre.org/ 2348 Stephen Farrell 2349 Trinity College Dublin 2350 Distributed Systems Group 2351 Department of Computer Science 2352 Trinity College 2353 Dublin 2 2354 Ireland 2356 Phone: +353-1-608-1539 2357 Email: stephen.farrell@cs.tcd.ie 2359 Howard Weiss 2360 SPARTA, Inc. 2361 7110 Samuel Morse Drive 2362 Columbia, MD 21046 2363 US 2365 Phone: +1-443-430-8089 2366 Email: hsw@sparta.com 2368 Peter Lovell 2369 SPARTA, Inc. 2370 7110 Samuel Morse Drive 2371 Columbia, MD 21046 2372 US 2374 Phone: +1-443-430-8052 2375 Email: peter.lovell@sparta.com