draft-ietf-secsh-architecture-17.txt   draft-ietf-secsh-architecture-18.txt 
Network Working Group C. Lonvick, Ed. Network Working Group C. Lonvick, Ed.
Internet-Draft Cisco Systems, Inc Internet-Draft Cisco Systems, Inc.
Expires: April 24, 2005 October 24, 2004 Expires: May 19, 2005 November 18, 2004
SSH Protocol Architecture SSH Protocol Architecture
draft-ietf-secsh-architecture-17.txt draft-ietf-secsh-architecture-18.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 35 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 April 24, 2005. This Internet-Draft will expire on May 19, 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 2, line 13 skipping to change at page 2, line 13
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Specification of Requirements . . . . . . . . . . . . . . . . 3 3. Conventions Used in This Document . . . . . . . . . . . . . . 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 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 and Method Naming . . . . . . . . . . . . . . . . . 10 6. Algorithm and Method Naming . . . . . . . . . . . . . . . . . 10
7. Message Numbers . . . . . . . . . . . . . . . . . . . . . . . 11 7. Message Numbers . . . . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9.1 Pseudo-Random Number Generation . . . . . . . . . . . . . 13 9.1 Pseudo-Random Number Generation . . . . . . . . . . . . . 12
9.2 Transport . . . . . . . . . . . . . . . . . . . . . . . . 14 9.2 Transport . . . . . . . . . . . . . . . . . . . . . . . . 13
9.2.1 Confidentiality . . . . . . . . . . . . . . . . . . . 14 9.2.1 Confidentiality . . . . . . . . . . . . . . . . . . . 13
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.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 . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . 29 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 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 3, line 49 skipping to change at page 3, line 49
The client sends a service request once a secure transport layer The client sends a service request once a secure transport layer
connection has been established. A second service request is sent connection has been established. A second service request is sent
after user authentication is complete. This allows new protocols to after user authentication is complete. This allows new protocols to
be defined and coexist with the protocols listed above. be defined and coexist with the protocols listed above.
The connection protocol provides channels that can be used for a wide The connection protocol provides channels that can be used for a wide
range of purposes. Standard methods are provided for setting up 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. Conventions Used in This Document
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. These keywords are to be interpreted as described in requirements. These keywords are to be interpreted as described in
[RFC2119]. [RFC2119].
All documents related to the SSH protocols shall use the keywords The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME
"PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME FIRST SERVED", FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG
"EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG APPROVAL", "IETF APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in
CONSENSUS", and "STANDARDS ACTION" to describe namespace allocation. this document when used to describe namespace allocation are to be
These keywords are to be interpreted as described in [RFC2434]. 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 7, line 16 skipping to change at page 7, line 16
broken, it is easy to switch to some other algorithm without broken, it is easy to switch to some other algorithm without
modifying the base protocol. modifying the base protocol.
Specific concessions were made to make wide-spread fast deployment Specific concessions were made to make wide-spread fast deployment
easier. The particular case where this comes up is verifying that easier. The particular case where this comes up is verifying that
the server host key really belongs to the desired host; the protocol the server host key really belongs to the desired host; the protocol
allows the verification to be left out, but this is NOT RECOMMENDED. allows the verification to be left out, but this is NOT RECOMMENDED.
This is believed to significantly improve usability in the short This is believed to significantly improve usability in the short
term, until widespread Internet public key infrastructures emerge. term, until widespread Internet public key infrastructures emerge.
4.5 Packet Size and Overhead 4.5 Localization and Character Set Support
Some readers will worry about the increase in packet size due to new
headers, padding, and Message Authentication Code (MAC). The minimum
packet size is in the order of 28 bytes (depending on negotiated
algorithms). The increase is negligible for large packets, but very
significant for one-byte packets (telnet-type sessions). There are,
however, several factors that make this a non-issue in almost all
cases:
o The minimum size of a TCP/IP header is 32 bytes. Thus, the
increase is actually from 33 to 51 bytes (roughly).
o The minimum size of the data field of an Ethernet packet is 46
bytes [RFC0894]. Thus, the increase is no more than 5 bytes.
When Ethernet headers are considered, the increase is less than 10
percent.
o The total fraction of telnet-type data in the Internet is
negligible, even with increased packet sizes.
The only environment where the packet size increase is likely to have
a significant effect is PPP [RFC1134] over slow modem lines (PPP
compresses the TCP/IP headers, emphasizing the increase in packet
size). However, with modern modems, the time needed to transfer is
in the order of 2 milliseconds, which is a lot faster than people can
type.
There are also issues related to the maximum packet size. To
minimize delays in screen updates, one does not want excessively
large packets for interactive sessions. The maximum packet size is
negotiated separately for each channel.
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 [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
skipping to change at page 11, line 20 skipping to change at page 10, line 38
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 [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 [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.)
skipping to change at page 14, line 44 skipping to change at page 14, line 12
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 [ROGAWAY], [DAI], (commonly known as the Rogaway attack [ROGAWAY], [DAI],
[BELLARE,KOHNO,NAMPREMPRE],) to work, the attacker would need to know [BELLARE,KOHNO,NAMPREMPRE]) to work, the attacker would need to know
the Initialization Vector (IV) of the next block that is going to be the Initialization Vector (IV) of the next block that is going to be
encrypted. In CBC mode that is the output of the encryption of the encrypted. In CBC mode that is the output of the encryption of the
previous block. If the attacker does not have any way to see the previous block. If the attacker does not have any way to see the
packet yet (i.e., it is in the internal buffers of the SSH packet yet (i.e., it is in the internal buffers of the SSH
implementation or even in the kernel) then this attack will not work. implementation or even in the kernel) then this attack will not 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
skipping to change at page 20, line 31 skipping to change at page 20, line 31
diffie-hellman methods described in the section "Diffie-Hellman Key diffie-hellman methods described in the section "Diffie-Hellman Key
Exchange" of [SSH-TRANS] (including diffie-hellman-group1-sha1 and Exchange" of [SSH-TRANS] (including diffie-hellman-group1-sha1 and
diffie-hellman-group14-sha1) are secure even if private diffie-hellman-group14-sha1) are secure even if private
keying/authentication material is later revealed, but not if the keying/authentication material is later revealed, but not if the
session keys are revealed. So, given this definition of PFS, SSH session keys are revealed. So, given this definition of PFS, SSH
does have PFS. This property is not commuted to any of the does have PFS. This property is not commuted to any of the
applications or protocols using SSH as a transport however. The applications or protocols using SSH as a transport however. The
transport layer of SSH provides confidentiality for password transport layer of SSH provides confidentiality for password
authentication and other methods that 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 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],
skipping to change at page 25, line 10 skipping to change at page 25, line 8
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]
Ylonen, T. and C. Lonvick, "SSH Transport Layer Protocol", Lonvick, C., "SSH Transport Layer Protocol", I-D
I-D draft-ietf-transport-19.txt, October 2004. draft-ietf-transport-20.txt, October 2004.
[SSH-USERAUTH] [SSH-USERAUTH]
Ylonen, T. and C. Lonvick, "SSH Authentication Protocol", Lonvick, C., "SSH Authentication Protocol", I-D
I-D draft-ietf-userauth-22.txt, October 2004. draft-ietf-userauth-23.txt, October 2004.
[SSH-CONNECT] [SSH-CONNECT]
Ylonen, T. and C. Lonvick, "SSH Connection Protocol", I-D Lonvick, C., "SSH Connection Protocol", I-D
draft-ietf-connect-20.txt, October 2004. draft-ietf-connect-21.txt, October 2004.
[SSH-NUMBERS] [SSH-NUMBERS]
Ylonen, T. and C. Lonvick, "SSH Protocol Assigned Lonvick, C., "SSH Protocol Assigned Numbers", I-D
Numbers", I-D draft-ietf-assignednumbers-07.txt, October draft-ietf-assignednumbers-08.txt, October 2004.
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 26, line 8 skipping to change at page 26, line 5
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 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982. 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
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
multi-protocol transmission of datagrams over
Point-to-Point links", RFC 1134, November 1989.
[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", RFC
1964, June 1996. 1964, June 1996.
skipping to change at page 28, line 8 skipping to change at page 27, line 36
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.
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
 End of changes. 

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