idnits 2.17.1 draft-templin-dtnskmreq-00.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 : ---------------------------------------------------------------------------- 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 date (February 25, 2015) is 3347 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0791' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 489, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Intended status: Informational S. Burleigh 5 Expires: August 29, 2015 JPL, Calif. Inst. Of Technology 6 February 25, 2015 8 DTN Security Key Management - Requirements and Design 9 draft-templin-dtnskmreq-00.txt 11 Abstract 13 Delay/Disruption Tolerant Networking (DTN) introduces a network model 14 in which communications may be subject to long delays and/or 15 intermittent connectivity. These challenges render traditional 16 security key management mechanisms infeasible since round trip delays 17 may exceed the duration of communication opportunities. This 18 document therefore proposes requirements and outlines a design for 19 security key management in DTNs. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 29, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. DTN Security Key Management Core Requirements . . . . . . . . 4 58 3.1. REQ1: Must Provide Keys When Needed . . . . . . . . . . . 4 59 3.2. REQ2: Must Be Trustworthy . . . . . . . . . . . . . . . . 5 60 3.3. REQ3: No Single Point of Failure . . . . . . . . . . . . 5 61 3.4. REQ4: Multiple Points of Authority . . . . . . . . . . . 5 62 3.5. REQ5: No Veto . . . . . . . . . . . . . . . . . . . . . . 5 63 3.6. REQ6: Must Bind Public Key with DTN Node Identity . . . . 5 64 3.7. REQ7: Must Support Secure Bootstrapping of a Node's 65 Identity and its Public Key . . . . . . . . . . . . . . . 6 66 3.8. REQ8: Must Support Revocation . . . . . . . . . . . . . . 6 67 3.9. REQ9: Revocations Must Be Delay Tolerant . . . . . . . . 6 68 4. DTN Security Key Management Design Criteria . . . . . . . . . 6 69 4.1. DC1: Must Perform Timely Key Provisioning . . . . . . . . 6 70 4.2. DC2: Pub/Sub Model . . . . . . . . . . . . . . . . . . . 6 71 4.3. DC3: Publication Must Be Spread Over Multiple KAs . . . . 7 72 4.4. DC4: Availability and Security . . . . . . . . . . . . . 7 73 5. Candidate DTN Security Key Management Design . . . . . . . . 8 74 6. Limitations and Challenges . . . . . . . . . . . . . . . . . 9 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 10.2. Informative References . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 The Delay/Disruption Tolerant Network (DTN) architecture [RFC4838] 86 introduces a data communications concept in which "bundles" of data 87 are exchanged in store-and-forward fashion between endpoints that may 88 be separated by long-delay or intermittently-connected paths. The 89 Bundle Protocol Specification [RFC5050] provides the bundle message 90 format and operations, including convergence layer transmission, 91 fragmentation and custody transfer. Each bundle further may include 92 extensions, among which may be security parameters designed to ensure 93 confidentiality, integrity and authentication 94 [RFC6257][I-D.irtf-dtnrg-sbsp]. These securing mechanisms (termed 95 "Bundle Security Protocol") operate within the constraints imposed by 96 various "ciphersuites". Prominent among these are ciphersuites that 97 rely on public/private key pairs where the public key is used to 98 encrypt data and verify signatures while the private key is used to 99 decrypt data and sign messages. Like any other public/private key 100 system, however, Delay Tolerant Networks require some form of Public 101 Key Infrastructure (PKI) to ensure that private key holders are 102 properly authorized to use them as attested by a trusted Certificate 103 Authority (CA) [RFC4210]. 105 Public key cryptography in DTNs may be in some ways simpler than in 106 traditional Internet security approaches. In particular, some BSP 107 ciphersuites impose no need for peers to establish a long-term secret 108 "symmetric" session key to be applied across a stream of bundles in 109 the way that protocols such as the Internet Key Exchange (IKE) 110 [RFC5996] establish session keys to be applied across a stream of 111 packets. Instead, per the provisions of these ciphersuites, each 112 bundle carries its own secret symmetric key in which the bundle is 113 encrypted (in which case the symmetric key is itself encrypted in the 114 public key of the receiver) or by which the bundle is signed (in 115 which case the symmetric key is itself signed in the private key of 116 the sender). 118 While the operation of the DTN securing mechanisms themselves can be 119 applied independently of the key management scheme, in their current 120 incarnation they can only be used with pre-placed irrevocable keys 121 since there are no published mechanisms for automated security key 122 management. On the surface, the use of standard PKI mechanisms would 123 seem to be a natural fit, but traditional methods are not appropriate 124 for long-delay and/or disrupted paths. This issue has prompted 125 earlier IRTF investigations into an automated key management scheme 126 for DTN [I-D.farrell-dtnrg-km][I-D.irtf-dtnrg-sec-overview], and it 127 was also highlighted in "A Bundle of Problems" [WOOD08], Section 4.13 128 and "Security Analysis of DTN Architecture and Bundle Protocol 129 Specification for Space-Based Networks" [IVAN09]. 131 Therefore, an automated system for the publication and revocation of 132 public keys will be necessary for many DTN applications, and that 133 system must be designed to function in the presence of long delays 134 and/or intermittent connectivity. The system must provide timely 135 delivery of new public keys and security-key meta-data even though 136 the delay inherent in the system may result in actual conveyance to 137 DTN nodes long after transmission. Moreover the improper operation 138 of this system, whether caused by malfunction or by a deliberate 139 attack, could have significant impact on the usability of the 140 network; the system must therefore be highly resistant to operational 141 failure. In this document, we discuss the problem, provide 142 requirements and propose a design for a suitable solution. 144 2. Discussion 146 Traditional automated PKI key management protocols allow for a 147 subject (aka "end entity") to create a self-generated public/private 148 key pair and then register the public key with a trusted Certificate 149 Authority (CA) [RFC4210]. However, in a network based on DTN there 150 may be significant delays between the time at which an end entity 151 requests another entity's certificate and the time at which the 152 requested certificate is delivered. Also, issues such as the 153 publication of a new key pair can result in communication failures if 154 end entities do not discover the new public key until some time after 155 the old public key is deprecated. Alternatives such as a "web of 156 trust" (e.g., via Pretty Good Privacy (PGP) [RFC4880]) may have 157 application in some DTNs, but this is a topic for further study. 159 An old adage that also needs to be addressed is whether there is a 160 "one-size-fits-all" solution. DTNs may come in various shapes and 161 sizes, and various approaches may be better suited to some DTNs than 162 others. More specifically, in the future there may not be one "DTN" 163 in the same way that there is one public Internet. But rather, there 164 may be many DTNs for public or private use - each with its own 165 operational capabilities and constraints. 167 There will likely be ways to accomplish public key publication in the 168 presence of long delays and/or disruptions, since keys can be 169 published to take effect at some point in the future. However, 170 timely certificate revocation may be infeasible due to the long 171 delays inherent in many DTNs. DTN subjects therefore must be 172 vigilant in ascertaining the degree to which long-delay 173 correspondents can be trusted. These and many more issues must be 174 carefully considered in any design. 176 3. DTN Security Key Management Core Requirements 178 A number of fundamental requirements must be satisfied by any 179 security key management design for DTN. The requirements include the 180 following: 182 3.1. REQ1: Must Provide Keys When Needed 184 The practical significance of this requirement is that the DTN 185 security key management design must not rely on timely responses to 186 queries directed to a Public Key Infrastructure (PKI). Low-delay 187 online access using standard Internet connections (i.e., TCP/IP) may 188 never be available. Even if the query is submitted using some delay- 189 tolerant protocol, the opportunity to use the key to encrypt or 190 verify data may have ended by the time the key arrives. In short, 191 traditional PKIs are considered incompatible with DTN. 193 3.2. REQ2: Must Be Trustworthy 195 The design must be based on a trust anchor common to all nodes in the 196 DTN network. A common trust anchor is needed to ensure that all DTN 197 nodes will receive public keys from a secured key authority and not 198 from an anonymous source. In particular, DTN nodes cannot simply 199 accept public keys directly from one another with no prior trust 200 basis. Otherwise, the network and all devices that use it could be 201 compromised. The trust anchor should store and forward only 202 authentic public keys from DTKA Key Authorities in an authentic 203 manner so that the unavailability of DTKA Key Authorities will not 204 prevent or delay communications between any two DTN nodes. 206 3.3. REQ3: No Single Point of Failure 208 The design must not introduce a single point of failure; the system 209 must not fail in the event that one or more critical infrastructure 210 elements are damaged. In particular, DTN nodes cannot always depend 211 on receiving information from any single key authority node, since 212 that node may not always be reachable over the network, may be 213 subject to failures such as power outages, or may be compromised by 214 an attacker. Much like the way RAID disc arrays operate, the system 215 must be resilient to one or more failures. 217 3.4. REQ4: Multiple Points of Authority 219 The design must not introduce a single point of authority that could 220 degrade the entire network if hijacked by an attacker. In 221 particular, DTN nodes must never be forced to trust information 222 provided by any single key authority node without corroboration by 223 other key authority nodes. 225 3.5. REQ5: No Veto 227 Correspondingly, the design must never enable any single key 228 authority node (possibly hijacked by an attacker) to degrade the 229 network by declining to corroborate the information provided by other 230 key authority nodes. 232 3.6. REQ6: Must Bind Public Key with DTN Node Identity 234 This requirement is about the claim for binding a public key with the 235 ID of a DTN node. The key authority must certify the association of 236 a public key with an identified DTN node when and only when that 237 association is asserted by some entity that the key authority trusts. 238 The mechanism by which such assertions are communicated must itself 239 be secured. This requirement is a generic requirement for all secure 240 Public Key Infrastructures. 242 3.7. REQ7: Must Support Secure Bootstrapping of a Node's Identity and 243 its Public Key 245 The Key Authority must authorize the use of the association between a 246 Node's identity and its public key, along with other administrative 247 information, in its DTN. Such association is essentially random and 248 cannot be verified in an automated manner. Thus, the association 249 must be verified manually before the Key Authority can approve the 250 use of the association in its DTN. 252 3.8. REQ8: Must Support Revocation 254 The DTN PKI must provide a mechanism that allows Certificate 255 Authorities to revoke a certificate even before the certificate 256 expires. 258 3.9. REQ9: Revocations Must Be Delay Tolerant 260 The propagation of information about revocation of issued and valid 261 certificates must use DTN only. DTN certificate revocation must not 262 assume the application will employ low-delay communications to verify 263 public key certificates as is normal in the terrestrial Internet, 264 where the Online Certificate Status Protocol (OCSP) is available to 265 verify the absence of a public key in the revocation list in an on- 266 demand manner. 268 4. DTN Security Key Management Design Criteria 270 We believe these core requirements imply several structural 271 guidelines on security key management design for DTN. A candidate 272 DTN security key management design can be formulated according to the 273 following design criteria: 275 4.1. DC1: Must Perform Timely Key Provisioning 277 The design must ensure that security keys are put in place before 278 they are actually needed. For example, if a source signs a bundle of 279 data using its private key, each DTN node in the path may require 280 access to the public key before the bundle arrives. Otherwise, the 281 bundle could be rejected due to security policy. This means that DTN 282 nodes must generate public/private key pairs and assert them to the 283 key authority long in advance of when they would actually be needed. 285 4.2. DC2: Pub/Sub Model 287 The design must be based on a publish/subscribe model instead of an 288 online (pull-based, or client/server) directory service, since on- 289 demand retrieval from a traditional server is not possible in many 290 DTN environments due to delays/disruptions. One alternative is for 291 the key authority to publish public key "bulletins" to which all DTN 292 nodes subscribe. The bulletins must reach all DTN nodes in the 293 network over the same long-delay links that carry ordinary data 294 bundles. Bulletins therefore must convey keys to be used at some 295 point in the future. 297 4.3. DC3: Publication Must Be Spread Over Multiple KAs 299 The key management system's responsibility for distributing key 300 information bulletins must be spread across multiple Key Authority 301 Nodes (KAs); a monolithic bulletin generated by a single KA would 302 violate requirements 3, 4, and 5. The cooperating KA nodes must 303 publish fractionated data that can be aggregated to reconstitute the 304 original bulletin; it must never be possible for the compromise of 305 any single KA to result in reception of an inauthentic bulletin. 306 Specifically, the KAs must agree on a bulletin through control 307 message exchanges, after which each KA publishes a few overlapping 308 fragments of the bulletin instead of the full bulletin. Each DTN 309 node then receives the fragments and reassembles them into a complete 310 bulletin. In this way, it is OK if one or more of the KAs fails 311 because the fragments are overlapping and DTN nodes will be able to 312 reconstruct the full bulletin. It is also OK if one or more of the 313 KAs has been hacked, because the integrity of the bulletin will be 314 ensured by the consensus agreement of all KAs. However, at least a 315 few non-compromised KAs (functioning as trust anchors) must be 316 present and reachable for the system to survive with assured 317 integrity. 319 4.4. DC4: Availability and Security 321 Like all other critical infrastructure elements, the key management 322 system must be maintained as highly available and hardened against 323 compromise. The latter requirement may require strong physical 324 security, e.g., secured data centers, hardened mobile platforms, etc. 325 This is no different than for other core network services such as the 326 Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP) 327 and many others. As in all other networking operations, nodes depend 328 on at least occasional contact with critical infrastructure. Where 329 fully ad-hoc networks are needed, dynamic key distribution may not be 330 feasible. In that case, permanent Pre-Placed Keys (PPK) and/or 331 limited-scope pairwise key exchanges may be the only solution 332 alternatives. 334 5. Candidate DTN Security Key Management Design 336 We anticipate a security model for DTN that is based on ephemeral 337 secret keys included on a per-bundle basis, i.e., in a similar manner 338 as for S/MIME. That is, the symmetric keys used to secure DTN bundle 339 traffic should normally be single-use (ephemeral) keys carried in 340 individual bundles rather than persistent session keys. DTN nodes 341 use public/private key pairs to encrypt/decrypt or sign/verify the 342 ephemeral keys. The ephemeral keys are used to decrypt/authenticate 343 bundle data efficiently. 345 In the design, DTN node public keys are registered with a Key 346 Management System (KMS) that serves as the trust anchor for all 347 secured DTN transactions. The KMS is organized as a group of N Key 348 Authority (KA) nodes that act in an inter-dependent fashion to 349 distribute public keys to all DTN nodes. 351 Each DTN node generates its own public/private key pair and registers 352 the public key with the KMS. The KMS in turn issues key assertions 353 and revocations in periodic bulletins sent via multicast 354 transmissions to all DTN nodes. The keys are designated for use at 355 some time in the future, since delays/disruptions may preclude 356 immediate delivery. 358 Each KA node in the KMS has all current public key information for 359 the DTN, but for each bulletin publication it sends only a subset of 360 blocks (or "fragments") of the entire bulletin. Each bulletin is 361 erasure-coded for Forward Error Correction (FEC) in case some 362 fragments are lost, corrupted, or deemed untrustworthy. The 363 resulting parity blocks for error detection are also included in the 364 publication. Receivers then reassemble the bulletin from the union 365 of fragments and parity blocks received, i.e., even if some fragments 366 are lost, and extract time-tagged public keys from the bulletin. 368 In subsequent operation, the public key that a node uses to encrypt 369 or sign an outbound bundle will be selected based on bundle creation 370 time. The node must ensure that when it creates a bundle it is using 371 a key that other nodes have been informed of. This means that each 372 DTN node must cache keys for sufficiently long times to account for 373 delays in the path. 375 DTN nodes must therefore keep track of all recently-received public 376 keys for each potential peer node in the DTN. A DTN node that 377 receives a bundle then uses the newest key that is no younger than 378 the bundle creation time to verify or decrypt the ephemeral key 379 included with the bundle. 381 Since multiple keys are retained at each node with different creation 382 times, there is no need to synchronize key transmission and 383 reception; the receiving node has the appropriate key in place long 384 before the bundle arrives. 386 Additionally, no information in the key distribution system is kept 387 secret - it's all public information. The point of the KMS is to 388 provide a critical infrastructure trust basis so that DTN nodes can 389 tell whether a prospective correspondent is authorized to use the 390 public key it claims. 392 Security is then based on the DTN node's trust relationship with the 393 KMS. As a result, all public keys are distributed securely. The KMS 394 service is automated, with potential human intervention for 395 revocation. No multi-message exchanges over long-delay links are 396 needed (i.e., as for services such as the Internet Key Exchange (IKE) 397 protocol), since ephemeral keys are used instead of session keys. 398 The system also provides no single point of failure or compromise. 400 6. Limitations and Challenges 402 The candidate KMS design requires a scalable, reliable multicast 403 capability. The DTN Bundle Protocol (BP) reliably delivers bundles 404 to one or more recipients based on convergence layer protocols such 405 as TCP and LTP. Reliable delivery in the BP is "hop-by-hop", where 406 each hop needs to receive data reliably from the previous hop to 407 ensure that end-to-end delivery is reliable. Scalable reliable 408 multicast delivery is also based on hop-by-hop convergence layers, 409 but large-scale reliable multicast is an end-to-end consideration 410 that is not dealt with well in the Internet and needs to be better 411 understood in the DTN context. 413 Security of the KMS is a fundamental requirement for service 414 integrity. Just as for core Internet services (e.g., the DNS, DHCP, 415 etc.), the KMS must be protected against network-based and physical 416 security attacks. The system design is resilient to one or more 417 elements being compromised, but bringing down all nodes essentially 418 brings down the DTN. History has proven that services of this nature 419 in the public Internet can be protected against comprehensive 420 destruction, but measures must be taken to ensure network and 421 physical security. 423 Another measure that may be considered in this context is KMS 424 confederation. The KAs of a "local" KMS might forward bulletins to 425 the KAs of another KMS as well as to the local node populations they 426 serve. Such a structure would tend to make the KMS not only more 427 durable but also more scalable. 429 Nodes that (re)enter the DTN after a long time away can present a 430 challenging bootstrapping situation. Sometimes DTN nodes can go 431 offline for extended periods of time (days/weeks/months), which would 432 essentially bring the same consideration as for a new DTN node 433 entering service for the first time. Upon (re)entering the DTN, the 434 node has to publish its public key via the KMS. This "first contact" 435 trust establishment is crucial to the security of the entire system, 436 i.e., ,there needs to be a way for the new DTN node to trust the KMS, 437 and for the KMS to validate the identity of the DTN node. In effect, 438 a trusted entity (a node or a human) must somehow "vouch" for the new 439 node. 441 DTN KMS services in fixed networks are not a problem, since the DTN 442 topology does not change. On the other hand, Mobile Ad-hoc Networks 443 (MANETs) typically show up in Unmanned Aerial Vehicle (UAV) networks, 444 tactical military networks, etc. In that case, portions of the DTN 445 may become detached from the rest of the DTN and re-attach at a 446 different point of the DTN at a later time. This is more of a 447 routing issue than a KMS issue, but routing aspects (especially in 448 MANETs where there is no critical infrastructure) need to be 449 understood. 451 Scaling considerations in terms of the size of the public key 452 database must be analyzed on a per-DTN basis. For example, it may 453 not be necessary for all DTN nodes to receive the public keys of all 454 other DTN nodes since only a subset of all public keys may ever be 455 needed. This is the same scaling consideration that motivated the 456 design of the public Internet Domain Name System (DNS), when 457 maintenance and distribution of a single, central repository at the 458 SRI Network Information Center (SRI-NIC) became too unwieldy to 459 maintain as the Internet grew exponentially. 461 7. IANA Considerations 463 There are no IANA considerations for this document. 465 8. Security Considerations 467 This document is entirely about security aspects of key management as 468 a crucial component of DTN security; hence, security considerations 469 appear throughout the document. 471 DTN security considerations are discussed in 472 [RFC6257][I-D.irtf-dtnrg-sbsp]. 474 9. Acknowledgments 476 Security key management has been discussed broadly in DTN mailing 477 list discussions as well as in many of the documents cited in this 478 publication. The candidate design discussed here is based on the 479 original ideas of Scott Burleigh from NASA/JPL. Kapaleeswaran 480 Viswanathan provided valuable review input. 482 10. References 484 10.1. Normative References 486 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 487 1981. 489 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 490 (IPv6) Specification", RFC 2460, December 1998. 492 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 493 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 494 Networking Architecture", RFC 4838, April 2007. 496 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 497 Specification", RFC 5050, November 2007. 499 10.2. Informative References 501 [I-D.farrell-dtnrg-km] 502 Farrell, S., "DTN Key Management Requirements", draft- 503 farrell-dtnrg-km-00 (work in progress), June 2007. 505 [I-D.irtf-dtnrg-sbsp] 506 Birrane, E., "Streamlined Bundle Security Protocol 507 Specification", draft-irtf-dtnrg-sbsp-01 (work in 508 progress), May 2014. 510 [I-D.irtf-dtnrg-sec-overview] 511 Farrell, S., Symington, S., Weiss, H., and P. Lovell, 512 "Delay-Tolerant Networking Security Overview", draft-irtf- 513 dtnrg-sec-overview-06 (work in progress), March 2009. 515 [IVAN09] Ivancic, W., "Security Analysis of DTN Architecture and 516 Bundle Protocol Specification for Space-Based Networks", 517 October 2009. 519 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 520 "Internet X.509 Public Key Infrastructure Certificate 521 Management Protocol (CMP)", RFC 4210, September 2005. 523 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 524 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 526 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 527 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 528 5996, September 2010. 530 [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, 531 "Bundle Security Protocol Specification", RFC 6257, May 532 2011. 534 [WOOD08] Wood, L., Eddy, W., and P. Holliday, "A Bundle of 535 Problems", December 2008. 537 Authors' Addresses 539 Fred L. Templin (editor) 540 Boeing Research & Technology 541 P.O. Box 3707 542 Seattle, WA 98124 543 USA 545 Email: fltemplin@acm.org 547 Scott Burleigh 548 JPL, Calif. Inst. Of Technology 549 4800 Oak Grove Dr. 550 Pasadena, CA 91109-8099 551 USA 553 Phone: +1 818 393 3353 554 Email: Scott.Burleigh@jpl.nasa.gov