IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: IESG feedback on core drafts.
Overall, a very good start. Specific nits noted inline.
Ran
rja%extremenetworks.com@localhost
On Saturday, Mar 29, 2003, at 11:33 America/Montreal, Joseph Galbraith
wrote:
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 secure encrypted
channel over an insecure network. It performs server
s/a secure encrypted channel/a confidential channel/
"encryption" is the mechanism.
"confidentiality" is the property.
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. Individual mechanisms specified in the in
s/user./user to the server./
authentication protocol use teh session id provided
s/teh/the/
by the transport protocol and/or depend on the security
and integrity gaurentees of the transport protocol.
s/guarentees/guarantees/
The connection protocol [3] specifies a mechanism
to multiplex multiple streams [channels] of data over
the secure transport. It also specifies channels for
s/secure transport/confidential and authenticated transport/
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
This protocol does allow the encryption 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" method is enabled.
So long as the "none" cipher is not used, this protocol
provides confidentiality. Older, smaller ciphers, such
as 3des and arcfour MAY be less secure from attack than
ciphers such as AES. Implementors SHOULD prefer ciphers
such as twofish, serpent, or AES over blowfish, 3des and
arcfour.
s/MAY/might/
The capitalised "MAY" as used in IETF documents related only
to permission, not to possibilities. In the sentence above,
the apparent meaning is that some ciphers might be less
desirable than others, so "might" is a more clear choice
and capitalised "MAY" is a clearly bad choice.
With ciphers operating in CBC mode is theoretically
vulnerable to choosen cipher-text attacks because of
the high predicability of the start of packet sequence.
Not a sentence; please rephrase.
Also, please consider adding a bibliographic reference
to some paper, article, or book in the published literature.
However, this attack is still relatively hard enough, and
requires a sufficiently high number of packets, to be safe
in the short term. Ciphers with larger block sizes are
less vulnerable the ciphers with smaller block sizes.
[Is this true?]
See previous comment.
Effort is underway to standardize the use of CTR mode
ciphers in the SSH protocol. When this work is completed,
implementors SHOULD support it.
Premature. Suggest deleting those 2 sentences for now.
The issue can be revisited later if/when CTR mode is specified
and there is some clear consensus on whether those specs
are solid.
In addition, the CBC mode attack can be mitigated by
ensuring the an SSH_MSG_IGNORE packet preceeds any real
data at the start of a TCP packet.
[Is this true? 26 of the 32 length bits can probably
be reliably guessed to be 0. One or two of the pad
length bits are likewise reliably guessed as 0. The
packet type is known. 26 of the length field of the
string in an ignore packet are known. So 26 + 2 + 8 + 16 =
52 of the first 64 bits are reliablely known (or 62 of
the first 128 bits) -- my understanding is hazy-- is
this applicable to the vulnerability?]
We ought avoid making claims unless we are certain that
they are valid. Again, it is pleasant to cite some
document, paper, or book in the public literature for
published claims such as in this document.
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 may
s/may/might/
start to leak information after 2**32 packets have
been sent. However, following the rekeying
recomendations 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.
s/should happen/SHOULD hapen/
In this case, one appears to be trying to levy implementation
guidance, so capitalisation is appropriate.
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.
Is it random or pseudo-random ?
Does the difference matter in this case ?
This session id is used by higher level protocols
to prevent replay of packets form previous sessions.
In addition, the use of cipher chaining prevents
replay of packets within the session. Cipher chaining
also prevents the insertion or deletion of packets.
Citations would be pleasant for these claims.
11.1.4 Man-in-the-middle
This protocol makes no assumptions nor provisions for
s/no/neither/
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. 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.
Narrow *which* window ?
Intended meaning is not crystal clear above.
2. Use an authentication method that is not vulnerable
to man-in-the-middle. For example, public-key
authentication is not vulnerable to man-in-the-middle
attack, because the signature is made across data
that is session specific. The attack can not use
the signature he receives because the session specific
data between the attacker and server is different, and
can not create a valid signature because he does not
have the private key.
Is this really true and sufficient ?
However, this does assume that the public-key has
been distributed to the server host in some secure
fashion before the first SSH connection can be made.
3. Because the protocol is extensible, future extensions
to the protocol may provide better mechanisms for dealing
s/may/might/
This is not dealing with permissions, but with possibilities.
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.
s/should provide/SHOULD provide/
Again, this is providing implementation guidance, so ought to be
capitalised.
Use of this protocol without reliable association
association of what/whom ?
is inherently insecure, but may be necessary in
non-security critical environments, and still
provides protection against passive attacks. However,
implementors of protocols running on top of this
protocol should keep this possibility in mind.
??? s/protocols running/applications running/ ???
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.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 transport layer
provides forward secrecy for password authentication and other
methods that rely on secret data.
"perfect forward secrecy" or "forward secrecy" ?
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 encryption, authentication
s/encryption/confidentiality/
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
Authentication is always a delicate security operation.
Implementor MUST not only ensure that the credentials
given validate the professed user, but also that the
local policy of the server hosts allows the user the
access requested.
Propose edit of paragraph above to:
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
this completely at the time of authentication, because
the kind of service being requested is not yet clear.
Unclear antecedent "this".
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.
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 enforcable
policy. The use of smartcards, or other technology
to make passphrases an enforcable 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
comprimises.
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 mitaging
s/mitaging/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 comprimised.
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 proxy forwarding
of other protocols. The proxy forwarding functionality
can be used to circumvent firewall protections. Implementors
SHOULD provide a mechanism to disable to administratively
control the proxy forwarding funcitonality.
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 pass 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.
Add citation for "magic cookie spoofing".
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 administors should, as a matter of course, use
X11 security mechanism to prevent unauthorized use of
the X11 server.
Which "X11 security mechanism" is meant ?
Also, please add a citation for that mechanism.
------------------------------------------------------------------------
---
Home |
Main Index |
Thread Index |
Old Index