draft-ietf-secsh-architecture-15.txt

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

   o  SSH protocol (service) names.




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


   These names MUST be printable US-ASCII strings, and MUST NOT contain
   the characters at-sign ('@'), comma (','), or whitespace or control
   characters (ASCII codes 32 or less).  Names are case-sensitive, and
   MUST NOT be longer than 64 characters.

   Names with the at-sign ('@') in them are allocated by the owner of
   DNS name after the at-sign (hierarchical allocation in [RFC-2343]),
   otherwise the same restrictions as above.

   Each category of names listed above has a separate namespace.
   However, using the same name in multiple categories SHOULD be avoided
   to minimize confusion.

   Message numbers (see Section Message Numbers (Section 7)) in the
   range of 0..191 are allocated via IETF consensus; message numbers in
   the 192..255 range (the "Local extensions" set) are reserved for
   private use.

9. 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 mechanisms which
   can be used to authenticate 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.

9.1 Pseudo-Random Number Generation

   This protocol binds each session key to the session by including
   random, session specific data in the hash used to produce session
   keys.  Special care should be taken to ensure that all of the random
   numbers are of good quality.  If the random data here (e.g., DH



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


   parameters) are pseudo-random then the pseudo-random number generator
   should be cryptographically secure (i.e., its next output not easily
   guessed even when knowing all previous outputs) and, furthermore,
   proper entropy needs to be added to the pseudo-random number
   generator.  RFC 1750 [1750] offers suggestions for sources of random
   numbers and entropy.  Implementors should note the importance of
   entropy and the well-meant, anecdotal warning about the difficulty in
   properly implementing pseudo-random number generating functions.

   The amount of entropy available to a given client or server may
   sometimes be less than what is required.  In this case one must
   either resort to pseudo-random number generation regardless of
   insufficient entropy or refuse to run the protocol.  The latter is
   preferable.

9.2 Transport

9.2.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
   published as a US Federal Information Processing Standards [FIPS-197]
   and the cryptographic community as being acceptable for this purpose
   as well has accepted AES.  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



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


   is still deemed difficult and not considered fully practicable
   especially if relatively longer block sizes are used.

   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
   [ROGAWAY],[DAI],[BELLARE,KOHNO,NAMPREMPRE]) 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.




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


   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.












































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


   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


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

9.2.3 Replay

   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.



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


   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.

   Replay detection using monotonically increasing sequence numbers as
   input to the MAC, or HMAC in some cases, is described in [RFC2085] />
   [RFC2246], [RFC2743], [RFC1964], [RFC2025], and [RFC1510].  The
   underlying construct is discussed in [RFC2104].  Essentially a
   different sequence number in each packet ensures that at least this