idnits 2.17.1 draft-ietf-secsh-dns-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (April 2, 2003) is 7687 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 normative reference: RFC 2535 (ref. '4') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-22) exists of draft-ietf-secsh-architecture-13 == Outdated reference: A later version (-24) exists of draft-ietf-secsh-transport-15 -- Obsolete informational reference (is this intentional?): RFC 2411 (ref. '7') (Obsoleted by RFC 6071) -- Obsolete informational reference (is this intentional?): RFC 2845 (ref. '8') (Obsoleted by RFC 8945) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Shell Working Group J. Schlyter 3 Internet-Draft Carlstedt Research & 4 Expires: October 1, 2003 Technology 5 W. Griffin 6 Network Associates Laboratories 7 April 2, 2003 9 Using DNS to securely publish SSH key fingerprints 10 draft-ietf-secsh-dns-04.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 1, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This document describes a method to verify SSH host keys using 41 DNSSEC. The document defines a new DNS resource record that contains 42 a standard SSH key fingerprint. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. SSH Host Key Verification . . . . . . . . . . . . . . . . . 3 48 2.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2.2 Implementation Notes . . . . . . . . . . . . . . . . . . . . 3 50 2.3 Fingerprint Matching . . . . . . . . . . . . . . . . . . . . 4 51 2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. The SSHFP Resource Record . . . . . . . . . . . . . . . . . 4 53 3.1 The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . . 4 54 3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . . 5 55 3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . . 5 56 3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.2 Presentation Format of the SSHFP RR . . . . . . . . . . . . 6 58 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 60 Normative References . . . . . . . . . . . . . . . . . . . . 8 61 Informational References . . . . . . . . . . . . . . . . . . 8 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 63 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 64 Intellectual Property and Copyright Statements . . . . . . . 10 66 1. Introduction 68 The SSH [5] protocol provides secure remote login and other secure 69 network services over an insecure network. The security of the 70 connection relies on the server authenticating itself to the client. 72 Server authentication is normally done by presenting the fingerprint 73 of an unknown public key to the user for verification. If the user 74 decides the fingerprint is correct and accepts the key, the key is 75 saved locally and used for verification for all following 76 connections. While some security-conscious users verify the 77 fingerprint out-of-band before accepting the key, many users blindly 78 accepts the presented key. 80 The method described here can provide out-of-band verification by 81 looking up a fingerprint of the server public key in the DNS [1][2] 82 and using DNSSEC [4] to verify the lookup. 84 In order to distribute the fingerprint using DNS, this document 85 defines a new DNS resource record to carry the fingerprint. 87 Basic understanding of the DNS system [1][2] and the DNS security 88 extensions [4] is assumed by this document. 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [3]. 94 2. SSH Host Key Verification 96 2.1 Method 98 Upon connection to a SSH server, the SSH client MAY look up the SSHFP 99 resource record(s) for the host it is connecting to. If the 100 algorithm and fingerprint of the key received from the SSH server 101 matches the algorithm and fingerprint of one of the SSHFP resource 102 record(s) returned from DNS, the client MAY accept the identity of 103 the server. 105 2.2 Implementation Notes 107 Client implementors SHOULD provide a configurable policy used to 108 select the order of methods used to verify a host key. This document 109 defines one method: Fingerprint storage in DNS. Another method 110 defined in the SSH Architecture [5] uses local files to store keys 111 for comparison. Other methods that could be defined in the future 112 might include storing fingerprints in LDAP or other databases. A 113 configurable policy will allow administrators to determine which 114 methods they want to use and in what order the methods should be 115 prioritized. This will allow administrators to determine how much 116 trust they want to place in the different methods. 118 One specific scenario for having a configurable policy is where 119 clients do not use fully qualified host names to connect to servers. 120 In this scenario, the implementation SHOULD verify the host key 121 against a local database before verifying the key via the fingerprint 122 returned from DNS. This would help prevent an attacker from injecting 123 a DNS search path into the local resolver and forcing the client to 124 connect to a different host. 126 2.3 Fingerprint Matching 128 The public key and the SSHFP resource record are matched together by 129 comparing algorithm number and fingerprint. 131 The public key algorithm and the SSHFP algorithm number MUST 132 match. 134 A message digest of the public key, using the message digest 135 algorithm specified in the SSHFP fingerprint type, MUST match the 136 SSH FP fingerprint. 138 2.4 Authentication 140 A public key verified using this method MUST only be trusted if the 141 SSHFP resource record (RR) used for verification was authenticated by 142 a trusted SIG RR. 144 Clients that do not validate the DNSSEC signatures themselves MUST 145 use a secure transport, e.g. TSIG [8], SIG(0) [9] or IPsec [7], 146 between themselves and the entity performing the signature 147 validation. 149 3. The SSHFP Resource Record 151 The SSHFP resource record (RR) is used to store a fingerprint of a 152 SSH public host key that is associated with a Domain Name System 153 (DNS) name. 155 The RR type code for the SSHFP RR is TBA. 157 3.1 The SSHFP RDATA Format 159 The RDATA for a SSHFP RR consists of an algorithm number, fingerprint 160 type and the fingerprint of the public host key. 162 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 163 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | algorithm | fp type | / 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 167 / / 168 / fingerprint / 169 / / 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 3.1.1 Algorithm Number Specification 174 This algorithm number octet describes the algorithm of the public 175 key. The following values are assigned: 177 Value Algorithm name 178 ----- -------------- 179 0 reserved 180 1 RSA 181 2 DSS 183 Reserving other types requires IETF consensus. 185 3.1.2 Fingerprint Type Specification 187 The fingerprint type octet describes the message-digest algorithm 188 used to calculate the fingerprint of the public key. The following 189 values are assigned: 191 Value Fingerprint type 192 ----- ---------------- 193 0 reserved 194 1 SHA-1 196 Reserving other types requires IETF consensus. For interoperability 197 reasons, as few fingerprint types as possible should be reserved. 198 The only reason to reserve additional types is to increase security. 200 3.1.3 Fingerprint 202 The fingerprint is calculated over the public key blob as described 203 in [6]. 205 The message-digest algorithm is presumed to produce an opaque octet 206 string output which is placed as-is in the RDATA fingerprint field. 208 3.2 Presentation Format of the SSHFP RR 210 The presentation format of the SSHFP resource record consists of two 211 numbers (algorithm and fingerprint type) followed by the fingerprint 212 itself presented in hex, e.g: 214 host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890 216 4. Security Considerations 218 Currently, the amount of trust a user can realistically place in a 219 server key is proportional to the amount of attention paid to 220 verifying that the public key presented actually corresponds to the 221 private key of the server. If a user accepts a key without verifying 222 the fingerprint with something learned through a secured channel, the 223 connection is vulnerable to a man-in-the-middle attack. 225 The approach suggested here shifts the burden of key checking from 226 each user of a machine to the key checking performed by the 227 administrator of the DNS recursive server used to resolve the host 228 information. Hopefully, by reducing the number of times that keys 229 need to be verified by hand, each verification is performed more 230 completely. Furthermore, by requiring an administrator do the 231 checking, the result may be more reliable than placing this task in 232 the hands of an application user. 234 The overall security of using SSHFP for SSH host key verification is 235 dependent on detailed aspects of how verification is done in SSH 236 implementations. One such aspect is in which order fingerprints are 237 looked up (e.g. first checking local file and then SSHFP). We note 238 that in addition to protecting the first-time transfer of host keys, 239 SSHFP can optionally be used for stronger host key protection. 241 If SSHFP is checked first, new SSH host keys may be distributed by 242 replacing the corresponding SSHFP in DNS. 244 If SSH host key verification can be configured to require SSHFP, 245 we can implement SSH host key revocation by removing the 246 corresponding SSHFP from DNS. 248 As stated in Section 2.2, we recommend that SSH implementors provide 249 a policy mechanism to control the order of methods used for host key 250 verification. One specific scenario for having a configurable policy 251 is where clients use unqualified host names to connect to servers. In 252 this case, we recommend that SSH implementations check the host key 253 against a local database before verifying the key via the fingerprint 254 returned from DNS. This would help prevent an attacker from injecting 255 a DNS search path into the local resolver and forcing the client to 256 connect to a different host. 258 A different approach to solve the DNS search path issue would be for 259 clients to use a trusted DNS search path, i.e., one not acquired 260 through DHCP or other autoconfiguration mechanisms. Since there is no 261 way with current DNS lookup APIs to tell whether a search path is 262 from a trusted source, the entire client system would need to be 263 configured with this trusted DNS search path. 265 Another dependency is on the implementation of DNSSEC itself. As 266 stated in Section 2.4, we mandate the use of secure methods for 267 lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This 268 is especially important if SSHFP is to be used as a basis for host 269 key rollover and/or revocation, as described above. 271 Since DNSSEC only protects the integrity of the host key fingerprint 272 after it is signed by the DNS zone administrator, the fingerprint 273 must be transferred securely from the SSH host administrator to the 274 DNS zone administrator. This could be done manually between the 275 administrators or automatically using secure DNS dynamic update [10] 276 between the SSH server and the nameserver. We note that this is no 277 different from other key enrollment situations, e.g. a client sending 278 a certificate request to a certificate authority for signing. 280 5. IANA Considerations 282 IANA needs to allocate a RR type code for SSHFP from the standard RR 283 type space (type 44 requested). 285 IANA needs to open a new registry for the SSHFP RR type for public 286 key algorithms. Defined types are: 288 0 is reserved 289 1 is RSA 290 2 is DSA 292 Adding new reservations requires IETF consensus. 294 IANA needs to open a new registry for the SSHFP RR type for 295 fingerprint types. Defined types are: 297 0 is reserved 298 1 is SHA-1 300 Adding new reservations requires IETF consensus. 302 Normative References 304 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 305 13, RFC 1034, November 1987. 307 [2] Mockapetris, P., "Domain names - implementation and 308 specification", STD 13, RFC 1035, November 1987. 310 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 311 Levels", BCP 14, RFC 2119, March 1997. 313 [4] Eastlake, D., "Domain Name System Security Extensions", RFC 314 2535, March 1999. 316 [5] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH 317 Protocol Architecture", draft-ietf-secsh-architecture-13 (work 318 in progress), September 2002. 320 [6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. 321 Lehtinen, "SSH Transport Layer Protocol", 322 draft-ietf-secsh-transport-15 (work in progress), September 323 2002. 325 Informational References 327 [7] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document 328 Roadmap", RFC 2411, November 1998. 330 [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 331 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 332 2845, May 2000. 334 [9] Eastlake, D., "DNS Request and Transaction Signatures ( 335 SIG(0)s)", RFC 2931, September 2000. 337 [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic 338 Update", RFC 3007, November 2000. 340 Authors' Addresses 342 Jakob Schlyter 343 Carlstedt Research & Technology 344 Stora Badhusgatan 18-20 345 Goteborg SE-411 21 346 Sweden 348 EMail: jakob@crt.se 349 URI: http://www.crt.se/~jakob/ 350 Wesley Griffin 351 Network Associates Laboratories 352 15204 Omega Drive Suite 300 353 Rockville, MD 20850 354 USA 356 EMail: wgriffin@tislabs.com 357 URI: http://www.nailabs.com/ 359 Appendix A. Acknowledgements 361 The authors gratefully acknowledges, in no particular order, the 362 contributions of the following persons: 364 Martin Fredriksson 366 Olafur Gudmundsson 368 Edward Lewis 370 Bill Sommerfeld 372 Intellectual Property Statement 374 The IETF takes no position regarding the validity or scope of any 375 intellectual property or other rights that might be claimed to 376 pertain to the implementation or use of the technology described in 377 this document or the extent to which any license under such rights 378 might or might not be available; neither does it represent that it 379 has made any effort to identify any such rights. Information on the 380 IETF's procedures with respect to rights in standards-track and 381 standards-related documentation can be found in BCP-11. Copies of 382 claims of rights made available for publication and any assurances of 383 licenses to be made available, or the result of an attempt made to 384 obtain a general license or permission for the use of such 385 proprietary rights by implementors or users of this specification can 386 be obtained from the IETF Secretariat. 388 The IETF invites any interested party to bring to its attention any 389 copyrights, patents or patent applications, or other proprietary 390 rights which may cover technology that may be required to practice 391 this standard. Please address the information to the IETF Executive 392 Director. 394 Full Copyright Statement 396 Copyright (C) The Internet Society (2003). All Rights Reserved. 398 This document and translations of it may be copied and furnished to 399 others, and derivative works that comment on or otherwise explain it 400 or assist in its implementation may be prepared, copied, published 401 and distributed, in whole or in part, without restriction of any 402 kind, provided that the above copyright notice and this paragraph are 403 included on all such copies and derivative works. However, this 404 document itself may not be modified in any way, such as by removing 405 the copyright notice or references to the Internet Society or other 406 Internet organizations, except as needed for the purpose of 407 developing Internet standards in which case the procedures for 408 copyrights defined in the Internet Standards process must be 409 followed, or as required to translate it into languages other than 410 English. 412 The limited permissions granted above are perpetual and will not be 413 revoked by the Internet Society or its successors or assignees. 415 This document and the information contained herein is provided on an 416 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 417 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 418 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 419 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 420 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 422 Acknowledgement 424 Funding for the RFC Editor function is currently provided by the 425 Internet Society.