draft-ietf-secsh-architecture-21.txt   draft-ietf-secsh-architecture-22.txt 
Network Working Group C. Lonvick, Ed. Network Working Group T. Ylonen
Internet-Draft Cisco Systems, Inc. Internet-Draft SSH Communications Security Corp
Expires: August 21, 2005 February 17, 2005 Expires: September 15, 2005 C. Lonvick, Ed.
Cisco Systems, Inc.
March 14, 2005
SSH Protocol Architecture SSH Protocol Architecture
draft-ietf-secsh-architecture-21.txt draft-ietf-secsh-architecture-22.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 37
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 August 21, 2005. This Internet-Draft will expire on September 15, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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
skipping to change at page 2, line 14 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Conventions Used in This Document . . . . . . . . . . . . . . 5
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Host Keys . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 Host Keys . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . 6 4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . 7
4.3 Policy Issues . . . . . . . . . . . . . . . . . . . . . . 7 4.3 Policy Issues . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Security Properties . . . . . . . . . . . . . . . . . . . 8 4.4 Security Properties . . . . . . . . . . . . . . . . . . . 8
4.5 Localization and Character Set Support . . . . . . . . . . 8 4.5 Localization and Character Set Support . . . . . . . . . . 8
5. Data Type Representations Used in the SSH Protocols . . . . . 9 5. Data Type Representations Used in the SSH Protocols . . . . . 9
6. Algorithm and Method Naming . . . . . . . . . . . . . . . . . 11 6. Algorithm and Method Naming . . . . . . . . . . . . . . . . . 11
7. Message Numbers . . . . . . . . . . . . . . . . . . . . . . . 12 7. Message Numbers . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9.1 Pseudo-Random Number Generation . . . . . . . . . . . . . 14 9.1 Pseudo-Random Number Generation . . . . . . . . . . . . . 14
9.2 Transport . . . . . . . . . . . . . . . . . . . . . . . . 14 9.2 Transport . . . . . . . . . . . . . . . . . . . . . . . . 14
9.2.1 Confidentiality . . . . . . . . . . . . . . . . . . . 14 9.2.1 Confidentiality . . . . . . . . . . . . . . . . . . . 14
9.2.2 Data Integrity . . . . . . . . . . . . . . . . . . . . 17 9.2.2 Data Integrity . . . . . . . . . . . . . . . . . . . . 17
9.2.3 Replay . . . . . . . . . . . . . . . . . . . . . . . . 17 9.2.3 Replay . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2.4 Man-in-the-middle . . . . . . . . . . . . . . . . . . 18 9.2.4 Man-in-the-middle . . . . . . . . . . . . . . . . . . 18
9.2.5 Denial-of-service . . . . . . . . . . . . . . . . . . 20 9.2.5 Denial-of-service . . . . . . . . . . . . . . . . . . 20
9.2.6 Covert Channels . . . . . . . . . . . . . . . . . . . 21 9.2.6 Covert Channels . . . . . . . . . . . . . . . . . . . 21
9.2.7 Forward Secrecy . . . . . . . . . . . . . . . . . . . 21 9.2.7 Forward Secrecy . . . . . . . . . . . . . . . . . . . 21
skipping to change at page 2, line 51 skipping to change at page 3, line 5
9.3.4 Public Key Authentication . . . . . . . . . . . . . . 24 9.3.4 Public Key Authentication . . . . . . . . . . . . . . 24
9.3.5 Password Authentication . . . . . . . . . . . . . . . 24 9.3.5 Password Authentication . . . . . . . . . . . . . . . 24
9.3.6 Host Based Authentication . . . . . . . . . . . . . . 24 9.3.6 Host Based Authentication . . . . . . . . . . . . . . 24
9.4 Connection Protocol . . . . . . . . . . . . . . . . . . . 24 9.4 Connection Protocol . . . . . . . . . . . . . . . . . . . 24
9.4.1 End Point Security . . . . . . . . . . . . . . . . . . 24 9.4.1 End Point Security . . . . . . . . . . . . . . . . . . 24
9.4.2 Proxy Forwarding . . . . . . . . . . . . . . . . . . . 25 9.4.2 Proxy Forwarding . . . . . . . . . . . . . . . . . . . 25
9.4.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . 25 9.4.3 X11 Forwarding . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1 Normative References . . . . . . . . . . . . . . . . . . . 26 10.1 Normative References . . . . . . . . . . . . . . . . . . . 26
10.2 Informative References . . . . . . . . . . . . . . . . . . 26 10.2 Informative References . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
A. Trademark Notice . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . 30 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]. Many people contributed to the development of this document over the
Listing their names here does not mean that they endorse this years. People who should be acknowledged include Mats Andersson, Ben
document, but that they have contributed to it. Harris, Brent McClure, Niels Moller, Damien Miller, Derek Fawcus,
Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff Van Dyke,
Comments on this internet draft should be sent to the IETF SECSH Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph Galbraith, Ken
working group, details at: Hornstein, Markus Friedl, Martin Forssen, Nicolas Williams, Niels
http://ietf.org/html.charters/secsh-charter.html Note: This paragraph Provos, Perry Metzger, Peter Gutmann, Simon Josefsson, Simon Tatham,
will be removed before this document progresses to become an RFC. Wei Dai, Denis Bider, der Mouse, and Tadayoshi Kohno. Listing their
names here does not mean that they endorse this document, but that
they have contributed to it.
2. Introduction 2. Introduction
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. It consists of three major services over an insecure network. It consists of three major
components: components:
o The Transport Layer Protocol [SSH-TRANS] provides server o The Transport Layer Protocol [SSH-TRANS] provides server
authentication, confidentiality, and integrity. It may optionally authentication, confidentiality, and integrity. It may optionally
also provide compression. The transport layer will typically be also provide compression. The transport layer will typically be
run over a TCP/IP connection, but might also be used on top of any run over a TCP/IP connection, but might also be used on top of any
skipping to change at page 6, line 34 skipping to change at page 6, line 38
[RFC1282]). [RFC1282]).
Implementations SHOULD try to make the best effort to check host Implementations SHOULD try to make the best effort to check host
keys. An example of a possible strategy is to only accept a host key keys. An example of a possible strategy is to only accept a host key
without checking the first time a host is connected, save the key in without checking the first time a host is connected, save the key in
a local database, and compare against that key on all future a local database, and compare against that key on all future
connections to that host. connections to that host.
Implementations MAY provide additional methods for verifying the Implementations MAY provide additional methods for verifying the
correctness of host keys, e.g., a hexadecimal fingerprint derived correctness of host keys, e.g., a hexadecimal fingerprint derived
from the SHA-1 hash of the public key. Such fingerprints can easily from the SHA-1 hash [FIPS-180-2] of the public key. Such
be verified by using telephone or other external communication fingerprints can easily be verified by using telephone or other
channels. external communication channels.
All implementations SHOULD provide an option to not accept host keys All implementations SHOULD provide an option to not accept host keys
that cannot be verified. that cannot be verified.
The members of this Working Group believe that 'ease of use' is The members of this Working Group believe that 'ease of use' is
critical to end-user acceptance of security solutions, and no critical to end-user acceptance of security solutions, and no
improvement in security is gained if the new solutions are not used. improvement in security is gained if the new solutions are not used.
Thus, providing the option not to check the server host key is Thus, providing the option not to check the server host key is
believed to improve the overall security of the Internet, even though believed to improve the overall security of the Internet, even though
it reduces the security of the protocol in configurations where it is it reduces the security of the protocol in configurations where it is
skipping to change at page 17, line 33 skipping to change at page 17, line 33
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.
So long as the "none" MAC is not used, this protocol provides data So long as the "none" MAC is not used, this protocol provides data
integrity. integrity.
Because MACs use a 32 bit sequence number, they might start to leak Because MACs use a 32-bit sequence number, they might start to leak
information after 2**32 packets have been sent. However, following information after 2**32 packets have been sent. However, following
the rekeying recommendations should prevent this attack. The the rekeying recommendations should prevent this attack. The
transport protocol [SSH-TRANS] recommends rekeying after one gigabyte transport protocol [SSH-TRANS] recommends rekeying after one gigabyte
of data, and the smallest possible packet is 16 bytes. Therefore, of data, and the smallest possible packet is 16 bytes. Therefore,
rekeying SHOULD happen after 2**28 packets at the very most. rekeying SHOULD happen after 2**28 packets at the very most.
9.2.3 Replay 9.2.3 Replay
The use of a MAC other than "none" provides integrity and The use of a MAC other than "none" provides integrity and
authentication. In addition, the transport protocol provides a authentication. In addition, the transport protocol provides a
skipping to change at page 26, line 19 skipping to change at page 26, line 19
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", Lonvick, C., "SSH Transport Layer Protocol",
I-D draft-ietf-secsh-transport-23.txt, February 2005. I-D draft-ietf-secsh-transport-24.txt, March 2005.
[SSH-USERAUTH] [SSH-USERAUTH]
Lonvick, C., "SSH Authentication Protocol", Lonvick, C., "SSH Authentication Protocol",
I-D draft-ietf-secsh-userauth-26.txt, February 2005. I-D draft-ietf-secsh-userauth-27.txt, March 2005.
[SSH-CONNECT] [SSH-CONNECT]
Lonvick, C., "SSH Connection Protocol", Lonvick, C., "SSH Connection Protocol",
I-D draft-ietf-secsh-connect-24.txt, February 2005. I-D draft-ietf-secsh-connect-25.txt, March 2005.
[SSH-NUMBERS] [SSH-NUMBERS]
Lonvick, C., "SSH Protocol Assigned Numbers", Lonvick, C., "SSH Protocol Assigned Numbers",
I-D draft-ietf-secsh-assignednumbers-11.txt, February I-D draft-ietf-secsh-assignednumbers-12.txt, March 2005.
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.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
10.2 Informative References 10.2 Informative References
[FIPS-186-2]
Federal Information Processing Standards Publication,
"FIPS PUB 186-2, Digital Signature Standard (DSS)",
January 2000.
[FIPS-197]
National Institute of Standards and Technology, "FIPS 197,
Specification for the Advanced Encryption Standard",
November 2001.
[ANSI T1.523-2001]
American National Standards Institute, Inc., "Telecom
Glossary 2000", February 2001.
[SCHEIFLER]
Scheifler, R., "X Window System : The Complete Reference
to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital
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.
[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.
[RFC1282] Kantor, B., "BSD Rlogin", RFC 1282, December 1991. [RFC1282] Kantor, B., "BSD Rlogin", RFC 1282, December 1991.
skipping to change at page 28, line 15 skipping to change at page 27, line 43
[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.
[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.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86, Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, April 2004. RFC 3766, April 2004.
[FIPS-180-2]
National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", Federal Information Processing
Standards Publication 180-2, August 2002.
[FIPS-186-2]
National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", Federal Information Processing
Standards Publication 186-2, January 2000.
[FIPS-197]
National Institure of Standards and Technology, "Advanced
Encryption Standard (AES)", Federal Information Processing
Standards Publication 197, November 2001.
[ANSI T1.523-2001]
American National Standards Institute, Inc.>, "Telecom
Glossary 2000", ANSI T1.523-2001, February 2001.
[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.
[SCHEIFLER]
Scheifler, R., "X Window System : The Complete Reference
to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital
Press ISBN 1555580882, February 1992.
[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 Proceedings of 6th USENIX Security Symposium, San Jose
CA http://www.usenix.org/publications/library/proceedings/ CA http://www.usenix.org/publications/library/proceedings/
skipping to change at page 29, line 6 skipping to change at page 29, line 10
[Openwall] [Openwall]
Solar Designer and D. Song, "SSH Traffic Analysis Solar Designer and D. Song, "SSH Traffic Analysis
Attacks", Presentation given at HAL2001 and NordU2002 Attacks", Presentation given at HAL2001 and NordU2002
Conferences, Sept 2001. Conferences, Sept 2001.
[USENIX] Song, X.D., Wagner, D. and X. Tian, "Timing Analysis of [USENIX] Song, X.D., Wagner, D. and X. Tian, "Timing Analysis of
Keystrokes and SSH Timing Attacks", Paper given at 10th Keystrokes and SSH Timing Attacks", Paper given at 10th
USENIX Security Symposium, 2001. USENIX Security Symposium, 2001.
Author's Address Authors' Addresses
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
Appendix A. Trademark Notice
"ssh" is a registered trademark in the United States and/or other
countries.
Note to the RFC Editor: This should be a separate section like the
subsequent ones, and not an appendix. This paragraph to be removed
before publication.
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
 End of changes. 

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