From owner-ietf-ssh@clinet.fi  Wed Mar 26 06:54:43 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id GAA06433;
	Wed, 26 Mar 1997 06:54:43 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id GAA03498;
	Wed, 26 Mar 1997 06:54:42 +0200 (EET)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id GAA08622 for ietf-ssh-outgoing; Wed, 26 Mar 1997 06:53:12 +0200 (EET)
Received: from muuri.ssh.fi (ssh.fi [194.100.44.97]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id GAA08612; Wed, 26 Mar 1997 06:53:09 +0200 (EET)
Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id GAA03494;
	Wed, 26 Mar 1997 06:53:08 +0200 (EET)
Received: (from ylo@localhost)
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) id GAA06429;
	Wed, 26 Mar 1997 06:53:08 +0200 (EET)
Date: Wed, 26 Mar 1997 06:53:08 +0200 (EET)
Message-Id: <199703260453.GAA06429@pilari.ssh.fi>
From: Tatu Ylonen <ylo@ssh.fi>
To: ietf-ssh@clinet.fi
CC: ssh@clinet.fi
Subject: draft-ietf-secsh-userauth-01.txt
Organization: SSH Communications Security, Finland
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 22274
Lines: 598

Please find below the current draft for the ssh 2.0 user
authentication protocol.  

Comments and suggestions are welcome.  Note that this should be
reviewed in combination with the transport layer protocol, as this
uses some material (e.g., session identifier) provided by the
transport layer.

    Tatu

Network Working Group                           Tatu Ylonen <ylo@ssh.fi>
INTERNET-DRAFT                               SSH Communications Security
draft-ietf-secsh-userauth-01.txt                          March 22, 1997
Expires: September 1, 1997


                      SSH Authentication Protocol

Status of This memo

This document is an Internet-Draft. 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.''

To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast),
or ftp.isi.edu (US West Coast).

Abstract

This documents describes the SSH authentication protocol.  It is used to
prove that the client is authorized access the requested service with
the supplied user name.  This authorization can be demonstrated through
possession of a password, through possession of a key, by authenticating
the client host and user, by some other method, or a combination of
these.























Tatu Ylonen <ylo@ssh.fi>                                        [page 1]

INTERNET-DRAFT                                            March 22, 1997
 
Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  User Authentication   . . . . . . . . . . . . . . . . . . . . . .  2
  2.1.  Authentication Requests   . . . . . . . . . . . . . . . . . .  3
  2.2.  Responses to Authentication Requests  . . . . . . . . . . . .  4
  2.3.  No Authentication   . . . . . . . . . . . . . . . . . . . . .  4
  2.4.  Password-Style Authentications  . . . . . . . . . . . . . . .  5
    2.4.1.  Password Authentication   . . . . . . . . . . . . . . . .  5
    2.4.2.  SecurID Authentication  . . . . . . . . . . . . . . . . .  5
  2.5.  One-Time Passwords and Similar Methods  . . . . . . . . . . .  5
    2.5.1.  S/KEY   . . . . . . . . . . . . . . . . . . . . . . . . .  6
    2.5.2.  NRL OPIE  . . . . . . . . . . . . . . . . . . . . . . . .  6
  2.6.  Other Authentication Methods  . . . . . . . . . . . . . . . .  6
    2.6.1.  Public Key Authentication   . . . . . . . . . . . . . . .  6
    2.6.2.  Host-Based Authentication   . . . . . . . . . . . . . . .  7
    2.6.3.  Kerberos Authentication   . . . . . . . . . . . . . . . .  8
3.  When Authentication Is Complete   . . . . . . . . . . . . . . . .  9
4.  Banner Message  . . . . . . . . . . . . . . . . . . . . . . . . .  9
5.  Message Numbers   . . . . . . . . . . . . . . . . . . . . . . . . 10
6.  Address of Author   . . . . . . . . . . . . . . . . . . . . . . . 10



1.  Introduction

This protocol is designed to run over the SSH transport layer protocol
using the same packet-based protocol as the transport layer.  The
service name is "ssh-userauth".

Authentication works by the client first declaring the service name and
the user name to be used to access the service.  The server then
responds with the set of authentication methods that are acceptable; the
client then sends an authentication request, and this dialog continues
until access has been granted or denied.

When this protocol starts, it receives the session identifier from the
transport layer protocol.  The session identifier uniquely identifies
this session and is suitable for signing to prove ownership of a private
key.

2.  User Authentication

Authentication is mostly client-driven.  The client sends an
authentication request, and the server responds with success or failure.
With a failure response the server informs the client which methods may
be used to continue the dialog, thus guiding the client through a
potentially complex sequence of authentications.

Authentication methods are identified by names (strings).  Some methods
are defined in the protocol; additional methods may be defined using the
syntax "name@domainname" as the method name (for example,
"footoken@footoken.com").  This ensures that private extensions can be


Tatu Ylonen <ylo@ssh.fi>                                        [page 2]

INTERNET-DRAFT                                            March 22, 1997
 
implemented without breaking compatibility and without requiring a
central registry of method names.  Method names are case-sensitive.
Names must consist of non-control characters.  Commas are not allowed in
names; at signs can only be used for the purpose described above.

The following methods are predefined:

none                 Checks if no authentication ok
password             Knowledge of password
securid              SecurID authentication
skey                 S/KEY one-time passwords
opie                 NRL OPIE one-time passwords
publickeytest        Tests whether a key is acceptable
publickey            Possession of private key
hostbased            Identity of client host and user
kerberos4            Kerberos v4 authentication
kerberos5            Kerberos v5 authentication
kerberos-afs         AFS Kerberos authentication

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 may want to limit the number of authentication attempts a
client may perform (the recommended limit is 20 attempts).

2.1.  Authentication Requests

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

            vlint32   SSH_MSG_USERAUTH_REQUEST
            string    user
            string    service
            string    method name
            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
state if they change.

If the requested service is not available, the server may disconnect
immediately or any time later.

If the requested user does not exist, the server is allowed to
disconnect, or may send a bogus list of acceptable authentications but
never accept any.  This makes it possible for the server to avoid
disclosing information about which accounts exist.

There are several authentication methods that basically work by the
client sending some kind of identifying string (or other data) to the
server, and the server directly responding with success or failure.


Tatu Ylonen <ylo@ssh.fi>                                        [page 3]

INTERNET-DRAFT                                            March 22, 1997
 
Examples of this style of authentication are "password" and "securid"
methods.  Other such methods may be defined later.

Another common form is one where the server sends a prompt (a
challenge), and the client is supposed to respond appropriately based on
the challenge.  Most one-time password methods use this form; examples
include "skey" and "opie".

While there is usually little point in clients sending 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 responds with

            vlint32   SSH_MSG_USERAUTH_FAILURE
            string    authentications_that_can_continue

authentications_that_can_continue is a comma-separated list of
authentication method names that may productively continue the
authentication dialog.  Methods that require interaction with the user
should not be listed unless they can actually be used to authenticate
this user.  Note that successful response to one method in the list may
not be enough to be accepted; the server is allowed to require multiple
authentications.  The server should not list authentications that it has
already accepted.

When the server accepts authentication, it responds with

            vlint32   SSH_MSG_USERAUTH_SUCCESS

The client may send several authentication requests without waiting for
responses from previous requests.  The server will acknowledge any
failed requests with a SSH_SMSG_AUTH_FAILURE message.  However,
SSH_SMSG_AUTH_SUCCESS is sent only once, and any further authentication
requests received after that are silently ignored.

Once SSH_MSG_USERAUTH_SUCCESS has been sent, any non-authentication
messages sent by the client will be passed to the service being run
above this authentication protocol.
2.3.  No Authentication

A client may request the list of real authentication methods that may
continue by using the "none" authentication method.  This is actually an
authentication request: if no authentication at all is needed for the


Tatu Ylonen <ylo@ssh.fi>                                        [page 4]

INTERNET-DRAFT                                            March 22, 1997
 
user, this returns SSH_MSG_USERAUTH_SUCCESS.  Otherwise, this returns
failure and with it the list of authentication methods that can
continue.

2.4.  Password-Style Authentications

All password-style authentication methods use a single message of the
following format.  The server responds with success or failure.

            vlint32   SSH_MSG_USERAUTH_REQUEST
            string    user
            string    service
            string    method name
            string    authenticating string

2.4.1.  Password Authentication

This is conventional password authentication.  The method name is
"password"; the authenticating string is the plaintext password.  Note
that the password is sent as plaintext in the packet, but the entire
packet (including the password) is encrypted by the transport layer.  It
is not possible for the client to hash the password, because it cannot
know how the server stores the password.

2.4.2.  SecurID Authentication

SecurID is a timing-based hardware token authenticator.  The user enters
a code displayed on the token as authentication.  The entered token is
passed in the following message.

The method name for SecurID authentication is "securid"; the
authenticating string is the code displayed on the hardware token.

2.5.  One-Time Passwords and Similar Methods

All one-time password authentication methods use the following message
exchange:

            vlint32   SSH_MSG_USERAUTH_REQUEST
            string    user
            string    service
            string    method name

The server responds with either SSH_MSG_USERAUTH_FAILURE or

            vlint32   SSH_MSG_USERAUTH_OTP_PROMPT
            string    prompt

The client then responds with either a new authentication request or

            vlint32   SSH_MSG_USERAUTH_OTP_RESPONSE
            string    response



Tatu Ylonen <ylo@ssh.fi>                                        [page 5]

INTERNET-DRAFT                                            March 22, 1997
 
The server responds to this message with either success or failure.

2.5.1.  S/KEY

S/KEY is an early one-time password mechanism.  The method name is
"skey".

2.5.2.  NRL OPIE

NRL OPIE is another one-time password mechanism.  The method name for it
is "opie".

2.6.  Other Authentication Methods

2.6.1.  Public Key Authentication

The possession of a private key can serve as authentication.  This
method works by sending a signature created by the private key.

Private keys are often stored encrypted at the client host, and the user
must supply a passphrase before the signature can be generated.  To
avoid needing to supply passphrases when it is not necessary, the client
can optionally query whether a particular key is acceptable as
authentication.  This done with the following message.  The key may
include certificates.

            vlint32   SSH_MSG_USERAUTH_REQUEST
            string    user
            string    service
            string    "publickeytest"
            string    public key algorithm name
            string    public key to be used for authentication

Public key algorithms are defined in the transport layer specification.
The key may include certificates.

The server will respond to this message with either
SSH_MSG_USERAUTH_FAILURE or with

            vlint32   SSH_MSG_USERAUTH_PK_OK

However, no response is sent after a successful authentication.

To do actual authentication, the client should then send a signature
generated by the public key.  It is permissible to send the signature
directly without first querying whether the key is acceptable.

            vlint32   SSH_MSG_USERAUTH_REQUEST
            string    user
            string    service
            string    "publickey"
            string    public key algorithm name
            string    public key to be used for authentication


Tatu Ylonen <ylo@ssh.fi>                                        [page 6]

INTERNET-DRAFT                                            March 22, 1997
 
            string    signature

The public key may contain certificates.

Signature  is a signature by the corresponding private key of the HASH
of the concatenation of the following, in this order:

o  the session identifier (which binds the signature to the server host
   key and the particular key exchange),

o  length of the user name as a 32-bit integer, msb first,

o  user name (without length or null characters),

o  length of the service name as a 32-bit integer, msb first,

o  service name (without length or null characters),

o  length of the public key algorithm name as a 32-bit integer, msb
   first,

o  public key algorithm name (without length or null characters),

o  length of the public key from the message as a 32-bit integer, msb
   first, and

o  the public key from the message (without length or null characters).

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

If both checks succeed, authentication may be granted (the server may
also require further authentication with other methods, without letting
the client know at this point that authentication has partially
succeeded).

2.6.2.  Host-Based Authentication

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.  The client requests this form of
authentication by sending the following message.

            vlint32   SSH_MSG_USERAUTH_REQUEST
            string    user
            string    service
            string    "hostbased"
            string    public key algorithm for host key
            string    public host key for client host
            string    client host name
            string    client user name


Tatu Ylonen <ylo@ssh.fi>                                        [page 7]

INTERNET-DRAFT                                            March 22, 1997
 
            string    signature

The public key may contain certificates.  Public key algorithm names are
defined in the transport layer protocol specification.

Signature is a signature by the host key of HASH of the concatenation of
the following, in this order:

o  the session identifier (which binds the signature to the server host
   key and the particular key exchange),

o  length of the user name as a 32-bit integer, msb first,

o  user name (without length or null characters),

o  length of the service name as a 32-bit integer, msb first,

o  service name (without length or null characters),

o  length of the public host key algorithm name as a 32-bit integer, msb
   first,

o  public host key algorithm name (without length or null characters),

o  length of the public host key from the message as a 32-bit integer,
   msb first,

o  the public host key from the message (without length or null
   characters),

o  length of the client host name as a 32-bit integer, msb first,

o  client host name (without length or null characters),

o  length of the client user name as a 32-bit integer, msb first, and

o  client user name (without length or null characters).

Authentication is accepted if the server can verify that the host key
actually belongs to the client host, the given user on that host is
allowed to log in, and the signature is a valid signature on the
appropriate value by the given host key.  (The server is also allowed to
ignore the client user name, if it only wants to authenticate the client
host.)

It is recommended that whenever possible, the server performs 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.

2.6.3.  Kerberos Authentication



Tatu Ylonen <ylo@ssh.fi>                                        [page 8]

INTERNET-DRAFT                                            March 22, 1997
 
There are several ways to authenticate the user using Kerberos (OSF DCE
and AFS are also incarnations of Kerberos).  Different versions of
Kerberos (v4, v5, DCE, and AFS) have different capabilities.  Separate
messages have been defined for each of these.  In each case, the server
should respond with success or failure.

            vlint32   SSH_MSG_USERAUTH_REQUEST
            string    user
            string    service
            string    "kerberos4"
            string    kerberos v4 credentials

            vlint32   SSH_MSG_USERAUTH_REQUEST
            string    user
            string    service
            string    "kerberos5"
            string    kerberos v5 credentials
            string    kerberos v5 ticket granting ticket (may be empty)

            vlint32   SSH_MSG_USERAUTH_REQUEST
            string    user
            string    service
            string    "kerberos-afs"
            string    AFS token

The Kerberos authentication requests should be sent before other
authentication requests.  The other authentication methods may need to
access files from the user's home directory, which may not be accessible
until e.g. the AFS token has been passed.  Note that even if these
requests fail, they may have side effects, such as making the home
directory accessible.

3.  When Authentication Is Complete

Authentication is complete when the server has responded with
SSH_MSG_USERAUTH_SUCCESS.  Any SSH_MSG_USERAUTH_REQUEST messages
received after sending this message will be silently ignored.

When sending SSH_MSG_USERAUTH_SUCCESS, the server also starts whatever
application was requested as the service.  Any non-authentication
messages received will be passed to the requested service.

