idnits 2.17.1 draft-ietf-secsh-dns-05.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 (September 5, 2003) is 7537 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 2434 (ref. '4') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2535 (ref. '5') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-22) exists of draft-ietf-secsh-architecture-14 == Outdated reference: A later version (-24) exists of draft-ietf-secsh-transport-16 -- Obsolete informational reference (is this intentional?): RFC 2411 (ref. '8') (Obsoleted by RFC 6071) -- Obsolete informational reference (is this intentional?): RFC 2845 (ref. '9') (Obsoleted by RFC 8945) Summary: 4 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 OpenSSH 3 Expires: March 5, 2004 W. Griffin 4 SPARTA 5 September 5, 2003 7 Using DNS to Securely Publish SSH Key Fingerprints 8 draft-ietf-secsh-dns-05.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on March 5, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document describes a method to verify SSH host keys using 39 DNSSEC. The document defines a new DNS resource record that contains 40 a standard SSH key fingerprint. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. SSH Host Key Verification . . . . . . . . . . . . . . . . . 3 46 2.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2.2 Implementation Notes . . . . . . . . . . . . . . . . . . . . 3 48 2.3 Fingerprint Matching . . . . . . . . . . . . . . . . . . . . 4 49 2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. The SSHFP Resource Record . . . . . . . . . . . . . . . . . 4 51 3.1 The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . . 5 52 3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . . 5 53 3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . . 5 54 3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3.2 Presentation Format of the SSHFP RR . . . . . . . . . . . . 6 56 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 58 Normative References . . . . . . . . . . . . . . . . . . . . 8 59 Informational References . . . . . . . . . . . . . . . . . . 8 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 61 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 62 Intellectual Property and Copyright Statements . . . . . . . 10 64 1. Introduction 66 The SSH [6] protocol provides secure remote login and other secure 67 network services over an insecure network. The security of the 68 connection relies on the server authenticating itself to the client 69 as well as the user authenticating itself to the server. 71 If a connection is established to a server whose public key is not 72 already known to the client, a fingerprint of the key is presented to 73 the user for verification. If the user decides that the fingerprint 74 is correct and accepts the key, the key is saved locally and used for 75 verification for all following connections. While some 76 security-conscious users verify the fingerprint out-of-band before 77 accepting the key, many users blindly accept the presented key. 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 [5] to verify the lookup. 83 In order to distribute the fingerprint using DNS, this document 84 defines a new DNS resource record, "SSHFP", to carry the fingerprint. 86 Basic understanding of the DNS system [1][2] and the DNS security 87 extensions [5] 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 match 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. This document 108 defines one method: Fingerprint storage in DNS. Another method 109 defined in the SSH Architecture [6] uses local files to store keys 110 for comparison. Other methods that could be defined in the future 111 might include storing fingerprints in LDAP or other databases. A 112 configurable policy will allow administrators to determine which 113 methods they want to use and in what order the methods should be 114 prioritized. This will allow administrators to determine how much 115 trust they want to place in the different methods. 117 One specific scenario for having a configurable policy is where 118 clients do not use fully qualified host names to connect to servers. 119 In this scenario, the implementation SHOULD verify the host key 120 against a local database before verifying the key via the fingerprint 121 returned from DNS. This would help prevent an attacker from injecting 122 a DNS search path into the local resolver and forcing the client to 123 connect to a different host. 125 2.3 Fingerprint Matching 127 The public key and the SSHFP resource record are matched together by 128 comparing algorithm number and fingerprint. 130 The public key algorithm and the SSHFP algorithm number MUST 131 match. 133 A message digest of the public key, using the message digest 134 algorithm specified in the SSHFP fingerprint type, MUST match the 135 SSHFP fingerprint. 137 2.4 Authentication 139 A public key verified using this method MUST NOT be trusted if the 140 SSHFP resource record (RR) used for verification was not 141 authenticated by a trusted SIG RR. 143 Clients that do validate the DNSSEC signatures themselves SHOULD use 144 standard DNSSEC validation procedures. 146 Clients that do not validate the DNSSEC signatures themselves MUST 147 use a secure transport, e.g. TSIG [9], SIG(0) [10] or IPsec [8], 148 between themselves and the entity performing the signature 149 validation. 151 3. The SSHFP Resource Record 153 The SSHFP resource record (RR) is used to store a fingerprint of a 154 SSH public host key that is associated with a Domain Name System 155 (DNS) name. 157 The RR type code for the SSHFP RR is TBA. 159 3.1 The SSHFP RDATA Format 161 The RDATA for a SSHFP RR consists of an algorithm number, fingerprint 162 type and the fingerprint of the public host key. 164 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | algorithm | fp type | / 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 169 / / 170 / fingerprint / 171 / / 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 3.1.1 Algorithm Number Specification 176 This algorithm number octet describes the algorithm of the public 177 key. The following values are assigned: 179 Value Algorithm name 180 ----- -------------- 181 0 reserved 182 1 RSA 183 2 DSS 185 Reserving other types requires IETF consensus [4]. 187 3.1.2 Fingerprint Type Specification 189 The fingerprint type octet describes the message-digest algorithm 190 used to calculate the fingerprint of the public key. The following 191 values are assigned: 193 Value Fingerprint type 194 ----- ---------------- 195 0 reserved 196 1 SHA-1 198 Reserving other types requires IETF consensus [4]. 200 For interoperability reasons, as few fingerprint types as possible 201 should be reserved. The only reason to reserve additional types is 202 to increase security. 204 3.1.3 Fingerprint 205 The fingerprint is calculated over the public key blob as described 206 in [7]. 208 The message-digest algorithm is presumed to produce an opaque octet 209 string output which is placed as-is in the RDATA fingerprint field. 211 3.2 Presentation Format of the SSHFP RR 213 The RDATA of the presentation format of the SSHFP resource record 214 consists of two numbers (algorithm and fingerprint type) followed by 215 the fingerprint itself presented in hex, e.g: 217 host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890 219 The use of mnemonics instead of numbers is not allowed. 221 4. Security Considerations 223 Currently, the amount of trust a user can realistically place in a 224 server key is proportional to the amount of attention paid to 225 verifying that the public key presented actually corresponds to the 226 private key of the server. If a user accepts a key without verifying 227 the fingerprint with something learned through a secured channel, the 228 connection is vulnerable to a man-in-the-middle attack. 230 The overall security of using SSHFP for SSH host key verification is 231 dependent on the security policies of the SSH host administrator and 232 DNS zone administrator (in transferring the fingerprint), detailed 233 aspects of how verification is done in the SSH implementation, and in 234 the client's diligence in accessing the DNS in a secure manner. 236 One such aspect is in which order fingerprints are looked up (e.g. 237 first checking local file and then SSHFP). We note that in addition 238 to protecting the first-time transfer of host keys, SSHFP can 239 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 SSH host key revocation can be implemented 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 [11] 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 [4]. 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 [4]. 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] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 314 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 316 [5] Eastlake, D., "Domain Name System Security Extensions", RFC 317 2535, March 1999. 319 [6] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. 320 Lehtinen, "SSH Protocol Architecture", 321 draft-ietf-secsh-architecture-14 (work in progress), July 2003. 323 [7] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. 324 Lehtinen, "SSH Transport Layer Protocol", 325 draft-ietf-secsh-transport-16 (work in progress), July 2003. 327 Informational References 329 [8] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document 330 Roadmap", RFC 2411, November 1998. 332 [9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, 333 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 334 2845, May 2000. 336 [10] Eastlake, D., "DNS Request and Transaction Signatures ( 337 SIG(0)s)", RFC 2931, September 2000. 339 [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic 340 Update", RFC 3007, November 2000. 342 Authors' Addresses 344 Jakob Schlyter 345 OpenSSH 346 812 23rd Avenue SE 347 Calgary, Alberta T2G 1N8 348 Canada 350 EMail: jakob@openssh.com 351 URI: http://www.openssh.com/ 353 Wesley Griffin 354 SPARTA 355 7075 Samuel Morse Drive 356 Columbia, MD 21046 357 USA 359 EMail: wgriffin@sparta.com 360 URI: http://www.sparta.com/ 362 Appendix A. Acknowledgements 364 The authors gratefully acknowledge, in no particular order, the 365 contributions of the following persons: 367 Martin Fredriksson 369 Olafur Gudmundsson 371 Edward Lewis 373 Bill Sommerfeld 375 Intellectual Property Statement 377 The IETF takes no position regarding the validity or scope of any 378 intellectual property or other rights that might be claimed to 379 pertain to the implementation or use of the technology described in 380 this document or the extent to which any license under such rights 381 might or might not be available; neither does it represent that it 382 has made any effort to identify any such rights. Information on the 383 IETF's procedures with respect to rights in standards-track and 384 standards-related documentation can be found in BCP-11. Copies of 385 claims of rights made available for publication and any assurances of 386 licenses to be made available, or the result of an attempt made to 387 obtain a general license or permission for the use of such 388 proprietary rights by implementors or users of this specification can 389 be obtained from the IETF Secretariat. 391 The IETF invites any interested party to bring to its attention any 392 copyrights, patents or patent applications, or other proprietary 393 rights which may cover technology that may be required to practice 394 this standard. Please address the information to the IETF Executive 395 Director. 397 Full Copyright Statement 399 Copyright (C) The Internet Society (2003). All Rights Reserved. 401 This document and translations of it may be copied and furnished to 402 others, and derivative works that comment on or otherwise explain it 403 or assist in its implementation may be prepared, copied, published 404 and distributed, in whole or in part, without restriction of any 405 kind, provided that the above copyright notice and this paragraph are 406 included on all such copies and derivative works. However, this 407 document itself may not be modified in any way, such as by removing 408 the copyright notice or references to the Internet Society or other 409 Internet organizations, except as needed for the purpose of 410 developing Internet standards in which case the procedures for 411 copyrights defined in the Internet Standards process must be 412 followed, or as required to translate it into languages other than 413 English. 415 The limited permissions granted above are perpetual and will not be 416 revoked by the Internet Society or its successors or assignees. 418 This document and the information contained herein is provided on an 419 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 420 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 421 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 422 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 423 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 425 Acknowledgement 427 Funding for the RFC Editor function is currently provided by the 428 Internet Society.