From owner-ietf-ssh@clinet.fi  Wed Apr  2 15:56:44 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 PAA08918;
	Wed, 2 Apr 1997 15:56:43 +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 PAA27762;
	Wed, 2 Apr 1997 15:56:42 +0300 (EET DST)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id PAA29830 for ietf-ssh-outgoing; Wed, 2 Apr 1997 15:53:11 +0300 (EET DST)
Received: from mailgw.liu.se (mailgw.liu.se [130.236.1.10]) by hauki.clinet.fi (8.8.5/8.6.4) with SMTP id PAA29127; Wed, 2 Apr 1997 15:44:07 +0300 (EET DST)
Received: from linda.lidac.liu.se (linda.lidac.liu.se [130.236.10.10]) by mailgw.liu.se (8.6.9/8.6.9) with ESMTP id OAA21292; Wed, 2 Apr 1997 14:44:02 +0200
Received: from [130.236.95.12] ([130.236.95.12])
          by linda.lidac.liu.se (8.8.4/8.8.4) with SMTP
	  id OAA20622; Wed, 2 Apr 1997 14:43:58 +0200 (MET DST)
X-Sender: mawidlid@linda.lidac.liu.se (Unverified)
Message-Id: <v01530504af67f7ac49c9@[130.236.95.12]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 2 Apr 1997 13:47:01 +0200
To: ssh@clinet.fi, ietf-ssh@clinet.fi
From: MarWi@unit.liu.se (Martin Widin)
Subject: draft-ietf-secsh-transport-00.txt
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 17022
Lines: 413

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>                                        =C4page 1=C5

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>                                        =C4page 2=C5

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>                                        =C4page 3=C5

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=C4n=C5, 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>                                        =C4page 4=C5

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>                                        =C4page 5=C5

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>                                        =C4page 6=C5

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


From owner-ietf-ssh@clinet.fi  Wed Apr  2 15:56:41 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 PAA08904;
	Wed, 2 Apr 1997 15:56:41 +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 PAA27756;
	Wed, 2 Apr 1997 15:56:40 +0300 (EET DST)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id PAA29850 for ietf-ssh-outgoing; Wed, 2 Apr 1997 15:53:17 +0300 (EET DST)
Received: from mailgw.liu.se (mailgw.liu.se [130.236.1.10]) by hauki.clinet.fi (8.8.5/8.6.4) with SMTP id PAA29128; Wed, 2 Apr 1997 15:44:07 +0300 (EET DST)
Received: from linda.lidac.liu.se (linda.lidac.liu.se [130.236.10.10]) by mailgw.liu.se (8.6.9/8.6.9) with ESMTP id OAA21297; Wed, 2 Apr 1997 14:44:06 +0200
Received: from [130.236.95.12] ([130.236.95.12])
          by linda.lidac.liu.se (8.8.4/8.8.4) with SMTP
	  id OAA20597; Wed, 2 Apr 1997 14:44:03 +0200 (MET DST)
X-Sender: mawidlid@linda.lidac.liu.se (Unverified)
Message-Id: <v01530503af67f7ab4998@[130.236.95.12]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 2 Apr 1997 13:47:05 +0200
To: ssh@clinet.fi, ietf-ssh@clinet.fi
From: MarWi@unit.liu.se (Martin Widin)
Subject: draft-ietf-secsh-transport-00.txt
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 16998
Lines: 379

          blowfish-cbc     optional          Blowfish in CBC mode

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


Tatu Ylonen <ylo@ssh.fi>                                        =C4page 7=C5

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.

