Internet DRAFT - draft-weber-secsh-msg-hostkeys

draft-weber-secsh-msg-hostkeys






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]