idnits 2.17.1 draft-johansson-pk-trust-alts-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 6, 2009) is 5379 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-radext-radsec-04 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Johansson 3 Internet-Draft SUNET 4 Intended status: Informational July 6, 2009 5 Expires: January 7, 2010 7 Simple Public Key Trust Alternatives 8 draft-johansson-pk-trust-alts-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 7, 2010. 33 Copyright Notice 35 Copyright (c) 2009 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 in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes often used patterns for establishing 47 technical trust for public key-based security architectures other 48 than traditional PKIX-based public key infrastructure. The intent is 49 that this document be useful as a reference for protocol 50 specification authors who use technology like PKIX, PGP or S/MIME as 51 part of their protocols. 53 Table of Contents 55 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction and motiviation . . . . . . . . . . . . . . . . . 4 57 3. PKIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4. Simple Public Key Trust Alternatives . . . . . . . . . . . . . 7 59 4.1. The role of X.509 certificates . . . . . . . . . . . . . . 7 60 4.2. Manually Shared Public Keys . . . . . . . . . . . . . . . 7 61 4.3. Leap-of-faith Shared Public Keys . . . . . . . . . . . . . 8 62 4.4. Authenticated Bag-of-Keys . . . . . . . . . . . . . . . . 8 63 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 5.1. SAML Metadata . . . . . . . . . . . . . . . . . . . . . . 10 65 5.2. DNSSEC Trust Bridge . . . . . . . . . . . . . . . . . . . 10 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 70 8.2. Informational References . . . . . . . . . . . . . . . . . 13 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 1. Terminology 75 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" 76 and "MAY" that appear in this document are to be interpreted as 77 described in [RFC2119] 79 2. Introduction and motiviation 81 Several protocols introduced by the IETF aswell as by by other SDOs 82 employ public key-based technology in various ways - notably in order 83 to protect messages or channels, eg using security technology like 84 S/MIME, PGP or TLS. Notable examples include SIP, XMPP aswell as 85 calendaring and scheduling protocols and several WebSSO technologies 86 including SAML and OpenID. 88 A common problem facing these protocols is how to establish technical 89 trust between protocol endpoints in the absence of a canonical 90 internet-wide PKI. 92 This document only deals with technical trust, i.e artifacts and 93 entities used to establish secure channels between protocol 94 endpoints. Arguably there are larger issues involved in the general 95 concept of "trust" but this falls outside the scope of this document. 97 Furthermore this document does not attempt to describe new design for 98 technical trust but rather focuses on what can be achieved using 99 common existing protocols, implementations and toolchains. 101 Quite often the problem of establishing technical trust for public- 102 key technologies is presented as a simple market problem. The theory 103 is that since public Certificate Authorities (CAs) exist and are 104 readily available, their products are a simple answer to the question 105 of how to establish technical trust between (say) TLS endpoints. 107 Economy does play a role in trust. Most commercial CAs sell several 108 products where the price of the certificate is related to the cost of 109 identity vetting that is performed so clearly there is a relationship 110 between the amount of work that is spent on vetting and due diligence 111 and the value of the trust represented by the technical trust bearer 112 (eg X.509 certificate) that is produced. 114 Quite often it is desirable to establish technical trust between a 115 small group of entities, excluding all others with a high degree of 116 certainty. This is also known as a "ring of trust". For instance a 117 private CA could be used to represent trust in a set of properties 118 shared by all entities issued keys from the CA - for instance that 119 all key holders represent the same type of organization or that they 120 all represent the same class of service. The value of the CA is in 121 the vetting and due diligence done to insure that the set of of 122 certificates issued from the CA is isomorphic to a proper subset of 123 entities having the given property. 125 Rather than being a simple question of "how much" vetting/due 126 diligence was done before signing a certificate we see that trust 127 often depends on specific contextual validation ("does this endpoint 128 have property X?") for which no market exists in general since the 129 size of these rings of trust are often small compared to the number 130 of customers of most commercial CAs. 132 One problem with the single PKI model is that entities often need to 133 participate in transactions within multiple contexts joining multiple 134 rings of trust. The various ways in which multiple contexts can be 135 represented using PKIX (eg naming constraints or 'bridge' CAs) are 136 either not widely implemented or suffer from interoperability 137 problems making them somewhat impractical. 139 This is not to say that traditional PKIX technology does not have a 140 role to play still. Some of the strategies described in this 141 protocol can be seen as extensions building on top of traditional PKI 142 which remain an important tool. 144 3. PKIX 146 TODO: Overview of bridge/cross PKI. 148 4. Simple Public Key Trust Alternatives 150 4.1. The role of X.509 certificates 152 An X.509 certificate can carry lots of semantics using its names and 153 extensions. It is also possible to treat an X.509 certificate as a 154 simple public key container, disregarding any other element in the 155 certificate. Validation for such "raw key" certificates MUST be 156 limited to comparing the public key or key fingerprint with a copy of 157 the public key received from a trusted source. Used this way an 158 X.509 certificate can be used with most existing PKIX implementations 159 by altering the way certificate validation is performed. 161 While it may seem easier (and cleaner) to handle raw keys directly 162 this is seldom supported in existing implementations. 164 4.2. Manually Shared Public Keys 166 Arguably the simplest form of trust is derived from manually sharing 167 keys. This can easily implemented using any X.509 certificates 168 (which do not necessarily have to be self-signed) serving as public 169 key bearers. In order to support this model it MUST be possible to 170 validate endpoints using key values or key fingerprints. Exactly how 171 the keys are established and updated is out of scope for this simple 172 model. 174 An example is RADIUS over TCP. Traditionally RADIUS uses a shared- 175 secret model where RADIUS clients and servers are each given (out of 176 band) a secret which must be shared among parties who need to 177 communicate with each other. RADIUS uses UDP. Recent work has 178 extended RADIUS to use TCP ([I-D.ietf-radext-radsec]) and TLS for 179 securing communication between RADIUS endpoints. 181 Distributing self-signed X.509 certificates and validating peers 182 using their raw keys or key fingerprints is in this context 183 semantically equivalent to managing traditional RADIUS shared 184 secrets. 186 This begs the question of why a PKI isn't a better alternative than 187 self-signed X.509 certificates used as raw key bearers. From a 188 theoretical perspective a PKI might be preferable to manually sharing 189 keys but practical deployment experience shows that it is very 190 uncommon for RADIUS servers only to be part of a single business 191 relationship which would lead to the requirement to deploy bridge or 192 cross CA between the PKIX PKIs representing the various relationships 193 a RADIUS server may be part of. 195 Deploying bridge CAs constitutes overhead which may be difficult to 196 justify when the scale of the business relationships (number of 197 relationships and number of members in each ring of trust) is small. 198 By comparison manually sharing (possibly self-signed) certificate is 199 good enough for many situations. 201 4.3. Leap-of-faith Shared Public Keys 203 Certain protocols such as Secure Shell ([RFC4251] and [RFC4253]) and 204 BTNS ([RFC5386]) allow security associations to be established by the 205 so called leap-of-faith model where an initial association is 206 established with little or no prior trust. Subsequent associations 207 to the same endpoint is by contrast required to be authenticated 208 using keys or other artifacts exchanged during the first association. 210 For instance Secure Shell associates endpoints (Secure Shell servers) 211 with key fingerprints. When an SSH client opens a connection to the 212 server fingerprints MUST match or the user is notified and forced to 213 take action to manually authenticate the (possibly valid) new key. 215 The Secure Shell leap-of-faith authentication can be generalized to a 216 pattern for public key sharing: Protocols implementing this pattern 217 MUST provide mechanisms for endpoints to publish their keys or key 218 fingerprints or include them in protocol messages. 220 The first time a trust relationship is needed the keys or 221 fingerprints are associated with a representation of the endpont (eg 222 URL or hostname). If the endpoint subsequently publishes a different 223 (set of) keys or fingerprints the trust relationship MUST be 224 invalidated and a manual process MUST resolve if this was a valid key 225 roll-over or an attack. 227 4.4. Authenticated Bag-of-Keys 229 A variation of manually shared public keys, the bag-of-keys approach 230 is similar to a traditional X.509 Certificate Authority but with a 231 few important operational differences. 233 The bag-of-keys is a data structure (eg XML, DNS resource records, 234 ASN.1, etc) containing encoded representation of keys (either raw 235 keys, X.509 certificates or in some cases fingerprints of keys). The 236 data structure MUST be authenticated for instance using one or more 237 digital signatures and it is from this authentication that trust in 238 the contained keys is derived. 240 Trust in the authentication (eg the signing keys) can be established 241 using manually sharing the corresponding public keys (cf above) or by 242 any other means, including the mechanisms described in this document. 243 Below we'll see how DNSSEC fits into this picture. 245 By including a time-to-live parameter for the embedded keys or 246 fingerprints in the data structure itself the consumer of the keys 247 can easily determine for how long it is safe to cache the keys in the 248 data structure. 250 There are several operationally significant differences between a 251 authenticated bag-of-keys and a traditional CA: 253 o The data structure can describe its own validity to consumers 254 which eliminates the need for revocation infrastructure (eg CRLs 255 or OCSP) - the bag-of-keys is both a CA and a CRL of sorts. 256 Regular updates of the bag-of-keys replaces the need for validity 257 checks. 259 o Most signature representation (eg XML-DSig or CMS) allows for 260 multiple separate signatures on a single object. Using this 261 mechanism to authenticate the bag-of-keys data structure it is 262 possible to represent multiple trust relationships on single bag- 263 of-keys. 265 o It is possible to assign multiple keys (with different life-times 266 for instance) to a given entity in the bag-of-keys allowing for a 267 simple roll-over mechanism. 269 o Keys contained in the bag-of-keys can be used to configure the 270 validation-engine at a time separate from when these keys are used 271 - i.e validation is done at configure-time rather than at run- 272 time. This may seem like a relatively minor point but deployment 273 experience from web federated identity shows this to be an 274 important simplification. 276 5. Examples 278 5.1. SAML Metadata 280 The Security Assertion Markup Language (SAML) is a set of protocols 281 and protocol bindings used to communicate information about 282 authentication and authorization between peers. Communication is in 283 the form of XML-based messages. Security is either derived from 284 security at the message-transport layer (eg TLS) or XML digital 285 signatures of the XML messages. In both cases SAML employs various 286 means of establishing technical trust between peers. 288 Information about SAML entities (protocol endpoints and bindings) is 289 sometimes described using SAML metadata which is used by protocol 290 endpoints and supporting infrastructure. An important part of SAML 291 metadata is to describe the entity-to-key mapping which can be done 292 either by giving the name of a key (eg the name of a certificate) or 293 by embedding the key itself. 295 Embedding keys in metadata (which is then signed using XML-DSig) is 296 an example of the bag-of-keys pattern described above. 298 5.2. DNSSEC Trust Bridge 300 DNSSEC [RFC4033], [RFC4034], [RFC4035] is a mechanism for securing 301 data in the domain name system (DNS). By introducing new (or reusing 302 existing) resource records it is possible to use DNSSEC to provide a 303 measure of authentication for any data than can be represented stored 304 and queried from the DNS. 306 For instance [RFC4255] describes a way to store Secure Shell ( 307 [RFC4251] and [RFC4253]) fingerprints in DNS and a semantics for the 308 trust derived from such fingerprints when stored in Secure DNS. 309 Other examples include [RFC4398] (certificates in the DNS) and 310 [RFC4025] (IPSec keying material). 312 We can think of these cases as examples of the authenticated bag-of- 313 keys pattern where DNSSEC authenticates the keys (or fingerprints of 314 keys) represented as DNS resource records. 316 6. Security Considerations 318 Revocation is an important part of key management. Experience shows 319 that it is sometimes quite difficult to achieve large-scale 320 deployment of revocation infrastructure. The authentication bag-of- 321 keys pattern does not include revocation but instead relies on the 322 consumer regularly refreshing the data structure. Should the 323 consumer fail to do that there is an increased risk of key 324 compromise. 326 Leap-of-faith key sharing is vulnerable to user fatigue - presenting 327 a user with questions about security associations when the user only 328 wants to "get to his/her stuff" clearly hasn't worked so far. 330 Implementors of leap-of-faith patterns should strongly consider not 331 allowing users to make decisions about security associations at all 332 or at least not to present such decisions as problems to be overcome 333 before the user can access resources. 335 7. IANA Considerations 337 None 339 8. References 341 8.1. Normative References 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, March 1997. 346 8.2. Informational References 348 [I-D.ietf-radext-radsec] 349 Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 350 "TLS encryption for RADIUS over TCP (RadSec)", 351 draft-ietf-radext-radsec-04 (work in progress), 352 March 2009. 354 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 355 Material in DNS", RFC 4025, March 2005. 357 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 358 Rose, "DNS Security Introduction and Requirements", 359 RFC 4033, March 2005. 361 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 362 Rose, "Resource Records for the DNS Security Extensions", 363 RFC 4034, March 2005. 365 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 366 Rose, "Protocol Modifications for the DNS Security 367 Extensions", RFC 4035, March 2005. 369 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 370 Protocol Architecture", RFC 4251, January 2006. 372 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 373 Transport Layer Protocol", RFC 4253, January 2006. 375 [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely 376 Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, 377 January 2006. 379 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 380 System (DNS)", RFC 4398, March 2006. 382 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 383 Security: An Unauthenticated Mode of IPsec", RFC 5386, 384 November 2008. 386 Author's Address 388 Leif Johansson 389 SUNET 391 Email: leifj@sunet.se 392 URI: http://www.sunet.se