=46or 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 =3D 16)
          hmac-sha    optional         HMAC-SHA (length =3D 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>                                        =C4page 8=C5

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=C416=C5  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>                                        =C4page 9=C5

INTERNET-DRAFT                                            March 22, 1997

            boolean   first_kex_packet_follows
            byte=C44=C5   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>                                       =C4page 10=C5

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>                                       =C4page 11=C5

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

=46irst, 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>                                       =C4page 12=C5

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>                                       =C4page 13=C5

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


From owner-ietf-ssh@clinet.fi  Wed Apr  2 15:56: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 PAA08910;
	Wed, 2 Apr 1997 15:56:42 +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 PAA27761;
	Wed, 2 Apr 1997 15:56:41 +0300 (EET DST)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id PAA29847 for ietf-ssh-outgoing; Wed, 2 Apr 1997 15:53:14 +0300 (EET DST)
Received: from mailgw.liu.se (mailgw.liu.se [130.236.1.10]) by hauki.clinet.fi (8.8.5/8.6.4) with SMTP id PAA29134; Wed, 2 Apr 1997 15:44:11 +0300 (EET DST)
Received: from linda.lidac.liu.se (linda.lidac.liu.se [130.236.10.10]) by mailgw.liu.se (8.6.9/8.6.9) with ESMTP id OAA21301; Wed, 2 Apr 1997 14:44:10 +0200
Received: from [130.236.95.12] ([130.236.95.12])
          by linda.lidac.liu.se (8.8.4/8.8.4) with SMTP
	  id OAA20585; Wed, 2 Apr 1997 14:44:07 +0200 (MET DST)
X-Sender: mawidlid@linda.lidac.liu.se (Unverified)
Message-Id: <v01530502af67f7aa4964@[130.236.95.12]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 2 Apr 1997 13:47:09 +0200
To: ssh@clinet.fi, ietf-ssh@clinet.fi
From: MarWi@unit.liu.se (Martin Widin)
Subject: draft-ietf-secsh-transport-00.txt
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 17053
Lines: 456

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>                                       =C4page 14=C5

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>                                       =C4page 15=C5

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>                                       =C4page 16=C5

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:

          =A7define SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT      1
          =A7define SSH_DISCONNECT_PROTOCOL_ERROR                   2
          =A7define SSH_DISCONNECT_KEY_EXCHANGE_FAILED              3
          =A7define SSH_DISCONNECT_HOST_AUTHENTICATION_FAILED       4


Tatu Ylonen <ylo@ssh.fi>                                       =C4page 17=C5

INTERNET-DRAFT                                            March 22, 1997

          =A7define SSH_DISCONNECT_MAC_ERROR                        5
          =A7define SSH_DISCONNECT_COMPRESSION_ERROR                6
          =A7define SSH_DISCONNECT_SERVICE_NOT_AVAILABLE            7
          =A7define SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED   8
          =A7define SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE          9
          =A7define SSH_DISCONNECT_CONNECTION_LOST                 10
          =A7define 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>                                       =C4page 18=C5

INTERNET-DRAFT                                            March 22, 1997

11.  Summary of Message Numbers

The following message numbers have been defined in this protocol.

          =A7define SSH_MSG_DISCONNECT             1
          =A7define SSH_MSG_IGNORE                 2
          =A7define SSH_MSG_UNIMPLEMENTED          3
          =A7define SSH_MSG_DEBUG                  4
          =A7define SSH_MSG_KEXINIT               10
          =A7define SSH_MSG_NEWKEYS               11
          =A7define SSH_MSG_SERVICE_REQUEST       12
          =A7define SSH_MSG_SERVICE_ACCEPT        13

          /* Numbers 15-19 for kex packets.
             Different kex methods may reuse message numbers in
             this range. */
          =A7define SSH_MSG_KEXDE_HOSTKEY         15
          =A7define 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. */
          =A7define SSH_MSG_STREAM_DATA           20
          =A7define SSH_MSG_STREAM_EOF            21
          =A7define 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>                                       =C4page 19=C5

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=C4n=C5      exponent, MSB first, n =3D floor((bits+7)/8)
            uint32        number of bits in the modulus
            bytes=C4n=C5      modulus, MSB first, n =3D 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>                                       =C4page 20=C5

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>                                       =C4page 21=C5


From owner-ietf-ssh@clinet.fi  Fri Apr  4 18:28: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 SAA19582;
	Fri, 4 Apr 1997 18:28:45 +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 SAA05003;
	Fri, 4 Apr 1997 18:28:44 +0300 (EET DST)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id SAA08356 for ietf-ssh-outgoing; Fri, 4 Apr 1997 18:13:59 +0300 (EET DST)
Received: from nic.carlstedt.se (nic.carlstedt.se [193.12.107.10]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id SAA08289 for <ietf-ssh@clinet.fi>; Fri, 4 Apr 1997 18:13:23 +0300 (EET DST)
Received: from giraf.carlstedt.se (giraf.carlstedt.se [172.16.1.10]) by nic.carlstedt.se (8.8.5/8.8.1) with ESMTP id RAA24188 for <ietf-ssh@clinet.fi>; Fri, 4 Apr 1997 17:13:15 +0200 (MET DST)
Received: from carlstedt.se (giraf.carlstedt.se [172.16.1.10]) by giraf.carlstedt.se (8.8.5/8.8.3) with ESMTP id RAA13634 for <ietf-ssh@clinet.fi>; Fri, 4 Apr 1997 17:13:11 +0200 (MET DST)
Message-Id: <199704041513.RAA13634@giraf.carlstedt.se>
Date: Fri, 4 Apr 1997 17:13:09 +0200 (MET DST)
From: Martin Forssen <maf@carlstedt.se>
Subject: Securid advanced operations
To: ietf-ssh@clinet.fi
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 397
Lines: 9

The current userauth draft does not support any other securid
authetification than the simple case that the user supplies the code.
Securid can sometimes require the next token code as well. Or it can be
in new-pin mode which involves multiple interactions with the user. Are
there any good reasons why the protocol doesn't support these? Or have I
missed something in the specifications?

	/MaF

From owner-ietf-ssh@clinet.fi  Fri Apr  4 19:32:05 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 TAA20048;
	Fri, 4 Apr 1997 19:32:01 +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 TAA05153;
	Fri, 4 Apr 1997 19:32:00 +0300 (EET DST)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id TAA12907 for ietf-ssh-outgoing; Fri, 4 Apr 1997 19:30:06 +0300 (EET DST)
Received: from hermes.achilles.net (hermes.achilles.net [198.53.206.3]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id TAA12887 for <ietf-ssh@clinet.fi>; Fri, 4 Apr 1997 19:29:55 +0300 (EET DST)
Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [205.233.54.146]) by hermes.achilles.net (8.7.5/8.7.3) with ESMTP id LAA07139; Fri, 4 Apr 1997 11:30:28 -0500
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 LAA03864; Fri, 4 Apr 1997 11:17:41 -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 LAA00435; Fri, 4 Apr 1997 11:28:29 -0500 (EST)
Message-Id: <199704041628.LAA00435@amaterasu.sandelman.ottawa.on.ca>
To: Martin Forssen <maf@carlstedt.se>
CC: ietf-ssh@clinet.fi
Subject: Re: Securid advanced operations 
In-reply-to: Your message of "Fri, 04 Apr 1997 17:13:09 +0200."
             <199704041513.RAA13634@giraf.carlstedt.se> 
Date: Fri, 04 Apr 1997 11:28:18 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1415
Lines: 35

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


T>>>>> "Martin" == Martin Forssen <maf@carlstedt.se> writes:
    Martin> he current userauth draft does not support any other
    Martin> securid authetification than the simple case that the user
    Martin> supplies the code.  Securid can sometimes require the next
    Martin> token code as well. Or it can be in new-pin mode which

  The simple reason is that these modes are not well understood by
many developers... I went through this realization about how the
new-pin mode and the reauth mode worked only after discussing securid
integration to a product with a securid SE.

  One technical reason, is that the protocol is client driven. If it
were more server driven, then the server could keep sending prompts
(instead of just accepts/denies) to the user until it was satisfied
with the response.
  
   :!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

iQB1AwUBM0UsGKZpLyXYhL+BAQGztAL/QGVSTwtXXn08AxwKhs/B4ENxbNmedVA0
1cdlYKBsBmgaWql7g1dB5feI9fzWi96dJS3OYJOrsZsAGevacSvACKIcgqXzyJDz
cxJlzo5uv9Z6fDRbF0ewc/8OIsXf9vC2
=WDJR
-----END PGP SIGNATURE-----
From owner-ietf-ssh@clinet.fi  Sat Apr  5 19:36:06 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 TAA01889;
	Sat, 5 Apr 1997 19:36:05 +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 TAA09363;
	Sat, 5 Apr 1997 19:36:05 +0300 (EET DST)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id TAA24731 for ietf-ssh-outgoing; Sat, 5 Apr 1997 19:27:53 +0300 (EET DST)
Received: from hermes.achilles.net (hermes.achilles.net [198.53.206.3]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id TAA24717 for <ietf-ssh@clinet.fi>; Sat, 5 Apr 1997 19:27:35 +0300 (EET DST)
Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [205.233.54.146]) by hermes.achilles.net (8.7.5/8.7.3) with ESMTP id LAA19989; Sat, 5 Apr 1997 11:28:28 -0500
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 LAA07327; Sat, 5 Apr 1997 11:15:24 -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 LAA01398; Sat, 5 Apr 1997 11:25:44 -0500 (EST)
Message-Id: <199704051625.LAA01398@amaterasu.sandelman.ottawa.on.ca>
To: Tatu Ylonen <ylo@ssh.fi>, ietf-ssh@clinet.fi
Subject: Re: Securid advanced operations 
In-reply-to: Your message of "Sat, 05 Apr 1997 11:29:25 +0300."
             <199704050829.LAA28580@pilari.ssh.fi> 
Date: Sat, 05 Apr 1997 11:25:39 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2089
Lines: 50

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


>>>>> "Tatu" == Tatu Ylonen <ylo@ssh.fi> writes:
    Tatu> Can you give concrete suggestions how it should be changed
    Tatu> to be better suited for most purposes?

  I think the server should say:

  Please authenticate with the following item: the client can decline
to do so. The server can then go onwards and ask for other types if it
desires. 

  The order is server chosen, not client chosen. This gets around
possibly strange things where you need to pass kerberos tickets to get
access to ~/.ssh, but then want to do RSA authentication. HOWEVER, if
there were a firewall in front of the intended target host, then you
might want to do RSA authentication (for the firewall), and then pass
the ticket to the intended target host, and *then* do password
authentication (or RSA, again).

  The server always gives a positive or negative response. A positive
response does not constitute the end of authentication.
  For interactive type tokens, the server should be able to do things
like:
	send the following string to the user as a prompt, tell me the response
	
  The strings could be numbered (so the client can, if they understand
things, e.g. s/key or opie do the computation itself), but any strings
that are not understood are passed to a human. The client declining to
authenticate like that if it can't get a human to cooperate.

  In the firewall proxy case, the transport layer *will* have to cope
with certificates, but I think we can deal with that a bit later.

   :!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

iQB1AwUBM0Z896ZpLyXYhL+BAQHuuAL9FzazsuRYe/w9uxyCBdUkkmiH0MwpW88I
fnGsftjj2F0Q4CuuOp3knUMwjLo9SddlAHlKa+9RvQ1PFJp85+z2QaVB1vBD1Vkn
DR3pf18zus5aPo+J0u+jqWRpx0zJvO9H
=BQv3
-----END PGP SIGNATURE-----
From owner-ietf-ssh@clinet.fi  Sat Apr  5 19:52:42 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 TAA02335;
	Sat, 5 Apr 1997 19:52:41 +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 TAA09391;
	Sat, 5 Apr 1997 19:52:41 +0300 (EET DST)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id TAA25685 for ietf-ssh-outgoing; Sat, 5 Apr 1997 19:51:47 +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 TAA25677 for <ietf-ssh@clinet.fi>; Sat, 5 Apr 1997 19:51:45 +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 TAA09387;
	Sat, 5 Apr 1997 19:51:45 +0300 (EET DST)
Received: (from ylo@localhost)
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) id TAA01993;
	Sat, 5 Apr 1997 19:51:43 +0300 (EET DST)
Date: Sat, 5 Apr 1997 19:51:43 +0300 (EET DST)
Message-Id: <199704051651.TAA01993@pilari.ssh.fi>
From: Tatu Ylonen <ylo@ssh.fi>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
CC: ietf-ssh@clinet.fi
Subject: Re: Securid advanced operations 
In-Reply-To: <199704051625.LAA01398@amaterasu.sandelman.ottawa.on.ca>
References: <199704050829.LAA28580@pilari.ssh.fi>
	<199704051625.LAA01398@amaterasu.sandelman.ottawa.on.ca>
Organization: SSH Communications Security, Finland
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3355
Lines: 74

>   Please authenticate with the following item: the client can decline
> to do so. The server can then go onwards and ask for other types if it
> desires. 

It can already do this: it just lists one authentication method as the
possible continuation.

>   The order is server chosen, not client chosen. This gets around
> possibly strange things where you need to pass kerberos tickets to get
> access to ~/.ssh, but then want to do RSA authentication. HOWEVER, if
> there were a firewall in front of the intended target host, then you
> might want to do RSA authentication (for the firewall), and then pass
> the ticket to the intended target host, and *then* do password
> authentication (or RSA, again).

As far as I understand, the server can already do it with the current
proposal.

>   The server always gives a positive or negative response. A positive
> response does not constitute the end of authentication.

One could reasonably argue that the server should give some indication
when one part of authentication has been successfully performed.

Can you think of benefits that this would give?

>   For interactive type tokens, the server should be able to do things
> like:
> 	send the following string to the user as a prompt, tell me the response

This doesn't work very beautifully in a windows environment, unless
you do all authentication within the terminal window.  The current
implementation asks for the password in a separate window, but nothing
would prevent asking it in the terminal window itself.

>   The strings could be numbered (so the client can, if they understand
> things, e.g. s/key or opie do the computation itself), but any strings
> that are not understood are passed to a human. The client declining to
> authenticate like that if it can't get a human to cooperate.

Note that I cannot think of a reasonable way to build a clean user
interface to do this, unless everything happens in the plain terminal
window.

One issue is what kind of user interface styles do we want to
support.  This affects the protocol quite a bit.  Currently I've
chosen to have authentication not go through an ascii-based terminal
interface.  This may or may not be the right choice.

Reasons in favor or this choice:
  - can provide specific user interface for each method (e.g., some
    one-time password methods may involve a challenge passed to a
    hardware token via optical reading)
  - it is easy to localize (i.e., translate to different languages)
    the user interface
  - new methods can be added very easily e.g. as DLLs
  - can more easily extend to future applications where you don't
    actually start a terminal session after authentication, but
    instead do something different (e.g., transfer files).  In these
    cases you might not have a terminal window at all.

Reasons against this choice:
  - need special support for each new method on the client side
  - cannot use standard login program (in many cases, cannot use
    anyway because of X11, port forwarding, e.g. problems, and you
    don't want to enable these before the user has been authenticated)

>   In the firewall proxy case, the transport layer *will* have to cope
> with certificates, but I think we can deal with that a bit later.

Yes.  The idea is that the key blobs passed in the transport protocol
can contain certificates.

    Tatu
From owner-ietf-ssh@clinet.fi  Sat Apr  5 22:35:41 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 WAA11397;
	Sat, 5 Apr 1997 22:35:41 +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 WAA09767;
	Sat, 5 Apr 1997 22:35:41 +0300 (EET DST)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id WAA01544 for ietf-ssh-outgoing; Sat, 5 Apr 1997 22:33:16 +0300 (EET DST)
Received: from hermes.achilles.net (hermes.achilles.net [198.53.206.3]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id WAA01527 for <ietf-ssh@clinet.fi>; Sat, 5 Apr 1997 22:33:03 +0300 (EET DST)
Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [205.233.54.146]) by hermes.achilles.net (8.7.5/8.7.3) with ESMTP id OAA27064 for <ietf-ssh@clinet.fi>; Sat, 5 Apr 1997 14:34:29 -0500
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 OAA07770 for <ietf-ssh@clinet.fi>; Sat, 5 Apr 1997 14:20:26 -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 OAA01613 for <ietf-ssh@clinet.fi>; Sat, 5 Apr 1997 14:30:42 -0500 (EST)
Message-Id: <199704051930.OAA01613@amaterasu.sandelman.ottawa.on.ca>
To: ietf-ssh@clinet.fi
Subject: Re: Securid advanced operations 
In-reply-to: Your message of "Sat, 05 Apr 1997 19:51:43 +0300."
             <199704051651.TAA01993@pilari.ssh.fi> 
Date: Sat, 05 Apr 1997 14:30:40 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2414
Lines: 64

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


>>>>> "Tatu" == Tatu Ylonen <ylo@ssh.fi> writes:
    Tatu> It can already do this: it just lists one authentication
    Tatu> method as the possible continuation.

  I didn't get this from my first reading. I believe that you agreed
to change this though

    Tatu> As far as I understand, the server can already do it with
    Tatu> the current proposal.

  Can the *client*? Putting the smarts in the server just makes sense
to me. 

    Tatu> One could reasonably argue that the server should give some
    Tatu> indication when one part of authentication has been
    Tatu> successfully performed.

    Tatu> Can you think of benefits that this would give?

  Yes. It allows the client to give know that the authentication
succeeded, and not simply give up. 

    >> For interactive type tokens, the server should be able to do
    >> things like: send the following string to the user as a prompt,
    >> tell me the response

    Tatu> This doesn't work very beautifully in a windows environment,
    Tatu> unless you do all authentication within the terminal window.

  I don't see the challenge in bring up a dialogue to prompt the user.

    Tatu> Note that I cannot think of a reasonable way to build a
    Tatu> clean user interface to do this, unless everything happens
    Tatu> in the plain terminal window.

  The server can give the client a notion of whether the entry should
echo. Beyond that, I'm not sure what additional information is really
required. 
 
    Tatu> Reasons against this choice: - need special support for each
    Tatu> new method on the client side - cannot use standard login

  There needs to be a generic challenge/response system. That way you
don't need to augment the clients each time. That is expensive to do
in terms of both programming, logistics and training.

   :!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

iQB1AwUBM0anxaZpLyXYhL+BAQHIqwL+I6otG+HkI0BAg1DtQXrXyfTM4Oip5vUm
COBIBmqg7h+ueWaFMzmq776CGlKENrvS46RSm0a8mA71GipjQ2g8qNlk/wjUJiro
r0Z9SJUlNjEiCM7bCnEbet8seILEH/4L
=xoPF
-----END PGP SIGNATURE-----
From owner-ietf-ssh@clinet.fi  Fri Apr 11 20:32:14 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 UAA16623;
	Fri, 11 Apr 1997 20:32:14 +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 UAA00667;
	Fri, 11 Apr 1997 20:32:13 +0300 (EET DST)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id UAA11600 for ietf-ssh-outgoing; Fri, 11 Apr 1997 20:23:40 +0300 (EET DST)
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 UAA11575 for <ietf-ssh@clinet.fi>; Fri, 11 Apr 1997 20:23:25 +0300 (EET DST)
Received: (from morgan@localhost) by parc.power.net (8.7.1/8.7.1) id JAA27512; Fri, 11 Apr 1997 09:25:06 -0700
From: "Andrew G. Morgan" <morgan@parc.power.net>
Message-Id: <199704111625.JAA27512@parc.power.net>
Subject: Re: draft-ietf-secsh-userauth-01.txt (fwd)
To: pam-list@redhat.com (Linux-PAM)
Date: Fri, 11 Apr 1997 09:25:06 -0700 (PDT)
Cc: ietf-ssh@clinet.fi
Content-Type: text
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 4863
Lines: 135

Hi,

I guess I sent this to Tatu a long while back.  I've had no acknowledgment
so I suppose it got drowned in his mail folder...  In case anyone has any
further comments, I am posting it to both the PAM and the itef-secsh
lists...

Cheers

Andrew

I wrote:
> Subject: Re: draft-ietf-secsh-userauth-01.txt (fwd)
> To: ylo@ssh.fi (Tatu Ylonen)
> Date: Sat, 29 Mar 1997 13:15:45 -0800 (PST)
> 
> Hi,
> 
> Tatu Ylonen wrote:
> > I'm not very very familiar with the way PAM works.
> 
> I maintain Linux-PAM so I guess I'm in a position to clarify things(!)
> 
> I've had a chance to read over your Draft RFC and I see that your
> User-authentication protocols are specifically trying to address things that
> PAM tries to abstract: I am sure that it will be possible to add 'PAM' style
> authentication to the list of supported protocols...
> 
> Aside from "how to write a PAM application", which is what the source code I
> pointed to in my previous post was all about.  To implement PAM you will
> have to provide a dummied down "protocol"... One that implicitly assumes
> that the server can be trusted.  [This is on the level of the simple
> Password-Style Authentication (2.4) in the posted draft.]
> 
> Overview:
> 
> PAM separates the job of authentication from the task of writing an
> application.  "modules" (dynamically loaded object code) are loaded to
> perform the authentication tasks.
> 
> Generally, authentication requires some participation on the part of the
> client (the user has to read requests and type inputs). PAM (currently)
> limits such participation to one of four types:
> 
> 	Echoed input     -  for things like usernames
> 	Non-echoed input -  for passwords
> 	Text messages    -  for server -> client (user) informative messages
> 	Error messages   -  for server -> client (user) errors/warnings
> 
> The way things would work with sshd is that slogin would request PAM
> authentication and sshd would go into a block of code like this:
> 
> 	pam_start()
> 	pam_authenticate()
> 	....
> 	pam_end()
> 
> The pam_authenticate() function is the part that calls the module
> authentication code...
> 
> One of the arguments to pam_start() is a sshd-specific "conversation"
> function.  Should the PAM (module) need to send messages or obtain input
> from the client, it is this conversation() function that it will use to
> do it.
> 
> TODO (regarding the protocols):
> 
> I think to get sshd/slogin to interact in a way that will successfully work
> with PAM we have to define some new SSH_MSG_'s:
> 
> The client (C) would do something like:
> 
> C>	vlint32	SSH_MSG_USERAUTH_REQUEST
> 	string	user
> 	string	service
> 	string  "PAM"
> 
> The server (S) would then jump to the above code and any module that needed
> to talk to the client would use the conversation() function to send things
> like:
> 
> S>	vlint32	SSH_MSG_USERAUTH_PAM_MESG
> 	string	number-of-requests	[eg. "3"]
> 	string  first-request-type	[eg. "text"]
> 	string  first-string		[eg. "Please enter the following.."]
> 	string  second-request-type	[eg. "echo" - prompt with echo]
> 	string  second-string		[eg. "Username: "]
> 	string	third-request-type	[eg. "blind" - prompt no echo]
> 	string	third-string		[eg. "Password: "]
> 
> [Lets define the remaining request-type as "error".] The client would
> display the text and obtain the required input(s). It would then send the
> following to the server:
> 
> C>	vlint32 SSH_MSG_USERAUTH_PAM_RESP
> 	string  number-of-responses	[eg. "2"]
> 	string	first-response-string	[eg. "morgan"]
> 	string	second-response-string	[eg. "sorry-its-a-secret"]
> 
> In general, there may be any number of these MESG-RESP exchanges. ["0" is a
> valid number-of-responses].
> 
> If either side wishes to terminate the PAM authentication process it can
> send
> 
> 	vlint32 SSH_MSG_USERAUTH_PAM_ABORT
> 
> And at that point I guess you'll be able to define how the authentication
> will continue..
> 
> I hope this is enough to get you oriented to what and how PAM could work
> with ssh..
> 
> > 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.
> 
> Feel free to either use the above example, or email me for further help/text
> etc. Ssh is something I _personally_ really want to see working with PAM!
> 
> Best wishes
> 
> 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 ]
> 


-- 
               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  Mon Apr 14 04:28:20 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 EAA11046;
	Mon, 14 Apr 1997 04:28:20 +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 EAA07798;
	Mon, 14 Apr 1997 04:28:19 +0300 (EET DST)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id EAA01145 for ietf-ssh-outgoing; Mon, 14 Apr 1997 04:25:28 +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 EAA01140 for <ietf-ssh@clinet.fi>; Mon, 14 Apr 1997 04:25:25 +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 EAA07786;
	Mon, 14 Apr 1997 04:25:25 +0300 (EET DST)
Received: (from ylo@localhost)
	by pilari.ssh.fi (8.8.5/8.8.5/1.9) id EAA11034;
	Mon, 14 Apr 1997 04:25:22 +0300 (EET DST)
Date: Mon, 14 Apr 1997 04:25:22 +0300 (EET DST)
Message-Id: <199704140125.EAA11034@pilari.ssh.fi>
From: Tatu Ylonen <ylo@ssh.fi>
To: "Andrew G. Morgan" <morgan@parc.power.net>
CC: ietf-ssh@clinet.fi, pam-list@redhat.com
Subject: Re: draft-ietf-secsh-userauth-01.txt (fwd)
In-Reply-To: <199704111625.JAA27512@parc.power.net>
References: <199704111625.JAA27512@parc.power.net>
Organization: SSH Communications Security, Finland
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 403
Lines: 10

> I guess I sent this to Tatu a long while back.  I've had no acknowledgment
> so I suppose it got drowned in his mail folder...  In case anyone has any
> further comments, I am posting it to both the PAM and the itef-secsh
> lists...

Sorry about the delay.  Yes, it's still waiting for processing in my
mailbox.  (I was at the IETF last week, and have hardly read my mail
during that time.)

    Tatu
From owner-ietf-ssh@clinet.fi  Tue Apr 22 04:08:54 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 EAA04418;
	Tue, 22 Apr 1997 04:08:53 +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 EAA06842;
	Tue, 22 Apr 1997 04:08:47 +0300 (EET DST)
Received: (daemon@localhost) by hauki.clinet.fi (8.8.5/8.6.4) id EAA05640 for ietf-ssh-outgoing; Tue, 22 Apr 1997 04:04:30 +0300 (EET DST)
Received: from alcor.concordia.ca (root@alcor.Concordia.CA [132.205.7.51]) by hauki.clinet.fi (8.8.5/8.6.4) with ESMTP id EAA05634 for <ietf-ssh@clinet.fi>; Tue, 22 Apr 1997 04:04:21 +0300 (EET DST)
Received: from localhost (anne@localhost [127.0.0.1])
	by alcor.concordia.ca (8.8.5/8.8.5) with SMTP id VAA15394
	for ietf-ssh@clinet.fi; Mon, 21 Apr 1997 21:04:03 -0400 (EDT)
Message-Id: <199704220104.VAA15394@alcor.concordia.ca>
X-Authentication-Warning: alcor.concordia.ca: anne@localhost [127.0.0.1] didn't use HELO protocol
To: ietf-ssh@clinet.fi
Subject: Comments on draft-ietf-secsh-userauth-00.txt
Reply-To: Anne Bennett <anne@alcor.concordia.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Mon, 21 Apr 97 21:04:02 -0400
From: Anne Bennett <anne@alcor.concordia.ca>
X-Mts: smtp
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 28547
Lines: 692


Appended are my comments on the userauth-00 draft, which is the one I
picked up a few days before the IETF.  I noticed some comments that
purported to be about userauth-01, but if 01 is out, I missed the
announcement.  I hope the appended is useful anyway.


Anne.
-- 
Ms. Anne Bennett, Computing Services, Concordia University, Montreal H3G 1M8
anne@alcor.concordia.ca                                       (514) 848-7606
----------------------------------------------------------------------------

I've read the authentication draft 00 very carefully, and I have lots
of question and comments.

I must say that overall I am very impressed with this draft; it looks
more like a "02" than a "00"! :-)  I found it mostly quite clear.  I
should add that I am reading it from the point of view of a
well-informed sysadmin who wants to understand the protocol; I really
cannot comment on the cryptographic or algorithmic aspects of the
protocol.  Also, you should be warned that I'm a very picky
proofreader; I hope you find this more useful than annoying.


