Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
RFC 4255
Document | Type |
RFC - Proposed Standard
(January 2006; Errata)
Was draft-ietf-secsh-dns (secsh WG)
|
|
---|---|---|---|
Last updated | 2015-10-14 | ||
Replaces | draft-ietf-secsh-dns-key-format | ||
Stream | IETF | ||
Formats | plain text pdf htmlized with errata bibtex | ||
Stream | WG state | WG Document | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4255 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Russ Housley | ||
Send notices to | (None) |
Network Working Group J. Schlyter Request for Comments: 4255 OpenSSH Category: Standards Track W. Griffin SPARTA January 2006 Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes a method of verifying Secure Shell (SSH) host keys using Domain Name System Security (DNSSEC). The document defines a new DNS resource record that contains a standard SSH key fingerprint. Table of Contents 1. Introduction ....................................................2 2. SSH Host Key Verification .......................................2 2.1. Method .....................................................2 2.2. Implementation Notes .......................................2 2.3. Fingerprint Matching .......................................3 2.4. Authentication .............................................3 3. The SSHFP Resource Record .......................................3 3.1. The SSHFP RDATA Format .....................................4 3.1.1. Algorithm Number Specification ......................4 3.1.2. Fingerprint Type Specification ......................4 3.1.3. Fingerprint .........................................5 3.2. Presentation Format of the SSHFP RR ........................5 4. Security Considerations .........................................5 5. IANA Considerations .............................................6 6. Normative References ............................................7 7. Informational References ........................................7 8. Acknowledgements ................................................8 Schlyter & Griffin Standards Track [Page 1] RFC 4255 DNS and SSH Fingerprints January 2006 1. Introduction The SSH [6] 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 as well as the user authenticating itself to the server. If a connection is established to a server whose public key is not already known to the client, a fingerprint of the key is presented to the user for verification. If the user decides that 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 accept 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 [5] to verify the lookup. In order to distribute the fingerprint using DNS, this document defines a new DNS resource record, "SSHFP", to carry the fingerprint. Basic understanding of the DNS system [1][2] and the DNS security extensions [5] 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 an 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 match 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 [6] 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 Schlyter & Griffin Standards Track [Page 2] RFC 4255 DNS and SSH Fingerprints January 2006 configurable policy will allow administrators to determine whichShow full document text