4.  Banner Message

The server may send a SSH_MSG_USERAUTH_BANNER message at any time.  This
message contains a message to be displayed to the client user before
attempting authentication.  On most Unix machines, this message is read
from /etc/issue.  In some jurisdictions, sending a warning message
before authentication may be relevant to getting legal protection.  The
message may contain newlines.

            vlint32   SSH_MSG_USERAUTH_BANNER
            string    message


Tatu Ylonen <ylo@ssh.fi>                                        [page 9]

INTERNET-DRAFT                                            March 22, 1997
 
The client should normally display the message on screen if convenient.
However, it may be sent on every login, and opening a separate window
for it would probably be too annoying.  The client is thus free to
ignore it, but displaying it should be possible at least if explicitly
requested.

5.  Message Numbers

All message numbers used by this authencation protocol are in the range
30..39, which is part of the range reserved for protocols running on top
of the SSH transport layer protocol.  Message numbers above and
including 40 are reserved for protocols running on top of this level.
Receiving them before authentication is complete is an error, and the
server must disconnect in this case.  After successful authentication,
these messages are passed to the higher-level service.

The server should ignore any method-specific messages received while
expecting an authentication request.  These might sometimes result if
the client sends an authentication request that the server does not
understand.

#define SSH_MSG_USERAUTH_BANNER         31
#define SSH_MSG_USERAUTH_FAILURE        32
#define SSH_MSG_USERAUTH_SUCCESS        33
#define SSH_MSG_USERAUTH_REQUEST        34

/* Messages 35-39 are reserved for method-specific messages.
   Different authentication methods may reuse the same message
   numbers. */
/* Key-based */
#define SSH_MSG_USERAUTH_PK_OK          35
/* One-time passwords */
#define SSH_MSG_USERAUTH_OTP_PROMPT     35
#define SSH_MSG_USERAUTH_OTP_RESPONSE   36

6.  Address of Author

              Tatu Ylonen
              SSH Communications Security Ltd.
              Tekniikantie 12
              FIN-02150 ESPOO
              Finland

              E-mail: ylo@ssh.fi










Tatu Ylonen <ylo@ssh.fi>                                       [page 10]
From owner-ietf-ssh@clinet.fi  Wed Mar 26 06:56:28 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id GAA06451;
	Wed, 26 Mar 1997 06:56:27 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id GAA03513;
	Wed, 26 Mar 1997 06:56:27 +0200 (EET)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id GAA08882 for ietf-ssh-outgoing; Wed, 26 Mar 1997 06:56:22 +0200 (EET)
Received: from muuri.ssh.fi (ssh.fi [194.100.44.97]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id GAA08864; Wed, 26 Mar 1997 06:56:18 +0200 (EET)
Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id GAA03509;
	Wed, 26 Mar 1997 06:56:17 +0200 (EET)
Received: (from ylo@localhost)
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) id GAA06447;
	Wed, 26 Mar 1997 06:56:16 +0200 (EET)
Date: Wed, 26 Mar 1997 06:56:16 +0200 (EET)
Message-Id: <199703260456.GAA06447@pilari.ssh.fi>
From: Tatu Ylonen <ylo@ssh.fi>
To: ietf-ssh@clinet.fi
CC: ssh@clinet.fi
Subject: draft-ietf-secsh-connect-01.txt
Organization: SSH Communications Security, Finland
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 28590
Lines: 892

Please find below a draft of the ssh 2.0 connection protocol (that
handles multiplexing several channels onto the same encrypted
tunnel).  Channels can be interactive sessions, X11 connections,
forwarded TCP/IP ports, etc.

Comments and suggestions are welcome.

    Tatu

Network Working Group                           Tatu Ylonen <ylo@ssh.fi>
INTERNET-DRAFT                               SSH Communications Security
draft-ietf-secsh-connect-01.txt                           March 22, 1997
Expires: September 1, 1997


                                    

Status of This memo

This document is an Internet-Draft. 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.''

To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast),
or ftp.isi.edu (US West Coast).

Abstract

This document describes the SSH connection protocol.  It runs over the
SSH user authentication layer, and performs management of forwarded con-
nections and the terminal session(s).


























Tatu Ylonen <ylo@ssh.fi>                                        [page 1]

INTERNET-DRAFT                                            March 22, 1997
 
Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Channel Mechanism   . . . . . . . . . . . . . . . . . . . . . . .  2
  2.1.  Opening a Channel   . . . . . . . . . . . . . . . . . . . . .  3
  2.2.  Data Transfer   . . . . . . . . . . . . . . . . . . . . . . .  3
  2.3.  Closing a Channel   . . . . . . . . . . . . . . . . . . . . .  4
3.  Sessions  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
  3.1.  Opening a Session   . . . . . . . . . . . . . . . . . . . . .  4
  3.2.  Requesting a Pseudo-Terminal  . . . . . . . . . . . . . . . .  5
  3.3.  Environment Variable Passing  . . . . . . . . . . . . . . . .  5
  3.4.  Requesting X11 Forwarding   . . . . . . . . . . . . . . . . .  6
  3.5.  Requesting Athentication Agent Forwarding   . . . . . . . . .  6
  3.6.  Starting Shell or Command   . . . . . . . . . . . . . . . . .  6
  3.7.  Session Data Transfer   . . . . . . . . . . . . . . . . . . .  7
  3.8.  Additional Control Messages   . . . . . . . . . . . . . . . .  7
    3.8.1.  Window Change Message   . . . . . . . . . . . . . . . . .  7
    3.8.2.  Local Flow Control  . . . . . . . . . . . . . . . . . . .  7
  3.9.  Terminating a Session   . . . . . . . . . . . . . . . . . . .  8
4.  X11 Forwarding  . . . . . . . . . . . . . . . . . . . . . . . . .  8
5.  Authentication Agent Forwarding   . . . . . . . . . . . . . . . .  8
6.  TCP/IP Port Forwarding  . . . . . . . . . . . . . . . . . . . . .  9
  6.1.  Requesting Port Forwarding  . . . . . . . . . . . . . . . . .  9
  6.2.  Opening a Forwarded Connection  . . . . . . . . . . . . . . .  9
7.  FTP Forwarding  . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.  Encoding of Terminal Modes  . . . . . . . . . . . . . . . . . . . 10
9.  Summary of Message Numbers  . . . . . . . . . . . . . . . . . . . 14
10.  Address of Author  . . . . . . . . . . . . . . . . . . . . . . . 15



1.  Introduction

This protocol has been designed to run over the SSH transport layer and
user authentication protocols.  The service name for this protocol
(after user authentication) is "ssh-connection".  It provides
interactive login sessions, remote execution of commands, forwarded
TCP/IP connections, and forwarded X11 connections.

2.  Channel Mechanism

All terminal sessions, forwarded connections, etc. are channels.  Either
side may open a channel.  Multiple channels are multiplexed on the
single connection.

There are several ways to open a channel; typically the method used
depends on the intended use of the channel.  After opening, however,
different channels use the same mechanisms for communication.

Channels are identified by numbers at each end.  The number referring to
a channel may be different on each side.  Requests to open a channel
contain the sender's channel number.  Any other channel-related messages
contain the recipient's channel number for the channel.


Tatu Ylonen <ylo@ssh.fi>                                        [page 2]

INTERNET-DRAFT                                            March 22, 1997
 
All channel-related messages contain the number of the channel they
refer to.

Channels are flow-controlled.  No data may be sent to a channel until a
message is received to indicate that window space is available.

2.1.  Opening a Channel

Regardless of the method used to open a channel, when a side wishes to
open a channel, it allocates a local number for the channel.  It then
sends a method-specific message to the other side, and includes the
local channel number and initial window size in the message.  The remote
side then decides whether it can open the channel, and responds with
either

            vlint32   SSH_MSG_CHANNEL_OPEN_CONFIRMATION
            vlint32   recipient_channel
            vlint32   sender_channel
            vlint32   initial_window_size

where recipient_channel is the channel number given in the original open
request, and sender_channel is the channel number allocated by the other
side, or

            vlint32   SSH_MSG_CHANNEL_OPEN_FAILURE
            vlint32   recipient_channel

The window size specifies how many characters the other party can send
before it must wait for the window to be adjusted.  Both parties use the
following message to adjust the window.

            vlint32   SSH_MSG_CHANNEL_WINDOW_ADJUST
            vlint32   recipient_channel
            vlint32   bytes_to_add

Upon receiving this message, the recipient increases the number of bytes
it is allowed to send by the given amount.

2.2.  Data Transfer

Data transfer is done with messages of the following type.

            vlint32   SSH_MSG_CHANNEL_DATA
            vlint32   recipient_channel
            string    data

The maximum amount of data allowed is the current window size.  The
window size is decremented by the amount of data sent.

Additionally, some channels can transfer several types of data.  An
example of this is stderr data from interactive sessions.  Such data can
be passed with SSH_MSG_CHANNEL_EXTENDED_DATA messages, where a separate
integer specifies the type of the data.  The available types and their


Tatu Ylonen <ylo@ssh.fi>                                        [page 3]

INTERNET-DRAFT                                            March 22, 1997
 
interpretation depend on the type of the channel.

            vlint32   SSH_MSG_CHANNEL_EXTENDED_DATA
            vlint32   recipient_channel
            vlint32   data_type_code
            string    data

Data sent with these messages consumes the same window as ordinary data.

Currently, only the following type is defined.

          #define SSH_EXTENDED_DATA_STDERR                1

2.3.  Closing a Channel

When a party will no longer send more data to a channel, it should send
SSH_MSG_CHANNEL_EOF.

            vlint32   SSH_MSG_CHANNEL_EOF
            vlint32   recipient_channel

No explicit response is sent to this message; however, the application
may send EOF to whatever is at the other end of the channel.  Note that
the channel remains open after this message, and more data may still be
sent in the other direction.

When either party wishes to terminate the channel, it sends
SSH_MSG_CHANNEL_CLOSE.  Upon receiving this message, a party must send
back an SSH_MSG_CHANNEL_CLOSE unless it has already sent this message
for the channel.  The channel is considered closed for a party when it
has both sent and received SSH_MSG_CHANNEL_CLOSE, and the party may then
reuse the channel number.  It is legal to send SSH_MSG_CHANNEL_CLOSE
without having sent or received SSH_MSG_EOF.

  vlint32   SSH_MSG_CHANNEL_CLOSE
  vlint32   recipient_channel

3.  Sessions

A session is a remote execution of a command.  The command may be an
shell, a program, or some built-in subsystem.  It may or may not have a
tty, and may or may not involve X11 forwarding.  Multiple sessions can
be active simultaneously.

A session is created by SSH_MSG_CHANNEL_CREATE_SESSION.  Then, the
client may send preparatory requests for the session, such as starting
X11 forwarding or allocating a pseudo-terminal.  Finally, the client
requests to execute a command or to start an interactive shell.

3.1.  Opening a Session

A session is started by sending the following message.  While this
message can be sent by either side, it is normally recommended for


Tatu Ylonen <ylo@ssh.fi>                                        [page 4]

INTERNET-DRAFT                                            March 22, 1997
 
clients not to permit opening new sessions to avoid a corrupt server
from attacking clients.

            vlint32   SSH_MSG_CHANNEL_CREATE_SESSION
            vlint32   sender_channel

The server allocates a channel number and responds with open
confirmation or open failure.

3.2.  Requesting a Pseudo-Terminal

A pseudo-terminal can be allocated for the session by sending the
following message.

  vlint32   SSH_MSG_SESSION_REQUEST_PTY
  vlint32   recipient_channel (session)
  string    TERM environment variable value (e.g., vt100)
  vlint32   terminal width, characters (e.g., 80)
  vlint32   terminal height, rows (e.g., 24)
  vlint32   terminal width, pixels (e.g., 480)
  vlint32   terminal height, pixels (e.g., 640)
  string    encoded terminal modes

The encoding of terminal modes is described in Section ``Encoding of
Terminal Modes''.

The server responds with either SSH_MSG_CHANNEL_SUCCESS or
SSH_MSG_CHANNEL_FAILURE.  The client is allowed to send further messages
without waiting for the response to this message.

            vlint32   SSH_MSG_CHANNEL_SUCCESS
            vlint32   recipient_channel

            vlint32   SSH_MSG_CHANNEL_FAILURE
            vlint32   recipient_channel

3.3.  Environment Variable Passing

Environment variables may be passed to the shell/command to be started
later.  Typically, each machine will have a preconfigured set of
variables that it will allow.  Since uncontrolled setting of environment
variables can be very dangerous, it is recommended that implementations
allow setting only variables whose names have been explicitly configured
to be allowed.

            vlint32   SSH_MSG_SESSION_ENVIRONMENT_VARIABLE
            vlint32   recipient_channel
            string    variable_name
            string    variable_value

The server responds with either SSH_MSG_CHANNEL_SUCCESS or
SSH_MSG_CHANNEL_FAILURE.  The client is allowed to send further messages
without waiting for the response to this message.


Tatu Ylonen <ylo@ssh.fi>                                        [page 5]

INTERNET-DRAFT                                            March 22, 1997
 
3.4.  Requesting X11 Forwarding

X11 forwarding may be requested for a session by sending

            vlint32   SSH_MSG_SESSION_REQUEST_X11_FORWARDING
            vlint32   recipient_channel (session)
            string    x11_authentication_protocol
            string    x11_authentication_cookie
            vlint32   x11_screen_number

It is recommended that the authentication cookie that is sent be a fake,
random cookie, and that the cookie is checked and replaced by the real
cookie when a connection request is received.

The server responds with either SSH_MSG_CHANNEL_SUCCESS or
SSH_MSG_CHANNEL_FAILURE.  The client is allowed to send futher messages
without waiting for the reponse to this message.

3.5.  Requesting Athentication Agent Forwarding

Authentication agent forwarding may be requested for a session by
sending

            vlint32   SSH_MSG_SESSION_REQUEST_AGENT_FORWARDING
            vlint32   recipient_channel (session)

The server responds with either SSH_MSG_CHANNEL_SUCCESS or
SSH_MSG_CHANNEL_FAILURE.  The client is allowed to send futher messages
without waiting for the reponse to this message.

3.6.  Starting Shell or Command

Once the session has been set up, a shell or command is started at the
remote end.  This can happen in any of a number of ways.

            vlint32   SSH_MSG_SESSION_EXEC_SHELL
            vlint32   recipient_channel

            vlint32   SSH_MSG_SESSION_EXEC_COMMAND
            vlint32   recipient_channel
            string    command

            vlint32   SSH_MSG_SESSION_EXEC_PREDEFINED
            vlint32   recipient_channel
            vlint32   subsystem_name