< Abstract
< 
< This documents describes the SSH authentication protocol.  It is used to
< prove that the client is authorized access the requested service with
                                     ^to

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

I made the mistake of reading the authorization document *before*
reading the transport document, and found myself quite puzzled by many
of the references.  I think it would be worthwhile to link the two
documents more clearly, both in the abstract and in the introduction.
That might save a lot of people the grief I went through trying to
figure out the cryptic data types. :-)  I realize that the "transport"
(session?) layer may change to a more TLS-like protocol, but my
comments still stand: we need to tie in this document more clearly
with the document that describes the underlying layer.

I propose the following additional paragraph for the abstract:

  The SSH authentication protocol uses the transport protocol
  described in RFC XXX.

(Are we being inaccurate in describing the secsh-transport protocol as
"transport"?  I never can remember the seven layers...)

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

I propose adding the following to the above paragraph:

  The SSH transport layer protocol is described in RFC XXX, which
  explains the data types "vlint32" and "string", as well as the
  meaning of HASH, and the concept of a "packet" in this protocol.
  It also discusses the generation of the session identifier and the
  concept of "service".


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

Style/clarification (and minor change at end of last sentence):

  Authentication works as follows: the client declares the
  service name, and the user name under which to access this
  service.  The server responds to this declaration with a set
  of acceptable authentication methods for the given
  user/service combination.  The client then sends an
  authentication request using one of the methods listed by the
  server.  This dialog continues until access has been granted,
  or until either the client or the server disconnects.

