idnits 2.17.1 draft-burleigh-dtnwg-dtka-01.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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 2, 2018) is 2218 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) == Missing Reference: 'Node ID' is mentioned on line 801, but not defined == Missing Reference: 'KIM' is mentioned on line 415, but not defined == Missing Reference: 'KAx' is mentioned on line 671, but not defined == Outdated reference: A later version (-31) exists of draft-ietf-dtn-bpbis-10 == Outdated reference: A later version (-27) exists of draft-ietf-dtn-bpsec-06 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Burleigh 3 Internet-Draft D. Horres 4 Intended status: Standards Track JPL, Calif. Inst. Of Technology 5 Expires: September 3, 2018 K. Viswanathan 6 M. Benson 7 F. Templin 8 Boeing Research & Technology 9 March 2, 2018 11 Architecture for Delay-Tolerant Key Administration 12 draft-burleigh-dtnwg-dtka-01.txt 14 Abstract 16 Delay-Tolerant Key Administration (DTKA) is a system of public-key 17 management protocols intended for use in Delay Tolerant Networking 18 (DTN). This document outlines a DTKA proposal for space-based 19 communications, which are characterized by long communication delays 20 and planned communication contacts. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 3, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Motivation and Design Strategy . . . . . . . . . . . . . 3 58 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.3. About This Document . . . . . . . . . . . . . . . . . . . 3 60 1.4. Related Documents . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. High Level Architecture . . . . . . . . . . . . . . . . . . . 5 63 3.1. Application Domains . . . . . . . . . . . . . . . . . . . 6 64 3.2. System Entities . . . . . . . . . . . . . . . . . . . . . 6 65 3.3. System Interconnections . . . . . . . . . . . . . . . . . 7 66 3.4. Architectural Assumption on Communication . . . . . . . . 8 67 3.5. System Security Configuration . . . . . . . . . . . . . . 9 68 4. Detailed Design . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.1. Message Formats . . . . . . . . . . . . . . . . . . . . . 9 70 4.2. Non-receipt of a Bulletin . . . . . . . . . . . . . . . . 12 71 4.3. Node Registration . . . . . . . . . . . . . . . . . . . . 13 72 4.4. Key Revocation . . . . . . . . . . . . . . . . . . . . . 14 73 4.5. Key Roll-over . . . . . . . . . . . . . . . . . . . . . . 15 74 4.6. Key Endorsement . . . . . . . . . . . . . . . . . . . . . 16 75 4.7. Key Distribution . . . . . . . . . . . . . . . . . . . . 17 76 4.8. Secure Communications . . . . . . . . . . . . . . . . . . 18 77 4.9. Communication Stack View . . . . . . . . . . . . . . . . 19 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 19 82 7.2. Informative References . . . . . . . . . . . . . . . . . 20 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 85 1. Introduction 87 Delay-Tolerant Key Administration (DTKA) is a system of public-key 88 management protocols intended for use in Delay Tolerant Networking 89 (DTN) [RFC4838]. This document outlines a DTKA proposal for space- 90 based communications, which are characterized by long communication 91 delays and planned communication contacts. The proposal satisfies 92 the requirements for DTN Security Key Management 93 [I-D.templin-dtnskmreq]. 95 1.1. Motivation and Design Strategy 97 In general, on-demand interactive communications, like client-server 98 interactions, are not feasible in DTN's network model. Terrestrial 99 public-key management protocols require on-demand interactions with 100 remote computing nodes to distribute and validate public-keys. For 101 example, terrestrial public-key management protocols require on- 102 demand interactions with a remote trusted authority (Certificate 103 Revocation List (CRL)) to determine if a given public-key certificate 104 has been revoked or not. Therefore, such terrestrial public-key 105 management protocols cannot be used in DTN. 107 Periodic and planned communications are an inherent property of 108 space-based communication systems. Thus, the core principle of DTKA 109 is to exploit this property of space-based communication systems in 110 order to avoid the need for on-demand interactive communications for 111 key management. Therefore, the design strategy for DTKA is to pro- 112 actively distribute authenticated public-keys to all nodes in a given 113 DTN instance in advance to ensure that keys will be available when 114 needed even if there may be significant delays or disruptions. This 115 design strategy is to be contrasted with protocols for terrestrial 116 Public-Key Infrastructures, in which authenticated public-keys are 117 exchanged interactively, just-in-time and on demand. 119 1.2. Scope 121 DTKA was originally designed for space-based DTN environments, but it 122 could potentially be used in terrestrial DTN environments as well. 124 1.3. About This Document 126 This document describes the high-level architecture of DTKA and lists 127 the architectural entities, their interactions, and system 128 assumptions. 130 1.4. Related Documents 132 The following documents provide the necessary context for the high- 133 level design described in this document. 135 RFC 4838 [RFC4838] describes the architecture for DTN and is 136 titled, "Delay-Tolerant Networking Architecture." That document 137 provides a high-level overview of DTN architecture and the 138 decisions that underpin the DTN architecture. 140 RFC 5050 [RFC5050] describes the protocol and message formats for 141 DTN and is titled, "Bundle Protocol Specification." That document 142 provides the format of the network protocol message for DTN, 143 called a Bundle, along with descriptions of processes for 144 generating, sending, forwarding, and receiving Bundles. It also 145 specifies an encoding format called SDNV (Self-Delimiting Numeric 146 Values) for use in DTN. Each bundle comprises a primary block, a 147 payload block, and zero or more additional extension blocks. A 148 node may receive and process a bundle even when the bundle 149 contains one or more extension blocks that the node is not 150 equipped to process. 152 RFC 6257 [RFC6257] is titled, "Bundle Security Protocol 153 Specification." It specifies the message formats and processing 154 rules for providing three types of security services to bundles, 155 namely: confidentiality, integrity, and authentication. It does 156 not specify mechanisms for key management. Rather, it assumes 157 that cryptographic keys are somehow in place and then specifies 158 how the keys shall be used to provide the security services. 159 Additionally, it attempts to standardize a default cipher suite 160 for DTN. 162 The revised Internet Draft [I-D.ietf-dtn-bpsec] for DTN 163 communication security is titled, "Bundle Security Protocol 164 Specification (bpsec)." When compared with RFC 6257, it is silent 165 on concepts such as Security Regions, at-most-once-delivery 166 option, and cipher suite specification. It deletes the Bundle 167 Authentication Block and generalized the Payload Integrity and 168 Payload Confidentiality Blocks to Block Integrity Block and Block 169 Confidentiality Block. It provides more detailed specification 170 for bundle canonicalization and rules for processing bundles 171 received from other nodes. Like RFC 6257, the draft does not 172 describe any key management mechanisms for DTN but assumes that a 173 suitable key management mechanism shall be in place. 175 5050bis [I-D.ietf-dtn-bpbis] is an Internet Draft on standards 176 track that intends to update RFC 5050. It introduces a new 177 concept called "node ID" as distinguished from the existing 178 concept of "endpoint ID": a single DTN endpoint may contain one or 179 more nodes. It also migrates some primary block fields into 180 extension blocks, making the primary block immutable. In the 181 Security Considerations section, 5050bis explicitly describes end- 182 to-end security using Block-Integrity-Block (BIB) and Block- 183 Confidentiality-Block (BCB). It does not specify link-by-link 184 security considerations to be part of the bundle protocol level 185 using the Bundle-Authenticity-Block (BAB), which was described in 186 RFC 6257. The convergence layers may provide link-by-link 187 authentication instead of bundle protocol agent. 189 The Internet Draft for specifying requirements for DTN Key 190 Management [I-D.templin-dtnskmreq] is titled, "DTN Security Key 191 Management - Requirements and Design." It sketches nine 192 requirements and four design criteria for DTN Key Management 193 system. The last two requirements are the need to support 194 revocation in a delay tolerant manner. It also specifies the 195 requirements for avoiding single points of failure and 196 opportunities for the presence of multiple key management 197 authorities. 199 2. Terminology 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 202 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 203 this document are to be interpreted as described in [RFC2119]. Lower 204 case uses of these words are not to be interpreted as carrying 205 RFC2119 significance. 207 3. High Level Architecture 209 +---------+ +-----------+2.ListOfAuthenticated +------+ 210 |Key |1.(NodeID, Key)| Key |(Node ID, Key) | Key | 211 |Owner +---------------> Authority +----------------------> User | 212 |(Node ID)| | | | | 213 +---^-----+ +-----------+ +---^--+ 214 | 3.Secure Communications | 215 +------------------------------------------------------------+ 217 Figure 1: Abstract Data-Flow-Diagram for DTKA 219 The DTKA system includes Key Owners, Key Agents (which, in aggregate, 220 constitute the Key Authority), and Key Users. For the sake of 221 simplicity and to promote conceptual clarity, Figure 1 shows a single 222 Key Agent. In order to avoid a single point-of-trust, DTKA provides 223 mechanisms to distribute the Key Authority function among one or more 224 DTKA Key Agents using an erasure-coding technique. This trust- 225 distributing mechanism is discussed later in this document. 227 Each Key Owner has a unique DTN Node ID and chooses its own public- 228 private key pair. In order to associate a public-key (Key) with its 229 Node ID, a Key Owner sends an assertion of the form: (Node ID, Key) 230 to the Key Authority. Key Owners need to authenticate their 231 respective keys in one of two ways: 233 1. in the case of out-of-band bootstrapping, Key Authority shall 234 rely on the physical security of the out-of-band channel to 235 validate the integrity of the received message and the Key Owner 236 needs to sign the association (Node ID, Key) using the private 237 key corresponding to the Key. Association realized using such an 238 interaction will be called Out-of-band-authentication (OOBAuth); 239 or, 241 2. in the case of in-band authentication, the Key Owner or a trusted 242 third-party needs to sign the association (Node ID, Key) using 243 the private key corresponding to the previously authenticated and 244 currently effective public-key for that NodeID. If the Key Owner 245 signs the association, there will be roll-over association. If a 246 trusted third-party signs the association, the association will 247 have the type endorse so as to indicate an endorsement. 249 Each Key User periodically receives a list of authenticated public- 250 keys from the Key Authority and uses the authenticated public-keys as 251 needed. 253 3.1. Application Domains 255 DTN can be used in various theatres such as space, airspace, on earth 256 and at sea. There can be more than one installation of DTN in each 257 of these theatres administered by different administrative entities, 258 which may represent countries, companies and institutions. A 259 particular installation of DTN with a single aggregate key authority 260 is called an Application Domain. 262 3.2. System Entities 264 The architectural elements of DTKA, which shall henceforth be called 265 DTKA Entities, are listed below. 267 DTKA Key Agent (DTKA-KA) 268 DTKA-KA is part of the root of trust for authenticated 269 distribution of public-keys for a given application domain. All 270 DTKA Entities must have physically authenticated public-keys of 271 all DTKA Key Agents (DTKA-KAs), which together constitute the DTKA 272 Key Authority for a given application domain. 274 DTKA Key Owner[Node ID] (DTKA-KO[Node ID]) 275 DTKA-KO[Node ID] is a computing node that has possession of the 276 private key corresponding to the public-key authenticated for a 277 given Node Identity (Node ID) by the DTKA-KAs for the Key Owner's 278 application domain. 280 DTKA Key User (DTKA-KU) 281 DTKA-KU is a computing node that receives authenticated public- 282 keys from DTKA-KAs and distributes the same within a single 283 computing machine through a suitable Interprocess Communication 284 mechanism, which is outside the scope of this document. 286 DTKA Key Manager (DTKA-KM) and DTKA Key Manager Client (DTKA-KMC) 287 DTKA-KM is a DTKA Key User that receives authenticated public-keys 288 from DTKA-KAs and distributes the same over a communication 289 network to DTKA-KMCs, which are not DTKA Entities. DTKA-KMC can 290 be a DTN node that can receive key distributions from DTKA KMs. 291 The communication and security protocols for the interactions 292 between DTKA-KMs and DTKA-KMCs are outside the scope of this 293 document. 295 3.3. System Interconnections 297 ++ ++ 298 ++ +----------------------------------------------------------+ ++ 299 ++ Sub-second One-Way-Light-Time (OWLT) and Rarely Disrupted Link ++ 300 ++ +----------^--------------------------------------^--------+ ++ 301 ++ | | ++ 302 +-------v-------+ +-------v-------+ 303 | DTKA Entity | | DTKA Entity | 304 | | | | 305 | +-----------+ | | +-----------+ | 306 | | DTKA Key | | .................... | | DTKA Key | | 307 | | Agent | | | | Agent | | 308 | +-----------+ | | +-----------+ | 309 | +-----------+ | | +-----------+ | 310 | | TSM | | | | TSM | | 311 | +-----------+ | | +-----------+ | 312 +-------^-------+ +-------^-------+ 313 ++ | | ++ 314 ++ +----------v--------------------------------------v--------+ ++ 315 ++ Communication Link with Delay and Disruptions ++ 316 ++ +----------^--------------------------------------^--------+ ++ 317 ++ | | ++ 318 +-------v-------+ +-------v-------+ 319 | DTKA Entity | | DTKA Entity | 320 | | | | 321 | +-----------+ | | +-----------+ | 322 | | DTKA Key | | | | DTKA Key | | 323 | | Owner | | | | User | | 324 | +-----------+ | | +-----------+ | 325 | +-----------+ | | +-----------+ | 326 | |Autonomous | | | |Autonomous | | 327 | |Clock | | | |Clock | | 328 | +-----------+ | | +-----------+ | 329 +---------------+ +---------------+ 331 Figure 2: DTKA System Interconnections 333 Figure 2 depicts the system level interconnections that are assumed 334 for the design of DTKA. An application domain can have one or more 335 DTKA-KAs, all of which must be interconnected using a sub-second One- 336 Way-Light-Time (OWLT) and rarely disrupted link. Such communication 337 link can be realized using terrestrial Internet or specialized point- 338 to-point space communication techniques. This link shall be used by 339 the DTKA-KAs to synchronize between themselves. The DTKA-KAs shall 340 run a reliable Time Synchronization Mechanism (TSM), like the Network 341 Time Protocol (NTP) service. TSM shall ensure that time is 342 synchronized between the DTKA-KAs that realize the DTKA Key Authority 343 for a given application domain. 345 A potentially delayed and frequently disrupted communication link is 346 assumed to interconnect DTKA-KAs, DTKA-KOs and DTKA-KUs. This 347 delayed-and-disrupted communication link is used by the DTKA-KAs to 348 multicast authenticated public-key associations to DTKA-KUs. The 349 DTKA-KUs are assumed to have access to autonomous clocks. Autonomous 350 clocks keep time without external correction signals and with an 351 allowed drift in the order of a few seconds. But, delay-tolerant 352 mechanisms for clock agreement such as issuance of UTC offsets in 353 network management messages may be present. 355 3.4. Architectural Assumption on Communication 357 In the subsequent sections, it shall be seen that DTKA-KAs shall 358 dispatch updates to the list of authenticated public-keys in the 359 system using erasure coding techniques. It is evident that at least 360 a sub-set of such communications updates must reach each DTKA-KU. 361 Therefore, the DTN upon which the DTKA operates must satisfy the 362 following communication assumption before DTKA can function along 363 expected lines: all addressed receivers MUST receive sufficient 364 number of bundles from the DTKA-KAs before the earliest effective 365 time among the effective times of all public-key associations in the 366 payloads of the bundles. Note that the underlying DTN will not be 367 aware of the effective times of the public-key associations in the 368 payloads of the bundles. 370 The above assumption can be restated using DTKA protocol 371 terminologies, which shall be seen in the subsequent sections, as 372 follows: All addressed receivers MUST receive enough of the code 373 blocks for a given bulletin to enable reassembly of that bulletin 374 before the earliest effective-time among all associations in the 375 bulletin. 377 3.5. System Security Configuration 379 The current public-keys of all designated DTKA-KAs for a given 380 application domain must be securely configured into every DTKA-KA and 381 DTKA-KU that needs to participate in that application domain; this is 382 a pre-condition for initializing those DTKA-Entities. This process 383 will ensure that the DTKA Agents are established as the root of trust 384 for that application domain. 386 4. Detailed Design 388 4.1. Message Formats 390 Every DTKA-KA in an application domain will receive requests for 391 associating public-keys with Node IDs from the respective DTKA-KOs. 392 After authenticating the requests and any pending revocations (as 393 described in Section 4.4 below), every DTKA-KA reaches consensus with 394 all other DTKA-KAs, which constitute the Key Authority in its 395 application domain, on some subset of the authenticated requests and 396 revocations. The protocols and algorithms for DTKA-KA consensus is 397 an implementation aspect and out-of-scope of this document. After 398 each successful consensus, each DTKA-KA must increment its local 399 value called Bulletin Serial Number (BSN) and agree on the Trust 400 Model Number (TMN) for the bulletin. Thereafter, each DTKA-KA must 401 independently multicast to all participating DTKA Entities the subset 402 of authenticated list of address-and-key associations on which 403 consensus was reached along with the new BSN value. The message 404 format for this multicast, which is called a Bulletin, supports 405 message authentication and redundancy. The goal of message 406 authentication is to prevent DTKA Entities' acceptance of malicious 407 multicast messages issued by hostile nodes. The goal of message 408 redundancy is to ensure that a minimal set of collaborating DTKA-KAs 409 in the application domain will be able to successfully send out-of- 410 band-authentication (OOBAuth) or revocations for address-and-key 411 associations to all DTKA Entities -- the DTKA Entities need not know 412 which DTKA-KAs are not collaborating. 414 As mentioned previously, bulletin is a collection of association 415 blocks (or Key Information Message [KIM] data structure) such that 416 each association block represents a single association of a Node ID 417 with a public-key as depicted in Figure 3. Each block issues either 418 an out-of-band-authentication (OOBAuth) or endorse or revoke or roll- 419 over instruction to the receiving DTKA Entities, which use the key 420 information message to execute the instruction locally. The 421 semantics for each of the instruction shall be described in 422 subsequent sections. The block labelled "Bulletin Hash" contains the 423 cryptographic hash computed over all association blocks (key 424 information messages), the Bulletin Serial Number (BSN) and the Trust 425 Model Number (TMN) in that bulletin. The BSN is a unique and 426 sequential bulletin identifier. The TMN is a unique identifier to 427 indicate the trust model configuration that is to be used to validate 428 this bulletin. The trust model configuration can be seen as a list 429 of DTKA-KAs (Key Agents), who are trusted to authenticate this 430 bulletin to all DTKA Users in the system. The trust model 431 configuration is also used to indicate the t-out-of-n threshold 432 configuration that shall be described in the next paragraph. The 433 precise syntax for the trust model configuration is a DTKA-KA 434 implementation aspect and, is therefore, out-of-scope of this 435 document. 437 +--------+--------+---+---+----------------------------------------+ +---+ 438 |Bulletin|Bulletin|TMN|BSN|Key information message (KIM): | | | 439 | |hash | | |{([Node ID, Effective Time, Public Key],|..|KIM| 440 | | | | | OOBAuth/endorse/revoke/roll_over)} | | | 441 +--------+--------+---+---+----------------------------------------+ +---+ 443 Figure 3: Bulletin 445 After forming a bulletin, a (Q+k)-erasure code algorithm is used to 446 create an erasure code for the bulletin. Thus, receipt of any Q 447 distinct code blocks will be sufficient to decode the bulletin. To 448 ensure that the incapacity or compromise -- or veto (disagreement on 449 bulletin content) -- of any single DTKA-KA will not result in 450 malfunction of the key authority mechanism, each DTKA-KA is assigned 451 primary responsibility for transmission of some limited subset of the 452 bulletin's code blocks and backup responsibility for some other 453 limited subset. The assigned code block subsets for the various 454 DTKA-KAs are selected in such a way that every code block is to be 455 transmitted by two different DTKA-KAs. The combination of these two 456 transmission redundancy mechanisms (parity code blocks and duplicate 457 transmissions), together with reliable bundle transmission at the 458 convergence layer under bundle multicast, minimizes the likelihood of 459 any client node being unable to reconstruct the bulletin from the 460 code blocks it receives. 462 During system initialization, the code-block assignments for each 463 DTKA-KA need to be configured into every DTKA Entity. The code-block 464 assignment for the example considered in this section is shown below 465 in the table, in which an x-mark depicts the assignment of a code 466 block to a DTKA-KA. It can be seen in the table that, in this 467 example, code-blocks from at least five (t=5) DTKA-KAs must be 468 received before the bulletin blocks can be decoded. Also, when all 469 DTKA-KAs multicast their pre-defined code blocks, n * m (8*3 = 24) 470 code blocks are sent to all DTKA Entities. To further defend against 471 a compromised DTKA-KA node introducing error into the key 472 distribution system: 474 o All nodes are informed of the code block subsets for which all 475 DTKA-KA nodes are responsible. Any received code block that was 476 transmitted by a DTKA-KA node which was not responsible for 477 transmission of that code block is discarded by the receiving 478 node. 480 o Each code block issued by the each KA is signed under that KA's 481 private key. The bulletin hash in the code block uniquely 482 identifies the bulletin that will be reconstructed using this code 483 block. Every transmitted code block is accompanied by the 484 bulletin hash. All - and only - code blocks tagged with the 485 unique bulletin hash are reassembled into the bulletin identified 486 by that hash. 488 o If the hash of a bulletin reassembled from a set of received code 489 blocks is not verified then, for each the DTKA-KA node that 490 transmitted one or more of the constituent code blocks, all code 491 blocks transmitted by that node are excluded from the reassembled 492 bulletin. Upon success, the node whose transmitted code blocks 493 had been excluded from the reassembled bulletin may be presumed to 494 be compromised. 496 +-----------------------------------+---+---+---+---+---+---+---+---+ 497 | Code Block Numbers (0 to (Q + k | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 498 | -1)) | | | | | | | | | 499 +-----------------------------------+---+---+---+---+---+---+---+---+ 500 | KA 1 | x | x | x | | | | | | 501 | KA 2 | | x | x | x | | | | | 502 | KA 3 | | | x | x | x | | | | 503 | KA 4 | | | | x | x | x | | | 504 | KA 5 | | | | | x | x | x | | 505 | KA 6 | | | | | | x | x | x | 506 | KA 7 | x | | | | | | x | x | 507 | KA 8 | x | x | | | | | | x | 508 +-----------------------------------+---+---+---+---+---+---+---+---+ 510 Table 1: Example Trust-Table: Code Blocks Assignments for Key Agents 512 The message format for transmitting the assigned code-blocks by each 513 DTKA-KA is shown in Figure 4. Note that each such message is the 514 payload of a Bundle and that the authenticity of that payload is 515 nominally protected by a Block Integrity Block containing a digital 516 signature computed in the private key of the issuing Key Agent; the 517 message itself contains no self-authentication material. Reading the 518 figure left to right, we have: (a) a field indicating the type of 519 this message, namely Bulletin code block; (b) the bulletin hash as 520 defined in Figure 3; (c) the trust model number that provides trust- 521 table configuration as depicted in Table 1; (d) the code-block 522 numbers (column numbers in the trust-table) for which code-blocks are 523 available in this code block message; and, (e) the specified code- 524 blocks from the DTKA-KA. The identity of the DTKA-KA (KAx) that 525 generated the code blocks must be available as the source node ID of 526 the DTN bundle that carried this code block message. KAx is used to 527 validate the signature in the bundle's Block Integrity Block before 528 the message is delivered to DTKA by the underlying DTN protocol 529 layer. 531 +----------+----------+---+-----------+------------+ 532 | Bulletin | Bulletin |TMN| Code Block| Code Blocks| 533 | Codeblock| Hash | | Numbers | | 534 +----------+----------+---+-----------+------------+ 536 Figure 4: Message Format for Code Blocks 538 4.2. Non-receipt of a Bulletin 540 When a DTKA Entity receives sufficient number of bulletin blocks from 541 the DTKA Key Agents, it can reconstruct the corresponding bulletin 542 with its unique Bundle Serial Number (BSN) in the format depicted in 543 Figure 3. By maintaining a historical list of successfully 544 reconstructed BSN values and analysing for gaps in the BSN historical 545 list, a DTKA Entity can detect non-receipt of past bulletins. Upon 546 such a detection, the DTKA Entity must send a request to all the DTKA 547 Key Agents in the format specified in Figure 5 in order to request 548 retransmission of the past bulletins for a given BSN value. When 549 such request is received by a DTKA Key Agent, the DTKA Key Agent must 550 retransmit its code blocks corresponding to the requested BSN only to 551 the requesting DTKA Entity in the format shown in Figure 4. The 552 security for this communication from the DTKA Key Agents must be 553 similar to the security for the bulletin broadcast communication. 554 Upon receiving sufficient number of bulletin blocks for the requested 555 bulletin, the requesting DTKA Entity may reconstruct the bulletin and 556 verify that the bulletin with the requested BSN has indeed been 557 received. Thereupon, the DTKA Entity must update its BSN historical 558 list with the received BSN value. 560 +----------+-----------+---------------+-------+ 561 | Bulletin | Request | Requesting |List | 562 | Request | Timestamp | Node (Node ID)|of BSNs| 563 +----------+-----------+---------------+-------+ 565 Figure 5: Message Format for Requesting Retransmission of Bulletin 567 4.3. Node Registration 569 In order to register a new DTKA-KO in the system, DTKA requires the 570 DTKA-KO with a Node ID (DTKA-KO[Node ID]) to generate a public- 571 private key pair and preserve the secrecy of its private key. The 572 DTKA-KO[Node ID] needs to generate an association message of the form 573 (Node ID, effective-time, public-key), where effective-time specifies 574 the start time after which the public-key is valid. That is, each 575 bundle sent by this node is to be authenticated using the node's most 576 recently effective public key whose effective time is less than the 577 bundle's creation time. The DTKA-KO[Node ID] must send the 578 association message, along with a signature on the message using its 579 private key, to the DTKA-KA as depicted in Figure 6. Since DTKA-KA 580 would not have seen the association of the public-key to that key 581 owner previously, it cannot trust that the message indeed originated 582 from DTKA-KO[Node ID]. Therefore, for registration purposes, this 583 initial message from the DTKA-KO[Node ID] to the DTKA-KA MUST be 584 protected by transmitting it over an independently (e.g., physically) 585 authenticated channel. The independently authenticated channel can 586 be realized by physically securing the access to the DTKA-KA server, 587 using a physical communication medium, such as a USB dongle, and 588 manually verifying the authenticity of the communication from the 589 DTKA-KO. The manual verification is a one-time process for a given 590 Key Owner. When an application domain has more than one DTKA-KA 591 (KAx), the message from DTKA-KO[Node ID] must be sent to each DTKA-KA 592 (KAx) in a similarly secure manner. 594 Although the messages to DTKA-KA (KAx) are independently 595 authenticated, the DTKA-KO[Node ID] must sign the association message 596 using its private key. The signature is not intended to 597 cryptographically authenticate the message but only to prove to the 598 DTKA-KA that the DTKA-KO[Node ID] is indeed in possession of the 599 private key. This self-signed message by the DTKA-KO is useful to 600 ensure that the physical courier, which is used to realize the 601 physically authenticated channel, has not tampered the message sent 602 by the DTKA-KO to the DTKA-KA. Additionally, the self-signed message 603 is useful to audit the operations of the DTKA-KA. 605 +---------------------+ +---------------+ 606 | DTKA-KO[Node ID] | | DTKA-KA (KAx) | 607 +--------|------------+ +-------|-------+ 608 **|*******************************************|** 609 * | | * 610 * |{[Node ID, Effective Time, Public Key, s] | * 611 * | such that s = Sign(Private Key, [Node ID, | * 612 * | Effective Time, Public Key,...])} | * 613 * +-------------------------------------------> * 614 * | | * 615 * | Physically authenticated channel(USB,...) | * 616 **|*******************************************|** 617 | | 618 | +--+ 619 | TRUE = Verify(Public Key, s, [Node ID, | | 620 | Effective Time, Public Key,...]) | | 621 | +--> 622 | | 623 + + 625 Figure 6: Interaction Diagram 1: Node Registration 627 Each DTKA-KA will insert the received association message into its 628 next bulletin (refer to Figure 3), for multicast as an out-of-band- 629 authentication (OOBAuth) association: when registration is received 630 through a physically authenticated channel. The bulletin will be 631 multicast to all DTKA Entities using the protocol described in 632 Section 4.7. 634 As an alternative to the use of a physically authenticated channel, 635 the registration association message may be sent by a trusted third- 636 party node whose authenticated public key is already registered and 637 known to all DTKA-KAs, so that the message may be authenticated by 638 verifying the digital signature (formed using the trusted third-party 639 node's current private key) in the BIB of the bundle containing the 640 message. Each DTKA-KA will insert such association requests in its 641 next bulletin for multicast as an endorsed association by tagging the 642 corresponding Key Information message in the bulletin as "endorse" 643 (refer to Figure 3). The bulletin will be multicast to all DTKA 644 Entities using the protocol described in Section 4.7. 646 4.4. Key Revocation 648 Manual decisions trigger the key revocation procedure. Every DTKA-KA 649 in an application domain is assumed to have a human operator who can 650 trigger the revocation process. When a key is to be revoked, the 651 human operator will need to authenticate to the respective DTKA-KA 652 (KAx) server, identify the public-key and Node ID to be revoked, and 653 instruct that DTKA-KA (KAx) revocation software to schedule a 654 revocation message. The revocation software in DTKA-KA (KAx) will 655 multicast a message as shown in Figure 7. The process for sending 656 out the code-blocks by all the DTKA-KAs with this revocation 657 information is described in Section 4.1. 659 +---------+ +---------+ 660 | DTKA-KA | | DTKA-KA | 661 | (KAx) | | (KAy) | 662 +---|-----+ +---|-----+ 663 | | 664 | | 665 | Multicast{m , s such that | 666 | s = Sign(PrivateKey[KAx], m) and | 667 | m = [KAx, Revoke, [Node ID, Effective Time, Pub Key)]} | 668 +--------------------------------------------------------> 669 | | 670 | +--+ 671 | TRUE = Verify(Public Key[KAx], s, [Node ID, | | 672 | Effective Time, New Public Key,...]) | | 673 | +--> 674 | | 675 + + 677 Figure 7: Interaction Diagram 1.1: Key Revocation 679 4.5. Key Roll-over 681 When a DTKA-KO[Node ID] has been registered by the DTKA-KA using the 682 protocol described in Figure 6, the DTKA-KO[Node ID] can periodically 683 roll-over to a new public-private key pair by following the key roll- 684 over protocol described in Figure 8. The protocol for key roll-over 685 is similar to the one for key registration except that: (a) the 686 protocol can be executed using DTN bundles issued by the KO itself 687 without requiring any independently secured out-of-band communication 688 channels; and, (b) the old (current) public-key is used to 689 authenticate the association of the new public-key with the Node ID 690 for that DTKA KO. The DTKA-KO [Node ID] must send this message to 691 every key agent in its application domain. Upon accepting the roll- 692 over message from the DTKA-KO[Node ID], each key agent will schedule 693 the roll-over instruction for identified Node ID and public-key in 694 its next bulletin as described in Section 4.1. A DTKA-KO can 695 schedule any number of future roll-overs but the number of such roll- 696 over schedules may need to be limited to avoid Denial of Service 697 attacks by registered nodes -- but this topic is beyond the scope of 698 this document. 700 +---------------------+ +---------------+ 701 | DTKA-KO[Node ID] | | DTKA-KA (KAx) | 702 +--------|------------+ +-------|-------+ 703 | | 704 |{[Node ID, Effective Time, New Public Key, s] | 705 | such that s = Sign(Old Private Key, [Node ID, | 706 | Effective Time, New Public Key,...])} | 707 +-----------------------------------------------> 708 | | 709 | | 710 | +--+ 711 | TRUE = Verify(Old Public Key, s, [Node ID, | | 712 | Effective Time, New Public Key,...]) | | 713 | +--> 714 | | 715 + + 717 Figure 8: Interaction Diagram 1.2: Key Rollover 719 4.6. Key Endorsement 721 When a DTKA-KO[Node ID] is not registered and does not have access to 722 any out-of-band authentication channel with any DTKA-KA, the DTKA- 723 KO[Node ID] will need to have access to an out-of-band authentication 724 channel for a trusted third-party (TTP), which is registered with the 725 DTKA-KA. Upon receiving the (Node ID, Key, Effective time) 726 information from the DTKA-KO[Node ID] over the out-of-band 727 authentication channel, the trusted third-party needs to relay that 728 information to the DTKA-KA by signing the information under its 729 authenticated public key. This interaction is depicted in Figure 9. 730 Upon accepting the endorse message from the trusted third-party, each 731 key agent will schedule an endorse instruction for identified Node ID 732 and public-key in its next bulletin as described in Section 4.1. 734 +---------------------+ +---------------+ 735 |Trusted third-party | | DTKA-KA (KAx) | 736 +--------|------------+ +-------|-------+ 737 | | 738 |{[Node ID, Public Key, Effective Time, s] | 739 | such that s = Sign(TTP Private Key, [Node ID, | 740 | Public Key, Effective Time,...])} | 741 +-----------------------------------------------> 742 | | 743 | | 744 | +--+ 745 | TRUE = Verify(TTP Public Key, s, [Node ID, | | 746 | Effective Time, Public Key,...]) | | 747 | +--> 748 | | 749 + + 751 Figure 9: Interaction Diagram 1.3: Key Endorsement 753 4.7. Key Distribution 755 Each DTKA-KA collects multiple out-of-band-authentication (OOBAuth), 756 revocation, roll-over and endorse association messages from different 757 parties by following the protocols described in Section 4.3, 758 Section 4.4, Section 4.5 and Figure 9. Then, each DTKA-KA forms and 759 sends multicast communications for the code blocks for its bulletin 760 to all DTKA Key Users as explained in Section 4.1. The DTKA-KUs 761 verify the authenticity of each code block from all the DTKA-KAs 762 before using the code blocks to decode the bulletin, which will 763 contains out-of-band key authentication, key revocation, key roll- 764 over and endorse instructions. The DTKA-KUs perform these 765 instructions in their respective local key database. This 766 interaction between the DTKA-KAs and the DTKA-KUs of an application 767 domain is shown in Figure 10. 769 +-------------------+ +--------------+ 770 | DTKA-KA (KAx) | | DTKA-KU | 771 +---------+---------+ +--------+-----+ 772 | | 773 +-----------------------------------------------> 774 | Send(KAx, BulletinHash, CodeBlockNumber | 775 | CodeBlock of Bulletin such that Bulletin = | 776 | array[Node ID, Effective Time, PubKey]) | 777 | | 778 | +---+ 779 | Wait for code blocks | | 780 | from key authorities +---> 781 | | 782 | +---+ 783 | Decode Bulletin using code | | 784 | blocks from key authorities +---> 785 + + 787 Figure 10: Interaction Diagram 2: Bulk Key Distribution 789 4.8. Secure Communications 791 After receiving out-of-band-authentication (OOBAuth), roll-over or 792 endorse information, every DTKA-KU shall have authenticated public- 793 keys for different Node IDs in its local database. These 794 authenticated public-keys can be used to authenticate messages 795 received from the DTKA-KO[Node ID] and to send confidential messages 796 to the DTKA-KO[Node ID] after the specified effective-time for each 797 Node ID and public-key pair. This interaction is specified in 798 Figure 11. 800 +---------------------+ +--------------+ 801 | DTKA-KO[Node ID] | | DTKA-KU | 802 +--------+------------+ +--------+-----+ 803 |Secure communications | 804 |[Node ID, Creation Time, Signature, Data] | 805 +------------------------------------------> 806 | | 807 |Secure communications | 808 |[Node ID, Creation Time, Encrypted Data] | 809 <------------------------------------------+ 810 | | 811 + + 813 Figure 11: Interaction Diagram 3: Secure communication 815 4.9. Communication Stack View 817 DTKA is designed to be a special DTN application that shall perform 818 key management operations using the services of the Bundle Protocol 819 and BPSec. DTKA will use BP, which in turn will use BPSec to 820 authenticate the messages containing the public-keys that are 821 subsequently to be used by BPSec for securing future communications 822 as shown in Figure 12. 824 +-------------+---------+ +-------------------------------------+ 825 |Applications | DTKA +---> | 826 +-------------+---------+ | Local Keys Database | 827 |Bundle Protocol (BPSec)<---+(Node ID, Public Key, Effective Time)| 828 +-----------------------+ | | 829 | Convergence Layer | +-------------------------------------+ 830 +-----------------------+ 831 | Transport Layer | 832 +-----------------------+ 833 | Network Layer | 834 +------------------------+ 835 | Physical Layer | 836 +-----------------------+ 838 Figure 12: Block Diagram: Communication Stack View for DTKA 840 5. IANA Considerations 842 This document potentially contains IANA considerations depending on 843 the design choices adopted for future work. But, in its present 844 form, there are no immediate IANA considerations. 846 6. Security Considerations 848 Security issues and considerations are discussed through out this 849 document. 851 7. References 853 7.1. Normative References 855 [I-D.ietf-dtn-bpbis] 856 Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 857 Version 7", draft-ietf-dtn-bpbis-10 (work in progress), 858 November 2017. 860 [I-D.ietf-dtn-bpsec] 861 Birrane, E. and K. McKeever, "Bundle Protocol Security 862 Specification", draft-ietf-dtn-bpsec-06 (work in 863 progress), October 2017. 865 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 866 Requirement Levels", BCP 14, RFC 2119, 867 DOI 10.17487/RFC2119, March 1997, 868 . 870 7.2. Informative References 872 [I-D.templin-dtnskmreq] 873 Templin, F. and S. Burleigh, "DTN Security Key Management 874 - Requirements and Design", draft-templin-dtnskmreq-00 875 (work in progress), February 2015. 877 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 878 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 879 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 880 April 2007, . 882 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 883 Specification", RFC 5050, DOI 10.17487/RFC5050, November 884 2007, . 886 [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, 887 "Bundle Security Protocol Specification", RFC 6257, 888 DOI 10.17487/RFC6257, May 2011, 889 . 891 Authors' Addresses 893 Scott Burleigh 894 JPL, Calif. Inst. Of Technology 895 4800 Oak Grove Dr. 896 Pasadena, CA 91109-8099 897 USA 899 Email: Scott.Burleigh@jpl.nasa.gov 900 David Horres 901 JPL, Calif. Inst. Of Technology 902 4800 Oak Grove Dr. 903 Pasadena, CA 91109-8099 904 USA 906 Email: David.C.Horres@jpl.nasa.gov 908 Kapali Viswanathan 909 Boeing Research & Technology 910 Boeing International Corporation India Private Limited 911 A Block, 4th Floor, Lake View Building 912 Bagmane Tech Park, C.V. Raman Nagar 913 Bangalore, KA 560093 914 IN 916 Email: kapaleeswaran.viswanathan@boeing.com 918 Michael W. Benson 919 Boeing Research & Technology 920 The Boeing Company 921 499 Boeing Boulevard 922 Huntsville, AL 35824 923 USA 925 Email: michael.w.benson@boeing.com 927 Fred L. Templin 928 Boeing Research & Technology 929 P.O. Box 3707 930 Seattle, WA 98124 931 USA 933 Email: fltemplin@acm.org