IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Even Newer Section 11 for Your Comments
Hi Folks,
My thanks to everyone who's been discussing and making comments upon the
proposed Section 11. Below is a revision based upon the recent email
thread. Please look that over and provide your further comments. To make
the task of looking at the revisions easier, I've attached a file with
some html in it. (Your indulgences, please.) When viewed in a browser it
displays redline striking to indicate deleted passages and green text to
indicate insertions. It's not exact but it has markups at or near the
places that have changed which will hopefully allow everyone to review
these changes without having to hunt them down manually.
I've edited some significant changes into Section 11.1.3 "Replay" and have
added a new Section 11.1.7 "Forward Secrecy". Please look those over
carefully. I've also tried very hard to keep outstanding questions in
this which still need to be addressed. These should be findable by
looking for "[xxx: " at the start of lines below.
One comment that was raised was about adding a new section on the security
of the key exchange. I have not attempted to address that and it is not
noted below. If that is needed in this section, would someone
(Joseph? :-) please propose text?
Thanks,
Chris
===vvv=== New Proposal for Section 11 ===vvv===
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 [1] 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 [2] provides a suite of mechanism which
can be used to authenticating the 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 [3] 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 Transport
11.1.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, 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.
[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
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.1.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.1.3 Replay
This protocol binds each session key to the session by including
random data that is specific to the session in the hash used to
produce session keys. If the random data here (e.g., DH parameters)
are pseudo-random then the PRNG should be cryptographically secure
(i.e., its next output not easily guessed, even when knowing all
previous outputs) and, furthermore, the PRNG should be seeded with some
truly random inputs, or as random as can be available. In any case,
the amount of entropy available to a given client or server sometimes
may be less than what is needed to run the protocol, in which case
either one must resort to PRNGs anyways or refuse to run the protocol.
In practice implementors will generally rely on some PRNG. RFC 1750
[1750] contains more discussion on this.
[1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
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.
[RJA: I imagine that a sequence number does help preclude replay attacks,
[RJA: but I was hoping that someone else had actually done some analysis
[RJA: that we could cite to justify the claim that this MAC combined with
[RJA: this kind of sequence numbering would actually provide replay
[RJA: attack prevention.
11.1.4 Man-in-the-middle
This protocol makes no assumptions nor provisions for
an infrastructure for distributing public keys. It is
expected that this protocol will sometimes be used without
insisting on reliable association between the server host
key and the server host name. Such usage is vulnerable
to man-in-the-middle attacks.
This vulnerability to man-in-the-middle attacks can
be mitigated in several fashions:
1. Narrow the window during which the client is vulnerable to such a
man-in-the-middle attack. If the client ensures that the host key
for a given server remains consistant, an attacker must execute the
man-in-the-middle attack on the _first_ connection to a given
server.
2. Use an authentication method that is not vulnerable to
man-in-the-middle attacks. For example, public-key authentication
is not vulnerable to man-in-the-middle attack as long as the
public-key of the server has been securely distributed to the
clients before the first SSH connection is made. This is because
the signature is made across data that is session specific. 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.
[RJA: Is this really true and sufficient ?
3. 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, storing the hostkey fingerprint
in a secure dns database, or using kerberos over gssapi
during keyexchange to authenticate the server.
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 include secured Web pages, the DNS
[draft-ietf-secsh-dns], physical pieces of paper, etc.
Implementors SHOULD provide recommendations on how best to do
this with their implementation.
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.1.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.1.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.1.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 and
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.
[ANSI T1.523-2001] American National Standard T1.523-2001, "Telecom
Glossary 2000", American National Standards Institute, Inc., Approved
February 28, 2001.
11.2 Authentication Protocol
The purpose of this protocol is to perform client user
authentication. It assumed that this runs 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.
The server may go into a "sleep" period after repeated unsuccessful
authentications to make key search harder.
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.
11.2.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 MAC protection, requests to change authentication data (e.g.
password change) SHOULD be disabled to avoid an attacker from
modifying the ciphertext without being noticed, rendering the new
authentication data unusable (denial of service).
11.2.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.2.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 that should apply at the time of authentication, because the
kind of service being requested is not yet clear. 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, local security
policy for the server host MUST be applied and enforced correctly.
[Nico: What if no policy is available?
11.2.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.2.5 Password authentication
The password mechanism of 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.2.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.3 Connection protocol
11.3.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.3.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.3.3 X11 forwarding
Another form of proxy forwarding provided by the ssh
connection protocol is the forwarding of the X11 protocol.
Implementors of the X11 protocol SHOULD implement the magic cookie
spoofing, to prevent unauthorized use of the proxy. More information
about the use of the X11 magic cookie may be found in many of the
available manual references and implementation guides for X11. For
example, viewing the manual page for "xauth" in BSD systems may be one
place to start.
X11 forwarding relies on end-point security. If end-point
security has been compromised, X11 forwarding will allow
any attack against the X11 server possible locally.
Users and administrators should, as a matter of course, use
X11 security mechanism to prevent unauthorized use of
the X11 server.
[RJA: Which "X11 security mechanism" is meant ?
[RJA: Also, please add a citation for that mechanism.
[JG: Well, I didn't have a particular one in mind. The
[JG: advice is to use any X11 security mechanism. I'd
[JG: be willing to remove the paragraph.
[RJA: I'd like to keep text encouraging folks to use as much
[RJA: security as they can. I'm not an expert on the security
[RJA: properties of X11. I was thinking that there probably were
[RJA: some specific security mechanisms (e.g. my vague recollection
[RJA: of the MIT-magic-cookie hack noted above) that we ought
[RJA: to mention and cite.
===^^^=== New Proposal for Section 11 ===^^^===
<pre>
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 [1] 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 [2] provides a suite of mechanism which
can be used to authenticating the 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 [3] 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 Transport
11.1.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, 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.
[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
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.1.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.1.3 Replay
This protocol binds each session key to the session by including
random data that is specific to the session in the hash used to
produce session keys.
<strike><font color=red>This</font></strike> <strong><font color=green>If the random data here (e.g., DH parameters)
are pseudo-random then the PRNG should be cryptographically secure
(i.e., its next output not easily guessed, even when knowing all
previous outputs) and, furthermore, the PRNG should be seeded with some
truly random inputs, or as random as can be available. In any case,
the amount of entropy available to a given client or server sometimes
may be less than what is needed to run the protocol, in which case
either one must resort to PRNGs anyways or refuse to run the protocol.
In practice implementors will generally rely on some PRNG. RFC 1750
[1750] contains more discussion on this.
[1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
The use of a MAC other than 'none' provides integrity and
authentication. In addition, the transport protocol provides a unique</font></strong>
session <strike><font color=red>id</font></strike> <strong><font color=green>identifier (bound in part to pseudo-random data that</font></strong> is <strong><font color=green>part
of the algorithm and key exchange process) that can be</font></strong> used by higher
level protocols to <strong><font color=green>bind data to a given session and</font></strong> prevent replay of <strike><font color=red>packets form</font></strike>
<strong><font color=green>data from prior sessions. For example, the authentication protocol uses
this to prevent replay of signatures from</font></strong> previous sessions.
<strike><font color=red>In addition,</font></strike> <strong><font color=green>Because
public key authentication exchanges are cryptographically bound to</font></strong> the <strike><font color=red>use</font></strike>
<strong><font color=green>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</font></strong> of <strike><font color=red>cipher chaining prevents
replay</font></strike> <strong><font color=green>the protocol.
If two session happen to have the same session ID [hash</font></strong> of <strong><font color=green>key
exchanges] then</font></strong> packets <strike><font color=red>within</font></strike> <strong><font color=green>from one can be replayed against</font></strong> the <strike><font color=red>session. Cipher chaining
also prevents</font></strike> <strong><font color=green>other. It
must be stressed that</font></strong> the <strike><font color=red>insertion or deletion</font></strike> <strong><font color=green>chances</font></strong> of <strike><font color=red>packets.</font></strike> <strong><font color=green>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.
[RJA: I imagine that a sequence number does help preclude replay attacks,
[RJA: but I was hoping that someone else had actually done some analysis
[RJA: that we could cite to justify the claim that this MAC combined with
[RJA: this kind of sequence numbering would actually provide replay
[RJA: attack prevention.</font></strong>
11.1.4 Man-in-the-middle
This protocol makes no assumptions nor provisions for
an infrastructure for distributing public keys. It is
expected that this protocol will sometimes be used without
insisting on reliable association between the server host
key and the server host name. Such usage is vulnerable
to man-in-the-middle attacks.
This vulnerability to man-in-the-middle attacks can
be mitigated in several fashions:
1. Narrow the <strike><font color=red>window.</font></strike> <strong><font color=green>window during which the client is vulnerable to such a
man-in-the-middle attack.</font></strong> If the client ensures that the host key
for a given server remains consistant, an attacker must execute the
man-in-the-middle attack on the _first_ connection to a given
server.
2. Use an authentication method that is not vulnerable to <strike><font color=red>man-in-the-middle.</font></strike>
<strong><font color=green>man-in-the-middle attacks.</font></strong> For example, public-key authentication
is not vulnerable to man-in-the-middle
<strike><font color=red>attack,</font></strike> <strong><font color=green>attack as long as the
public-key of the server has been securely distributed to the
clients before the first SSH connection is made. This is</font></strong> because
the signature is made across data that is session specific. The <strike><font color=red>attack can not use
the signature he receives because the</font></strike>
session specific data between the attacker and server <strike><font color=red>is different,</font></strike> <strong><font color=green>will be
different between the client-to-attacker session</font></strong> and
<strike><font color=red>can</font></strike> <strong><font color=green>the
attacker-to-server sessions due to the randomness discussed above.
From this, the attacker will</font></strong> not <strike><font color=red>create a valid signature because</font></strike> <strong><font color=green>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</font></strong> he does
not have the private <strike><font color=red>key.
However, this does assume</font></strike> <strong><font color=green>key of</font></strong> that <strike><font color=red>the public-key has
been distributed to the server host in some secure
fashion before the first SSH connection can be made.</font></strike> <strong><font color=green>server.
[RJA: Is this really true and sufficient ?</font></strong>
3. 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, storing the hostkey fingerprint
in a secure dns database, or using kerberos over gssapi
during keyexchange to authenticate the server.
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 include secured Web pages, the DNS
[draft-ietf-secsh-dns], physical pieces of paper, etc.
Implementors SHOULD provide recommendations on how best to do
this with their implementation.
Use of this protocol without <strong><font color=green>a</font></strong> reliable association <strong><font color=green>of the binding
between a host and its host keys</font></strong> is inherently <strike><font color=red>insecure, but</font></strike> <strong><font color=green>insecure and is NOT
RECOMMENDED. It</font></strong> may <strong><font color=green>however</font></strong> be necessary in non-security critical
environments, and <strong><font color=green>will</font></strong> still
<strike><font color=red>provides</font></strike> <strong><font color=green>provide</font></strong> protection against passive <strike><font color=red>attacks. However,
implementors</font></strike>
<strong><font color=green>attacks. Implementors</font></strong> of protocols <strong><font color=green>and applications</font></strong> running on top of
this protocol should keep this possibility in mind.
11.1.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.1.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.
<strong><font color=green>11.1.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 and
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.
[ANSI T1.523-2001] American National Standard T1.523-2001, "Telecom
Glossary 2000", American National Standards Institute, Inc., Approved
February 28, 2001.</font></strong>
11.2 Authentication Protocol
The purpose of this protocol is to perform client user
authentication. It assumed that this runs 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.
The <strike><font color=red>transport layer
provides forward secrecy for password authentication and other
methods that rely on secret data.
The</font></strike> server may go into a "sleep" period after repeated unsuccessful
authentications to make key search harder.
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.
11.2.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 MAC protection, requests to change authentication data (e.g.
password change) SHOULD be disabled to avoid an attacker from
modifying the ciphertext without being noticed, rendering the new
authentication data unusable (denial of service).
11.2.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.2.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
<strike><font color=red>this completely</font></strike> <strong><font color=green>the local security
policy that should apply</font></strong> at the time of authentication, because the
kind of service being requested is not yet clear. 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, local security
policy for the server host MUST be applied and enforced correctly.
<strong><font color=green>[Nico: What if no policy is available?</font></strong>
11.2.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.2.5 Password authentication
The password mechanism of 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.2.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.3 Connection protocol
11.3.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.3.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.3.3 X11 forwarding
Another form of proxy forwarding provided by the ssh
connection protocol is the forwarding of the X11 protocol.
Implementors of the X11 protocol SHOULD implement the magic cookie
spoofing, to prevent unauthorized use of the proxy. <strong><font color=green>More information
about the use of the X11 magic cookie may be found in many of the
available manual references and implementation guides for X11. For
example, viewing the manual page for "xauth" in BSD systems may be one
place to start.</font></strong>
X11 forwarding relies on end-point security. If end-point
security has been compromised, X11 forwarding will allow
any attack against the X11 server possible locally.
Users and administrators should, as a matter of course, use
X11 security mechanism to prevent unauthorized use of
the X11 server.
<strong><font color=green>
[RJA: Which "X11 security mechanism" is meant ?
[RJA: Also, please add a citation for that mechanism.
[JG: Well, I didn't have a particular one in mind. The
[JG: advice is to use any X11 security mechanism. I'd
[JG: be willing to remove the paragraph.
[RJA: I'd like to keep text encouraging folks to use as much
[RJA: security as they can. I'm not an expert on the security
[RJA: properties of X11. I was thinking that there probably were
[RJA: some specific security mechanisms (e.g. my vague recollection
[RJA: of the MIT-magic-cookie hack noted above) that we ought
[RJA: to mention and cite.</font><strong></pre>
Home |
Main Index |
Thread Index |
Old Index