< When this protocol starts, it receives the session identifier from the
       ^^^^ the authentication protocol
< 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.

Style:

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

  When the server returns a failure response to the client, it
  also lists a set of authentication methods which the client
  may use to continue the dialog, thus [...]

A more general question: I'm not sure I understand why you overload
"failure" to mean both "more authentication required" and
"authentication denied, go away".  My initial response was great
puzzlement, since the two situations "feel" different to me, but when
I thought it over, I could not easily come up with a situation where
it would be important to differentiate between them.  It may not
belong here in the draft, but I'd be interested in understanding your
reasoning for this choice of approach.

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

Two comments about the above paragraph:
 1) I'd strongly recommend you tighten up the specification of the
    names; specify the permitted set of characters instead of stating
    "no control characters", and specify whether or not there is a
    maximum length, and if so what it is.
 2) The last sentence fragment should have its "misplaced only" fixed,
    and should read:
      at signs can be used only for the purpose described above.

< The following methods are predefined:

Does that mean that the servers and clients MUST implement them all in
order to comply to the proposed standard?  If not, is there a
mandatory subset?

< none                 Checks if no authentication ok
< password             Knowledge of password

Unix-style /etc/passwd encrypted with crypt?  Or implementation
dependent?  Do you mean any reusable 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

I suspect that above you mean Unix "r-command"-style authentication;
we should try to come up with a clearer one-line description to avoid
keeping readers in suspense until they get to the relevant subsection.
:-)  Nothing comes to mind offhand, unfortunately.

