idnits 2.17.00 (12 Aug 2021) /tmp/idnits62292/draft-gutmann-keycont-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 673. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 684. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 697. 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 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 29, 2008) is 4982 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Gutmann 3 Internet-Draft University of Auckland 4 Intended status: BCP September 29, 2008 5 Expires: April 2, 2009 7 Key Management through Key Continuity (KCM) 8 draft-gutmann-keycont-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 2, 2009. 35 Abstract 37 This memo provides advice and Best Current Practice for implementors 38 and deployers of security applications that wish to use the key 39 continuity method of key management. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 45 2. Key Management through Key Continuity . . . . . . . . . . . . 4 46 2.1. Key Continuity in SSH . . . . . . . . . . . . . . . . . . 4 47 2.2. Key Continuity in SSL/TLS and IPsec . . . . . . . . . . . 5 48 2.3. Key Continuity in Other Security Protocols . . . . . . . . 6 49 3. Using Key Continuity for Key Management . . . . . . . . . . . 7 50 3.1. Key Generation . . . . . . . . . . . . . . . . . . . . . . 7 51 3.2. Optional out-of-band Authentication . . . . . . . . . . . 7 52 3.3. Key Rollover . . . . . . . . . . . . . . . . . . . . . . . 8 53 3.4. Key <-> Host/Service Mapping . . . . . . . . . . . . . . . 8 54 3.5. User Interface . . . . . . . . . . . . . . . . . . . . . . 8 55 3.6. Trust Lifetimes . . . . . . . . . . . . . . . . . . . . . 9 56 3.7. Key Hash/Fingerprint Truncation . . . . . . . . . . . . . 9 57 3.8. Key Information Storage . . . . . . . . . . . . . . . . . 10 58 3.9. Key Continuity via External Authorities . . . . . . . . . 11 59 4. Key Continuity Data Storage . . . . . . . . . . . . . . . . . 12 60 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 67 Intellectual Property and Copyright Statements . . . . . . . . . . 20 69 1. Introduction 71 There are many ways of managing the identification of remote 72 entities. One simple but also highly effective method is the use of 73 key continuity, a means of ensuring that that the entity a user is 74 dealing with today is the same as the one they were dealing with last 75 week (this principle is sometimes referred to as continuity of 76 identity). In the case of cryptographic protocols the problem 77 becomes one of determining whether a file server, mail server, online 78 store, or bank that a user dealt with last week is still the same one 79 this week. Using key continuity to verify this means that if the 80 remote entity used a given key to communicate/authenticate itself 81 last week then the use of the same key this week indicates that it's 82 the same entity. This doesn't require any third-party attestation 83 because it can be done directly by comparing last week's key to this 84 week's one. This is the basis for key management through key 85 continuity: Once you've got a known-good key, you can verify a remote 86 entity's identity by verifying that they're still using the same key. 87 This document describes the principles that underly key management 88 through key continuity, and provides guidelines for its use in 89 practice. 91 1.1. Conventions Used in This Document 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. Key Management through Key Continuity 99 In its most basic form, key management through key continuity 100 consists of two steps: 102 Step 1 On the first connection exchange key(s), possibly with 103 additional out-of-band authentication. 104 Step 2 On subsequent connections ensure that the key being used 105 matches the one exchanged initially. 107 In more formal terms, the key continuity method of key management may 108 be regarded as a variation of the baby-duck security model 109 [Duckling1] [Duckling2] in which a newly-initialised device (either 110 one fresh out of the box or one reset to its ground state) imprints 111 upon the first device that it sees in the same way that a newly 112 hatched duckling imprints on the first moving object that it sees as 113 its mother. 115 2.1. Key Continuity in SSH 117 SSH [SSH] was the first widely-used security application that used 118 key continuity as its primary form of key managment. The first time 119 that a user connects to an SSH server, the client application 120 displays a warning that it's been given a new public key that it's 121 never encountered before, and asks the user whether they want to 122 continue. When the user clicks "Yeah, sure, whatever" (although the 123 button is more frequently labelled "OK"), the client application 124 remembers the key that was used, and compares it to future keys used 125 by the server. If the key is the same each time, there's a good 126 chance that it's the same server (SSH terminology refers to this as 127 the known-hosts mechanism). In addition to this SSH allows a user to 128 verify the key via its fingerprint, which can be conveniently 129 exchanged via out-of-band means. The fingerprint is a universal key 130 identifier consisting of the hash of the key components or the hash 131 of the certificate if the key is in the form of a certificate. 133 SSH is the original key-continuity solution, but unfortunately it 134 doesn't provide complete continuity. When the server is rebuilt, the 135 connection to the previous key is lost unless the sysadmin has 136 remembered to archive the configuration and keying information after 137 they set up the server (some OS distributions can migrate keys over 138 during an OS upgrade, so this can vary somewhat depending on the OS 139 and how total the replacement of system components is). Since SSH is 140 often used to secure access to kernel-of-the-week open-source Unix 141 systems the breaking of the chain of continuity can happen more 142 frequently than would first appear. 144 Some of the problem is due to the ease with which an SSH key 145 changeover can occur. In the PKI world this process is so painful 146 that the same key is typically reused and recycled in perpetuity, 147 ensuring key continuity at some cost in security since a compromise 148 of a key recycled over a period of several years compromises all data 149 that the key protected in that time unless a mechanism that provides 150 perfect forward secrecy is used (it rarely is). In contrast an SSH 151 key can be replaced quickly and easily, limiting its exposure to 152 attack but breaking the chain of continuity. A solution to this 153 problem would be to have the server automatically generate and 154 certify key n+1 when key n is taken into use, with key n+1 saved to 155 offline media such as a floppy disk or USB memory token for future 156 use when the system or SSH server is reinstalled/replaced. In this 157 way continuity to the previous, known server key is maintained. 158 Periodically rolling over the key (even without it being motivated by 159 the existing system/server being replaced) is good practice since it 160 limits the exposure of any one key. This would require a small 161 change to the SSH protocol to allow an old-with-new key exchange 162 message to be set after the changeover has occurred. 164 2.2. Key Continuity in SSL/TLS and IPsec 166 Unlike SSH, SSL/TLS [TLS] and IPsec [IPsec] were designed to rely on 167 an external key management infrastructure, although at a pinch both 168 can function without it by using shared keys, typically passwords. 169 The lack of such an infrastructure has been addressed in two ways. 170 In SSL the client (particularly in its most widespread form, the web 171 browser) contains a large collection of hardcoded CA certificates 172 (over a hundred) that are trusted to issue SSL server certificates. 173 Many of these hardcoded CAs are completely unknown, follow dubious 174 practices such as using weak 512-bit keys or keys with 40-year 175 lifetimes, appear moribund, or have had their CA keys on-sold to 176 various third parties when the original owners went out of business 177 [NotDead]. All of these CAs are assigned the same level of trust, 178 which means that the whole system is only as secure as the least 179 secure CA, since compromising or subverting any one of the CAs 180 compromises the entire collection (in PKI terminology what's being 181 implemented is unbounded universal cross-certification among all of 182 the CAs). 184 The second solution, used by both SSL/TLS and IPsec, is to use self- 185 issued certificates where the user acts as their own CA and issues 186 themselves certificates that then have to be installed on client/peer 187 machines. In both cases the security provided is little better than 188 for SSH keys unless the client is careful to disable all CA 189 certificates except for the one or two that they trust, a process 190 that requires around 700 mouse clicks for Internet Explorer 6. A 191 further downside of this is that the client software will now throw 192 up warning dialogs prophesying all manner of doom and destruction 193 when an attempt is made to connect to a server with a certificate 194 from a now-untrusted CA, although research by security usability 195 researchers indicates that invalid or untrusted certificates have 196 little to no effect on users anyway so this is probably not a big 197 deal [Hardening]. 199 The same key-continuity solution used in SSH can be used here, and is 200 already employed by some SSL clients such as MTAs which have to deal 201 with self-issued and similar informal certificates more frequently 202 than other applications such as web servers. This is because of 203 their use in STARTTLS, an extension to SMTP that provides 204 opportunistic TLS-based encryption for mail transfers. Similar 205 facilities exist for other mail protocols such as POP and IMAP, with 206 the mechanism being particularly popular with SMTP server 207 administrators because it provides a means of authenticating 208 legitimate users to prevent misuse by spammers. Since the mail 209 servers are set up and configured by sysadmins rather than commercial 210 organisations worried about adverse user reactions to browser warning 211 dialogs they typically make use of self-issued certificates since 212 there's no point in paying a CA for the same thing. 214 Key continuity management among STARTTLS implementations is still 215 somewhat haphazard. Since STARTTLS is intended to be a completely 216 transparent, fire-and-forget solution, the ideal setup would 217 automatically generate a certificate on the server side when the 218 software is installed and use standard SSH-style key continuity 219 management on the client, with optional out-of-band verification via 220 the key/certificate fingerprint. Some implementations (typically 221 open-source ones) support this fully, some support various aspects of 222 it (for example requiring tedious manual operations for certificate 223 generation or key/certificate verification), and some (typically 224 commercial ones) require the use of certificates from commercial CAs, 225 an even more tedious (and expensive) manual operation. 227 2.3. Key Continuity in Other Security Protocols 229 A similar model is used in SIP, in which the first connection 230 exchanges a (typically) self-signed certificate which is then checked 231 for continuity on subsequent connects. Further measures such as the 232 use of speaker voice recognition can be used to provide additional 233 authentication for the SIP exchange. A similar principle has been 234 used in several secure IP-phone protocols, which (for example) have 235 one side read out a hash of the key over the secure link, relying for 236 its security on the fact that real-time voice spoofing is relatively 237 difficult to perform. 239 3. Using Key Continuity for Key Management 241 Section 2 outlined a number of considerations that need to be taken 242 into account when using key continuity as a form of key management. 243 These are covered in the following subsections. 245 3.1. Key Generation 247 The simplest key-continuity approach automatically (and 248 transparently) generates the key when the application that uses it is 249 installed or configured for the first time. If the underlying 250 protocol uses certificates then the application would generate a 251 standard self-signed certificate at this point, otherwise it can use 252 whatever key format the underlying protocol uses, typically raw 253 public key components encoded in a protocol-specific manner. 255 3.2. Optional out-of-band Authentication 257 If possible, the initial exchange should use additional out-of-band 258 authentication to authenticate the key. A standard technique is to 259 generate a hash or fingerprint of the key and verify the hash through 260 out-of-band means. All standard security protocols have a notion of 261 a key hash in some form, whether it be an X.509 certificate 262 fingerprint, a PGP/OpenPGP [OpenPGP] key fingerprint, or an SSH key 263 fingerprint and the use of key authentication channels such as PGP 264 key fingerprints printed on business cards or in email signatures is 265 a long-established practice. Unfortunately research has shown that 266 this form of authentication is (at least in the case of SSH 267 fingerprints) relatively easily defeated [Fingerprints], see 268 Section 3.9 for a more practical solution to this problem 270 An extended form of this style of authentication has been proposed in 271 the form of cryptoIDs, long-lived fingerprints tied to a (user- 272 controlled) root key that's used to certify sub-keys on demand. The 273 intent of a cryptoID is to associate it with user information such as 274 their name and email address and treat it as a standard part of the 275 user identity data. For example a key change notification would be 276 handled in the same way as an email address change notification, 277 making it part of the standard user information-propagation channels. 279 The out-of-band verification of the hash/fingerprint is done in a 280 situation-specific manner. For example when the key is used in a 281 VoIP application the communicating parties may read the hash value 282 over the link, relying on speaker voice recognition and the 283 difficulty of performing real-time continous-speech spoofing for 284 security. When the key is used to secure access to a network server 285 the hash may be communicated in person, over the phone, printed on a 286 business card, or published in some other well-known location. When 287 the key is used to secure access to a bank server the hash may be 288 communicated using a PIN mailer, or by having the user visit their 289 bank branch. Although it's impossible to enumerate every situation 290 here, applying a modicum of common sense should provide the corerct 291 approach for specific situations. 293 Other distribution mechanisms are also possible. For example when 294 configuring a machine the administrator can pre-install the key 295 information when the operating system is installed, in the same way 296 that many systems come pre-configured with trusted X.509 297 certificates. 299 3.3. Key Rollover 301 When a key needs to be replaced the new key should ideally be 302 authenticated using forward-chaining authentication from the current 303 key. For example if the key is in the form of an X.509 certificate 304 or PGP key, the current key can sign the new key. If the key 305 consists solely of raw key components exchanged during a protocol 306 handshake, this type of forward-chaining authentication isn't 307 possible without modifying the underlying protocol. Protocol 308 designers may wish to take into account the requirements for forward- 309 chaining authentication when designing new protocols or updating 310 existing ones. 312 3.4. Key <-> Host/Service Mapping 314 A key will usually be associated with a service type (for example 315 "SSH" or "TLS"), a host, and a port (typically the port is specified 316 implicitly by the service type, but it may also be specified 317 explicitly if a nonstandard port is used). When storing key 318 continuity data, the service/host/port information should always be 319 stored exactly as seen by the user, without any subsequent expansion, 320 conversion, or other translation. For example if the user knows a 321 host as www.example.com then the key continuity data should be stored 322 under this name, and not under the associated IP address(es). 323 Applying the WYSIWYG principle to the name that the user sees 324 prevents problems with things like virtual hosting (where 325 badguy.example.com has the same IP address as goodguy.example.com), 326 hosts that have been moved to a new IP address, and so on. 328 3.5. User Interface 330 Providing a usable user interface for security features has 331 historically proven to be an extremely difficult undertaking 332 [Phishing]. A feature of key continuity management is that in its 333 simplest form it requires very little UI: if the key crosses a 334 certain trust threshold (length of use, number of times it's been 335 used, rating(s) from an external key continuity authority, and so on) 336 then the connection can be allowed, otherwise it's disallowed. If an 337 external authority is used this becomes particularly simple. 339 Unfortunately this basic strategy may not be suitable in all cases. 340 In particular if no external authority is available or the key is 341 unknown then requiring that the user wait for a set number of days 342 until it's certain that the key doesn't belong to an ephemeral 343 phishing site will no doubt cause user acceptance problems. The 344 general-case key bootstrap problem appears to be an unsolveable one, 345 althoug a great many hypotheses and workable but situation-specific 346 solutions do exist. If should be remembered though that the intent 347 of key continuity management is to ensure key continuity and not key 348 initial authentication. Designing an appropriate user interface for 349 a key continuity mechanism is (as with all security user interface 350 designs) a challenging problem. [Usability] provides extensive 351 guidance on effectively communicating the issues to users, and 352 potential traps and pitfalls to avoid. 354 3.6. Trust Lifetimes 356 Like real-world trust, trust of keys can both increase and decrease 357 over time. In current key trust models, trust is purely boolean, 358 starting out untrusted and then becoming completely trusted for all 359 eternity once the user clicks OK on a dialog requesting that the key 360 be trusted. In the real world trust doesn't work like this, but must 361 be built up over time. Similarly, trust can decay over time. 363 Rather than making trust a purely boolean value, you can remember how 364 many times a key has been safely used of for how long the key has 365 been around and increase or decrease the trust in it over time. For 366 example a new key should be regarded with suspicion unless verified 367 by out-of-band means, which slowly decreases with repeated use. A 368 key that's been used once should have a much lower trust level than 369 one that's been used a hundred times, something that the current 370 boolean model that's typically used with certificates isn't capable 371 of providing. 373 3.7. Key Hash/Fingerprint Truncation 375 The use of the full hash/fingerprint when the authentication process 376 is being performed by humans can be quite cumbersome, requiring the 377 transmission and verification of (for the most common hash algorithm, 378 SHA-1), 40 hex digits. Implementors may consider truncating the hash 379 value to make it easier to work with. For example a 64-bit hash 380 value provides a moderate level of security while still allowing the 381 value to be printed on media such as business cards and communicated 382 and checked by humans. Although such a short hash value isn't secure 383 against an intensive brute-force attack, it is sufficient to stop all 384 but the most dedicated attackers, and certainly far more secure than 385 simply accepting the key at face value as is currently widely done. 386 Implementors should consider the relative merits of usability vs. 387 security when deciding to truncate the key hash/fingerprint. 389 3.8. Key Information Storage 391 Configuration information of this kind is typically stored using a 392 two-level scheme, systemwide information set up when then operating 393 system is installed or configured and managed by the system 394 administrator and per-user information which is private to each user. 395 For example on Unix systems the systemwide configuration data is 396 traditionally stored in /etc or /var, with per-userconfiguration data 397 stored in the user's home directory. Under Windows the systemwide 398 configuration data is stored under an OS service account and the per- 399 user configuration data is stored in the user's registry branch. The 400 systemwide configuration provides an initial known-good set of key 401 <-> identity mappings, with per-user data providing additional user- 402 specific information that doesn't affect any other users on the 403 system. 405 Note that the use of plaintext host names may make the information 406 vulnerable to address harvesting by an attacker who has gained read 407 access to the file, since it identifies remote hosts that the user/ 408 local host software implicitly trusts. For example a worm might use 409 it to identify remote hosts to attack. In addition a plaintext 410 record of sites that a user has interacted with cryptographically may 411 present privacy concerns. [AddressHarvest] contains more information 412 on this type of attack, and possible countermeasures. 414 The key continuity data should be protected by at least OS-level 415 security measures if they are available and if it's regarded as 416 particularly sensitive or if it's used on a shared machine like a 417 home PC where everyone shares the same account then it can be given 418 additional protection through encapsulation in PGP or S/MIME security 419 envelopes or through the use of other cryptographic protection 420 mechanisms such as cryptographic checksums or MACs. When 421 encapsulated using PGP or S/MIME the key data is no longer in its 422 original form and will need to be extracted in order to be used. 423 Alternatively if integrity protection only is considered sufficient 424 then a mechanism like a PGP or S/MIME detached signature can be 425 stored alongside the key data so that the data can be used directly 426 while still allowing it to be verified. 428 3.9. Key Continuity via External Authorities 430 Directly managing key continuity on end-user systems may not always 431 be the best approach to take. For one thing the system needs to 432 manage and record a (potentially unbounded) number of locations that 433 the user has visited, which can be problematic if the system has 434 limited storage capacity, although in practice this is likely to be 435 fairly limited since most users interact with only a very small 436 number of sites that use encryption. A larger concern though is the 437 fact that when the user visits a site that they've never been to 438 before they initially have no key continuity information to rely 439 upon, the key/trust bootstrap problem. 441 The bootstrap problem can be addressed through the use of an external 442 authority to manage the key continuity information. A key continuity 443 external authority records how long a particular key has been in use 444 by a particular cryptographic service and returns this information in 445 response to queries. Note that this differs very significantly from 446 the information that CAs provide. A commercial CA guarantees that 447 money changed hands and that some form of identity checking took 448 place while the only information that a key continuity authority 449 provides is the amount of time that a particular key has been in use 450 by that service. Since the lifetime of a typical phishing site 451 currently runs at around 12 hours (well under the response time of 452 any blacklist or site-rating system), a key continuity authority 453 provides a means of singling out phishing sites and similar short- 454 lived traps for users, making it necessary to operate a phishing site 455 continuously at the same location for a considerable amount of time 456 in order to build up the necessary key continuity history. A key 457 continuity authority therefore implements a form of key whitelist 458 that can be run directly alongside the (relatively ineffective) site 459 blacklists already used by some applications like web browsers. Note 460 that in order to ensure true continuity of use key continuity 461 authorities should re-check keys at random intervals to ensure that a 462 site and its key really are around for the entire time interval and 463 not just during the initial check and the final phish. 465 Use of an external key continuity authority carries with it a variety 466 of aplication- and situation-specific considerations such as which 467 external authority to trust, whether the communications need to be 468 authenticated and/or encrypted or not, potential privacy concerns 469 when using an external authority, tradeoffs of speed/throughput vs. 470 security, and so on. A more detailed analysis may be found in 471 [Perspectives]. 473 4. Key Continuity Data Storage 475 [[Note: This may be better off in its own RFC, although since it's 476 pretty cross-jurisdictional there's no obvious domain to put it 477 under. The main motivation for including it here is to avoid a 478 profusion of incompatible homebrew formats, with applications having 479 to support a mass of oddball variants in order to authenticate keys]] 481 Applications require a standardised means of associating hosts with 482 keys. The following text-based format, inspired by the /etc/passwd 483 format, is recommended for easy exchange of key continuity data 484 across applications. The format of the key data file using using 485 Augmented BNF [ABNF] is as follows. 487 keydata = keydef | comment | blank 489 keydef = algorithm ":" key-hash ":" service ":" host ":" port rfu CRLF 491 comment = "#" *(WSP / VCHAR) CRLF 493 blank = *(WSP) CRLF 495 algorithm = *(ALPHA / DIGIT) 497 key-hash = *(HEXDIG) 499 service = *(ALPHA) 501 host = [wherever this is specified] 503 port = *(DIGIT) / "" 505 rfu = "" / ":" *(WSP / VCHAR) 507 The algorithm field contains the hash/fingerprint algorithm, usually 508 "sha1". This allows multiple hash algorithms to be used for a 509 fingerprint. For example while the current standard algorithm is 510 SHA-1, some legacy implementations may require MD5, and future 511 implementations may use SHA-1 successors. 513 The key-hash field contains the hash/fingerprint of the key. This 514 value may be truncated as described in section 3. When comparing 515 truncated hashes for equality, the first min( hash1_length, 516 hash2_length ) bytes of the two values are compared. 518 The service field specifies the service or protocol that the hash/ 519 fingerprint applies to. For example if both a TLS and and SSH server 520 were running on the same host, the protocol field would be used to 521 distinguish between the key hashes for the two servers. 523 The host-name and (optional) host-port fields contain the host name 524 and port that the key corresponds to. Typically the port is 525 implicitly specified in the service field, but it may also be 526 explicitly specified here. 528 For example a typical key continuity data file might consist of: 530 # Sample key continuity data file 532 sha1:B65427F83CED23A70263F8247C8D94192F751983:tls:www.example.com:443 533 sha1:17A2FE37808F3E84:ssh:ssh.example.com:22 534 md5:B2071C526B19F27C:ssh:ssh.example.com:22 536 The first entry contains the fingerprint of an X.509 certificate used 537 by the web server for www.example.com. The second and third entries 538 contain the (truncated) fingerprint of the SSH key used by the server 539 ssh.example com, first in the standard SHA-1 format and then in the 540 alternative MD5 format. 542 5. Discussion 544 The intent of this format is to follow the widely-used and recognised 545 /etc/passwd file format with which many users will be familiar. The 546 format has been kept deliberately simple in order to avoid designing 547 a general-purpose security assertion language such as KeyNote 548 [KeyNote] or SAML [SAML]. While this will no doubt not suit all 549 users, it should suffice for most, while remaining simple enough to 550 encourage widespread adoption. 552 There are two options available for storing the key-continuity data, 553 the single-file format described above, and one entry per file. The 554 latter makes it possible to use mechanisms like rsync to update 555 individual entries/files across systems, but leads to an explosion of 556 hard-to-manage tiny files, each containing a little piece of 557 configuration data. It also makes it impossible to secure the 558 configuration data via mechanisms such as PGP or S/MIME. Finally, 559 the number of users who would use rsync to manage these files, when 560 compared to the total user base, is essentially nonexistent. For 561 this reason the single-file approach is preferred. 563 6. Security Considerations 565 Publishing a BCP on the topic of key/trust verification may make the 566 authors a lightning rod for complaints of the form "this is just 567 pretend security, you really need a ". 570 7. IANA Considerations 572 This document has no IANA Actions. 574 8. References 576 8.1. Normative References 578 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 579 Specifications: ABNF", RFC 4234, October 2005. 581 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 582 Requirement Levels", BCP 14, RFC 2119, March 1997. 584 8.2. Informative References 586 [AddressHarvest] 587 Schechter, S., Jung, J., Stockwell, W., and C. McLain, 588 "Inoculating SSH Against Address-Harvesting", Proceedings 589 of the 2006 Network and Distributed Systems Security 590 Symposium 2006, February 2006. 592 [Duckling1] 593 Stajano, F. and R. Anderson, "The Resurrecting Duckling: 594 Security Issues in Ad-Hoc Wireless Networking", 595 Proceedings of the 7th International Workshop on Security 596 Protocols 1999, Springer-Verlag Lecture Notes in Computer 597 Science 1796, April 1999. 599 [Duckling2] 600 Stajano, F., "The Resurrecting Duckling - What Next?", 601 Proceedings of the 8th International Workshop on Security 602 Protocols 2000, Springer-Verlag Lecture Notes in Computer 603 Science 2133, April 2000. 605 [Fingerprints] 606 "Fuzzy Fingerprints: Attacking Vulnerabilities in the 607 Human Brain", October 2003. 609 [Hardening] 610 Xia, H. and J. Brustoloni, "Hardening Web Browsers Against 611 Man-in-the-Middle and Eavesdropping Attacks", Proceedings 612 of the 14th International World Wide Web Conference 2005, 613 May 2005. 615 [IPsec] Kent, S. and K. Seo, "Security Architecture for the 616 Internet Protocol", RFC 4301, December 2005. 618 [KeyNote] Blaze, M., Feigenbaum, J., Ioannidis, J., and A. 619 Keromytis, "The KeyNote Trust-Management System Version 620 2", RFC 2704, September 1999. 622 [NotDead] Gutmann, P., "PKI: It's Not Dead, Just Resting", IEEE 623 Computer August 2002, August 2002. 625 [OpenPGP] Callas, J., Donnerhacke, L., Hal, H., Shaw, D., and R. 626 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 628 [Perspectives] 629 Wendlandt, D., Andersen, D., and A. Perrig, "Perspectives: 630 Improving SSH-style Host Authentication with Multi-Path 631 Probing", Proceedings of the 2008 USENIX Annual Technical 632 Conference 2008, June 2008. 634 [Phishing] 635 Jakobsson, M., Ed. and S. Myers, Ed., "Phishing and 636 Countermeasures", 2007. 638 [SAML] "Security Assertion Markup Language (SAML), Version 2.0", 639 2008. 641 [SSH] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 642 Transport Layer Protocol", RFC 4253, Janaury 2006. 644 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 645 (TLS) Protocol", RFC 4346, April 2006. 647 [Usability] 648 Gutmann, P., "Security Usability", September 2008. 650 Author's Address 652 Peter Gutmann 653 University of Auckland 654 Department of Computer Science 655 New Zealand 657 Email: pgut001@cs.auckland.ac.nz 659 Full Copyright Statement 661 Copyright (C) The IETF Trust (2008). 663 This document is subject to the rights, licenses and restrictions 664 contained in BCP 78, and except as set forth therein, the authors 665 retain all their rights. 667 This document and the information contained herein are provided on an 668 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 669 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 670 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 671 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 672 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 673 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 675 Intellectual Property 677 The IETF takes no position regarding the validity or scope of any 678 Intellectual Property Rights or other rights that might be claimed to 679 pertain to the implementation or use of the technology described in 680 this document or the extent to which any license under such rights 681 might or might not be available; nor does it represent that it has 682 made any independent effort to identify any such rights. Information 683 on the procedures with respect to rights in RFC documents can be 684 found in BCP 78 and BCP 79. 686 Copies of IPR disclosures made to the IETF Secretariat and any 687 assurances of licenses to be made available, or the result of an 688 attempt made to obtain a general license or permission for the use of 689 such proprietary rights by implementers or users of this 690 specification can be obtained from the IETF on-line IPR repository at 691 http://www.ietf.org/ipr. 693 The IETF invites any interested party to bring to its attention any 694 copyrights, patents or patent applications, or other proprietary 695 rights that may cover technology that may be required to implement 696 this standard. Please address the information to the IETF at 697 ietf-ipr@ietf.org.