idnits 2.17.1 draft-ietf-secsh-dns-03.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 (March 25, 2003) is 7696 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 -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- 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 (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Secure Shell Working Group J. Schlyter 2 Internet-Draft Carlstedt Research & 3 Expires: September 23, 2003 Technology 4 W. Griffin 5 Network Associates Laboratories 6 March 25, 2003 8 Using DNS to securely publish SSH key fingerprints 9 draft-ietf-secsh-dns-03.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-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 http:// 26 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 September 23, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document describes a method to verify SSH host keys using 40 DNSSEC. The document defines a new DNS resource record that contains 41 a standard SSH key fingerprint. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. SSH Host Key Verification . . . . . . . . . . . . . . . . . 3 47 2.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2.2 Implementation Notes . . . . . . . . . . . . . . . . . . . . 3 49 2.3 Fingerprint Matching . . . . . . . . . . . . . . . . . . . . 4 50 2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. The SSHFP Resource Record . . . . . . . . . . . . . . . . . 4 52 3.1 The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . . 4 53 3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . . 4 54 3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . . 5 55 3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2 Presentation Format of the SSHFP RR . . . . . . . . . . . . 5 57 4. Security Considerations . . . . . . . . . . . . . . . . . . 5 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 59 Normative References . . . . . . . . . . . . . . . . . . . . 7 60 Informational References . . . . . . . . . . . . . . . . . . 8 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 62 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 63 Intellectual Property and Copyright Statements . . . . . . . 10 65 1. Introduction 67 The SSH [5] protocol provides secure remote login and other secure 68 network services over an insecure network. The security of the 69 connection relies on the server authenticating itself to the client. 71 Server authentication is normally done by presenting the fingerprint 72 of an unknown public key to the user for verification. If the user 73 decides the fingerprint is correct and accepts the key, the key is 74 saved locally and used for verification for all following 75 connections. While some security-conscious users do verify the 76 fingerprint out-of-band before accepting the key, the average user 77 usually blindly accepts the key presented. 79 The method described here can provide out-of-band verification by 80 looking up a fingerprint of the server public key in the DNS [1][2] 81 and using DNSSEC [4] to verify the lookup. 83 In order to distribute the fingerprint using DNS, this document 84 defines a new DNS resource record to carry the fingerprint. 86 Basic understanding of the DNS system [1][2] and the DNS security 87 extensions [4] is assumed by this document. 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [3]. 93 2. SSH Host Key Verification 95 2.1 Method 97 Upon connection to a SSH server, the SSH client MAY look up the SSHFP 98 resource record(s) for the host it is connecting to. If the 99 algorithm and fingerprint of the key received from the SSH server 100 matches the algorithm and fingerprint of one of the SSHFP resource 101 record(s) returned from DNS, the client MAY accept the identity of 102 the server. 104 2.2 Implementation Notes 106 Client implementors SHOULD provide a configurable policy used to 107 select the order of methods used to verify a host key and which 108 fingerprints to trust ultimately, after user confirmation or not at 109 all. 111 One specific scenario for having a configurable policy is where 112 clients use unqualified host names to connect to servers. In this 113 scenario, the implementation SHOULD verify the host key against a 114 local database before verifying the key via the fingerprint returned 115 from DNS. This would help prevent an attacker from injecting a DNS 116 search path into the local resolver and forcing the client to connect 117 to a different host. 119 2.3 Fingerprint Matching 121 The public key and the SSHFP resource record are matched together by 122 comparing algorithm number and fingerprint. 124 2.4 Authentication 126 A public key verified using this method MUST only be trusted if the 127 SSHFP RR used for verification was authenticated by a trusted SIG RR. 129 Clients that do not validate the DNSSEC signatures themselves MUST 130 use a secure transport, e.g. TSIG [8], SIG(0) [9] or IPsec [7], 131 between themselves and the entity performing the signature 132 validation. 134 3. The SSHFP Resource Record 136 The SSHFP resource record (RR) is used to store a fingerprint of a 137 SSH public host key that is associated with a Domain Name System 138 (DNS) name. 140 The RR type code for the SSHFP RR is TBA. 142 3.1 The SSHFP RDATA Format 144 The RDATA for a SSHFP RR consists of an algorithm number, fingerprint 145 type and the fingerprint of the public host key. 147 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | algorithm | fp type | / 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 152 / / 153 / fingerprint / 154 / / 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 3.1.1 Algorithm Number Specification 159 This algorithm number octet describes the algorithm of the public 160 key. The following values are assigned: 162 Value Algorithm name 163 ----- -------------- 164 0 reserved 165 1 RSA 166 2 DSS 168 Reserving other types requires IETF consensus. 170 3.1.2 Fingerprint Type Specification 172 The fingerprint type octet describes the message-digest algorithm 173 used to calculate the fingerprint of the public key. The following 174 values are assigned: 176 Value Fingerprint type 177 ----- ---------------- 178 0 reserved 179 1 SHA-1 181 Reserving other types requires IETF consensus. For interoperability 182 reasons, as few fingerprint types as possible should be reserved. 183 The only reason to reserve additional types is to increase security. 185 3.1.3 Fingerprint 187 The fingerprint is calculated over the public key blob as described 188 in [6]. 190 3.2 Presentation Format of the SSHFP RR 192 The presentation format of the SSHFP resource record consists of two 193 numbers (algorithm and fingerprint type) followed by the fingerprint 194 itself presented in hex, e.g: 196 host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890 198 4. Security Considerations 200 Currently, the amount of trust a user can realistically place in a 201 server key is proportional to the amount of attention paid to 202 verifying that the key presented is actually the key at the server. 203 If a user accepts a key without verifying the fingerprint with 204 something learned through a secured channel, the connection is 205 vulnerable to a man-in-the-middle attack. 207 The approach suggested here shifts the burden of key checking from 208 each user of a machine to the key checking performed by the 209 administrator of the DNS recursive server used to resolve the host 210 information. Hopefully, by reducing the number of times that keys 211 need to be verified by hand, each verification is performed more 212 completely. Furthermore, by requiring an administrator do the 213 checking, the result may be more reliable than placing this task in 214 the hands of an application user. 216 The overall security of using SSHFP for SSH host key verification is 217 dependent on detailed aspects of how verification is done in SSH 218 implementations. One such aspect is in which order fingerprints are 219 looked up (e.g. first checking local file and then SSHFP). We note 220 that in addition to protecting the first-time transfer of host keys, 221 SSHFP can optionally be used for stronger host key protection. 223 If SSHFP is checked first, new SSH host keys may be distributed by 224 replacing the corresponding SSHFP in DNS. 226 If SSH host key verification can be configured to require SSHFP, 227 we can implement SSH host key revocation by removing the 228 corresponding SSHFP from DNS. 230 As stated in Section 2.2, we recommend that SSH implementors provide 231 a policy mechanism to control the order of methods used for host key 232 verification. One specific scenario for having a configurable policy 233 is where clients use unqualified host names to connect to servers. In 234 this case, we recommend that SSH implementations check the host key 235 against a local database before verifying the key via the fingerprint 236 returned from DNS. This would help prevent an attacker from injecting 237 a DNS search path into the local resolver and forcing the client to 238 connect to a different host. 240 A different approach to solve the DNS search path issue would be for 241 clients to use a trusted DNS search path, i.e., one not acquired 242 through DHCP or other autoconfiguration mechanisms. Since there is no 243 way with current DNS lookup APIs to tell whether a search path is 244 from a trusted source, the entire client system would need to be 245 configured with this trusted DNS search path. 247 Another dependency is on the implementation of DNSSEC itself. As 248 stated in Section 2.4, we mandate the use of secure methods for 249 lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This 250 is especially important if SSHFP is to be used as a basis for host 251 key rollover and/or revocation, as described above. 253 Since DNSSEC only protects the integrity of the host key fingerprint 254 after it is signed by the DNS zone administrator, the fingerprint 255 must be transferred securely from the SSH host administrator to the 256 DNS zone administrator. This could be done manually between the 257 administrators or automatically using secure DNS dynamic update [10] 258 between the SSH server and the nameserver. We note that this is no 259 different from other key enrollment situations, e.g. a client sending 260 a certificate request to a certificate authority for signing. 262 5. IANA Considerations 264 IANA needs to allocate a RR type code for SSHFP from the standard RR 265 type space (type 44 requested). 267 IANA needs to open a new registry for the SSHFP RR type for public 268 key algorithms. Defined types are: 270 0 is reserved 271 1 is RSA 272 2 is DSA 274 Adding new reservations requires IETF consensus. 276 IANA needs to open a new registry for the SSHFP RR type for 277 fingerprint types. Defined types are: 279 0 is reserved 280 1 is SHA-1 282 Adding new reservations requires IETF consensus. 284 Normative References 286 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 287 13, RFC 1034, November 1987. 289 [2] Mockapetris, P., "Domain names - implementation and 290 specification", STD 13, RFC 1035, November 1987. 292 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 293 Levels", BCP 14, RFC 2119, March 1997. 295 [4] Eastlake, D., "Domain Name System Security Extensions", RFC 296 2535, March 1999. 298 [5] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH 299 Protocol Architecture", draft-ietf-secsh-architecture-13 (work 300 in progress), September 2002. 302 [6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. 304 Lehtinen, "SSH Transport Layer Protocol", 305 draft-ietf-secsh-transport-15 (work in progress), September 306 2002. 308 Informational References 310 [7] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document 311 Roadmap", RFC 2411, November 1998. 313 [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 314 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 315 2845, May 2000. 317 [9] Eastlake, D., "DNS Request and Transaction Signatures ( 318 SIG(0)s)", RFC 2931, September 2000. 320 [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic 321 Update", RFC 3007, November 2000. 323 Authors' Addresses 325 Jakob Schlyter 326 Carlstedt Research & Technology 327 Stora Badhusgatan 18-20 328 Goteborg SE-411 21 329 Sweden 331 EMail: jakob@crt.se 332 URI: http://www.crt.se/~jakob/ 334 Wesley Griffin 335 Network Associates Laboratories 336 15204 Omega Drive Suite 300 337 Rockville, MD 20850 338 USA 340 EMail: wgriffin@tislabs.com 341 URI: http://www.nailabs.com/ 343 Appendix A. Acknowledgements 345 The authors gratefully acknowledges, in no particular order, the 346 contributions of the following persons: 348 Martin Fredriksson 349 Olafur Gudmundsson 351 Edward Lewis 353 Bill Sommerfeld 355 Intellectual Property Statement 357 The IETF takes no position regarding the validity or scope of any 358 intellectual property or other rights that might be claimed to 359 pertain to the implementation or use of the technology described in 360 this document or the extent to which any license under such rights 361 might or might not be available; neither does it represent that it 362 has made any effort to identify any such rights. Information on the 363 IETF's procedures with respect to rights in standards-track and 364 standards-related documentation can be found in BCP-11. Copies of 365 claims of rights made available for publication and any assurances of 366 licenses to be made available, or the result of an attempt made to 367 obtain a general license or permission for the use of such 368 proprietary rights by implementors or users of this specification can 369 be obtained from the IETF Secretariat. 371 The IETF invites any interested party to bring to its attention any 372 copyrights, patents or patent applications, or other proprietary 373 rights which may cover technology that may be required to practice 374 this standard. Please address the information to the IETF Executive 375 Director. 377 Full Copyright Statement 379 Copyright (C) The Internet Society (2003). All Rights Reserved. 381 This document and translations of it may be copied and furnished to 382 others, and derivative works that comment on or otherwise explain it 383 or assist in its implementation may be prepared, copied, published 384 and distributed, in whole or in part, without restriction of any 385 kind, provided that the above copyright notice and this paragraph are 386 included on all such copies and derivative works. However, this 387 document itself may not be modified in any way, such as by removing 388 the copyright notice or references to the Internet Society or other 389 Internet organizations, except as needed for the purpose of 390 developing Internet standards in which case the procedures for 391 copyrights defined in the Internet Standards process must be 392 followed, or as required to translate it into languages other than 393 English. 395 The limited permissions granted above are perpetual and will not be 396 revoked by the Internet Society or its successors or assignees. 398 This document and the information contained herein is provided on an 399 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 400 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 401 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 402 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 403 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 405 Acknowledgement 407 Funding for the RFC Editor function is currently provided by the 408 Internet Society.