< kerberos4            Kerberos v4 authentication
< kerberos5            Kerberos v5 authentication
< kerberos-afs         AFS Kerberos authentication

In all cases above, I think it would be very helpful to put in
parentheses the RFC which describes the authentication method (where
such RFCs exist).

< 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
                                                ^ failed?
< client may perform (the recommended limit is 20 attempts).
                    ^ in a single session?  Over a given time period?

We should add what happens when this threshold is exceeded.


< 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

I'd tend to use "username" instead of "user", but that may be a matter
of preference.  Again, permitted character sets (if appropriate), and
whether or not there are length limitations on the strings above,
should be mentioned.

It's not clear what you mean by "service" here; I looked up "service
request" in the transport draft, and am even more puzzled, since if we
authenticated for a service, why should we then have to explicitly
request a service?  I think the concept of service, and whether the
service above is the same as the one in section 8 of the transport
draft, and what the relationship is between the two, needs to be
explained.  I can't suggest text because I don't understand what is
meant.

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

So clearly the authentication sequence is stateful, and at least from
the server's point of view, failure is not the same as incomplete
authentication.  Will the client need to keep track of state as well?
If so, there might be a need to differentiate between failure and
incomplete authentication...

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

With or without emitting some kind of message or specific status code?

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

I think that this section:
== begin ==
< 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.
< 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".
== end ==

