draft-ietf-secsh-transport-17.txt

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

       mod p.  C sends "e" to S.

   2.  S generates a random number y (0 < y < q) and computes f = g^y
       mod p.  S receives "e".  It computes K = e^y mod p, H = hash(V_C
       || V_S || I_C || I_S || K_S || e || f || K) (these elements are
       encoded according to their types; see below), and signature s on
       H with its private host key. S sends "K_S || f || s" to C. The
       signing operation may involve a second hashing operation.

   3.  C verifies that K_S really is the host key for S (e.g. using
       certificates or a local database). C is also allowed to accept
       the key without verification; however, doing so will render the
       protocol insecure against active attacks (but may be desirable
       for practical reasons in the short term in many environments).  C
       then computes K = f^x mod p, H = hash(V_C || V_S || I_C || I_S ||
       K_S || e || f || K), and verifies the signature s on H.

   Either side MUST NOT send or accept e or f values that are not in the
   range [1, p-1]. If this condition is violated, the key exchange
   fails.


   This is implemented with the following messages.  The hash algorithm
   for computing the exchange hash is defined by the method name, and is
   called HASH.  The public key algorithm for signing is negotiated with
   the KEXINIT messages.

   First, the client sends the following:




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


     byte      SSH_MSG_KEXDH_INIT
     mpint     e


   The server responds with the following:

     byte      SSH_MSG_KEXDH_REPLY
     string    server public host key and certificates (K_S)
     mpint     f
     string    signature of H

   The hash H is computed as the HASH hash of the concatenation of the
   following:

     string    V_C, the client's version string (CR and NL excluded)
     string    V_S, the server's version string (CR and NL excluded)
     string    I_C, the payload of the client's SSH_MSG_KEXINIT
     string    I_S, the payload of the server's SSH_MSG_KEXINIT
     string    K_S, the host key
     mpint     e, exchange value sent by the client
     mpint     f, exchange value sent by the server
     mpint     K, the shared secret

   This value is called the exchange hash, and it is used to
   authenticate the key exchange. The exchange hash SHOULD be kept
   secret.


   The signature algorithm MUST be applied over H, not the original
   data.  Most signature algorithms include hashing and additional
   padding.  For example, "ssh-dss" specifies SHA-1 hashing; in that
   case, the data is first hashed with HASH to compute H, and H is then
   hashed with SHA-1 as part of the signing operation.

7.1 diffie-hellman-group1-sha1

   The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key
   exchange with SHA-1 as HASH, and Oakley group 14 [RFC3526] (2048-bit
   MODP Group).  It is included below in hexadecimal and decimal.

   The prime p is equal to 2^1024 - 2^960 - 1 + 2^64 * floor( 2^894 Pi +
   129093 ). Its hexadecimal value is:

         FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
         29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
         EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
         E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
         EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381



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


         FFFFFFFF FFFFFFFF.

   In decimal, this value is:

         179769313486231590770839156793787453197860296048756011706444
         423684197180216158519368947833795864925541502180565485980503
         646440548199239100050792877003355816639229553136239076508735
         759914822574862575007425302077447712589550957937778424442426
         617334727629299387668709205606050270810842907692932019128194
         467627007.

   The generator used with this prime is g = 2. The group order q is (p
   - 1) / 2.

8. Key Re-Exchange

   Key re-exchange is started by sending an SSH_MSG_KEXINIT packet when
   not already doing a key exchange (as described in Section Section
   6.1). When this message is received, a party MUST respond with its
   own SSH_MSG_KEXINIT message except when the received SSH_MSG_KEXINIT
   already was a reply. Either party MAY initiate the re-exchange, but
   roles MUST NOT be changed (i.e., the server remains the server, and
   the client remains the client).


   Key re-exchange is performed using whatever encryption was in effect
   when the exchange was started.  Encryption, compression, and MAC
   methods are not changed before a new SSH_MSG_NEWKEYS is sent after
   the key exchange (as in the initial key exchange).  Re-exchange is
   processed identically to the initial key exchange, except for the
   session identifier that will remain unchanged. It is permissible to
   change some or all of the algorithms during the re-exchange.  Host
   keys can also change.  All keys and initialization vectors are
   recomputed after the exchange.  Compression and encryption contexts
   are reset.


   It is recommended that the keys are changed after each gigabyte of
   transmitted data or after each hour of connection time, whichever
   comes sooner. However, since the re-exchange is a public key
   operation, it requires a fair amount of processing power and should
   not be performed too often.


   More application data may be sent after the SSH_MSG_NEWKEYS packet
   has been sent; key exchange does not affect the protocols that lie
   above the SSH transport layer.




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


