IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Pulling it all together - New Section 11 on Security Considerations
Hi Folks,
Below is the latest version of the Security Considerations section. This
reflects all of the discussions on the lists on the various parts of this
over the past few weeks. I appreciate all of the feedback and help.
I've also put together an html document of the changes from the previous
version; red strike outs for deletions and green text for insertions.
I'll put it on a web server and send around a pointer rsn. [The server
isn't doing so well today but I think it will be fixed in the next day
or so.] If you'd like to see that sooner rather than later, please email
me directly and I'll send it to you.
If you would like to suggest any changes, please call out the relevent
section in the Subject line of your email. Also, please remove the
non-related sections from your reply as this thing is getting a bit long.
Thanks,
Chris
==========================================================================
11. Security Considerations
In order to make the entire body of Security Considerations more
accessible, Security Considerations for the transport, authentication,
and connection documents have been gathered here.
The transport protocol [SSH-TRANS] provides a confidential channel
over an insecure network. It performs server host authentication, key
exchange, encryption, and integrity protection. It also derives a
unique session id that may be used by higher-level protocols.
The authentication protocol [SSH-USERAUTH] provides a suite of
mechanisms which can be used to authenticatethe client user to the
server. Individual mechanisms specified in the in authentication
protocol use the session id provided by the transport protocol and/or
depend on the security and integrity guarantees of the transport
protocol.
The connection protocol [SSH-CONNECT] specifies a mechanism to
multiplex multiple streams (channels) of data over the confidential
and authenticated transport. It also specifies channels for accessing
an interactive shell, for 'proxy-forwarding' various external
protocols over the secure transport (including arbitrary TCP/IP
protocols), and for accessing secure 'subsystems' on the server host.
11.1 PRNG
This protocol binds each session key to the session by including
random, session specific data in the hash used to produce session
keys. Special care should be taken to ensure that all of the random
numbers are of good quality. If the random data here (e.g., DH
parameters) are pseudo-random then the pseudo-random number generator
should be cryptographically secure (i.e., its next output not easily
guessed even when knowing all previous outputs) and, furthermore,
proper entropy needs to be added to the pseudo-random number
generator. RFC 1750 [RFC1750] offers suggestions for sources of
random numbers and entropy. Implementors should note the importance
of entropy and the well-meant, anecdotal warning about the difficulty
in properly implementing pseudo-random number generating functions.
The amount of entropy available to a given client or server may
sometimes be less than what is required. In this case one must either
resort to pseudo-random number generation regardless of insufficient
entropy or refuse to run the protocol. The latter is preferable.
11.2 Transport
11.2.1 Confidentiality
It is beyond the scope of this document and the Secure Shell Working
Group to analyze or recommend specific ciphers other than the ones
which have been established and accepted within the industry. At the
time of this writing, ciphers commonly in use include 3DES, ARCFOUR,
twofish, serpent and blowfish. AES has been accepted by The US Federal
Information Processing Standards [FIPS-197] and the cryptographic
community as being acceptable for this purpose as well. As always,
implementors and users should check current literature to ensure that
no recent vulnerabilities have been found in ciphers used within
products. Implementors should also check to see which ciphers are
considered to be relatively stronger than others and should recommend
their use to users over relatively weaker ciphers. It would be
considered good form for an implementation to politely and
unobtrusively notify a user that a stronger cipher is available and
should be used when a weaker one is actively chosen.
The "none" cipher is provided for debugging and SHOULD NOT be used
except for that purpose. It's cryptographic properties are
sufficiently described in RFC 2410 [RFC2410], which will show that its
use does not meet the intent of this protocol.
The relative merits of these and other ciphers may also be found in
current literature. Two references that may provide information on the
subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER]. Both of these
describe the CBC mode of operation of certain ciphers and the weakness
of this scheme. Essentially, this mode is theoretically vulnerable to
chosen cipher-text attacks because of the high predictability of the
start of packet sequence. However, this attack is still deemed
difficult and not considered fully practicable especially if relatively
longer block sizes are used.
Additionally, another CBC mode attack may be mitigated through the
insertion of packets containing SSH_MSG_IGNORE. Without this
technique, a specific attack may be successful. For this attack
(commonly known as the Rogaway attack) to work, the attacker would
need to know the IV of the next block that is going to be 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 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. 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.
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 no
other packets waiting for transmission. Implementors may wish to check
to see if there are any unsent packets awaiting transmission, but
unfortunately it is not normally easy to obtain this information from
the kernel or buffers. If there are not, then a packet containing
SSH_MSG_IGNORE SHOULD be sent. If a new packet is added to the stream
every time the attacker knows the IV that is supposed to be used for
the next packet, then the attacker will not be able to guess the
correct IV, thus the attack will never be successfull.
As an example, consider the following case:
Client Server
------ ------
TCP(seq=x, len=500) ->
contains Record 1
[500 ms passes, no ACK]
TCP(seq=x, len=1000) ->
contains Records 1,2
<- ACK
(1) The Nagle algorithm + TCP retransmits mean that the two
records get coalesced into a single TCP segment
(2) Record 2 is *not* at the beginning of the TCP segment
and never will be, since it gets ACKed.
(3) Yet, the attack is possible because Record 1 has already
been seen.
As this example indicates, it's totally unsafe to use the existence
of unflushed data in the TCP buffers proper as a guide to whether
you need an empty packet, since when you do the second write(),
the buffers will contain the un-ACKed Record 1.
On the other hand, it's perfectly safe to have the following
situation:
Client Server
------ ------
TCP(seq=x, len=500) ->
contains SSH_MSG_IGNORE
TCP(seq=y, len=500) ->
contains Data
Provided that the IV for second SSH Record is fixed after the data for
the Data packet is determined -i.e. you do:
read from user
encrypt null packet
encrypt data packet
11.2.2 Data Integrity
This protocol does allow the Data Integrity mechanism to be disabled.
Implementors SHOULD be wary of exposing this feature for any purpose
other than debugging. Users and administrators SHOULD be explicitly
warned anytime the "none" MAC is enabled.
So long as the "none" MAC is not used, this protocol
provides data integrity.
Because MACs use a 32 bit sequence number, they might start to leak
information after 2**32 packets have been sent. However, following
the rekeying recommendations should prevent this attack. The
transport protocol [1] recommends rekeying after one gigabyte of data,
and the smallest possible packet is 16 bytes. Therefore, rekeying
SHOULD happen after 2**28 packets at the very most.
11.2.3 Replay
The use of a MAC other than 'none' provides integrity and
authentication. In addition, the transport protocol provides a unique
session identifier (bound in part to pseudo-random data that is part
of the algorithm and key exchange process) that can be used by higher
level protocols to bind data to a given session and prevent replay of
data from prior sessions. For example, the authentication protocol uses
this to prevent replay of signatures from previous sessions. Because
public key authentication exchanges are cryptographically bound to the
session (i.e., to the initial key exchange) they cannot be successfully
replayed in other sessions. Note that the session ID can be made
public without harming the security of the protocol.
If two session happen to have the same session ID [hash of key
exchanges] then packets from one can be replayed against the other.
It must be stressed that the chances of such an occurrence are,
needless to say, minimal when using modern cryptographic methods.
This is all the more so true when specifying larger hash function
outputs and DH parameters.
Replay detection using monotonically increasing sequence numbers as
input to the MAC, or HMAC in some cases, is described in RFC 2085
[RFC2085], RFC 2246 [RFC2246], RFC 2743 [RFC2743], RFC 1964 [RFC1964],
RFC 2025 [RFC2025], and RFC 1510 [RFC1510]. The underlying construct
is discussed in RFC 2104 [RFC2104]. Essentially a different sequence
number in each packet ensures that at least this one input to the MAC
function will be unique and will provide a nonrecurring MAC output
that is not predictable to an attacker. If the session stays active
long enough, however, this sequence number will wrap. This event may
provide an attacker an opportunity to replay a previously recorded
packet with an identical sequence number but only if the peers have
not rekeyed since the transmission of the first packet with that
sequence number. If the peers have rekeyed, then the replay will be
detected as the MAC check will fail. For this reason, it must be
emphasized that peers MUST rekey before a wrap of the sequence
numbers. Naturally, if an attacker does attempt to replay a captured
packet before the peers have rekeyed, then the receiver of the
duplicate packet will not be able to validate the MAC and it will be
discarded. The reason that the MAC will fail is because the receiver
will formulate a MAC based upon the packet contents, the shared
secret, and the expected sequence number. Since the replayed packet
will not be using that expected sequence number (the sequence number
of the replayed packet will have already been passed by the receiver)
then the calculated MAC will not match the MAC received with the
packet.
11.2.4 Man-in-the-middle
This protocol makes no assumptions nor provisions for an
infrastructure or means for distributing the public keys of hosts. It
is expected that this protocol will sometimes be used without first
verifying the association between the server host key and the server
host name. Such usage is vulnerable to man-in-the-middle attacks.
This section describes this and encourages administrators and users to
understand the importance of verifying this association before any
session is initiated.
There are two cases of man-in-the-middle attacks to consider. The
first is where an attacker places a device between the client and the
server before the session is initiated. In this case, the attack
device is trying to mimic the legitimate server and will offer its
public key to the client when the client initiates a session. If it
were to offer the public key of the server, then it would not be able
to decrypt or sign the transmissions between the legitimate server and
the client unless it also had access to the private-key of the host.
The attack device will also, simultaneously to this, initiate a
session to the legitimate server masquerading itself as the client.
If the public key of the server had been securely distributed to the
client prior to that session initiation, the key offered to the client
by the attack device will not match the key stored on the client. In
that case, the user SHOULD be given a warning that the offered host
key does not match the host key cached on the client. As described in
Section 3.1 of [SSH-ARCH], the user may be free to accept the new key
and continue the session. It is RECOMMENDED that the warning provide
sufficient information to the user of the client device so they may
make an informed decision. If the user chooses to continue the
session with the stored public-key of the server (not the public-key
offered at the start of the session), then the session specific data
between the attacker and server will be different between the
client-to-attacker session and the attacker-to-server sessions due to
the randomness discussed above. From this, the attacker will not be
able to make this attack work since the attacker will not be able to
correctly sign packets containing this session specific data from the
server since he does not have the private key of that server.
Insecure distribution of server public keys allows a second type of
man-in-the-middle attack that should also be considered in this case;
one with suitable but incorrect host keys. If the server public keys
are not securely distributed then the client cannot know if it is
talking to the intended server. An attacker may use social
engineering techniques to pass off server keys to unsuspecting users
and may then place a man-in-the-middle attack device between the
legitimate server and the clients. If this is allowed to happen then
the clients will form client-to-attacker sessions and the attacker
will form attacker-to-server sessions and will be able to monitor and
manipulate all of the traffic between the clients and the legitimate
servers. Server administrators are encouraged to make host key
fingerprints available for checking by some means whose security does
not rely on the integrity of the actual host keys. Possible
mechanisms are discussed in Section 3.1 of [SSH-ARCH] and may also
include secured Web pages, physical pieces of paper, etc.
Implementors SHOULD provide recommendations on how best to do this
with their implementation. Because the protocol is extensible, future
extensions to the protocol may provide better mechanisms for dealing
with the need to know the server's host key before connecting. For
example, making the host key fingerprint available through a secure
DNS lookup, or using kerberos over gssapi during key exchange to
authenticate the server are possibilities.
As a second man-in-the-middle case, attackers may attempt to
manipulate packets in transit between peers after the session has been
established. As described in the Replay part of this section, a
successful attack of this nature is very improbable. As in the Replay
section, this reasoning does assume that the MAC is secure and that it
is infeasible to construct inputs to a MAC algorithm to give a known
output. This is discussed in much greater detail in Section 6 of RFC
2104. If the MAC algorithm has a vulnerability or is weak enough,
then the attacker may be able to specify certain inputs to yield a
known MAC. With that they may be able to alter the contents of a
packet in transit. Alternatively the attacker may be able to exploit
the algorithm vulnerability or weakness to find the shared secret by
reviewing the MACs from captured packets. In either of those cases,
an attacker could construct a packet or packets that could be inserted
into an SSH stream. To prevent that, implementors are encouraged to
utilize commonly accepted MAC algorithms and administrators are
encouraged to watch current literature and discussions of cryptography
to ensure that they are not using a MAC algorithm that has a recently
found vulnerability or weakness.
In summary, the use of this protocol without a reliable association of
the binding between a host and its host keys is inherently insecure
and is NOT RECOMMENDED. It may however be necessary in non-security
critical environments, and will still provide protection against
passive attacks. Implementors of protocols and applications running
on top of this protocol should keep this possibility in mind.
11.2.5 Denial-of-service
This protocol is designed to be used over a reliable transport. If
transmission errors or message manipulation occur, the connection is
closed. The connection SHOULD be re-established if this occurs.
Denial of service attacks of this type ("wire cutter") are almost
impossible to avoid.
In addition, this protocol is vulnerable to Denial of Service
attacks because an attacker can force the server to go through
the CPU and memory intensive tasks of connection setup and
key exchange without authenticating. Implementors SHOULD provide
features that make this more difficult. For example, only allowing
connections from a subset of IPs known to have valid users.
11.2.6 Covert Channels
The protocol was not designed to eliminate covert channels. For
example, the padding, SSH_MSG_IGNORE messages, and several other
places in the protocol can be used to pass covert information, and
the recipient has no reliable way to verify whether such information
is being sent.
11.2.7 Forward Secrecy
It should be noted that the Diffie-Hellman key exchanges may provide
perfect forward secrecy (PFS). PFS is essentially defined as the
cryptographic property of a key-establishment protocol in which the
compromise of a session key or long-term private key after a given
session does not cause the compromise of any earlier session.
[ANSI T1.523-2001] SSHv2 sessions resulting from a key exchange using
diffie-hellman-group1-sha1 are secure even if private
keying/authentication material is later revealed, but not if the
session keys are revealed. So, given this definition of PFS, SSHv2
does have PFS. It is hoped that all other key exchange mechanisms
proposed and used in the future will also provide PFS. This property
is not commuted to any of the applications or protocols using SSH as a
transport however. The transport layer of SSH provides
confidentiality for password authentication and other methods that
rely on secret data.
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
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 and
that they should be erased from memory as soon as the key exchange
completes.
11.3 Authentication Protocol
The purpose of this protocol is to perform client user authentication.
It assumes that this run over a secure transport layer protocol, which
has already authenticated the server machine, established an encrypted
communications channel, and computed a unique session identifier for
this session.
Several authentication methods with different security characteristics
are allowed. It is up to the server's local policy to decide which
methods (or combinations of methods) it is willing to accept for each
user. Authentication is no stronger than the weakest 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.
11.3.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 as stated above that the Authentication Protocol only
run 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.
11.3.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.
11.3.3 Local security policy
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 or 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.
Implementors are encouraged to provide a default local policy and
make its parameters known to administrators and users. At the
discretion of the implementors, 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
this policy 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.
11.3.4 Public key authentication
The use of public-key authentication assumes that the client 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 section on password authentication below.)
11.3.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.
11.3.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.
11.4 Connection protocol
11.4.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 end point 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. Implementors 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 target in 'port-forwarding' operations, which users are allowed to
use interactive shell facilities, or which users are allowed to use
exposed subsystems.
11.4.2 Proxy forwarding
The SSH connection protocol allows for proxy forwarding of other
protocols such as SNMP, 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. Implementors 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.
11.4.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. Implementors, 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 SSHv2 (or other, secure protocols), combined
with actual and pseudo-displays which accept connections only over
local IPC mechanisms authorized by permissions or 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 allowing
display opens only over local IPC. It is RECOMMENDED that SSHv2
server implementations that support X11 forwarding default to allowing
display opens only over local IPC. On single-user systems it might be
reasonable to default to allowing local display opens over TCP/IP.
Implementors 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.
References from this section:
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993.
[RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[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] Diercks, 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.
[SCHNEIER] Applied Cryptography, Second Edition, Bruce Schneier, Wiley
and Sons Publisher, 1996
[KAUFMAN,PERLMAN,SPECINER] Network Security; PRIVATE Communication in
a PUBLIC World, Charlie Kaufman, Radia Perlman, Mike Speciner,
Prentice Hall Publisher, 1995
[FIPS-197] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard (AES)"
FIPS 197. November 26, 2001.
[ANSI T1.523-2001] American National Standard T1.523-2001, "Telecom
Glossary 2000", American National Standards Institute, Inc.,
Approved February 28, 2001.
[SCHEIFLER] Scheifler, R., "X Window System : The Complete
Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd
edition.", Digital Press ISBN 1555580882, Feburary
1992.
[CERT] The CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
U.S.A.
( http://www.cert.org/nav/index_red.html )
[VENEMA] Wietse Venema, "Murphy's Law and Computer Security", Proceedings
of 6th USENIX Security Symposium, San Jose, CA, July 1996.
http://www.usenix.org/publications/library/proceedings/sec96/venema.html
Home |
Main Index |
Thread Index |
Old Index