draft-ietf-secsh-architecture-20.txt   draft-ietf-secsh-architecture-21.txt 
Network Working Group C. Lonvick, Ed. Network Working Group C. Lonvick, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: June 9, 2005 December 9, 2004 Expires: August 21, 2005 February 17, 2005
SSH Protocol Architecture SSH Protocol Architecture
draft-ietf-secsh-architecture-20.txt draft-ietf-secsh-architecture-21.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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 June 9, 2005. This Internet-Draft will expire on August 21, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
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. It also discusses the terminology used in SSH protocol documents. It also discusses the
SSH algorithm naming system that allows local extensions. The SSH SSH algorithm naming system that allows local extensions. The SSH
protocol consists of three major components: The Transport Layer protocol consists of three major components: The Transport Layer
Protocol provides server authentication, confidentiality, and Protocol provides server authentication, confidentiality, and
integrity with perfect forward secrecy. The User Authentication integrity with perfect forward secrecy. The User Authentication
Protocol authenticates the client to the server. The Connection Protocol authenticates the client to the server. The Connection
Protocol multiplexes the encrypted tunnel into several logical Protocol multiplexes the encrypted tunnel into several logical
channels. Details of these protocols are described in separate channels. Details of these protocols are described in separate
documents. documents.
Table of Contents Table of Contents
1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Conventions Used in This Document . . . . . . . . . . . . . . 4
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Host Keys . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1 Host Keys . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Policy Issues . . . . . . . . . . . . . . . . . . . . . . 6 4.3 Policy Issues . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Security Properties . . . . . . . . . . . . . . . . . . . 6 4.4 Security Properties . . . . . . . . . . . . . . . . . . . 8
4.5 Localization and Character Set Support . . . . . . . . . . 7 4.5 Localization and Character Set Support . . . . . . . . . . 8
5. Data Type Representations Used in the SSH Protocols . . . . . 8 5. Data Type Representations Used in the SSH Protocols . . . . . 9
6. Algorithm and Method Naming . . . . . . . . . . . . . . . . . 10 6. Algorithm and Method Naming . . . . . . . . . . . . . . . . . 11
7. Message Numbers . . . . . . . . . . . . . . . . . . . . . . . 10 7. Message Numbers . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9.1 Pseudo-Random Number Generation . . . . . . . . . . . . . 12 9.1 Pseudo-Random Number Generation . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . . . 17
9.2.3 Replay . . . . . . . . . . . . . . . . . . . . . . . . 16 9.2.3 Replay . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2.4 Man-in-the-middle . . . . . . . . . . . . . . . . . . 17 9.2.4 Man-in-the-middle . . . . . . . . . . . . . . . . . . 18
9.2.5 Denial-of-service . . . . . . . . . . . . . . . . . . 19 9.2.5 Denial-of-service . . . . . . . . . . . . . . . . . . 20
9.2.6 Covert Channels . . . . . . . . . . . . . . . . . . . 20 9.2.6 Covert Channels . . . . . . . . . . . . . . . . . . . 21
9.2.7 Forward Secrecy . . . . . . . . . . . . . . . . . . . 20 9.2.7 Forward Secrecy . . . . . . . . . . . . . . . . . . . 21
9.2.8 Ordering of Key Exchange Methods . . . . . . . . . . . 20 9.2.8 Ordering of Key Exchange Methods . . . . . . . . . . . 21
9.3 Authentication Protocol . . . . . . . . . . . . . . . . . 20 9.2.9 Traffic Analysis . . . . . . . . . . . . . . . . . . . 21
9.3.1 Weak Transport . . . . . . . . . . . . . . . . . . . . 21 9.3 Authentication Protocol . . . . . . . . . . . . . . . . . 22
9.3.2 Debug Messages . . . . . . . . . . . . . . . . . . . . 21 9.3.1 Weak Transport . . . . . . . . . . . . . . . . . . . . 22
9.3.3 Local Security Policy . . . . . . . . . . . . . . . . 22 9.3.2 Debug Messages . . . . . . . . . . . . . . . . . . . . 23
9.3.4 Public Key Authentication . . . . . . . . . . . . . . 22 9.3.3 Local Security Policy . . . . . . . . . . . . . . . . 23
9.3.5 Password Authentication . . . . . . . . . . . . . . . 23 9.3.4 Public Key Authentication . . . . . . . . . . . . . . 24
9.3.6 Host Based Authentication . . . . . . . . . . . . . . 23 9.3.5 Password Authentication . . . . . . . . . . . . . . . 24
9.4 Connection Protocol . . . . . . . . . . . . . . . . . . . 23 9.3.6 Host Based Authentication . . . . . . . . . . . . . . 24
9.4.1 End Point Security . . . . . . . . . . . . . . . . . . 23 9.4 Connection Protocol . . . . . . . . . . . . . . . . . . . 24
9.4.2 Proxy Forwarding . . . . . . . . . . . . . . . . . . . 23 9.4.1 End Point Security . . . . . . . . . . . . . . . . . . 24
9.4.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . 24 9.4.2 Proxy Forwarding . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.4.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . 25
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 25 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.2 Informative References . . . . . . . . . . . . . . . . . . . 25 10.1 Normative References . . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 27 10.2 Informative References . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . 30
1. Contributors 1. Contributors
The major original contributors of this set of documents have been: The major original contributors of this set of documents have been:
Tatu Ylonen, 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 set of documents 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].
skipping to change at page 4, line 14 skipping to change at page 5, line 14
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe
requirements. These keywords are to be interpreted as described in requirements. These keywords are to be interpreted as described in
[RFC2119]. [RFC2119].
The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME
FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG
APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in
this document when used to describe namespace allocation are to be this document when used to describe namespace allocation are to be
interpreted as described in [RFC2434]. interpreted as described in [RFC2434].
Protocol fields and possible values to fill them are defined in this
set of documents. Protocol fields will be defined in the message
definitions. As an example, SSH_MSG_CHANNEL_DATA is defined as
follows.
byte SSH_MSG_CHANNEL_DATA
uint32 recipient channel
string data
Throughout these documents, when the fields are referenced, they will
appear within single quotes. When values to fill those fields are
referenced, they will appear within double quotes. Using the above
example, possible values for 'data' are "foo" and "bar".
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 10 skipping to change at page 7, line 24
other implementations. other implementations.
One design goal has been to keep the base protocol as simple as One design goal has been to keep the base protocol as simple as
possible, and to require as few algorithms as possible. However, all possible, and to require as few algorithms as possible. However, all
implementations MUST support a minimal set of algorithms to ensure implementations MUST support a minimal set of algorithms to ensure
interoperability (this does not imply that the local policy on all interoperability (this does not imply that the local policy on all
hosts would necessary allow these algorithms). The mandatory hosts would necessary allow these algorithms). The mandatory
algorithms are specified in the relevant protocol documents. algorithms are specified in the relevant protocol documents.
Additional algorithms, methods, formats, and extension protocols can Additional algorithms, methods, formats, and extension protocols can
be defined in separate drafts. See Section Algorithm Naming (Section be defined in separate drafts. See Section Algorithm Naming
6) for more information. (Section 6) for more information.
4.3 Policy Issues 4.3 Policy Issues
The protocol allows full negotiation of encryption, integrity, key The protocol allows full negotiation of encryption, integrity, key
exchange, compression, and public key algorithms and formats. exchange, compression, and public key algorithms and formats.
Encryption, integrity, public key, and compression algorithms can be Encryption, integrity, public key, and compression algorithms can be
different for each direction. different for each direction.
The following policy issues SHOULD be addressed in the configuration The following policy issues SHOULD be addressed in the configuration
mechanisms of each implementation: mechanisms of each implementation:
skipping to change at page 9, line 39 skipping to change at page 11, line 8
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 have a non-zero length, and it MUST NOT names. A name MUST have a non-zero length, and it MUST NOT
contain a comma (","). As this is a list of names, all of the contain a comma (","). As this is a list of names, all of the
elements contained are names and MUST be in US-ASCII. Context may elements contained are names and MUST be in US-ASCII. Context may
impose additional restrictions on the names. For example; the impose additional restrictions on the names. For example; the
names in a name-list may have to be a list of valid algorithm names in a name-list may have to be a list of valid algorithm
identifiers (see Section 6 below), or a list of [RFC3066] language identifiers (see Section 6 below), or a list of [RFC3066] language
tags. The order of the names in a name-list may, or may not be tags. The order of the names in a name-list may or may not be
significant. Again, this depends on the context where the list is significant. Again, this depends on the context where the list is
used. Terminating null characters MUST NOT be used; neither for used. Terminating null characters MUST NOT be used; neither for
the individual names, nor for the list as a whole. the individual names, nor for the list as a whole.
Examples: Examples:
value representation (hex) value representation (hex)
----- -------------------- ----- --------------------
(), the empty name-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
skipping to change at page 20, line 47 skipping to change at page 21, line 47
9.2.8 Ordering of Key Exchange Methods 9.2.8 Ordering of Key Exchange Methods
As stated in the section on "Algorithm Negotiation" of [SSH-TRANS], As stated in the section on "Algorithm Negotiation" of [SSH-TRANS],
each device will send a list of preferred methods for key exchange. each device will send a list of preferred methods for key exchange.
The most-preferred method is the first in the list. It is The most-preferred method is the first in the list. It is
RECOMMENDED to sort the algorithms by cryptographic strength, RECOMMENDED to sort the algorithms by cryptographic strength,
strongest first. Some additional guidance for this is given in strongest first. Some additional guidance for this is given in
[RFC3766]. [RFC3766].
9.2.9 Traffic Analysis
Passive monitoring of any protocol may give an attacker some
information about the session, the user, or protocol specific
information that they would otherwise not be able to garner. For
example, it has been shown that traffic analysis of an SSH session
can yield information about the length of the password - [Openwall]
and [USENIX]. Implementors should use the SSH_MSG_IGNORE packet
along with the inclusion of random lengths of padding to thwart
attempts of traffic analysis. Other methods may also be found and
implemented.
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 24, line 34 skipping to change at page 25, line 45
against the X11 server. Users and administrators should, as a matter against the X11 server. Users and administrators should, as a matter
of course, use appropriate X11 security mechanisms to prevent of course, use appropriate X11 security mechanisms to prevent
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 access control lists IPC mechanisms authorized by permissions or access control lists
(ACLs), does correct many X11 security problems as long as the "none" (ACLs), does correct many X11 security problems as long as the "none"
MAC is not used. It is RECOMMENDED that X11 display implementations MAC is not used. It is RECOMMENDED that X11 display implementations
default to allowing display opens only over local IPC. It is default to allowing display opens only over local IPC. It is
RECOMMENDED that SSH server implementations that support X11 RECOMMENDED that SSH server implementations that support X11
forwarding default to allowing display opens only over local IPC. On forwarding default to allowing display opens only over local IPC. On
single-user systems it might be reasonable to default to allowing single-user systems it might be reasonable to default to allowing
local display opens over TCP/IP. 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",
draft-ietf-secsh-transport-22.txt, December 2004. I-D draft-ietf-secsh-transport-23.txt, February 2005.
[SSH-USERAUTH] [SSH-USERAUTH]
Lonvick, C., "SSH Authentication Protocol", I-D Lonvick, C., "SSH Authentication Protocol",
draft-ietf-secsh-userauth-25.txt, December 2004. I-D draft-ietf-secsh-userauth-26.txt, February 2005.
[SSH-CONNECT] [SSH-CONNECT]
Lonvick, C., "SSH Connection Protocol", I-D Lonvick, C., "SSH Connection Protocol",
draft-ietf-secsh-connect-23.txt, December 2004. I-D draft-ietf-secsh-connect-24.txt, February 2005.
[SSH-NUMBERS] [SSH-NUMBERS]
Lonvick, C., "SSH Protocol Assigned Numbers", I-D Lonvick, C., "SSH Protocol Assigned Numbers",
draft-ietf-secsh-assignednumbers-10.txt, December 2004. I-D draft-ietf-secsh-assignednumbers-11.txt, February
2005.
[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 [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.
[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.
skipping to change at page 26, line 27 skipping to change at page 27, line 37
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1282] Kantor, B., "BSD Rlogin", RFC 1282, December 1991. [RFC1282] Kantor, B., "BSD Rlogin", RFC 1282, December 1991.
[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993. Authentication Service (V5)", RFC 1510, September 1993.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
1964, June 1996. RFC 1964, June 1996.
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
(SPKM)", RFC 2025, October 1996. (SPKM)", RFC 2025, October 1996.
[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.
skipping to change at page 27, line 17 skipping to change at page 28, line 27
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".
[VENEMA] Venema, W., "Murphy's Law and Computer Security", [VENEMA] Venema, W., "Murphy's Law and Computer Security",
Proceedings of 6th USENIX Security Symposium, San Jose CA Proceedings of 6th USENIX Security Symposium, San Jose
http://www.usenix.org/publications/library/proceedings/ CA http://www.usenix.org/publications/library/proceedings/
sec96/venema.html, July 1996. sec96/venema.html, July 1996.
[ROGAWAY] Rogaway, P., "Problems with Proposed IP Cryptography", [ROGAWAY] Rogaway, P., "Problems with Proposed IP Cryptography",
Unpublished paper http://www.cs.ucdavis.edu/~rogaway/ Unpublished paper http://www.cs.ucdavis.edu/~rogaway/
papers/draft-rogaway-ipsec-comments-00.txt, 1996. papers/draft-rogaway-ipsec-comments-00.txt, 1996.
[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. Proceedings of the 9th ACM Conference on Computer and
Communications Security, Sept 2002.
[Openwall]
Solar Designer and D. Song, "SSH Traffic Analysis
Attacks", Presentation given at HAL2001 and NordU2002
Conferences, Sept 2001.
[USENIX] Song, X.D., Wagner, D. and X. Tian, "Timing Analysis of
Keystrokes and SSH Timing Attacks", Paper given at 10th
USENIX Security Symposium, 2001.
Author's Address Author's Address
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 Rights 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; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 28, line 46 skipping to change at page 30, line 46
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
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/