IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

New Proposal for Section 11.3 Authentication Protocol



Hi,

I've made changes to the first part of Section 11.3 "Authentication
Protocol" and 11.3.1 "Weak Transport" to address the concerns from Simon
and Nico about MITM and _user_ authentication mechanisms.  Please comment.

Thanks,
Chris

===================================================================


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.




Home | Main Index | Thread Index | Old Index