aboutsummaryrefslogtreecommitdiff
path: root/doc/draft-ietf-secsh-dns-04.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/draft-ietf-secsh-dns-04.txt')
-rw-r--r--doc/draft-ietf-secsh-dns-04.txt616
1 files changed, 0 insertions, 616 deletions
diff --git a/doc/draft-ietf-secsh-dns-04.txt b/doc/draft-ietf-secsh-dns-04.txt
deleted file mode 100644
index 7667a5e..0000000
--- a/doc/draft-ietf-secsh-dns-04.txt
+++ /dev/null
@@ -1,616 +0,0 @@
-
-
-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]
-