INTERNET DRAFT Joel N. Weber II August 14, 2003 Expires February 14, 2004 Secure Shell ``pgp-sign-*'' Public Key Algorithms draft-weber-secsh-pgp-sign-00.txt This document is an Internet-Draft and is subject to all the 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html The distribution of this memo is unlimited. It is filed as draft- weber-secsh-pgp-sign-00.txt, and expires 14 February 2004. Please send comments to the author or to ietf-ssh@netbsd.org ABSTRACT This document clarifies details of using OpenPGP keys as host keys and user authentication keys in the Secure Shell protocol. Preventing man in the middle attacks is an important part of security, and in many circumstances verifying the authenticity of an OpenPGP key will be easier than verifying the authenticity of an ssh- rsa or ssh-dss key. INTRODUCTION The Secure Shell Transport protocol [TRANSPORT] defines the host key types pgp-sign-rsa and pgp-sign-dss, which allow the decentralized certification model of the OpenPGP standard [RFC2440] to be used in conjunction with the Secure Shell protocol. This has the potential to be more effective than the traditional ssh- Weber Secure Shell ``pgp-sign-*'' [Page 1] draft-weber-secsh-pgp-sign-00.txt August 14 2003 rsa and ssh-dss keys with a local database on the client in preventing man in the middle attacks involving accepting an attacker's host key, because it is typically easier to determine whether a new OpenPGP key belongs to the real host than a new ssh-rsa or ssh-dss key. An OpenPGP key also can be used for public key user authentication. This document fills in details not adaquately explained by [TRANSPORT]. 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. KEY/CERTIFICATE If a subkey is being used by the key exchange algorithm for the signature of the hash, the choice of ``pgp-sign-dss'' vs ``pgp-sign- rsa'' is made on the basis of the subkey being used. If the top- level key is used for the signature, then the top-level's key is used to determine which Secure Shell key type identifier to use. The key/certificate consists of a single toplevel key, a self- signature of that key, zero or more subkeys with signatures binding them to the toplevel key, and zero or more certification packets, all in OpenPGP binary format. The keys and signatures may use any algorithm supported by an OpenPGP implementation, as long as the subkey or toplevel key used for the actual signature is of a type which has a corresponding Secure Shell key format identifier. USER ID VALUE Every OpenPGP format key has a user ID identifying it. For use as a host key with the Secure Shell protocol, the section in angle brackets MUST be of the form where example.com is the hostname of the Secure Shell server. The hostname in the key's user ID MUST be fully qualified. Clients SHOULD ignore user ID values which do not meet the requirements of this paragraph, unless they have been explicitly configured otherwise. The key SHOULD have a user ID for every name which is used as the hostname of the Secure Shell server where the OpenPGP key is used as the host key. DNS aliases for hostnames SHOULD NOT be trusted; if the goal is to trust DNSSEC, then it is RECOMMENDED that DNSSEC be used to distribute the host key fingerprint rather than using an OpenPGP host Weber Secure Shell ``pgp-sign-*'' [Page 2] draft-weber-secsh-pgp-sign-00.txt August 14 2003 key. Clients SHOULD NOT treat an unqualified hostname as matching if doing so might involve trusting DNS in a way that it should not be trusted. For example, a DNS resolver which is configured to search multiple domain names could be tricked by an attacker into choosing a different domain names than the one the user intended. If the domain name comes from unauthenticated DHCP, it also SHOULD NOT be used for canonicalization. KEY VERIFICATION When verifying a signature during initial key exchange, an implementation SHOULD reject the signature if there is no trusted path through unexpired signatures, or if the key or subkey is expired. An implementation SHOULD ignore any signatures on the key used to sign the hash which are made on user ID values that do not correspond to the hostname being used for the connection. An implementation MAY disregard the trust and expiration during rekeying if the key was used during initial key exchange or in a subsequent rekeying and was determined to be trusted at that time. An implementation MAY disregard trust information for user authentication, but MUST NOT disregard expiration. An implementation MAY prompt the user to collect information about which keys are trusted after recieving a key from a server before deciding whether an adaquate trust path exists. It is frequently the case that verifying the trust path will involve both RSA and DSS keys; therefore, it is RECOMMENDED that implementations support both. KEYRING MANAGEMENT A client MAY unconditionally add any key recieved from an ssh server to the client's keyring at the begining of the connection. If this is done, the end user documentation SHOULD warn that an attacker can add arbitrary keys to the keyring in this way. A client MAY choose to add a key to the keyring only when it can be determined that they will be trusted once they are added, or MAY add trusted keys unconditionally and prompt the user before adding an untrusted key to the keyring. It may be necessary to retrieve additional toplevel OpenPGP keys from a keyserver or by other means in order to establish a trust path. A Weber Secure Shell ``pgp-sign-*'' [Page 3] draft-weber-secsh-pgp-sign-00.txt August 14 2003 Secure Shell client MAY include facilities to support this, or MAY leave this as the responsibility of the OpenPGP implementation being used. A server doing public key user authentication using an OpenPGP key MUST NOT unconditionally add data provided by arbitrary unauthenticated clients to its keyring. However, it MAY add new subkeys which have valid binding signatures made by a toplevel key which is authorized, to facilitate the use of subkeys which periodically expire. Such a server SHOULD NOT add new certifications to the keyring in this fashion, however. REVOCATION Implementations of pgp-sign-* SHOULD support passing revocation certificates from the server to the client using SSH_MSG_HOSTKEYS, as described in [HOSTKEYS], in order to facilitate making stolen, revoked private keys become unusable. CLOCK CONSIDERATIONS If the system clock can be manipulated by an attacker, expired keys may be mistakenly treated as unexpired. End user documentation SHOULD warn of this. LOCAL DATABASE CONSIDERATIONS Client implementations SHOULD make sure that once a host has been connected to using a ``pgp-sign-*'' key, a subsequent connection to a man-in-the-middle attacker which offers keys of other types which are not recognizable as trusted offers a different and stronger warning than when no previous host key information exists for a host. This can either be done by checking the OpenPGP keyring before deciding that a host key is new, or by making an entry in the same database where ``ssh-rsa'' and ``ssh-dss'' keys are stored. The latter approach may have some performance advantages, and may also allow for more code reuse, especially in implementations of the Secure Shell protocol which also support other key exchange algthorithms such as the GSSAPI family of key exchange algorithms. SECURITY CONSIDERATIONS This entire document is about security considerations. AUTHOR'S ADDRESS Joel N. Weber II Weber Secure Shell ``pgp-sign-*'' [Page 4] draft-weber-secsh-pgp-sign-00.txt August 14 2003 185 Lowell St #2 Somerville MA 02144-2629 Email: weber@joelweber.com NORMATIVE REFERENCES [RFC2026] S. Bradner, RFC2026, BCP 9: "The Internet Standard Process - Revision 3," October 1996, Obsoletes - RFC 1602, Status: Best Current Practice. [RFC2119] S. Bradner, RFC 2119, BCP 14: "Key words for use in RFCs to Indicate Requirement Levels," March 1997. [RFC2440] J. Callas, L. Donnerhacke, H. Finney, R. Thayer, RFC2440: "OpenPGP Message Format," November 1998. [TRANSPORT] RFC-Editor: To be replaced by RFC number for draft-ietf- secsh-transport INFORMATIVE REFERENCES [HOSTKEYS] draft-weber-secsh-msg-hostkeys-00.txt, not yet submitted. IPR NOTICES 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. COPYRIGHT NOTICE Copyright (C) The Internet Society 2003. All Rights Reserved. Weber Secure Shell ``pgp-sign-*'' [Page 5] draft-weber-secsh-pgp-sign-00.txt August 14 2003 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 implmentation 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 assigns. 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Weber Secure Shell ``pgp-sign-*'' [Page 6]