... does not belong here.  I think these paragraphs should be moved to
sections 2.4 and 2.5, which describe password-style and
challenge-response authentication schemes.  Also, I'd be careful with
"Other such methods may be defined later": I think you should either
state the extension mechanism (if it differs from the blah@blah.com
stuff you described under method named above), or remove that
sentence.

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

... but not reset its state if the username and service have not
changed?  And reset its state if they *have* changed?

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

This last sentence means that the server cannot require multiple
authentications by the same method.  Is this what is intended?

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

The last two paragraphs seemed to contradict each other, but upon
reading them for the third time I noticed that "authentication
requests" were mentioned in the first paragraph, but
"non-authentication messages" were mentioned in the second.  The text
is entirely correct as written, but (since we cannot use italics for
"authentication" and "non-authentication" in the draft) we could
perhaps make the text a bit easier to read:

  [...] However, SSH_SMSG_AUTH_SUCCESS is sent only once.

  Once SSH_MSG_USERAUTH_SUCCESS has been sent, any further
  authentication messages sent by the client are silently ignored,
  while any non-authentication messages sent by the client are
  passed to the service being run after this authentication protocol.


< 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
                                   ^ ("password" or "securid")
<             string    authenticating string
<
< 2.5.  One-Time Passwords and Similar Methods
        ^^^^^^^^^^^^^^^^^^

