idnits 2.17.1 draft-ietf-secsh-dns-02.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 10 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 (January 11, 2003) is 7776 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. -------------------------------------------------------------------------------- 1 Secure Shell Working Group J. Schlyter 2 Internet-Draft Carlstedt Research & 3 Expires: July 12, 2003 Technology 4 W. Griffin 5 Network Associates Laboratories 6 January 11, 2003 8 Using DNS to securely publish SSH key fingerprints 9 draft-ietf-secsh-dns-02.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 18 other groups may also distribute working documents as 19 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 July 12, 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 . . . . . . . . . . . . . . . 4 55 3.1.2 Fingerprint type specification . . . . . . . . . . . . . . . 5 56 3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.2 Presentation format of the SSHFP RR . . . . . . . . . . . . 5 58 4. Security considerations . . . . . . . . . . . . . . . . . . 5 59 5. IANA considerations . . . . . . . . . . . . . . . . . . . . 6 60 Normative References . . . . . . . . . . . . . . . . . . . . 7 61 Informational References . . . . . . . . . . . . . . . . . . 7 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 63 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 64 Intellectual Property and Copyright Statements . . . . . . . 9 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 do verify the 77 fingerprint out-of-band before accepting the key, the average user 78 usually blindly accepts the key presented. 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 and which 109 fingerprints to trust ultimately, after user confirmation or not at 110 all. 112 One specific scenario for having a configurable policy is where 113 clients use unqualified host names to connect to servers. In this 114 scenario, the implementation SHOULD verify the host key against a 115 local database before verifying the key via the fingerprint returned 116 from DNS. This would help prevent an attacker from injecting a DNS 117 search path into the local resolver and forcing the client to connect 118 to a different host. 120 2.3 Fingerprint matching 122 The public key and the SSHFP resource record are matched together by 123 comparing algorithm number and fingerprint. 125 2.4 Authentication 127 A public key verified using this method MUST only be trusted if the 128 SSHFP RR used for verification was authenticated by a trusted SIG RR. 130 Clients that do not validate the DNSSEC signatures themselves MUST 131 use a secure transport, e.g. TSIG [8], SIG(0) [9] or IPsec [7], 132 between themselves and the entity performing the signature 133 validation. 135 3. The SSHFP resource record 137 The SSHFP resource record (RR) is used to store a fingerprint of a 138 SSH public host key that is associated with a Domain Name System 139 (DNS) name. 141 The RR type code for the SSHFP RR is TBA. 143 3.1 The SSHFP RDATA format 145 The RDATA for a SSHFP RR consists of an algorithm number, fingerprint 146 type and the fingerprint of the public host key. 148 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | algorithm | fp type | / 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 153 / / 154 / fingerprint / 155 / / 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 3.1.1 Algorithm number specification 160 This algorithm number octet describes the algorithm of the public 161 key. The following values are assigned: 163 Value Algorithm name 164 ----- -------------- 165 0 reserved 166 1 RSA 167 2 DSS 169 Reserving other types requires IETF consensus. 171 3.1.2 Fingerprint type specification 173 The fingerprint type octet describes the message-digest algorithm 174 used to calculate the fingerprint of the public key. The following 175 values are assigned: 177 Value Fingerprint type 178 ----- ---------------- 179 0 reserved 180 1 SHA-1 182 Reserving other types requires IETF consensus. For interoperability 183 reasons, as few fingerprint types as possible should be reserved. 184 The only reason to reserve additional types is to increase security. 186 3.1.3 Fingerprint 188 The fingerprint is calculated over the public key blob as described 189 in [6]. 191 3.2 Presentation format of the SSHFP RR 193 The presentation format of the SSHFP resource record consists of two 194 numbers (algorithm and fingerprint type) followed by the fingerprint 195 itself presented in hex, e.g: 197 host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890 199 4. Security considerations 201 Currently, the amount of trust a user can realistically place in a 202 server key is proportional to the amount of attention paid to 203 verifying that the key presented is actually the key at the server. 204 If a user accepts a key without verifying the fingerprint with 205 something learned through a secured channel, the connection is 206 vulnerable to a man-in-the-middle attack. 208 The approach suggested here shifts the burden of key checking from 209 each user of a machine to the key checking performed by the 210 administrator of the DNS recursive server used to resolve the host 211 information. Hopefully, by reducing the number of times that keys 212 need to be verified by hand, each verification is performed more 213 completely. Furthermore, by requiring an administrator do the 214 checking, the result may be more reliable than placing this task in 215 the hands of an application user. 217 The overall security of using SSHFP for SSH host key verification is 218 dependent on detailed aspects of how verification is done in SSH 219 implementations. One such aspect is in which order fingerprints are 220 looked up (e.g. first checking local file and then SSHFP). We note 221 that in addition to protecting the first-time transfer of host keys, 222 SSHFP can optionally be used for stronger host key protection. 224 If SSHFP is checked first, new SSH host keys may be distributed by 225 replacing the corresponding SSHFP in DNS. 227 If SSH host key verification can be configured to require SSHFP, 228 we can implement SSH host key revocation by removing the 229 corresponding SSHFP from DNS. 231 As stated in Section 2.2, we recommend that SSH implementors provide 232 a policy mechanism to control the order of methods used for host key 233 verification. 235 Another dependency is on the implementation of DNSSEC itself. As 236 stated in Section 2.4, we mandate the use of secure methods for 237 lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This 238 is especially important if SSHFP is to be used as a basis for host 239 key rollover and/or revocation, as described above. 241 Since DNSSEC only protects the integrity of the host key fingerprint 242 after it is signed by the DNS zone administrator, the fingerprint 243 must be transferred securely from the SSH host administrator to the 244 DNS zone administrator. This could be done manually between the 245 administrators or automatically using secure DNS dynamic update [10] 246 between the SSH server and the nameserver. We note that this is no 247 different from other key enrollment situations, e.g. a client 248 sending a certificate request to a certificate authority for signing. 250 5. IANA considerations 252 IANA needs to allocate a RR type code for SSHFP from the standard RR 253 type space (type 44 requested). 255 IANA needs to open a new registry for the SSHFP RR type for public 256 key algorithms. Defined types are: 258 0 is reserved 259 1 is RSA 260 2 is DSA 262 Adding new reservations requires IETF consensus. 264 IANA needs to open a new registry for the SSHFP RR type for 265 fingerprint types. Defined types are: 267 0 is reserved 268 1 is SHA-1 270 Adding new reservations requires IETF consensus. 272 Normative References 274 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 275 13, RFC 1034, November 1987. 277 [2] Mockapetris, P., "Domain names - implementation and 278 specification", STD 13, RFC 1035, November 1987. 280 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 281 Levels", BCP 14, RFC 2119, March 1997. 283 [4] Eastlake, D., "Domain Name System Security Extensions", RFC 284 2535, March 1999. 286 [5] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T J. and S. 287 Lehtinen, "SSH Transport Layer Protocol", work in progress 288 draft-ietf-secsh-architecture-13.txt, September 2002. 290 [6] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T J. and S. 291 Lehtinen, "SSH Transport Layer Protocol", work in progress 292 draft-ietf-secsh-transport-15.txt, September 2002. 294 Informational References 296 [7] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document 297 Roadmap", RFC 2411, November 1998. 299 [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 300 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 301 2845, May 2000. 303 [9] Eastlake, D., "DNS Request and Transaction Signatures ( 304 SIG(0)s)", RFC 2931, September 2000. 306 [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic 307 Update", RFC 3007, November 2000. 309 Authors' Addresses 311 Jakob Schlyter 312 Carlstedt Research & Technology 313 Stora Badhusgatan 18-20 314 Goteborg SE-411 21 315 Sweden 317 EMail: jakob@crt.se 318 URI: http://www.crt.se/~jakob/ 320 Wesley Griffin 321 Network Associates Laboratories 322 15204 Omega Drive Suite 300 323 Rockville, MD 20850 324 USA 326 EMail: wgriffin@tislabs.com 327 URI: http://www.nailabs.com/ 329 Appendix A. Acknowledgements 331 The authors gratefully acknowledges, in no particular order, the 332 contributions of the following persons: 334 Martin Fredriksson 336 Olafur Gudmundsson 338 Edward Lewis 340 Bill Sommerfeld 342 Intellectual Property Statement 344 The IETF takes no position regarding the validity or scope of any 345 intellectual property or other rights that might be claimed to 346 pertain to the implementation or use of the technology described in 347 this document or the extent to which any license under such rights 348 might or might not be available; neither does it represent that it 349 has made any effort to identify any such rights. Information on the 350 IETF's procedures with respect to rights in standards-track and 351 standards-related documentation can be found in BCP-11. Copies of 352 claims of rights made available for publication and any assurances of 353 licenses to be made available, or the result of an attempt made to 354 obtain a general license or permission for the use of such 355 proprietary rights by implementors or users of this specification can 356 be obtained from the IETF Secretariat. 358 The IETF invites any interested party to bring to its attention any 359 copyrights, patents or patent applications, or other proprietary 360 rights which may cover technology that may be required to practice 361 this standard. Please address the information to the IETF Executive 362 Director. 364 Full Copyright Statement 366 Copyright (C) The Internet Society (2003). All Rights Reserved. 368 This document and translations of it may be copied and furnished to 369 others, and derivative works that comment on or otherwise explain it 370 or assist in its implementation may be prepared, copied, published 371 and distributed, in whole or in part, without restriction of any 372 kind, provided that the above copyright notice and this paragraph are 373 included on all such copies and derivative works. However, this 374 document itself may not be modified in any way, such as by removing 375 the copyright notice or references to the Internet Society or other 376 Internet organizations, except as needed for the purpose of 377 developing Internet standards in which case the procedures for 378 copyrights defined in the Internet Standards process must be 379 followed, or as required to translate it into languages other than 380 English. 382 The limited permissions granted above are perpetual and will not be 383 revoked by the Internet Society or its successors or assignees. 385 This document and the information contained herein is provided on an 386 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 387 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 388 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 389 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 390 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 392 Acknowledgement 394 Funding for the RFC Editor function is currently provided by the 395 Internet Society.