idnits 2.17.1 draft-shore-trust-problemstatement-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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2013) is 4078 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) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Shore 3 Internet-Draft No Mountain Software 4 Expires: August 29, 2013 K. O'Donoghue 5 ISOC 6 February 25, 2013 8 A problem statement on trust in IETF protocols 9 draft-shore-trust-problemstatement-01 11 Abstract 13 This document attempts to set out a problem statement and framework 14 for future discussions regarding "trust" in the IETF. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on August 29, 2013. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology and glossary . . . . . . . . . . . . . . . . . . . 4 52 3. What is trust? . . . . . . . . . . . . . . . . . . . . . . . . 6 53 4. Modeling trust . . . . . . . . . . . . . . . . . . . . . . . . 8 54 5. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 56 7. Path forward . . . . . . . . . . . . . . . . . . . . . . . . . 13 57 8. Informative References . . . . . . . . . . . . . . . . . . . . 14 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 60 1. Introduction 62 "Trust" is used quite broadly in IETF documents but has not been 63 discussed or defined very rigorously. To the extent that it's been 64 discussed explicitly it's typically been within an implementation or 65 protocol definition context, often around the question of trust 66 anchors and their management (see RFCs [RFC5914], [RFC5934], 67 [RFC6024], and many others for examples). 69 In this document we intend to tease out how IETF protocols have 70 tended to approach questions around trust, discuss whether or not 71 this has been sufficient, and see if there is new work on trust that 72 could be of value. We are not specifically interested in defining 73 the word "trust," but rather identifying broader issues and problems 74 related to trust. 76 Note, as well, that a survey of trust mechanisms in IETF documents 77 and protocols is out-of-scope for this document. 79 Text relating to problems around revocation will be added to future 80 revisions of this document, as well as text relating to problems 81 modeling trust in third-party and federated authentication and 82 authorization protocols. 84 2. Terminology and glossary 86 Assurance, Assurance Level 88 Attestation of Control 90 Authentication 92 Binding, Cryptographic Binding 94 Blocklist/Whitelist 96 Certification, Certification Practices, Certification 98 Practices Statement 100 Certifying Authority, Certification Authority 102 Confidence 104 Correct 106 Digitally Signed/Digital Signature 108 Hijack 110 Identity, Identity information 112 Leap of Faith 114 Legitimate 116 Mediated Trust 118 Revocation 120 Risk 122 Source Integrity 124 Transitive Operations (in the context of Trust) 126 Trust 128 Trust Anchor 129 Trust Auditing 131 Trust Establishment and Bootstrapping 133 Trust Framework 135 Trust Revocation 137 Trust Passing 139 Trust Transaction 141 Trustee, Trustor 143 Unilateral Trust, Bilateral Trust 145 Validation, Validation of Compliance 147 3. What is trust? 149 As of this writing, "trust" does not appear to be defined in an IETF 150 document, relying, rather, on functional or operational contexts to 151 imply intent. [RFC4949], a quite substantial internet security 152 glossary, does not define it anywhere, although in its definition of 153 "source integrity" it includes the text: 155 The property that data is trustworthy (i.e., worthy of reliance or 156 trust), based on the trustworthiness of its sources and the 157 trustworthiness of any procedures used for handling data in the 158 system. 160 which is a rather circular discussion. 162 Kaliya Hamlin, on her IdentityWoman blog, has written a bit [1] about 163 this in the context of the NSTIC [2] (National Strategy for Trusted 164 Identities in Cyberspace) program, ultimately arguing that a "trust 165 framework" is an accountability framework. 167 Accountability would seem to be a component of an intuitive 168 understanding of "trust," and establishing accountability is a core 169 component of establishing trust as we understand it, but 170 accountability implies auditability only; that is to say, this 171 definition seems to focus on the ability to retrospectively determine 172 that some set of actions took place in the past. Establishing 173 accountability does not establish that future interactions will be 174 safe, and authorized. 176 The OASIS Web Service Secure Exchange Technical committee has 177 developed a standard [ws-trust] to specify a framework for, among 178 other things, brokering trust relationships. Much like the IETF, 179 they seem to rely on an operational definition of "trust": 181 Trust is the characteristic that one entity is willing to rely 182 upon a second entity to execute a set of actions and/or to make 183 set of assertions about a set of subjects and/or scopes. 185 Zainab Aljazzaf has done extensive work on trust in web transactions, 186 and in his doctoral dissertation [tbss] he defines trust as a complex 187 subjective term, with the following components: 189 o Utility: a trustee (for example, an IdP, or a web server) needs to 190 provide a utility to a trustor (for example, a relying party or a 191 web browser) 193 o Dependency and reliability 194 o Risk attitude. 196 o Vulnerability 198 o Remedies, in the event of a breach of trust. This is closely 199 related to Hamlin's notion of accountability 201 o Confidence expectation, with an inverse relationship between trust 202 and confidence (Aljazzaf asserts that possession of confidence 203 makes trust unnecessary) 205 o Context-specific 207 o Subjective -- trust is experienced differently for different 208 trustees 210 o A trustor may have no control over the trustee. The more control 211 a trustor has over a trustee, the less need there is for trust 213 He then goes on to propose the following one-sentence definition of 214 trust: 216 Trust is the willingness of the trustor to rely on a trustee to do 217 what is promised in a given context, irrespective of the ability 218 to monitor or control the trustee, and even though negative 219 consequences may occur. 221 The key question seems to be around risk, and the expectations of 222 risk. Imparting trust would seem in some sense to be a signaling 223 mechanism - that transactions with the trusted party should be 224 regarded as carrying known than transactions with non-trusted 225 parties. 227 4. Modeling trust 229 Describing, or modeling, trust requires identifying parties and 230 understanding their relationships. It may also require identifying 231 trust processes. 233 Participants in a trust transaction may resemble the participants in 234 identity services (see, for example, the OASIS SAML 2.0 glossary 235 [samlgloss]). A trustor may be seen to take on a similar role to 236 that of a relying party, while a trustee may have a parallel role to 237 an identity provider. Both a trustee and an identity provider make 238 authoritative assertions about a subject. 240 Trustors may or may not have an established relationship with a given 241 entity. That is to say, at the time that a transaction is initiated, 242 a trustor may have information about the other party, and they may 243 have an existing business relationship. For example, if you have an 244 account with your bank, you provide them with identifying and other 245 information. When you establish an account with an ISP you are 246 providing them with considerably less information but you are paying 247 them - you are purchasing a service. 249 It is also common to have unilateral relationships, in which one 250 party has knowledge of and is able to authenticate the other party, 251 but the other party has to rely on mediated trust regarding the first 252 party. This is common with banks, for example, where to access your 253 account online you need to present the credentials you've established 254 directly with the bank, while the bank authenticates itself to you 255 using mediated authentication (an X.509 certificate issued by a 256 commercial CA and presented using the TLS protocol). 258 We believe that in this case, trust establishment and bootstrapping, 259 trust auditing, and trust revocation are normal trust lifecycle 260 activities. 262 Where problems seem to arise is in those cases where two entities 263 without an existing relationship attempt to determine whether or not, 264 and to what extent, they may trust each other. With some exceptions 265 (for example, unauthenticated IPsec SAs [RFC5386], or the use of 266 self-signed X.509 certificates), this involves the use of some 267 mediating agent and tends to rely on a transitive trust model. 269 Transitivity in trust is similar to transitivity in mathematics: 270 "Things which are equal to the same thing are equal to one another." 271 (the first of Euclid's Common Notions). When there are transitive 272 trust relationships, if A trusts B and B trusts C, then A trusts C. 274 Quite possibly the most common case of mediated trust on the internet 275 is the use of X.509 [RFC5280]certificates in TLS [RFC5246]. X.509 276 certificates are issued to identify entities, but because of 277 conflation of identity with trust issues are often seen as conveying 278 trust. That is to say, a model in which I trust a given CA to assert 279 identity is, in practice, often a seen as a model in which I trust a 280 given entity based on its CA's assertion of identity. 282 A given user cannot reasonably be expected to have pre-installed end 283 entity certificates for every server she is likely to want to access, 284 and so we have mediated trust based on someone (in this case, a 285 certification authority) making an authoritative statement about the 286 identity of a server, and that statement being verifiable using 287 formal and well-understood (??) validation procedures, walking a 288 chain of trust back to an installed trust anchor. 290 Another example, but one in which communicating entities may be 291 closely related and still not have foreknowledge of one another, is 292 in the use of group keys, as in GDOI [RFC6407] (the Group DOI for 293 IKE). In that case group members share a key, but access to the key 294 (along with key management operations including initial 295 authentication) is mediated through a Group Controller/Key Server. 297 A non-cryptographic example of mediated, transitive trust is in VoIP 298 systems in which a call control server is used. For example, if user 299 Customer A has service with Service A, and is able to authenticate to 300 that service, and Customer B has service with Service B, and is 301 similarly able to authenticate to its service, Customer A is able to 302 talk to Customer B if Service A and Service B know about each other 303 and trust each other. 305 A variation on the mediated, authority-based trust models described 306 above is consensus systems, where an endpoint or user still needs to 307 rely on an external source for the basis for trust decisions, but a 308 trust decision is based on agreement (or not) between a number of 309 parties. If a very large number of parties state that a given entity 310 is trustworthy, with little disagreement, that leads to a different 311 decision from one when there's substantial agreement that a given 312 entity is untrustworthy, or when there's very little agreement (or 313 insufficient data). As of this writing we are not familiar with 314 consensus-based trust models in IETF protocols. 316 5. Problems 318 We believe that these are the major problems with the internet trust 319 infrastructure as commonly used in IETF protocols: 321 o Users, services, and other network elements are often required to 322 make trust decisions about entities with which they have no 323 previous relationship 325 o There is often insufficient information about the practices at and 326 reliability of network entities making identity and attribute 327 assertions 329 o There has been no delegation mechanism to make it clear when one 330 entity is authorized to act on behalf of another entity. OAuth 331 is [3] an authorization mechanism currently under development 332 which may prove to be useful for generalized service delegation. 334 As described in Section 4, we believe that where there are problems 335 related to trust in IETF protocols, it is largely in situations in 336 which participating endpoints have no foreknowledge of one another, 337 or the knowledge is unilateral. 339 This is due at least in part to the familiar problem of conflating 340 authentication - proven identity - with the problem of authorization. 341 In the case where two entities have an existing relationship this is 342 probably reasonable. It is unlikely that the credentials or 343 resources would have been provisioned if the relationship were not 344 authorized. 346 In cases where there is no pre-existing relationship, however, there 347 is frequently insufficient basis to make a trust decision. 348 Transitivity is not appropriate in all cases, and is a genuinely bad 349 idea in many. 351 When a certification authority issues a certificate and signs it, 352 they are making an identity assertion. That may be sufficient for 353 access control decisions when there is local knowledge of the 354 identity being asserted, or when the resources being requested are 355 low-value or not sensitive. The broader problem with identity 356 assertions is that it is not always possible to know how reliable, or 357 trustworthy, a given certification authority or trust anchor is, or 358 what their vetting practices are for verifying a customer's actual 359 identity before issuing a certificate or other credentials. Having a 360 certification authority vouch for an entity's identity is meaningless 361 if the CA is not careful about making sure that an applicant really 362 is who they say they are. Unfortunately it is not often possible to 363 know how reliable a given CA is, or whether or not their vetting 364 practices meet a given set of requirements. 366 In addition to the limitations with the existing internet trust and 367 identity infrastructure, there are some missing components, as well. 368 There isn't always a mechanism to identify the relationship between 369 two entities when one is needed. For example, a utility company 370 (gas, electric, sewer, water) may use a third-party payments company, 371 and when you use the utility's website, when you click the "Pay my 372 bill" button you're taken to the payment company's website. From the 373 underlying identity and trust mechanism it is not possible to 374 determine that there really is a relationship between the utility and 375 the payment company, and that the payment company is authorized to 376 collect money on behalf of the utility. A delegation mechanism is 377 missing. 379 6. Security Considerations 381 This document attempts to describe and identify problem areas related 382 to trust in the internet infrastructure, within IETF scope. As such 383 it does not introduce new mechanisms. However, it should be 384 understood that the problems described in this document do have 385 immediate impact on the security of related mechanisms. 386 Recommendations for remediation are outside the scope of this 387 document. 389 7. Path forward 391 We suggest that there may be value in pursuing discussion of some of 392 the question raised earlier in this document. In particular, 394 o Is there value in a shared understanding or shared definition of 395 what is meant by the word "trust?" 397 o Do we, as an organization, care about clearer descriptions of 398 trust models in IETF protocols? 400 o Do we need to develop a stronger understanding of how to support 401 trust frameworks, or how to develop frameworks in which multiple 402 trust and policy models are used in a given scenario (say, in 403 VoIP, where you may involved DNS, SIP, TLS, STUN, and others in 404 completing a single "call")? 406 o Should we be differentiating between threats introduced by 407 cryptographic or protocol flaws, and threats tied to trust 408 problems? 410 o Does renewed interest in federated and other third-party identity 411 and authorization mechanisms affect organizational priorities 412 around trust issues? 414 o What, if anything, does the IETF need to be doing more generally 415 around questions of trust? 417 8. Informative References 419 [tbss] Aljazzaf, Z., "Trust-Based Service Selection", 420 December 2011, . 423 [ws-trust] 424 "WS-Trust 1.3: OASIS Standard", March 2007, . 428 [samlgloss] 429 "Glossary for the OASIS Security Assertion Markup Language 430 (SAML) V2.0", March 2005, . 433 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 434 RFC 4949, August 2007. 436 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 437 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 439 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 440 Housley, R., and W. Polk, "Internet X.509 Public Key 441 Infrastructure Certificate and Certificate Revocation List 442 (CRL) Profile", RFC 5280, May 2008. 444 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 445 Security: An Unauthenticated Mode of IPsec", RFC 5386, 446 November 2008. 448 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 449 Format", RFC 5914, June 2010. 451 [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 452 Management Protocol (TAMP)", RFC 5934, August 2010. 454 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 455 Requirements", RFC 6024, October 2010. 457 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 458 of Interpretation", RFC 6407, October 2011. 460 [1] 463 [2] 465 [3] 467 Authors' Addresses 469 Melinda Shore 470 No Mountain Software 471 PO Box 16271 472 Two Rivers, AK 99716 473 US 475 Phone: +1 907 322 9522 476 Email: melinda.shore@nomountain.net 478 Karen O'Donoghue 479 ISOC 480 7167 Goby Lane 481 King George, VA 482 US 484 Email: odonoghue@isoc.org