diff options
Diffstat (limited to 'doc/draft-ietf-secsh-dns-04.txt')
-rw-r--r-- | doc/draft-ietf-secsh-dns-04.txt | 616 |
1 files changed, 616 insertions, 0 deletions
diff --git a/doc/draft-ietf-secsh-dns-04.txt b/doc/draft-ietf-secsh-dns-04.txt new file mode 100644 index 00000000..7667a5e8 --- /dev/null +++ b/doc/draft-ietf-secsh-dns-04.txt @@ -0,0 +1,616 @@ + + +Secure Shell Working Group J. Schlyter +Internet-Draft Carlstedt Research & +Expires: October 1, 2003 Technology + W. Griffin + Network Associates Laboratories + April 2, 2003 + + + Using DNS to securely publish SSH key fingerprints + draft-ietf-secsh-dns-04.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on October 1, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document describes a method to verify SSH host keys using + DNSSEC. The document defines a new DNS resource record that contains + a standard SSH key fingerprint. + + + + + + + + + + +Schlyter & Griffin Expires October 1, 2003 [Page 1] + +Internet-Draft DNS and SSH fingerprints April 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. SSH Host Key Verification . . . . . . . . . . . . . . . . . 3 + 2.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2 Implementation Notes . . . . . . . . . . . . . . . . . . . . 3 + 2.3 Fingerprint Matching . . . . . . . . . . . . . . . . . . . . 4 + 2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. The SSHFP Resource Record . . . . . . . . . . . . . . . . . 4 + 3.1 The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . . 4 + 3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . . 5 + 3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . . 5 + 3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.2 Presentation Format of the SSHFP RR . . . . . . . . . . . . 6 + 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 + Normative References . . . . . . . . . . . . . . . . . . . . 8 + Informational References . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 + A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 + Intellectual Property and Copyright Statements . . . . . . . 10 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter & Griffin Expires October 1, 2003 [Page 2] + +Internet-Draft DNS and SSH fingerprints April 2003 + + +1. Introduction + + The SSH [5] protocol provides secure remote login and other secure + network services over an insecure network. The security of the + connection relies on the server authenticating itself to the client. + + Server authentication is normally done by presenting the fingerprint + of an unknown public key to the user for verification. If the user + decides the fingerprint is correct and accepts the key, the key is + saved locally and used for verification for all following + connections. While some security-conscious users verify the + fingerprint out-of-band before accepting the key, many users blindly + accepts the presented key. + + The method described here can provide out-of-band verification by + looking up a fingerprint of the server public key in the DNS [1][2] + and using DNSSEC [4] to verify the lookup. + + In order to distribute the fingerprint using DNS, this document + defines a new DNS resource record to carry the fingerprint. + + Basic understanding of the DNS system [1][2] and the DNS security + extensions [4] is assumed by this document. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [3]. + +2. SSH Host Key Verification + +2.1 Method + + Upon connection to a SSH server, the SSH client MAY look up the SSHFP + resource record(s) for the host it is connecting to. If the + algorithm and fingerprint of the key received from the SSH server + matches the algorithm and fingerprint of one of the SSHFP resource + record(s) returned from DNS, the client MAY accept the identity of + the server. + +2.2 Implementation Notes + + Client implementors SHOULD provide a configurable policy used to + select the order of methods used to verify a host key. This document + defines one method: Fingerprint storage in DNS. Another method + defined in the SSH Architecture [5] uses local files to store keys + for comparison. Other methods that could be defined in the future + might include storing fingerprints in LDAP or other databases. A + configurable policy will allow administrators to determine which + + + +Schlyter & Griffin Expires October 1, 2003 [Page 3] + +Internet-Draft DNS and SSH fingerprints April 2003 + + + methods they want to use and in what order the methods should be + prioritized. This will allow administrators to determine how much + trust they want to place in the different methods. + + One specific scenario for having a configurable policy is where + clients do not use fully qualified host names to connect to servers. + In this scenario, the implementation SHOULD verify the host key + against a local database before verifying the key via the fingerprint + returned from DNS. This would help prevent an attacker from injecting + a DNS search path into the local resolver and forcing the client to + connect to a different host. + +2.3 Fingerprint Matching + + The public key and the SSHFP resource record are matched together by + comparing algorithm number and fingerprint. + + The public key algorithm and the SSHFP algorithm number MUST + match. + + A message digest of the public key, using the message digest + algorithm specified in the SSHFP fingerprint type, MUST match the + SSH FP fingerprint. + + +2.4 Authentication + + A public key verified using this method MUST only be trusted if the + SSHFP resource record (RR) used for verification was authenticated by + a trusted SIG RR. + + Clients that do not validate the DNSSEC signatures themselves MUST + use a secure transport, e.g. TSIG [8], SIG(0) [9] or IPsec [7], + between themselves and the entity performing the signature + validation. + +3. The SSHFP Resource Record + + The SSHFP resource record (RR) is used to store a fingerprint of a + SSH public host key that is associated with a Domain Name System + (DNS) name. + + The RR type code for the SSHFP RR is TBA. + +3.1 The SSHFP RDATA Format + + The RDATA for a SSHFP RR consists of an algorithm number, fingerprint + type and the fingerprint of the public host key. + + + +Schlyter & Griffin Expires October 1, 2003 [Page 4] + +Internet-Draft DNS and SSH fingerprints April 2003 + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | algorithm | fp type | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / + / / + / fingerprint / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +3.1.1 Algorithm Number Specification + + This algorithm number octet describes the algorithm of the public + key. The following values are assigned: + + Value Algorithm name + ----- -------------- + 0 reserved + 1 RSA + 2 DSS + + Reserving other types requires IETF consensus. + +3.1.2 Fingerprint Type Specification + + The fingerprint type octet describes the message-digest algorithm + used to calculate the fingerprint of the public key. The following + values are assigned: + + Value Fingerprint type + ----- ---------------- + 0 reserved + 1 SHA-1 + + Reserving other types requires IETF consensus. For interoperability + reasons, as few fingerprint types as possible should be reserved. + The only reason to reserve additional types is to increase security. + +3.1.3 Fingerprint + + The fingerprint is calculated over the public key blob as described + in [6]. + + The message-digest algorithm is presumed to produce an opaque octet + string output which is placed as-is in the RDATA fingerprint field. + + + + + +Schlyter & Griffin Expires October 1, 2003 [Page 5] + +Internet-Draft DNS and SSH fingerprints April 2003 + + +3.2 Presentation Format of the SSHFP RR + + The presentation format of the SSHFP resource record consists of two + numbers (algorithm and fingerprint type) followed by the fingerprint + itself presented in hex, e.g: + + host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890 + + +4. Security Considerations + + Currently, the amount of trust a user can realistically place in a + server key is proportional to the amount of attention paid to + verifying that the public key presented actually corresponds to the + private key of the server. If a user accepts a key without verifying + the fingerprint with something learned through a secured channel, the + connection is vulnerable to a man-in-the-middle attack. + + The approach suggested here shifts the burden of key checking from + each user of a machine to the key checking performed by the + administrator of the DNS recursive server used to resolve the host + information. Hopefully, by reducing the number of times that keys + need to be verified by hand, each verification is performed more + completely. Furthermore, by requiring an administrator do the + checking, the result may be more reliable than placing this task in + the hands of an application user. + + The overall security of using SSHFP for SSH host key verification is + dependent on detailed aspects of how verification is done in SSH + implementations. One such aspect is in which order fingerprints are + looked up (e.g. first checking local file and then SSHFP). We note + that in addition to protecting the first-time transfer of host keys, + SSHFP can optionally be used for stronger host key protection. + + If SSHFP is checked first, new SSH host keys may be distributed by + replacing the corresponding SSHFP in DNS. + + If SSH host key verification can be configured to require SSHFP, + we can implement SSH host key revocation by removing the + corresponding SSHFP from DNS. + + As stated in Section 2.2, we recommend that SSH implementors provide + a policy mechanism to control the order of methods used for host key + verification. One specific scenario for having a configurable policy + is where clients use unqualified host names to connect to servers. In + this case, we recommend that SSH implementations check the host key + against a local database before verifying the key via the fingerprint + returned from DNS. This would help prevent an attacker from injecting + + + +Schlyter & Griffin Expires October 1, 2003 [Page 6] + +Internet-Draft DNS and SSH fingerprints April 2003 + + + a DNS search path into the local resolver and forcing the client to + connect to a different host. + + A different approach to solve the DNS search path issue would be for + clients to use a trusted DNS search path, i.e., one not acquired + through DHCP or other autoconfiguration mechanisms. Since there is no + way with current DNS lookup APIs to tell whether a search path is + from a trusted source, the entire client system would need to be + configured with this trusted DNS search path. + + Another dependency is on the implementation of DNSSEC itself. As + stated in Section 2.4, we mandate the use of secure methods for + lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This + is especially important if SSHFP is to be used as a basis for host + key rollover and/or revocation, as described above. + + Since DNSSEC only protects the integrity of the host key fingerprint + after it is signed by the DNS zone administrator, the fingerprint + must be transferred securely from the SSH host administrator to the + DNS zone administrator. This could be done manually between the + administrators or automatically using secure DNS dynamic update [10] + between the SSH server and the nameserver. We note that this is no + different from other key enrollment situations, e.g. a client sending + a certificate request to a certificate authority for signing. + +5. IANA Considerations + + IANA needs to allocate a RR type code for SSHFP from the standard RR + type space (type 44 requested). + + IANA needs to open a new registry for the SSHFP RR type for public + key algorithms. Defined types are: + + 0 is reserved + 1 is RSA + 2 is DSA + + Adding new reservations requires IETF consensus. + + IANA needs to open a new registry for the SSHFP RR type for + fingerprint types. Defined types are: + + 0 is reserved + 1 is SHA-1 + + Adding new reservations requires IETF consensus. + +Normative References + + + +Schlyter & Griffin Expires October 1, 2003 [Page 7] + +Internet-Draft DNS and SSH fingerprints April 2003 + + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [5] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH + Protocol Architecture", draft-ietf-secsh-architecture-13 (work + in progress), September 2002. + + [6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. + Lehtinen, "SSH Transport Layer Protocol", + draft-ietf-secsh-transport-15 (work in progress), September + 2002. + +Informational References + + [7] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document + Roadmap", RFC 2411, November 1998. + + [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + + [9] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + +Authors' Addresses + + Jakob Schlyter + Carlstedt Research & Technology + Stora Badhusgatan 18-20 + Goteborg SE-411 21 + Sweden + + EMail: jakob@crt.se + URI: http://www.crt.se/~jakob/ + + + + +Schlyter & Griffin Expires October 1, 2003 [Page 8] + +Internet-Draft DNS and SSH fingerprints April 2003 + + + Wesley Griffin + Network Associates Laboratories + 15204 Omega Drive Suite 300 + Rockville, MD 20850 + USA + + EMail: wgriffin@tislabs.com + URI: http://www.nailabs.com/ + +Appendix A. Acknowledgements + + The authors gratefully acknowledges, in no particular order, the + contributions of the following persons: + + Martin Fredriksson + + Olafur Gudmundsson + + Edward Lewis + + Bill Sommerfeld + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter & Griffin Expires October 1, 2003 [Page 9] + +Internet-Draft DNS and SSH fingerprints April 2003 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Schlyter & Griffin Expires October 1, 2003 [Page 10] + +Internet-Draft DNS and SSH fingerprints April 2003 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter & Griffin Expires October 1, 2003 [Page 11] + |