idnits 2.17.1 draft-ymbk-ta-publication-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 2012) is 4272 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-dane-protocol' is defined on line 309, but no explicit reference was found in the text == Unused Reference: 'RFC5934' is defined on line 335, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bellovin 3 Internet-Draft Columbia University 4 Intended status: Informational R. Bush 5 Expires: January 31, 2013 Internet Initiative Japan 6 R. Housley 7 Vigil Security, LLC 8 S. Kent 9 BBN Technologies 10 S. Turner 11 IECA, Inc. 12 August 2012 14 Trust Anchor Publication Advice 15 draft-ymbk-ta-publication-00 17 Abstract 19 Many Internet protocols and services rely on credentials which use 20 asymmetric keys. Many of these are hierarchic structures having 21 certification authorities (CAs) that act as trust anchors (TAs). 22 There is little general guidance on procedures for how these trust 23 anchors can be distributed or otherwise published with prudence. To 24 quote a well known security expert, "It's a matter of oral tradition 25 in security circles." This document attempts to capture some of that 26 lore. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 31, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 This document may not be modified, and derivative works of it may not 60 be created, and it may not be published except as an Internet-Draft. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Trust in the Conveyance . . . . . . . . . . . . . . . . . . . 3 66 2.1. TLS / https . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.2. In Packaged Software . . . . . . . . . . . . . . . . . . . 3 68 3. Trust in the Conveyor . . . . . . . . . . . . . . . . . . . . 4 69 3.1. PGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.2. Physical Proximity . . . . . . . . . . . . . . . . . . . . 4 71 4. Advice yet to be Organized . . . . . . . . . . . . . . . . . . 5 72 4.1. Public Transport Plus Verification . . . . . . . . . . . . 5 73 4.2. TAMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4.3. SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 4.4. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 4.5. RPKI . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 4.5.1. Hardware Security Module . . . . . . . . . . . . . . . 6 78 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 79 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 Many Internet protocols and services make use of asymmetric keys 85 distributed via certificates (e.g., X.509 or OPGP) or analogous 86 formats (e.g., DNSSEC records). Many of these certificates are 87 organized into hierarchic structures having one or more trust anchors 88 (TAs). In any hierarchical structure, the choice of root is 89 important. In PKIs, it is quite critical, since an untrustworthy or 90 incompentent TA can issue credentials to imposters, vitiating the 91 security guarantees for the entire structure. This in turn implies 92 that anyone relying on a PKI must have accurate knowledge of the root 93 of the tree. However, there is little general guidance on procedures 94 for how these trust anchors can be distributed in a fashion that 95 ensures their integrity and authenticity. To quote a well known 96 security expert, "It's a matter of oral tradition in security 97 circles." This document attempts to capture some of that lore. 99 In particular, the issue of publication of root TA(s) for the 100 Resource Public Key Infrastructure (RPKI) incited this document. We 101 recommend it be handled similarly to the DNSSEC root keys, see 102 Section 4.5. 104 We do not address the complex matter of generating key pairs for 105 trust anchors. They range from exceedingly formal and complex, e.g. 106 [icann-dnssec] for DNSSEC, to the exceedingly informal, e.g. [pgp- 107 gen]. We assume the public key material and associated date have 108 been created, and address the problem of distribution and/or 109 publication of the TA materiel in a secure fashion. 111 The distribution/publication problem is how to give relying parties 112 (RPs) who will use the TA confidence that the trust anchor is 113 authentic. In this context authentic means that the public key and 114 associated data has not been modified in an unauthorized fashion, and 115 the data associated with the TA accurately identifies the principle 116 that it represents. There is usually no external trust environment 117 which is the same as that of the TA; after all this is a TA. So the 118 problem often devolves to issues of identity and trust in the 119 conveyance or conveyor of the TA. This is often referred to as 'Out 120 Of Band' (OOB) verification of the TA. 122 Fundamentally, one can trust information if it came via a trusted 123 path and/or was delivered by a trustworthy source. We refer to these 124 as "conveyance" and "conveyor". In addition, one can build up trust 125 by suitable conbination of information from many different sources; 126 this gives rise to a variety of hybrid schemes. 128 Note carefully that there is no one solution for all situations. The 129 proper answer depends on the operational needs, and often on the 130 particular hardware and software involved. 132 2. Trust in the Conveyance 134 2.1. TLS / https 136 For some applications, an HTTP GET authenticated with TLS [RFC5785] 137 may be sufficient. Given the number of certificates in the normal 138 browser, many consider this imprudent and suggest that the user 139 should ensure that the certification path validates to a particular 140 TA that they trust for introducing other TAs. This may be beyond the 141 average user 143 Use of further authenticity such as DANE, see [I-D.ietf-dane- 144 protocol] is another approach. 146 Microsoft distributes new browser TAs in the same manner as software 147 updates, which rely on certificate path validation. Thus the entropy 148 of the browser's certificate store can only increase. 150 2.2. In Packaged Software 152 Embedding a TA in software is a common method of distribution in many 153 contexts. In an enterprise context this may suffice, e.g., if 154 software distribution is tightly controlled by the enterprise. Most 155 operating systems and browsers use this method, as the vendors of 156 these products are dealing with a set of RPs that is large, 157 geographically dispersed, and unknown to the TA management. But, 158 this approach is not without risks. 160 For example, an RP who receives an OS copy on a DVD in conjunction 161 with the purchase of a laptop is probably confident that the TA(s) 162 embedded in that OS have not been modified and that the vendor has 163 vouched for the accuracy of the TA material. In contrast, if a copy 164 of a browser is downloaded via the Internet, the set of TAs embedded 165 in it may or may not be what the browser vendor intended. Attacks on 166 the DNS (absent DNSSEC), or on the server from which the browser 167 image was acquired could have resulted in bogus TA material. 169 3. Trust in the Conveyor 171 For applications where the credential is that of an identity, 172 authentication of the conveyor might be appropriate. 174 3.1. PGP 176 Pretty Good Privacy (PGP) [RFC4880] is based on personal identity, 177 and "Uses a combination of strong public-key and symmetric 178 cryptography to provide security services for electronic 179 communications and data storage." 181 PGP itself actually has no root of trust, but rather is a web of 182 trust sans root. It would not be of extreme interest here except it 183 has some of the few well-documented rituals of authenticating 184 exchange of credentials involving fingerprints (hashes) of keys [pgp- 185 party]. There is also a system of coordinated key servers [REF 186 NEEDED]. 188 3.2. Physical Proximity 190 In some environments it is possible to provide good physical, 191 personnel, and procedural security for TA distribution. This is 192 especially easy if the set of RPs is small, geographically local, and 193 known to the TA management. 195 For example, in an organization an employee might receive a smart 196 card loaded with a personal certificate and private key, and the TA 197 for the organization. If the organization distributes this card to 198 the employee in person, e.g., as a side effect of employee (or 199 student) orientation, the employee can probably rely on the 200 authenticity of the TA. The DoD Common Access Card (CAC) delivers TA 201 material in this fashion, through a network of verification officers 202 and associated work stations. 204 4. Advice yet to be Organized 206 4.1. Public Transport Plus Verification 208 Less secure TA distribution mechanism are often employed when the RP 209 population is very large, or geographically dispersed, or not known 210 by TA management a priori. 212 For example, a smart card loaded with a TA might be sent to an RP via 213 the postal system. The RP, upon receipt if the card, can't be 214 absolutely sure that the TA represents the entity identified on the 215 card or in accompanying documentation. If registered mail is 216 employed the likelihood of tampering en route might be considered 217 very small, but the identity of the sender still would not be 218 assured. Thus some means of independently verifying that aspect of 219 TA security would still be needed. Depending on the context, such 220 verification might be easy, or very difficult. For example, if the 221 card is designed to enable access to a bank account, the RP might try 222 to use it and see of the bank balances reported match what the RP 223 expects. If the RP need not provide a password or other secret value 224 to gain access to the account this is a reasonable way for the RP to 225 verify that the card "works" and that it probably was issued by their 226 bank, and thus the TA on the card is likely associated with the bank. 228 4.2. TAMP 230 The Trust Anchor Management Protocol (TAMP [RFC4255]) is a transport 231 independent protocol for the management of trust anchors and 232 community identifiers stored in a trust anchor store. 234 The core concept is not complex. Trust one signer to be the one to 235 introduce other public keys as trust anchors, and those may have 236 constraints (one for signed software, one for TLS, only for IPsec, or 237 whatever). Complexity comes if you want to allow that one signer to 238 pass the privilege to another signer. 240 More needed here. 242 4.3. SSH 243 Secure Shell (SSH [RFC4251]) authenticates [RFC4252] over the SSH 244 Transport Layer Protocol, [RFC4253]. The server may authenticate the 245 user's identity by a number of means, password, asymmetric key, 246 challenge response, etc. The user authenticates the server by an 247 asymmetric key. That key may have been transmitted out of band, e.g. 248 using DNSSEC [RFC4255] or some other credible (to the user) means. 249 SSH also offers a 'trust the transport' key conveyance, with manual 250 hash verification, for the first connection to the server. 252 4.4. DNSSEC 254 DNSSEC relies on a diverse public distribution mechanism to 255 distribute the TA material for the DNS root, see [icann-dnssec]. The 256 DNS root TA material is available in multiple formats (e.g., S/MIME, 257 PEM certificate request, XML, and OPGP), and from multiple sites 258 (e.g., iana.org, ???). An RP that acquires the DNS TA material from 259 multiple sources can verify that the public key values it acquires 260 all match. An adversary would have to spoof replies from all of the 261 queried sources to fool an RP. Moreover, if the RP received bogus 262 DNS root TA data, the RP would not be able to validate legitimate 263 DNSSEC records. Thus an adversary would have to insert itself in the 264 RPs (DNESEC) communication path on a persistent basis to avoid 265 detection. This is perceived as a difficult task and thus the DNSSEC 266 mechanism for distributing TA material is viewed as adequate. 268 4.5. RPKI 270 Trust Anchor Locators (TALs) are used to distribute TAs in the RPKI. 271 A TAL is a URI and a self-signed X.509 certificate. There is no plan 272 to publish TALs in multiple formats, as the TAL format itself is 273 quite simple. 275 It is anticipated that the root TAL, like the DNSSEC root zone TA 276 material, will be published by the IANA similarly to the DNSSEC root 277 keys, see [icann-dnssec]. Until the IANA signs the root TAL for the 278 RPKI, it is anticipated that the next level in the hierarchy, the 279 RIRs, will each publish a TAL using analogous means. 281 Unlike the certificates in browsers, the IANA and RIRs are a small 282 and static set of TAL publishers. It should be easier to distribute 283 them in a more credible fashion. 285 4.5.1. Hardware Security Module 286 If a TA is used only offline, and one employs a good HSM (e.g., FIPS 287 140 level 4) then it is very, very unlikely that the private key will 288 be compromised and not detected. IANA and the RIRs can afford to 289 protect their keys this way, so one should rarely have to change 290 these TAs. Thus the principle problem is how an RP can become 291 confident that the TAL data it acquires is legitimate. The same 292 principle applies here as for DNSSEC. Each RP should acquire TALs 293 from multiple locations and verify that the data are consistent. 294 Each RP will be downloading and verifying data from multiple RPKI 295 repositories. If the TAL(s) acquired by an RP are not accurate, then 296 legitimate RPKI data acquired from repositories will not validate. 297 Thus an adversary would have to insert itself in the RPs RPKI 298 repository communication path on a persistent basis to avoid 299 detection. This is perceived as a difficult task and thus the RPKI 300 mechanism for distributing TA material is viewed as adequate. 302 5. Acknowledgements 304 The authors would like to thank Shane Amante for inciting this 305 effort. 307 6. References 309 [I-D.ietf-dane-protocol] 310 Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 311 of Named Entities (DANE) Transport Layer Security (TLS) 312 Protocol: TLSA", Internet-Draft draft-ietf-dane- 313 protocol-23, June 2012. 315 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 316 Protocol Architecture", RFC 4251, January 2006. 318 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 319 Authentication Protocol", RFC 4252, January 2006. 321 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 322 Transport Layer Protocol", RFC 4253, January 2006. 324 [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely 325 Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, 326 January 2006. 328 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D. and R. 329 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 331 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 332 Uniform Resource Identifiers (URIs)", RFC 5785, April 333 2010. 335 [RFC5934] Housley, R., Ashmore, S. and C. Wallace, "Trust Anchor 336 Management Protocol (TAMP)", RFC 5934, August 2010. 338 [icann-dnssec] 339 Ljunggren, F., Okubo, T., Lamb, R., Schlyter, J., "DNSSEC 340 Practice Statement for the Root Zone KSK Operator", 2010, 341 . 343 [pgp-gen] cets@seas.upenn.edu, "Generating PGP Keys", , . 346 [pgp-party] 347 Brennen, A. V., "The Keysigning Party HOWTO", 2008, . 351 Authors' Addresses 353 Steven M. Bellovin 354 Columbia University 355 1214 Amsterdam Avenue, MC 0401 356 New York, New York 10027 357 US 359 Phone: +1 212 939 7149 360 Email: bellovin@acm.org 362 Randy Bush 363 Internet Initiative Japan 364 5147 Crystal Springs 365 Bainbridge Island, Washington 98110 366 US 368 Email: randy@psg.com 370 Russell Housley 371 Vigil Security, LLC 372 918 Spring Knoll Drive 373 Herndon, VA 20170 374 US 376 Email: housley@vigilsec.com 378 Stephen Kent 379 BBN Technologies 380 10 Moulton St. 381 Cambridge, MA 02138 382 US 384 Email: kent@bbn.com 385 Sean Turner 386 IECA, Inc. 387 3057 Nutley Street, Suite 106 388 Fairfax, Virginia 22031 389 US 391 Email: turners@ieca.com