This last form executes a predefined subsystem.  It expected that these
will include a general file transfer mechanism, and possibly other
features.  Implementations may also allow configuring more such
mechanisms.  Having a special message for them avoids the need to have
their paths and command names be supplied by the other side.  This also
makes it easier to implement them in the same executable as the rest of
the protocol on platforms where that is desirable.


Tatu Ylonen <ylo@ssh.fi>                                        [page 6]

INTERNET-DRAFT                                            March 22, 1997
 
3.7.  Session Data Transfer

Data transfer for a session is done using SSH_MSG_CHANNEL_DATA and
SSH_MSG_CHANNEL_EXTENDED_DATA packets and the window mechanism.  The
extended data type SSH_EXTENDED_DATA_STDERR has been defined for stderr
data.

3.8.  Additional Control Messages

Smooth operation sometimes requires extra messages to be passed to
notify the other side of some event or change.

A single message type, SSH_MSG_SESSION_NOTIFICATION has been defined for
all of these notifications.  Implementations should ignore all
notifications that they cannot interpret, and are free to ignore any
notifications.

  vlint32   SSH_MSG_SESSION_NOTIFICATION
  vlint32   recipient_channel
  string    notification_type
  ...

Currently, the following notification types have been defined:

            window_change          Window size changed
            xon_xoff_flow_control  Local flow control

3.8.1.  Window Change Message

When the window (terminal) size changes on the client side (client here
means the party who sent the create message for the session), it may
send a message to the other side to inform it of the new size.

            vlint32   SSH_MSG_SESSION_NOTIFICATION
            vlint32   recipient_channel
            string    "window_change"
            vlint32   terminal width, columns
            vlint32   terminal height, rows
            vlint32   terminal width, pixels
            vlint32   terminal height, pixels

3.8.2.  Local Flow Control

On many systems it is possible to determine if a pseudo-terminal is
using control-S control-Q flow control.  When this is the case, it is
often desirable to do the flow control at the client end to speed up
responses to user requests.  This is facilitated by the following two
notifications.  Initially, the server is responsible for flow control.
(Here, again, client means the side originating the session, and server
the other side.)

  vlint32   SSH_MSG_SESSION_NOTIFICATION
  vlint32   recipient_channel


Tatu Ylonen <ylo@ssh.fi>                                        [page 7]

INTERNET-DRAFT                                            March 22, 1997
 
  string    "xon_xoff_flow_control"
  boolean   client_can_do

If client_can_do is true, the client (originator) can do control-S
control-Q flow control locally.

3.9.  Terminating a Session

When the command running at the other end terminates,
SSH_MSG_SESSION_EXIT_STATUS may be sent to return the exit status of the
command.  Returning the status is optional, but recommended.  No
acknowledgement is sent for this message.  The channel needs to be
closed with SSH_MSG_CHANNEL_CLOSE after this message.

            vlint32   SSH_MSG_SESSION_EXIT_STATUS
            vlint32   recipient_channel
            vlint32   exit_status

4.  X11 Forwarding

X11 forwarding is requested with respect to a session.  However,
forwarded connections are independent of the session.

The request to forward X11 connections opens a fake X11 display on the
server.  No connections are opened at this time.

When an X11 client connects the fake X11 server, a request is sent to
the originator of the session.

            vlint32   SSH_MSG_X11_OPEN
            vlint32   sender_channel
            vlint32   initial_window_size
            string    originator_string

The recipient should respond with open confirmation or open failure.
Originator_string is a free-form implementation-dependent description of
the X11 client that made the connection.  It should typically contain
the IP address and port of the client, and may also contain user name or
other information if available.  It should be in a format that is
understandable by a user.

5.  Authentication Agent Forwarding

Authentication agent forwarding is requested with respect to a session.
However, forwarded connections are independent of the session.

When an application requests a connection to the authentication agent,
the following message is sent to the originator of the session.

            vlint32   SSH_MSG_AGENT_OPEN
            vlint32   sender_channel
            vlint32   initial_window_size
            string    originator_string


Tatu Ylonen <ylo@ssh.fi>                                        [page 8]

INTERNET-DRAFT                                            March 22, 1997
 
            string    host_chain

The recipient should respond with open confirmation or open failure.
Originator_string is a free-form implementation-dependent description of
the application that made the connection, or empty if no description is
available. host_chain is a comma-separated list of hosts this request
has passed through. (Receiver of the message appends the sender's name,
if the message will be passed on (i.e. receiver is not the actual
agent).)

Because only one application can use a forwarded agent channel at a
time, multiple channels cannot be multiplexed in a ssh daemon. Instead,
ssh daemon must pass the request, and forward the reply all the way from
the agent to the requesting application. This results in creation of a
private channel for application using the agent. Agent stores the host
chain for every channel and uses it to determine which operations are
permitted.

6.  TCP/IP Port Forwarding

6.1.  Requesting Port Forwarding

A party need not explicitly request forwardings from its own end to the
other direction.  However, it if wishes to have connections to a port on
the other side be forwarded to the local side, it must explicitly
request this.

            vlint32   SSH_MSG_REQUEST_TCPIP_PORT_FORWARDING
            string    address_to_bind
            vlint32   port_number_to_bind

Address_to_bind and port_number_to_bind specify the IP address and port
to which the socket to be listened is bound.  The address should be
"0.0.0.0" if connections are allowed from anywhere.  (Note that the
client can still filter connections based on information passed in the
open request.)

Implementations should only allow forwarding privileged ports if the
user has been authenticated as a privileged user.

The recipient will respond to this message with either
SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE.

            vlint32   SSH_MSG_REQUEST_SUCCESS

            vlint32   SSH_MSG_REQUEST_FAILURE

6.2.  Opening a Forwarded Connection

When a connection comes to a port for which forwarding was requested
with SSH_MSG_REQUEST_TCPIP_PORT_FORWARDING, the following message is
sent to the other side.



Tatu Ylonen <ylo@ssh.fi>                                        [page 9]

INTERNET-DRAFT                                            March 22, 1997
 
            vlint32   SSH_MSG_TCPIP_REMOTE_PORT_OPEN
            vlint32   sender_channel
            vlint32   initial_window_size
            vlint32   port_that_was_connected
            string    originator_ip_address
            vlint32   originator_port
            string    originator_string

When a connection comes to a locally forwarded TCP/IP port, the
following packet is sent to the other side.  Note that these messages
may be sent also for ports for which no forwarding has been explicitly
requested.  The receiving side must decide whether to allow the
forwarding.

            vlint32   SSH_MSG_TCPIP_PORT_OPEN
            vlint32   sender_channel
            vlint32   initial_window_size
            string    host_to_connect
            vlint32   port_to_connect
            string    originator_ip_address
            vlint32   originator_port
            string    originator_string

Host_to_connect and port_to_connect specify the TCP/IP host and port
where the recipient should connect the channel.  Host_to_connect may be
either a domain name or a numeric IP address.

Originator_ip_address is the numeric IP address of the machine where the
connection request comes from, and originator_port is the port on the
originator host from where the connection came from.  Originator_string
is a free-form description of where the connection came in a form that
can be displayed to the user.

7.  FTP Forwarding

XXX

8.  Encoding of Terminal Modes

Terminal modes (as passed in SSH_MSG_SESSION_REQUEST_PTY) are encoded
into a byte stream.  It is intended that the coding be portable across
different environments.

The tty mode description is a stream of bytes.  The stream consists of
opcode-argument pairs.  It is terminated by opcode TTY_OP_END (0).
Opcodes 1-127 have one-byte arguments.  Opcodes 128-159 have 32-bit
integer arguments (stored msb first).  Opcodes 160-255 are not yet
defined, and cause parsing to stop (they should only be used after any
other data).

The client puts in the stream any modes it knows about, and the server
ignores any modes it does not know about.  This allows some degree of
machine-independence, at least between systems that use a POSIX-like tty


Tatu Ylonen <ylo@ssh.fi>                                       [page 10]

INTERNET-DRAFT                                            March 22, 1997
 
interface.  The protocol can support other systems as well, but the
client may need to fill reasonable values for a number of parameters so
the server pty gets set to a reasonable mode (the server leaves all
unspecified mode bits in their default values, and only some
combinations make sense).

The following opcodes have been defined.  The naming of opcodes mostly
follows the POSIX terminal mode flags.

   0 TTY_OP_END
      Indicates end of options.

   1 VINTR
      Interrupt character; 255 if none.  Similarly for the other
      characters.  Not all of these characters are supported on all
      systems.

   2 VQUIT
      The quit character (sends SIGQUIT signal on UNIX systems).

   3 VERASE
      Erase the character to left of the cursor.

   4 VKILL
      Kill the current input line.

   5 VEOF
      End-of-file character (sends EOF from the terminal).

   6 VEOL
      End-of-line character in addition to carriage return and/or
      linefeed.

   7 VEOL2
      Additional end-of-line character.

   8 VSTART
      Continues paused output (normally control-Q).

   9 VSTOP
      Pauses output (normally control-S).

   10 VSUSP
      Suspends the current program.

   11 VDSUSP
      Another suspend character.

   12 VREPRINT
      Reprints the current input line.

   13 VWERASE
      Erases a word left of cursor.


Tatu Ylonen <ylo@ssh.fi>                                       [page 11]

INTERNET-DRAFT                                            March 22, 1997
 
   14 VLNEXT
      More special input characters; these are probably not supported on
      most systems.
   15 VFLUSH
      Character to flush output.

   16 VSWTCH
      ???

   17 VSTATUS
      ???

   18 VDISCARD
      ???

   30 IGNPAR
      The ignore parity flag.  The next byte should be 0 if this flag is
      not set, and 1 if it is set.

   31 PARMRK
      Mark parity and framing errors.

   32 INPCK
      Enable checking of parity errors.

   33 ISTRIP
      Strip 8th bit off chars.

   34 INLCR
      Map NL into CR on input.

   35 IGNCR
      Ignore CR on input.

   36 ICRNL
      Map CR to NL on input.

   37 IUCLC
      ???

   38 IXON
      Enable output flow control.

   39 IXANY
      Any char will restart after stop.

   40 IXOFF
      Enable input flow control.

   41 IMAXBEL
      Ring bell on input queue full.

   50 ISIG


Tatu Ylonen <ylo@ssh.fi>                                       [page 12]

INTERNET-DRAFT                                            March 22, 1997
 
      Enable signals INTR, QUIT, DSUSP.

   51 ICANON
      Canonicalize input lines.

   52 XCASE
      ???
   53 ECHO
      Enable echoing.

   54 ECHOE
      Visually erase chars.

   55 ECHOK
      Kill character discards current line.

   56 ECHONL
      Echo NL even if ECHO is off.

   57 NOFLSH
      Don't flush after interrupt.

   58 TOSTOP
      Stop background jobs from output.

   59 IEXTEN
      Enable extensions.

   60 ECHOCTL
      Echo control characters as ^(Char).

   61 ECHOKE
      Visual erase for line kill.

   62 PENDIN
      Retype pending input.

   70 OPOST
      Enable output processing.

   71 OLCUC
      Convert lowercase to uppercase.

   72 ONLCR
      Map NL to CR-NL.

   73 OCRNL
      ???

   74 ONOCR
      ???

   75 ONLRET


Tatu Ylonen <ylo@ssh.fi>                                       [page 13]

INTERNET-DRAFT                                            March 22, 1997
 
      ???

   90 CS7
      7 bits.

   91 CS8
      8 bits.

   92 PARENB
      Parity enable.

   93 PARODD
      Odd parity, else even.

   192 TTY_OP_ISPEED
      Specifies the input baud rate in bits per second (as a 32-bit int,
      msb first).

   193 TTY_OP_OSPEED
      Specifies the output baud rate in bits per second (as a 32-bt int,
      msb first).

9.  Summary of Message Numbers

The following message numbers are used by this protocol.  If an
unrecognized message is received, SSH_MSG_REQUEST_FAILURE should be sent
in response.

          #define SSH_MSG_CHANNEL_OPEN_CONFIRMATION          40
          #define SSH_MSG_CHANNEL_OPEN_FAILURE               41
          #define SSH_MSG_CHANNEL_WINDOW_ADJUST              42
          #define SSH_MSG_CHANNEL_DATA                       43
          #define SSH_MSG_CHANNEL_EOF                        44
          #define SSH_MSG_CHANNEL_CLOSE                      45
          #define SSH_MSG_CHANNEL_CREATE_SESSION             46
          #define SSH_MSG_SESSION_REQUEST_PTY                47
          #define SSH_MSG_CHANNEL_SUCCESS                    48
          #define SSH_MSG_CHANNEL_FAILURE                    49
          #define SSH_MSG_SESSION_ENVIRONMENT_VARIABLE       50
          #define SSH_MSG_SESSION_REQUEST_X11_FORWARDING     51
          #define SSH_MSG_SESSION_REQUEST_AGENT_FORWARDING   52
          #define SSH_MSG_SESSION_EXEC_SHELL                 53
          #define SSH_MSG_SESSION_EXEC_COMMAND               54
          #define SSH_MSG_SESSION_EXEC_PREDEFINED            55
          #define SSH_MSG_SESSION_NOTIFICATION               56
          #define SSH_MSG_SESSION_EXIT_STATUS                57
          #define SSH_MSG_X11_OPEN                           58
          #define SSH_MSG_AGENT_OPEN                         59
          #define SSH_MSG_REQUEST_TCPIP_PORT_FORWARDING      60
          #define SSH_MSG_REQUEST_SUCCESS                    61
          #define SSH_MSG_REQUEST_FAILURE                    62
          #define SSH_MSG_TCPIP_REMOTE_PORT_OPEN             63
          #define SSH_MSG_TCPIP_PORT_OPEN                    64


Tatu Ylonen <ylo@ssh.fi>                                       [page 14]

INTERNET-DRAFT                                            March 22, 1997
 
10.  Address of Author

              Tatu Ylonen
              SSH Communications Security Ltd.
              Tekniikantie 12
              FIN-02150 ESPOO
              Finland

              E-mail: ylo@ssh.fi













































Tatu Ylonen <ylo@ssh.fi>                                       [page 15]
From owner-ietf-ssh@clinet.fi  Thu Mar 27 10:17:47 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id KAA19065;
	Thu, 27 Mar 1997 10:17:46 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id KAA07728;
	Thu, 27 Mar 1997 10:17:45 +0200 (EET)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id KAA25468 for ietf-ssh-outgoing; Thu, 27 Mar 1997 10:13:50 +0200 (EET)
Received: from muuri.ssh.fi (ssh.fi [194.100.44.97]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id KAA25451 for <ietf-ssh@clinet.fi>; Thu, 27 Mar 1997 10:13:37 +0200 (EET)
Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id KAA07710;
	Thu, 27 Mar 1997 10:12:33 +0200 (EET)
Received: (from ylo@localhost)
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) id KAA19048;
	Thu, 27 Mar 1997 10:12:20 +0200 (EET)