I'd prefer to use the term "challenge-response"; for example, I use a
home-grown one-time password scheme which does *not* require a
challenge, and so would fit into "password-style" authentication
above, and not into your section 2.5.

< All one-time password authentication methods use the following message
      ^^^^^^^^^^^^^^^^^ challenge-response
< exchange:
< 
<             vlint32   SSH_MSG_USERAUTH_REQUEST
<             string    user
<             string    service
<             string    method name
                                   ^ ("skey" or "opie")


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

Clarify the above:

  The possession of a private key can serve as authentication.  This
  method works by having the client send a signature created with the
  private key of the user, which the server checks with the client
  user's public 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
		 ^^^^^ verify
< authentication.  This done with the following message.  The key may
		       ^is
< include certificates.

(Last sentence is redundant with text below, and should be deleted.)

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

These sentences:

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

could be clarified:

  "Public key algorithm names" are defined in the transport layer
  specification (RFC XXX).  The "public key to be used for
  authentication" may include certificates.

< The server will respond to this message with either
< SSH_MSG_USERAUTH_FAILURE or with
< 
<             vlint32   SSH_MSG_USERAUTH_PK_OK
< 
< To do actual authentication, the client should then send a signature
< generated by the public key.  It is permissible to send the signature
            ^^using
< directly without first querying whether the key is acceptable.
                         ^^^^^^^^
                         verifying
