draft-ietf-secsh-architecture-01.txt   draft-ietf-secsh-architecture-02.txt 
Network Working Group T. Ylonen Network Working Group T. Ylonen
INTERNET-DRAFT T. Kivinen INTERNET-DRAFT T. Kivinen
draft-ietf-secsh-architecture-01.txt M. Saarinen draft-ietf-secsh-architecture-02.txt M. Saarinen
Expires in six months SSH Expires in six months T. Rinne
7 November 1997 S. Lehtinen
SSH
6 August 1998
SSH Protocol Architecture SSH Protocol Architecture
Status of This memo Status of This memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast),
or ftp.isi.edu (US West Coast). or ftp.isi.edu (US West Coast).
Abstract Abstract
SSH is a protocol for secure remote login and other secure network SSH is a protocol for secure remote login and other secure network ser-
services over an insecure network. vices over an insecure network. This document describes the architecture
of the SSH protocol, and the notation and terminology used in SSH proto-
This document describes the architecture of the SSH protocol, and the col documents. It also discusses the SSH algorithm naming system that
notation and terminology used in SSH protocol documents. It also discusses allows local extensions. The SSH protocol consists of three major com-
the SSH algorithm naming system that allows local extensions. ponents: Transport layer protocol provides server authentication, confi-
dentiality, and integrity with perfect forward secrecy. User authentica-
The SSH protocol consists of three major components: Transport layer tion protocol authenticates the client to the server. Connection proto-
protocol provides server authentication, confidentiality, and integrity col multiplexes the encrypted tunnel into several logical channels.
with perfect forward secrecy. User authentication protocol authenticates Details of these protocols are described in separate documents.
the client to the server. Connection protocol multiplexes the encrypted
tunnel into several logical channels. Details of these protocols are
described in separate documents.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Specification of Requirements . . . . . . . . . . . . . . . . . 2 2. Specification of Requirements . . . . . . . . . . . . . . . . . 2
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Host Keys . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Host Keys . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Policy Issues . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Policy Issues . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Security Properties . . . . . . . . . . . . . . . . . . . . 5 3.4. Security Properties . . . . . . . . . . . . . . . . . . . . 5
skipping to change at page 3, line 47 skipping to change at page 3, line 47
the other hand, each host key must be appropriately certified by a the other hand, each host key must be appropriately certified by a
central authority before authorization is possible. Also, a lot of central authority before authorization is possible. Also, a lot of
trust is placed on the central infrastructure. trust is placed on the central infrastructure.
The protocol provides the option that the server name - host key The protocol provides the option that the server name - host key
association is not checked when connecting the host for the first time. association is not checked when connecting the host for the first time.
This allows communication without prior communication of host keys or This allows communication without prior communication of host keys or
certification. The connection still provides protection against passive certification. The connection still provides protection against passive
listening; however, it becomes vulnerable to active man-in-the-middle listening; however, it becomes vulnerable to active man-in-the-middle
attacks. Implementations SHOULD NOT normally allow such connections by attacks. Implementations SHOULD NOT normally allow such connections by
default, as they pose a potential security problem. However, as there default, as they pose a potential security problem. However, as there is
is no widely deployed key infrastructure available on the Internet yet, no widely deployed key infrastructure available on the Internet yet,
this option makes the protocol much more usable during the transition this option makes the protocol much more usable during the transition
time until such an infrastructure emerges, while still providing a much time until such an infrastructure emerges, while still providing a much
higher level of security than that offered by older solutions (e.g. higher level of security than that offered by older solutions (e.g.
telnet [RFC-854] and rlogin [RFC-1282]). telnet [RFC-854] and rlogin [RFC-1282]).
Implementations SHOULD try to make best effort to check host keys. An Implementations SHOULD try to make best effort to check host keys. An
example of a possible strategy is to only accept a host key without example of a possible strategy is to only accept a host key without
checking the first time a host is connected, save the key in a local checking the first time a host is connected, save the key in a local
database, and compare against that key on all future connections to that database, and compare against that key on all future connections to that
host. host.
skipping to change at page 8, line 25 skipping to change at page 8, line 25
80 00 00 00 02 00 80 80 00 00 00 02 00 80
-1234 00 00 00 02 ed cc -1234 00 00 00 02 ed cc
-deadbeef 00 00 00 05 ff 21 52 41 11 -deadbeef 00 00 00 05 ff 21 52 41 11
4.1. Encoding of Network Addresses 4.1. Encoding of Network Addresses
Network addresses are encoded as strings. DNS names MUST NOT be used, as Network addresses are encoded as strings. DNS names MUST NOT be used, as
DNS is an insecure protocol. DNS is an insecure protocol.
If an address contains a colon (':', ascii 58), it is interpreted as an If an address contains a colon (':', ascii 58), it is interpreted as an
IPv6 address. The encoding of IPv6 addresses is described in RFC-1884. IPv6 address. The encoding of IPv6 addresses is described in [RFC-1884].
IPv4 addresses are expressed in the standard dot-separated decimal IPv4 addresses are expressed in the standard dot-separated decimal
format (e.g. 127.0.0.1). format (e.g. 127.0.0.1).
5. Algorithm Naming 5. Algorithm Naming
The SSH protocols refer to particular hash, encryption, integrity, The SSH protocols refer to particular hash, encryption, integrity,
compression, and key exchange algorithms or protocols by names. There compression, and key exchange algorithms or protocols by names. There
are some standard algorithms that all implementations MUST support. are some standard algorithms that all implementations MUST support.
There are also algorithms that are defined in the protocol specification There are also algorithms that are defined in the protocol specification
but are OPTIONAL. Furthermore, it is expected that some organizations but are OPTIONAL. Furthermore, it is expected that some organizations
skipping to change at line 560 skipping to change at page 11, line 43
FIN-02150 ESPOO FIN-02150 ESPOO
Finland Finland
E-mail: kivinen@ssh.fi E-mail: kivinen@ssh.fi
Markku-Juhani O. Saarinen Markku-Juhani O. Saarinen
SSH Communications Security Ltd. SSH Communications Security Ltd.
Tekniikantie 12 Tekniikantie 12
FIN-02150 ESPOO FIN-02150 ESPOO
Finland Finland
E-mail: mjos@ssh.fi E-mail: mjos@ssh.fi
Timo J. Rinne
SSH Communications Security Ltd.
Tekniikantie 12
FIN-02150 ESPOO
Finland
E-mail: tri@ssh.fi
Sami Lehtinen
SSH Communications Security Ltd.
Tekniikantie 12
FIN-02150 ESPOO
Finland
E-mail: sjl@ssh.fi
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/