draft-ietf-secsh-architecture-18.txt   draft-ietf-secsh-architecture-19.txt 
Network Working Group C. Lonvick, Ed. Network Working Group C. Lonvick, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: May 19, 2005 November 18, 2004 Expires: May 30, 2005 November 29, 2004
SSH Protocol Architecture SSH Protocol Architecture
draft-ietf-secsh-architecture-18.txt draft-ietf-secsh-architecture-19.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference 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."
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.
This Internet-Draft will expire on May 19, 2005. This Internet-Draft will expire on May 30, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
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
services over an insecure network. This document describes the services over an insecure network. This document describes the
architecture of the SSH protocol, as well as the notation and architecture of the SSH protocol, as well as the notation and
skipping to change at page 3, line 7 skipping to change at page 3, line 7
9.4.2 Proxy Forwarding . . . . . . . . . . . . . . . . . . . 23 9.4.2 Proxy Forwarding . . . . . . . . . . . . . . . . . . . 23
9.4.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . 24 9.4.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 25 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 25
10.2 Informative References . . . . . . . . . . . . . . . . . . . 25 10.2 Informative References . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . 28
1. Contributors 1. Contributors
The major original contributors of this document were: Tatu Ylonen, The major original contributors of this set of documents have been:
Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH
Communications Security Corp), and Markku-Juhani O. Saarinen Communications Security Corp), and Markku-Juhani O. Saarinen
(University of Jyvaskyla). Darren Moffit was the original editor of (University of Jyvaskyla). Darren Moffit was the original editor of
this document and also made very substantial contributions. this set of documents and also made very substantial contributions.
Additional contributors to this document include [need list]. Additional contributors to this document include [need list].
Listing their names here does not mean that they endorse this Listing their names here does not mean that they endorse this
document, but that they have contributed to it. document, but that they have contributed to it.
Comments on this internet draft should be sent to the IETF SECSH Comments on this internet draft should be sent to the IETF SECSH
working group, details at: working group, details at:
http://ietf.org/html.charters/secsh-charter.html Note: This paragraph http://ietf.org/html.charters/secsh-charter.html Note: This paragraph
will be removed before this document progresses to become an RFC. will be removed before this document progresses to become an RFC.
skipping to change at page 5, line 9 skipping to change at page 5, line 9
association is not checked when connecting to the host for the first association is not checked when connecting to the host for the first
time. This allows communication without prior communication of host time. This allows communication without prior communication of host
keys or certification. The connection still provides protection keys or certification. The connection still provides protection
against passive listening; however, it becomes vulnerable to active against passive listening; however, it becomes vulnerable to active
man-in-the-middle attacks. Implementations SHOULD NOT normally allow man-in-the-middle attacks. Implementations SHOULD NOT normally allow
such connections by default, as they pose a potential security such connections by default, as they pose a potential security
problem. However, as there is no widely deployed key infrastructure problem. However, as there is no widely deployed key infrastructure
available on the Internet yet, this option makes the protocol much available on the Internet yet, this option makes the protocol much
more usable during the transition time until such an infrastructure more usable during the transition time until such an infrastructure
emerges, while still providing a much higher level of security than emerges, while still providing a much higher level of security than
that offered by older solutions (e.g. telnet [RFC0854] and rlogin that offered by older solutions (e.g., telnet [RFC0854] and rlogin
[RFC1282]). [RFC1282]).
Implementations SHOULD try to make the best effort to check host Implementations SHOULD try to make the best effort to check host
keys. An example of a possible strategy is to only accept a host key keys. An 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 without checking the first time a host is connected, save the key in
a local database, and compare against that key on all future a local database, and compare against that key on all future
connections to that host. connections to that host.
Implementations MAY provide additional methods for verifying the Implementations MAY provide additional methods for verifying the
correctness of host keys, e.g., a hexadecimal fingerprint derived correctness of host keys, e.g., a hexadecimal fingerprint derived
skipping to change at page 7, line 31 skipping to change at page 7, line 31
the data MUST be explicitly specified. In most places, ISO 10646 the data MUST be explicitly specified. In most places, ISO 10646
with UTF-8 encoding is used [RFC3629]. When applicable, a field is with UTF-8 encoding is used [RFC3629]. When applicable, a field is
also provided for a language tag [RFC3066]. also provided for a language tag [RFC3066].
One big issue is the character set of the interactive session. There One big issue is the character set of the interactive session. There
is no clear solution, as different applications may display data in is 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 employed in the client, and the character set to be used is
effectively determined by the terminal emulation. Thus, no place is effectively determined by the terminal emulation. Thus, no place is
provided for directly specifying the character set or encoding for provided for directly specifying the character set or encoding for
terminal session data. However, the terminal emulation type (e.g. terminal session data. However, the terminal emulation type (e.g.,
"vt100") is transmitted to the remote site, and it implicitly "vt100") is transmitted to the remote site, and it implicitly
specifies the character set and encoding. Applications typically use specifies the character set and encoding. Applications typically use
the terminal type to determine what character set they use, or the the terminal type to determine what character set they use, or the
character set is determined using some external means. The terminal character set is determined using some external means. The terminal
emulation may also allow configuring the default character set. In emulation may also allow configuring the default character set. In
any case, the character set for the terminal session is considered any case, the character set for the terminal session is considered
primarily a client local issue. primarily a client local issue.
Internal names used to identify algorithms or protocols are normally Internal names used to identify algorithms or protocols are normally
never displayed to users, and must be in US-ASCII. never displayed to users, and must be in US-ASCII.
skipping to change at page 8, line 29 skipping to change at page 8, line 29
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
store values other than 0 and 1. store values other than 0 and 1.
uint32 uint32
Represents a 32-bit unsigned integer. Stored as four bytes in the Represents a 32-bit unsigned integer. Stored as four bytes in the
order of decreasing significance (network byte order). For order of decreasing significance (network byte order). For
example, the value 699921578 (0x29b7f4aa) is stored as 29 b7 f4 example: the value 699921578 (0x29b7f4aa) is stored as 29 b7 f4
aa. aa.
uint64 uint64
Represents a 64-bit unsigned integer. Stored as eight bytes in Represents a 64-bit unsigned integer. Stored as eight bytes in
the order of decreasing significance (network byte order). the order of decreasing significance (network byte order).
string string
Arbitrary length binary string. Strings are allowed to contain Arbitrary length binary string. Strings are allowed to contain
arbitrary binary data, including null characters and 8-bit arbitrary binary data, including null characters and 8-bit
characters. They are stored as a uint32 containing its length characters. They are stored as a uint32 containing its length
(number of bytes that follow) and zero (= empty string) or more (number of bytes that follow) and zero (= empty string) or more
bytes that are the value of the string. Terminating null bytes that are the value of the string. Terminating null
characters are not used. characters are not used.
Strings are also used to store text. In that case, US-ASCII is Strings are also used to store text. In that case, US-ASCII is
skipping to change at page 8, line 48 skipping to change at page 8, line 49
Arbitrary length binary string. Strings are allowed to contain Arbitrary length binary string. Strings are allowed to contain
arbitrary binary data, including null characters and 8-bit arbitrary binary data, including null characters and 8-bit
characters. They are stored as a uint32 containing its length characters. They are stored as a uint32 containing its length
(number of bytes that follow) and zero (= empty string) or more (number of bytes that follow) and zero (= empty string) or more
bytes that are the value of the string. Terminating null bytes that are the value of the string. Terminating null
characters are not used. characters are not used.
Strings are also used to store text. In that case, US-ASCII is Strings are also used to store text. In that case, US-ASCII is
used for internal names, and ISO-10646 UTF-8 for text that might used for internal names, and ISO-10646 UTF-8 for text that might
be displayed to the user. The terminating null character SHOULD be displayed to the user. The terminating null character SHOULD
NOT normally be stored in the string. NOT normally be stored in the string. For example: the US-ASCII
string "testing" is represented as 00 00 00 07 t e s t i n g. The
For example, the US-ASCII string "testing" is represented as 00 00 UTF8 mapping does not alter the encoding of US-ASCII characters.
00 07 t e s t i n g. The UTF8 mapping does not alter the encoding
of US-ASCII characters.
mpint mpint
Represents multiple precision integers in two's complement format, Represents multiple precision integers in two's complement format,
stored as a string, 8 bits per byte, MSB first. Negative numbers stored as a string, 8 bits per byte, MSB first. Negative numbers
have the value 1 as the most significant bit of the first byte of have the value 1 as the most significant bit of the first byte of
the data partition. If the most significant bit would be set for the data partition. If the most significant bit would be set for
a positive number, the number MUST be preceded by a zero byte. a positive number, the number MUST be preceded by a zero byte.
Unnecessary leading bytes with the value 0 or 255 MUST NOT be Unnecessary leading bytes with the value 0 or 255 MUST NOT be
included. The value zero MUST be stored as a string with zero included. The value zero MUST be stored as a string with zero
bytes of data. bytes of data.
By convention, a number that is used in modular computations in By convention, a number that is used in modular computations in
Z_n SHOULD be represented in the range 0 <= x < n. Z_n SHOULD be represented in the range 0 <= x < n.
Examples: Examples:
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
name-list name-list
A string containing a comma separated list of names. A name list A string containing a comma-separated list of names. A name-list
is represented as a uint32 containing its length (number of bytes is represented as a uint32 containing its length (number of bytes
that follow) followed by a comma-separated list of zero or more that follow) followed by a comma-separated list of zero or more
names. A name MUST be non-zero length, and it MUST NOT contain a names. A name MUST be non-zero length, and it MUST NOT contain a
comma (","). Context may impose additional restrictions on the comma (","). Context may impose additional restrictions on the
names; for example, the names in a list may have to be valid names; for example, the names in a name-list may have to be valid
algorithm identifier (see Section 6 below), or [RFC3066] language algorithm identifier (see Section 6 below), or [RFC3066] language
tags. The order of the names in a list may or may not be tags. The order of the names in a name-list may or may not be
significant, also depending on the context where the list is is significant. Again, this depends on the context where the list is
used. Terminating NUL characters are not used, neither for the used. Terminating NUL characters are not used; neither for the
individual names, nor for the list as a whole. individual names, nor for the list as a whole.
Examples: Examples:
value representation (hex) value representation (hex)
--------------------------------------- ----- --------------------
(), the empty list 00 00 00 00 (), the empty name-list 00 00 00 00
("zlib") 00 00 00 04 7a 6c 69 62 ("zlib") 00 00 00 04 7a 6c 69 62
("zlib", "none") 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65 ("zlib", "none") 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65
6. Algorithm and Method Naming 6. Algorithm and Method 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 methods by names. There compression, and key exchange algorithms or methods by names. There
are some standard algorithms and methods that all implementations are some standard algorithms and methods that all implementations
MUST support. There are also algorithms and methods that are defined MUST support. There are also algorithms and methods that are defined
in the protocol specification but are OPTIONAL. Furthermore, it is in the protocol specification but are OPTIONAL. Furthermore, it is
skipping to change at page 10, line 29 skipping to change at page 10, line 29
There are two formats for algorithm and method names: There are two formats for algorithm and method names:
o Names that do not contain an at-sign ("@") are reserved to be o Names that do not contain an at-sign ("@") are reserved to be
assigned by IETF CONSENSUS. Examples include "3des-cbc", "sha-1", assigned by IETF CONSENSUS. Examples include "3des-cbc", "sha-1",
"hmac-sha1", and "zlib" (the doublequotes are not part of the "hmac-sha1", and "zlib" (the doublequotes are not part of the
name). Names of this format are only valid if they are first name). Names of this format are only valid if they are first
registered with the IANA. Registered names MUST NOT contain an registered with the IANA. Registered names MUST NOT contain an
at-sign ("@"), a comma (","), or whitespace or control characters at-sign ("@"), a comma (","), or whitespace or control characters
(ASCII codes 32 or less). Names are case-sensitive, and MUST NOT (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT
be longer than 64 characters. be longer than 64 characters.
o Anyone can define additional algorithms or methods by using names o Anyone can define additional algorithms or methods by using names
in the format name@domainname, e.g. "ourcipher-cbc@example.com". in the format name@domainname, e.g., "ourcipher-cbc@example.com".
The format of the part preceding the at sign is not specified, The format of the part preceding the at-sign is not specified,
however these names MUST be printable US-ASCII strings, and MUST however these names MUST be printable US-ASCII strings, and MUST
NOT contain the comma character (","), whitespace, or control NOT contain the comma character (","), whitespace, or control
characters (ASCII codes 32 or less). The part following the characters (ASCII codes 32 or less). The part following the
at-sign MUST be a valid, fully qualified domain name [RFC1034] at-sign MUST be a valid, fully qualified domain name [RFC1034]
controlled by the person or organization defining the name. Names controlled by the person or organization defining the name. Names
are case-sensitive, and MUST NOT be longer than 64 characters. It are case-sensitive, and MUST NOT be longer than 64 characters. It
is up to each domain how it manages its local namespace. It is up to each domain how it manages its local namespace. It
should be noted that these names resemble STD 11 [RFC0822] email should be noted that these names resemble STD 11 [RFC0822] email
addresses. This is purely coincidental and actually has nothing addresses. This is purely coincidental and actually has nothing
to do with STD 11 [RFC0822]. to do with STD 11 [RFC0822].
7. Message Numbers 7. Message Numbers
SSH packets have message numbers in the range 1 to 255. These SSH packets have message numbers in the range 1 to 255. These
numbers have been allocated as follows: numbers have been allocated as follows:
Transport layer protocol: Transport layer protocol:
1 to 19 Transport layer generic (e.g. disconnect, ignore, 1 to 19 Transport layer generic (e.g., disconnect, ignore,
debug, etc.) debug, etc.)
20 to 29 Algorithm negotiation 20 to 29 Algorithm negotiation
30 to 49 Key exchange method specific (numbers can be reused 30 to 49 Key exchange method specific (numbers can be reused
for different authentication methods) for different authentication methods)
User authentication protocol: User authentication protocol:
50 to 59 User authentication generic 50 to 59 User authentication generic
60 to 79 User authentication method specific (numbers can be 60 to 79 User authentication method specific (numbers can be
reused for different authentication methods) reused for different authentication methods)
skipping to change at page 11, line 32 skipping to change at page 11, line 32
Local extensions: Local extensions:
192 to 255 Local extensions 192 to 255 Local extensions
8. IANA Considerations 8. IANA Considerations
This document is part of a set. The instructions for the IANA for This document is part of a set. The instructions for the IANA for
the SSH protocol as defined in this document, [SSH-USERAUTH], the SSH protocol as defined in this document, [SSH-USERAUTH],
[SSH-TRANS], and [SSH-CONNECT], are detailed in [SSH-NUMBERS]. The [SSH-TRANS], and [SSH-CONNECT], are detailed in [SSH-NUMBERS]. The
following is a brief summary for convenience, but note well that following is a brief summary for convenience, but note well that
[SSH-NUMBERS] is the actual instructions to the IANA, which may be [SSH-NUMBERS] contains the actual instructions to the IANA, which may
superceded in the future. be superceded in the future.
Allocation of the following types of names in the SSH protocols is Allocation of the following types of names in the SSH protocols is
assigned by IETF consensus: assigned by IETF consensus:
o Service Names o Service Names
* Authentication Methods * Authentication Methods
* Connection Protocol Channel Names * Connection Protocol Channel Names
* Connection Protocol Global Request Names * Connection Protocol Global Request Names
* Connection Protocol Channel Request Names * Connection Protocol Channel Request Names
o Key Exchange Method Names o Key Exchange Method Names
o Assigned Algorithm Names o Assigned Algorithm Names
skipping to change at page 16, line 47 skipping to change at page 16, line 47
of data, and the smallest possible packet is 16 bytes. Therefore, of data, and the smallest possible packet is 16 bytes. Therefore,
rekeying SHOULD happen after 2**28 packets at the very most. rekeying SHOULD happen after 2**28 packets at the very most.
9.2.3 Replay 9.2.3 Replay
The use of a MAC other than 'none' provides integrity and The use of a MAC other than 'none' provides integrity and
authentication. In addition, the transport protocol provides a authentication. In addition, the transport protocol provides a
unique session identifier (bound in part to pseudo-random data that unique session identifier (bound in part to pseudo-random data that
is part of the algorithm and key exchange process) that can be used is part of the algorithm and key exchange process) that can be used
by higher level protocols to bind data to a given session and prevent by higher level protocols to bind data to a given session and prevent
replay of data from prior sessions. For example, the authentication replay of data from prior sessions. For example: the authentication
protocol uses this to prevent replay of signatures from previous protocol uses this to prevent replay of signatures from previous
sessions. Because public key authentication exchanges are sessions. Because public key authentication exchanges are
cryptographically bound to the session (i.e., to the initial key cryptographically bound to the session (i.e., to the initial key
exchange) they cannot be successfully replayed in other sessions. exchange) they cannot be successfully replayed in other sessions.
Note that the session ID can be made public without harming the Note that the session ID can be made public without harming the
security of the protocol. security of the protocol.
If two sessions happen to have the same session ID (hash of key If two sessions happen to have the same session ID (hash of key
exchanges) then packets from one can be replayed against the other. exchanges) then packets from one can be replayed against the other.
It must be stressed that the chances of such an occurrence are, It must be stressed that the chances of such an occurrence are,
skipping to change at page 19, line 4 skipping to change at page 19, line 4
will be able to monitor and manipulate all of the traffic between the will be able to monitor and manipulate all of the traffic between the
clients and the legitimate servers. Server administrators are clients and the legitimate servers. Server administrators are
encouraged to make host key fingerprints available for checking by encouraged to make host key fingerprints available for checking by
some means whose security does not rely on the integrity of the some means whose security does not rely on the integrity of the
actual host keys. Possible mechanisms are discussed in Section Host actual host keys. Possible mechanisms are discussed in Section Host
Keys (Section 4.1) and may also include secured Web pages, physical Keys (Section 4.1) and may also include secured Web pages, physical
pieces of paper, etc. Implementors SHOULD provide recommendations on pieces of paper, etc. Implementors SHOULD provide recommendations on
how best to do this with their implementation. Because the protocol how best to do this with their implementation. Because the protocol
is extensible, future extensions to the protocol may provide better is extensible, future extensions to the protocol may provide better
mechanisms for dealing with the need to know the server's host key mechanisms for dealing with the need to know the server's host key
before connecting. For example, making the host key fingerprint before connecting. For example: making the host key fingerprint
available through a secure DNS lookup, or using Kerberos ([RFC1510]) available through a secure DNS lookup, or using Kerberos ([RFC1510])
over GSS-API ([RFC1964]) during key exchange to authenticate the over GSS-API ([RFC1964]) during key exchange to authenticate the
server are possibilities. server are possibilities.
In the third man-in-the-middle case, attackers may attempt to In the third man-in-the-middle case, attackers may attempt to
manipulate packets in transit between peers after the session has manipulate packets in transit between peers after the session has
been established. As described in the Replay part of this section, a been established. As described in the Replay part of this section, a
successful attack of this nature is very improbable. As in the successful attack of this nature is very improbable. As in the
Replay section, this reasoning does assume that the MAC is secure and Replay section, this reasoning does assume that the MAC is secure and
that it is infeasible to construct inputs to a MAC algorithm to give that it is infeasible to construct inputs to a MAC algorithm to give
skipping to change at page 19, line 48 skipping to change at page 19, line 48
This protocol is designed to be used over a reliable transport. If This protocol is designed to be used over a reliable transport. If
transmission errors or message manipulation occur, the connection is transmission errors or message manipulation occur, the connection is
closed. The connection SHOULD be re-established if this occurs. closed. The connection SHOULD be re-established if this occurs.
Denial of service attacks of this type ("wire cutter") are almost Denial of service attacks of this type ("wire cutter") are almost
impossible to avoid. impossible to avoid.
In addition, this protocol is vulnerable to Denial of Service attacks In addition, this protocol is vulnerable to Denial of Service attacks
because an attacker can force the server to go through the CPU and because an attacker can force the server to go through the CPU and
memory intensive tasks of connection setup and key exchange without memory intensive tasks of connection setup and key exchange without
authenticating. Implementors SHOULD provide features that make this authenticating. Implementors SHOULD provide features that make this
more difficult. For example, only allowing connections from a subset more difficult - for example: only allowing connections from a subset
of IPs known to have valid users. of IPs known to have valid users.
9.2.6 Covert Channels 9.2.6 Covert Channels
The protocol was not designed to eliminate covert channels. For The protocol was not designed to eliminate covert channels. For
example, the padding, SSH_MSG_IGNORE messages, and several other example, the padding, SSH_MSG_IGNORE messages, and several other
places in the protocol can be used to pass covert information, and places in the protocol can be used to pass covert information, and
the recipient has no reliable way to verify whether such information the recipient has no reliable way to verify whether such information
is being sent. is being sent.
skipping to change at page 21, line 22 skipping to change at page 21, line 22
The server may go into a "sleep" period after repeated unsuccessful The server may go into a "sleep" period after repeated unsuccessful
authentication attempts to make key search more difficult for authentication attempts to make key search more difficult for
attackers. Care should be taken so that this doesn't become a attackers. Care should be taken so that this doesn't become a
self-denial of service vector. self-denial of service vector.
9.3.1 Weak Transport 9.3.1 Weak Transport
If the transport layer does not provide confidentiality, If the transport layer does not provide confidentiality,
authentication methods that rely on secret data SHOULD be disabled. authentication methods that rely on secret data SHOULD be disabled.
If it does not provide strong integrity protection, requests to If it does not provide strong integrity protection, requests to
change authentication data (e.g. a password change) SHOULD be change authentication data (e.g., a password change) SHOULD be
disabled to prevent an attacker from modifying the ciphertext without disabled to prevent an attacker from modifying the ciphertext without
being noticed, or rendering the new authentication data unusable being noticed, or rendering the new authentication data unusable
(denial of service). (denial of service).
The assumption as stated above that the Authentication Protocol only The assumption as stated above that the Authentication Protocol only
run over a secure transport that has previously authenticated the run over a secure transport that has previously authenticated the
server is very important to note. People deploying SSH are reminded server is very important to note. People deploying SSH are reminded
of the consequences of man-in-the-middle attacks if the client does of the consequences of man-in-the-middle attacks if the client does
not have a very strong a priori association of the server with the not have a very strong a priori association of the server with the
host key of that server. Specifically for the case of the host key of that server. Specifically for the case of the
skipping to change at page 22, line 21 skipping to change at page 22, line 21
is taken to enable debugging messages. is taken to enable debugging messages.
9.3.3 Local Security Policy 9.3.3 Local Security Policy
Implementer MUST ensure that the credentials provided validate the Implementer MUST ensure that the credentials provided validate the
professed user and also MUST ensure that the local policy of the professed user and also MUST ensure that the local policy of the
server permits the user the access requested. In particular, because server permits the user the access requested. In particular, because
of the flexible nature of the SSH connection protocol, it may not be of the flexible nature of the SSH connection protocol, it may not be
possible to determine the local security policy, if any, that should possible to determine the local security policy, if any, that should
apply at the time of authentication because the kind of service being apply at the time of authentication because the kind of service being
requested is not clear at that instant. For example, local policy requested is not clear at that instant. For example: local policy
might allow a user to access files on the server, but not start an might allow a user to access files on the server, but not start an
interactive shell. However, during the authentication protocol, it interactive shell. However, during the authentication protocol, it
is not known whether the user will be accessing files or attempting is not known whether the user will be accessing files or attempting
to use an interactive shell, or even both. In any event, where local to use an interactive shell, or even both. In any event, where local
security policy for the server host exists, it MUST be applied and security policy for the server host exists, it MUST be applied and
enforced correctly. enforced correctly.
Implementors are encouraged to provide a default local policy and Implementors are encouraged to provide a default local policy and
make its parameters known to administrators and users. At the make its parameters known to administrators and users. At the
discretion of the implementors, this default policy may be along the discretion of the implementors, this default policy may be along the
skipping to change at page 23, line 18 skipping to change at page 23, line 18
9.3.5 Password Authentication 9.3.5 Password Authentication
The password mechanism as specified in the authentication protocol The password mechanism as specified in the authentication protocol
assumes that the server has not been compromised. If the server has assumes that the server has not been compromised. If the server has
been compromised, using password authentication will reveal a valid been compromised, using password authentication will reveal a valid
username / password combination to the attacker, which may lead to username / password combination to the attacker, which may lead to
further compromises. further compromises.
This vulnerability can be mitigated by using an alternative form of This vulnerability can be mitigated by using an alternative form of
authentication. For example, public-key authentication makes no authentication. For example: public-key authentication makes no
assumptions about security on the server. assumptions about security on the server.
9.3.6 Host Based Authentication 9.3.6 Host Based Authentication
Host based authentication assumes that the client has not been Host based authentication assumes that the client has not been
compromised. There are no mitigating strategies, other than to use compromised. There are no mitigating strategies, other than to use
host based authentication in combination with another authentication host based authentication in combination with another authentication
method. method.
9.4 Connection Protocol 9.4 Connection Protocol
skipping to change at page 24, line 36 skipping to change at page 24, line 36
unauthorized use of the X11 server. Implementors, administrators and unauthorized use of the X11 server. Implementors, administrators and
users who wish to further explore the security mechanisms of X11 are users who wish to further explore the security mechanisms of X11 are
invited to read [SCHEIFLER] and analyze previously reported problems invited to read [SCHEIFLER] and analyze previously reported problems
with the interactions between SSH forwarding and X11 in CERT with the interactions between SSH forwarding and X11 in CERT
vulnerabilities VU#363181 and VU#118892 [CERT]. vulnerabilities VU#363181 and VU#118892 [CERT].
X11 display forwarding with SSH, by itself, is not sufficient to X11 display forwarding with SSH, by itself, is not sufficient to
correct well known problems with X11 security [VENEMA]. However, X11 correct well known problems with X11 security [VENEMA]. However, X11
display forwarding in SSH (or other, secure protocols), combined with display forwarding in SSH (or other, secure protocols), combined with
actual and pseudo-displays which accept connections only over local actual and pseudo-displays which accept connections only over local
IPC mechanisms authorized by permissions or ACLs, does correct many IPC mechanisms authorized by permissions or access control lists
X11 security problems as long as the "none" MAC is not used. It is (ACLs), does correct many X11 security problems as long as the "none"
RECOMMENDED that X11 display implementations default to allowing MAC is not used. It is RECOMMENDED that X11 display implementations
display opens only over local IPC. It is RECOMMENDED that SSH server default to allowing display opens only over local IPC. It is
implementations that support X11 forwarding default to allowing RECOMMENDED that SSH server implementations that support X11
display opens only over local IPC. On single-user systems it might forwarding default to allowing display opens only over local IPC. On
be reasonable to default to allowing local display opens over TCP/IP. single-user systems it might be reasonable to default to allowing
local display opens over TCP/IP.
Implementors of the X11 forwarding protocol SHOULD implement the Implementors of the X11 forwarding protocol SHOULD implement the
magic cookie access checking spoofing mechanism as described in magic cookie access checking spoofing mechanism as described in
[SSH-CONNECT] as an additional mechanism to prevent unauthorized use [SSH-CONNECT] as an additional mechanism to prevent unauthorized use
of the proxy. of the proxy.
10. References 10. References
10.1 Normative References 10.1 Normative References
[SSH-TRANS] [SSH-TRANS]
Lonvick, C., "SSH Transport Layer Protocol", I-D Lonvick, C., "SSH Transport Layer Protocol", I-D
draft-ietf-transport-20.txt, October 2004. draft-ietf-transport-21.txt, November 2004.
[SSH-USERAUTH] [SSH-USERAUTH]
Lonvick, C., "SSH Authentication Protocol", I-D Lonvick, C., "SSH Authentication Protocol", I-D
draft-ietf-userauth-23.txt, October 2004. draft-ietf-userauth-24.txt, November 2004.
[SSH-CONNECT] [SSH-CONNECT]
Lonvick, C., "SSH Connection Protocol", I-D Lonvick, C., "SSH Connection Protocol", I-D
draft-ietf-connect-21.txt, October 2004. draft-ietf-connect-22.txt, November 2004.
[SSH-NUMBERS] [SSH-NUMBERS]
Lonvick, C., "SSH Protocol Assigned Numbers", I-D Lonvick, C., "SSH Protocol Assigned Numbers", I-D
draft-ietf-assignednumbers-08.txt, October 2004. draft-ietf-assignednumbers-09.txt, November 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
10.2 Informative References 10.2 Informative References
[FIPS-186-2] [FIPS-186-2]
Federal Information Processing Standards Publication, Federal Information Processing Standards Publication,
"FIPS PUB 186-2, Digital Signature Standard (DSS)", "FIPS PUB 186-2, Digital Signature Standard (DSS)",
January 2000. January 2000.
[FIPS-197] [FIPS-197]
National Institute of Standards and Technology, "FIPS 197, National Institute of Standards and Technology, "FIPS 197,
Specification for the Advanced Encryption Standard", Specification for the Advanced Encryption Standard",
skipping to change at page 26, line 35 skipping to change at page 26, line 46
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104, Keyed-Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998. Its Use With IPsec", RFC 2410, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86, Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, April 2004. RFC 3766, April 2004.
[SCHNEIER] [SCHNEIER]
Schneier, B., "Applied Cryptography Second Edition: Schneier, B., "Applied Cryptography Second Edition:
protocols algorithms and source in code in C", 1996. protocols algorithms and source in code in C", 1996.
[KAUFMAN,PERLMAN,SPECINER] [KAUFMAN,PERLMAN,SPECINER]
 End of changes. 

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