< 
<             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
< 
< The public key may contain certificates.

The above sentence is redundant.

< Signature  is a signature by the corresponding private key of the HASH
           ^extra space     ^^with
(where the HASH algorithm is available from the transport layer)
< 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).

(Use "the" on none or all of the items above, not on only some of
them.)

< 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.  
                                    It is rather similar to the Unix
  "rhosts" and "hosts.equiv" styles of authentication, except that the
  identity of the client host is checked more rigorously.

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

< 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
<             string    signature

As in the above section, these sentences:

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

could be clarified:

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

< Signature is a signature by the host key
                           ^^^^^^^^^^^^^^^
                           with the private host key for the client host
< of HASH
    ^the
  (where the HASH algorithm is available from the transport layer)
< 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).

Same comment as before with respect to "the".

< 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
                                     ^ named in the message
< 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
                                     XXXX                      ^only
< host.)
< 
< It is recommended that whenever possible, the server performs additional
                                                       perform
< 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.


< 3.  When Authentication Is Complete

I'd like to request changes similar to those I suggested above, to
avoid the reader having to read this text three times before realizing
that the apparent contradiction does not exist:  :-)

< Authentication is complete when the server has responded with
< SSH_MSG_USERAUTH_SUCCESS.  Any SSH_MSG_USERAUTH_REQUEST messages
                          ;  any
< received after sending this message will be silently ignored.
                                      ^^^^^^^
                                      are
< 
< When sending SSH_MSG_USERAUTH_SUCCESS, the server also starts whatever
< application was requested as the service.  Any non-authentication
                                                 (non-authentication)
< messages received will be passed to the requested service.
                    ^^^^^^^
                    after this point are

< 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

I'd suggest:

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

  The ssh server may send a SSH_MSG_USERAUTH_BANNER message at any
  time.  This message contains text to be displayed to the client user
  before authentication is attempted.  The form is as follows, where
  "message" may contain newlines:

              vlint32   SSH_MSG_USERAUTH_BANNER
              string    message

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

Eeek; as a "fascist" sysadmin, I'd rather see:

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

< 5.  Message Numbers
< 
< All message numbers used by this authencation protocol are in the range
                                         ^ti
< 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.  

  Message numbers 40 and higher are reserved for protocols running
  after this authentication protocol, so receiving one of them before
  authentication is complete is an error, to which the server must
  respond by disconnecting.

(Note: does the server emit a message before disconnecting?)

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

I'd reorder this text a bit:

< 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

...as follows:

  These are the general authentication message codes:
  
  #define SSH_MSG_USERAUTH_BANNER         31
  #define SSH_MSG_USERAUTH_FAILURE        32
  #define SSH_MSG_USERAUTH_SUCCESS        33
  #define SSH_MSG_USERAUTH_REQUEST        34

  In addition to the above, there is a range of message numbers
  (35..39) reserved for method-specific messages;  note that different
  authentication methods may reuse the same message numbers:
  
  /* Key-based */
  #define SSH_MSG_USERAUTH_PK_OK          35
  /* Challenge-response */
  #define SSH_MSG_USERAUTH_OTP_PROMPT     35
  #define SSH_MSG_USERAUTH_OTP_RESPONSE   36

  The server should ignore any method-specific messages it receives while
  expecting an authentication request.  These might sometimes result if
  the client sends an authentication request that the server does not
  understand, and follows with the method-specific continuation
  without waiting for the server's response.



< 6.  Address of Author
< 
<               Tatu Ylonen
<               SSH Communications Security Ltd.
<               Tekniikantie 12
<               FIN-02150 ESPOO
<               Finland
< 
<               E-mail: ylo@ssh.fi

Believe it or not, I have no comments on your address. :-)

We do, however, need a security considerations section.

