Subject: updated transport & userauth drafts

From: Darren Moffat <[email-masked]>
Date: Thu, 28 Feb 2002 21:19:37 -0800 (PST)

The updated transport and userauth drafts have been submitted and are in the
queue to comeout by March 11th.

Since this is a little while away I've attached copies below.

The two issues addressed are the x.509 and the stonger language on dealing
with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ.

No changes are now possible until after the next IETF.

--
Darren J Moffat

Network Working Group                                          T. Ylonen
Internet-Draft                                                T. Kivinen
Expires: August 29, 2002                SSH Communications Security Corp
                                                             M. Saarinen
                                                 University of Jyvaskyla
                                                                T. Rinne
                                                             S. Lehtinen
                                        SSH Communications Security Corp
                                                       February 28, 2002

                      SSH Authentication Protocol
                    draft-ietf-secsh-userauth-15.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all 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/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 29, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   SSH is a protocol for secure remote login and other secure network
   services over an insecure network.  This document describes the SSH
   authentication protocol framework and public key, password, and host-
   based client authentication methods.  Additional authentication
   methods are described in separate documents.  The SSH authentication
   protocol runs on top of the SSH transport layer protocol and provides

Ylonen, et. al.          Expires August 29, 2002                [Page 1]

Internet-Draft         SSH Authentication Protocol         February 2002

   a single authenticated tunnel for the SSH connection protocol.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The Authentication Protocol Framework  . . . . . . . . . . . .  3
   2.1 Authentication Requests  . . . . . . . . . . . . . . . . . . .  4
   2.2 Responses to Authentication Requests . . . . . . . . . . . . .  4
   2.3 The "none" Authentication Request  . . . . . . . . . . . . . .  6
   2.4 Completion of User Authentication  . . . . . . . . . . . . . .  6
   2.5 Banner Message . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Authentication Protocol Message Numbers  . . . . . . . . . . .  7
   4.  Public Key Authentication Method: publickey  . . . . . . . . .  7
   5.  Password Authentication Method: password . . . . . . . . . . .  9
   6.  Host-Based Authentication: hostbased . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  Additional Information . . . . . . . . . . . . . . . . . . . . 13
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15

Ylonen, et. al.          Expires August 29, 2002                [Page 2]

Internet-Draft         SSH Authentication Protocol         February 2002

1. Introduction

   The SSH authentication protocol is a general-purpose user
   authentication protocol.  It is intended to be run over the SSH
   transport layer protocol [SSH-TRANS].  This protocol assumes that the
   underlying protocols provide integrity and confidentiality
   protection.

   This document should be read only after reading the SSH architecture
   document [SSH-ARCH].  This document freely uses terminology and
   notation from the architecture document without reference or further
   explanation.

   The service name for this protocol is "ssh-userauth".

   When this protocol starts, it receives the session identifier from
   the lower-level protocol (this is the exchange hash H from the first
   key exchange).  The session identifier uniquely identifies this
   session and is suitable for signing in order to prove ownership of a
   private key.  This protocol also needs to know whether the lower-
   level protocol provides confidentiality protection.

2. The Authentication Protocol Framework

   The server drives the authentication by telling the client which
   authentication methods can be used to continue the exchange at any
   given time.  The client has the freedom to try the methods listed by
   the server in any order.  This gives the server complete control over
   the authentication process if desired, but also gives enough
   flexibility for the client to use the methods it supports or that are
   most convenient for the user, when multiple methods are offered by
   the server.

   Authentication methods are identified by their name, as defined in
   [SSH-ARCH].  The "none" method is reserved, and MUST NOT be listed as
   supported.  However, it MAY be sent by the client.  The server MUST
   always reject this request, unless the client is to be allowed in
   without any authentication, in which case the server MUST accept this
   request.  The main purpose of sending this request is to get the list
   of supported methods from the server.

   The server SHOULD have a timeout for authentication, and disconnect
   if the authentication has not been accepted within the timeout
   period.  The RECOMMENDED timeout period is 10 minutes.  Additionally,
   the implementation SHOULD limit the number of failed authentication
   attempts a client may perform in a single session (the RECOMMENDED
   limit is 20 attempts).  If the threshold is exceeded, the server
   SHOULD disconnect.

Ylonen, et. al.          Expires August 29, 2002                [Page 3]

Internet-Draft         SSH Authentication Protocol         February 2002

2.1 Authentication Requests

   All authentication requests MUST use the following message format.
   Only the first few fields are defined; the remaining fields depend on
   the authentication method.

     byte      SSH_MSG_USERAUTH_REQUEST
     string    user name (in ISO-10646 UTF-8 encoding [RFC2279])
     string    service name (in US-ASCII)
     string    method name (US-ASCII)
     The rest of the packet is method-specific.

   The user name and service are repeated in every new authentication
   attempt, and MAY change.  The server implementation MUST carefully
   check them in every message, and MUST flush any accumulated
   authentication states if they change.  If it is unable to flush some
   authentication state, it MUST disconnect if the user or service name
   changes.

   The service name specifies the service to start after authentication.
   There may be several different authenticated services provided.  If
   the requested service is not available, the server MAY disconnect
   immediately or at any later time.  Sending a proper disconnect
   message is RECOMMENDED.  In any case, if the service does not exist,
   authentication MUST NOT be accepted.

   If the requested user does not exist, the server MAY disconnect, or
   MAY send a bogus list of acceptable authentication methods, but never
   accept any.  This makes it possible for the server to avoid
   disclosing information on which accounts exist.  In any case, if the
   user does not exist, the authentication request MUST NOT be accepted.

   While there is usually little point for clients to send requests that
   the server does not list as acceptable, sending such requests is not
   an error, and the server SHOULD simply reject requests that it does
   not recognize.

   An authentication request MAY result in a further exchange of
   messages.  All such messages depend on the authentication method
   used, and the client MAY at any time continue with a new
   SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST
   abandon the previous authentication attempt and continue with the new
   one.

2.2 Responses to Authentication Requests

   If the server rejects the authentication request, it MUST respond
   with the following:

Ylonen, et. al.          Expires August 29, 2002                [Page 4]

Internet-Draft         SSH Authentication Protocol         February 2002

     byte      SSH_MSG_USERAUTH_FAILURE
     string    authentications that can continue
     boolean   partial success

   "Authentications that can continue" is a comma-separated list of
   authentication method names that may productively continue the
   authentication dialog.

   It is RECOMMENDED that servers only include those methods in the list
   that are actually useful.  However, it is not illegal to include
   methods that cannot be used to authenticate the user.

   Already successfully completed authentications SHOULD NOT be included
   in the list, unless they really should be performed again for some
   reason.

   "Partial success" MUST be TRUE if the authentication request to which
   this is a response was successful.  It MUST be FALSE if the request
   was not successfully processed.

   When the server accepts authentication, it MUST respond with the
   following:

     byte      SSH_MSG_USERAUTH_SUCCESS

   Note that this is not sent after each step in a multi-method
   authentication sequence, but only when the authentication is
   complete.

   The client MAY send several authentication requests without waiting
   for responses from previous requests.  The server MUST process each
   request completely and acknowledge any failed requests with a
   SSH_MSG_USERAUTH_FAILURE message before processing the next request.

   A request that results in further exchange of messages will be
   aborted by a second request.  It is not possible to send a second
   request without waiting for a response from the server, if the first
   request will result in further exchange of messages.  No
   SSH_MSG_USERAUTH_FAILURE message will be sent for the aborted method.

   SSH_MSG_USERAUTH_SUCCESS MUST be sent only once.  When
   SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication
   requests received after that SHOULD be silently ignored.

   Any non-authentication messages sent by the client after the request
   that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed
   to the service being run on top of this protocol.  Such messages can
   be identified by their message numbers (see Section Message Numbers

Ylonen, et. al.          Expires August 29, 2002                [Page 5]

Internet-Draft         SSH Authentication Protocol         February 2002

   (Section 3)).

2.3 The "none" Authentication Request

   A client may request a list of authentication methods that may
   continue by using the "none" authentication method.

   If no authentication at all is needed for the user, the server MUST
   return SSH_MSG_USERAUTH_SUCCESS.  Otherwise, the server MUST return
   SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of
   authentication methods that can continue.

   This method MUST NOT be listed as supported by the server.

2.4 Completion of User Authentication

   Authentication is complete when the server has responded with
   SSH_MSG_USERAUTH_SUCCESS; all authentication related messages
   received after sending this message SHOULD be silently ignored.

   After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the
   requested service.

