Re: IESG feedback on core drafts.

["Joseph Galbraith" <galb-list%vandyke.com@localhost>]

Well, I'm not sure if this is what we need or not, but
here is my first stab--

Here is the current Security Considerations section from
the transport draft.

>   This protocol provides a secure encrypted 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.
>
>   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 use 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.
>
>   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.
>
>   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.

Here is my proposed revision:

11. Security Considerations

   This protocol provides a secure encrypted 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.

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

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

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

   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.

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

   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.
   
   Use of this protocol without reliable association
   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.

11.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
   attack 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.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.

----

Is this what is needed, or am I way off track?

Thanks,

Joseph

----- Original Message ----- 
From: "Bill Sommerfeld" <sommerfeld%east.sun.com@localhost>
To: <ietf-ssh%netbsd.org@localhost>
Cc: <smb%research.att.com@localhost>; <jis%mit.edu@localhost>
Sent: Thursday, February 20, 2003 19:12
Subject: IESG feedback on core drafts.


> Some time ago I mentioned that the core drafts were being held up due
> to concerns about the security considerations section.
> 
> I've just gotten feedback from Steve Bellovin (security co-AD).
> 
> He states that in his opinion, the security consideration section is
> inadequate and should be rewritten along the lines described in
> draft-iab-sec-cons-03.txt including:
> 
>     ".. a discussion of the limitations of the protocol, the
>     countermeasures, and the residual vulnerabilities.  Looking just
>     at the architecture document, it says (in that section) nothing
>     about the risks from users accepting unknown host keys.  The
>     information is present in diffuse form in 3.1, but it isn't
>     spelled out clearly in one spot.  A possible countermeasure would
>     be some way for a logged-in user to then verify the fingerprint,
>     in a way that a clever mitm proxy would find hard to
>     mimic. Similarly, the draft says little about the security of the
>     endpoint being important.  It's not any one thing; it's that I'd
>     really like SEC-area documents to be better than average, and this
>     isn't up to the standards that I, at least, have been demanding of
>     documents from other areas."
> 
> WG members interested in forward progress of the core drafts should
> take the time to read draft-iab-sec-cons-03 and send suggested text to
> the list..
> 
> - Bill
> 
> 
> 
>