combination allowed.
The server may go into a sleep period after repeated unsuccessful
authentication attempts to make key search more difficult for
attackers. Care should be taken so that this doesn’t become a self-
denial of service vector.
9.4.1. Weak Transport
If the transport layer does not provide confidentiality,
authentication methods that rely on secret data SHOULD be disabled.
If it does not provide strong integrity protection, requests to
change authentication data (e.g., a password change) SHOULD be
disabled to prevent an attacker from modifying the ciphertext without
being noticed, or rendering the new authentication data unusable
(denial of service).
The assumption stated above, that the Authentication Protocol only
runs over a secure transport that has previously authenticated the
server, is very important to note. People deploying SSH are reminded
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
host key of that server. Specifically, for the case of the
Authentication Protocol, the client may form a session to a man-in-
the-middle attack device and divulge user credentials such as their
username and password. Even in the cases of authentication where no
user credentials are divulged, an attacker may still gain information
they shouldn’t have by capturing key-strokes in much the same way
that a honeypot works.
9.4.2. Debug Messages
Special care should be taken when designing debug messages. These
messages may reveal surprising amounts of information about the host
if not properly designed. Debug messages can be disabled (during
user authentication phase) if high security is required.
Administrators of host machines should make all attempts to
compartmentalize all event notification messages and protect them
from unwarranted observation. Developers should be aware of the
sensitive nature of some of the normal event and debug messages, and
may want to provide guidance to administrators on ways to keep this
information away from unauthorized people. Developers should
consider minimizing the amount of sensitive information obtainable by
users during the authentication phase, in accordance with the local
policies. For this reason, it is RECOMMENDED that debug messages be
initially disabled at the time of deployment and require an active
decision by an administrator to allow them to be enabled. It is also
RECOMMENDED that a message expressing this concern be presented to
the administrator of a system when the action is taken to enable
debugging messages.
9.4.3. Local Security Policy
The implementer MUST ensure that the credentials provided validate
the professed user and also MUST ensure that the local policy of the
server permits the user the access requested. In particular, because
of the flexible nature of the SSH connection protocol, it may not be
possible to determine the local security policy, if any, that should
apply at the time of authentication because the kind of service being
requested is not clear at that instant. For example, local policy
might allow a user to access files on the server, but not start an
interactive shell. However, during the authentication protocol, it
is not known whether the user will be accessing files, attempting to
use an interactive shell, or even both. In any event, where local
security policy for the server host exists, it MUST be applied and
enforced correctly.
Implementers are encouraged to provide a default local policy and
make its parameters known to administrators and users. At the
discretion of the implementers, this default policy may be along the
lines of anything-goes where there are no restrictions placed upon
users, or it may be along the lines of excessively-restrictive, in
which case, the administrators will have to actively make changes to
the initial default parameters to meet their needs. Alternatively,
it may be some attempt at providing something practical and
immediately useful to the administrators of the system so they don’t
have to put in much effort to get SSH working. Whatever choice is
made must be applied and enforced as required above.
9.4.4 Public Key Authentication
The use of public key authentication assumes that the client host has
not been compromised. It also assumes that the private key of the
server host has not been compromised.
This risk can be mitigated by the use of passphrases on private keys;
however, this is not an enforceable policy. The use of smartcards,
or other technology to make passphrases an enforceable policy is
suggested.
The server could require both password and public key authentication;
however, this requires the client to expose its password to the
server (see the section on Password Authentication below.)
9.4.5. Password Authentication
The password mechanism, as specified in the authentication protocol,
assumes that the server has not been compromised. If the server has
been compromised, using password authentication will reveal a valid
username/password combination to the attacker, which may lead to
further compromises.
This vulnerability can be mitigated by using an alternative form of
authentication. For example, public key authentication makes no
assumptions about security on the server.
9.4.6. Host-Based Authentication
Host-based authentication assumes that the client has not been
compromised. There are no mitigating strategies, other than to use
host-based authentication in combination with another authentication
method.
9.5. Connection Protocol
9.5.1. End Point Security
End point security is assumed by the connection protocol. If the
server has been compromised, any terminal sessions, port forwarding,
or systems accessed on the host are compromised. There are no
mitigating factors for this.
If the client has been compromised, and the server fails to stop the
attacker at the authentication protocol, all services exposed (either
as subsystems or through forwarding) will be vulnerable to attack.
Implementers SHOULD provide mechanisms for administrators to control
which services are exposed to limit the vulnerability of other
services. These controls might include controlling which machines
and ports can be targeted in port-forwarding operations, which users
are allowed to use interactive shell facilities, or which users are
allowed to use exposed subsystems.
9.5.2. Proxy Forwarding
The SSH connection protocol allows for proxy forwarding of other
protocols such as SMTP, POP3, and HTTP. This may be a concern for
network administrators who wish to control the access of certain
applications by users located outside of their physical location.
Essentially, the forwarding of these protocols may violate site-
specific security policies, as they may be undetectably tunneled
through a firewall. Implementers SHOULD provide an administrative
mechanism to control the proxy forwarding functionality so that
site-specific security policies may be upheld.
In addition, a reverse proxy forwarding functionality is available,
which, again, can be used to bypass firewall controls.
As indicated above, end-point security is assumed during proxy
forwarding operations. Failure of end-point security will compromise
all data passed over proxy forwarding.
9.5.3. X11 Forwarding
Another form of proxy forwarding provided by the SSH connection
protocol is the forwarding of the X11 protocol. If end-point
security has been compromised, X11 forwarding may allow attacks
against the X11 server. Users and administrators should, as a matter
of course, use appropriate X11 security mechanisms to prevent
unauthorized use of the X11 server. Implementers, administrators,
and users who wish to further explore the security mechanisms of X11
are invited to read [SCHEIFLER] and analyze previously reported
problems with the interactions between SSH forwarding and X11 in CERT
vulnerabilities VU#363181 and VU#118892 [CERT].
X11 display forwarding with SSH, by itself, is not sufficient to
correct well known problems with X11 security [VENEMA]. However, X11
display forwarding in SSH (or other secure protocols), combined with
actual and pseudo-displays that accept connections only over local
IPC mechanisms authorized by permissions or access control lists
(ACLs), does correct many X11 security problems, as long as the
"none" MAC is not used. It is RECOMMENDED that X11 display
implementations default to allow the display to open only over local
IPC. It is RECOMMENDED that SSH server implementations that support
X11 forwarding default to allow the display to open only over local
IPC. On single-user systems, it might be reasonable to default to
allow the local display to open over TCP/IP.
Implementers of the X11 forwarding protocol SHOULD implement the
magic cookie access-checking spoofing mechanism, as described in
[SSH-CONNECT], as an additional mechanism to prevent unauthorized use
of the proxy.
10. References
10.1. Normative References
[SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Transport Layer Protocol", RFC 4253, January
2006.
[SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Authentication Protocol", RFC 4252, January
2006.
[SSH-CONNECT] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
(SSH) Connection Protocol", RFC 4254, January
2006.
[SSH-NUMBERS] Lehtinen, S. and C. Lonvick, Ed., "The Secure
Shell (SSH) Protocol Assigned Numbers", RFC 4250,
January 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998.
[RFC3066] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of
ISO 10646", STD 63, RFC 3629, November 2003.
10.2. Informative References
[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
Specification", STD 8, RFC 854, May 1983.
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC1282] Kantor, B., "BSD Rlogin", RFC 1282, December 1991.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn,
"The Kerberos Network Authentication Service
(V5)", RFC 4120, July 2005.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API
Mechanism", RFC 1964, June 1996.
[RFC2025] Adams, C., "The Simple Public-Key GSS-API
Mechanism (SPKM)", RFC 2025, October 1996.
[RFC2085] Oehler, M. and R. Glenn, "HMAC-MD5 IP
Authentication with Replay Prevention", RFC 2085,
February 1997.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC
2104, February 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption
Algorithm and Its Use With IPsec", RFC 2410,
November 1998.
[RFC2743] Linn, J., "Generic Security Service Application
Program Interface Version 2, Update 1", RFC 2743,
January 2000.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths
For Public Keys Used For Exchanging Symmetric
Keys", BCP 86, RFC 3766, April 2004.
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106,
RFC 4086, June 2005.
[FIPS-180-2] US National Institute of Standards and Technology,
"Secure Hash Standard (SHS)", Federal Information
Processing Standards Publication 180-2, August
2002.
[FIPS-186-2] US National Institute of Standards and Technology,
"Digital Signature Standard (DSS)", Federal
Information Processing Standards Publication 186-
2, January 2000.
[FIPS-197] US National Institute 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, B., "Applied Cryptography Second
Edition: protocols algorithms and source in code
in C", John Wiley and Sons, New York, NY, 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] Kaufman, C., Perlman, R., and M. Speciner,
"Network Security: PRIVATE Communication in a
PUBLIC World", Prentice Hall Publisher, 1995.
[CERT] CERT Coordination Center, The.,
"http://www.cert.org/nav/index_red.html".
[VENEMA] Venema, W., "Murphy’s Law and Computer Security",
Proceedings of 6th USENIX Security Symposium, San
Jose CA
http://www.usenix.org/publications/library/
proceedings/sec96/venema.html, July 1996.
[ROGAWAY] Rogaway, P., "Problems with Proposed IP
Cryptography", Unpublished paper
http://www.cs.ucdavis.edu/~rogaway/ papers/draft-
rogaway-ipsec-comments-00.txt, 1996.
[DAI] Dai, W., "An attack against SSH2 protocol", Email
to the SECSH Working Group ietf-ssh@netbsd.org
ftp:// ftp.ietf.org/ietf-mail-archive/secsh/2002-
02.mail, Feb 2002.
[BELLARE] Bellaire, M., Kohno, T., and C. Namprempre,
"Authenticated Encryption in SSH: Fixing the SSH
Binary Packet Protocol", 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.
Authors’ Addresses
Tatu Ylonen
SSH Communications Security Corp
Valimotie 17
00380 Helsinki
Finland
EMail: ylo@ssh.com
Chris Lonvick (editor)
Cisco Systems, Inc.
12515 Research Blvd.
Austin 78759
USA
EMail: clonvick@cisco.com
Trademark Notice
"ssh" is a registered trademark in the United States and/or other
countries.
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
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
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).