draft-ietf-secsh-architecture-16.txt   draft-ietf-secsh-architecture-17.txt 
Network Working Group T. Ylonen Network Working Group C. Lonvick, Ed.
Internet-Draft SSH Communications Security Corp Internet-Draft Cisco Systems, Inc
Expires: December 1, 2004 C. Lonvick, Ed. Expires: April 24, 2005 October 24, 2004
Cisco Systems, Inc
June 2, 2004
SSH Protocol Architecture SSH Protocol Architecture
draft-ietf-secsh-architecture-16.txt draft-ietf-secsh-architecture-17.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of section 3 of RFC 3667. By submitting this Internet-Draft, each
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 become aware will be disclosed, in accordance with
RFC 3668.
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 December 1, 2004. This Internet-Draft will expire on April 24, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. 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
terminology used in SSH protocol documents. The SSH protocol terminology used in SSH protocol documents. It also discusses the
consists of three major components: The Transport Layer Protocol SSH algorithm naming system that allows local extensions. The SSH
provides server authentication, confidentiality, and integrity with protocol consists of three major components: The Transport Layer
perfect forward secrecy. Details of these protocols are described in Protocol provides server authentication, confidentiality, and
separate documents. integrity with perfect forward secrecy. The User Authentication
Protocol authenticates the client to the server. The 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. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Specification of Requirements . . . . . . . . . . . . . . . . 3 3. Specification of Requirements . . . . . . . . . . . . . . . . 3
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1 Host Keys . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1 Host Keys . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . 5
4.3 Policy Issues . . . . . . . . . . . . . . . . . . . . . . 6 4.3 Policy Issues . . . . . . . . . . . . . . . . . . . . . . 6
4.4 Security Properties . . . . . . . . . . . . . . . . . . . 6 4.4 Security Properties . . . . . . . . . . . . . . . . . . . 6
4.5 Packet Size and Overhead . . . . . . . . . . . . . . . . . 7 4.5 Packet Size and Overhead . . . . . . . . . . . . . . . . . 7
4.6 Localization and Character Set Support . . . . . . . . . . 7 4.6 Localization and Character Set Support . . . . . . . . . . 7
5. Data Type Representations Used in the SSH Protocols . . . . . 8 5. Data Type Representations Used in the SSH Protocols . . . . . 8
6. Algorithm Naming . . . . . . . . . . . . . . . . . . . . . . . 10 6. Algorithm and Method Naming . . . . . . . . . . . . . . . . . 10
7. Message Numbers . . . . . . . . . . . . . . . . . . . . . . . 11 7. Message Numbers . . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9.1 Pseudo-Random Number Generation . . . . . . . . . . . . . 13 9.1 Pseudo-Random Number Generation . . . . . . . . . . . . . 13
9.2 Transport . . . . . . . . . . . . . . . . . . . . . . . . 13 9.2 Transport . . . . . . . . . . . . . . . . . . . . . . . . 14
9.2.1 Confidentiality . . . . . . . . . . . . . . . . . . . 13 9.2.1 Confidentiality . . . . . . . . . . . . . . . . . . . 14
9.2.2 Data Integrity . . . . . . . . . . . . . . . . . . . . 16 9.2.2 Data Integrity . . . . . . . . . . . . . . . . . . . . 16
9.2.3 Replay . . . . . . . . . . . . . . . . . . . . . . . . 16 9.2.3 Replay . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2.4 Man-in-the-middle . . . . . . . . . . . . . . . . . . 17 9.2.4 Man-in-the-middle . . . . . . . . . . . . . . . . . . 17
9.2.5 Denial-of-service . . . . . . . . . . . . . . . . . . 19 9.2.5 Denial-of-service . . . . . . . . . . . . . . . . . . 19
9.2.6 Covert Channels . . . . . . . . . . . . . . . . . . . 20 9.2.6 Covert Channels . . . . . . . . . . . . . . . . . . . 20
9.2.7 Forward Secrecy . . . . . . . . . . . . . . . . . . . 20 9.2.7 Forward Secrecy . . . . . . . . . . . . . . . . . . . 20
9.2.8 Ordering of Key Exchange Methods . . . . . . . . . . . 20
9.3 Authentication Protocol . . . . . . . . . . . . . . . . . 20 9.3 Authentication Protocol . . . . . . . . . . . . . . . . . 20
9.3.1 Weak Transport . . . . . . . . . . . . . . . . . . . . 21 9.3.1 Weak Transport . . . . . . . . . . . . . . . . . . . . 21
9.3.2 Debug Messages . . . . . . . . . . . . . . . . . . . . 21 9.3.2 Debug Messages . . . . . . . . . . . . . . . . . . . . 21
9.3.3 Local Security Policy . . . . . . . . . . . . . . . . 22 9.3.3 Local Security Policy . . . . . . . . . . . . . . . . 22
9.3.4 Public Key Authentication . . . . . . . . . . . . . . 22 9.3.4 Public Key Authentication . . . . . . . . . . . . . . 22
9.3.5 Password Authentication . . . . . . . . . . . . . . . 22 9.3.5 Password Authentication . . . . . . . . . . . . . . . 23
9.3.6 Host Based Authentication . . . . . . . . . . . . . . 23 9.3.6 Host Based Authentication . . . . . . . . . . . . . . 23
9.4 Connection Protocol . . . . . . . . . . . . . . . . . . . 23 9.4 Connection Protocol . . . . . . . . . . . . . . . . . . . 23
9.4.1 End Point Security . . . . . . . . . . . . . . . . . . 23 9.4.1 End Point Security . . . . . . . . . . . . . . . . . . 23
9.4.2 Proxy Forwarding . . . . . . . . . . . . . . . . . . . 23 9.4.2 Proxy Forwarding . . . . . . . . . . . . . . . . . . . 24
9.4.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . 24 9.4.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 24 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 25
10.2 Informative References . . . . . . . . . . . . . . . . . . . 25 10.2 Informative References . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . 29
1. Contributors 1. Contributors
The major original contributors of this document were: Tatu Ylonen, The major original contributors of this document were: Tatu Ylonen,
Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH 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 document and also made very substantial contributions.
Additional contributors to this document include [need list]. Additional contributors to this document include [need list].
skipping to change at page 4, line 5 skipping to change at page 4, line 5
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 range of purposes. Standard methods are provided for setting up
secure interactive shell sessions and for forwarding ("tunneling") secure interactive shell sessions and for forwarding ("tunneling")
arbitrary TCP/IP ports and X11 connections. arbitrary TCP/IP ports and X11 connections.
3. Specification of Requirements 3. Specification of Requirements
All documents related to the SSH protocols shall use the keywords All documents related to the SSH protocols shall use the keywords
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe
requirements. They are to be interpreted as described in [RFC2119]. requirements. These keywords are to be interpreted as described in
[RFC2119].
All documents related to the SSH protocols shall use the keywords
"PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME FIRST SERVED",
"EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG APPROVAL", "IETF
CONSENSUS", and "STANDARDS ACTION" to describe namespace allocation.
These keywords are to be interpreted as described in [RFC2434].
4. Architecture 4. Architecture
4.1 Host Keys 4.1 Host Keys
Each server host SHOULD have a host key. Hosts MAY have multiple Each server host SHOULD have a host key. Hosts MAY have multiple
host keys using multiple different algorithms. Multiple hosts MAY host keys using multiple different algorithms. Multiple hosts MAY
share the same host key. If a host has keys at all, it MUST have at share the same host key. If a host has keys at all, it MUST have at
least one key using each REQUIRED public key algorithm (DSS least one key using each REQUIRED public key algorithm (DSS
[FIPS-186-2]). [FIPS-186-2]).
skipping to change at page 6, line 29 skipping to change at page 6, line 37
public key algorithms also affects this choice. public key algorithms also affects this choice.
o The authentication methods that are to be required by the server o The authentication methods that are to be required by the server
for each user. The server's policy MAY require multiple for each user. The server's policy MAY require multiple
authentication for some or all users. The required algorithms MAY authentication for some or all users. The required algorithms MAY
depend on the location where the user is trying to log in from. depend on the location where the user is trying to log in from.
o The operations that the user is allowed to perform using the o The operations that the user is allowed to perform using the
connection protocol. Some issues are related to security; for connection protocol. Some issues are related to security; for
example, the policy SHOULD NOT allow the server to start sessions example, the policy SHOULD NOT allow the server to start sessions
or run commands on the client machine, and MUST NOT allow or run commands on the client machine, and MUST NOT allow
connections to the authentication agent unless forwarding such connections to the authentication agent unless forwarding such
connections has been requested. Other issues, such as which TCP/ connections has been requested. Other issues, such as which
IP ports can be forwarded and by whom, are clearly issues of local TCP/IP ports can be forwarded and by whom, are clearly issues of
policy. Many of these issues may involve traversing or bypassing local policy. Many of these issues may involve traversing or
firewalls, and are interrelated with the local security policy. bypassing firewalls, and are interrelated with the local security
policy.
4.4 Security Properties 4.4 Security Properties
The primary goal of the SSH protocol is to improve security on the The primary goal of the SSH protocol is to improve security on the
Internet. It attempts to do this in a way that is easy to deploy, Internet. It attempts to do this in a way that is easy to deploy,
even at the cost of absolute security. even at the cost of absolute security.
o All encryption, integrity, and public key algorithms used are o All encryption, integrity, and public key algorithms used are
well-known, well-established algorithms. well-known, well-established algorithms.
o All algorithms are used with cryptographically sound key sizes o All algorithms are used with cryptographically sound key sizes
that are believed to provide protection against even the strongest that are believed to provide protection against even the strongest
skipping to change at page 7, line 42 skipping to change at page 8, line 4
minimize delays in screen updates, one does not want excessively minimize delays in screen updates, one does not want excessively
large packets for interactive sessions. The maximum packet size is large packets for interactive sessions. The maximum packet size is
negotiated separately for each channel. negotiated separately for each channel.
4.6 Localization and Character Set Support 4.6 Localization and Character Set Support
For the most part, the SSH protocols do not directly pass text that For the most part, the SSH protocols do not directly pass text that
would be displayed to the user. However, there are some places where would be displayed to the user. However, there are some places where
such data might be passed. When applicable, the character set for such data might be passed. When applicable, the character set for
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 [RFC2279]. 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 10, line 4 skipping to change at page 10, line 10
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 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 list may or may not be
significant, also depending on the context where the list is is significant, also depending on the context where the list is 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 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 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 protocols by names. compression, and key exchange algorithms or methods by names. There
There are some standard algorithms that all implementations MUST are some standard algorithms and methods that all implementations
support. There are also algorithms that are defined in the protocol MUST support. There are also algorithms and methods that are defined
specification but are OPTIONAL. Furthermore, it is expected that in the protocol specification but are OPTIONAL. Furthermore, it is
some organizations will want to use their own algorithms. expected that some organizations will want to use their own
algorithms or methods.
In this protocol, all algorithm identifiers MUST be printable In this protocol, all algorithm and method identifiers MUST be
US-ASCII non-empty strings no longer than 64 characters. Names MUST printable US-ASCII, non-empty strings no longer than 64 characters.
be case-sensitive. Names MUST be case-sensitive.
There are two formats for algorithm 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 (RFCs). Examples include `3des-cbc', assigned by IETF CONSENSUS. Examples include "3des-cbc", "sha-1",
`sha-1', `hmac-sha1', and `zlib' (the quotes are not part of the "hmac-sha1", and "zlib" (the doublequotes are not part of the
name). Names of this format MUST NOT be used without first name). Names of this format are only valid if they are first
registering them. Registered names MUST NOT contain an at-sign registered with the IANA. Registered names MUST NOT contain an
(@) or a comma (,). at-sign ("@"), a comma (","), or whitespace or control characters
o Anyone can define additional algorithms by using names in the (ASCII codes 32 or less). Names are case-sensitive, and MUST NOT
format name@domainname, e.g. "ourcipher-cbc@example.com". The be longer than 64 characters.
format of the part preceding the at sign is not specified; it MUST o Anyone can define additional algorithms or methods by using names
consist of US-ASCII characters except at-sign and comma. The part in the format name@domainname, e.g. "ourcipher-cbc@example.com".
following the at-sign MUST be a valid fully qualified internet The format of the part preceding the at sign is not specified,
domain name [RFC1034] controlled by the person or organization however these names MUST be printable US-ASCII strings, and MUST
defining the name. It is up to each domain how it manages its NOT contain the comma character (","), whitespace, or control
local namespace. characters (ASCII codes 32 or less). The part following the
at-sign MUST be a valid, fully qualified domain name [RFC1034]
controlled by the person or organization defining the name. Names
are case-sensitive, and MUST NOT be longer than 64 characters. It
is up to each domain how it manages its local namespace. It
should be noted that these names resemble [RFC0822] email
addresses. This is purely coincidental and actually has nothing
to do with [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, debug, 1 to 19 Transport layer generic (e.g. disconnect, ignore,
etc.) debug, 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
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)
Connection protocol: Connection protocol:
80 to 89 Connection protocol generic 80 to 89 Connection protocol generic
skipping to change at page 11, line 34 skipping to change at page 12, line 4
reused for different authentication methods) reused for different authentication methods)
Connection protocol: Connection protocol:
80 to 89 Connection protocol generic 80 to 89 Connection protocol generic
90 to 127 Channel related messages 90 to 127 Channel related messages
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
8. IANA Considerations 8. IANA Considerations
This document is part of a set. The instructions for IANA for the This document is part of a set. The instructions for the IANA for
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 initial instructions to the IANA, which [SSH-NUMBERS] is the actual instructions to the IANA, which may be
may be superceded in the future. 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 SSH encryption algorithm names, o Service Names
o SSH MAC algorithm names, * Authentication Methods
o SSH public key algorithm names (public key algorithm also implies * Connection Protocol Channel Names
encoding and signature/encryption capability), * Connection Protocol Global Request Names
o SSH key exchange method names, and * Connection Protocol Channel Request Names
o SSH protocol (service) names. o Key Exchange Method Names
o Assigned Algorithm Names
* Encryption Algorithm Names
* MAC Algorithm Names
* Public Key Algorithm Names
* Compression Algorithm Names
These names MUST be printable US-ASCII strings, and MUST NOT contain These names MUST be printable US-ASCII strings, and MUST NOT contain
the characters at-sign ('@'), comma (','), or whitespace or control the characters at-sign ("@"), comma (","), or whitespace or control
characters (ASCII codes 32 or less). Names are case-sensitive, and characters (ASCII codes 32 or less). Names are case-sensitive, and
MUST NOT be longer than 64 characters. MUST NOT be longer than 64 characters.
Names with the at-sign ('@') in them are allocated by the owner of Names with the at-sign ("@") in them are locally defined extensions
DNS name after the at-sign (hierarchical allocation in [RFC2434]), and are not controlled by the IANA.
otherwise the same restrictions as above.
Each category of names listed above has a separate namespace. Each category of names listed above has a separate namespace.
However, using the same name in multiple categories SHOULD be avoided However, using the same name in multiple categories SHOULD be avoided
to minimize confusion. to minimize confusion.
Message numbers (see Section Message Numbers (Section 7)) in the Message numbers (see Section Message Numbers (Section 7)) in the
range of 0..191 are allocated via IETF consensus as described in range of 0..191 are allocated via IETF CONSENSUS as described in
[RFC2434]. Message numbers in the 192..255 range (the "Local [RFC2434]. Message numbers in the 192..255 range (the "Local
extensions" set) are reserved for private use. extensions" set) are reserved for PRIVATE USE also as described in
[RFC2434].
9. Security Considerations 9. Security Considerations
In order to make the entire body of Security Considerations more In order to make the entire body of Security Considerations more
accessible, Security Considerations for the transport, accessible, Security Considerations for the transport,
authentication, and connection documents have been gathered here. authentication, and connection documents have been gathered here.
The transport protocol [SSH-TRANS] provides a confidential channel The transport protocol [SSH-TRANS] provides a confidential channel
over an insecure network. It performs server host authentication, over an insecure network. It performs server host authentication,
key exchange, encryption, and integrity protection. It also derives key exchange, encryption, and integrity protection. It also derives
skipping to change at page 13, line 51 skipping to change at page 14, line 26
implementors and users should check current literature to ensure that implementors and users should check current literature to ensure that
no recent vulnerabilities have been found in ciphers used within no recent vulnerabilities have been found in ciphers used within
products. Implementors should also check to see which ciphers are products. Implementors should also check to see which ciphers are
considered to be relatively stronger than others and should recommend considered to be relatively stronger than others and should recommend
their use to users over relatively weaker ciphers. It would be their use to users over relatively weaker ciphers. It would be
considered good form for an implementation to politely and considered good form for an implementation to politely and
unobtrusively notify a user that a stronger cipher is available and unobtrusively notify a user that a stronger cipher is available and
should be used when a weaker one is actively chosen. should be used when a weaker one is actively chosen.
The "none" cipher is provided for debugging and SHOULD NOT be used The "none" cipher is provided for debugging and SHOULD NOT be used
except for that purpose. It's cryptographic properties are except for that purpose. Its cryptographic properties are
sufficiently described in [RFC2410], which will show that its use sufficiently described in [RFC2410], which will show that its use
does not meet the intent of this protocol. does not meet the intent of this protocol.
The relative merits of these and other ciphers may also be found in The relative merits of these and other ciphers may also be found in
current literature. Two references that may provide information on current literature. Two references that may provide information on
the subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER] Both of the subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER] Both of
these describe the CBC mode of operation of certain ciphers and the these describe the CBC mode of operation of certain ciphers and the
weakness of this scheme. Essentially, this mode is theoretically weakness of this scheme. Essentially, this mode is theoretically
vulnerable to chosen cipher-text attacks because of the high vulnerable to chosen cipher-text attacks because of the high
predictability of the start of packet sequence. However, this attack predictability of the start of packet sequence. However, this attack
is deemed difficult and not considered fully practicable especially is deemed difficult and not considered fully practicable especially
if relatively longer block sizes are used. if relatively longer block sizes are used.
Additionally, another CBC mode attack may be mitigated through the Additionally, another CBC mode attack may be mitigated through the
insertion of packets containing SSH_MSG_IGNORE. Without this insertion of packets containing SSH_MSG_IGNORE. Without this
technique, a specific attack may be successful. For this attack technique, a specific attack may be successful. For this attack
(commonly known as the Rogaway attack (commonly known as the Rogaway attack [ROGAWAY], [DAI],
[ROGAWAY],[DAI][BELLARE,KOHNO,NAMPREMPRE],) to work, the attacker [BELLARE,KOHNO,NAMPREMPRE],) to work, the attacker would need to know
would need to know the Initialization Vector (IV) of the next block the Initialization Vector (IV) of the next block that is going to be
that is going to be encrypted. In CBC mode that is the output of the encrypted. In CBC mode that is the output of the encryption of the
encryption of the previous block. If the attacker does not have any previous block. If the attacker does not have any way to see the
way to see the packet yet (i.e., it is in the internal buffers of the packet yet (i.e., it is in the internal buffers of the SSH
SSH implementation or even in the kernel) then this attack will not implementation or even in the kernel) then this attack will not work.
work. If the last packet has been sent out to the network (i.e., the If the last packet has been sent out to the network (i.e., the
attacker has access to it) then he can use the attack. attacker has access to it) then he can use the attack.
In the optimal case an implementor would need to add an extra packet In the optimal case an implementor would need to add an extra packet
only if the packet has been sent out onto the network and there are only if the packet has been sent out onto the network and there are
no other packets waiting for transmission. Implementors may wish to no other packets waiting for transmission. Implementors may wish to
check to see if there are any unsent packets awaiting transmission, check to see if there are any unsent packets awaiting transmission,
but unfortunately it is not normally easy to obtain this information but unfortunately it is not normally easy to obtain this information
from the kernel or buffers. If there are not, then a packet from the kernel or buffers. If there are not, then a packet
containing SSH_MSG_IGNORE SHOULD be sent. If a new packet is added containing SSH_MSG_IGNORE SHOULD be sent. If a new packet is added
to the stream every time the attacker knows the IV that is supposed to the stream every time the attacker knows the IV that is supposed
skipping to change at page 16, line 16 skipping to change at page 16, line 16
situation: situation:
Client Server Client Server
------ ------ ------ ------
TCP(seq=x, len=500) ----> TCP(seq=x, len=500) ---->
contains SSH_MSG_IGNORE contains SSH_MSG_IGNORE
TCP(seq=y, len=500) ----> TCP(seq=y, len=500) ---->
contains Data contains Data
Provided that the IV for the second SSH Record is fixed after the data for Provided that the IV for the second SSH Record is fixed after the
the Data packet is determined, then the following should be performed: data for the Data packet is determined, then the following should
be performed:
read from user read from user
encrypt null packet encrypt null packet
encrypt data packet encrypt data packet
9.2.2 Data Integrity 9.2.2 Data Integrity
This protocol does allow the Data Integrity mechanism to be disabled. This protocol does allow the Data Integrity mechanism to be disabled.
Implementors SHOULD be wary of exposing this feature for any purpose Implementors SHOULD be wary of exposing this feature for any purpose
other than debugging. Users and administrators SHOULD be explicitly other than debugging. Users and administrators SHOULD be explicitly
warned anytime the "none" MAC is enabled. warned anytime the "none" MAC is enabled.
skipping to change at page 20, line 20 skipping to change at page 20, line 20
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.
9.2.7 Forward Secrecy 9.2.7 Forward Secrecy
It should be noted that the Diffie-Hellman key exchanges may provide It should be noted that the Diffie-Hellman key exchanges may provide
perfect forward secrecy (PFS). PFS is essentially defined as the perfect forward secrecy (PFS). PFS is essentially defined as the
cryptographic property of a key-establishment protocol in which the cryptographic property of a key-establishment protocol in which the
compromise of a session key or long-term private key after a given compromise of a session key or long-term private key after a given
session does not cause the compromise of any earlier session. [ANSI session does not cause the compromise of any earlier session. [ANSI
T1.523-2001] SSH sessions resulting from a key exchange using T1.523-2001] SSH sessions resulting from a key exchange using the
diffie-hellman-group1-sha1 are secure even if private keying/ diffie-hellman methods described in the section "Diffie-Hellman Key
authentication material is later revealed, but not if the session Exchange" of [SSH-TRANS] (including diffie-hellman-group1-sha1 and
keys are revealed. So, given this definition of PFS, SSH does have diffie-hellman-group14-sha1) are secure even if private
PFS. It is hoped that all other key exchange mechanisms proposed and keying/authentication material is later revealed, but not if the
used in the future will also provide PFS. This property is not session keys are revealed. So, given this definition of PFS, SSH
commuted to any of the applications or protocols using SSH as a does have PFS. This property is not commuted to any of the
transport however. The transport layer of SSH provides applications or protocols using SSH as a transport however. The
confidentiality for password authentication and other methods that transport layer of SSH provides confidentiality for password
rely on secret data. authentication and other methods that rely on secret data.
Editor's Note: diffie-hellman-group14-sha1 is controversial at the
moment. It is being discussed on the mailing list.
Of course, if the DH private parameters for the client and server are Of course, if the DH private parameters for the client and server are
revealed then the session key is revealed, but these items can be revealed then the session key is revealed, but these items can be
thrown away after the key exchange completes. It's worth pointing thrown away after the key exchange completes. It's worth pointing
out that these items should not be allowed to end up on swap space out that these items should not be allowed to end up on swap space
and that they should be erased from memory as soon as the key and that they should be erased from memory as soon as the key
exchange completes. exchange completes.
9.2.8 Ordering of Key Exchange Methods
As stated in the section on "Algorithm Negotiation" of [SSH-TRANS],
each device will send a list of preferred methods for key exchange.
The most-preferred method is the first in the list. It is
RECOMMENDED to sort the algorithms by cryptographic strength,
strongest first. Some additional guidance for this is given in
[RFC3766].
9.3 Authentication Protocol 9.3 Authentication Protocol
The purpose of this protocol is to perform client user The purpose of this protocol is to perform client user
authentication. It assumes that this run over a secure transport authentication. It assumes that this run over a secure transport
layer protocol, which has already authenticated the server machine, layer protocol, which has already authenticated the server machine,
established an encrypted communications channel, and computed a established an encrypted communications channel, and computed a
unique session identifier for this session. unique session identifier for this session.
Several authentication methods with different security Several authentication methods with different security
characteristics are allowed. It is up to the server's local policy characteristics are allowed. It is up to the server's local policy
skipping to change at page 21, line 14 skipping to change at page 21, line 26
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 disabled to prevent an attacker from modifying the ciphertext without
without being noticed, or rendering the new authentication data being noticed, or rendering the new authentication data unusable
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
Authentication Protocol the client may form a session to a Authentication Protocol the client may form a session to a
man-in-the-middle attack device and divulge user credentials such as man-in-the-middle attack device and divulge user credentials such as
their username and password. Even in the cases of authentication their username and password. Even in the cases of authentication
skipping to change at page 24, line 46 skipping to change at page 25, line 11
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]
Ylonen, T. and C. Lonvick, "SSH Transport Layer Protocol", Ylonen, T. and C. Lonvick, "SSH Transport Layer Protocol",
I-D draft-ietf-transport-18.txt, May 2004. I-D draft-ietf-transport-19.txt, October 2004.
[SSH-USERAUTH] [SSH-USERAUTH]
Ylonen, T. and C. Lonvick, "SSH Authentication Protocol", Ylonen, T. and C. Lonvick, "SSH Authentication Protocol",
I-D draft-ietf-userauth-21.txt, May 2004. I-D draft-ietf-userauth-22.txt, October 2004.
[SSH-CONNECT] [SSH-CONNECT]
Ylonen, T. and C. Lonvick, "SSH Connection Protocol", I-D Ylonen, T. and C. Lonvick, "SSH Connection Protocol", I-D
draft-ietf-connect-19.txt, May 2004. draft-ietf-connect-20.txt, October 2004.
[SSH-NUMBERS] [SSH-NUMBERS]
Ylonen, T. and C. Lonvick, "SSH Protocol Assigned Ylonen, T. and C. Lonvick, "SSH Protocol Assigned
Numbers", I-D draft-ietf-assignednumbers-06.txt, May 2004. Numbers", I-D draft-ietf-assignednumbers-07.txt, October
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.
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.
skipping to change at page 25, line 37 skipping to change at page 25, line 50
[ANSI T1.523-2001] [ANSI T1.523-2001]
American National Standards Institute, Inc., "Telecom American National Standards Institute, Inc., "Telecom
Glossary 2000", February 2001. Glossary 2000", February 2001.
[SCHEIFLER] [SCHEIFLER]
Scheifler, R., "X Window System : The Complete Reference Scheifler, R., "X Window System : The Complete Reference
to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital
Press ISBN 1555580882, February 1992. Press ISBN 1555580882, February 1992.
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983. Specification", STD 8, RFC 854, May 1983.
[RFC0894] Hornig, C., "Standard for the transmission of IP datagrams [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams
over Ethernet networks", STD 41, RFC 894, April 1984. over Ethernet networks", STD 41, RFC 894, April 1984.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1134] Perkins, D., "Point-to-Point Protocol: A proposal for [RFC1134] Perkins, D., "Point-to-Point Protocol: A proposal for
skipping to change at page 26, line 25 skipping to change at page 26, line 42
[RFC2085] Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with [RFC2085] Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with
Replay Prevention", RFC 2085, February 1997. Replay Prevention", RFC 2085, February 1997.
[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.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[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 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. 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 [RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001. 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
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
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]
Kaufman, C., Perlman, R. and M. Speciner, "Network Kaufman, C., Perlman, R. and M. Speciner, "Network
Security: PRIVATE Communication in a PUBLIC World", 1995. Security: PRIVATE Communication in a PUBLIC World", 1995.
[CERT] CERT Coordination Center, The., [CERT] CERT Coordination Center, The.,
"http://www.cert.org/nav/index_red.html". "http://www.cert.org/nav/index_red.html".
skipping to change at page 27, line 24 skipping to change at page 28, line 5
[DAI] Dai, W., "An attack against SSH2 protocol", Email to the [DAI] Dai, W., "An attack against SSH2 protocol", Email to the
SECSH Working Group ietf-ssh@netbsd.org ftp:// SECSH Working Group ietf-ssh@netbsd.org ftp://
ftp.ietf.org/ietf-mail-archive/secsh/2002-02.mail, Feb ftp.ietf.org/ietf-mail-archive/secsh/2002-02.mail, Feb
2002. 2002.
[BELLARE,KOHNO,NAMPREMPRE] [BELLARE,KOHNO,NAMPREMPRE]
Bellaire, M., Kohno, T. and C. Namprempre, "Authenticated Bellaire, M., Kohno, T. and C. Namprempre, "Authenticated
Encryption in SSH: Fixing the SSH Binary Packet Protocol", Encryption in SSH: Fixing the SSH Binary Packet Protocol",
, Sept 2002. , Sept 2002.
Authors' Addresses Author's Address
Tatu Ylonen
SSH Communications Security Corp
Fredrikinkatu 42
HELSINKI FIN-00100
Finland
EMail: ylo@ssh.com
Chris Lonvick (editor) Chris Lonvick (editor)
Cisco Systems, Inc Cisco Systems, Inc
12515 Research Blvd. 12515 Research Blvd.
Austin 78759 Austin 78759
USA USA
EMail: clonvick@cisco.com EMail: clonvick@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
Full Copyright Statement Disclaimer of Validity
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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