Internet Draft Y. Klein E. Felstaine Expires January 10, 2001 SANRAD July 10, 2000 iSCSI Security Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Introduction ............................................................2 1.1. Motivation for adding security to iSCSI ............................................................2 1.2. Key consideration for choosing a security protocol ............................................................3 1.3. iSCSI Security Architecture ............................................................3 1.4. Conventions Used in This Document ............................................................4 2. Protocol Considerations ............................................................4 2.1. Policy Issues ............................................................4 2.2. Security Properties ............................................................5 2.3. IANA Considerations ............................................................5 2.4. Security Considerations ............................................................5 3. Connection Setup ............................................................6 3.1. Usage over TCP/IP ............................................................6 3.2. Protocol Version Exchange ............................................................6 3.3. Compatibility with Old iSCSI Versions ............................................................7 4. iSCSI Considerations..............................................7 4.1. The Negotiation and Authentication Phase ............................................................7 4.2. iSCSI Parameters ............................................................7 5. Binary Packet Protocol ............................................................8 5.1. Maximum Packet Length ............................................................9 5.2. Encryption ............................................................9 5.3. Data Integrity ...........................................................10 5.4. Key Exchange Methods ...........................................................11 5.5. Public Key Algorithms ...........................................................11 6. Key Exchange ...........................................................13 6.1. Algorithm Negotiation ...........................................................13 6.2. Output from Key Exchange ...........................................................15 6.3. Taking Keys into Use ...........................................................16 7. Diffie-Hellman Key Exchange ...........................................................17 7.1. diffie-hellman-group1-sha1 ...........................................................18 8. Key Re-Exchange ...........................................................19 Klein, Felstaine [page 1] iSCSI Security Protocol July 2000 9. Service Request ............................................. .....19 10. Additional Messages ...................................................20 10.1. Disconnection Message ...................................................20 11. User Authentication ...................................................20 11.1. Authentication Requests ...................................................21 11.2. Responses to Authentication Requests ...................................................22 11.3. The none Authentication Request ...................................................23 11.4. Completion of User Authentication ...................................................23 11.5. Public Key Authentication Method: publickey ...................................................23 11.6. Password Authentication Method: password ...................................................24 12. References ...................................................26 13. Authors' Addresses ...................................................27 Abstract The iSCSI Security Layer is an SSH based protocol for secure, iSCSI aware, network services over an insecure storage network. The protocol supports login, server authentication, integrity protection and encryption, thus enables application such as Virtual Private Storage Area Networks (VPSAN). Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. 1. Introduction The iSCSI Security layer is a secure protocol integrated with the iSCSI (Internet SCSI) protocol. It provides options for encryption, cryptographic host authentication, and integrity protection. This document details the protocol. 1.1. Motivation for adding security to iSCSI The iSCSI (Internet SCSI) is a protocol over the TCP layer, designed to transfer SCSI commands and data. Forming a secure layer on top of the TCP layer and below the iSCSI layer provides infrastructure for additional applications. Those include: . Virtual Private Storage Area Network (VPSAN). This feature will enable users to close parts of the SAN over a common physical network. Thus, it will enable the creation of private SANs within common SAN/LAN systems. . Eavesdropping Protection. Securing a channel enables to from third party eavesdropping. Thus, guaranties any confidential information on the network traffic. . Enemy Attacks. The authentication provided by the secure layer defends the stored information from any third party modification. This guaranties integrity of the network storage. Klein, Felstaine [page 2] iSCSI Security Protocol July 2000 1.2. Key consideration for choosing a security protocol . The protocol should be an adaptation of a highly reliable and massively tested existing protocol (SSH in this case), to the iSCSI peculiarities. . The protocol should support iSCSI awareness: o A distinction is needed between different types of packets, which may require different types of security actions. o For instance, command packets may optionally be encrypted where data packet need not (since encryption of high volume traffic in gigabit speeds is infeasible). . The iSCSI security protocol should not require host administrators to install any network security components (such as a host based IP sec) in addition to installing the iSCSI stack (in which the proposed security protocol should be integrated). . Having said all that, the protocol should reside on top of the TCP along with iSCSI, where it can easily distinguish between the different types of traffic carried (commands, data, authenticators etc.). . Authentication should be host-based - as user authentication need not be performed. A higher-level protocol for user authentication can be designed on top of this protocol within the server (initiator) OS. . The protocol should be designed to be simple and flexible, to allow parameter negotiation, and to minimize the number of round-trips. . Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm should all be negotiated. It is expected that in the proposed protocol, in most environments, only 2 round- trips will be needed for full key exchange, server authentication, service request, and acceptance notification of service request. The worst case is 3 round-trips. 1.3. iSCSI Security Architecture The protocol is constructed from 3 main phases. In phase one, the login phase, keys are exchanged between client and server, and algorithms and parameters are negotiated. The additional two phases include authentication and a secure session. Both authentication Klein, Felstaine [page 3] iSCSI Security Protocol July 2000 and the session are done over a secure channel, i.e., protected from any eavesdropping. An example security with reasonable security parameters is discussed in Section #4.2. 1.4. Conventions Used in This Document The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [RFC-2119]. 2. Protocol Considerations 2.1. Policy Issues The protocol allows full negotiation of encryption, integrity, key exchange, and public key algorithms and formats. Encryption, integrity and public key, can be different for each direction. The following policy issues SHOULD be addressed in the configuration mechanisms of each implementation: . Encryption and integrity algorithms, separately for each direction. The policy MUST specify which is the preferred algorithm (e.g. the first algorithm listed in each category). . Public key algorithms and key exchange method to be used for host authentication. The existence of trusted host keys for different public key algorithms also affects this choice. . The authentication methods that are to be required by the server for each user. The server's policy MAY require Klein, Felstaine [page 4] iSCSI Security Protocol July 2000 multiple authentication for some or all users. The required algorithms MAY depend on the location from where the user is trying to log in from. . The operations that the user is allowed to perform using the connection protocol. Some issues are related to security; for example, the policy SHOULD NOT allow the server to start sessions or run commands on the client machine, and MUST NOT allow connections to the authentication agent unless forwarding it has been requested. Other issues, such as which TCP/IP ports can be forwarded and by whom, are clear local policy issues. Many of these issues may involve traversing or bypassing firewalls, and are interrelated with the local security policy. 2.2. Security Properties The primary goal of the iSCSI security protocols is improved security on the Internet. It attempts to do this in a way that is easy to deploy, even at the cost of absolute security. . All encryption, integrity, and public key algorithms used are well known well-established algorithms. . All algorithms are used with cryptographically sound key sizes that are believed to provide protection against even the strongest cryptanalytic attacks for decades. . All algorithms are negotiated, and in case some algorithm is broken, it is easy to switch to some other algorithm without modifying the base protocol. Specific concessions were made to make widespread fast deployment easier. The particular case where this comes up is verifying that the server host key really belongs to the desired host; the protocol allows the verification to be left out (but this is NOT RECOMMENDED). This is believed to significantly improve usability in the short term, until widespread Internet public key infrastructures emerge. 2.3. IANA Considerations Allocation of the following types of names in the iSCSI securoty protocols is assigned to IANA: . encryption algorithm names, . MAC algorithm names, . public key algorithm names (public key algorithm also implies encoding and signature/encryption capability), . key exchange method names, and . protocol (service) names. The IANA-allocated 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. Each category of names listed above has a separate namespace. However, using the same name in multiple categories SHOULD be avoided to minimize confusion. 2.4. Security Considerations Special care should be taken to ensure that all of the random numbers are of good quality. The random numbers SHOULD be produced with safe mechanisms discussed in [RFC1750]. When displaying text, such as error or debug messages to the user, the client software SHOULD replace any control characters (except tab, carriage return and newline) with safe sequences to avoid Klein, Felstaine [page 5] iSCSI Security Protocol July 2000 attacks by sending terminal control characters. Not using MAC or encryption SHOULD be avoided. The user authentication protocol is subject to man-in-the-middle attacks if the encryption is disabled. The iSCSI security protocol does not protect against message alteration if no MAC is used. 3. Connection Setup iSCSI Security protocol works over any 8-bit clean, binary- transparent transport. The underlying transport SHOULD protect against transmission errors as such errors cause the iSCSI connection to terminate. The client initiates the connection. 3.1. Usage over TCP/IP When used over TCP/IP, the server normally listens for connections on the IANA iSCSI port. This port number has been registered with the IANA, and has been officially assigned for iSCSI. 3.2. Protocol Version Exchange When the connection has been established, both sides MUST send an identification string of the form "iSCSI-protoversion- softwareversion comments", followed by carriage return and newline characters (ascii 13 and 10, respectively). Both sides MUST be able to process identification strings without carriage return character. No null character is sent. The maximum length of the string is 255 characters, including the carriage return and newline. The part of the identification string preceding carriage return and newline is used in the Diffie-Hellman key exchange (Section ''Diffie- Hellman Key Exchange''). The server MAY send other lines of data before sending the version string. Each line SHOULD be terminated by a carriage return and newline. Such lines MUST NOT begin with "iSCSI-", and SHOULD be encoded in ISO-10646 UTF-8 [RFC-2044] (language is not specified). Clients MUST be able to process such lines; they MAY be silently ignored, or MAY be displayed to the client user; Version strings MUST consist of printable US-ASCII characters, not including whitespaces or a minus sign (-). The version string is primarily used to trigger compatibility extensions and to indicate the capabilities of an implementation. The comment string should contain additional information that might be useful in solving user problems. The protocol version described in this document is 1.0. Key exchange will begin immediately after sending this identifier. All packets following the identification string SHALL use the Klein, Felstaine [page 6] iSCSI Security Protocol July 2000 binary packet protocol, to be described below. 3.3. Compatibility with Old iSCSI Versions During a transition period, it is important to be able to work compatibly with installed iSCSI clients and servers using an older version of the protocol. Information in this section is only relevant for implementations supporting compatibility with iSCSI versions 1.x. 4. iSCSI Considerations The following section describes the relevant parameters and architecture of the iSCSI protocol over the secure layer. 4.1. The Negotiation and Authentication Phase The negotiation and authentication phase takes place over the exchange, algorithm setup and parameters negotiation. The transferred data is set on the payload field of the text command (recall that this phase is not encrypted). 4.2. iSCSI Parameters The negotiation phase MUST include in addition the specific iSCSI parameters. These include: . What to encrypt (none, iSCSI-command-header, iSCSI-command- header+payload, iSCSI-command-header+payload+data) . What to authenticate (none, iSCSI-command-header, iSCSI- command-header+payload, iSCSIcommand-header+payload+data) (Where data refers to the data read and write commands). The negotiation phase is set as follows: 1. The host sends the server a list of the options, where the first is the most preferred option and the last is the less one. 2. The server sends the possible option (based on its capabilities). 3. The host acknowledges the set. After this phase, every part is formatted according to this setup. That is, if headers are encrypted, they are formatted as describe in chapter #5. Else, it is done as described in the iSCSI protocol without further changes. It should be noted that under reasonable implementation scenarios, implementers MAY choose to apply encryption and/or authentication Klein, Felstaine [page 7] iSCSI Security Protocol July 2000 only on the iSCSI headers and the iSCSI commands. This is a compromise for the sake of reducing the computation requirements. The obtained security in such an implementation scenario might authenticated by the iSCSI command header, which means that the command comes from an initiator that is authorized to address the specific target. In addition an eavesdropper cannot know where the going to (i.e. initiator address). The eavesdropper can do very little with what it may obtain (random raw traffic) unless he stores huge traces and try to decipher it off-line. 5. Binary Packet Protocol This section defines the format of the packet transferred between client and server. Each packet is of the following format. uint32 packet_length byte padding_length byte[n1] payload; n1 = packet_length - padding_length 1 byte[n2] random padding; n2 = padding_length byte[m] mac (message authentication code); m = mac_length . packet_length The length of the packet (bytes), not including MAC or the packet_length field itself. . padding_length Length of padding (bytes). . payload The useful contents of the packet. . Padding Arbitrary-length padding, such that the total length of (packet_length || padding_length || payload || padding) is a multiple of the cipher block size or 8, whichever is larger. There MUST be at least four bytes of padding. The padding SHOULD consist of random bytes. The maximum amount of padding is 255 bytes. . MAC Message authentication code. If message authentication has been negotiated, this field contains the MAC bytes. Initially, the MAC algorithm MUST be "none". Note that length of the concatenation of packet length, padding length, payload, and padding MUST be a multiple of the cipher block size or 8, whichever is larger. This constraint MUST be enforced even when using stream ciphers. Note that the packet length field Klein, Felstaine [page 8] iSCSI Security Protocol July 2000 is also encrypted, and processing it requires special care when sending or receiving packets. The minimum size of a packet is 16 (or the cipher block size, whichever is larger) bytes (plus MAC); implementations SHOULD decrypt the length after receiving the first 8 (or cipher block size, whichever is larger) bytes of a packet. 5.1. Maximum Packet Length All implementations MUST be able to process packets with uncompressed payload length of 32768 bytes or less and total packet size of 35000 bytes or less (including length, padding length, payload, padding, and MAC). Implementations SHOULD support longer packets, where they might be needed e.g. if an implementation wants to send a very large number of certificates. Such packets MAY be sent if the version string indicates that the other party is able to process them. However, implementations SHOULD check that the packet length is reasonable for the implementation to avoid denial- of-service and/or buffer overflow attacks. 5.2. Encryption An encryption algorithm and a key will be negotiated during the key exchange. When encryption is in effect, the packet length, padding length, payload and padding fields of each packet MUST be encrypted with the given algorithm. The encrypted data in all packets sent in one direction SHOULD be considered a single data stream. For example, initialization vectors SHOULD be passed from the end of one packet to the beginning of the next packet. All ciphers SHOULD use keys with an effective key length of 128 bits or more. The ciphers in each direction MUST run independently of each other, and implementations MUST allow independently choosing the algorithm for each direction (if multiple algorithms are allowed by local policy). The following ciphers are currently defined: 3des_cbc REQUIRED three key 3DES in CBC mode blowfish_cbc RECOMMENDED Blowfish in CBC mode twofish_cbc RECOMMENDED Twofish in CBC mode Arcfour OPTIONAL the ARCFOUR stream cipher idea_cbc OPTIONAL IDEA in CBC mode cast128_cbc OPTIONAL CAST-128 in CBC mode none OPTIONAL no encryption; NOT RECOMMENDED The "3des-cbc" cipher is three-key triple-DES (encrypt-decrypt- encrypt), where the first 8 bytes of the key are used for the first encryption, the next 8 bytes for the decryption, and the following 8 bytes for the final encryption. This requires 24 bytes of key Klein, Felstaine [page 9] iSCSI Security Protocol July 2000 data (of which 168 bits are actually used). To implement CBC mode, outer chaining MUST be used (i.e., there is only one initialization vector). This is a block cipher with 8 byte blocks. This algorithm is defined in [Schneier]. The "blowfish-cbc" cipher is Blowfish in CBC mode, with 128 bit keys [Schneier]. This is a block cipher with 8 byte blocks. The "twofish-cbc" cipher is Twofish in CBC mode, with 256 bit keys as described in Twofish AES submission. This is a block cipher with 16 byte blocks. The "arcfour" is the Arcfour stream cipher with 128 bit keys. The Arcfour cipher is believed to be compatible with the RC4 cipher [Schneier]. RC4 is a registered trademark of RSA Data Security Inc. The "idea-cbc" cipher is the IDEA cipher in CBC mode [Schneier]. IDEA is patented by Ascom AG. The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode [RFC- 2144]. The "none" algorithm specifies that no encryption is to be done. Note that this method provides no confidentiality protection, and it is not recommended. Some functionality (e.g. password authentication) may be disabled for security reasons if this cipher is chosen. 5.3. Data Integrity Data integrity is protected by including with each packet a message authentication code (MAC) that is computed from a shared secret, packet sequence number, and the contents of the packet. The message authentication algorithm and key are negotiated during key exchange. Initially, no MAC will be in effect, and its length MUST be zero. After key exchange, the selected MAC will be computed before encryption from the concatenation of packet data: mac = MAC(key, sequence_number || unencrypted_packet) where unencrypted_packet is the entire packet without MAC (the length fields, payload and padding), and sequence_number is an implicit packet sequence number represented as uint32. The sequence number is initialized to zero for the first packet, and is incremented after every packet (regardless of whether encryption or MAC is in use). It is never reset, even if keys/algorithms are renegotiated later. It wraps around to zero after every 2^32 packets. The packet sequence number itself is not included in the packet sent over the wire. The MAC algorithms for each direction MUST run independently, and implementations MUST allow choosing the algorithm independently for Klein, Felstaine [page 10] iSCSI Security Protocol July 2000 both directions. The MAC bytes resulting from the MAC algorithm MUST be transmitted without encryption as the last part of the packet. The number of MAC bytes depends on the algorithm chosen. The following MAC algorithms are currently defined: hmac-sha1 REQUIRED HMAC-SHA1 (length = 20) hmac-sha-96 RECOMMENDED first 96 bits of HMAC-SHA1 (length = 12) hmac-md5 OPTIONAL HMAC-MD5 (length = 16) hmac-md5-96 OPTIONAL first 96 bits of HMAC-MD5 (length = 12) none OPTIONAL no MAC; NOT RECOMMENDED The "hmac-*" algorithms are described in [RFC-2104]. The "*-n" MACs use only the first n bits of the resulting value. The hash algorithms are described in [Schneier]. The "none" method is NOT RECOMMENDED. An active attacker may be able to modify transmitted data if this is used. 5.4. Key Exchange Methods The key exchange method specifies how one-time session keys are generated for encryption and for authentication, and how the server authentication is done. Only one REQUIRED key exchange method has been defined: diffie-hellman-group1-sha1 REQUIRED This method is described later in this document. 5.5. Public Key Algorithms This protocol has been designed to be able to operate with almost any public key format, encoding, and algorithm (signature and/or encryption). There are several aspects that define a public key type: . Key format: how is the key encoded and how are certificates represented. The key blobs in this protocol MAY contain certificates in addition to keys. . Signature and/or encryption algorithms. Some key types may not support both signing and encryption. Key usage may also be restricted by policy statements in e.g. certificates. In this case, different key types SHOULD be defined for the different policy alternatives. . Encoding of signatures and/or encrypted data. This includes Klein, Felstaine [page 11] iSCSI Security Protocol July 2000 but is not limited to padding, byte order, and data formats. The following public key and/or certificate formats are currently defined: iscsi-dss REQUIRED sign Simple DSS x509v3 RECOMMENDED sign X.509 certificates spki OPTIONAL sign SPKI certificates pgp OPTIONAL sign OpenPGP The key type MUST always be explicitly known (from algorithm negotiation or some other source). It is not normally included in the key blob. Certificates and public keys are encoded as: uint32 combined length of the format identifier and associated data string certificate or public key format identifier byte[n] key/certificate data The certificate part may have be a zero length string, but a public key is required. This is the public key that will be used for authentication; the certificate sequence contained in the certificate blob can be used to provide authorization. The "iscsi-dss" key format has the following specific encoding: uint32 Length string "iscsi-dss" mpint P mpint Q mpint G mpint Y Here the "p", "q", "g", and "y" parameters form the signature key blob. Signing and verifying using this key format are done according to the Digital Signature Standard [FIPS-186] using the SHA-1 hash. A description can also be found in [Schneier]. The resulting signature is encoded as: uint32 length string "iscsi-dss" string dss_signature_blob dss_signature_blob is encoded as string containing "r" followed by "s" (which are 160 bits long integers, without lengths or padding, unsigned and in network byte order). The "x509v3" method indicates that the certificates, the public key, and the resulting signature are in X.509v3 compatible DER- encoded format. The formats used in X.509v3 is described in [PKIX-Part1]. Klein, Felstaine [page 12] iSCSI Security Protocol July 2000 The "spki" method indicates that the certificate blob contains a sequence of SPKI certificates. The format of SPKI certificates is described in [SPKI]. The "pgp" method indicates the the certificates, the public key, and the signature are in OpenPGP compatible binary format. [RFC- 2440] 6. Key Exchange Key exchange begins by each side sending lists of supported algorithms. Each side has a preferred algorithm in each category, and it is assumed that most implementations at any given time will use the same preferred algorithm. Each side MAY guess which algorithm the other side is using, and MAY send an initial key exchange packet according to the algorithm if appropriate for the preferred method. If all algorithms were guessed right, the optimistically sent packet MUST be handled as the first key exchange packet. However, if the guess was wrong, and a packet was optimistically sent by one or both parties, such packets MUST be ignored (even if the error in the guess would not affect the contents of the initial packet(s)), and the appropriate side MUST send the correct initial packet. Server authentication in the key exchange MAY be implicit. After a key exchange with implicit server authentication, the client MUST wait for response to its service request message before sending any further data. 6.1. Algorithm Negotiation Key exchange begins by each side sending the following packet: Byte iSCSI_MSG_KEXINIT byte[16] cookie (random bytes) string kex_algorithms string server_host_key_algorithms string encryption_algorithms_client_to_server string encryption_algorithms_server_to_client string Mac_algorithms_client_to_server string Mac_algorithms_server_to_client string languages_client_to_server string languages_server_to_client Boolean First_kex_packet_follows uint32 0 (reserved for future extension) Each of the algorithm strings MUST be a comma-separated list of algorithm names. Each supported (allowed) algorithm MUST be listed, in order of preference. Klein, Felstaine [page 13] iSCSI Security Protocol July 2000 The first algorithm in each list MUST be the preferred (guessed) algorithm. Each string MUST contain at least one algorithm name. . cookie The cookie MUST be a random value generated by the sender. Its purpose is to make it impossible for either side to fully determine the keys and the session identifier. . kex_algorithms Key exchange algorithms were defined above. The first algorithm MUST be the preferred (and guessed) algorithm. If both sides make the same guess, that algorithm MUST used. Otherwise, the following algorithm MUST be used to choose a key exchange method: iterate over client's kex algorithms, one at a time. Choose the first algorithm that satisfies the following conditions: . the server also supports the algorithm, . if the algorithm requires an encryption-capable host key, there is an encryption-capable algorithm on the server's server_host_key_algorithms that is also supported by the client, and . if the algorithm requires a signature-capable host key, there is a signature-capable algorithm on the server's server_host_key_algorithms that is also supported by the client. If no algorithm satisfying all these conditions can be found, the connection fails, and both sides MUST disconnect. . server_host_key_algorithms List of the algorithms supported for the server host key. The server lists the algorithms for which it has host keys; the client lists the algorithms that it is willing to accept. (There MAY be multiple host keys for a host, possibly with different algorithms.) Some host keys may not support both signatures and encryption (this can be determined from the algorithm), and thus not all host keys are valid for all key exchange methods. Algorithm selection depends on whether the chosen key exchange algorithm requires a signature- or encryption capable host key. It MUST be possible to determine this from the public key algorithm name. The first algorithm on the client's list that satisfies the requirements and is also supported by the server MUST be chosen. If there is no such algorithm, both sides MUST disconnect. . encryption_algorithms Klein, Felstaine [page 14] iSCSI Security Protocol July 2000 Lists the acceptable symmetric encryption algorithms in order of preference. The chosen encryption algorithm to each direction MUST be the first algorithm on the client's list that is also on the server's list. If there is no such algorithm, both sides MUST disconnect. Note that "none" must be explicitly listed if it is to be acceptable. The defined algorithm names are listed in Section ''Encryption''. . mac_algorithms Lists the acceptable MAC algorithms in order of preference. The chosen MAC algorithm MUST be the first algorithm on the client's list that is also on the server's list. If there is no such algorithm, both sides MUST disconnect. Note that "none" must be explicitly listed if it is to be acceptable. The MAC algorithm names are listed in Section ''Data Integrity''. . languages This is a comma-separated list of language tags in order of preference [RFC-1766]. Both parties MAY ignore this list. If there are no language preferences, this list SHOULD be empty. . first_kex_packet_follows Indicates whether a guessed key exchange packet follows. If a guessed packet will be sent, this MUST be true. If no guessed packet will be sent, this MUST be false. After receiving the iSCSI_MSG_KEXINIT packet from the other side, each party will know whether their guess was right. If the other party's guess was wrong, and this field was true, the next packet MUST be silently ignored, and both sides MUST then act as determined by the negotiated key exchange method. If the guess was right, key exchange MUST continue using the guessed packet. After the KEXINIT packet exchange, the key exchange algorithm is run. It may involve several packet exchanges, as specified by the key exchange method. 6.2. Output from Key Exchange The key exchange produces two values: a shared secret K, and an exchange hash H. Encryption and authentication keys are derived from these. The exchange hash H from the first key exchange is additionally used as the session identifier, which is a unique identifier for this connection. It is used by authentication methods as a part of the data that is signed as a proof of possession of a private key. Once computed, the session identifier is not changed, even if keys are later re- Klein, Felstaine [page 15] iSCSI Security Protocol July 2000 exchanged. Each key exchange method specifies a hash function that is used in the key exchange. The same hash algorithm MUST be used in key derivation. Here, we'll call it HASH. Encryption keys MUST be computed as HASH of a known value and K as follows: . Initial IV client to server: HASH(K || H || "A" || session_id) (Here K is encoded as mpint and "A" as byte and session_id as raw data."A" means the single character A, ascii 65). . Initial IV server to client: HASH(K || H || "B" || session_id) . Encryption key client to server: HASH(K || H || "C" || session_id) . Encryption key server to client: HASH(K || H || "D" || session_id) . Integrity key client to server: HASH(K || H || "E" || session_id) . Integrity key server to client: HASH(K || H || "F" || session_id) Key data MUST be taken from the beginning of the hash output. 128 bits (16 bytes) SHOULD be used for algorithms with variable-length keys. For other algorithms, as many bytes as are needed are taken from the beginning of the hash value. If the key length in longer than the output of the HASH, the key is extended by computing HASH of the concatenation of K and H and the entire key so far, and appending the resulting bytes (as many as HASH generates) to the key. This process is repeated until enough key material is available; the key is taken from the beginning of this value. In other words, K1 = HASH(K || H || X || session_id) (X is e.g. "A") K2 = HASH(K || H || K1) K3 = HASH(K || H || K1 || K2) ... key = K1 || K2 || K3 || ... 6.3. Taking Keys into Use Key exchange ends by each side sending an iSCSI_MSG_NEWKEYS message. This message is sent with the old keys and algorithms. All messages sent after this message MUST use the new keys and algorithms. Klein, Felstaine [page 16] iSCSI Security Protocol July 2000 When this message is received, the new keys and algorithms MUST be taken into use for receiving. This message is the only valid message after key exchange, in addition to iSCSI_MSG_DEBUG, iSCSI_MSG_DISCONNECT and iSCSI_MSG_IGNORE messages. The purpose of this message is to ensure that a party is able to respond with a disconnect message that the other party can understand if something goes wrong with the key exchange. Implementations MUST NOT accept any other messages after key exchange before receiving iSCSI_MSG_NEWKEYS. 7. Diffie-Hellman Key Exchange The Diffie-Hellman key exchange provides a shared secret that can not be determined by either party alone. The key exchange is combined with a signature with the host key to provide host authentication. In the following description (C is the client, S is the server; p is a large safe prime, g is a generator for a subgroup of GF(p), and q is the order of the subgroup; V_S is S's version string; V_C is C's version string; K_S is S's public host key; I_C is C's KEXINIT message and I_S S's KEXINIT message which have been exchanged before this part begins): 1. C generates a random number x (1 < x < q) and computes e = g^x 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 Klein, Felstaine [page 17] iSCSI Security Protocol July 2000 with the KEXINIT messages. First, the client sends: Byte iSCSI_MSG_KEXDH_INIT Mpint E The server responds with: Byte iSCSI_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 iSCSI_MSG_KEXINIT String I_S, the payload of the server's iSCSI _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 signature algorithm MUST be applied over H, not the original data. Most signature algorithms include hashing and additional padding. For example, a "iscsi-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 the following group: 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 FFFFFFFF FFFFFFFF. In decimal, this value is Klein, Felstaine [page 18] iSCSI Security Protocol July 2000 179769313486231590770839156793787453197860296048756011706444 423684197180216158519368947833795864925541502180565485980503 646440548199239100050792877003355816639229553136239076508735 759914822574862575007425302077447712589550957937778424442426 617334727629299387668709205606050270810842907692932019128194 467627007. The generator used with this prime is g = 2. The group order q is (p - 1) / 2. This group was taken from the ISAKMP/Oakley specification, and was originally generated by Richard Schroeppel at the University of Arizona. Properties of this prime are described in [Orm96]. 8. Key Re-Exchange Key re-exchange is started by sending a iSCSI_MSG_KEXINIT packet when not already doing a key exchange (as described in Section ''Algorithm Negotiation''). When this message is received, a party MUST respond with its own iSCSI_MSG_KEXINIT message except when the received iSCSI_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 and MAC methods are not changed before a new iSCSI_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. 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 iSCSI_MSG_NEWKEYS packet has been sent; key exchange does not affect the protocols that lie above the iSCSI layer. 9. Service Request After the key exchange, the client requests a service. The service is identified by a name. Currently, the following names have been reserved: . iscsi-userauth . iscsi-connection Klein, Felstaine [page 19] iSCSI Security Protocol July 2000 Similar local naming policy is applied to the service names that is applied to the algorithm names; a local service should use the servicename@domain syntax. Byte iSCSI_MSG_SERVICE_REQUEST String service name If the server rejects the service request, it SHOULD send an appropriate iSCSI_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 Byte iSCSI_MSG_SERVICE_ACCEPT String service name Message numbers used by services should be in the area reserved for them (see Section ''Summary of Message Numbers''). 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. 10.1. Disconnection Message Byte iSCSI_MSG_DISCONNECT uint32 reason code String description [RFC- 2044] String language tag [RFC- 1766] 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 iSCSI_DISCONNECT_HOST_NOT_ALLOWED_TO_CONNECT 1 #define iSCSI_DISCONNECT_PROTOCOL_ERROR 2 #define iSCSI_DISCONNECT_KEY_EXCHANGE_FAILED 3 #define iSCSI_DISCONNECT_RESERVED 4 #define iSCSI_DISCONNECT_MAC_ERROR 5 #define iSCSI_DISCONNECT_SERVICE_NOT_AVAILABLE 7 Klein, Felstaine [page 20] iSCSI Security Protocol July 2000 #define iSCSI_DISCONNECT_PROTOCOL_VERSION_NOT_SUPPORTED 8 #define iSCSI_DISCONNECT_HOST_KEY_NOT_VERIFIABLE 9 #define iSCSI_DISCONNECT_CONNECTION_LOST 10 #define iSCSI_DISCONNECT_BY_APPLICATION 11 #define iSCSI_DISCONNECT_TOO_MANY_CONNECTIONS 12 #define iSCSI_DISCONNECT_AUTH_CANCELLED_BY_USER 13 #define iSCSI_DISCONNECT_NO_MORE_AUTH_METHODS_AVAILABLE 14 #define iSCSI_DISCONNECT_ILLEGAL_USER_NAME 15 11. User Authentication This section describes the user authentication phase. The server drives the authentication by telling the client which authentications can usefully continue the dialog at any given time. The client has the freedom to try the methods listed by the server in any order. This gives the server complete control over the authentication process if it so desired, but also gives enough flexibility for the client to use the methods it supports or that are most convenient for the user when multiple methods are offered by the server. Authentication methods are identified by names. The "none" method is reserved, and MUST NOT be listed as supported. However, it MAY be sent by the client. The server MUST always reject this request, unless the client is to be allowed in without any authentication, in which case the server MUST accept this request. The main purpose of sending this request is to get the list of supported methods from the server. The server SHOULD have a timeout for authentication, and disconnect if the authentication has not been accepted within the timeout period. The RECOMMENDED timeout period is 10 minutes. Additionally, the implementation SHOULD limit the number of failed authentication attempts a client may perform in a single session (the RECOMMENDED limit is 20 attempts). If the threshold is exceeded, the server SHOULD disconnect. 11.1. Authentication Requests All authentication requests MUST use the following message format. Only the first few fields are defined; the remaining fields depend on the authentication method. Byte iSCSI_MSG_USERAUTH_REQUEST String user name (in ISO-10646 UTF-8 encoding) String service name (in US-ASCII) String method name (US-ASCII) rest of the packet is method-specific The user name and service are repeated in every new authentication attempt, and MAY change. The server implementation MUST carefully check them in every message, and MUST flush any accumulated Klein, Felstaine [page 21] iSCSI Security Protocol July 2000 authentication state if they change. If it is unable to flush some authentication state, it MUST disconnect if the user or service name changes. The service name specifies the service to start after authentication. There may be several different authenticated services provided. If the requested service is not available, the server MAY disconnect immediately or any time later. Sending a proper disconnect message is RECOMMENDED. In any case, if the service does not exist, authentication MUST NOT be accepted. If the requested user does not exist, the server MAY disconnect, or MAY send a bogus list of acceptable authentications but never accept any. This makes it possible for the server to avoid disclosing information about which accounts exist. In any case, if the user does not exist, the authentication request MUST NOT be accepted. While there is usually little point for clients to send requests that the server does not list as acceptable, sending such requests is not an error, and the server SHOULD simply reject requests that it does not recognize. An authentication request MAY result in a further exchange of messages. All such messages depend on the authentication method used, and the client MAY at any time continue with a new iSCSI_MSG_USERAUTH_REQUEST message, in which case the server MUST abandon the previous authentication attempt and continue with the new one. 11.2. Responses to Authentication Requests If the server rejects the authentication request, it MUST respond with Byte iSCSI_MSG_USERAUTH_FAILURE String authentications that can continue Boolean partial success "Authentications that can continue" is a comma-separated list of authentication method names that may productively continue the authentication dialog. It is RECOMMENDED that servers only include those methods in the list that are actually useful. However, it is not illegal to include methods that cannot be used to authenticate the user. Already successfully completed authentications SHOULD NOT be included in the list, unless they really should be performed again for some reason. "Partial success" MUST be true if the authentication request to which this is a response was successful. It MUST be false if the Klein, Felstaine [page 22] iSCSI Security Protocol July 2000 request was not successfully processed. When the server accepts authentication, it MUST respond with byte iSCSI_MSG_USERAUTH_SUCCESS Note that this is not sent after each step in a multi-method authentication sequence, but only when authentication is complete. The client MAY send several authentication requests without waiting for responses from previous requests. The server MUST acknowledge any failed requests with a iSCSI_MSG_USERAUTH_FAILURE message. However, iSCSI_MSG_USERAUTH_SUCCESS MUST sent only once, and once iSCSI_MSG_USERAUTH_SUCCESS has been sent, any further authentication requests received after that SHOULD be silently ignored. Any non-authentication messages sent by the client after the request that resulted in iSCSI_MSG_USERAUTH_SUCCESS being sent MUST be passed to the service being run on top of this protocol. Such messages can be identified by their message numbers (see Section ''Message Numbers''). 11.3. The none Authentication Request A client may request a list of authentication methods that may continue by using the "none" authentication method. If no authentication at all is needed for the user, the server MUST return iSCSI_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return iSCSI_MSG_USERAUTH_FAILURE and MAY return with it a list of authentication methods that can continue. This method MUST NOT be listed as supported by the server. 11.4. Completion of User Authentication Authentication is complete when the server has responded with iSCSI_MSG_USERAUTH_SUCCESS; all authentication related messages received after sending this message SHOULD be silently ignored. After sending iSCSI_MSG_USERAUTH_SUCCESS, the server starts the requested service. 11.5. Public Key Authentication Method: publickey The only REQUIRED authentication method is public key authentication. All implementations MUST support this method; however, not all users need to have public keys, and most local policies are not likely to require public key authentication for all users in near future. With this method, the possession of a private key serves as authentication. This method works by sending a signature created with a private key of the user. The server MUST check that the key is a valid authenticator for the user, and MUST check that the Klein, Felstaine [page 23] iSCSI Security Protocol July 2000 signature is valid. If both hold, the authentication request MUST be accepted; otherwise it MUST be rejected. (Note that the server MAY require additional authentications after successful authentication.) Private keys are often stored encrypted at the client host, and the user must supply a passphrase before the signature can be generated. Even if they are not, the signing operation involves some expensive computation. To avoid unnecessary processing and user interaction, the following message is provided for querying whether authentication using the key would be acceptable. Byte iSCSI_MSG_USERAUTH_REQUEST String user name String service String "publickey" Boolea FALSE String Public key algorithm name String Public key blob Public key algorithms were defined earlier. The public key blob may contain certificates. Any public key algorithm may be offered for use in authentication. In particular, the list is not constrained by what was negotiated during key exchange (as that was affected by which algorithms the server had a host key). If the server does not support some algorithm, it MUST simply reject the request. The server MUST respond to this message with either iSCSI_MSG_USERAUTH_FAILURE or with Byte iSCSI_MSG_USERAUTH_PK_OK String public key algorithm name from the request String public key blob from the request To do actual authentication, the client MAY then send a signature generated using the private key. Client MAY send the signature directly without first verifying whether the key is acceptable. The signature is sent using the following packet Byte iSCSI_MSG_USERAUTH_REQUEST String user name String service String "publickey" Boolean TRUE String public key algorithm name String Public key to be used for authentication String signature Signature is a signature by the corresponding private key over the following data, in this order: Klein, Felstaine [page 24] iSCSI Security Protocol July 2000 . session identifier (encoded as string), and . packet payload without the signature. When the server receives this message, it MUST check whether the supplied key is acceptable for authentication, and if so, it MUST check whether the signature is correct. If both checks succeed, this method is successful. Note that the server may require additional authentications. The server MUST respond with iSCSI_MSG_USERAUTH_SUCCESS (if no more authentications are needed), or iSCSI_MSG_USERAUTH_FAILURE (if the request failed, or more authentications are needed). The following method-specific message numbers are used by the publickey authentication method. /* Key-based */ #define iSCSI_MSG_USERAUTH_PK_OK 60 11.6. Password Authentication Method: password Password authentication uses the following packets. Note that a server MAY request the user to change password. All implementations SHOULD support password authentication. Byte iSCSI_MSG_USERAUTH_REQUEST String user name String service String "password" Boolean FALSE String plaintext password (ISO- 10646 UTF-8) Note that the password is encoded in ISO-10646 UTF-8. It is up to the server how it interprets the password and validates it against the password database. However, if the client reads the password in some other encoding (e.g., ISO 8859-1 (ISO Latin1)), it MUST convert the password to ISO-10646 UTF-8 before transmitting, and the server MUST convert the password to the encoding used on that system for passwords. Note that even though the cleartext password is transmitted in the packet, the entire packet is encrypted by the transport layer. Both the server and the client should check whether the underlying transport layer provides confidentiality (i.e., encryption is being used). If no confidentiality is provided ("none" cipher), password authentication SHOULD be disabled. If there is no confidentiality or no MAC, password change SHOULD be disabled. Normally, the server responds to this message with success or failure. However, the server MAY also respond with iSCSI_MSG_USERAUTH_PASSWD_CHANGEREQ. Klein, Felstaine [page 25] iSCSI Security Protocol July 2000 Byte iSCSI_MSG_USERAUTH_PASSWD_CHANGEREQ String prompt (ISO-10646 UTF-8) String language tag (as defined in RFC 1766) In this case, the software client SHOULD request a new password from the user, and send a new request using the following message. The client may also send this message instead of the normal password authentication request without the server asking for it. Byte iSCSI_MSG_USERAUTH_REQUEST String user name String service String "password" Boolean TRUE String plaintext old password (ISO-10646 UTF-8) String plaintext new password (ISO-10646 UTF-8) The server must reply to request message with iSCSI_MSG_USERAUTH_SUCCESS, iSCSI_MSG_USERAUTH_FAILURE, or another iSCSI_MSG_USERAUTH_PASSWD_CHANGEREQ. The meaning of these is as follows: iSCSI_MSG_USERAUTH_SUCCESS Password has been changed, and authentication has been successfully completed. iSCSI_MSG_USERAUTH_FAILURE with partial success The password has been changed, but more authentications are needed. iSCSI_MSG_USERAUTH_FAILURE without partial success The password has not been changed. Either password changing was not supported, or the old password was bad. Note that if the server has already sent iSCSI_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports changing the password. iSCSI_MSG_USERAUTH_CHANGEREQ The password was not changed because the new password was not acceptable (e.g. too easy to guess). 12. References [FIPS-186] Federal Information Processing Standards Publication (FIPS PUB) 186, Digital Signature Standard, 18 May 1994. [Orm96] Orman, H., "The Oakley Key Determination Protocol", version 1, TR97-92, Department of Computer Science Technical Report, University of Arizona. [PKIX-Part1] Housley, R., et al, "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile", Internet Draft, draft- ietf-pkix-ipki-part1-11.txt Klein, Felstaine [page 26] iSCSI Security Protocol July 2000 [RFC-1034] Mockapetris, P., "Domain Names - Concepts and Facilities", November 1987. [RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", March 1995. [RFC-1950] Deutch, P. and Gailly, J-L., "ZLIB Compressed Data Format Specification version 3.3", May 1996. [RFC-1951] Deutch, P., "DEFLATE Compressed Data Format Specification version 1.3", May 1996. [RFC-2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode and ISO 10646", October 1996. [RFC-2104] Krawczyk, H., Bellare, M., and Canetti, R., "HMAC: Keyed- Hashing for Message Authentication", February 1997 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", March 1997. [RFC-2144] Adams, C., "The CAST-128 Encryption Algorithm", May 1997. [RFC-2440] Callas, J., et al, "OpenPGP Message Format", November 1998. [Schneier] Schneier, B., "Applied Cryptography Second Edition: protocols, algorithms, and source code in C", 2nd edition, John Wiley & Sons, New York, NY, 1996. [SSH-ARCH] Ylonen, T., et al, "SSH Protocol Architecture", Internet Draft, draft-ietf-secsh-architecture-05.txt [SSH-USERAUTH] Ylonen, T., et al, "SSH Authentication Protocol", Internet Draft, draft-ietf-secsh-userauth-07.txt [SSH-CONNECT] Ylonen, T., et al, "SSH Connection Protocol", Internet Draft, draft-ietf-secsh-connect-07.txt 13. Authors' Addresses Yaron Klein SANRAD 5 Haarad St. Tel-Aviv, Israel Phone 972-3-7664297 e-mail klein@sanrad.com Eyal Felstaine SANRAD 5 Haarad St. Tel-Aviv, Israel Phone: 972-3-7659997 Email: eyal@sanrad.com Klein, Felstaine [page 27]