9. Service Request

   After the key exchange, the client requests a service. The service is
   identified by a name. The format of names and procedures for defining
   new names are defined in [SSH-ARCH].


   Currently, the following names have been reserved:

     ssh-userauth
     ssh-connection

   Similar local naming policy is applied to the service names, as is
   applied to the algorithm names; a local service should use the
   "servicename@domain" syntax.

     byte      SSH_MSG_SERVICE_REQUEST
     string    service name

   If the server rejects the service request, it SHOULD send an
   appropriate SSH_MSG_DISCONNECT message and MUST disconnect.


   When the service starts, it may have access to the session identifier
   generated during the key exchange.


   If the server supports the service (and permits the client to use
   it), it MUST respond with the following:

     byte      SSH_MSG_SERVICE_ACCEPT
     string    service name

   Message numbers used by services should be in the area reserved for
   them (see Section 6 in [SSH-ARCH]).  The transport level will
   continue to process its own messages.


   Note that after a key exchange with implicit server authentication,
   the client MUST wait for response to its service request message
   before sending any further data.

10. Additional Messages

   Either party may send any of the following messages at any time.






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


10.1 Disconnection Message

     byte      SSH_MSG_DISCONNECT
     uint32    reason code
     string    description [RFC2279]
     string    language tag [RFC3066]

   This message causes immediate termination of the connection.  All
   implementations MUST be able to process this message; they SHOULD be
   able to send this message.

   The sender MUST NOT send or receive any data after this message, and
   the recipient MUST NOT accept any data after receiving this message.
   The description field gives a more specific explanation in a
   human-readable form.  The error code gives the reason in a more
   machine-readable format (suitable for localization), and can have the
   following values:

     #define SSH_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT      1
     #define SSH_DISCONNECT_PROTOCOL_ERROR                   2
     #define SSH_DISCONNECT_KEY_EXCHANGE_FAILED              3
     #define SSH_DISCONNECT_RESERVED                         4
     #define SSH_DISCONNECT_MAC_ERROR                        5
     #define SSH_DISCONNECT_COMPRESSION_ERROR                6
     #define SSH_DISCONNECT_SERVICE_NOT_AVAILABLE            7
     #define SSH_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED   8
     #define SSH_DISCONNECT_HOST_KEY_NOT_VERIFIABLE          9
     #define SSH_DISCONNECT_CONNECTION_LOST                 10
     #define SSH_DISCONNECT_BY_APPLICATION                  11
     #define SSH_DISCONNECT_TOO_MANY_CONNECTIONS            12
     #define SSH_DISCONNECT_AUTH_CANCELLED_BY_USER          13
     #define SSH_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE  14
     #define SSH_DISCONNECT_ILLEGAL_USER_NAME               15

   If the description string is displayed, control character filtering
   discussed in [SSH-ARCH] should be used to avoid attacks by sending
   terminal control characters.

10.2 Ignored Data Message

     byte      SSH_MSG_IGNORE
     string    data

   All implementations MUST understand (and ignore) this message at any
   time (after receiving the protocol version). No implementation is
   required to send them. This message can be used as an additional
   protection measure against advanced traffic analysis techniques.




Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 22]

Internet-Draft        SSH Transport Layer Protocol              Oct 2003


10.3 Debug Message

     byte      SSH_MSG_DEBUG
     boolean   always_display
     string    message [RFC2279]
     string    language tag [RFC3066]

   All implementations MUST understand this message, but they are
   allowed to ignore it.  This message is used to pass the other side
   information that may help debugging.  If always_display is TRUE, the
   message SHOULD be displayed.  Otherwise, it SHOULD NOT be displayed
   unless debugging information has been explicitly requested by the
   user.


   The message doesn't need to contain a newline. It is, however,
   allowed to consist of multiple lines separated by CRLF (Carriage
   Return - Line Feed) pairs.


   If the message string is displayed, terminal control character
   filtering discussed in [SSH-ARCH] should be used to avoid attacks by
   sending terminal control characters.

10.4 Reserved Messages

   An implementation MUST respond to all unrecognized messages with an
   SSH_MSG_UNIMPLEMENTED message in the order in which the messages were
   received.  Such messages MUST be otherwise ignored.  Later protocol
   versions may define other meanings for these message types.

     byte      SSH_MSG_UNIMPLEMENTED
     uint32    packet sequence number of rejected message


11. Summary of Message Numbers

   The following message numbers have been defined in this protocol:

     #define SSH_MSG_DISCONNECT             1
     #define SSH_MSG_IGNORE                 2
     #define SSH_MSG_UNIMPLEMENTED          3
     #define SSH_MSG_DEBUG                  4
     #define SSH_MSG_SERVICE_REQUEST        5
     #define SSH_MSG_SERVICE_ACCEPT         6

     #define SSH_MSG_KEXINIT                20
     #define SSH_MSG_NEWKEYS                21



Ylonen & Moffat, Editor    Expires March 31, 2004              [Page 23]

Internet-Draft        SSH Transport Layer Protocol              Oct 2003


     /* Numbers 30-49 used for kex packets.
        Different kex methods may reuse message numbers in
        this range. */

     #define SSH_MSG_KEXDH_INIT             30
     #define SSH_MSG_KEXDH_REPLY            31