draft-ietf-secsh-architecture-15.txt

来自「OTP是开放电信平台的简称」· 文本 代码 · 共 1,525 行 · 第 1/5 页

   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.

9.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 three cases of man-in-the-middle attacks to consider.  The
   first is where an attacker places a device between the client and the



Ylonen & Moffat          Expires March 31, 2004                [Page 17]

Internet-Draft         SSH Protocol Architecture                Oct 2003


   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 [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.

   The second case that should be considered is similar to the first
   case in that it also happens at the time of connection but this case
   points out the need for the secure distribution of server public
   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



Ylonen & Moffat          Expires March 31, 2004                [Page 18]

Internet-Draft         SSH Protocol Architecture                Oct 2003


   available through a secure DNS lookup, or using kerberos over gssapi
   during key exchange to authenticate the server are possibilities.

   In the third 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.

9.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.

9.2.6 Covert Channels

   The protocol was not designed to eliminate covert channels.  For



Ylonen & Moffat          Expires March 31, 2004                [Page 19]

Internet-Draft         SSH Protocol Architecture                Oct 2003


   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.

9.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.

9.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.



Ylonen & Moffat          Expires March 31, 2004                [Page 20]

Internet-Draft         SSH Protocol Architecture                Oct 2003


9.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.

9.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.
   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 messages 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.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



Ylonen & Moffat          Expires March 31, 2004                [Page 21]

Internet-Draft         SSH Protocol Architecture                Oct 2003


   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.

9.3.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 section on password authentication below.)

9.3.5 Password authentication