idnits 2.17.1 draft-snyder-trust-relationships-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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 25, 2011) is 4567 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snyder 3 Internet-Draft Opus One 4 Expires: April 27, 2012 K. O'Donoghue 5 ISOC 6 M. Shore 7 TBS 8 October 25, 2011 10 A Survey of Trust Models and Relationships in Internet Protocols 11 draft-snyder-trust-relationships-00 13 Abstract 15 This document reviews common Internet protocols and discusses how 16 each protocol establishes, maintains, and tears down trust 17 relationships within the protocol. This document includes discussion 18 of "meta" trust issues, including extra-protocol trust creation, 19 management, and destruction. In cases where specific issues related 20 to establishment of trust have been documented, these are discussed 21 as well. By examining both similarities and differences between 22 different protocols, this document can help protocol designers and 23 maintainers in IETF working groups learn from successful (and un- 24 successful) Internet protocols. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 27, 2012. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Overview and Problem Statement . . . . . . . . . . . . . . . . 3 63 4. DKIM (Domain Keys Identified Mail) . . . . . . . . . . . . . . 4 64 4.1. DKIM Background and Overview . . . . . . . . . . . . . . . 4 65 4.2. Trust Relationships in DKIM . . . . . . . . . . . . . . . 4 66 4.3. DKIM Diagrams . . . . . . . . . . . . . . . . . . . . . . 4 67 5. DNSSEC (Domain Name System Security Extensions) . . . . . . . 4 68 5.1. DNSSEC Background and Overview . . . . . . . . . . . . . . 4 69 5.2. Trust Relationships in DNSSEC . . . . . . . . . . . . . . 4 70 5.3. DNSSEC Diagrams . . . . . . . . . . . . . . . . . . . . . 4 71 6. PKI (Public Key Infrastructure) . . . . . . . . . . . . . . . 4 72 6.1. PKI Background and Overview . . . . . . . . . . . . . . . 4 73 6.2. Trust Relationships in PKI . . . . . . . . . . . . . . . . 5 74 6.2.1. Basic Model . . . . . . . . . . . . . . . . . . . . . 5 75 6.2.2. Creating and instantiating trust . . . . . . . . . . . 6 76 6.2.3. Validating Trust . . . . . . . . . . . . . . . . . . . 8 77 6.2.4. Revoking Trust . . . . . . . . . . . . . . . . . . . . 8 78 6.3. PKI Diagrams . . . . . . . . . . . . . . . . . . . . . . . 9 79 7. RPKI (Resource Public Key Infrastructure) . . . . . . . . . . 9 80 7.1. RPKI Background and Overview . . . . . . . . . . . . . . . 9 81 7.2. Trust Relationships in RPKI . . . . . . . . . . . . . . . 9 82 7.3. RPKI Diagrams . . . . . . . . . . . . . . . . . . . . . . 9 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 88 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 91 1. Introduction 93 Many Internet protocols need to establish some type of trust between 94 the parties participating in the protocol in order to be effective. 95 For example, the Internet Key Establishment (IKE) protocol ([insert] 96 [references] [here]) passes through an authentication phase between 97 the two IKE peers before it moves to a second phase where 98 cryptographic material is established for encrypting and 99 authenticating IPsec traffic. The authentication phase serves to 100 establish trust between the two IKE peers. For example, if the IKE 101 peers use pre-shared secrets, then each IKE peer is willing to trust 102 the other once they have mutually proven knowledge of a pre-shared 103 secret. 105 Please note that this document was derived from existing protocols 106 and does not attempt to define or re-define the function of any 107 Internet protocol. This document is entirely non-definitive and 108 should not be used by implementers as an authoritative source of 109 information about protocol behavior or description. 111 WHY IS THIS IMPORTANT? 113 NEED A BETTER DESCRIPTION OF "TRUST" HERE AND WHAT WE WILL BE LOOKING 114 AT EXACTLY. 116 The protocols described in the document were chosen for their 117 exemplar value. This document is not meant to be an exhaustive 118 description of all protocols and their trust establishment models. 120 2. Terminology 122 Trust: This is the definition of Trust. 124 Authentication: This is the definition of Authentication. 126 Identification: This is the definition of Identification. 128 Reputation: This is the definition of Reputation. 130 3. Overview and Problem Statement 132 In this section, we would provide as much background and other 133 related information as we can to help describe some things 134 including... 136 WHY ARE WE DOING THIS? 137 WHAT IS THE VALUE OF THIS CONTRIBUTION? 139 WHAT ARE WE NOT INCLUDING IN THIS DOCUMENT AND WHY? 141 4. DKIM (Domain Keys Identified Mail) 143 4.1. DKIM Background and Overview 145 Protocol Overview 147 4.2. Trust Relationships in DKIM 149 Trust Models and Relationships in DKIM 151 4.3. DKIM Diagrams 153 Diagrams go here 155 5. DNSSEC (Domain Name System Security Extensions) 157 5.1. DNSSEC Background and Overview 159 Protocol Overview 161 5.2. Trust Relationships in DNSSEC 163 Trust Models and Relationships in DNSSEC 165 5.3. DNSSEC Diagrams 167 Diagrams go here 169 6. PKI (Public Key Infrastructure) 171 6.1. PKI Background and Overview 173 The IETF PKIX working group has specified an X.509v3 profile, and 174 that profile and set of associated specifications are colloquially 175 referred to as PKIX. The core specification is RFC 5280. 177 Throughout this section we look at how trust is conveyed in PKIX from 178 two perspectives: 180 (1) from the perspective of a relying party -- an entity that 181 receives an assertion (credential) and needs to make a decision 182 whether or not to trust it, and 184 (2) from the perspective of an end entity -- an entity that needs to 185 assert its identity in a way that can be accepted by a relying 186 party. 188 By way of terminology, the entity which signed a certificate and 189 which is vouching for the authenticity of both the certificate and 190 the certificate holder is referred to as the issuer. The entity to 191 which the certificate was issued is the subject. 193 Trust in PKIX is instantiated through the use of trust anchors. A 194 trust anchor is itself a certificate, but one about which a human has 195 made an explicit trust decision. In this context, subsequent trust 196 decisions must successfully chain back to that initial decision -- 197 that a certification authority is reliable, secure, and honest, and 198 that its business practices provide assurance that it will only be 199 issuing certificates to entities which are also reliable, secure, and 200 honest. 202 This document does not yet discuss the Trust Anchor Management 203 Protocol. [insert][reference][here] TAMP does not change the 204 underlying trust model or the trust lifecycle, although it does 205 provide mechanisms for implementing it. 207 6.2. Trust Relationships in PKI 209 6.2.1. Basic Model 211 Perhaps the key assumption around which PKIX is built is that it is 212 not necessary for two entities to have an existing relationship in 213 order to make a decision whether or not to accept the otherE1/4s 214 assertions as 1) correct, and 2) trustworthy. Rather than 215 negotiating in advance of any communication, those decisions are 216 mediated through the use of third party agents, and consequently 217 whether or not a given entity is trustworthy comes down to the 218 question of whether or not the agent (and its agent, and on up the 219 chain) can be seen as trustworthy and authoritative, and can make 220 reliable assertions about the credentials it has issued. 222 A certification authority, which may or may not be a commercial 223 entity, issues signed credentials for its customers. These 224 credentials are known as end entity certificates. Its signature is 225 essentially an attestation that the CA has some level of confidence 226 that the entity to which the certificate was issued really is who it 227 claims to be. Certificates may be chained from a trust anchor -- 228 that is to say, there may be from zero to n certification authorities 229 between the trust anchor and the end entity to which the certificate 230 has been issued.[insert][reference][here] 232 Trust is instantiated by provisioning a root certificate in a local 233 cache or in some logically local data store. This root certificate 234 functions as a trust anchor. If the process of validating an end 235 entity certificate does not terminate at a trust anchor, the 236 validation fails. 238 The data model is essentially hierarchical, and tree-shaped. While a 239 CA may issue multiple (typically many) certificates, a certificate 240 may have only one issuer. At the very top of the trust tree is a 241 person or organization who determines which root certificates 242 represent a trusted CA (note that this decision and associated 243 information are basically determined manually and out-of-band, 244 typically requiring human judgment). 246 Bidirectional trust may be established between two CAs and their 247 subjects through the use of cross-certification. In this case the 248 two CAs issue certificate to each other. It is still the case, 249 however, that a certificate will have one issuer, and that a CA may 250 issue multiple (many) certificates. The decision to cross-certify is 251 still out-of-band, and human. The question of what the trust anchor 252 is in this situation is still being debated on the pkix mailing list5 253 and is unresolved as of this writing. (Oct/2011) 255 Self-signed certificates merit special mention, because they are so 256 commonly deployed. A self-signed certificate is one in which the 257 issuer and the subject are the same. It is very rarely the case that 258 a self-signed certificate is already installed in a root cert cache 259 and is functioning as a trust anchor, but it is very common for users 260 to accept and install self-signed certificates when they are offered 261 by a visited website. 263 6.2.2. Creating and instantiating trust 265 There are two aspects to creating trust and instantiating it through 266 PKIX technologies. The first aspect relates to the determination 267 made by a user or systems administrator (i.e. a relying party) that a 268 given certification authority is a reliable source of authority 269 regarding the identity of the entities represented in the certificate 270 it issues. The second relates to the determination made by the end 271 entity that a given certification authority is a reliable agent -- 272 that they are who they say they are, that their business practices 273 are sound, that the operation of their certificate infrastructure is 274 secure, and, perhaps most importantly, that the chain to the trust 275 anchor contains only issuers who are also secure, reliable, and 276 trustworthy. The relying party also needs to have assurances about 277 intermediate CAs and certificates in a chain, but this comes into 278 play during validation, not during provisioning. 280 6.2.2.1. Bootstrapping trust in a relying party 282 From an end entity perspective, trust is instantiated, or verified, 283 through the presence of trust anchors in a local store. A decision 284 to install or provision a root CA certificate as a trust anchor is an 285 out-of-band, human decision and represents a decision to trust that 286 the CA represented by that certificate is secure, reliable, and 287 authoritative. It also represents a decision that the intermediate 288 CAs underneath the root CA are also secure, reliable, and 289 authoritative (this has turned out to be a problem, in practice). 291 It is typically the case that web browsers are distributed with a 292 cache of root certificates, which have been vetted with varying 293 degrees of rigor by the browser developers. When a user decides to 294 use a browser with an existing cache, theyE1/4re implicitly trusting 295 the browser developers. This is not unreasonable -- in theory, the 296 browser developer has the resources and expertise to evaluate trust 297 anchors for inclusion, and will exclude certificates from unreliable 298 CAs. 300 In other cases, often in cases where a local CA is issuing 301 certificates, a local systems administrator makes the decision to add 302 a root CA certificate from a local (or neighboring) CA. 304 A special case of bootstrapping trust, and one which poses a security 305 problem, is that a user may be offered an unknown certificate, be 306 asked by the browser whether or not to accept it, and will not only 307 accept the certificate as authentic but also install it locally for 308 future use. In this situation there is an apparent disconnect 309 between whatE1/4s happening conceptually in the security transaction 310 (the user is being asked whether or not to accept a credential as 311 both authentic and trustworthy) and the userE1/4s understanding of 312 whatE1/4s going on (the user just wants the connection to complete 313 and may not understand the underlying security model). 315 6.2.2.2. Bootstrapping trust in an end entity 317 In this case, bootstrapping essentially means investigating 318 certification authorities, making a decision to acquire a certificate 319 from one, and installing that certificate. Again,this is a human 320 decision thatE1/4s instantiated through technical means (the 321 provisioning of the certificate). 323 Unfortunately there really is no way, as a relying party, to 324 determine the soundness of the end entityE1/4s decision to acquire a 325 cert from a particular CA. It may be that they chose one CA over 326 another on the basis of business practices but it may also be the 327 case that they chose the least expensive vendor regardless of 328 soundness. When things are working as they should a CA will only 329 sell certificates to other very reliable CAs, and on down the chain, 330 but there have been several issues with compromised or sloppy 331 intermediate CAs in the recent past that call this model into 332 question. 334 6.2.2.3. A brief digression on EV certs 336 The CA/Browser forum has published guidelines for identity 337 verification, including specification of specific identity criteria. 338 These center around three goals: 340 (1) establish the legal identity of the certificate applicant; 342 (2) establish that the applicant has legal ownership of the entity 343 for which the certificate is to be issued (the Subject), and 345 (3) confirm the identity and the authority of the ownerE1/4s agents. 347 Certificates issued under these criteria are called Extended 348 Validation Certificates. Browser markers provide visual clues, such 349 as color in the address bar, when an EV certificate is present and 350 has been validated. A CA must typically pass an independent audit to 351 be accepted by browser vendors as an issuer of EV certs. 353 6.2.3. Validating Trust 355 In PKIX, trust is chained back to a trust anchor. Validation 356 essentially consists of path validation, with the assumption that 357 youE1/4ll trust who your anchor vouches for, and so on up the chain. 359 It may also be the case that a non-root certificate - an end-entity 360 certificate thatE1/4s not a trust anchor, is explicitly trusted, 361 usually through local installation in a browser or other cache. 362 Unfortunately itE1/4s often the case that the user is making a 363 decision to get a connection to work rather than making an explicit 364 trust decision. 366 6.2.4. Revoking Trust 368 The X.509 lifecycle model typically is based on a long-lived 369 credential (months or, more often, years) which may expire without 370 being reissued, or may be explicitly revoked. Explicit revocation 371 may be accomplished through a variety of measures: 373 (1) Manual removal from a browser or other certificate cache, 375 (2) Blacklist checking by the relying party as part of the 376 validation process. This, in turn, may take one of several 377 forms: 379 (a) Certificate revocation lists, issued by the certification 380 authority which issued the original certificate. These 381 should be created and published on a regular, timely 382 schedule and must be checked as part of the certificate 383 validation process. 385 (b) A status query at validation time, through the use of the 386 Online Certificate Status Protocol 388 (c) Blacklisting by the browser vendor 390 The technical means for revoking trust is essentially the same as 391 that for revoking a non-trust anchor certificate. If the trust 392 anchor is gone, certificates which chain back to it will fail the 393 validation check. 395 6.3. PKI Diagrams 397 Diagrams go here 399 7. RPKI (Resource Public Key Infrastructure) 401 7.1. RPKI Background and Overview 403 Protocol Overview 405 7.2. Trust Relationships in RPKI 407 Trust Models and Relationships in RPKI 409 7.3. RPKI Diagrams 411 Diagrams go here 413 8. IANA Considerations 415 None. 417 9. Security Considerations 419 To be supplied. 421 10. Acknowledgements 423 Insert list of key collaborators.. 425 11. References 427 11.1. Normative References 429 11.2. Informative References 431 Authors' Addresses 433 Joel Snyder 434 Opus One, Inc. 435 1404 East Lind Road 436 Tucson, Arizona 85719 437 US 439 Phone: +1 520 324 0494 440 Email: jms@opus1.com 441 URI: http://www.opus1.com/jms 443 Karen O'Donoghue 444 The Internet Society 445 7167 Goby Lane 446 King George, Virginia 22485 447 US 449 Email: odonoghue@isoc.org 450 URI: http://www.isoc.org 452 Melinda Shore 453 TBS