draft-ietf-secsh-dns-03.txt   draft-ietf-secsh-dns-04.txt 
Secure Shell Working Group J. Schlyter Secure Shell Working Group J. Schlyter
Internet-Draft Carlstedt Research & Internet-Draft Carlstedt Research &
Expires: September 23, 2003 Technology Expires: October 1, 2003 Technology
W. Griffin W. Griffin
Network Associates Laboratories Network Associates Laboratories
March 25, 2003 April 2, 2003
Using DNS to securely publish SSH key fingerprints Using DNS to securely publish SSH key fingerprints
draft-ietf-secsh-dns-03.txt draft-ietf-secsh-dns-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 23, 2003. This Internet-Draft will expire on October 1, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document describes a method to verify SSH host keys using This document describes a method to verify SSH host keys using
DNSSEC. The document defines a new DNS resource record that contains DNSSEC. The document defines a new DNS resource record that contains
a standard SSH key fingerprint. a standard SSH key fingerprint.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SSH Host Key Verification . . . . . . . . . . . . . . . . . 3 2. SSH Host Key Verification . . . . . . . . . . . . . . . . . 3
2.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Implementation Notes . . . . . . . . . . . . . . . . . . . . 3 2.2 Implementation Notes . . . . . . . . . . . . . . . . . . . . 3
2.3 Fingerprint Matching . . . . . . . . . . . . . . . . . . . . 4 2.3 Fingerprint Matching . . . . . . . . . . . . . . . . . . . . 4
2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4 2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4
3. The SSHFP Resource Record . . . . . . . . . . . . . . . . . 4 3. The SSHFP Resource Record . . . . . . . . . . . . . . . . . 4
3.1 The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . . 4 3.1 The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . . 4
3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . . 4 3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . . 5
3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . . 5 3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . . 5
3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Presentation Format of the SSHFP RR . . . . . . . . . . . . 5 3.2 Presentation Format of the SSHFP RR . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
Normative References . . . . . . . . . . . . . . . . . . . . 7 Normative References . . . . . . . . . . . . . . . . . . . . 8
Informational References . . . . . . . . . . . . . . . . . . 8 Informational References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . 10
1. Introduction 1. Introduction
The SSH [5] protocol provides secure remote login and other secure The SSH [5] protocol provides secure remote login and other secure
network services over an insecure network. The security of the network services over an insecure network. The security of the
connection relies on the server authenticating itself to the client. connection relies on the server authenticating itself to the client.
Server authentication is normally done by presenting the fingerprint Server authentication is normally done by presenting the fingerprint
of an unknown public key to the user for verification. If the user 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 decides the fingerprint is correct and accepts the key, the key is
saved locally and used for verification for all following saved locally and used for verification for all following
connections. While some security-conscious users do verify the connections. While some security-conscious users verify the
fingerprint out-of-band before accepting the key, the average user fingerprint out-of-band before accepting the key, many users blindly
usually blindly accepts the key presented. accepts the presented key.
The method described here can provide out-of-band verification by 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] looking up a fingerprint of the server public key in the DNS [1][2]
and using DNSSEC [4] to verify the lookup. and using DNSSEC [4] to verify the lookup.
In order to distribute the fingerprint using DNS, this document In order to distribute the fingerprint using DNS, this document
defines a new DNS resource record to carry the fingerprint. defines a new DNS resource record to carry the fingerprint.
Basic understanding of the DNS system [1][2] and the DNS security Basic understanding of the DNS system [1][2] and the DNS security
extensions [4] is assumed by this document. extensions [4] is assumed by this document.
skipping to change at page 3, line 47 skipping to change at page 3, line 47
Upon connection to a SSH server, the SSH client MAY look up the SSHFP 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 resource record(s) for the host it is connecting to. If the
algorithm and fingerprint of the key received from the SSH server algorithm and fingerprint of the key received from the SSH server
matches the algorithm and fingerprint of one of the SSHFP resource matches the algorithm and fingerprint of one of the SSHFP resource
record(s) returned from DNS, the client MAY accept the identity of record(s) returned from DNS, the client MAY accept the identity of
the server. the server.
2.2 Implementation Notes 2.2 Implementation Notes
Client implementors SHOULD provide a configurable policy used to Client implementors SHOULD provide a configurable policy used to
select the order of methods used to verify a host key and which select the order of methods used to verify a host key. This document
fingerprints to trust ultimately, after user confirmation or not at defines one method: Fingerprint storage in DNS. Another method
all. 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
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 One specific scenario for having a configurable policy is where
clients use unqualified host names to connect to servers. In this clients do not use fully qualified host names to connect to servers.
scenario, the implementation SHOULD verify the host key against a In this scenario, the implementation SHOULD verify the host key
local database before verifying the key via the fingerprint returned against a local database before verifying the key via the fingerprint
from DNS. This would help prevent an attacker from injecting a DNS returned from DNS. This would help prevent an attacker from injecting
search path into the local resolver and forcing the client to connect a DNS search path into the local resolver and forcing the client to
to a different host. connect to a different host.
2.3 Fingerprint Matching 2.3 Fingerprint Matching
The public key and the SSHFP resource record are matched together by The public key and the SSHFP resource record are matched together by
comparing algorithm number and fingerprint. 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 2.4 Authentication
A public key verified using this method MUST only be trusted if the A public key verified using this method MUST only be trusted if the
SSHFP RR used for verification was authenticated by a trusted SIG RR. SSHFP resource record (RR) used for verification was authenticated by
a trusted SIG RR.
Clients that do not validate the DNSSEC signatures themselves MUST Clients that do not validate the DNSSEC signatures themselves MUST
use a secure transport, e.g. TSIG [8], SIG(0) [9] or IPsec [7], use a secure transport, e.g. TSIG [8], SIG(0) [9] or IPsec [7],
between themselves and the entity performing the signature between themselves and the entity performing the signature
validation. validation.
3. The SSHFP Resource Record 3. The SSHFP Resource Record
The SSHFP resource record (RR) is used to store a fingerprint of a 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 SSH public host key that is associated with a Domain Name System
skipping to change at page 5, line 34 skipping to change at page 5, line 48
Reserving other types requires IETF consensus. For interoperability Reserving other types requires IETF consensus. For interoperability
reasons, as few fingerprint types as possible should be reserved. reasons, as few fingerprint types as possible should be reserved.
The only reason to reserve additional types is to increase security. The only reason to reserve additional types is to increase security.
3.1.3 Fingerprint 3.1.3 Fingerprint
The fingerprint is calculated over the public key blob as described The fingerprint is calculated over the public key blob as described
in [6]. 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.
3.2 Presentation Format of the SSHFP RR 3.2 Presentation Format of the SSHFP RR
The presentation format of the SSHFP resource record consists of two The presentation format of the SSHFP resource record consists of two
numbers (algorithm and fingerprint type) followed by the fingerprint numbers (algorithm and fingerprint type) followed by the fingerprint
itself presented in hex, e.g: itself presented in hex, e.g:
host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890 host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890
4. Security Considerations 4. Security Considerations
Currently, the amount of trust a user can realistically place in a Currently, the amount of trust a user can realistically place in a
server key is proportional to the amount of attention paid to server key is proportional to the amount of attention paid to
verifying that the key presented is actually the key at the server. verifying that the public key presented actually corresponds to the
If a user accepts a key without verifying the fingerprint with private key of the server. If a user accepts a key without verifying
something learned through a secured channel, the connection is the fingerprint with something learned through a secured channel, the
vulnerable to a man-in-the-middle attack. connection is vulnerable to a man-in-the-middle attack.
The approach suggested here shifts the burden of key checking from The approach suggested here shifts the burden of key checking from
each user of a machine to the key checking performed by the each user of a machine to the key checking performed by the
administrator of the DNS recursive server used to resolve the host administrator of the DNS recursive server used to resolve the host
information. Hopefully, by reducing the number of times that keys information. Hopefully, by reducing the number of times that keys
need to be verified by hand, each verification is performed more need to be verified by hand, each verification is performed more
completely. Furthermore, by requiring an administrator do the completely. Furthermore, by requiring an administrator do the
checking, the result may be more reliable than placing this task in checking, the result may be more reliable than placing this task in
the hands of an application user. the hands of an application user.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/