INTERNET DRAFT Joel N. Weber II October 18, 2003 Expires April 18, 2004 SSH_MSG_HOSTKEYS draft-weber-secsh-msg-hostkeys-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-msg-hostkeys-00.txt, and expires 18 April 2004. Please send comments to the author or to ietf-ssh@netbsd.org ABSTRACT This document defines the message SSH_MSG_HOSTKEYS for the Secure Shell transport protocol. This message is used to send host keys for future use, and to provide information about revoked host keys. INTRODUCTION This document defines a new message for the Secure Shell transport protocol, SSH_MSG_HOSTKEYS. This message is used after SSH_MSG_NEWKEYS messages have been sent, so that an encrypted and intergrity protected channel exists, and the client has verified that it is connected to the correct server. One purpose of SSH_MSG_HOSTKEYS is to send host keys which can be used to authenticate future sessions, primarily in cases where receiving a host key over an authenticated channel will demonstrate Weber SSH_MSG_HOSTKEYS [Page 1] draft-weber-secsh-msg-hostkeys-00.txt October 18 2003 its validity. For example, some key exchange algorithms such as the GSSAPI family of key exchange algorithms can use credentials which may not always be available, and using the authenticated channel to pass a key of a type such as ssh-rsa or ssh-dss may be useful. Advertising a new ssh-rsa or ssh-dss key before putting it into service in order to allow a smooth rollover to the new key is another potential use for this message. Another purpose of SSH_MSG_HOSTKEYS is to facilitate the revocation of keys. For keys of types such as ssh-rsa and ssh-dss, which do not have any concept of a revocation certificate, this is done by having the client disable those keys which the server is no longer advertising; for key types that support revocation certificates, such as pgp-sign-rsa, this provides a mechanism for sending revocation certificates, so that an attacker later presenting a certified key without presenting a revocation certificate will be thwarted. It is also possible to use keys that are sent via SSH_MSG_HOSTKEYS when rekeying, especially if the credentials used for the initial key exchange are no longer available. SSH_MSG_HOSTKEYS does not provide any mechanism for specifying that a key expires; if key expiration is needed, use a key format that stores an expiration date. For example, if the functionality of an ssh-rsa or ssh-dss key is desired but an expiration date is also needed, a self-signed X.509 certificate may be an appropriate choice. 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. MESSAGE FORMAT The start of an SSH_MSG_HOSTKEYS message is: byte SSH_MSG_HOSTKEYS int version int subtype If a client conforming to this version of the specification recieves a message with a subtype value which is not equal to SSH_MSG_HOSTKEYS_REPLY, it MUST respond with SSH_MSG_UNIMPLEMENTED. If a server conforming to this version of the specification recieves a message with a subtype value which is not equal to SSH_MSG_HOSTKEYS_REQUEST, it MUST respond with SSH_MSG_UNIMPLEMENTED. SSH_MSG_HOSTKEYS_REQUEST Weber SSH_MSG_HOSTKEYS [Page 2] draft-weber-secsh-msg-hostkeys-00.txt October 18 2003 The client sends the following request to the server: byte SSH_MSG_HOSTKEYS int version int SSH_MSG_HOSTKEYS_REQUEST A client conforming to this version of the protocol MUST send a version of 0. A client conforming to this version of the specification MUST NOT send this message until after SSH_MSG_NEWKEYS has been sent by both the client and server. A server conforming to this version of the protocol MUST ignore the value sent in the version field, and MUST always reply with a version 0 message. A server MUST ignore any data after the version field. A server conforming to this version of the specification MUST reply with SSH_MSG_UNIMPLEMENTED if it recieves this message before both sides have send SSH_MSG_NEWKEYS. A server which does not support this message and which conforms to the protocol described in [TRANSPORT] will respond to the client with SSH_MSG_UNIMPLEMENTED. Implementation note: It is believed that some servers which violate the protocol described in [TRANSPORT] will terminate the connection when no subsystem is active, so clients MAY wait until the ssh-userauth service is active before sending this message. SSH_MSG_HOSTKEYS_REPLY A server conforming to this version of the protocol MUST NOT send SSH_MSG_HOSTKEYS except in response to recieving SSH_MSG_HOSTKEYS. However, a client conforming to this version of the protocol MUST reply to any SSH_MSG_HOSTKEYS message it recieves which has a version which is not zero by sending SSH_MSG_UNIMPLEMENTED, regardless of when in the protocol exchange it recieves the message. When determining the version, a client MUST ignore the presence or absence of any data following the subtype field. A client conforming to this specification MUST also reply to any unsolicited SSH_MSG_HOSTKEYS by sending SSH_MSG_UNIMPLEMENTED. When the server recieves a SSH_MSG_HOSTKEYS request, it replies with a message starting with: byte SSH_MSG_HOSTKEYS int version int SSH_MSG_HOSTKEYS_REPLY int tuple_count Weber SSH_MSG_HOSTKEYS [Page 3] draft-weber-secsh-msg-hostkeys-00.txt October 18 2003 after the tuple_count field are tuple_count occurances of the following: string key type string key data Server Behavior For keys which are currently used, the server MUST send any keys of types not supporting revocation, and SHOULD send any other keys which do not have certificates. In addition, the server SHOULD send keys having certificates which are self-signed or otherwise not likely to be verifyable by a client, and MAY send other keys. There MAY be more than one active key of any given type. The server SHOULD include revocation certificates for any keys of types which support revocation certificates and which are no longer used. This includes any keys which have any sort of third-party certification which a client may choose to trust, as well as any keys which have been sent via SSH_MSG_HOSTKEYS in the past. The revocation certificates SHOULD include revocation certificates for expired keys, in order to remove the possibility of an attacker manipulating the system clock in order to use an expired key. Client Behavior For unrevoked keys of types where the determination of whether the key is trusted is influenced by whether it has been sent via SSH_MSG_HOSTKEYS, the client SHOULD add any keys it receives in an SSH_MSG_HOSTKEYS message to its database. It MAY prompt the user before doing so. The client MAY take these actions for keys of any type. For key types which do not support revocation certificates the client SHOULD mark as unusable or delete from its database any keys which it currently has for the server it is connected to which are not included in the SSH_MSG_HOSTKEYS message. The client SHOULD store all revocation certificates it recieves, so that if an attacker presents the key corresponding to the revocation certificate in the future, the client will know it should reject that key. For key types which support revocation certificates, the client SHOULD display a warning if its database contains an expired key for which it does not have a revocation certificate, regardless of whether that key has been sent in the current SSH_MSG_HOSTKEYS. The client SHOULD display a warning if it has a stored revocation Weber SSH_MSG_HOSTKEYS [Page 4] draft-weber-secsh-msg-hostkeys-00.txt October 18 2003 certificate for the host it is connected to but the host omits the revocation certificate from the SSH_MSG_HOSTKEYS. Some key types include a field which allows the key to name which server it applies to. The server MAY include keys which correspond to another server. A client SHOULD store any revocation certificates recieved in this fashion, as long as the revocation certificate is designed in such a way that only a possesor of the host's private key or trusted third party's private key could have created the revocation certificate. A client SHOULD ignore any other keys which do not correspond to the server it is currently connected to, unless it has specific knowlege that the server it is connected to is especially trusted, or that several servers are equally trusted and a part of the same administrative domain. SUBTYPE VALUES SSH_MSG_HOSTKEYS_REQUEST 0 SSH_MSG_HOSTKEYS_REPLY 1 IANA CONSIDERATIONS The value of SSH_MSG_HOSTKEYS is to be assigned by IANA from the range of message numbers reserved for transport layer generic messages (1 to 19). Assignment to take place when the document is published as an RFC, per section 1 of draft-ietf-secsh- assignednumbers-04.txt. SECURITY CONSIDERATIONS This protocol can be used to provide authenticated key distribution. The strength of this authentication is only as good as the authenticity of the key material used to authenticate the Secure Shell transport layer session being used to transport the keys, and this authenticity is only guaranteed after SSH_MSG_NEWKEYS has been exchanged. This protocol is only effective at sending revocation certificates once a client happens to connect to the correct server; if a client consistently connects to a man-in-the-middle attacker, it may never learn of the revocation certificate against the key that a man-in- the-middle attacker may be using. For key types which support revocation certificates, this protocol does not provide a way to revoke the key if it becomes impossible to generate a revocation certificate, such as if the private key is lost. Therefore, a revocation certificate SHOULD be generated and stored in a secure offline location at the time the key is created. Weber SSH_MSG_HOSTKEYS [Page 5] draft-weber-secsh-msg-hostkeys-00.txt October 18 2003 ACKNOWLEGEMENTS The basic requirements and basic design of the message type described here were worked out in an email discussion between Jeffrey Hutzelman, Joel N. Weber II, and Nicolas Williams. AUTHOR'S ADDRESS Joel N. Weber II 185 Lowell St #2 Somerville MA 02144-2629 Email: weber@joelweber.com NORMATIVE REFERENCES [RFC2119] S. Bradner, RFC 2119, BCP 14: "Key words for use in RFCs to Indicate Requirement Levels," March 1997. [TRANSPORT] RFC-Editor: To be replaced by RFC number for draft-ietf- secsh-transport 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. This document and translations of it may be copied and furnished to Weber SSH_MSG_HOSTKEYS [Page 6] draft-weber-secsh-msg-hostkeys-00.txt October 18 2003 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 SSH_MSG_HOSTKEYS [Page 7]