Date: Thu, 27 Mar 1997 10:12:20 +0200 (EET)
Message-Id: <199703270812.KAA19048@pilari.ssh.fi>
From: Tatu Ylonen <ylo@ssh.fi>
To: Elliot Lee <sopwith@cuc.edu>
Cc: pam-list@redhat.com, ietf-ssh@clinet.fi
Subject: Re: draft-ietf-secsh-userauth-01.txt (fwd)
In-Reply-To: <Pine.LNX.3.95.970327014937.28324A-100000@helix.cs.cuc.edu>
References: <Pine.GSO.3.95.970327171117.23564k-100000@hawk.ind.tansu.com.au>
	<Pine.LNX.3.95.970327014937.28324A-100000@helix.cs.cuc.edu>
Organization: SSH Communications Security, Finland
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1520
Lines: 32

> I read it. It is moving towards a more easily PAMifiable model, but it is,
> as the author (cc'd on this) says:
> > Authentication is mostly client-driven.  The client sends an
> > authentication request, and the server responds with success or failure.
>
> This is 180 degrees contrary to the PAM model, which has the server asking
> the client for the appropriate auth tokens.
> 
> If it is possible to have the rhosts-style of authentication always be
> tried before password authentication, then we can store the rhosts info on
> an rhosts try, always fail the rhosts try, and pass the rhosts info in
> with a pam_authenticate() call when password authentication is tried. 

I'm not very very familiar with the way PAM works.

However, in the new protocol the server actually drives the
authentication process.  Whenever a request fails, it lists the
authentication methods that might productively continue the dialog.
The server's policy may dictate that other authentications can be
tried only after "pam" authentication.  Or, the client's policy might
say that "pam" authentication is tried before any other
authentications if the server is willing to accept it.

I've clarified the wording of the draft regarding the authentication
process being client-driven.

I'd appreciate if someone can tell me what it would take to add "pam"
as an authentication method (or multiple methods if appropriate).
Ideally, someone could write a section on the pam authentication
methods to be included in the draft.

    Tatu
From owner-ietf-ssh@clinet.fi  Thu Mar 27 10:51:45 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id KAA19236;
	Thu, 27 Mar 1997 10:51:44 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id KAA07790;
	Thu, 27 Mar 1997 10:51:44 +0200 (EET)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id KAA28129 for ietf-ssh-outgoing; Thu, 27 Mar 1997 10:51:12 +0200 (EET)
Received: from helix.cs.cuc.edu (sopwith@helix.cs.cuc.edu [204.32.57.128]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id KAA28122 for <ietf-ssh@clinet.fi>; Thu, 27 Mar 1997 10:51:07 +0200 (EET)
Received: from localhost (sopwith@localhost)
	by helix.cs.cuc.edu (8.8.5/8.8.5) with SMTP id DAA32722;
	Thu, 27 Mar 1997 03:50:54 -0500
Date: Thu, 27 Mar 1997 03:50:54 -0500 (EST)
From: Elliot Lee <sopwith@cuc.edu>
X-Sender: sopwith@helix.cs.cuc.edu
To: pam-list@redhat.com
cc: ietf-ssh@clinet.fi
Subject: Re: draft-ietf-secsh-userauth-01.txt (fwd)
In-Reply-To: <199703270812.KAA19048@pilari.ssh.fi>
Message-ID: <Pine.LNX.3.95.970327033503.31125C-100000@helix.cs.cuc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2206
Lines: 56

On Thu, 27 Mar 1997, Tatu Ylonen wrote:

> I'm not very very familiar with the way PAM works.
> 
> However, in the new protocol the server actually drives the
> authentication process.  Whenever a request fails, it lists the
> authentication methods that might productively continue the dialog.
> The server's policy may dictate that other authentications can be
> tried only after "pam" authentication.  Or, the client's policy might
> say that "pam" authentication is tried before any other
> authentications if the server is willing to accept it.

Ahh. Sounds like it will work well with PAM, just a little round-a-bout.

> I'd appreciate if someone can tell me what it would take to add "pam" 
> as an authentication method (or multiple methods if appropriate). 
> Ideally, someone could write a section on the pam authentication methods
> to be included in the draft. 

Well here's a bit of how PAM works WRT ssh:

It's designed to allow you to use many different authentication methods
with a standard API and without recompiling.

Can we do something like:
Ask client for remote username
pam_start()
do pam_set_item for PAM_RUSER, PAM_RHOST, and PAM_TTY (may not have tty if
it's not an interactive login, that's OK).
Call pam_authenticate()
	pam_authenticate may call our conversation callback which will
	send a custom prompt to the client and ask the client for a
	password.
The results of this would tell us whether or not to let the user in.

There are also some other PAM functions that need to be called when
starting/closing a session:
	pam_setcred() (usually does equiv of initgroups() and other stuff
			like that)
	pam_acct_mgmt() (some other stuff)
	pam_open_session() (utmp handling theoretically, resource limits, etc.)
--- do whatever your program does
	pam_close_session()
	pam_end()

May be problems with allowing the conversation function to send a message
back to the client - i.e. do we use a global variable to let it access the
socket fd and/or state information in order to be able to send messages?

Well there's my ideas, I'm sure other pam-list members have comments
as well.

Hope this helps,
-- Elliot Lee
   http://www.redhat.com/             http://www.linuxexpo.org/

From owner-ietf-ssh@clinet.fi  Thu Mar 27 15:40:03 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id PAA21461;
	Thu, 27 Mar 1997 15:40:03 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id PAA08598;
	Thu, 27 Mar 1997 15:40:02 +0200 (EET)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id PAA15752 for ietf-ssh-outgoing; Thu, 27 Mar 1997 15:37:12 +0200 (EET)
Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [205.233.54.146]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id PAA15702 for <ietf-ssh@clinet.fi>; Thu, 27 Mar 1997 15:36:39 +0200 (EET)
Received: from amaterasu.sandelman.ottawa.on.ca (amaterasu.sandelman.ottawa.on.ca [205.233.54.134]) by lox.sandelman.ottawa.on.ca (8.7.5/8.7.3) with ESMTP id IAA02683; Thu, 27 Mar 1997 08:19:35 -0500 (EST)
Received: from amaterasu.sandelman.ocunix.on.ca (LOCALHOST [127.0.0.1]) by amaterasu.sandelman.ottawa.on.ca (8.7.5/8.6.12) with ESMTP id IAA04306; Thu, 27 Mar 1997 08:33:39 -0500 (EST)
Message-Id: <199703271333.IAA04306@amaterasu.sandelman.ottawa.on.ca>
To: Tatu Ylonen <ylo@ssh.fi>
CC: ietf-ssh@clinet.fi
Subject: Re: draft-ietf-secsh-userauth-01.txt (fwd) 
In-reply-to: Your message of "Thu, 27 Mar 1997 10:12:20 +0200."
             <199703270812.KAA19048@pilari.ssh.fi> 
Date: Thu, 27 Mar 1997 08:33:34 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2381
Lines: 53

-----BEGIN PGP SIGNED MESSAGE-----


  I read the draft yesterday and was about to comment on it today, but
I see someone else has beaten me to this comment.

  I do not see how the client can ever know that it needs to do
multiple authentications. The server is purposely vague about what
kind of authentication is requires, and in the case of multiple
authentication is vague about when the client has satisfied it.

  I realize that there are many that prefer that the server not give
away its security policy. I know we had this debate before.
  
  I would like to see text that explains how a multiple levels of
authentication could be performed, preferably where the proxy server
connected the client to a final destination after the initial
authentication. (This would happen with the proxy server creating a
new transport layer to the new server) 
  An example is necessary here. I see contradictory text between the
last paragraph of 2.6.1 and section 3: "any SSH_MSG_USERAUTH_REQUEST
messages after sending this message will be silently ignored"
  How can the client know that the initial partial authentication be
successful except by receipt of a USERAUTH_SUCCESS?
  Also, how does the client know which method succeeded? 

  Further, I'm concerned about the text being silent about not sending
password logins when the server host key is new, or has changed. 

  I must admit that I prefer server driven authentication. At least as
an option in the protocol.

  The other case that this would be interesting is if the server may
request client authentication at any stage. Perhaps this is better
done through a connection to the agent. I imagine having an SSH aware
su, where the client can present a certificate to su (which has a
secure channel to sshd) which verifies that user can become root.

   :!mcr!:            |  Network security consulting and 
   Michael Richardson |      contract programming
 WWW: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.

  
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQB1AwUBMzp3G6ZpLyXYhL+BAQEUFAL/ed3Y+43LR7s3Bp8/7prx7B1jXBaiKRE6
s9kGHx/M5cHmZcqo6we2n6x/cxN9HRo+9pH+lJpCfdtZ+dM23Z6vs+CBv7HHHGq8
cPIkrVZjxviQBrNTmlgVw+zsJZk5vuPg
=J8FD
-----END PGP SIGNATURE-----
From owner-ietf-ssh@clinet.fi  Thu Mar 27 17:11:37 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id RAA22197;
	Thu, 27 Mar 1997 17:11:37 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id RAA08844;
	Thu, 27 Mar 1997 17:11:31 +0200 (EET)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id RAA22532 for ietf-ssh-outgoing; Thu, 27 Mar 1997 17:08:31 +0200 (EET)
Received: from ietf.org (ietf.org [132.151.1.19]) by hauki.clinet.fi (8.8.5/8.6.4) with SMTP id RAA22511 for <ietf-ssh@clinet.fi>; Thu, 27 Mar 1997 17:08:22 +0200 (EET)
Received: from ietf.ietf.org by ietf.org id aa17382; 27 Mar 97 9:55 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
cc: ietf-ssh@clinet.fi
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-secsh-transport-00.txt
Date: Thu, 27 Mar 1997 09:55:06 -0500
Message-ID:  <9703270955.aa17382@ietf.org>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3275
Lines: 84

--NextPart

 A New Internet-Draft is available from the on-line Internet-Drafts 
 directories. This draft is a work item of the Secure Shell Working Group 
 of the IETF.                                                              

       Title     : SSH Transport Layer Protocol                            
       Author(s) : T. Ylonen
       Filename  : draft-ietf-secsh-transport-00.txt
       Pages     : 21
       Date      : 03/26/1997

This document describes the SSH transport layer protocol.  The protocol can
be used as a basis for a number of secure network services.  It provides 
strong encryption, server authentication, and integrity protection.        

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-secsh-transport-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-transport-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-secsh-transport-00.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.
							
							

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19970326115213.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-secsh-transport-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-secsh-transport-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19970326115213.I-D@ietf.org>

--OtherAccess--

--NextPart--
From owner-ietf-ssh@clinet.fi  Thu Mar 27 17:11:34 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id RAA22190;
	Thu, 27 Mar 1997 17:11:34 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id RAA08843;
	Thu, 27 Mar 1997 17:11:29 +0200 (EET)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id RAA22516 for ietf-ssh-outgoing; Thu, 27 Mar 1997 17:08:28 +0200 (EET)
Received: from ietf.org (ietf.org [132.151.1.19]) by hauki.clinet.fi (8.8.5/8.6.4) with SMTP id RAA22497 for <ietf-ssh@clinet.fi>; Thu, 27 Mar 1997 17:08:14 +0200 (EET)
Received: from ietf.ietf.org by ietf.org id aa17383; 27 Mar 97 9:55 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
cc: ietf-ssh@clinet.fi
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-secsh-userauth-00.txt
Date: Thu, 27 Mar 1997 09:55:09 -0500
Message-ID:  <9703270955.aa17383@ietf.org>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3411
Lines: 86

--NextPart

 A New Internet-Draft is available from the on-line Internet-Drafts 
 directories. This draft is a work item of the Secure Shell Working Group 
 of the IETF.                                                              

       Title     : SSH Authentication Protocol                             
       Author(s) : T. Ylonen
       Filename  : draft-ietf-secsh-userauth-00.txt
       Pages     : 10
       Date      : 03/26/1997

This documents describes the SSH authentication protocol.  It is used to 
prove that the client is authorized access the requested service with the 
supplied user name.  This authorization can be demonstrated through 
possession of a password, through possession of a key, by authenticating 
the client host and user, by some other method, or a combination of these. 

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-secsh-userauth-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-userauth-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-secsh-userauth-00.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.
							
							

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19970326115622.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-secsh-userauth-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-secsh-userauth-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19970326115622.I-D@ietf.org>

--OtherAccess--

--NextPart--
From owner-ietf-ssh@clinet.fi  Thu Mar 27 17:12:50 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id RAA22204;
	Thu, 27 Mar 1997 17:12:49 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id RAA08850;
	Thu, 27 Mar 1997 17:12:48 +0200 (EET)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id RAA23097 for ietf-ssh-outgoing; Thu, 27 Mar 1997 17:11:58 +0200 (EET)
Received: from ietf.org (ietf.org [132.151.1.19]) by hauki.clinet.fi (8.8.5/8.6.4) with SMTP id RAA23040 for <ietf-ssh@clinet.fi>; Thu, 27 Mar 1997 17:11:41 +0200 (EET)
Received: from ietf.ietf.org by ietf.org id aa17435; 27 Mar 97 9:55 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
cc: ietf-ssh@clinet.fi
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-secsh-connect-00.txt
Date: Thu, 27 Mar 1997 09:55:18 -0500
Message-ID:  <9703270955.aa17435@ietf.org>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3265
Lines: 84

--NextPart

 A New Internet-Draft is available from the on-line Internet-Drafts 
 directories. This draft is a work item of the Secure Shell Working Group 
 of the IETF.                                                              

       Title     : Connect                                                 
       Author(s) : T. Ylonen
       Filename  : draft-ietf-secsh-connect-00.txt
       Pages     : 15
       Date      : 03/26/1997

This document describes the SSH connection protocol.  It runs over the SSH 
user authentication layer, and performs management of forwarded connections
and the terminal session(s).                                               

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-secsh-connect-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-secsh-connect-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-secsh-connect-00.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.
							
							

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv@ds.internic.net"

Content-Type: text/plain
Content-ID: <19970326120036.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-secsh-connect-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-secsh-connect-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19970326120036.I-D@ietf.org>

--OtherAccess--

--NextPart--
From owner-ietf-ssh@clinet.fi  Thu Mar 27 23:13:22 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id XAA24235;
	Thu, 27 Mar 1997 23:13:22 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id XAA09602;
	Thu, 27 Mar 1997 23:13:22 +0200 (EET)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id XAA23483 for ietf-ssh-outgoing; Thu, 27 Mar 1997 23:11:08 +0200 (EET)
Received: from parc.power.net (parc.power.net [198.186.216.82]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id XAA23461 for <ietf-ssh@clinet.fi>; Thu, 27 Mar 1997 23:10:58 +0200 (EET)
Received: (from morgan@localhost) by parc.power.net (8.7.1/8.7.1) id NAA02968; Thu, 27 Mar 1997 13:13:33 -0800
From: "Andrew G. Morgan" <morgan@parc.power.net>
Message-Id: <199703272113.NAA02968@parc.power.net>
Subject: Re: draft-ietf-secsh-userauth-01.txt (fwd)
To: pam-list@redhat.com
Date: Thu, 27 Mar 1997 13:13:33 -0800 (PST)
Cc: ietf-ssh@clinet.fi
In-Reply-To: <Pine.LNX.3.95.970327033503.31125C-100000@helix.cs.cuc.edu> from "Elliot Lee" at Mar 27, 97 03:50:54 am
Content-Type: text
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1030
Lines: 28

Tatu Ylonen wrote:
> I'd appreciate if someone can tell me what it would take to add "pam"
> as an authentication method (or multiple methods if appropriate).
> Ideally, someone could write a section on the pam authentication
> methods to be included in the draft.

You might like to take a look at the source code from my forthcoming LJ
article:

    http://parc.power.net/morgan/Linux-PAM/pre/Linux-PAM-C-listing.txt

It is an update of the one contained in the PAM RFC:

    http://parc.power.net/morgan/Linux-PAM/rfc86.0.txt.gz


[Note, (In his previous email) Elliot placed the setcred and session calls
in the reverse order from that specified in the RFC.. This was a mistake
that I think I'm probably responsible for, and one that I only realized
needed correcting when writing the article for LJ :*( ]

Hope this helps,

Andrew
-- 
               Linux-PAM, libpwdb, Orange-Linux and Linux-GSS
                  http://parc.power.net/morgan/index.html
       [ For those that prefer FTP  ---  ftp://ftp.lalug.org/morgan ]
From owner-ietf-ssh@clinet.fi  Fri Mar 28 03:20:31 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id DAA26515;
	Fri, 28 Mar 1997 03:20:30 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id DAA10348;
	Fri, 28 Mar 1997 03:20:30 +0200 (EET)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id DAA10360 for ietf-ssh-outgoing; Fri, 28 Mar 1997 03:19:27 +0200 (EET)
Received: from muuri.ssh.fi (ssh.fi [194.100.44.97]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id DAA10347 for <ietf-ssh@clinet.fi>; Fri, 28 Mar 1997 03:19:21 +0200 (EET)
Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id DAA10341;
	Fri, 28 Mar 1997 03:19:19 +0200 (EET)
Received: (from ylo@localhost)
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) id DAA26506;
	Fri, 28 Mar 1997 03:19:19 +0200 (EET)
Date: Fri, 28 Mar 1997 03:19:19 +0200 (EET)
Message-Id: <199703280119.DAA26506@pilari.ssh.fi>
From: Tatu Ylonen <ylo@ssh.fi>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Cc: ietf-ssh@clinet.fi, ylo@ssh.fi
Subject: Re: draft-ietf-secsh-userauth-00.txt (fwd) 
In-Reply-To: <199703271333.IAA04306@amaterasu.sandelman.ottawa.on.ca>
References: <199703270812.KAA19048@pilari.ssh.fi>
	<199703271333.IAA04306@amaterasu.sandelman.ottawa.on.ca>
Organization: SSH Communications Security, Finland
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 7965
Lines: 164

>   I do not see how the client can ever know that it needs to do
> multiple authentications. The server is purposely vague about what
> kind of authentication is requires, and in the case of multiple
> authentication is vague about when the client has satisfied it.

Every time an authentication request fails (or succeeds but more
authentications are required), the server responds with
a SSH_MSG_USERAUTH_FAILURE message that contains a list of
authentication methods that could usefully continue the dialog.
The list changes as some authentications are accepted.

Suppose, for example, that the server's policy says:
  - from within foo.org, accept password, hostbased, one-time
    password, and publickey authentication
  - from anywhere else, require hostbased authentication PLUS one-time
    password

The client would typically first send a "none" authentication request.
The server responds with the list of methods that can reasonably
continue: "password,hostbased,publickey,skey,opie" if from inside
foo.org (maybe not all of these for every user), and
"hostbased,skey,opie" if outside.  Suppose the client is outside, and
it now sends a correct hostbased request.  The server responds with
SSH_MSG_USERAUTH_FAILURE, but this time lists only "skey,opie".  If
the client now sends a successful "skey" authentication, the server
responds with SSH_MSG_USERAUTH_SUCCESS.

Note that it would have been equally legal for the server to first
list only "hostbased" when coming from outside the organization, and
then change the list to "skey,opie" when hostbased authentication has
been successfully performed.

I've already clarified some of the wording in the draft regarding
authentication being client-driven.  It is really server-driven, with
some flexibility allowed for the client (the client chooses from the
methods offered by the server).

>   I realize that there are many that prefer that the server not give
> away its security policy. I know we had this debate before.

In the current design, the server reveals which methods it is willing
to accept.  This may depend on where the user is logging in from, and
may depend on the user.  Other details of the policy are only revealed
after the client has successfully performed some authentication.

>   I would like to see text that explains how a multiple levels of
> authentication could be performed, preferably where the proxy server
> connected the client to a final destination after the initial
> authentication. (This would happen with the proxy server creating a
> new transport layer to the new server) 

I assume you mean like a firewall proxy, and the user first
authenticates to the firewall and only then gets connected to the real
host where he needs to autenticate again?

This has currently not been thought of.  I welcome any suggestions on
how this should work.  Issues to consider include:
  - how does the client know whether it can know the proxy server (the
    man in the middle)?
  - how does the server know that it can trust the proxy server (the
    man in the middle)?
  - how to tell the real server who the real client is?

One part of the solution could be to create a certificate that
authorizes the proxy to act on behalf of each side.  Another part
could be a proxy authentication message that tells the server that it
should use another session id and host name as the basis for
authentication than that supplied by the transport layer.

This could work as follows:

1. The client connects the target host, but the firewall redirects the
connection to the proxy (or should there be a mechanism to have it
connect the proxy directly?).  The proxy sends its own host key,
together with a trusted certificate saying that it is an authorized
representative of the target host.

2. The client then authenticates itself to the proxy, using any
authentication methods the proxy asks for.  The dialog is as described
in the userauth draft.

3. When the proxy is satisfied that the connection is legal (it would
normally send SSH_MSG_USERAUTH_SUCCESS), it suppresses the success
message, connects the real target host, and establishes a transport
layer connection.

4. It sends the real target a "proxied-connection" authentication
message that looks like the following:
     vlint32   SSH_MSG_USERAUTH_REQUEST
     string    user
     string    service
     string    "proxied-connection"
     string    proxy_host_key_algorithm
     string    proxy_public_host_key  (may include certificates)
     string    real client host IP address (e.g. "128.34.129.121")
     string    real client port
     string    real client session id
     string    signature of other data by proxy host key

5. The real server verifies that the proxy host key is trusted and the
signature is valid.  It then stores the real client host, port, and
session id for use in further authentication, and uses these to decide
the policy (which might also be affected by the fact that it is coming
through a proxy).  The server then performs authentication operations
similar to "none" authentication, and responds with
SSH_MSG_USERAUTH_FAILURE listing the authentication methods it still
wants (or might respond with SSH_MSG_USERAUTH_SUCCESS if it is willing
to trust the proxy's judgement).

As far as I can see, this would allow a firewall proxy to decrypt and
re-encrypt any sessions if properly authorized by the communicating
parties (or someone they trust).

This does not completely solve the problem for the case that the
client needs to directly connect to the proxy (is that case
relevant?).  For that to work, we need to pass the name of the real
target host somewhere, either on the transport layer or on the user
authentication layer.  One possibility would be to have a new
fake authentication mehthod "connect-to-real-host" that could look
like the following:
      vlint32   SSH_MSG_USERAUTH_REQUEST
      string	user
      string	service
      string    "connect-to-real-host"
      string	real-target-host-name
The proxy could request this authentication method either in the
beginning of the authentication or at the end of the authentication.
I don't think this is very elegant though.

>   An example is necessary here. I see contradictory text between the
> last paragraph of 2.6.1 and section 3: "any SSH_MSG_USERAUTH_REQUEST
> messages after sending this message will be silently ignored"
>   How can the client know that the initial partial authentication be
> successful except by receipt of a USERAUTH_SUCCESS?
>   Also, how does the client know which method succeeded? 

The client is allowed to send many authentication requests without
waiting for response.  In practise, it could send any such requests
immediately that are quick to process and do not require any user
interaction.  For example, it could send all "none", "publickeytest",
"hostbased", or "kerberos" requests right away, and only then proceed
with more interactive authentications guided by the server.

The server will respond with SSH_MSG_USERAUTH_FAILURE to every request
in sequence, until it responds with SSH_MSG_USERAUTH_SUCCESS, after
which all SSH_MSG_USERAUTH_REQUEST packets are ignored.

This basically just speeds up login on long-distance connections.

>   Further, I'm concerned about the text being silent about not sending
> password logins when the server host key is new, or has changed. 

What to do when the host key is unknown is a very tricky issue in
general.  In such a situation, the connection is fundamentally
insecure.  In future, the problem will be solved by a key
infrastructure, but for now it is practical in many situations to
trust the supplied host key if no other key is avaiable (it is an
insecure against active attacs vs. no connection at all choice, and
usually slightly insecure is better than no communication at all).

In my opinion this is beyond the scope of the protocol, and is more a
policy and implementation issue.  What do others think?

    Tatu
From owner-ietf-ssh@clinet.fi  Fri Mar 28 03:59:55 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id DAA26808;
	Fri, 28 Mar 1997 03:59:54 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id DAA10437;
	Fri, 28 Mar 1997 03:59:54 +0200 (EET)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id DAA12636 for ietf-ssh-outgoing; Fri, 28 Mar 1997 03:59:13 +0200 (EET)
Received: from martigny.ai.mit.edu (martigny.ai.mit.edu [18.43.0.152]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id DAA12560; Fri, 28 Mar 1997 03:57:42 +0200 (EET)
Received: from freeside.ai.mit.edu by martigny.ai.mit.edu with SMTP
	(1.40.112.8/16.2) id AA207114242; Thu, 27 Mar 1997 20:57:22 -0500
From: "Philip J. Nesser II" <pjnesser@martigny.ai.mit.edu>
Message-Id: <199703280157.AA207114242@martigny.ai.mit.edu>
Subject: Re: draft-ietf-secsh-userauth-01.txt
To: ylo@ssh.fi (Tatu Ylonen)
Date: Thu, 27 Mar 1997 20:57:20 -0500 (EST)
Cc: ietf-ssh@clinet.fi, ssh@clinet.fi
In-Reply-To: <199703260453.GAA06429@pilari.ssh.fi> from "Tatu Ylonen" at Mar 26, 97 06:53:08 am
Organization: Nesser & Nesser Consulting
Phone: (206)481-4303
Us-Nail: 13501 100th Ave NE, Suite 5202, Kirkland, WA 98034
X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1381
Lines: 44

Tatu Ylonen supposedly said:
> 
> Please find below the current draft for the ssh 2.0 user
> authentication protocol.  
> 
> Comments and suggestions are welcome.  Note that this should be
> reviewed in combination with the transport layer protocol, as this
> uses some material (e.g., session identifier) provided by the
> transport layer.
> 
>     Tatu
> 
> Network Working Group                           Tatu Ylonen <ylo@ssh.fi>
> INTERNET-DRAFT                               SSH Communications Security
> draft-ietf-secsh-userauth-01.txt                          March 22, 1997
> Expires: September 1, 1997
> 

Tatu,
 
I would add the following specifications under the one time password 
systems, since the OTP system is being standardized in the IETF (RFC1938)
 
Under Section 2.0 in the list of predefined methods, add:
 
otp-md4                 OTP system using MD4 hashing
otp-md5                 OTP system using MD5 hashing
otp-sha1                OTP system using SHA1 hashing
 
 
Under Section 2.5 add the following subsections:
 
2.5.3 OTP
 
The One Time Password (OTP) is an IETF standards track protocol defined in
   
RFC 1938.  OTP is defined using three hash functions, MD4, MD5 and SHA1.
The method names for OTP hashes will be of the form "otp-<hash>", and in
the case of the three initial hash functions: "otp-md4", "otp-md5", and 
"otp-sha1".



--->  Phil
From owner-ietf-ssh@clinet.fi  Fri Mar 28 04:39:35 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id EAA27068;
	Fri, 28 Mar 1997 04:39:35 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id EAA10547;
	Fri, 28 Mar 1997 04:39:34 +0200 (EET)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id EAA15031 for ietf-ssh-outgoing; Fri, 28 Mar 1997 04:39:02 +0200 (EET)
Received: from muuri.ssh.fi (ssh.fi [194.100.44.97]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id EAA14980; Fri, 28 Mar 1997 04:38:03 +0200 (EET)
Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id EAA10543;
	Fri, 28 Mar 1997 04:38:03 +0200 (EET)
Received: (from ylo@localhost)
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) id EAA27064;
	Fri, 28 Mar 1997 04:38:02 +0200 (EET)
Date: Fri, 28 Mar 1997 04:38:02 +0200 (EET)
Message-Id: <199703280238.EAA27064@pilari.ssh.fi>
From: Tatu Ylonen <ylo@ssh.fi>
To: "Philip J. Nesser II" <pjnesser@martigny.ai.mit.edu>
CC: ietf-ssh@clinet.fi, ssh@clinet.fi
Subject: Re: draft-ietf-secsh-userauth-01.txt
In-Reply-To: <199703280157.AA207114242@martigny.ai.mit.edu>
References: <199703260453.GAA06429@pilari.ssh.fi>
	<199703280157.AA207114242@martigny.ai.mit.edu>
Organization: SSH Communications Security, Finland
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 410
Lines: 12

> I would add the following specifications under the one time password 
> systems, since the OTP system is being standardized in the IETF (RFC1938)
>  
> Under Section 2.0 in the list of predefined methods, add:
>  
> otp-md4                 OTP system using MD4 hashing
> otp-md5                 OTP system using MD5 hashing
> otp-sha1                OTP system using SHA1 hashing

Added.   Thanks.

    Tatu
From owner-ietf-ssh@clinet.fi  Fri Mar 28 06:18:12 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id GAA27658;
	Fri, 28 Mar 1997 06:18:12 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id GAA10719;
	Fri, 28 Mar 1997 06:18:11 +0200 (EET)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id GAA00794 for ietf-ssh-outgoing; Fri, 28 Mar 1997 06:14:18 +0200 (EET)
Received: from muuri.ssh.fi (ssh.fi [194.100.44.97]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id GAA00789 for <ietf-ssh@clinet.fi>; Fri, 28 Mar 1997 06:14:15 +0200 (EET)
Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id GAA10712
	for <ietf-ssh@clinet.fi>; Fri, 28 Mar 1997 06:14:14 +0200 (EET)
Received: (from ylo@localhost)
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) id GAA27648;
	Fri, 28 Mar 1997 06:14:14 +0200 (EET)
Date: Fri, 28 Mar 1997 06:14:14 +0200 (EET)
Message-Id: <199703280414.GAA27648@pilari.ssh.fi>
From: Tatu Ylonen <ylo@ssh.fi>
To: ietf-ssh@clinet.fi
Subject: publickeytest merged to publickey
Organization: SSH Communications Security, Finland
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3207
Lines: 86

I decided to merge the "publickeytest" authentication method into the
"publickey" method.  This avoids having to process "publickeytest" as
a special case in both server and client implementations.  The client
will still need to maintain state about which keys it has already
tested and what the answers have been, but at least for the server
it should be simpler this way.

The new text is below.  (This is in linuxdoc-sgml format.)

    Tatu

<sect2> Public Key Authentication <p>

The possession of a private key can serve as authentication.  This
method works by sending a signature created by the private key.  

Private keys are often stored encrypted at the client host, and the
user must supply a passphrase before the signature can be generated.
To avoid needing to supply passphrases when it is not necessary, the
client can optionally query whether a particular key would be acceptable as
authentication.  This done with the following message.  The key may
include certificates.

<tscreen><verb>
  vlint32   SSH_MSG_USERAUTH_REQUEST
  string    user
  string    service
  string    "publickey"
  boolean   FALSE
  string    public key algorithm name
  string    public key to be used for authentication
</verb></tscreen>

Public key algorithms are defined in the transport layer
specification.  The key may include certificates.

The server will respond to this message with either
SSH_MSG_USERAUTH_FAILURE or with

<tscreen><verb>
  vlint32   SSH_MSG_USERAUTH_PK_OK
</verb></tscreen>

To do actual authentication, the client should then send a signature
generated by the public key.  It is permissible to send the signature
directly without first querying whether the key is acceptable.

<tscreen><verb>
  vlint32   SSH_MSG_USERAUTH_REQUEST
  string    user
  string    service
  string    "publickey"
  boolean   TRUE
  string    public key algorithm name
  string    public key to be used for authentication
  string    signature
</verb></tscreen>

The public key may contain certificates.

<tt> Signature </tt> is a signature by the corresponding private key
of the HASH of the concatenation of the following, in this order:
<itemize>
<item> the session identifier (which binds the signature to the server
host key and the particular key exchange),
<item> length of the user name as a 32-bit integer, msb first,
<item> user name (without length or null characters),
<item> length of the service name as a 32-bit integer, msb first,
<item> service name (without length or null characters),
<item> length of the public key algorithm name as a 32-bit integer,
msb first,
<item> public key algorithm name (without length or null characters),
<item> length of the public key from the message as a 32-bit
integer, msb first, and
<item> the public key from the message (without length or null
characters).
</itemize>

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

If both checks succeed, authentication may be granted (the
server may also require further authentication with other methods,
without letting the client know at this point that authentication has
partially succeeded).
From owner-ietf-ssh@clinet.fi  Sat Mar 29 10:43:09 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id KAA10741;
	Sat, 29 Mar 1997 10:43:08 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id KAA15405;
	Sat, 29 Mar 1997 10:43:08 +0200 (EET)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id KAA18776 for ietf-ssh-outgoing; Sat, 29 Mar 1997 10:38:44 +0200 (EET)
Received: from muuri.ssh.fi (ssh.fi [194.100.44.97]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id KAA18767; Sat, 29 Mar 1997 10:38:38 +0200 (EET)
Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id KAA15394;
	Sat, 29 Mar 1997 10:38:37 +0200 (EET)
Received: (from ylo@localhost)
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) id KAA10729;
	Sat, 29 Mar 1997 10:38:36 +0200 (EET)
Date: Sat, 29 Mar 1997 10:38:36 +0200 (EET)
Message-Id: <199703290838.KAA10729@pilari.ssh.fi>
From: Tatu Ylonen <ylo@ssh.fi>
To: ssh@clinet.fi, ietf-ssh@clinet.fi
Subject: draft-ietf-secsh-transport-00.txt
Organization: SSH Communications Security, Finland
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 50943
Lines: 1242

There was apparently some a problem in sending this draft (message
size limit was too low on the ietf-ssh list).

    Tatu

Network Working Group                           Tatu Ylonen <ylo@ssh.fi>
INTERNET-DRAFT                               SSH Communications Security
draft-ietf-secsh-transport-00.txt                         March 22, 1997
Expires: September 1, 1997


                      SSH Transport Layer Protocol

Status of This memo

This document is an Internet-Draft. 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.''

To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast),
or ftp.isi.edu (US West Coast).

Abstract

This document describes the SSH transport layer protocol.  The protocol
can be used as a basis for a number of secure network services.  It pro-
vides strong encryption, server authentication, and integrity protec-
tion.

























Tatu Ylonen <ylo@ssh.fi>                                        [page 1]

INTERNET-DRAFT                                            March 22, 1997
 
Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Data Type Representations Used in the Protocol  . . . . . . . . .  3
  2.1.  vlint32   . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  2.2.  string  . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  2.3.  boolean   . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  2.4.  byte  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
  2.5.  uint16  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
  2.6.  uint32  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
3.  Algorithm Naming  . . . . . . . . . . . . . . . . . . . . . . . .  4
4.  Connection Setup  . . . . . . . . . . . . . . . . . . . . . . . .  4
  4.1.  Use over TCP/IP   . . . . . . . . . . . . . . . . . . . . . .  5
  4.2.  Protocol Version Exchange   . . . . . . . . . . . . . . . . .  5
  4.3.  Compatibility with Old SSH Versions   . . . . . . . . . . . .  5
    4.3.1.  Old Client, New Server  . . . . . . . . . . . . . . . . .  5
    4.3.2.  New Client, Old Server  . . . . . . . . . . . . . . . . .  5
5.  Binary Packet Protocol  . . . . . . . . . . . . . . . . . . . . .  6
  5.1.  Maximum Packet Length   . . . . . . . . . . . . . . . . . . .  6
  5.2.  Compression   . . . . . . . . . . . . . . . . . . . . . . . .  7
  5.3.  Encryption  . . . . . . . . . . . . . . . . . . . . . . . . .  7
  5.4.  Data Integrity  . . . . . . . . . . . . . . . . . . . . . . .  8
6.  Key Exchange  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
  6.1.  Algorithm Negotiation   . . . . . . . . . . . . . . . . . . .  9
  6.2.  Double-Encrypting Key Exchange  . . . . . . . . . . . . . . . 12
    6.2.1.  Server Sends Host Key   . . . . . . . . . . . . . . . . . 12
    6.2.2.  Deriving Exchange Hash and Session Identifier   . . . . . 13
    6.2.3.  Client Sends Double-Encrypted Session Key   . . . . . . . 14
    6.2.4.  Deriving Encryption and Integrity Keys  . . . . . . . . . 14
  6.3.  Taking Keys into Use  . . . . . . . . . . . . . . . . . . . . 15
7.  Key Re-Exchange   . . . . . . . . . . . . . . . . . . . . . . . . 15
8.  Service Request   . . . . . . . . . . . . . . . . . . . . . . . . 16
9.  Stream-Based Services   . . . . . . . . . . . . . . . . . . . . . 17
10.  Additional Messages  . . . . . . . . . . . . . . . . . . . . . . 17
  10.1.  Disconnection Message  . . . . . . . . . . . . . . . . . . . 17
  10.2.  Ignored Data Message   . . . . . . . . . . . . . . . . . . . 18
  10.3.  Debug Message  . . . . . . . . . . . . . . . . . . . . . . . 18
  10.4.  Reserved Messages  . . . . . . . . . . . . . . . . . . . . . 18
11.  Summary of Message Numbers   . . . . . . . . . . . . . . . . . . 18
12.  Public Keys and Public Key Infrastructure  . . . . . . . . . . . 19
  12.1.  x509   . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
  12.2.  spki   . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
  12.3.  ssh-rsa-pkcs1  . . . . . . . . . . . . . . . . . . . . . . . 20
13.  Address of Author  . . . . . . . . . . . . . . . . . . . . . . . 21



1.  Introduction

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



Tatu Ylonen <ylo@ssh.fi>                                        [page 2]

INTERNET-DRAFT                                            March 22, 1997
 
Authentication in this protocol level is host-based; this protocol does
not perform user authentication.  It is expected that a higher level
protocol will be defined on top of this protocol that will perform user
authentication for those services that need it.

The protocol has been designed to be simple, flexible, allow parameter
negotiation, and 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 1.5 round-trips will be needed
for full key exchange, server authentication, service request, and
acceptance notification of service request.  The worst case is 2.5
round-trips.

2.  Data Type Representations Used in the Protocol

2.1.  vlint32

The vlint32 can represent arbitrary 32-bit unsigned integers.  It is
stored as a variable number of bytes (1-5 bytes), depending on the value
being stored.

Bits 6-7 of the first byte (the most significant bits) determine the
number of additional bytes that follow, and are interpreted as follows.

  Bit7  Bit6    Number of bytes that follow
   0     0       0
   0     1       1
   1     0       2
   1     1       4

Bits 0-5 of the first byte and the following bytes contain the value of
the integer, MSB first.

If bits 6-7 are both one, the remaining bits in the first byte are zero
(reserved for future extension).

2.2.  string

A string here means an arbitrary length binary string.  Strings are
allowed to contain arbitrary binary data, including null characters and
8-bit characters.

A string is represented as a vlint32 containing its length, followed by
zero or more characters that are the value of the string.  No
terminating null character is normally included in the string.

2.3.  boolean

A boolean value is represented as a single byte.  The value 0 represents
false, and the value 1 represents true.  All non-zero values are
interpreted as true, but applications should not store values other than
0 and 1.


Tatu Ylonen <ylo@ssh.fi>                                        [page 3]

INTERNET-DRAFT                                            March 22, 1997
 
2.4.  byte

A byte represents an arbitrary 8-bit value.  Fixed length data is
sometimes represented as an array of bytes, written byte[n], where n is
the number of bytes in the array.

2.5.  uint16

A 16-bit unsigned integer, represented as two bytes, MSB first.

2.6.  uint32

A 32-bit unsigned integer, represented as four bytes, MSB first.

3.  Algorithm Naming

This protocol refers to particular hash, encryption, integrity,
compression, and key exchange algorithms in various places.  There are
some standard algorithms that all implementations are required to
support.  There are also algorithms that are defined in the protocol
specification but are optional.  Furthermore, it is expected that some
organizations will want to use their own algorithms whenever possible.
This leads to the problem of how algorithm identifiers are allocated.

In this protocols, all algorithm identifiers are represented as strings.
Names are case-sensitive.  Algorithm lists are comma-separated lists of
these identifiers, without spaces.  There are two formats for algorithm
identifiers:

o  Algorithms defined in the base protocol are simple strings, such as
   "3des-cbc", "sha-1", "hmac-sha", or "zip" (the quotes are not part of
   the name).  Defined algorithms may be mandatory or optional.  All
   interoperable implementations should implement mandatory algorithms
   and offer them as a possibility in key exchanges.  Optional
   algorithms are not crucial for interoperability, but may provide
   better performance or other advantages.  It is up to an
   implementation to decide which of these are supported and which are
   offered in key exchanges by default.

o  Anyone can define additional algorithms by using names in the format
   name@domainname, e.g. "ourcipher-cbc@ssh.fi".  The format of the part
   preceding the at sign is not specified; it may contain any non-
   control characters except at signs and commas.  The part following
   the at sign should be a valid internet domain name for the
   organization defining the name.  It is up to the each organization
   how they manage its locally defined names.

4.  Connection Setup

SSH works over any 8-bit clean, binary-transparent transport.  The
client initiates the connection, and sets up the binary-transparent
transport.



Tatu Ylonen <ylo@ssh.fi>                                        [page 4]

INTERNET-DRAFT                                            March 22, 1997
 
4.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 (Internet
Assigned Numbers Authority), and has been officially assigned for SSH.

4.2.  Protocol Version Exchange

When the connection has been established, both sides send an
identification string of the form "SSH-protoversion-softwareversion
comments", followed by carriage return and newline (ascii 13 and 10,
respectively).  No null character is sent.  The maximum length of the
string is 255 characters, including the cr and newline.  The protocol
version described in this document is 2.0.  Version strings should only
contain printable characters, not including space or '-'.  The string is
used in debugging outputs to ease debugging; the protocol version is
also used to trigger compatible extensions.  It is recommended that the
strings be as descriptive as possible.  The comment string could include
information such as the platform type which might be useful in solving
user problems.

Key exchange will begin immediately after sending this identifier
(normally without waiting for the identifier from the other side -- see
the next section for compatibility issues).  All packets following the
identification string will use the binary packet protocol, to be
described below.

4.3.  Compatibility with Old SSH Versions

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

4.3.1.  Old Client, New Server

Server implementations should support a configurable "compatibility"
flag that enables compatibility with old versions.  When this flag is
on, the server will 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 desired.

When compatibility with old clients is not needed, the server should
send its initial key exchange data immediately after the identification
string.  This saves a round-trip.

4.3.2.  New Client, Old Server

Since the new client will immediately send additional data after its
identification string (before receiving server's identification), the
old protocol has already been corrupted when the client learns that the
server is old.  When this happens, the client should close the


Tatu Ylonen <ylo@ssh.fi>                                        [page 5]

INTERNET-DRAFT                                            March 22, 1997
 
connection to the server, and reconnect using the old protocol this
time.

5.  Binary Packet Protocol

Each packet consists of the following fields:

    Length
      The length of the packet (bytes).  This represents the number of
      bytes that follow this value, not including the optional MAC.  The
      length is represented as a vlint32.

    Padding length
      Length of padding (bytes).  This field is represented as a
      vlint32.

    Payload
      The useful contents of the packet.  This field is optionally
      compressed.

    Padding
      Arbitrary-length padding, such that the total length of
      length+paddinglength+payload+padding is a multiple of the cipher
      block size or 8, whichever is larger.  It is recommended that at
      least four bytes of random padding be always used.

    MAC
      Message authentication code.  This field is optional, and its
      length depends on the algorithm in use.

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 is enforced even when using stream
ciphers.  Note that the packet length field is also encrypted, and
processing it requires special care when sending/receiving packets.  In
particular, one has to be extra careful when computing the amount of
padding, as changing the amount of padding can also change the size of
the length fields.  The minimum size of a packet is 8 (or cipher block
size, whichever is larger) characters (plus MAC); implementations should
decrypt the length after receiving the first 8 (or cipher block size,
whichever is larger) bytes of a packet.

When the protocol starts, no encryption is in effect, no compression is
used, and no MAC is in use.  During key exchange, an encryption method,
compression method, and a MAC method are selected.  Any further messages
will use the negotiated algorithms.

5.1.  Maximum Packet Length

The maximum length of the uncompressed payload is 32768 bytes.  The
maximum size of the entire packet, including length, padding length,
payload, padding, and MAC, is 35000 bytes.  The motivation for this
limit is to keep the protocol easy to implement on 16-bit machines.


Tatu Ylonen <ylo@ssh.fi>                                        [page 6]

INTERNET-DRAFT                                            March 22, 1997
 
5.2.  Compression

If compression has been negotiated, the payload field (and only it) will
be compressed using the negotiated algorithm.  The length field will
contain the compressed length (i.e., that transmitted on the wire).

Compressed packets must not exceed the total packet size limit; the
compression algorithm must guarantee that it does not expand the packet
too much.  The uncompressed payload size must not exceed the maximum
payload size (the compressed payload, however, may be bigger than the
maximum payload size, as long as the packet size limit is not exceeded).

The following compression methods are currently defined:

          none     mandatory       no compression
          zlib     optional        GNU ZLIB compression at level 6

The "zlib" compression is described in RFC1950.

The compression context is initialized after 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 all data will be
output, but the next packet will continue using compression tables from
the end of the previous packet.

Compression is independent in each direction, and the different
compression methods may be used for each direction.

5.3.  Encryption

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

The encrypted data in all packets sent in one direction will be
considered a single data stream.  For example, initialization vectors
will be passed from the end of one packet to the beginning of the next
packet.

The ciphers in each direction will run independently of each other.
They will typically use a different key, and different ciphers can be
used in each direction.

The following ciphers are currently defined:

          none             optional          no encryption
          3des-cbc         mandatory         three-key 3DES in CBC mode
          idea-cbc         optional          IDEA in CBC mode
          arcfour          optional          ARCFOUR stream cipher
          blowfish-cbc     optional          Blowfish in CBC mode

The 3des-cbc encryption is three-key triple-DES (encrypt-decrypt-


Tatu Ylonen <ylo@ssh.fi>                                        [page 7]

INTERNET-DRAFT                                            March 22, 1997
 
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 the parity bits are not actually used).  To implement CBC mode,
there is only one initialization vector.

For ciphers with variable-length keys, 128 bit keys are used.

The ARCFOUR cipher is compatible with the RC4 cipher; RC4 is a trademark
of RSA Data Security, Inc.

Descriptions of all of these ciphers can be found e.g. from Bruce
Schneier: Applied Cryptography, 2nd ed., John Wiley and Sons, 1996.

5.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 will be
zero.  After key exchange, the selected MAC will be computed before
encryption from the concatenation of packet data (lengths, payload, and
padding) and a packet sequence number (stored as a 32-bit integer, MSB
first).  The integrity key is also used in the computation of the MAC,
but the way it is used depends on the MAC algorithm in use.  Note that
the MAC algorithm may be different for each direction.

The packet sequence number is only used for integrity checking.  It is
never explicitly transmitted, but it is included in MAC computation to
ensure that no packets are lost or received out of sequence.  The
sequence number of the first packet sent is zero; from there on the
sequence number is incremented by one for every packet sent (separately
for each direction).  The packet number is 32 bits and wraps around if
32 bits is not enough for representing it.  The sequence number is
incremented also for packets that are not encrypted or MACed, and is not
reset even if keys are renegotiated later.

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

The following MAC algorithms are currently defined:

          none        optional         no MAC
          hmac-md5    optional         HMAC-MD5 (length = 16)
          hmac-sha    optional         HMAC-SHA (length = 20)
          md5-8       optional         first 8 bytes MD5 key+data+key
          sha-8       optional         first 8 bytes SHA-1 key+data+key
          sha         mandatory        SHA of key+data+key (20 bytes)

The HMAC methods are described in RFC 2104.


Tatu Ylonen <ylo@ssh.fi>                                        [page 8]

INTERNET-DRAFT                                            March 22, 1997
 
The "md5-8" method returns the first 8 bytes of MD5 of the concatenation
of the key, authenticated data, and the key again.  The "sha-8" method
is the same but using the SHA hash.

Even though only the "sha" method is mandatory, it is recommended that
implementations support and prefer the other methods.  (This method
exists only as a fallback should unexpected patent problems surface.)

6.  Key Exchange

Key exchange begins by each side sending lists of supported algorithms.
Each side has a preferred algorithm, and it is assumed that most
implementations at any given time will use the same preferred algorithm.
Each side will make the guess that the other side is using the same
algorithm, and may send an initial key exchange packet according to the
algorithm if appropriate for the preferred method.  If the guess is
wrong, they'll ignore the guessed packet, select a common algorithm, and
send the initial key exchange packet again, this time for the same
algorithm.
Currently, the following key exchange methods have been defined:

          double-encrypting-sha        mandatory

The implementation of these methods is described later in this section.

One should note that server authentication in the double-encrypting key
exchange is implicit, and the client doesn't really know the identity of
the server until it receives a message from the server using the correct
MAC and encryption.  This means that an attacker could fool the client
into using no encryption (if the client is willing to accept no
encryption), and the client might in some cases send sensitive data,
such as a password, before it notices that the server isn't responding
properly.  For this reason, it is recommended that clients should not
accept "none" encryption unless explicitly requested by the user.
Alternatively, they should wait for the server's response to the service
request before sending anything else.

6.1.  Algorithm Negotiation

Each side sends the following packet (this is the part that goes inside
the payload):

            vlint32   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    hash_algorithms


Tatu Ylonen <ylo@ssh.fi>                                        [page 9]

INTERNET-DRAFT                                            March 22, 1997
 
            boolean   first_kex_packet_follows
            byte[4]   0 (reserved for future extension)

Each of the algorithms strings are comma-separated lists of algorithm
names.  Each supported (allowed) algorithm should be listed, in order of
preference.  The preferred (guessed) algorithm should be listed first.
Each string must contain at least one algorithm name.  The value "none"
is not automatically allowed; if a party permits connections with "none"
as one of the algorithms, it should list that as an algorithm.

    cookie
      The cookies are random values generated by each side.  Their
      purpose is to make it impossible for either side to fully
      determine the keys (which might open possibilities for passing
      certain signatures/authentications to third parties).

    kex_algorithms
      Key exchange algorithms were defined above.  The first algorithm
      is the preferred (and guessed) algorithm.  If both sides make the
      same guess, that algorithm is used.  Otherwise, the following
      algorithm is 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: 1) the server
      also supports the algorithm 2) 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 3) 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, connection fails.

      The kex algorithm names were listed above.

    server_host_key_algorithms
      Lists 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 can 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 kex algorithm
      requires a signature- or encryption capable host key.  The first
      algorithm on the client's list that satisfies the requirements and
      is also supported by the server is chosen.

      Section ``Public Key Formats'' lists the available algorithm
      names.



Tatu Ylonen <ylo@ssh.fi>                                       [page 10]

INTERNET-DRAFT                                            March 22, 1997
 
    encryption_algorithms
      Lists the acceptable symmetric encryption algorithms in order of
      preference.  The chosen encryption algorithm will be the first
      algorithm on the client's list that is also on the server's list.
      If there is no such algorithm, connection fails.

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

      The algorithm to use is negotiated separately for each direction,
      and different algorithms may be chosen.
    mac_algorithms
      Lists the acceptable MAC algorithms in order of preference.  The
      chosen MAC algorithm will be the first algorithm on the client's
      list that is also on the server's list.  If there is no such
      algorithm, connection fails.

      Note that "none" must be explicitly listed if it is to be
      acceptable.  The MAC algorithm names are listed in Section ``Data
      Integrity''.

      The algorithm to use is negotiated separately for each direction,
      and different algorithms may be chosen.

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

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

      The algorithm to use is negotiated separately for each direction,
      and different algorithms may be chosen.

    hash_algorithms
      Lists the acceptable hash algorithms in order of preference.  The
      chosen hash algorithm will be the first algorithm on the client's
      list that is also on the server's list.  If there is no such
      algorithm, connection fails.

      Implementations should only permit algorithms that they consider
      to be fairly secure, as the hash function will be used e.g. for
      deriving various keys from the shared secret.  All hash algorithms
      must produce at least 16 bytes of output.

      Currently, the following hash functions are defined.

             md5          optional      MD5 algorithm (16 byte output)
             sha          mandatory     SHA-1 algorithm (20 byte output)


Tatu Ylonen <ylo@ssh.fi>                                       [page 11]

INTERNET-DRAFT                                            March 22, 1997
 
    first_kex_packet_follows
      Each side makes a guess of the negotiated key exchange method.
      This is based on the assumption that at any particular time there
      will be a single key exchange method and algorithm combination
      that dominates the installed base.  Making a guess about the
      algorithm will save a round-trip in the typical case, and will
      incur little extra cost in the other cases.

      Each side will determine if they are supposed to send an initial
      packet in their guessed key exchange method.  If they are, they
      will set this field to true and follow this packet by the first
      key exchange packet.

      The guessed method is the one listed first on the kex_algorithms,
      server_host_key_algorithms, and hash_algorithms lists.  If the
      negotiated values for any of these algorithms differs from the
      first value on either side, the guess is taken to be wrong, and
      the packet sent based on the guess is ignored.  Whether the
      packets based on the guess are actually wrong is not a factor in
      this decision (the information may not be available to make this
      decision).

      After receiving the SSH_MSG_KEXINIT packet from the other side,
      each party will know whether their guess was right.  If the guess
      was wrong, and this field is true, the next packet will be
      silently ignored, and each side will then act as determined by the
      negotiated key exchange method.  If the guess was right, key
      exchange will immediately continue.

6.2.  Double-Encrypting Key Exchange

The double-encrypting key exchange requires that the server host key
supports encryption.  The idea is that the server sends its public host
key and a periodically changing key (called the server key).  The client
then verifies that it is the correct key for the server, generates a
session key, encrypts the session key using both a time-variant server
key and the server host key, and sends the encrypted session key to the
server.

The server key and host keys must both support encryption, and their
sizes must be such that the server key can encrypt at least 48 bytes,
and the server host key can encrypt the result of the first encryption.
Note that padding is normally added at each encryption, depending on the
public key method, so the actual size difference of the keys is bigger.
Both keys must use the same public key algorithm.

6.2.1.  Server Sends Host Key

First, the server sends its public host and server keys in the following
packet:

            vlint32   SSH_MSG_KEXDE_HOSTKEY
            string    public host key


Tatu Ylonen <ylo@ssh.fi>                                       [page 12]

INTERNET-DRAFT                                            March 22, 1997
 
            string    public server key

The host key and server key are stored in binary representation as
described in Section ``Public Key Formats''.  Both keys are of the type
negotiated for the server host key.

After receiving the public keys, the client validates that the host key
really belongs to the intended server.  How this verification happens is
not specified in this protocol.  Currently it may be checked against a
database of known name-key mappings; in future it will be validated
using an Internet public key infrastructure.  The key may contain
certificates to facilitate this.

If the client is not willing to trust the server host key, it should
send an SSH_MSG_DISCONNECT packet and close the connection.

The client then generates a 256 bit random session key (shared secret).

6.2.2.  Deriving Exchange Hash and Session Identifier

To authenticate that no-one has been manipulating the key exchange with
the server, the client computes an SHA-1 hash of the concatenation of
the following (in this order):

1. the length of the payload of the client's SSH_MSG_KEXINIT message as
   4 bytes, MSB first,

2. the payload of the client's SSH_MSG_KEXINIT message,

3. the length of the payload of the server's SSH_MSG_KEXINIT message as
   4 bytes, MSB first,

4. the payload of the server's SSH_MSG_KEXINIT message,

5. the length of the payload of the server's SSH_MSG_KEXDE_HOSTKEY
   message as 4 bytes, MSB first,

6. the payload of the server's SSH_MSG_KEXDE_HOSTKEY message, and

7. the 32 bytes of the session key.

   This value is called the exchange hash, and it is used to
   authenticate the key exchange.

Note that the use of SHA-1 was hard-coded here.  This is used to
authenticate the key exchange, and using HASH here would lead to all
sorts of potential problems in verifying the security of the protocol.
Using a fixed hash short-circuits verification to the properties of
SHA-1.  Should the need ever arise, the only way to switch to another
algorithm here is to define a new key exchange algorithm (which, in
fact, is not very difficult).

The exchange hash from the first key exchange in a connection is called


Tatu Ylonen <ylo@ssh.fi>                                       [page 13]

INTERNET-DRAFT                                            March 22, 1997
 
the session identifier.  It is used in host authentication and other
authentication methods as data that is signed to prove possession of a
private key.

Once computed, the session identifier is not changed or recomputed even
if keys are later re-exchanged.  The exchange hash, on the other hand,
is computed separately for each key exchange.

6.2.3.  Client Sends Double-Encrypted Session Key

The client forms a message to send to the server by concatenating the
following (in this order): six zero bytes (reserved for future
extension), first 10 bytes of the exchange hash, and the 32 bytes of the
shared secret.  This results in a total of 48 bytes of data to be passed
to the server.  Note that the negotiated algorithms are not explicitly
passed, as the algorithms given in Section ``Algorithm Negotiation''
fully determine the algorithms.

The resulting data is encrypted first with the time-variant server key,
and the result then with the server host key.  The resulting double-
encrypted value is then sent to the server.  Note that public-key
encryption probably involves padding, depending on the algorithm.

            vlint32   SSH_MSG_KEXDE_SESSIONKEY
            string    double-encrypted session key

Upon receiving this message, the server uses its private host and server
keys to decrypt the session key.  It computes a corresponding SHA hash,
and compares the hash values.  If the hash does not match, the server
disconnects with the appropriate message.  If the hash matches, the
server responds with an SSH_MSG_NEWKEYS message and takes the keys into
use.

6.2.4.  Deriving Encryption and Integrity Keys

As a result of the key exchange, the parties have a 256-bit shared
secret.  Various keys are computed from this secret and the exchange
hash.  The session identifier is used to make it impossible for either
party to alone determine the keys.

Each key is computed as HASH of the concatenation of the session
identifier and 16 bytes of secret data.  The secret data is different
for each key, and is taken from the 32-byte shared secret as follows:

o  Initial IV client to server: bytes 0-15

o  Initial IV server to client: bytes 1-16

o  Encryption key client to server: bytes 5-20

o  Encryption key server to client: bytes 8-23

o  Integrity key client to server: bytes 13-28


Tatu Ylonen <ylo@ssh.fi>                                       [page 14]

INTERNET-DRAFT                                            March 22, 1997
 
o  Integrity key server to client: bytes 16-31

Key data is taken from the beginning of the hash output.  128 bits (16
bytes) will be used for algorithms with variable-length keys.  For other
algorithms, as many bytes are needed from the beginning of the hash
value as are needed.  If a longer key is needed for some algorithm than
is the output of the hash, the key is extended by computing HASH of the
entire key so far, and appending the resulting bytes (as many as HASH
outputs) to the key.  This process is repeated until enough key material
is available; the key is taken from the beginning of this value.  (Note
that extending the key does not increase its strength or entropy;
however, 128 bits already provides enough entropy.)

6.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 use the new keys and algorithms.

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

This message is the only valid message after key exchange, in addition
to 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.

            vlint32   SSH_MSG_NEWKEYS

7.  Key Re-Exchange

Either side may request re-exchange of keys at any time after the
service request has been accepted (and outside other key exchanges).
The re-exchange is not visible to the service.

Key re-exchange is started by sending a SSH_MSG_KEXINIT packet
(described in Section ``Algorithm Negotiation'').  When this message is
received, a party must respond with its own SSH_MSG_KEXINIT message.
Either party may initiate the re-exchange, but roles are not changed
(i.e., the server remains the server, and the client remains the
client).
Key re-exchange is performed under whatever encryption was in effect
when the exchange was started.  Encryption, compression, and MAC methods
are changed when 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.  It is permissible to change any 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.  The packet sequence
number is not reset.  The session identifier is not changed.

It is recommended that keys be changed after each gigabyte of


Tatu Ylonen <ylo@ssh.fi>                                       [page 15]

INTERNET-DRAFT                                            March 22, 1997
 
transmitted data or after each hour of connection time, whichever comes
sooner.

It is also possible to use the key re-exchange mechanism to switch to
faster algorithms after authentication, or to avoid double processing
for pre-encrypted or pre-authenticated data.  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.

8.  Service Request

After the various authentications, the client requests a service.  The
service is identified by a name.  Service names can contain any non-
control characters.  The name must not be longer than 64 characters.
Service names are case-sensitive.

            vlint32   SSH_MSG_SERVICE_REQUEST
            string    service name

Most server implementations will have a table of services that are
supported, specifying what to do for each service.

If the server rejects the service request, it should send a
SSH_MSG_DISCONNECT message.

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

If the server supports the service (and permits the client to use it),
it responds with

            vlint32   SSH_MSG_SERVICE_ACCEPT

The client is permitted to send further packets without waiting for the
this message; those packets will go to the selected service if the
server accepts the service request.  Message numbers used by services
should be in the area reserved for services (see Section ``Summary of
Message Numbers'').  The transport level will continue to process its
own messages.

The service name is not considered confidential information.  An active
network-level attacker may discover the service name by a man-in-the-
middle attack.  Successful reception of the service accept message will
confirm to the client that the server successfully received the session
key and that the key exchange was not tampered with.

If the negotiated cipher is "none", the client must wait until the
service accept message has been successfully received before sending any
more data.  Otherwise, an attacker could learn this data by modifying
negotiation parameters in such a way that the "none" cipher gets


Tatu Ylonen <ylo@ssh.fi>                                       [page 16]

INTERNET-DRAFT                                            March 22, 1997
 
selected.

9.  Stream-Based Services

It is expected that many services will actually be implemented by
applications that communicate with this protocol through pipes or some
other mechanism that passes a reliable stream of binary bytes.  For
those services, we define a protocol for passing data over this
protocol.  However, it is completely up to the particular service
whether it uses this protocol or something else.

Once a service has been selected, data is transmitted in each direction
asynchronously.  The data is packetized using the following format:

            vlint32   SSH_MSG_STREAM_DATA
            string    data

When the server or client application closes its output (i.e., will not
send more data), the following message is sent to the other side:

            vlint32   SSH_MSG_STREAM_EOF

No data can be sent after sending this message.  Data can still be
transmitted in the other direction.

When either party wishes to terminate communication, it sends
SSH_MSG_STREAM_CLOSE.  Upon receiving that message, a party should
immediately send back SSH_MSG_STREAM_CLOSE unless it has already sent
that.
            vlint32   SSH_MSG_STREAM_CLOSE

After both sending and receiving this message, the communications
channel should be closed.

10.  Additional Messages

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

10.1.  Disconnection Message

            vlint32   SSH_MSG_DISCONNECT
            vlint32   reason code
            string    description

This message causes immediate termination of the connection.  The
description field gives the reason for disconnecting in human-readable
form in English.  The error code gives the reason in a 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_HOST_AUTHENTICATION_FAILED       4


Tatu Ylonen <ylo@ssh.fi>                                       [page 17]

INTERNET-DRAFT                                            March 22, 1997
 
          #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

10.2.  Ignored Data Message

  vlint32   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 ever send them.

10.3.  Debug Message

            vlint32   SSH_MSG_DEBUG
            vlint32   type
            string    message

All implementations must understand this message, but they are allowed
to ignore it.  This message is used to pass information to the other
side which may help debugging problems.  The type may have any of the
following values:

    0 SSH_DEBUG_DEBUG
      The message contains information that may be useful for debugging
      problems; however, it should not normally be shown to the user.
      It is recommended that the data be available to the user for
      debugging purposes if explicitly requested.

    1 SSH_DEBUG_DISPLAY
      The message contains information that should preferably be shown
      to the user regardless of whether debugging information has been
      requested.

The message need not contain a newline.  It is, however, allowed to
consist of multiple lines separated by newlines.

10.4.  Reserved Messages

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

            vlint32   SSH_MSG_UNIMPLEMENTED
            uint32    packet sequence number of rejected message




Tatu Ylonen <ylo@ssh.fi>                                       [page 18]

INTERNET-DRAFT                                            March 22, 1997
 
11.  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_KEXINIT               10
          #define SSH_MSG_NEWKEYS               11
          #define SSH_MSG_SERVICE_REQUEST       12
          #define SSH_MSG_SERVICE_ACCEPT        13

          /* Numbers 15-19 for kex packets.
             Different kex methods may reuse message numbers in
             this range. */
          #define SSH_MSG_KEXDE_HOSTKEY         15
          #define SSH_MSG_KEXDE_SESSIONKEY      16

          /* Numbers 20- are reserved for service types.
             Different service types may reuse the same messages.
             Messages for stream-based services.  Other service types
             may be defined in other documents. */
          #define SSH_MSG_STREAM_DATA           20
          #define SSH_MSG_STREAM_EOF            21
          #define SSH_MSG_STREAM_CLOSE          22

12.  Public Keys and Public Key Infrastructure

This protocol has been designed to be able to operate with almost any
public key format, encoding, and algorithm.

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 (but are not
   required to) contain certificates in addition to keys.

o  Signature and/or encryption algorithms.  Some algorithms may not
   support both encryption and decryption.  Key usage may also be
   restricted by policy statements in e.g. certificates.

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

The following public key formats are currently defined:

          x509                    X.509 certificate
          spki                    IETF SPKI certificate
          ssh-rsa-pkcs1           RSA key with PKCS-1 encodings

Note that the key type is negotiated at the beginning of the key
exchange, and is not included in the key blob itself.


Tatu Ylonen <ylo@ssh.fi>                                       [page 19]

INTERNET-DRAFT                                            March 22, 1997
 
12.1.  x509

X.509 is the most widely used certificate format at the time of this
writing.  However, X.509 has many serious problems, both on a conceptual
and implementation level.  X.509v3 has addressed many of these problems,
and may be more usable than previous versions.

The key blob for an "x509" key blob is an X.509 (v3) certificate in
ASN.1 (DER) format.

12.2.  spki

SPKI (Simple Public Key Infrastructure) is based on the philosophy that
most applications actually require authorization, not identification.
SPKI also addresses naming and policy issues in an explicit and useful
way.

The key blob for an "spki" key blob contains a SPKI key optionally
followed by certificates.

12.3.  ssh-rsa-pkcs1

This key type defines an RSA public key, with (mostly) PKCS compatible
signature and encryption formats.  It supports both signatures and
encryption.

Public keys of this type are represented as follows:

            uint32        number of bits in the modulus
            uint32        number bits in the public exponent
            bytes[n]      exponent, MSB first, n = floor((bits+7)/8)
            uint32        number of bits in the modulus
            bytes[n]      modulus, MSB first, n = floor((bits+7)/8)

It is permissible that there be other data (e.g., certificates)
following this; however, such data is not yet defined.

Note that private key formats are not defined here, and are
implementation-specific.

An encrypted message is formed as follows (this follows PKCS-1 padding
rules).

o  The data to be encrypted is padded into a long integer of the same
   number of bits as the modulus as follows:

              MSB             .  .  .                LSB

               0   2   RND(n bytes)   0   encrypted_data

The RND bytes represent non-zero random bytes.

o  To encrypt, this integer is raised to the public exponent, modulo the


Tatu Ylonen <ylo@ssh.fi>                                       [page 20]

INTERNET-DRAFT                                            March 22, 1997
 
   modulus.

o  The result is converted to a byte string of floor((bits+7)/8) bytes
   (where bits is the number of bits in the modulus), MSB first.  This
   byte string (without any length or terminating characters) is the
   result of the encryption.

A signature is formed as follows.

o  The data to be signed (typically a message digest, but not required
   to be such) is padded into a long integer of the same number of bits
   as the modulus as follows:

              MSB             .  .  .             LSB

               0   1   FF (n bytes)   0   signed_data

o  To sign, this integer is raised to the private exponent, modulo the
   modulus.

o  The result is converted to a byte string of floor((bits+7)/8) bytes
   (where bits is the number of bits in the modulus), MSB first.  This
   byte string (without any length or terminating characters) is the
   signature.  Applications may add other data outside this value.

13.  Address of Author

              Tatu Ylonen
              SSH Communications Security Ltd.
              Tekniikantie 12
              FIN-02150 ESPOO
              Finland

              E-mail: ylo@ssh.fi




















Tatu Ylonen <ylo@ssh.fi>                                       [page 21]
From owner-ietf-ssh@clinet.fi  Sat Mar 29 18:03:31 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id SAA12778;
	Sat, 29 Mar 1997 18:03:30 +0200 (EET)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id SAA16011;
	Sat, 29 Mar 1997 18:03:29 +0200 (EET)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id SAA03264 for ietf-ssh-outgoing; Sat, 29 Mar 1997 18:02:10 +0200 (EET)
Received: from wentzl.cdg.chalmers.se (wentzl.cdg.chalmers.se [129.16.12.9]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id SAA03258 for <ietf-ssh@clinet.fi>; Sat, 29 Mar 1997 18:02:06 +0200 (EET)
Received: from wilfer6.cdg.chalmers.se (wilfer6.cdg.chalmers.se [129.16.12.16])
	by wentzl.cdg.chalmers.se (8.8.5/8.8.5) with ESMTP id RAA17002;
	Sat, 29 Mar 1997 17:02:01 +0100 (MET)
Received: from localhost (jakob@localhost)
	by wilfer6.cdg.chalmers.se (8.8.5/8.8.5) with SMTP id RAA29680;
	Sat, 29 Mar 1997 17:02:00 +0100 (MET)
X-Authentication-Warning: wilfer6.cdg.chalmers.se: jakob owned process doing -bs
Date: Sat, 29 Mar 1997 17:02:00 +0100 (MET)
From: Jakob Schlyter <jakob@cdg.chalmers.se>
To: Tatu Ylonen <ylo@ssh.fi>
cc: ietf-ssh@clinet.fi
Subject: Re: draft-ietf-secsh-connect-01.txt
In-Reply-To: <199703260456.GAA06447@pilari.ssh.fi>
Message-ID: <Pine.SOL.3.95.970329164423.29660B-100000@wilfer6.cdg.chalmers.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1205
Lines: 36

On Wed, 26 Mar 1997, Tatu Ylonen wrote:

> 3.6.  Starting Shell or Command
> 
> Once the session has been set up, a shell or command is started at the
> remote end.  This can happen in any of a number of ways.
> 
>             vlint32   SSH_MSG_SESSION_EXEC_SHELL
>             vlint32   recipient_channel
> 
>             vlint32   SSH_MSG_SESSION_EXEC_COMMAND
>             vlint32   recipient_channel
>             string    command
> 
>             vlint32   SSH_MSG_SESSION_EXEC_PREDEFINED
>             vlint32   recipient_channel
>             vlint32   subsystem_name

Shouldn't this be:

	      vlint32   SSH_MSG_SESSION_EXEC_PREDEFINED
	      vlint32   recipient_channel
	      string    subsystem_name

Maybe subsystem_name should be either a well-known subsystem_name or
something like "local_subsystem_name@domain" - much like the naming of
authentication methods in the SSH authentication protcol.

/Jakob

--
Jakob Schlyter <jakob@cdg.chalmers.se>       Networker
Phone:  +46 31-772 5919                      Computer Communications Group
Fax:    +46 31-772 5922                      Chalmers University of Technology
http://www.cdg.chalmers.se/~jakob/           S-412 96 Goteborg, Sweden

From owner-ietf-ssh@clinet.fi  Sun Mar 30 06:04:00 1997
Return-Path: <owner-ietf-ssh@clinet.fi>
Received: from muuri.ssh.fi (muuri.ssh.fi [192.168.2.254])
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) with ESMTP id GAA16656;
	Sun, 30 Mar 1997 06:04:00 +0300 (EET DST)
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id GAA17052;
	Sun, 30 Mar 1997 06:03:58 +0300 (EET DST)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id GAA06211 for ietf-ssh-outgoing; Sun, 30 Mar 1997 06:02:42 +0300 (EET DST)
Received: from muuri.ssh.fi (ssh.fi [194.100.44.97]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id GAA06204 for <ietf-ssh@clinet.fi>; Sun, 30 Mar 1997 06:02:39 +0300 (EET DST)
Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1])
	by muuri.ssh.fi (8.8.5/8.8.5/EPIPE-1.10) with ESMTP id GAA17047;
	Sun, 30 Mar 1997 06:02:37 +0300 (EET DST)
Received: (from ylo@localhost)
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) id GAA16652;
	Sun, 30 Mar 1997 06:02:36 +0300 (EET DST)
Date: Sun, 30 Mar 1997 06:02:36 +0300 (EET DST)
Message-Id: <199703300302.GAA16652@pilari.ssh.fi>
From: Tatu Ylonen <ylo@ssh.fi>
To: Jakob Schlyter <jakob@cdg.chalmers.se>
CC: ietf-ssh@clinet.fi
Subject: Re: draft-ietf-secsh-connect-01.txt
In-Reply-To: <Pine.SOL.3.95.970329164423.29660B-100000@wilfer6.cdg.chalmers.se>
References: <199703260456.GAA06447@pilari.ssh.fi>
	<Pine.SOL.3.95.970329164423.29660B-100000@wilfer6.cdg.chalmers.se>
Organization: SSH Communications Security, Finland
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 404
Lines: 13

> Shouldn't this be:
> 
> 	      vlint32   SSH_MSG_SESSION_EXEC_PREDEFINED
> 	      vlint32   recipient_channel
> 	      string    subsystem_name
> 
> Maybe subsystem_name should be either a well-known subsystem_name or
> something like "local_subsystem_name@domain" - much like the naming of
> authentication methods in the SSH authentication protcol.

You're right...  I changed it that way.

    Tatu
