Delivery-Date: Thu Dec 19 17:43:28 1996
Date: Thu, 19 Dec 1996 17:14:54 +0200 (EET)
Message-Id: <199612191514.RAA01257@pilari.ssh.fi>
From: Tatu Ylonen <ylo@ssh.fi>
To: ietf-ssh@clinet.fi, ssh@clinet.fi, ssh-announce@clinet.fi, jis@mit.edu,
        pnr@ssh.fi
Subject: Minutes of the Secure Shell BOF at 37th IETF, San Jose, Wed 11 Dec.8pm
Organization: SSH Communications Security, Finland
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 11483
Lines: 280

[Thanks to Pekka Nikander <pnr@ssh.fi> for writing the minutes. //ylo]

Minutes of the Secure Shell BOF at 37th IETF, San Jose, Wed 11 Dec.   8pm

Working group mailing list: ietf-ssh@clinet.fi
To subscribe: send mail to majordomo@clinet.fi with 
              "subscribe ietf-ssh" in the body of the message

An informal BOF concerning the Secure Shell, or SSH, was held at 37th
IETF at San Jose Fairmont Hotel on Wed 11 December 8pm.  The purpose
of the BOF was to introduce SSH, and to discuss formation of an IETF
working group to standardize the SSH protocol either as such or by
merging it partially to the TLS protocol standard.  It should be
noted, however, that SSH functionality greatly exceeds current TLS
functionality.

Minutes
-------

Introduction and discussion

Tatu Ylonen, the author of the current SSH implementation, gave a
brief overview of the system and the version 2.0 of the protocol.
A summary of the overview is attached as an appendix to this document.

A question was raised about the merits of SSH in respect to IPSEC.
Tatu's, as well as others, view is that IPSEC is something that may
finally replace SSH.  However, SSH is here now, and is being widely
used.  Furthermore, SSH is implemented as a user level program whereas
IPSEC usually requires kernel level implementation.  Therefore the
deployment of SSH has been, and most probably will be, must faster
than IPSEC deployment.

The next discussion item concerned SSH viz TLS.  According to Tatu,
there is considerable overlap in SSH and TLS at the pure
transport/record layer, i.e. at the lowest protocol layer just above
TCP (or other transport).  Thus, one of the items worth investigation
is to study how much and in which ways TLS transport protocol should
be changed in order to make it possible to base a new SSH version on
the top of the TLS transport.  A short description of the differences
between SSH and TLS is included as an appendix.

Considering SSH vs. TLS is must be noted that SSH includes much more
functionality than TLS, including channel multiplexion, generic TCP
port forwarding, X11-forwarding and authentication proxies.

It was also noted that there must be some sort of support for public
key infrastructures in SSH.  It seems to be very useful to support
SPKI, and probably there is also interest in supporting Kerberos and
PKIX (X.509).  Tatu certainly plans to add SPKI support to SSH in the
near future.

Formation of a working group

Tatu proposed an IETF working group to be formed.  Accoring to a straw
poll, there was clear support for standardization effort among the
attendees of the BOF.  The standardization process raised the need for
a second independent implementation.  Tatu expressed his wish that
e.g. some university would attempt such an task, and promised his
support for any such an effort.

A draft charter for the working group was presented:

  The goal of the working group is to define an extensible standards
  track protocol for secure remote login, secure file transfer, secure
  TCP/IP, X11 and other forwarding, compression, and similar tasks.
  The group will base its work on the SSH 2.0 protocol.

  The working group will attempt to produce a protocol which
  - provides strong security against cryptanalysis and protocol attacks,
  - can work reasonably well without a global security infrastructure,
  - can utilize existing security infrastructures when available
  - can be made easy to deploy and take into use,
  - requires minimum or no manual interaction from users,
  - is reasonably clean and simple to implement,
  - has minimum of patent hassles, and
  - works.

  In the protocol desing, no consideration will be given to export
  concerns or other legislative restrictions on encryption technology.

  The resulting protocol will operate over TCP/IP or other reliable
  (but probably insecure) transport, and will provide connection
  confidentiality and integrity combined with authentication of
  communicating parties.  It is intended to be implemented at the
  application level.

Some points noted on the charter:
  - the charter indicates support only for connection oriented
    protocols (i.e. TCP).  It would be nice if there were support for
    connectionless protocols as well, e.g. NFS forwarding has been
    asked for.
  - compression was added to the charter during the BOF
  - maybe the intended support for key infrastructure (SPKI, X.509)
    based authentication should be emphasized

Tatu presented an initial suggestion for milestones:

  Dec 1996	WG formed, first informal meeting
  Jan 1997	Publish current SSH-2.0 as an I-D
  Feb 1997	Publish an I-D describing changes needed to be made
		on TLS 1.0 so that it could be used for SSH
  Feb 1997	Publish I-Ds describing SSH authentication and
		multiplexing protocols
  Apr 1997	WG meets at Memphis
		- attempt to reach concensus on auth and mux protocols
		- evaluation on changes needed to TLS
		- attempt to decide whether use TLS transport with
		  changes, or the SSH 2.0 transport, as bases for
		  further standardization
  Jul 1997	WG meets at Munich
  Aug 1997	Submit a set of I-Ds describing the transport
		protocol, authentication protocol and multiplexing
		protocol to be published as Proposed Standard
  Dec 1997	WG meets
		- second independend implementation ready

A number of questions and comments were rosen in respect to the milestones:
- Maybe the SSH group can create a better transport protocol [than TLS]?
- The proposed timetable is probably too strict for the TLS working
  group to react to the proposed changes?
- How does Tatu's commercial interest inflict to the work of the
  working group?  (This was not seen to be a problem)

There was a strong consensus that the decision on whether the SSH
protocol could adapt into the TLS transport protocol or should there
be a separate transport protocol for SSH should be left open for now.

Finally, it was decided that the work continues on the mailing list.
Tatu will discuss the working group charter, milestones and chairing
with the security area director.  The questions left open at the BOF
will be discussed at the mailing list.

-----------------------------------------------------------------

APPENDIX 1.  Attendee list

[Note: Unfortunately, the Ad Hoc Committee meeting (on top-level
domain names) exceeded its time slot and overlapped with the informal
SSH BOF.  A very large portion of the IETF attendees were at the Ad
Hoc Committee meeting, and then went to the PGP key signing party
which overlapped the latter part of the SSH BOF. //ylo]

Jari Arkko		jar@iki.fi
Luc Boulianre		lucb@cs.mcgill.ca
Carl Ellison		cme@cybercash.com
Robert Enger		enger@pandora.erols.com
Roger Fajman		raf@eu.nih.gov
Olafur Gudmundsson	ogud@tis.com
Joel Jaeggli		joelja@darkwing.udri-gon.edu
Cheryl Madson		cmadson@cisco.com
Sandro Mazzucato	pedro@bunyip.com
Justin Newton		justin@erols.com
Pekka Nikander		Pekka.Nikander@nixu.fi
Clayton O'Neill		coneill@oneill.net
Pat Richard		patr@x509.com
Bill Sommerfied		sommerfield@apollo.hp.com
Tatu Ylonen		ylo@ssh.fi

-----------------------------------------------------------------

APPENDIX 2.  A BRIEF DESCRIPTION OF SSH

What is SSH?
- secure remote login
- secure X11 forwarding
- secure TCP-connection forwarding
- secure file transfer
- replaces rlogin, rsh, rcp, (rdist, ftp)
- no central place of trust; each machine only holds its own keys
- easy to install, easy to use
- uses strong cryptography: 1024 bit RSA, 3DES, Blowfish, IDEA
- available for Unix, Windows, OS/2, Amiga, and soon Macintosh
- Unix, OS/2, Amiga freely available, Windows version commercial

How widely SSH is used?
- in roughly 50 counties
- distributed through FTP sites in over 20 countries
- used on at least thousands, probably tens of thousands of sites
- probably hundreds of thousands of individual users
- roughly 1% of bytes at FIX-WEST; with peaks up to 5%

SSH Secure Remote Login
- strong authentication
  - does not trust the network
- server machine authenticated with RSA
  - prevents "Trojan horse" attacks
- fully distributed key management
- all traffic is automatically encrypted
- protection of data integrity
- X11 forwarding
- TCP-connection forwarding
- authentication agent (in future possibly on a smart card)

Some of the other features
- optional compression of all transmitted data
- easy to use
  - X11 $DISPLAY and xauth data set automatically
  - automatically 8-bit clean
  - exit status is returned on remote execution
  - can run arbitrary commands on a pty

Structure of the SSH 2.0 Protocol
---------------------------------

Transport layer
 - algorithm negotiation
 - key exchange
 - server host authentication
 - encryption
 - integrity protection
 - compression

Authentication layer
 - user authentication
   - passwords (over encrypted channel)
   - .rhosts or /etc/hosts with RSA client host authentication
   - RSA auhentication (user has an RSA key pair)
   - one-time passwords (over integrity protected channel)
   - Kerberos authentication (planned)

Multiplexing layer
  - multiplexes several logical connections over a single encrypted channel
  - remote login functionality
  - X11-forwarding
  - TCP-connection forwarding
  - file transfer

-----------------------------------------------------------------

APPENDIX 3.  TLS vs SSH

Differences and similarities between SSH 2.0 transport layer and 
TLS 1.0 proposal

  - mostly quite similar in functionality
  - packet structure is different, but essentially equivalent
  - both negotiate algorithms
    - SSH negotiates each algorithm separately, and can use different
      ciphers/compression for each direction
    - TLS uses algorithm suites
    - in SSH, anyone can add new algorithms without name conflicts
  - SSH supports compression, TLS does not yet (in practise)
  - SSH can support elliptic curves
  - SSH is not bound to a single key infrastructure or certifiate format

Reasons to adopt TLS 1.0 transport for SSH

  - TLS will become an IETF standard; i.e. various political reasons
  - wide use of a single protocol would mean more scrutinity
  - can use results of old key exchanges (may or may not be desirable)

Reasons not to adopt TLS 1.0 transport for SSH
  
  - X.509 specific key insfrastructure -- SPKI would be preferenced with SSH
  - harder to add support for new algorithms
  - TLS does not currently have support for compression
  - SSL does have support for weak cryptoalgorihtms; this means that
    SSL does not have very good repudiation outside the US

Why current SSH 2.0 transport layer would be better?

  - more flexible algorithm negotiation
  - certificate format negotiated; can support multiple infrastructures
  - easy to add proprietary algorithms and even key exchange methods locally
  - supports key re-exchange
  - packets are slightly smaller
  - all data is encrypted, the data stream is completely binary
  - would save time and work in the initial implementation

What changeds are needed toe made to the TLS if it is to be used in SSH?

  - must be allowed for implementations to NOT to implement weak algorithms
  - must add support for new key infrastructures, e.g. SPKI
  - must add real, working compression
  - should add some new algorithms, e.g. Blowfish, IDEA, Safer, EC*?
  - would like to add a new alert level "debug" (only shown on request)
  - would like to reserve some CipherSuite numbers for future extensions 

  More issues will most probably come up on closer inspection