2.5 Banner Message

   In some jurisdictions, sending a warning message before
   authentication may be relevant for getting legal protection.  Many
   UNIX machines, for example, normally display text from `/etc/issue',
   or use "tcp wrappers" or similar software to display a banner before
   issuing a login prompt.

   The SSH server may send a SSH_MSG_USERAUTH_BANNER message at any time
   before authentication is successful.  This message contains text to
   be displayed to the client user before authentication is attempted.
   The format is as follows:

     byte      SSH_MSG_USERAUTH_BANNER
     string    message (ISO-10646 UTF-8)
     string    language tag (as defined in [RFC1766])

   The client SHOULD by default display the message on the screen.
   However, since the message is likely to be sent for every login
   attempt, and since some client software will need to open a separate
   window for this warning, the client software may allow the user to
   explicitly disable the display of banners from the server.  The
   message may consist of multiple lines.

   If the message string is displayed, control character filtering

Ylonen, et. al.          Expires August 29, 2002                [Page 6]

Internet-Draft         SSH Authentication Protocol         February 2002

   discussed in [SSH-ARCH] SHOULD be used to avoid attacks by sending
   terminal control characters.

3. Authentication Protocol Message Numbers

   All message numbers used by this authentication protocol are in the
   range from 50 to 79, which is part of the range reserved for
   protocols running on top of the SSH transport layer protocol.

   Message numbers of 80 and higher are reserved for protocols running
   after this authentication protocol, so receiving one of them before
   authentication is complete is an error, to which the server MUST
   respond by disconnecting (preferably with a proper disconnect message
   sent first to ease troubleshooting).

   After successful authentication, such messages are passed to the
   higher-level service.

   These are the general authentication message codes:

     #define SSH_MSG_USERAUTH_REQUEST            50
     #define SSH_MSG_USERAUTH_FAILURE            51
     #define SSH_MSG_USERAUTH_SUCCESS            52
     #define SSH_MSG_USERAUTH_BANNER             53

   In addition to the above, there is a range of message numbers
   (60..79) reserved for method-specific messages.  These messages are
   only sent by the server (client sends only SSH_MSG_USERAUTH_REQUEST
   messages).  Different authentication methods reuse the same message
   numbers.

4. Public Key Authentication Method: publickey

   The only REQUIRED authentication method is public key authentication.
   All implementations MUST support this method; however, not all users
   need to have public keys, and most local policies are not likely to
   require public key authentication for all users in the near future.

   With this method, the possession of a private key serves as
   authentication.  This method works by sending a signature created
   with a private key of the user.  The server MUST check that the key
   is a valid authenticator for the user, and MUST check that the
   signature is valid.  If both hold, the authentication request MUST be
   accepted; otherwise it MUST be rejected.  (Note that the server MAY
   require additional authentications after successful authentication.)

   Private keys are often stored in an encrypted form at the client
   host, and the user must supply a passphrase before the signature can

Ylonen, et. al.          Expires August 29, 2002                [Page 7]

Internet-Draft         SSH Authentication Protocol         February 2002

   be generated.  Even if they are not, the signing operation involves
   some expensive computation.  To avoid unnecessary processing and user
   interaction, the following message is provided for querying whether
   authentication using the key would be acceptable.

     byte      SSH_MSG_USERAUTH_REQUEST
     string    user name
     string    service
     string    "publickey"
     boolean   FALSE
     string    public key algorithm name
     string    public key blob

   Public key algorithms are defined in the transport layer
   specification [SSH-TRANS].  The public key blob may contain
   certificates.

   Any public key algorithm may be offered for use in authentication.
   In particular, the list is not constrained by what was negotiated
   during key exchange.  If the server does not support some algorithm,
   it MUST simply reject the request.

   The server MUST respond to this message with either
   SSH_MSG_USERAUTH_FAILURE or with the following:

     byte      SSH_MSG_USERAUTH_PK_OK
     string    public key algorithm name from the request
     string    public key blob from the request

   To perform actual authentication, the client MAY then send a
   signature generated using the private key.  The client MAY send the
   signature directly without first verifying whether the key is
   acceptable.  The signature is sent using the following packet:

     byte      SSH_MSG_USERAUTH_REQUEST
     string    user name
     string    service
     string    "publickey"
     boolean   TRUE
     string    public key algorithm name
     string    public key to be used for authentication
     string    signature

   Signature is a signature by the corresponding private key over the
   following data, in the following order:

     string    session identifier
     byte      SSH_MSG_USERAUTH_REQUEST

Ylonen, et. al.          Expires August 29, 2002                [Page 8]

Internet-Draft         SSH Authentication Protocol         February 2002

     string    user name
     string    service
     string    "publickey"
     boolean   TRUE
     string    public key algorithm name
     string    public key to be used for authentication

   When the server receives this message, it MUST check whether the
   supplied key is acceptable for authentication, and if so, it MUST
   check whether the signature is correct.

   If both checks succeed, this method is successful.  Note that the
   server may require additional authentications.  The server MUST
   respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are
   needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more
   authentications are needed).

   The following method-specific message numbers are used by the
   publickey authentication method.

     /* Key-based */
     #define SSH_MSG_USERAUTH_PK_OK              60

5. Password Authentication Method: password

   Password authentication uses the following packets.  Note that a
   server MAY request the user to change the password.  All
   implementations SHOULD support password authentication.

     byte      SSH_MSG_USERAUTH_REQUEST
     string    user name
     string    service
     string    "password"
     boolean   FALSE
     string    plaintext password (ISO-10646 UTF-8)

   Note that the password is encoded in ISO-10646 UTF-8.  It is up to
   the server how it interprets the password and validates it against
   the password database.  However, if the client reads the password in
   some other encoding (e.g., ISO 8859-1 (ISO Latin1)), it MUST convert
   the password to ISO-10646 UTF-8 before transmitting, and the server
   MUST convert the password to the encoding used on that system for
   passwords.

   Note that even though the cleartext password is transmitted in the
   packet, the entire packet is encrypted by the transport layer.  Both
   the server and the client should check whether the underlying

Ylonen, et. al.          Expires August 29, 2002                [Page 9]

Internet-Draft         SSH Authentication Protocol         February 2002

   transport layer provides confidentiality (i.e., if encryption is
   being used).  If no confidentiality is provided (none cipher),
   password authentication SHOULD be disabled.  If there is no
   confidentiality or no MAC, password change SHOULD be disabled.

   Normally, the server responds to this message with success or
   failure.  However, if the password has expired the server SHOULD
   indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ.
   In anycase the server MUST NOT allow an expired password to be used
   for authentication.

     byte      SSH_MSG_USERAUTH_PASSWD_CHANGEREQ
     string    prompt (ISO-10646 UTF-8)
     string    language tag (as defined in [RFC1766])

   In this case, the client MAY continue with a different authentication
   method, or request a new password from the user and retry password
   authentication using the following message.  The client MAY also send
   this message instead of the normal password authentication request
   without the server asking for it.

     byte      SSH_MSG_USERAUTH_REQUEST
     string    user name
     string    service
     string    "password"
     boolean   TRUE
     string    plaintext old password (ISO-10646 UTF-8)
     string    plaintext new password (ISO-10646 UTF-8)

   The server must reply to request message with
   SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another
   SSH_MSG_USERAUTH_PASSWD_CHANGEREQ.  The meaning of these is as
   follows:

      SSH_MSG_USERAUTH_SUCCESS The password has been changed, and
      authentication has been successfully completed.

      SSH_MSG_USERAUTH_FAILURE with partial success The password has
      been changed, but more authentications are needed.

      SSH_MSG_USERAUTH_FAILURE without partial success The password has
      not been changed.  Either password changing was not supported, or
      the old password was bad.  Note that if the server has already
      sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports
      changing the password.

      SSH_MSG_USERAUTH_CHANGEREQ The password was not changed because
      the new password was not acceptable (e.g.  too easy to guess).

Ylonen, et. al.          Expires August 29, 2002               [Page 10]

Internet-Draft         SSH Authentication Protocol         February 2002

   The following method-specific message numbers are used by the
   password authentication method.

     #define SSH_MSG_USERAUTH_PASSWD_CHANGEREQ   60

6. Host-Based Authentication: hostbased

   Some sites wish to allow authentication based on the host where the
   user is coming from, and the user name on the remote host.  While
   this form of authentication is not suitable for high-security sites,
   it can be very convenient in many environments.  This form of
   authentication is OPTIONAL.  When used, special care SHOULD be taken
   to prevent a regular user from obtaining the private host key.

   The client requests this form of authentication by sending the
   following message.  It is similar to the UNIX "rhosts" and
   "hosts.equiv" styles of authentication, except that the identity of
   the client host is checked more rigorously.

   This method works by having the client send a signature created with
   the private key of the client host, which the server checks with that
   host's public key.  Once the client host's identity is established,
   authorization (but no further authentication) is performed based on
   the user names on the server and the client, and the client host
   name.

     byte      SSH_MSG_USERAUTH_REQUEST
     string    user name
     string    service
     string    "hostbased"
     string    public key algorithm for host key
     string    public host key and certificates for client host
     string    client host name (FQDN; US-ASCII)
     string    user name on the client host (ISO-10646 UTF-8)
     string    signature

   Public key algorithm names for use in "public key algorithm for host
   key" are defined in the transport layer specification.  The "public
   host key for client host" may include certificates.

   Signature is a signature with the private host key of the following
   data, in this order:

     string    session identifier
     byte      SSH_MSG_USERAUTH_REQUEST
     string    user name
     string    service

Ylonen, et. al.          Expires August 29, 2002               [Page 11]

Internet-Draft         SSH Authentication Protocol         February 2002

     string    "hostbased"
     string    public key algorithm for host key
     string    public host key and certificates for client host
     string    client host name (FQDN; US-ASCII)
     string    user name on the client host(ISO-10646 UTF-8)

   The server MUST verify that the host key actually belongs to the
   client host named in the message, that the given user on that host is
   allowed to log in, and that the signature is a valid signature on the
   appropriate value by the given host key.  The server MAY ignore the
   client user name, if it wants to authenticate only the client host.

   It is RECOMMENDED that whenever possible, the server perform
   additional checks to verify that the network address obtained from
   the (untrusted) network matches the given client host name.  This
   makes exploiting compromised host keys more difficult.  Note that
   this may require special handling for connections coming through a
   firewall.

7. Security Considerations

   The purpose of this protocol is to perform client user
   authentication.  It assumed that this runs over a secure transport
   layer protocol, which has already authenticated the server machine,
   established an encrypted communications channel, and computed a
   unique session identifier for this session.  The transport layer
   provides forward secrecy for password authentication and other
   methods that rely on secret data.

   The server may go into a "sleep" period after repeated unsuccessful
   authentications to make key search harder.

   If the transport layer does not provide encryption, authentication
   methods that rely on secret data SHOULD be disabled.  If it does not
   provide MAC protection, requests to change authentication data (e.g.
   password change) SHOULD be disabled to avoid an attacker from
   modifying the ciphertext without being noticed, rendering the new
   authentication data unusable (denial of service).

   Several authentication methods with different security
   characteristics are allowed.  It is up to the server's local policy
   to decide which methods (or combinations of methods) it is willing to
   accept for each user.  Authentication is no stronger than the weakest
   combination allowed.

   Special care should be taken when designing debug messages.  These
   messages may reveal surprising amounts of information about the host
   if not properly designed.  Debug messages can be disabled (during

Ylonen, et. al.          Expires August 29, 2002               [Page 12]

Internet-Draft         SSH Authentication Protocol         February 2002

   user authentication phase) if high security is required.

8. Trademark Issues

   As of this writing, SSH Communications Security Oy claims ssh as its
   trademark.  As with all IPR claims the IETF takes no position
   regarding the validity or scope of this trademark claim.

9. Additional Information

   The current document editor is: [email-masked].  Comments on
   this internet draft should be sent to the IETF SECSH working group,
   details at: http://ietf.org/html.charters/secsh-charter.html

References

   [RFC1766]       Alvestrand, H., "Tags for the Identification of
                   Languages", RFC 1766, March 1995.

   [RFC2279]       Yergeau, F., "UTF-8, a transformation format of ISO
                   10646", RFC 2279, January 1998.

   [SSH-ARCH]      Ylonen, T., "SSH Protocol Architecture", I-D draft-
                   ietf-architecture-12.txt, July 2001.

   [SSH-TRANS]     Ylonen, T., "SSH Transport Layer Protocol", I-D
                   draft-ietf-transport-13.txt, July 2001.

   [SSH-USERAUTH]  Ylonen, T., "SSH Authentication Protocol", I-D draft-
                   ietf-userauth-15.txt, July 2001.

   [SSH-CONNECT]   Ylonen, T., "SSH Connection Protocol", I-D draft-
                   ietf-connect-15.txt, July 2001.

Authors' Addresses

   Tatu Ylonen
   SSH Communications Security Corp
   Fredrikinkatu 42
   HELSINKI  FIN-00100
   Finland

   EMail: [email-masked]

Ylonen, et. al.          Expires August 29, 2002               [Page 13]

Internet-Draft         SSH Authentication Protocol         February 2002

   Tero Kivinen
   SSH Communications Security Corp
   Fredrikinkatu 42
   HELSINKI  FIN-00100
   Finland

   EMail: [email-masked]

   Markku-Juhani O. Saarinen
   University of Jyvaskyla

   Timo J. Rinne
   SSH Communications Security Corp
   Fredrikinkatu 42
   HELSINKI  FIN-00100
   Finland

   EMail: [email-masked]

   Sami Lehtinen
   SSH Communications Security Corp
   Fredrikinkatu 42
   HELSINKI  FIN-00100
   Finland

   EMail: [email-masked]

Ylonen, et. al.          Expires August 29, 2002               [Page 14]

Internet-Draft         SSH Authentication Protocol         February 2002

Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   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 implementation 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Ylonen, et. al.          Expires August 29, 2002               [Page 15]


Network Working Group                                          T. Ylonen
Internet-Draft                                                T. Kivinen
Expires: August 29, 2002                SSH Communications Security Corp
                                                             M. Saarinen
                                                 University of Jyvaskyla
                                                                T. Rinne
                                                             S. Lehtinen
                                        SSH Communications Security Corp
                                                       February 28, 2002

                      SSH Transport Layer Protocol
                   draft-ietf-secsh-transport-13.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all 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/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 29, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   SSH is a protocol for secure remote login and other secure network
   services over an insecure network.

   This document describes the SSH transport layer protocol which
   typically runs on top of TCP/IP.  The protocol can be used as a basis
   for a number of secure network services.  It provides strong

Ylonen, et. al.          Expires August 29, 2002                [Page 1]

Internet-Draft        SSH Transport Layer Protocol         February 2002

   encryption, server authentication, and integrity protection.  It may
   also provide compression.

   Key exchange method, public key algorithm, symmetric encryption
   algorithm, message authentication algorithm, and hash algorithm are
   all negotiated.

   This document also describes the Diffie-Hellman key exchange method
   and the minimal set of algorithms that are needed to implement the
   SSH transport layer protocol.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
   3.  Connection Setup . . . . . . . . . . . . . . . . . . . . . . .  3
   3.1 Use over TCP/IP  . . . . . . . . . . . . . . . . . . . . . . .  3
   3.2 Protocol Version Exchange  . . . . . . . . . . . . . . . . . .  3
   3.3 Compatibility With Old SSH Versions  . . . . . . . . . . . . .  4
   3.4 Old Client, New Server . . . . . . . . . . . . . . . . . . . .  4
   3.5 New Client, Old Server . . . . . . . . . . . . . . . . . . . .  5
   4.  Binary Packet Protocol . . . . . . . . . . . . . . . . . . . .  5
   4.1 Maximum Packet Length  . . . . . . . . . . . . . . . . . . . .  6
   4.2 Compression  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.4 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . .  9
   4.5 Key Exchange Methods . . . . . . . . . . . . . . . . . . . . . 10
   4.6 Public Key Algorithms  . . . . . . . . . . . . . . . . . . . . 10
   5.  Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . . 13
   5.1 Algorithm Negotiation  . . . . . . . . . . . . . . . . . . . . 13
   5.2 Output from Key Exchange . . . . . . . . . . . . . . . . . . . 16
   5.3 Taking Keys Into Use . . . . . . . . . . . . . . . . . . . . . 17
   6.  Diffie-Hellman Key Exchange  . . . . . . . . . . . . . . . . . 17
   6.1 diffie-hellman-group1-sha1 . . . . . . . . . . . . . . . . . . 19
   7.  Key Re-Exchange  . . . . . . . . . . . . . . . . . . . . . . . 19
   8.  Service Request  . . . . . . . . . . . . . . . . . . . . . . . 20
   9.  Additional Messages  . . . . . . . . . . . . . . . . . . . . . 21
   9.1 Disconnection Message  . . . . . . . . . . . . . . . . . . . . 21
   9.2 Ignored Data Message . . . . . . . . . . . . . . . . . . . . . 22
   9.3 Debug Message  . . . . . . . . . . . . . . . . . . . . . . . . 22
   9.4 Reserved Messages  . . . . . . . . . . . . . . . . . . . . . . 23
   10. Summary of Message Numbers . . . . . . . . . . . . . . . . . . 23
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   12. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 24
   13. Additional Information . . . . . . . . . . . . . . . . . . . . 24
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 27

Ylonen, et. al.          Expires August 29, 2002                [Page 2]

Internet-Draft        SSH Transport Layer Protocol         February 2002

1. Introduction

   The SSH transport layer is a secure low level transport protocol.  It
   provides strong encryption, cryptographic host authentication, and
   integrity protection.

   Authentication in this protocol level is host-based; this protocol
   does not perform user authentication.  A higher level protocol for
   user authentication can be designed on top of this protocol.

   The protocol has been designed to be simple, flexible, to allow
   parameter negotiation, and to minimize the number of round-trips.
   Key exchange method, public key algorithm, symmetric encryption
   algorithm, message authentication algorithm, and hash algorithm are
   all negotiated.  It is expected that in most environments, only 2
   round-trips will be needed for full key exchange, server
   authentication, service request, and acceptance notification of
   service request.  The worst case is 3 round-trips.

2. Conventions Used in This Document

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   and "MAY" that appear in this document are to be interpreted as
   described in [RFC2119]

   The used data types and terminology are specified in the architecture
   document [SSH-ARCH]

   The architecture document also discusses the algorithm naming
   conventions that MUST be used with the SSH protocols.

3. Connection Setup

   SSH works over any 8-bit clean, binary-transparent transport.  The
   underlying transport SHOULD protect against transmission errors as
   such errors cause the SSH connection to terminate.

   The client initiates the connection.

3.1 Use over TCP/IP

   When used over TCP/IP, the server normally listens for connections on
   port 22.  This port number has been registered with the IANA, and has
   been officially assigned for SSH.

3.2 Protocol Version Exchange

   When the connection has been established, both sides MUST send an

Ylonen, et. al.          Expires August 29, 2002                [Page 3]

Internet-Draft        SSH Transport Layer Protocol         February 2002

   identification string of the form "SSH-protoversion-softwareversion
   comments", followed by carriage return and newline characters (ASCII
   13 and 10, respectively).  Both sides MUST be able to process
   identification strings without carriage return character.  No null
   character is sent.  The maximum length of the string is 255
   characters, including the carriage return and newline.

   The part of the identification string preceding carriage return and
   newline is used in the Diffie-Hellman key exchange (see Section
   Section 6).

   The server MAY send other lines of data before sending the version
   string.  Each line SHOULD be terminated by a carriage return and
   newline.  Such lines MUST NOT begin with "SSH-", and SHOULD be
   encoded in ISO-10646 UTF-8 [RFC2279] (language is not specified).
   Clients MUST be able to process such lines; they MAY be silently
   ignored, or MAY be displayed to the client user; if they are
   displayed, control character filtering discussed in [SSH-ARCH] SHOULD
   be used.  The primary use of this feature is to allow TCP-wrappers to
   display an error message before disconnecting.

   Version strings MUST consist of printable US-ASCII characters, not
   including whitespaces or a minus sign (-).  The version string is
   primarily used to trigger compatibility extensions and to indicate
   the capabilities of an implementation.  The comment string should
   contain additional information that might be useful in solving user
   problems.

   The protocol version described in this document is 2.0.

   Key exchange will begin immediately after sending this identifier.
   All packets following the identification string SHALL use the binary
   packet protocol, to be described below.

3.3 Compatibility With Old SSH Versions

   During the transition period, it is important to be able to work in a
   way that is compatible with the installed SSH clients and servers
   that use an older version of the protocol.  Information in this
   section is only relevant for implementations supporting compatibility
   with SSH versions 1.x.

3.4 Old Client, New Server

   Server implementations MAY support a configurable "compatibility"
   flag that enables compatibility with old versions.  When this flag is
   on, the server SHOULD identify its protocol version as "1.99".
   Clients using protocol 2.0 MUST be able to identify this as identical

Ylonen, et. al.          Expires August 29, 2002                [Page 4]

Internet-Draft        SSH Transport Layer Protocol         February 2002

   to "2.0".  In this mode the server SHOULD NOT send the carriage
   return character (ASCII 13) after the version identification string.

   In the compatibility mode the server SHOULD NOT send any further data
   after its initialization string until it has received an
   identification string from the client.  The server can then determine
   whether the client is using an old protocol, and can revert to the
   old protocol if required.  In the compatibility mode, the server MUST
   NOT send additional data before the version string.

   When compatibility with old clients is not needed, the server MAY
   send its initial key exchange data immediately after the
   identification string.

3.5 New Client, Old Server

   Since the new client MAY immediately send additional data after its
   identification string (before receiving server's identification), the
   old protocol may already have been corrupted when the client learns
   that the server is old.  When this happens, the client SHOULD close
   the connection to the server, and reconnect using the old protocol.

4. Binary Packet Protocol

   Each packet is in the following format:

     uint32    packet_length
     byte      padding_length
     byte[n1]  payload; n1 = packet_length - padding_length - 1
     byte[n2]  random padding; n2 = padding_length
     byte[m]   mac (message authentication code); m = mac_length

      packet_length
         The length of the packet (bytes), not including MAC or the
         packet_length field itself.

      padding_length
         Length of padding (bytes).

      payload
         The useful contents of the packet.  If compression has been
         negotiated, this field is compressed.  Initially, compression
         MUST be "none".

      random padding
         Arbitrary-length padding, such that the total length of
         (packet_length || padding_length || payload || padding) is a
         multiple of the cipher block size or 8, whichever is larger.

Ylonen, et. al.          Expires August 29, 2002                [Page 5]

Internet-Draft        SSH Transport Layer Protocol         February 2002

         There MUST be at least four bytes of padding.  The padding
         SHOULD consist of random bytes.  The maximum amount of padding
         is 255 bytes.

      mac
         Message authentication code.  If message authentication has
         been negotiated, this field contains the MAC bytes.  Initially,
         the MAC algorithm MUST be "none".

   Note that length of the concatenation of packet length, padding
   length, payload, and padding MUST be a multiple of the cipher block
   size or 8, whichever is larger.  This constraint MUST be enforced
   even when using stream ciphers.  Note that the packet length field is
   also encrypted, and processing it requires special care when sending
   or receiving packets.

   The minimum size of a packet is 16 (or the cipher block size,
   whichever is larger) bytes (plus MAC); implementations SHOULD decrypt
   the length after receiving the first 8 (or cipher block size,
   whichever is larger) bytes of a packet.

4.1 Maximum Packet Length

   All implementations MUST be able to process packets with uncompressed
   payload length of 32768 bytes or less and total packet size of 35000
   bytes or less (including length, padding length, payload, padding,
   and MAC.).  The maximum of 35000 bytes is an arbitrary chosen value
   larger than uncompressed size.  Implementations SHOULD support longer
   packets, where they might be needed, e.g.  if an implementation wants
   to send a very large number of certificates.  Such packets MAY be
   sent if the version string indicates that the other party is able to
   process them.  However, implementations SHOULD check that the packet
   length is reasonable for the implementation to avoid denial-of-
   service and/or buffer overflow attacks.

4.2 Compression

   If compression has been negotiated, the payload field (and only it)
   will be compressed using the negotiated algorithm.  The length field
   and MAC will be computed from the compressed payload.  Encryption
   will be done after compression.

   Compression MAY be stateful, depending on the method.  Compression
   MUST be independent for each direction, and implementations MUST
   allow independently choosing the algorithm for each direction.

   The following compression methods are currently defined:

Ylonen, et. al.          Expires August 29, 2002                [Page 6]

Internet-Draft        SSH Transport Layer Protocol         February 2002

     none     REQUIRED        no compression
     zlib     OPTIONAL        ZLIB (LZ77) compression

   The "zlib" compression is described in [RFC1950] and in [RFC1951].
   The compression context is initialized after each key exchange, and
   is passed from one packet to the next with only a partial flush being
   performed at the end of each packet.  A partial flush means that the
   current compressed block is ended and all data will be output.  If
   the current block is not a stored block, one or more empty blocks are
   added after the current block to ensure that there are at least 8
   bits counting from the start of the end-of-block code of the current
   block to the end of the packet payload.

   Additional methods may be defined as specified in [SSH-ARCH].

4.3 Encryption

   An encryption algorithm and a key will be negotiated during the key
   exchange.  When encryption is in effect, the packet length, padding
   length, payload and padding fields of each packet MUST be encrypted
   with the given algorithm.

   The encrypted data in all packets sent in one direction SHOULD be
   considered a single data stream.  For example, initialization vectors
   SHOULD be passed from the end of one packet to the beginning of the
   next packet.  All ciphers SHOULD use keys with an effective key
   length of 128 bits or more.

   The ciphers in each direction MUST run independently of each other,
   and implementations MUST allow independently choosing the algorithm
   for each direction (if multiple algorithms are allowed by local
   policy).

   The following ciphers are currently defined:

     3des-cbc         REQUIRED          three-key 3DES in CBC mode
     blowfish-cbc     RECOMMENDED       Blowfish in CBC mode
     twofish256-cbc   OPTIONAL          Twofish in CBC mode,
                                        with 256-bit key
     twofish-cbc      OPTIONAL          alias for "twofish256-cbc" (this
                                        is being retained for
                                        historical reasons)
     twofish192-cbc   OPTIONAL          Twofish with 192-bit key
     twofish128-cbc   RECOMMENDED       Twofish with 128-bit key
     aes256-cbc       OPTIONAL          AES (Rijndael) in CBC mode,
                                        with 256-bit key
     aes192-cbc       OPTIONAL          AES with 192-bit key
     aes128-cbc       RECOMMENDED       AES with 128-bit key

Ylonen, et. al.          Expires August 29, 2002                [Page 7]

Internet-Draft        SSH Transport Layer Protocol         February 2002

     serpent256-cbc   OPTIONAL          Serpent in CBC mode, with
                                        256-bit key
     serpent192-cbc   OPTIONAL          Serpent with 192-bit key
     serpent128-cbc   OPTIONAL          Serpent with 128-bit key
     arcfour          OPTIONAL          the ARCFOUR stream cipher
     idea-cbc         OPTIONAL          IDEA in CBC mode
     cast128-cbc      OPTIONAL          CAST-128 in CBC mode
     none             OPTIONAL          no encryption; NOT RECOMMENDED

   The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt-
   encrypt), where the first 8 bytes of the key are used for the first
   encryption, the next 8 bytes for the decryption, and the following 8
   bytes for the final encryption.  This requires 24 bytes of key data
   (of which 168 bits are actually used).  To implement CBC mode, outer
   chaining MUST be used (i.e., there is only one initialization
   vector).  This is a block cipher with 8 byte blocks.  This algorithm
   is defined in [SCHNEIER]

   The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit keys
   [SCHNEIER].  This is a block cipher with 8 byte blocks.

   The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode,
   with 256 bit keys as described [TWOFISH].  This is a block cipher
   with 16 byte blocks.

   The "twofish192-cbc" cipher.  Same as above but with 192-bit key.

   The "twofish128-cbc" cipher.  Same as above but with 128-bit key.

   The "aes256-cbc" cipher is AES (Advanced Encryption Standard),
   formerly Rijndael, in CBC mode.  This version uses 256-bit key.

   The "aes192-cbc" cipher.  Same as above but with 192-bit key.

   The "aes128-cbc" cipher.  Same as above but with 128-bit key.

   The "serpent256-cbc" cipher in CBC mode, with 256-bit key as
   described in the Serpent AES submission.

   The "serpent192-cbc" cipher.  Same as above but with 192-bit key.

   The "serpent128-cbc" cipher.  Same as above but with 128-bit key.

   The "arcfour" is the Arcfour stream cipher with 128 bit keys.  The
   Arcfour cipher is believed to be compatible with the RC4 cipher
   [SCHNEIER].  RC4 is a registered trademark of RSA Data Security Inc.
   Arcfour (and RC4) has problems with weak keys, and should be used
   with caution.

Ylonen, et. al.          Expires August 29, 2002                [Page 8]

Internet-Draft        SSH Transport Layer Protocol         February 2002

   The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER].
   IDEA is patented by Ascom AG.

   The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode
   [RFC2144].

   The "none" algorithm specifies that no encryption is to be done.
   Note that this method provides no confidentiality protection, and it
   is not recommended.  Some functionality (e.g.  password
   authentication) may be disabled for security reasons if this cipher
   is chosen.

   Additional methods may be defined as specified in [SSH-ARCH].

4.4 Data Integrity

   Data integrity is protected by including with each packet a message
   authentication code (MAC) that is computed from a shared secret,
   packet sequence number, and the contents of the packet.

   The message authentication algorithm and key are negotiated during
   key exchange.  Initially, no MAC will be in effect, and its length
   MUST be zero.  After key exchange, the selected MAC will be computed
   before encryption from the concatenation of packet data:

     mac = MAC(key, sequence_number || unencrypted_packet)

   where unencrypted_packet is the entire packet without MAC (the length
   fields, payload and padding), and sequence_number is an implicit
   packet sequence number represented as uint32.  The sequence number is
   initialized to zero for the first packet, and is incremented after
   every packet (regardless of whether encryption or MAC is in use).  It
   is never reset, even if keys/algorithms are renegotiated later.  It
   wraps around to zero after every 2^32 packets.  The packet sequence
   number itself is not included in the packet sent over the wire.

   The MAC algorithms for each direction MUST run independently, and
   implementations MUST allow choosing the algorithm independently for
   both directions.

   The MAC bytes resulting from the MAC algorithm MUST be transmitted
   without encryption as the last part of the packet.  The number of MAC
   bytes depends on the algorithm chosen.

Ylonen, et. al.          Expires August 29, 2002                [Page 9]

Internet-Draft        SSH Transport Layer Protocol         February 2002

   The following MAC algorithms are currently defined:

     hmac-sha1    REQUIRED        HMAC-SHA1 (digest length = key
                                  length = 20)
     hmac-sha1-96 RECOMMENDED     first 96 bits of HMAC-SHA1 (digest
                                  length = 12, key length = 20)
     hmac-md5     OPTIONAL        HMAC-MD5 (digest length = key
                                  length = 16)
     hmac-md5-96  OPTIONAL        first 96 bits of HMAC-MD5 (digest
                                  length = 12, key length = 16)
     none         OPTIONAL        no MAC; NOT RECOMMENDED

   The "hmac-*" algorithms are described in [RFC2104] The "*-n" MACs use
   only the first n bits of the resulting value.

   The hash algorithms are described in [SCHNEIER].

   Additional methods may be defined as specified in [SSH-ARCH].

4.5 Key Exchange Methods

   The key exchange method specifies how one-time session keys are
   generated for encryption and for authentication, and how the server
   authentication is done.

   Only one REQUIRED key exchange method has been defined:

     diffie-hellman-group1-sha1       REQUIRED

   This method is described later in this document.

   Additional methods may be defined as specified in [SSH-ARCH].

4.6 Public Key Algorithms

   This protocol has been designed to be able to operate with almost any
   public key format, encoding, and algorithm (signature and/or
   encryption).

   There are several aspects that define a public key type:
   o  Key format: how is the key encoded and how are certificates
      represented.  The key blobs in this protocol MAY contain
      certificates in addition to keys.
   o  Signature and/or encryption algorithms.  Some key types may not
      support both signing and encryption.  Key usage may also be
      restricted by policy statements in e.g.  certificates.  In this
      case, different key types SHOULD be defined for the different
      policy alternatives.

Ylonen, et. al.          Expires August 29, 2002               [Page 10]

Internet-Draft        SSH Transport Layer Protocol         February 2002

   o  Encoding of signatures and/or encrypted data.  This includes but
      is not limited to padding, byte order, and data formats.

   The following public key and/or certificate formats are currently defined:

   ssh-dss              REQUIRED     sign    Simple DSS
   ssh-rsa              RECOMMENDED  sign    Simple RSA
   x509v3-sign-rsa      OPTIONAL     sign    X.509 certificates (RSA key)
   x509v3-sign-dss      OPTIONAL     sign    X.509 certificates (DSS key)
   spki-sign-rsa        OPTIONAL     sign    SPKI certificates (RSA key)
   spki-sign-dss        OPTIONAL     sign    SPKI certificates (DSS key)
   pgp-sign-rsa         OPTIONAL     sign    OpenPGP certificates (RSA key)
   pgp-sign-dss         OPTIONAL     sign    OpenPGP certificates (DSS key)

   Additional key types may be defined as specified in [SSH-ARCH].

   The key type MUST always be explicitly known (from algorithm
   negotiation or some other source).  It is not normally included in
   the key blob.

   Certificates and public keys are encoded as follows:

     string   certificate or public key format identifier
     byte[n]  key/certificate data

   The certificate part may have be a zero length string, but a public
   key is required.  This is the public key that will be used for
   authentication; the certificate sequence contained in the certificate
   blob can be used to provide authorization.

   Public key / certifcate formats that do not explicitly specify a
   signature format identifier MUST use the public key / certificate
   format identifier as the signature identifier.

   Signatures are encoded as follows:
     string    signature format identifier (as specified by the
               public key / cert format)
     byte[n]   signature blob in format specific encoding.

   The "ssh-dss" key format has the following specific encoding:

     string    "ssh-dss"
     mpint     p
     mpint     q
     mpint     g
     mpint     y

Ylonen, et. al.          Expires August 29, 2002               [Page 11]

Internet-Draft        SSH Transport Layer Protocol         February 2002

   Here the p, q, g, and y parameters form the signature key blob.

   Signing and verifying using this key format is done according to the
   Digital Signature Standard [FIPS-186] using the SHA-1 hash.  A
   description can also be found in [SCHNEIER].

   The resulting signature is encoded as follows:

     string    "ssh-dss"
     string    dss_signature_blob

   dss_signature_blob is encoded as a string containing r followed by s
   (which are 160 bits long integers, without lengths or padding,
   unsigned and in network byte order).

   The "ssh-rsa" key format has the following specific encoding:

     string    "ssh-rsa"
     mpint     e
     mpint     n

   Here the e and n parameters form the signature key blob.

   Signing and verifying using this key format is done according to
   [SCHNEIER] and [PKCS1] using the SHA-1 hash.

   The resulting signature is encoded as follows:

     string    "ssh-rsa"
     string    rsa_signature_blob

   rsa_signature_blob is encoded as a string containing s (which is an
   integer, without lengths or padding, unsigned and in network byte
   order).

   The "spki-sign-rsa" method indicates that the certificate blob
   contains a sequence of SPKI certificates.  The format of SPKI
   certificates is described in [RFC2693].  This method indicates that
   the key (or one of the keys in the certificate) is an RSA-key.

   The "spki-sign-dss".  As above, but indicates that the key (or one of
   the keys in the certificate) is a DSS-key.

   The "pgp-sign-rsa" method indicates the certificates, the public key,
   and the signature are in OpenPGP compatible binary format
   ([RFC2440]).  This method indicates that the key is an RSA-key.

   The "pgp-sign-dss".  As above, but indicates that the key is a DSS-

Ylonen, et. al.          Expires August 29, 2002               [Page 12]

Internet-Draft        SSH Transport Layer Protocol         February 2002

   key.

5. Key Exchange

   Key exchange begins by each side sending lists of supported
   algorithms.  Each side has a preferred algorithm in each category,
   and it is assumed that most implementations at any given time will
   use the same preferred algorithm.  Each side MAY guess which
   algorithm the other side is using, and MAY send an initial key
   exchange packet according to the algorithm if appropriate for the
   preferred method.

   Guess is considered wrong, if:
   o  the kex algorithm and/or the host key algorithm is guessed wrong
      (server and client have different preferred algorithm), or
   o  if any of the other algorithms cannot be agreed upon (the
      procedure is defined below in Section Section 5.1).

   Otherwise, the guess is considered to be right and the optimistically
   sent packet MUST be handled as the first key exchange packet.

   However, if the guess was wrong, and a packet was optimistically sent
   by one or both parties, such packets MUST be ignored (even if the
   error in the guess would not affect the contents of the initial
   packet(s)), and the appropriate side MUST send the correct initial
   packet.

   Server authentication in the key exchange MAY be implicit.  After a
   key exchange with implicit server authentication, the client MUST
   wait for response to its service request message before sending any
   further data.

5.1 Algorithm Negotiation

   Key exchange begins by each side sending the following packet:

     byte      SSH_MSG_KEXINIT
     byte[16]  cookie (random bytes)
     string    kex_algorithms
     string    server_host_key_algorithms
     string    encryption_algorithms_client_to_server
     string    encryption_algorithms_server_to_client
     string    mac_algorithms_client_to_server
     string    mac_algorithms_server_to_client
     string    compression_algorithms_client_to_server
     string    compression_algorithms_server_to_client
     string    languages_client_to_server
     string    languages_server_to_client

Ylonen, et. al.          Expires August 29, 2002               [Page 13]

Internet-Draft        SSH Transport Layer Protocol         February 2002

     boolean   first_kex_packet_follows
     uint32    0 (reserved for future extension)

   Each of the algorithm strings MUST be a comma-separated list of
   algorithm names (see ''Algorithm Naming'' in [SSH-ARCH]).  Each
   supported (allowed) algorithm MUST be listed in order of preference.

   The first algorithm in each list MUST be the preferred (guessed)
   algorithm.  Each string MUST contain at least one algorithm name.

      cookie
         The cookie MUST be a random value generated by the sender.  Its
         purpose is to make it impossible for either side to fully
         determine the keys and the session identifier.

      kex_algorithms
         Key exchange algorithms were defined above.  The first
         algorithm MUST be the preferred (and guessed) algorithm.  If
         both sides make the same guess, that algorithm MUST be used.
         Otherwise, the following algorithm MUST be used to choose a key
         exchange method: iterate over client's kex algorithms, one at a
         time.  Choose the first algorithm that satisfies the following
         conditions:
         +  the server also supports the algorithm,
         +  if the algorithm requires an encryption-capable host key,
            there is an encryption-capable algorithm on the server's
            server_host_key_algorithms that is also supported by the
            client, and
         +  if the algorithm requires a signature-capable host key,
            there is a signature-capable algorithm on the server's
            server_host_key_algorithms that is also supported by the
            client.
         +  If no algorithm satisfying all these conditions can be
            found, the connection fails, and both sides MUST disconnect.

      server_host_key_algorithms
         List of the algorithms supported for the server host key.  The
         server lists the algorithms for which it has host keys; the
         client lists the algorithms that it is willing to accept.
         (There MAY be multiple host keys for a host, possibly with
         different algorithms.)

         Some host keys may not support both signatures and encryption
         (this can be determined from the algorithm), and thus not all
         host keys are valid for all key exchange methods.

         Algorithm selection depends on whether the chosen key exchange

Ylonen, et. al.          Expires August 29, 2002               [Page 14]

Internet-Draft        SSH Transport Layer Protocol         February 2002

         algorithm requires a signature or encryption capable host key.
         It MUST be possible to determine this from the public key
         algorithm name.  The first algorithm on the client's list that
         satisfies the requirements and is also supported by the server
         MUST be chosen.  If there is no such algorithm, both sides MUST
         disconnect.

      encryption_algorithms
         Lists the acceptable symmetric encryption algorithms in order
         of preference.  The chosen encryption algorithm to each
         direction MUST be the first algorithm  on the client's list
         that is also on the server's list.  If there is no such
         algorithm, both sides MUST disconnect.

         Note that "none" must be explicitly listed if it is to be
         acceptable.  The defined algorithm names are listed in Section
         Section 4.3.

      mac_algorithms
         Lists the acceptable MAC algorithms in order of preference.
         The chosen MAC algorithm MUST be the first algorithm on the
         client's list that is also on the server's list.  If there is
         no such algorithm, both sides MUST disconnect.

         Note that "none" must be explicitly listed if it is to be
         acceptable.  The MAC algorithm names are listed in Section
         Figure 1.

      compression_algorithms
         Lists the acceptable compression algorithms in order of
         preference.  The chosen compression algorithm MUST be the first
         algorithm on the client's list that is also on the server's
         list.  If there is no such algorithm, both sides MUST
         disconnect.

         Note that "none" must be explicitly listed if it is to be
         acceptable.  The compression algorithm names are listed in
         Section Section 4.2.

      languages
         This is a comma-separated list of language tags in order of
         preference [RFC1766].  Both parties MAY ignore this list.  If
         there are no language preferences, this list SHOULD be empty.

      first_kex_packet_follows
         Indicates whether a guessed key exchange packet follows.  If a
         guessed packet will be sent, this MUST be TRUE.  If no guessed
         packet will be sent, this MUST be FALSE.

Ylonen, et. al.          Expires August 29, 2002               [Page 15]


         After receiving the SSH_MSG_KEXINIT packet from the other side,
         each party will know whether their guess was right.  If the
         other party's guess was wrong, and this field was TRUE, the
         next packet MUST be silently ignored, and both sides MUST then
         act as determined by the negotiated key exchange method.  If
         the guess was right, key exchange MUST continue using the
         guessed packet.

   After the KEXINIT packet exchange, the key exchange algorithm is run.
   It may involve several packet exchanges, as specified by the key
   exchange method.

5.2 Output from Key Exchange

   The key exchange produces two values: a shared secret K, and an
   exchange hash H.  Encryption and authentication keys are derived from
   these.  The exchange hash H from the first key exchange is
   additionally used as the session identifier, which is a unique
   identifier for this connection.  It is used by authentication methods
   as a part of the data that is signed as a proof of possession of a
   private key.  Once computed, the session identifier is not changed,
   even if keys are later re-exchanged.

   Each key exchange method specifies a hash function that is used in
   the key exchange.  The same hash algorithm MUST be used in key
   derivation.  Here, we'll call it HASH.

   Encryption keys MUST be computed as HASH of a known value and K as
   follows:
   o  Initial IV client to server: HASH(K || H || "A" || session_id)
      (Here K is encoded as mpint and "A" as byte and session_id as raw
      data."A" means the single character A, ASCII 65).
   o  Initial IV server to client: HASH(K || H || "B" || session_id)
   o  Encryption key client to server: HASH(K || H || "C" || session_id)
   o  Encryption key server to client: HASH(K || H || "D" || session_id)
   o  Integrity key client to server: HASH(K || H || "E" || session_id)
   o  Integrity key server to client: HASH(K || H || "F" || session_id)

   Key data MUST be taken from the beginning of the hash output.  128
   bits (16 bytes) SHOULD be used for algorithms with variable-length
   keys.  For other algorithms, as many bytes as are needed are taken
   from the beginning of the hash value.  If the key length in longer
   than the output of the HASH, the key is extended by computing HASH of
   the concatenation of K and H and the entire key so far, and appending
   the resulting bytes (as many as HASH generates) to the key.  This
   process is repeated until enough key material is available; the key
   is taken from the beginning of this value.  In other words:

Ylonen, et. al.          Expires August 29, 2002               [Page 16]

Internet-Draft        SSH Transport Layer Protocol         February 2002

     K1 = HASH(K || H || X || session_id)   (X is e.g. "A")
     K2 = HASH(K || H || K1)
     K3 = HASH(K || H || K1 || K2)
     ...
     key = K1 || K2 || K3 || ...

   This process will lose entropy if the amount of entropy in K is
   larger than the internal state size of HASH.

5.3 Taking Keys Into Use

   Key exchange ends by each side sending an SSH_MSG_NEWKEYS message.
   This message is sent with the old keys and algorithms.  All messages
   sent after this message MUST use the new keys and algorithms.

   When this message is received, the new keys and algorithms MUST be
   taken into use for receiving.

   This message is the only valid message after key exchange, in
   addition to SSH_MSG_DEBUG, SSH_MSG_DISCONNECT and SSH_MSG_IGNORE
   messages.  The purpose of this message is to ensure that a party is
   able to respond with a disconnect message that the other party can
   understand if something goes wrong with the key exchange.
   Implementations MUST NOT accept any other messages after key exchange
   before receiving SSH_MSG_NEWKEYS.

     byte      SSH_MSG_NEWKEYS

6. Diffie-Hellman Key Exchange

   The Diffie-Hellman key exchange provides a shared secret that can not
   be determined by either party alone.  The key exchange is combined
   with a signature with the host key to provide host authentication.

   In the following description (C is the client, S is the server; p is
   a large safe prime, g is a generator for a subgroup of GF(p), and q
   is the order of the subgroup; V_S is S's version string; V_C is C's
   version string; K_S is S's public host key; I_C is C's KEXINIT
   message and I_S S's KEXINIT message which have been exchanged before
   this part begins):

   1.  C generates a random number x (1 < x < q) and computes e = g^x
       mod p.  C sends "e" to S.

Ylonen, et. al.          Expires August 29, 2002               [Page 17]


   2.  S generates a random number y (0 < y < q) and computes f = g^y
       mod p.  S receives "e".  It computes K = e^y mod p, H = hash(V_C
       || V_S || I_C || I_S || K_S || e || f || K) (these elements are
       encoded according to their types; see below), and signature s on
       H with its private host key.  S sends "K_S || f || s" to C.  The
       signing operation may involve a second hashing operation.

   3.  C verifies that K_S really is the host key for S (e.g.  using
       certificates or a local database).  C is also allowed to accept
       the key without verification; however, doing so will render the
       protocol insecure against active attacks (but may be desirable
       for practical reasons in the short term in many environments).  C
       then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S ||
       K_S || e || f || K), and verifies the signature s on H.

   Either side MUST NOT send or accept e or f values that are not in the
   range [1, p-1].  If this condition is violated, the key exchange
   fails.

   This is implemented with the following messages.  The hash algorithm
   for computing the exchange hash is defined by the method name, and is
   called HASH.  The public key algorithm for signing is negotiated with
   the KEXINIT messages.

   First, the client sends the following:

     byte      SSH_MSG_KEXDH_INIT
     mpint     e

   The server responds with the following:

     byte      SSH_MSG_KEXDH_REPLY
     string    server public host key and certificates (K_S)
     mpint     f
     string    signature of H

   The hash H is computed as the HASH hash of the concatenation of the
   following:

     string    V_C, the client's version string (CR and NL excluded)
     string    V_S, the server's version string (CR and NL excluded)
     string    I_C, the payload of the client's SSH_MSG_KEXINIT
     string    I_S, the payload of the server's SSH_MSG_KEXINIT
     string    K_S, the host key
     mpint     e, exchange value sent by the client
     mpint     f, exchange value sent by the server
     mpint     K, the shared secret

Ylonen, et. al.          Expires August 29, 2002               [Page 18]

Internet-Draft        SSH Transport Layer Protocol         February 2002

   This value is called the exchange hash, and it is used to
   authenticate the key exchange.  The exchange hash SHOULD be kept
   secret.

   The signature algorithm MUST be applied over H, not the original
   data.  Most signature algorithms include hashing and additional
   padding.  For example, "ssh-dss" specifies SHA-1 hashing; in that
   case, the data is first hashed with HASH to compute H, and H is then
   hashed with SHA-1 as part of the signing operation.

6.1 diffie-hellman-group1-sha1

   The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key
   exchange with SHA-1 as HASH, and the following group:

   The prime p is equal to 2^1024 - 2^960 - 1 + 2^64 * floor( 2^894 Pi +
   129093 ).  Its hexadecimal value is:

         FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
         29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
         EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
         E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
         EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
         FFFFFFFF FFFFFFFF.

   In decimal, this value is:

         179769313486231590770839156793787453197860296048756011706444
         423684197180216158519368947833795864925541502180565485980503
         646440548199239100050792877003355816639229553136239076508735
         759914822574862575007425302077447712589550957937778424442426
         617334727629299387668709205606050270810842907692932019128194
         467627007.

   The generator used with this prime is g = 2.  The group order q is (p
   - 1) / 2.

   This group was taken from the ISAKMP/Oakley specification, and was
   originally generated by Richard Schroeppel at the University of
   Arizona.  Properties of this prime are described in [Orm96].

7. Key Re-Exchange

   Key re-exchange is started by sending an SSH_MSG_KEXINIT packet when
   not already doing a key exchange (as described in Section Section
   5.1).  When this message is received, a party MUST respond with its
   own SSH_MSG_KEXINIT message except when the received SSH_MSG_KEXINIT

Ylonen, et. al.          Expires August 29, 2002               [Page 19]

Internet-Draft        SSH Transport Layer Protocol         February 2002

   already was a reply.  Either party MAY initiate the re-exchange, but
   roles MUST NOT be changed (i.e., the server remains the server, and
   the client remains the client).

   Key re-exchange is performed using whatever encryption was in effect
   when the exchange was started.  Encryption, compression, and MAC
   methods are not changed before a new SSH_MSG_NEWKEYS is sent after
   the key exchange (as in the initial key exchange).  Re-exchange is
   processed identically to the initial key exchange, except for the
   session identifier that will remain unchanged.  It is permissible to
   change some or all of the algorithms during the re-exchange.  Host
   keys can also change.  All keys and initialization vectors are
   recomputed after the exchange.  Compression and encryption contexts
   are reset.

   It is recommended that the keys are changed after each gigabyte of
   transmitted data or after each hour of connection time, whichever
   comes sooner.  However, since the re-exchange is a public key
   operation, it requires a fair amount of processing power and should
   not be performed too often.

   More application data may be sent after the SSH_MSG_NEWKEYS packet
   has been sent; key exchange does not affect the protocols that lie
   above the SSH transport layer.

8. Service Request

   After the key exchange, the client requests a service.  The service
   is identified by a name.  The format of names and procedures for
   defining new names are defined in [SSH-ARCH].

   Currently, the following names have been reserved:

     ssh-userauth
     ssh-connection

   Similar local naming policy is applied to the service names, as is
   applied to the algorithm names; a local service should use the
   "servicename@domain" syntax.

     byte      SSH_MSG_SERVICE_REQUEST
     string    service name

   If the server rejects the service request, it SHOULD send an

Ylonen, et. al.          Expires August 29, 2002               [Page 20]

Internet-Draft        SSH Transport Layer Protocol         February 2002

   appropriate SSH_MSG_DISCONNECT message and MUST disconnect.

   When the service starts, it may have access to the session identifier
   generated during the key exchange.

   If the server supports the service (and permits the client to use
   it), it MUST respond with the following:

     byte      SSH_MSG_SERVICE_ACCEPT
     string    service name

   Message numbers used by services should be in the area reserved for
   them (see Section 6 in [SSH-ARCH]).  The transport level will
   continue to process its own messages.

   Note that after a key exchange with implicit server authentication,
   the client MUST wait for response to its service request message
   before sending any further data.

9. Additional Messages

   Either party may send any of the following messages at any time.

9.1 Disconnection Message

     byte      SSH_MSG_DISCONNECT
     uint32    reason code
     string    description [RFC2279]
     string    language tag [RFC1766]

   This message causes immediate termination of the connection.  All
   implementations MUST be able to process this message; they SHOULD be
   able to send this message.

   The sender MUST NOT send or receive any data after this message, and
   the recipient MUST NOT accept any data after receiving this message.
   The description field gives a more specific explanation in a human-
   readable form.  The error code gives the reason in a more machine-
   readable format (suitable for localization), and can have the
   following values:

     #define SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT      1
     #define SSH_DISCONNECT_PROTOCOL_ERROR                   2
     #define SSH_DISCONNECT_KEY_EXCHANGE_FAILED              3
     #define SSH_DISCONNECT_RESERVED                         4

Ylonen, et. al.          Expires August 29, 2002               [Page 21]

Internet-Draft        SSH Transport Layer Protocol         February 2002

     #define SSH_DISCONNECT_MAC_ERROR                        5
     #define SSH_DISCONNECT_COMPRESSION_ERROR                6
     #define SSH_DISCONNECT_SERVICE_NOT_AVAILABLE            7
     #define SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED   8
     #define SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE          9
     #define SSH_DISCONNECT_CONNECTION_LOST                 10
     #define SSH_DISCONNECT_BY_APPLICATION                  11
     #define SSH_DISCONNECT_TOO_MANY_CONNECTIONS            12
     #define SSH_DISCONNECT_AUTH_CANCELLED_BY_USER          13
     #define SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE  14
     #define SSH_DISCONNECT_ILLEGAL_USER_NAME               15

   If the description string is displayed, control character filtering
   discussed in [SSH-ARCH] should be used to avoid attacks by sending
   terminal control characters.

9.2 Ignored Data Message

     byte      SSH_MSG_IGNORE
     string    data

   All implementations MUST understand (and ignore) this message at any
   time (after receiving the protocol version).  No implementation is
   required to send them.  This message can be used as an additional
   protection measure against advanced traffic analysis techniques.

9.3 Debug Message

     byte      SSH_MSG_DEBUG
     boolean   always_display
     string    message [RFC2279]
     string    language tag [RFC1766]

   All implementations MUST understand this message, but they are
   allowed to ignore it.  This message is used to pass the other side
   information that may help debugging.  If always_display is TRUE, the
   message SHOULD be displayed.  Otherwise, it SHOULD NOT be displayed
   unless debugging information has been explicitly requested by the
   user.

   The message doesn't need to contain a newline.  It is, however,
   allowed to consist of multiple lines separated by CRLF (Carriage
   Return - Line Feed) pairs.

   If the message string is displayed, terminal control character
   filtering discussed in [SSH-ARCH] should be used to avoid attacks by

Ylonen, et. al.          Expires August 29, 2002               [Page 22]

Internet-Draft        SSH Transport Layer Protocol         February 2002

   sending terminal control characters.

9.4 Reserved Messages

   An implementation MUST respond to all unrecognized messages with an
   SSH_MSG_UNIMPLEMENTED message in the order in which the messages were
   received.  Such messages MUST be otherwise ignored.  Later protocol
   versions may define other meanings for these message types.

     byte      SSH_MSG_UNIMPLEMENTED
     uint32    packet sequence number of rejected message

10. Summary of Message Numbers

   The following message numbers have been defined in this protocol:

     #define SSH_MSG_DISCONNECT             1
     #define SSH_MSG_IGNORE                 2
     #define SSH_MSG_UNIMPLEMENTED          3
     #define SSH_MSG_DEBUG                  4
     #define SSH_MSG_SERVICE_REQUEST        5
     #define SSH_MSG_SERVICE_ACCEPT         6

     #define SSH_MSG_KEXINIT                20
     #define SSH_MSG_NEWKEYS                21

     /* Numbers 30-49 used for kex packets.
        Different kex methods may reuse message numbers in
        this range. */

     #define SSH_MSG_KEXDH_INIT             30
     #define SSH_MSG_KEXDH_REPLY            31

11. Security Considerations

   This protocol provides a secure encrypted channel over an insecure
   network.  It performs server host authentication, key exchange,
   encryption, and integrity protection.  It also derives a unique
   session id that may be used by higher-level protocols.

   It is expected that this protocol will sometimes be used without
   insisting on reliable association between the server host key and the
   server host name.  Such use is inherently insecure, but may be
   necessary in non-security critical environments, and still provides
   protection against passive attacks.  However, implementors of

Ylonen, et. al.          Expires August 29, 2002               [Page 23]

Internet-Draft        SSH Transport Layer Protocol         February 2002

   protocols running on top of this protocol should keep this
   possibility in mind.

   This protocol is designed to be used over a reliable transport.  If
   transmission errors or message manipulation occur, the connection is
   closed.  The connection SHOULD be re-established if this occurs.
   Denial of service attacks of this type ("wire cutter") are almost
   impossible to avoid.

   The protocol was not designed to eliminate covert channels.  For
   example, the padding, SSH_MSG_IGNORE messages, and several other
   places in the protocol can be used to pass covert information, and
   the recipient has no reliable way to verify whether such information
   is being sent.

12. Trademark Issues

   As of this writing, SSH Communications Security Oy claims ssh as its
   trademark.  As with all IPR claims the IETF takes no position
   regarding the validity or scope of this trademark claim.

13. Additional Information

   The current document editor is: [email-masked].  Comments on
   this internet draft should be sent to the IETF SECSH working group,
   details at: http://ietf.org/html.charters/secsh-charter.html

References

   [FIPS-186]      Federal Information Processing Standards Publication,
                   ., "FIPS PUB 186, Digital Signature Standard", May
                   1994.

   [Orm96]         Orman, H., "The Okaley Key Determination Protcol
                   version1, TR97-92", 1996.

   [RFC2459]       Housley, R., Ford, W., Polk, W. and D. Solo,
                   "Internet X.509 Public Key Infrastructure Certificate
                   and CRL Profile", RFC 2459, January 1999.

   [RFC1034]       Mockapetris, P., "Domain names - concepts and
                   facilities", STD 13, RFC 1034, Nov 1987.

   [RFC1766]       Alvestrand, H., "Tags for the Identification of
                   Languages", RFC 1766, March 1995.

Ylonen, et. al.          Expires August 29, 2002               [Page 24]

Internet-Draft        SSH Transport Layer Protocol         February 2002

   [RFC1950]       Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
                   Format Specification version 3.3", RFC 1950, May
                   1996.

   [RFC1951]       Deutsch, P., "DEFLATE Compressed Data Format
                   Specification version 1.3", RFC 1951, May 1996.

   [RFC2279]       Yergeau, F., "UTF-8, a transformation format of ISO
                   10646", RFC 2279, January 1998.

   [RFC2104]       Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
                   Keyed-Hashing for Message Authentication", RFC 2104,
                   February 1997.

   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2144]       Adams, C., "The CAST-128 Encryption Algorithm", RFC
                   2144, May 1997.

   [RFC2440]       Callas, J., Donnerhacke, L., Finney, H. and R.
                   Thayer, "OpenPGP Message Format", RFC 2440, November
                   1998.

   [RFC2693]       Ellison, C., Frantz, B., Lampson, B., Rivest, R.,
                   Thomas, B. and T. Ylonen, "SPKI Certificate Theory",
                   RFC 2693, September 1999.

   [SCHNEIER]      Schneier, B., "Applied Cryptography Second Edition:
                   protocols algorithms and source in code in C", 1996.

   [TWOFISH]       Schneier, B., "The Twofish Encryptions Algorithm: A
                   128-Bit Block Cipher, 1st Edition", March 1999.

   [SSH-ARCH]      Ylonen, T., "SSH Protocol Architecture", I-D draft-
                   ietf-architecture-12.txt, July 2001.

   [SSH-TRANS]     Ylonen, T., "SSH Transport Layer Protocol", I-D
                   draft-ietf-transport-13.txt, July 2001.

   [SSH-USERAUTH]  Ylonen, T., "SSH Authentication Protocol", I-D draft-
                   ietf-userauth-15.txt, July 2001.

   [SSH-CONNECT]   Ylonen, T., "SSH Connection Protocol", I-D draft-
                   ietf-connect-15.txt, July 2001.

Ylonen, et. al.          Expires August 29, 2002               [Page 25]

Internet-Draft        SSH Transport Layer Protocol         February 2002

Authors' Addresses

   Tatu Ylonen
   SSH Communications Security Corp
   Fredrikinkatu 42
   HELSINKI  FIN-00100
   Finland

   EMail: [email-masked]

   Tero Kivinen
   SSH Communications Security Corp
   Fredrikinkatu 42
   HELSINKI  FIN-00100
   Finland

   EMail: [email-masked]

   Markku-Juhani O. Saarinen
   University of Jyvaskyla

   Timo J. Rinne
   SSH Communications Security Corp
   Fredrikinkatu 42
   HELSINKI  FIN-00100
   Finland

   EMail: [email-masked]

   Sami Lehtinen
   SSH Communications Security Corp
   Fredrikinkatu 42
   HELSINKI  FIN-00100
   Finland

   EMail: [email-masked]

Ylonen, et. al.          Expires August 29, 2002               [Page 26]

Internet-Draft        SSH Transport Layer Protocol         February 2002

Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   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 implementation 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Ylonen, et. al.          Expires August 29, 2002               [Page 27]

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 01 Mar 2002 15:37:53 -0500

> queue to come out by March 11th.

Ouch.

Because of the publication delay, and because we've been stuck in last
call mode for a while, I'm going to attempt to accelerate things
somewhat...

A Working Group Last Call begins today and will end on 3/12/02 for
the following four drafts:

	draft-ietf-secsh-architecture-12.txt 
	draft-ietf-secsh-connect-15.txt
	draft-ietf-secsh-transport-13.txt (as mailed to ietf-secsh yesterday)
	draft-ietf-secsh-userauth-15.txt (as mailed to ietf-secsh yesterday)

I believe that these documents likely the current consensus of the
working group and should be submitted to the IESG for consideration
for publication as Proposed Standards.

Comments regarding the content of these documents should be sent to
the working group mailing list, <[email-masked]>.  If you believe
a change to a document is necessary, please include revised wording
along with your comment.

This Last Call period extends until March 12th, 2002, or one day after
the announcement of the latter two drafts, whichever comes later.  (If
the drafts which are eventually released differ in any substantial way
from what Darren released, I will extend the last call).

						- Bill

---

From: Wei Dai <[email-masked]>
Date: Fri, 1 Mar 2002 13:59:47 -0800

It looks like the transport draft still does not deal with the attack I
pointed out a few weeks ago. To fix this, I suggest that the following
text be added to section 4.3:

(begin quote)

     aes256-ctr       OPTIONAL          AES (Rijndael) in CTR mode,   
                                        with 256-bit key
     aes192-ctr       OPTIONAL          AES with 192-bit key
     aes128-ctr       RECOMMENDED       AES with 128-bit key

[and similarly for all other block ciphers]

   The "aes256-ctr" cipher is AES (Advanced Encryption Standard),       
   formerly Rijndael, in CTR mode.  This version uses 256-bit key.

   The "aes192-ctr" cipher.  Same as above but with 192-bit key.      

   The "aes128-ctr" cipher.  Same as above but with 128-bit key.      

For any cipher in CTR mode, the counter used to encrypt each plaintext
block MUST be the IV if no previous plaintext block exists, or C+1 mod 2^N
where C is the counter used to encrypt the previous block, and N is the
block size of the cipher in bits.  Network order SHOULD be used to convert
the counter between its octet string form and its integer form for the
computation of C+1 mod 2^N. 

(end quote)

And that the following text be added to the security discussions section:

(begin quote)

The protocol may be susceptible to chosen plaintext attacks if a CBC-mode
cipher is used. It is RECOMMENDED that CBC-mode ciphers be avoided if the
protocol is used in a way that allows an attacker to control part or all
of the first N bits of the plaintext of each packet, where N is the cipher
block size.

(end quote)

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 01 Mar 2002 17:28:08 -0500

I think it's too soon to make a document change because of this --
most importantly, I don't think that enough Real Cryptographers(tm)
have looked at either the problem or the proposed fix to conclude that
a change along the lines of your suggested fix is better than leaving
the document alone.

The use of ciphers in counter mode is also very new, and, as with all
stream ciphers, there are some definite subtleties to their use; who's
to say that crypto researchers won't find a problem with counter modes
which are just as bad as the CBC problem (i.e., a purely theoretical
vulnerability except in a few corner cases).

new ciphers can follow later once there's clear consensus on a
solution.

					- Bill

---

From: Wei Dai <[email-masked]>
Date: Fri, 1 Mar 2002 16:06:30 -0800

> a change along the lines of your suggested fix is better than leaving

I agree, there needs to be more review of the problem and the proposed
solution. Cryptography researchers may think the problem is too trivial
and uninteresting to look on their own initiative, so I suggest that
everyone who has a stake in this ask their favorite cryptographers to to
take a look. 

> vulnerability except in a few corner cases).

I think the cryptographic research community now understand cipher modes
and their security properties much better than they used to. The CBC mode
problem has been known for quite a while in the research community (but
apparently the knowledge has not been passed widely outside of it). CTR
mode is perhaps the best understood mode because of its simplicity, and I
believe it does not have any known problems when used in the way I
suggest.

I would say that a vulnerability is theoretical if there is no possibility
that it can be exploited in the real world. That is clearly not the case
here.

> new ciphers can follow later once there's clear consensus on a

I don't understand why we would want to standardize on a weak protocol. If
there is no consensus on a solution, wouldn't it be better to wait until
there is one?

---

From: Markus Friedl <[email-masked]>
Date: Sat, 2 Mar 2002 01:11:00 +0100

> there is no consensus on a solution, wouldn't it be better to wait until

then why use CTR and not OFB or CFB?

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 01 Mar 2002 19:12:43 -0500

> there is no consensus on a solution, wouldn't it be better to wait until

ssh is (much) more than just the encryption; the encryption part is
just one detail of the protocol, and it's a modularly replaceable
part.

					- Bill

---

From: Wei Dai <[email-masked]>
Date: Fri, 1 Mar 2002 16:31:53 -0800

> then why use CTR and not OFB or CFB?

http://saturn.tcs.hut.fi/~helger/papers/lrw00/html/ gives a good summary
of the advantages of CTR. Here are the ones that apply to SSH:

Software efficiency. Modern processors support some or all of the
following architectural features: aggressive pipelining, multiple
instruction dispatch per clock cycle, a large number of registers, and
SIMD instructions. By eliminating the computational dependency between Ci
and Cj, CTR-mode encryption enables effective utilization of the above
features. For many ciphers, a well-optimized implementation of CTR-mode
encryption on a processor such as an Pentium III, Itanium, Alpha, or a
Motorola AltiVec, may be substantially faster (even more than four times
[8]) than a well-optimized implementation of CBC-mode encryption. This is
greater than the gain obtained from switching from the slowest to the
fastest AES finalist on most platforms [7]. 

Hardware efficiency. Modes such as CBC encryption are limited in their
hardware speed by the maximal rate at which the underlying block cipher
can be computed. This is because one must complete the computation of
ciphertext Ci before one can begin to compute Ci + 1. Thus the maximal
throughput, in hardware, will be about the reciprocal of the latency for
E. In contrast, CTR model is fully parallelizable: one can be computing
blocks C1, C2,... all at the same time, limited only by the amount of
hardware that one throws at the problem. This has been shown to result in
30...100 times speedups for four of the AES finalists [6]. 

Preprocessing. Because the cryptographic work in enciphering a message M
is independent of M, preprocessing can be used, in some environments, to
increase speed. That is, one can compute the pad in ``spare cycles,'' even
before one knows the plaintext M. When M is known, it is XORed with the
already-computed pad. The latter can be done with throughput 10-25 Gbit/s
on a contemporary processor. 

Provable security. The above efficiency characteristics are not obtained
at the expense of security. In fact, the ``standard'' cryptographic
assumption about a block cipher's security--that it is a ``pseudorandom
permutation'' [9,4]--is enough to prove the security of CTR-mode
encryption. See [2], which shows that the concrete security bounds one
gets for CTR-mode encryption, using a block cipher, are no worse than what
one gets for CBC encryption. (Indeed there are approaches to get better
security bounds with CTR-mode encryption than with CBC mode, though these
do not directly use the block cipher E). See [4,3].) The security of CTR
mode is well-analyzed and well-understood.

---

From: Wei Dai <[email-masked]>
Date: Fri, 1 Mar 2002 16:58:51 -0800

> just one detail of the protocol, and it's a modularly replaceable

I think the encryption is much more than a detail. It's one of the two
most important services that ssh provides (the other one being the
authentication).

Sure ssh also does shells and file transfers and so on, but everyone would
still be using rcp and rsh if it weren't for the encryption and
authentication that ssh provides.

Even if we decide not to put in the proposed fix, we need to at least
mention the attack in the security considerations section. I don't see how
it could be completely ignored.

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 1 Mar 2002 20:06:30 -0500

On Friday, March 1, 2002, at 07:06 , Wei Dai wrote:
> I don't understand why we would want to standardize
> on a weak protocol. If there is no consensus on a solution,
> wouldn't it be better to wait until there is one?

There is clear consensus that SSHv2 in its current form requires
a lot more work for an adversary than the other available
alternatives.  The goal here is practical risk reduction,
not perfect security.  So we take what is practical to get
today (i.e. the current spec) and we can always update it
with additional new algorithsm later (if those algorithms
still look interesting after adequate Real Cryptographer(tm)
peer review).

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 1 Mar 2002 20:07:57 -0500

On Friday, March 1, 2002, at 07:31 , Wei Dai wrote:
> The security of CTR mode is well-analyzed and well-understood.

The Real Cryptographers (tm) that I talk with would
strongly dispute that assertion, though (fortunately)
they have better diplomatic skills than I do.

Ran

---

From: Markus Friedl <[email-masked]>
Date: Sat, 2 Mar 2002 19:01:04 +0100

> just one detail of the protocol, and it's a modularly replaceable

I agree with Bill:  The protocol is much more than CBC-encryption,
and it's so easy to switch ciphers.  The group really should move
on.

---

From: "Joseph Galbraith" <[email-masked]>
Date: Sat, 2 Mar 2002 11:50:54 -0800

> and it's so easy to switch ciphers.  The group really should move

I too agree.  Ciphers are easy to add.
The core drafts clearly define how to
specify additional ciphers independantly,
for exactly this purpose.

In fact, I would say that if people feel
strongly, it would not be too early to
start a document describing the proposed
new ciphers.

Such a document would naturally proceed
independantly from the core drafts.

But, in the event that all the Real
Cryptographers (TM) all of a sudden
said "Oh my gosh!  This is horrible!
Don't use CBC for anything!" we would
have something we'd actually been working
on, and ironing out the wording, clarity,
etc.

And, indeed, it wouldn't be a bad idea to have
some ciphers specified that didn't use CBC,
even without this specific attack, on the
principle that we don't want all our eggs
in one basket.

- Joseph

---

From: "Andersson, Mats" <[email-masked]>
Date: Sun, 3 Mar 2002 08:06:26 +0100 (CET)

> 	draft-ietf-secsh-transport-13.txt (as mailed to ietf-secsh yesterday)

As I (and others) have noted in previous mails:

In:
   key is required.
...

Delete this sentence, it doesn't carry any information IMHO, it's only
confusing things which are otherwise mostly clear.

Same paragraph:
...
   This is the public key that will be used for authentication; the
   certificate sequence contained in the certificate blob can be used to
   provide authorization.
...

Suggested rephrase:
...
   This is the public key that will be used for authentication. Whether
   it is a plain public key or certificate (or certificate chain) is
   implicit from the format used. A certificate chain is the binary
   concatenation (i.e. of byte[n] blobs) of certificates
   necessary for authentication as defined by the format used.
...

(note: if we don't explicitly define a certificate chain here we don't
know what it is, or we'll have to drag in PKCS7 or some other means of
transport/definition of one, rfc2459 doesn't define this AFAIK).

In the references part, [PKCS1] is missing, suggested addition:
...
   [PKCS1] RSA Laboratories. PKCS #1: RSA Encryption Standard. Version
           1.5, November 1993.
...

IMHO these changes will add/delete as much information as is needed to
unambigously (hopefully...) implement this.

Cheers,

/Mats

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 05 Mar 2002 17:17:26 -0500

> unambigously (hopefully...) implement this.

So, I don't think it's necessary to make these changes at this time.

The WG has opted to split out integration of certificates with ssh
into a separate document.  When it's ready, that draft can clarify the
description of certificate handling.

If anyone disagrees *strongly* with this, speak now and explain why we
need more delay before advancing the core drafts to IETF-wide last
call.

					- Bill

---

From: Wei Dai <[email-masked]>
Date: Fri, 8 Mar 2002 21:32:53 -0800

> they have better diplomatic skills than I do.

They would, or they do (dispute that assertion)? Would they be willing to
offer this working group an explaination why? Can you tell us who these
cryptographers are, or at least what their qualifications are?