Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
Extracted elements (20)
As few fingerprint types as possible should be reserved; the only reason to add new fingerprint type values is to increase security. This minimizes unnecessary algorithm proliferation while preserving a path for future cryptographic upgrades.
The SSHFP method is one of potentially several host key verification methods; others include local known-hosts files and future methods such as LDAP-based storage. A configurable policy ordering is needed to interoperate with existing SSH implementations that use local key databases.
A public key verified using SSHFP MUST NOT be trusted if the SSHFP RR used for verification was not authenticated by a trusted SIG RR.
Client implementors SHOULD provide a configurable policy to select the order of methods used to verify a host key, allowing administrators to control trust placement across DNS-based and local-file-based verification methods.
Clients that do not validate DNSSEC signatures themselves MUST use a secure transport (e.g., TSIG, SIG(0), or IPsec) between themselves and the entity performing the signature validation.
Clients that validate DNSSEC signatures themselves SHOULD use standard DNSSEC validation procedures.
The public key algorithm and the SSHFP algorithm number MUST match, and a message digest of the public key using the algorithm specified in the SSHFP fingerprint type MUST match the SSHFP fingerprint.
Upon connection to an SSH server, the SSH client MAY look up SSHFP resource records for the host. If the algorithm and fingerprint of the received server key match a returned SSHFP record, the client MAY accept the server's identity.
When clients do not use fully qualified host names, the implementation SHOULD verify the host key against a local database before verifying via the DNS-returned fingerprint, to prevent DNS search path injection attacks.
The algorithm number octet identifies the public key algorithm: 0 is reserved, 1 is RSA, 2 is DSS. Adding new values requires IETF consensus.
The fingerprint type octet identifies the message-digest algorithm: 0 is reserved, 1 is SHA-1. Adding new values requires IETF consensus. As few fingerprint types as possible should be reserved; additional types are only warranted to increase security.
The presentation format of the SSHFP RR consists of two decimal numbers (algorithm and fingerprint type) followed by the fingerprint in hexadecimal. Mnemonics are not allowed in place of numbers.
The SSHFP resource record (RR) type code 44 stores a fingerprint of an SSH public host key associated with a DNS name. Its RDATA consists of an algorithm number (1 octet), fingerprint type (1 octet), and the fingerprint itself (variable length).
IANA allocated RR type code 44 for SSHFP and opened a registry for SSHFP public key algorithms. Defined values: 0 (reserved), 1 (RSA), 2 (DSA). New reservations require IETF consensus.
IANA opened a registry for SSHFP fingerprint types. Defined values: 0 (reserved), 1 (SHA-1). New reservations require IETF consensus.
Accepting an SSH host key without verifying the fingerprint through a secured channel leaves the connection vulnerable to man-in-the-middle attacks. SSHFP provides out-of-band verification whose overall security depends on the SSH administrator, DNS zone administrator, SSH implementation details, and the client's secure DNS access.
Clients using unqualified host names should check the host key against a local database before consulting DNS to prevent an attacker from injecting a DNS search path via DHCP or other autoconfiguration mechanisms into the resolver.
If SSHFP is checked first and SSH host key verification can be configured to require SSHFP, then host key rollover is achieved by replacing the SSHFP in DNS, and revocation is achieved by removing it. DNSSEC integrity is essential for these operations.
Since DNSSEC only protects the fingerprint after it is signed, the fingerprint must be transferred securely from the SSH host administrator to the DNS zone administrator — either manually or via secure DNS dynamic update (RFC 3007).
The SSHFP RDATA encodes: algorithm (8-bit octet), fingerprint type (8-bit octet), followed by the fingerprint as a variable-length opaque octet string. The fingerprint is calculated over the public key blob as described in RFC 4253.