draft-ietf-secsh-architecture-07.txt   draft-ietf-secsh-architecture-08.txt 
Network Working Group T. Ylonen Network Working Group T. Ylonen
INTERNET-DRAFT T. Kivinen INTERNET-DRAFT T. Kivinen
draft-ietf-secsh-architecture-07.txt M. Saarinen draft-ietf-secsh-architecture-08.txt M. Saarinen
Expires: 9 July, 2001 T. Rinne Expires: 2 September, 2001 T. Rinne
S. Lehtinen S. Lehtinen
SSH Communications Security SSH Communications Security
9 January, 2001 2 March, 2001
SSH Protocol Architecture Secure Shell Remote Login Protocol Architecture
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
"work in progress." "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
SSH is a protocol for secure remote login and other secure network ser- The Secure Shell Remote Login Protocol is a suite of protocols for
vices over an insecure network. This document describes the architecture secure remote logins and other secure network services over an insecure
of the SSH protocol, as well as the notation and terminology used in SSH network. This document describes the overall architecture of the Secure
protocol documents. It also discusses the SSH algorithm naming system Shell protocols, as well as the notation and terminology used in the
that allows local extensions. The SSH protocol consists of three major protocol documents. It also discusses the algorithm naming system that
components: The Transport Layer Protocol provides server authentication, allows local extensions. The Secure Shell protocol consists of three
confidentiality, and integrity with perfect forward secrecy. The User major components: The Transport Layer Protocol provides server authenti-
Authentication Protocol authenticates the client to the server. The Con- cation, confidentiality, and integrity with perfect forward secrecy. The
nection Protocol multiplexes the encrypted tunnel into several logical User Authentication Protocol authenticates the client to the server. The
channels. Details of these protocols are described in separate docu- Connection Protocol multiplexes the encrypted tunnel into several logi-
ments. cal channels. Details of these protocols are described in separate doc-
uments.
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
3.5. Packet Size and Overhead . . . . . . . . . . . . . . . . . . 5 3.5. Packet Size and Overhead . . . . . . . . . . . . . . . . . . 5
3.6. Localization and Character Set Support . . . . . . . . . . . 6 3.6. Localization and Character Set Support . . . . . . . . . . . 6
4. Data Type Representations Used in the SSH Protocols . . . . . . 7 4. Data Type Representations Used in the Secure Shell Protocols . . 7
5. Algorithm Naming . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Algorithm Naming . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Message Numbers . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Message Numbers . . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 10
9. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
SSH is a protocol for secure remote login and other secure network The Secure Shell Remote Login Protocol is a protocol for secure remote
services over an insecure network. It consists of three major login and other secure network services over an insecure network. It
components: consists of three major components:
o The Transport Layer Protocol [SSH-TRANS] provides server o The Transport Layer Protocol [SECSH-TRANS] provides server
authentication, confidentiality, and integrity. It may optionally authentication, confidentiality, and integrity. It may optionally
also provide compression. The transport layer will typically be run also provide compression. The transport layer will typically be run
over a TCP/IP connection, but might also be used on top of any other over a TCP/IP connection, but might also be used on top of any other
reliable data stream. reliable data stream.
o The User Authentication Protocol [SSH-USERAUTH] authenticates the o The User Authentication Protocol [SECSH-USERAUTH] authenticates the
client-side user to the server. It runs over the transport layer client-side user to the server. It runs over the transport layer
protocol. protocol.
o The Connection Protocol [SSH-CONN] multiplexes the encrypted tunnel o The Connection Protocol [SECSH-CONN] multiplexes the encrypted tunnel
into several logical channels. It runs over the user authentication into several logical channels. It runs over the user authentication
protocol. protocol.
The client sends a service request once a secure transport layer The client sends a service request once a secure transport layer
connection has been established. A second service request is sent after connection has been established. A second service request is sent after
user authentication is complete. This allows new protocols to be defined user authentication is complete. This allows new protocols to be defined
and coexist with the protocols listed above. and coexist with the protocols listed above.
The connection protocol provides channels that can be used for a wide The connection protocol provides channels that can be used for a wide
range of purposes. Standard methods are provided for setting up secure range of purposes. Standard methods are provided for setting up secure
interactive shell sessions and for forwarding ("tunneling") arbitrary interactive shell sessions and for forwarding ("tunneling") arbitrary
TCP/IP ports and X11 connections. TCP/IP ports and X11 connections.
2. Specification of Requirements 2. Specification of Requirements
All documents related to the SSH protocols shall use the keywords All documents related to the Secure Shell protocols shall use the
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
NOT", "RECOMMENDED, "MAY", and "OPTIONAL" to describe requirements. "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe
They are to be interpreted as described in [RFC-2119]. requirements. They are to be interpreted as described in [RFC-2119].
3. Architecture 3. Architecture
3.1. Host Keys 3.1. Host Keys
Each server host SHOULD have a host key. Hosts MAY have multiple host Each server host SHOULD have a host key. Hosts MAY have multiple host
keys using multiple different algorithms. Multiple hosts MAY share the keys using multiple different algorithms. Multiple hosts MAY share the
same host key. If a host has keys at all, it MUST have at least one key same host key. If a host has keys at all, it MUST have at least one key
using each REQUIRED public key algorithm (currently DSS [FIPS-186]). using each REQUIRED public key algorithm (currently DSS [FIPS-186]).
skipping to change at page 5, line 32 skipping to change at page 5, line 30
example, the policy SHOULD NOT allow the server to start sessions or example, the policy SHOULD NOT allow the server to start sessions or
run commands on the client machine, and MUST NOT allow connections to run commands on the client machine, and MUST NOT allow connections to
the authentication agent unless forwarding such connections has been the authentication agent unless forwarding such connections has been
requested. Other issues, such as which TCP/IP ports can be forwarded requested. Other issues, such as which TCP/IP ports can be forwarded
and by whom, are clearly issues of local policy. Many of these issues and by whom, are clearly issues of local policy. Many of these issues
may involve traversing or bypassing firewalls, and are interrelated may involve traversing or bypassing firewalls, and are interrelated
with the local security policy. with the local security policy.
3.4. Security Properties 3.4. Security Properties
The primary goal of the SSH protocol is improved security on the The primary goal of the Secure Shell protocol is improved security on
Internet. It attempts to do this in a way that is easy to deploy, even the Internet. It attempts to do this in a way that is easy to deploy,
at the cost of absolute security. even at the cost of absolute security.
o All encryption, integrity, and public key algorithms used are well- o All encryption, integrity, and public key algorithms used are well-
known, well-established algorithms. known, well-established algorithms.
o All algorithms are used with cryptographically sound key sizes that o All algorithms are used with cryptographically sound key sizes that
are believed to provide protection against even the strongest are believed to provide protection against even the strongest
cryptanalytic attacks for decades. cryptanalytic attacks for decades.
o All algorithms are negotiated, and in case some algorithm is broken, o All algorithms are negotiated, and in case some algorithm is broken,
it is easy to switch to some other algorithm without modifying the it is easy to switch to some other algorithm without modifying the
skipping to change at page 6, line 33 skipping to change at page 6, line 31
However, with modern modems, the time needed to transfer is in the order However, with modern modems, the time needed to transfer is in the order
of 2 milliseconds, which is a lot faster than people can type. of 2 milliseconds, which is a lot faster than people can type.
There are also issues related to the maximum packet size. To minimize There are also issues related to the maximum packet size. To minimize
delays in screen updates, one does not want excessively large packets delays in screen updates, one does not want excessively large packets
for interactive sessions. The maximum packet size is negotiated for interactive sessions. The maximum packet size is negotiated
separately for each channel. separately for each channel.
3.6. Localization and Character Set Support 3.6. Localization and Character Set Support
For the most part, the SSH protocols do not directly pass text that For the most part, the Secure Shell protocols do not directly pass text
would be displayed to the user. However, there are some places where that would be displayed to the user. However, there are some places
such data might be passed. When applicable, the character set for the where such data might be passed. When applicable, the character set for
data MUST be explicitly specified. In most places, ISO 10646 with UTF-8 the data MUST be explicitly specified. In most places, ISO 10646 with
encoding is used [RFC-2279]. When applicable, a field is also provided UTF-8 encoding is used [RFC-2279]. When applicable, a field is also
for a language tag [RFC-1766]. provided for a language tag [RFC-1766].
One big issue is the character set of the interactive session. There is One big issue is the character set of the interactive session. There is
no clear solution, as different applications may display data in no clear solution, as different applications may display data in
different formats. Different types of terminal emulation may also be different formats. Different types of terminal emulation may also be
employed in the client, and the character set to be used is effectively employed in the client, and the character set to be used is effectively
determined by the terminal emulation. Thus, no place is provided for determined by the terminal emulation. Thus, no place is provided for
directly specifying the character set or encoding for terminal session directly specifying the character set or encoding for terminal session
data. However, the terminal emulation type (e.g. "vt100") is data. However, the terminal emulation type (e.g. "vt100") is
transmitted to the remote site, and it implicitly specifies the transmitted to the remote site, and it implicitly specifies the
character set and encoding. Applications typically use the terminal character set and encoding. Applications typically use the terminal
skipping to change at page 7, line 19 skipping to change at page 7, line 17
the server to decide how to map user names to accepted user names. the server to decide how to map user names to accepted user names.
Straight bit-wise binary comparison is RECOMMENDED. Straight bit-wise binary comparison is RECOMMENDED.
For localization purposes, the protocol attempts to minimize the number For localization purposes, the protocol attempts to minimize the number
of textual messages transmitted. When present, such messages typically of textual messages transmitted. When present, such messages typically
relate to errors, debugging information, or some externally configured relate to errors, debugging information, or some externally configured
data. For data that is normally displayed, it SHOULD be possible to data. For data that is normally displayed, it SHOULD be possible to
fetch a localized message instead of the transmitted message by using a fetch a localized message instead of the transmitted message by using a
numerical code. The remaining messages SHOULD be configurable. numerical code. The remaining messages SHOULD be configurable.
4. Data Type Representations Used in the SSH Protocols 4. Data Type Representations Used in the Secure Shell Protocols
byte byte
A byte represents an arbitrary 8-bit value (octet) [RFC-1700]. A byte represents an arbitrary 8-bit value (octet) [RFC-1700].
Fixed length data is sometimes represented as an array of bytes, Fixed length data is sometimes represented as an array of bytes,
written byte[n], where n is the number of bytes in the array. written byte[n], where n is the number of bytes in the array.
boolean boolean
A boolean value is stored as a single byte. The value 0 A boolean value is stored as a single byte. The value 0
represents FALSE, and the value 1 represents TRUE. All non-zero represents FALSE, and the value 1 represents TRUE. All non-zero
values MUST be interpreted as TRUE; however, applications MUST NOT values MUST be interpreted as TRUE; however, applications MUST NOT
skipping to change at page 8, line 31 skipping to change at page 8, line 30
value (hex) representation (hex) value (hex) representation (hex)
--------------------------------------------------------------- ---------------------------------------------------------------
0 00 00 00 00 0 00 00 00 00
9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7 9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7
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
5. Algorithm Naming 5. Algorithm Naming
The SSH protocols refer to particular hash, encryption, integrity, The Secure Shell protocols refer to particular hash, encryption,
compression, and key exchange algorithms or protocols by names. There integrity, compression, and key exchange algorithms or protocols by
are some standard algorithms that all implementations MUST support. names. There are some standard algorithms that all implementations MUST
There are also algorithms that are defined in the protocol specification support. There are also algorithms that are defined in the protocol
but are OPTIONAL. Furthermore, it is expected that some organizations specification but are OPTIONAL. Furthermore, it is expected that some
will want to use their own algorithms. organizations will want to use their own algorithms.
In this protocol, all algorithm identifiers MUST be printable US-ASCII In this protocol, all algorithm identifiers MUST be printable US-ASCII
strings no longer than 64 characters. Names MUST be case-sensitive. strings no longer than 64 characters. Names MUST be case-sensitive.
There are two formats for algorithm names: There are two formats for algorithm names:
o Names that do not contain an at-sign (@) are reserved to be assigned o Names that do not contain an at-sign (@) are reserved to be assigned
by IETF consensus (RFCs). Examples include `3des-cbc', `sha-1', by IETF consensus (RFCs). Examples include `3des-cbc', `sha-1',
`hmac-sha1', and `zlib' (the quotes are not part of the name). Names `hmac-sha1', and `zlib' (the quotes are not part of the name). Names
of this format MUST NOT be used without first registering them. of this format MUST NOT be used without first registering them.
skipping to change at page 9, line 7 skipping to change at page 9, line 5
o Anyone can define additional algorithms by using names in the format o Anyone can define additional algorithms by using names in the format
name@domainname, e.g. "ourcipher-cbc@ssh.com". The format of the part name@domainname, e.g. "ourcipher-cbc@ssh.com". The format of the part
preceding the at sign is not specified; it MUST consist of US-ASCII preceding the at sign is not specified; it MUST consist of US-ASCII
characters except at-sign and comma. The part following the at-sign characters except at-sign and comma. The part following the at-sign
MUST be a valid fully qualified internet domain name [RFC-1034] MUST be a valid fully qualified internet domain name [RFC-1034]
controlled by the person or organization defining the name. It is up controlled by the person or organization defining the name. It is up
to each domain how it manages its local namespace. to each domain how it manages its local namespace.
6. Message Numbers 6. Message Numbers
SSH packets have message numbers in the range 1 to 255. These numbers Secure Shell protocol packets have message numbers in the range 1 to
have been allocated as follows: 255. These numbers have been allocated as follows:
Transport layer protocol: Transport layer protocol:
1 to 19 Transport layer generic (e.g. disconnect, ignore, debug, 1 to 19 Transport layer generic (e.g. disconnect, ignore, debug,
etc.) etc.)
20 to 29 Algorithm negotiation 20 to 29 Algorithm negotiation
30 to 49 Key exchange method specific (numbers can be reused for 30 to 49 Key exchange method specific (numbers can be reused for
different authentication methods) different authentication methods)
User authentication protocol: User authentication protocol:
skipping to change at page 9, line 39 skipping to change at page 9, line 37
Reserved for client protocols: Reserved for client protocols:
128 to 191 Reserved 128 to 191 Reserved
Local extensions: Local extensions:
192 to 255 Local extensions 192 to 255 Local extensions
7. IANA Considerations 7. IANA Considerations
Allocation of the following types of names in the SSH protocols is Allocation of the following types of names in the Secure Shell protocols
assigned by IETF consensus: is assigned by IETF consensus:
o encryption algorithm names, o encryption algorithm names,
o MAC algorithm names, o MAC algorithm names,
o public key algorithm names (public key algorithm also implies o public key algorithm names (public key algorithm also implies
encoding and signature/encryption capability), encoding and signature/encryption capability),
o key exchange method names, and o key exchange method names, and
skipping to change at page 10, line 29 skipping to change at page 10, line 27
are of good quality. The random numbers SHOULD be produced with safe are of good quality. The random numbers SHOULD be produced with safe
mechanisms discussed in [RFC-1750]. mechanisms discussed in [RFC-1750].
When displaying text, such as error or debug messages to the user, the When displaying text, such as error or debug messages to the user, the
client software SHOULD replace any control characters (except tab, client software SHOULD replace any control characters (except tab,
carriage return and newline) with safe sequences to avoid attacks by carriage return and newline) with safe sequences to avoid attacks by
sending terminal control characters. sending terminal control characters.
Not using MAC or encryption SHOULD be avoided. The user authentication Not using MAC or encryption SHOULD be avoided. The user authentication
protocol is subject to man-in-the-middle attacks if the encryption is protocol is subject to man-in-the-middle attacks if the encryption is
disabled. The SSH protocol does not protect against message alteration disabled. The Secure Shell protocol does not protect against message
if no MAC is used. alteration if no MAC is used.
9. Trademark Issues 9. Trademark Issues
SSH is a registered trademark and Secure Shell is a trademark of SSH "ssh" is a registered trademark of SSH Communications Security Corp in
Communications Security Corp. SSH Communications Security Corp permits the United States and/or other countries.
the use of these trademarks as the name of this standard and protocol,
and permits their use to describe that a product conforms to this
standard, provided that the following acknowledgement is included where
the trademarks are used: ``SSH is a registered trademark and Secure
Shell is a trademark of SSH Communications Security Corp
(www.ssh.com)''. These trademarks may not be used as part of a product
name or in otherwise confusing manner without prior written permission
of SSH Communications Security Corp.
10. References 10. References
[FIPS-186] Federal Information Processing Standards Publication (FIPS [FIPS-186] Federal Information Processing Standards Publication (FIPS
PUB) 186, Digital Signature Standard, 18 May 1994. PUB) 186, Digital Signature Standard, 18 May 1994.
[RFC-854] Postel, J. and Reynolds, J: "Telnet Protocol Specification", [RFC-854] Postel, J. and Reynolds, J: "Telnet Protocol Specification",
May 1983. May 1983.
[RFC-894] Hornig, C: "A Standard for the Transmission of IP Datagrams [RFC-894] Hornig, C: "A Standard for the Transmission of IP Datagrams
skipping to change at page 11, line 29 skipping to change at page 11, line 20
[RFC-2279] Yergeau, F: "UTF-8, a transformation format of ISO 10646", [RFC-2279] Yergeau, F: "UTF-8, a transformation format of ISO 10646",
January 1998. January 1998.
[RFC-2119] Bradner, S: "Key words for use in RFCs to indicate [RFC-2119] Bradner, S: "Key words for use in RFCs to indicate
Requirement Levels", March 1997. Requirement Levels", March 1997.
[RFC-2343] Narten, T. and Alvestrand, H: "Guidelines for Writing an IANA [RFC-2343] Narten, T. and Alvestrand, H: "Guidelines for Writing an IANA
Considerations Section in RFCs", October 1998. Considerations Section in RFCs", October 1998.
[SSH-TRANS] Ylonen, T., et al: "SSH Transport Layer Protocol", Internet- [SECSH-TRANS] Ylonen, T., et al: "Secure Shell Transport Layer
Draft, draft-ietf-secsh-transport-09.txt Protocol", Internet-Draft, draft-ietf-secsh-transport-10.txt
[SSH-USERAUTH] Ylonen, T., et al: "SSH Authentication Protocol", [SECSH-USERAUTH] Ylonen, T., et al: "Secure Shell Authentication
Internet-Draft, draft-ietf-secsh-userauth-09.txt Protocol", Internet-Draft, draft-ietf-secsh-userauth-10.txt
[SSH-CONNECT] Ylonen, T., et al: "SSH Connection Protocol", Internet- [SECSH-CONNECT] Ylonen, T., et al: "Secure Shell Connection Protocol",
Draft, draft-ietf-secsh-connect-09.txt Internet-Draft, draft-ietf-secsh-connect-10.txt
11. Authors' Addresses 11. Authors' Addresses
Tatu Ylonen Tatu Ylonen
SSH Communications Security Corp SSH Communications Security Corp
Fredrikinkatu 42 Fredrikinkatu 42
FIN-00100 HELSINKI FIN-00100 HELSINKI
Finland Finland
E-mail: ylo@ssh.com E-mail: ylo@ssh.com
 End of changes. 

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