IPS Working Group Bernard Aboba INTERNET-DRAFT William Dixon Category: Standards Track Microsoft <draft-ietf-ips-security-00.txt> David Black 13 September 2001 EMC Joshua Tseng Nishan Systems Joseph Tardo Uri Elzur Broadcom M. Bakke S. Senum Cisco Systems Howard Herbert Jesse Walker Intel J. Satran Ofer Biran Charles Kunzinger IBM Securing iSCSI and iFCP using IPsec 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. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Aboba, et al. Standards Track [Page 1]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 Abstract This document discusses how iSCSI and iFCP may utilize IPsec to provide authentication, integrity, confidentiality and replay protection. Table of Contents 1. Introduction .......................................... 3 1.1 IPsec background ................................ 4 1.2 Terminology ..................................... 5 1.3 Requirements language ........................... 5 2. iSCSI security ........................................ 5 2.1 iSCSI security requirements .................... 5 2.2 Resource constraints ............................ 6 2.3 iSCSI security protocol ......................... 8 3. iSCSI security inter-operability guidelines ........... 8 3.1 iSCSI/IPsec binding ............................. 8 3.2 Initiating a new iSCSI session .................. 9 3.3 Graceful iSCSI teardown ......................... 10 3.4 Non-graceful iSCSI teardown ..................... 11 3.5 Application layer CRC ........................... 12 4. iFCP security ......................................... 13 4.1 iFCP security requirements ...................... 13 4.2 iFCP security design requirements ............... 16 5. Security considerations ............................... 17 5.1 Transport mode versus tunnel mode ............... 17 5.2 IKE issues ...................................... 18 5.3 Rekeying issues ................................. 18 5.4 Transform issues ................................ 21 5.5 IKE and application layer authentication ........ 23 5.6 Fragmentation issues ............................ 24 5.7 Security checks ................................. 25 5.8 NAT traversal ................................... 25 5.9 Certificate authentication ...................... 26 5.10 Machine versus user authentication .............. 26 5.11 Pre-shared keys ................................. 27 5.7 Use of AES in counter mode ...................... 28 6. References ............................................ 29 Appendix A - Software Performance of IPsec Transforms ....... 33 A.1 Authentication transforms ....................... 33 A.2 Encryption and Authentication transforms ........ 36 ACKNOWLEDGMENTS .............................................. 41 AUTHORS' ADDRESSES ........................................... 42 Intellectual property statement .............................. 44 Full Copyright Statement ..................................... 44 Aboba, et al. Standards Track [Page 2]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 1. Introduction iSCSI, described in [1], is a connection-oriented command/response protocol that runs over TCP, and is used to access disk, tape and other devices. iSCSI is a client-server protocol in which clients (Initiators) open connections to servers (Targets) and perform an iSCSI login. This draft uses the SCSI terms Initiator and Target for clarity and to avoid the common assumption that clients have considerably less computational and memory resources than servers; the reverse is often the case for SCSI, as Targets are commonly dedicated devices of some form. The iSCSI protocol has a text based negotiation mechanism as part of its initial (Login) procedure. The mechanism is extensible in what can be negotiated (new text keys and values can be defined) and also in the number of negotiation rounds (e.g., to accommodate functionality such as challenge-response authentication). While the iSCSI login may include mutual authentication of the iSCSI endpoints and negotiation of session parameters, iSCSI does not define its own per-packet authentication, integrity, confidentiality or replay protection mechanisms. After a successful login, the iSCSI Initiator may issue SCSI commands for execution by the iSCSI Target, which returns a status response for each command, over the same connection. A single connection is used for both command/status messages as well as transfer of data and/or optional command parameters. An iSCSI session may have multiple connections, but a separate login is performed on each. The iSCSI session terminates when its last connection is closed. iSCSI Initiators and Targets are layer 5 entities that are independent of TCP ports and IP addresses. An Initiator or Target may use multiple communication endpoints (<TCP port, IP address> pair), and such endpoints may be shared by multiple Initiators or Targets. The common case for sharing will be that the sharing entities are all of the same type (i.e., all Initiators or all Targets). iSCSI entities have names that are independent of communication endpoints, and iSCSI defines its own naming syntax for such entities (i.e., Initiators and Targets), see [52]. iFCP is a gateway-to-gateway protocol, which provides Fibre Channel fabric services to Fibre Channel devices over a TCP/IP network. iFCP uses TCP to provide congestion control, error detection and error recovery. iFCP's primary objective is to allow interconnection and networking of existing Fibre Channel devices at wire speeds over an IP network. The protocol achieves this transparency through a process that allows normal Fibre Channel frame traffic to pass through the gateway Aboba, et al. Standards Track [Page 3]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 directly, with provisions where necessary for intecepting and emulating the fabric services required by a Fibre Channel device. iFCP does not have a native, in-band security mechanism. Rather, iFCP relies upon the IPsec protocol suite to provide data confidentiality and authentication services, and IKE as the key management protocol. Each IPsec SA established by IKE protects a single TCP connection, which is used to support storage traffic between a unique pair of Fibre Channel N_PORTs. IPsec is a protocol suite which is used to secure communication at the network layer between two peers. The IPsec protocol suite is specified within the IP Security Architecture [6], IKE [7], IPsec Authentication Header (AH) [3] and IPsec Encapsulating Security Payload (ESP) [4] documents. IKE is the key management protocol while AH and ESP are used to protect IP traffic. This draft proposes use of the IPsec protocol suite for protecting iSCSI and iFCP traffic over IP networks, and discusses how iFCP and iSCSI should be used with IPsec. 1.1. IPsec background An IPsec SA is a one-way security association, uniquely identified by the 3-tuple: SPI, protocol (ESP) and destination IP. The parameters for an IPsec security association are typically established by a key management protocol. These include the encapsulation mode, encapsulation type, session keys and SPI values. IKE is a two phase negotiation protocol based on the modular exchange of messages defined by ISAKMP [54]. IKE has two phases, and accomplishes the following functions: [1] Protected cipher suite and options negotiation - using keyed HMACs and encryption and anti-replay mechanisms [2] Master key generation - via MODP Diffie-Hellman calculations [3] Authentication of end-points [4] IPsec SA management (selector negotiation, options negotiation, create, delete, and rekeying) An IKE phase 2 negotiation is performed to establish both an inbound and an outbound IPsec SAs. The traffic contained inside an IPsec SA is based on a selector proposed by the intiator, and accepted by the responder. In IPsec transport mode, the IPsec SA selector can be a "filter" or traffic classifier, defined as the 5-tuple: <Source IP Aboba, et al. Standards Track [Page 4]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 address, Destination IP address, transport protocol (UDP/SCTP/TCP), Source port, Destination port>. The session keys for each IPsec SA are derived from a master key, typically a MODP Diffie-Hellman computation. Rekeying of an existing IPsec SA pair is accomplished by creating two new IPsec SAs, making them active, and then optionally deleting the older IPsec SA pair. Typically the new outbound SA is used immediately, and the old inbound SA is left active to receive packets for some locally defined time, perhaps 30 seconds or 1 minute. 1.2. Terminology iSCSI iSCSI is a client-server protocol in which clients (Initiators) open connections to servers (Targets). Initiator The iSCSI Initiator connects to the Target on well-known TCP port <TBD>. The iSCSI Initiator then issues SCSI commands for execution by the iSCSI Target. Target The iSCSI Target listens on a well-known TCP port for incoming connections, and returns a status response for each command issued by the iSCSI Initiator, over the same connection. 1.3. Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [2]. 2. iSCSI security 2.1. iSCSI security requirements The iSCSI protocol is used to transmit SCSI commands over IP networks. Therefore, both the control and data packets of iSCSI are vulnerable to attack. Examples of attacks include: [1] An adversary may try to discover user identities by snooping data packets. [2] An adversary may try to modify packets (both control and data). [3] An adversary may try to hijack the iSCSI connection. [4] An adversary can launch denial of service attacks by terminating iSCSI connections, such as by sending a TCP reset. Aboba, et al. Standards Track [Page 5]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 [5] An adversary may attempt to disrupt the iSCSI logon negotiation so as to weaken the iSCSI authentication process or gain access to user passwords. To address these threats, the iSCSI security protocol MUST provide authentication, integrity and replay protection for control and data packets. It MUST provide confidentiality for control and data packets. An iSCSI security protocol MUST also provide a scalable approach to key management. Bi-directional authentication (Initiator to Target) and vice-versa MUST be provided. This authentication is logically between the iSCSI Initiator and the iSCSI Target (as opposed to between the TCP/IP communication endpoints). There is no requirement that the identities used in authentication be kept confidential (e.g., from a passive eavesdropper). The intent of the iSCSI design is that the Initiator and Target represent the systems (e.g., host and disk array or tape system) participating in the communication, as opposed to network communication interfaces or endpoints. The iSCSI protocol, and iSCSI logon authentication do not meet the security requirements for iSCSI. iSCSI logon authentication provides mutual authentication between the iSCSI Initiator and Target at connection origination, but does not protect control and data traffic on a per packet basis, leaving the iSCSI connection vulnerable to attack. iSCSI logon authentication can mutually authenticates the Initiator to the Target, but does not by itself provide per-packet authentication, integrity, confidentiality or replay protection. In addition, iSCSI logon authentication, outlined in [1], does not provide for a protected ciphersuite negotiation. Therefore, iSCSI logon provides a weak security solution. Given current networking technology, iSCSI security MUST be implementable at 1 Gbps in terms of CPU overhead and/or availability of suitable hardware implementations and SHOULD be implementable at 10 Gbbps. 10 Gbps implementations are desirable but are not an absolute requirement as implementation feasibility at these speeds is not yet proven. 2.2. Resource constraints iSCSI will be implemented on a variety of systems ranging from large servers running general purpose operating systems to embedded host bus adapters (HBAs). Host Bus Adapter is a generic term for a SCSI interface to other device(s); it's roughly analogous to the term Network Interface Card (NIC) for a TCP/IP network interface, except that HBAs generally have on-board SCSI implementations, whereas most NICs do not implement TCP, UDP, or IP. In general, a host bus adapter is the most constrained Aboba, et al. Standards Track [Page 6]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 iSCSI implementation environment, although an HBA may draw upon the resources of the system to which it is attached in some cases (e.g., authentication computations required for connection setup). More resources should be available to iSCSI implementations for embedded and general purpose operating systems. The following guidelines indicate the approximate level of resources that authentication, keying, and rekeying functionality can reasonably expect to draw upon: - Low power processors with small word size are generally not used, as power is usually not a constraining factor, with the possible exception of HBAs, which can draw upon the computational resources of the system into which they are inserted). Computational horsepower should be available to perform a reasonable amount of exponentiation as part of authentication and key derivation for connection setup. The same is true of rekeying, although the ability to avoid exponentiation for rekeying may be desirable (but is not an absolute requirement). - RAM and/or flash resources tend to be constrained in embedded implementations. 8-10 MB of code and data for authentication, keying, and rekeying is clearly excessive, 800-1000 KB is clearly larger than desirable, but tolerable if there is no other alternative and 80-100 KB should be acceptable. These sizes are intended as rough order of magnitude guidance, and should not be taken as hard targets or limits (e.g., smaller code sizes are always better). Software implementations for general purpose operating systems may have more leeway. The primary resource concern for implementation of authentication and keying mechanisms is code size, as iSCSI assumes that the computational horsepower to do exponentiations will be available. There is no dominant iSCSI usage scenario - the scenarios range from a single connection constrained only by media bandwidth to hundreds of Initiator connections to a single Target or communication endpoint. SCSI sessions and hence the connections they use tend to be relatively long lived; for disk storage, a host typically opens a SCSI connection on boot and closes it on shutdown. Tape session length tends to be measured in hours or fractions thereof (i.e., rapid fire sharing of the same tape device among different Initiators is unusual), although tape robot control sessions can be short when the robot is shared among tape drives. On the other hand, tape will not see a large number of Initiator connections to a single Target or communication endpoint, as each tape drive is dedicated to a single use at a single time, and a dozen tape drives is a large tape device. Aboba, et al. Standards Track [Page 7]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 2.3. iSCSI security protocol All iSCSI security compliant implementations MUST implement IPsec ESP in transport mode for securing both iSCSI control and data packets. If confidentiality is not used (e.g., iSCSI data traffic), ESP with NULL encryption may be used. The implementations MUST implement replay protection mechanisms of IPsec. iSCSI security MUST meet the key management requirements of the IPsec protocol suite. IKE MUST be supported for authentication, security association negotiation, and key management using the IPsec DOI [5]. To provide authentication, integrity and replay protection of iSCSI PDUs, iSCSI security implementations MUST support transport mode ESP with NULL encryption. HMAC-SHA1 MUST be supported for authentication, and AES in CBC MAC mode with XCBC extensions SHOULD be supported. To provide confidentiality, transport mode ESP with 3DES in CBC mode MUST be supported and AES in Counter Mode SHOULD be supported. To support authentication between the iSCSI Initiator and Target the Secure Remote Password (SRP) protocol described in RFC 2945 [48] MUST be implemented within the iSCSI text-based multi-round negotiation mechanism. A number of additional authentication protocols have also been specified in the current iSCSI draft. Negotiation between Initiator and Target is used to determine which authentication algorithm to use (or whether to use one at all); the connection closes if either side requires authentication and no mutually acceptable algorithm can be agreed upon. 3. iSCSI/IPsec inter-operability guidelines The following guidelines are established to meet iSCSI security requirements using IPsec in practical situations. 3.1. iSCSI/IPsec binding An iSCSI session [1], comprised of one or more TCP connections, is identified by the 2-tuple of the Initiator-defined identifier and the Target-defined identifier, <ISID, TSID>. Each connection within a given session is assigned a unique Connection Identification, CID. The TCP connection is identified by the 5-tuple <Source IP address, Destination IP address, TCP, Source Port, Destination Port>. An IPsec Phase 2 SA is identified by the 3-tuple <ESP,destination address, SPI>. The iSCSI session and connection information is carried within the iSCSI Login Commands, transported over TCP. Since an iSCSI initiator may have multiple interfaces, iSCSI connections within an iSCSI session may be initiated from different IP addresses. Similarly, multiple iSCSI targets Aboba, et al. Standards Track [Page 8]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 may exist behind a single IP address, so that there may be multiple iSCSI sessions between a given <source IP address, destination IP address> pair. The relationship between iSCSI sessions, TCP connections and IKE Phase 1 and Phase 2 SAs is as follows: [1] An iSCSI initiator or target may have more than one interface, and therefore may have multiple IP addresses. Also, multiple iSCSI initiators and targets may exist behind a single IP address. As a result, an iSCSI Session may correspond to multiple IKE Phase 1 Security Associations, though typically a single IKE Phase 1 security association will exist for an <Initiator IP address, Target IP address> tuple. [2] Each TCP connection within an iSCSI Session is protected by a separate IKE Phase 2 SA, with selectors specific to that TCP connection. Each IKE Phase 2 SA protects only a single TCP connection, and each TCP connection is transported under only one IKE Phase 2 SA. Given this, all the information needed for the iSCSI/IPsec binding is contained within the iSCSI Login messages from the iSCSI Initiator and Target. This includes the binding between an IKE Phase 1 SA and the corresponding iSCSI sessions, as well as the binding between an IPsec Phase 2 SA and the TCP connection and iSCSI connection ID. 3.2. Initiating a New iSCSI Session In order to create a new iSCSI Session, an Initiator implementing iSCSI security first establishes IKE Phase 1 and Phase 2 SAs, then exchanges iSCSI control messages over an IPSec-secured TCP connection. The iSCSI Initiator contacts the Target on well-known TCP port <TBD>. The Initiator and Target IKE implementation MUST successfully complete the IKE phase 1 and Phase 2 negotiations before the initial TCP connection setup messages are exchanged so that these messages can be IPsec protected. From this point forward, subsequent iSCSI connections established within the iSCSI session will be protected by IKE Phase 2 SAs derived from the IKE Phase 1 SA. In the Phase 2 Quick Mode exchanges used to protected individual iSCSI connections, the Identity Payload fields MUST be present. These fields MUST carry the source and destination addresses and source and destination ports of the iSCSI Initiator and Targets, thus binding the Phase 2 security association to specific TCP and iSCSI connections. The IKE Quick Mode ID payloads MUST carry individual addresses, and MUST NOT use the IP Subnet or IP Address Range formats. Aboba, et al. Standards Track [Page 9]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 Once the IKE Phase 2 negotiations are complete and the TCP connection is established over IPsec, the iSCSI Initiator MUST send the iSCSI Login command over the TCP connection secured by the recently negotiated Quick Mode SA. The Initiator fills in the ISID field, and leaves the TSID field set to zero, to indicate that it is the first message of a new session establishment exchange. The Initiator also fills in a CID value, which is associated with the iSCSI connection corresponding to the the TCP connection secured by the Quick Mode SA. When the iSCSI Target replies with its Login Command, both iSCSI devices will know the TSID, and therefore the iSCSI session identifier <ISDI, TSID>. At this point, a binding is established between the iSCSI session identifier and the IKE Phase 1 SAs. A single iSCSI session identifier may have multiple associated IKE Phase 1 SAs, and each IKE Phase 1 SA may have multiple associated iSCSI session identifiers. In addition, a binding is established between the iSCSI connection identifier CID, the TCP connection 5-tuple, and the IPsec Phase 2 SA, as identified by the <ESP, destination address, SPI> combination. Each iSCSI connection corresponds to a single TCP connection and IPsec Phase 2 SA. Before adding a new connection to an existing iSCSI Session, a new IKE Quick Mode exchange MUST occur, under the protection of an IKE Phase 1 SA. Within IKE, each key refresh requires that a new security association be established. In practice there is a time interval during which an old, about-to-expire SA and newly established SA will both be valid. The IPsec implementation will choose which security association to use based on local policy, and iSCSI concerns play no role in this selection process. 3.3. Graceful iSCSI Teardown Mechanisms within iSCSI provide for both graceful and non-graceful teardown of iSCSI Sessions or individual TCP connections within a given session. The iSCSI Logout command is used to effect graceful teardown. This command allows the iSCSI Initiator to request that: [a] the session be closed [b] a specific connection within the session be closed [c] a specific connection be marked for recovery, or [d] a specific connection be closed at the Target's request. Aboba, et al. Standards Track [Page 10]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 When the iSCSI implementation wishes to close a session, it MUST use the appropriate iSCSI commands to accomplish this. After exchanging the appropriate iSCSI control messages for session closure, the iSCSI security implementation SHOULD initiate a half-close of each TCP connection within the iSCSI session. Since a given IKE Phase 1 SA may be bound to multiple iSCSI sessions, the iSCSI implementation will only delete the IKE Phase 1 SAs bound to the iSCSI session if there are no remaining iSCSI sessions bound to those SAs. For those Phase 1 SAs that are deleted, the iSCSI security implementation will also delete the IKE Phase 2 SAs bound to them first, before deleting the Phase 1 SA. When the iSCSI security implementation wishes to close an individual TCP connection while leaving the parent iSCSI session active, it SHOULD half-close the TCP connection. This results in a FIN being sent, putting the TCP connection into the FIN WAIT-1 state, as described in [10]. After the other side responds, the TIME WAIT state is entered. After the expiration of the TIME WAIT timeout, the IKE Phase 2 security association bound to the TCP connection MUST be closed. Closing the TCP connection prior to deleting the IKE Phase 2 SA ensures that all the TCP packets sent on the connection are IPsec-protected. 3.4. Non-graceful iSCSI Teardown If the iSCSI security implementation becomes aware that a given TCP connection has unexpectedly failed, it SHOULD delete the associated IKE Phase 2 security association. If the IKE implementation receives a Phase 2 Delete message for a security association bound to a TCP connection, it SHOULD notify the iSCSI security implementation. If the TCP connection whose SA was deleted is one which a Logout Command/Logout Response sequence marked for removal from the iSCSI session, then the IKE Phase 2 Delete message serves as confirmation that the iSCSI peer has executed an iSCSI teardown process for the connection. The iSCSI connection state and any associated filters can now be safely removed. Since IPsec acceleration hardware may only be able to handle a limited number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent for idle SAs, as a means of keeping the number of active Phase 2 SAs to a minimum. An the receipt of an IKE Phase 2 delete message SHOULD NOT be interpreted as a reason for tearing down the corresponding iSCSI connection if no Logout Command/Logout Receive has been executed on the connection. Rather, it is preferrable to leave the iSCSI connection up, and if additional traffic is sent on it, to bring up another IKE Phase 2 SA to protect it. This avoids the potential for continually bringing iSCSI connections up and down. If an IKE implementation receives a Phase 1 Delete message for a Phase 1 Security Association bound to one or more iSCSI sessions, then it SHOULD notify the iSCSI security implementation. It also SHOULD delete the Aboba, et al. Standards Track [Page 11]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 associated IKE Phase 2 security associations. 3.5. Application-layer CRC iSCSI's error detection and recovery assumes that the TCP and IP checksums provide inadequate integrity protection and hence incorporates 32 bit CRCs to protect its headers and data. When a receiver CRC check fails (i.e., CRC computed at receiver does not match the received CRC), all data covered by that CRC must be discarded. Since presumably the error was not detected by the TCP checksum, TCP retransmission will not occur and thus cannot assist in recovering from the error. iSCSI contains both data and command retry mechanisms to deal with the resulting situations, including SNACK, the ability to reissue R2T commands, and the retry (X) bit for commands. IPsec per-packet authentication and integrity protection offers strong protection against an attacker attempting to modify packets in transit, as well as unintentional packet modifications caused by router malfunctions. This protection is considerably stronger than both the 16-bit TCP checksum [11] and the 32-bit application-layer CRC that has been proposed for use with iSCSI [1]. Since IPsec integrity protection occurs below TCP, if an error is discovered, then the packet will be discarded and TCP retransmission will occur, so that no recovery action need be taken at the iSCSI layer. As a result, if end-to-end IPsec integrity protection is known to be in place, and covers the entire connection between iSCSI endpoints (or the portion thereof that requires this additional integrity connection), portions of iSCSI can be simplified. In this case, the iSCSI CRC and mechanisms to recover from CRC check failures are not necessary. If the iSCSI CRC is negotiated, the recovery logic SHOULD simplified to regard any CRC check failure as fatal (e.g., generate a SCSI CHECK CONDITION on data error, close the corresponding TCP connection on header error) because it will be rare for errors undetected by IPsec integrity protection to be detected by the iSCSI CRC. Note that omitting the iSCSI CRC is not advisable in all situations where IPsec integrity protection is employed. When IPsec, TCP and iSCSI are implemented purely in software, it can be argued that additional failure modes may be detected by the TCP checksum and/or iSCSI CRC, and therefore that these additional checks are worthwhile. For example, verification of the cryptographic message integrity check might be successful, but then after the segment is copied as part of TCP processing, a memory error might cause TCP checksum or iSCSI CRC verification to fail. Given the demand for high speed iSCSI security implementations, implementations utilizing hardware offload are expected to become Aboba, et al. Standards Track [Page 12]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 common. Where IPsec processing as well as TCP checksum and iSCSI CRC verification are offloaded within the NIC, these individual checks no longer provide diversity against single points of failure. Since both the IPsec cryptographic message integrity check, the TCP checksum and the application layer CRC will have been verified prior to transferring data across the bus, subsequent transfer or memory errors will not be detected. As a result, where iSCSI security is supported, and IPsec processing is offloaded to the NIC, the iSCSI CRC is not necessary and the implementation may not request it. There are two exceptions to this: [1] If an implementation is an iSCSI-iSCSI proxy or gateway, it can propagate the iSCSI data CRC from one iSCSI connection to another. In this case, the iSCSI CRC is useful to protect iSCSI data against memory, bus, or software errors within the proxy or gateway, and requesting it is desirable. [2] If IPsec is provided by a device external to the actual iSCSI device, the iSCSI header and data CRCs can be kept across the part of the connection that is not protected by IPsec. For instance, the iSCSI connection could traverse an extra bus, interface card, network, interface card, and bus between the iSCSI device and the device providing IPsec. In this case, the iSCSI CRC is desirable, and the iSCSI implementation behind the IPsec device may request it. Note that if both ends of the connection are on the same segment, then traffic will be effectively protected by the layer 2 CRC, so that negotiation of the iSCSI CRC is not necessary. 4. iFCP Security iFCP is a protocol designed for use by gateway devices deployed in enterprise data centers. Such environments typically have security gateways designed to provide network security through isolation from public networks. Furthermore, iFCP data may need to traverse security gateways in order to support SAN-to-SAN connectivity across public networks. 4.1. iFCP security requirements The iFCP protocol is used to transmit FCP messages containing encapsulated SCSI commands and data over IP networks. Both iFCP data and iFCP gateways, as well as iSNS servers are vulnerable to attack. Examples of such attacks include: Aboba, et al. Standards Track [Page 13]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 [1] An adversary may attempt to acquire confidential data and identities by snooping data packets. [2] An adversary may attempt to modify packets containing data and control messages. [3] An adversary may attempt to inject new packets into the iFCP session. [4] An adversary may attempt to hijack the TCP connection carrying the iFCP session. [5] An adversary may launch denial of service attacks against the iFCP gateway or iSNS server. [6] An adversary may attempt to disrupt security negotiation process. [7] An adversary may attempt to impersonate a legitimate security gateway or iSNS server. To address the above threats, the iFCP security protocol MUST provide confidentiality, authentication, integrity, and replay protection on a per-datagram basis. It also MUST provide a scalable approach to key management. 4.1.1. Performance Issues iFCP security MUST be implementable at 1Gbps throughput, and SHOULD be implementable at 10Gbps throughput. These performance levels apply to aggregate gateway-to-gateway throughput, and include all TCP connections used to support N_PORT sessions between each pair of iFCP gateways. Note that iFCP gateway-to-gateway communications typically involve multiple TCP connections. Since each IPsec security association only protects a single TCP connection, it does not necessarily need to support the entire aggregate gateway-to-gateway throughput. Through use of multiple processing engines that independently support individual security associations, implementations may be able to scale to 10Gbps throughput for aggregate gateway-to-gateway traffic. 4.1.2. Interoperation with Security Gateways Enterprise data center networks are considered mission-critical facilities that must be isolated and protected from all possible security threats. Such networks are usually protected by security gateways, which at a minimum provide a shield against denial of service attacks. The iFCP security architecture should be able to leverage the protective services of the existing security infrastructure, including Aboba, et al. Standards Track [Page 14]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 firewall protection, NAT and NAPT services, and VPN services available on existing security gateways. 4.1.3. DHCP and static address assignment As iFCP gateways and switches are deployed within enterprise networks, IP addresses will be statically assigned in the same manner as most routers and switches. Consequently, IKE and IPsec features focused on supporting DHCP and other dynamic IP address assignment capabilities for mobile hosts are not required. 4.1.4. iFCP Authentication Requirements iFCP is a peer-to-peer protocol. iFCP sessions may be initiated by either or both peer gateways. Consequently, bi-directional authentication of peer gateways MUST be provided. iFCP is a transport protocol that encapsulates SCSI and Fibre Channel (FCP) messages. Therefore, Fibre Channel, operating system, and user identities are transparent to the iFCP protocol. IKE and IPSec authentication used to protect iFCP traffic shall be based upon the IP addresses of the communicating peer gateways. iFCP gateways shall use Discovery Domain information obtained from the iSNS server to determine whether the initiating Fibre Channel N_PORT should be allowed access to the target N_PORT. N_PORT identities used in the Port Login (PLOGI) process shall be considered authenticated provided that it is received from the remote gateway over a secure, IPsec-protected connection. There is no requirement that the identities used in authentication be kept confidential. 4.1.5. iFCP Confidentiality Requirements iFCP traffic may traverse insecure public networks, and therefore implementations MUST include per-packet encryption capabilities to provide confidentiality. 4.1.6. Rekeying Requirements Due to the high data transfer rates and the amount of data involved, iFCP MUST support the capability to rekey each phase 2 SA in time intervals as often as every 25 seconds. The iFCP security protocol MUST provide the capability for perfect forward secrecy in the rekeying process. Aboba, et al. Standards Track [Page 15]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 4.2. iFCP security design requirements The following sections describe security design requirements for iFCP. 4.2.1. Resource Constraints iFCP gateways and switches will typically be embedded systems deployed on racks in air-conditioned data center facilities. Such embedded systems may include hardware chipsets to provide data encryption, authentication, and integrity processing. Furthermore, memory and CPU resources are generally not a constraining factor. 4.2.2. iFCP Interaction with IPsec and IKE An iFCP gateway may have more than one interface and IP address, and multiple TCP connections to other iFCP gateways may exist at each interface and IP address. Each IP address in turn will support a single phase 1 IKE SA to each remote iFCP gateway's IP address. An active iFCP session is supported by one and only one TCP connection. This iFCP session is identified by the 2-tuple of the two communicating N_PORT ID's (3 byte Fibre Channel Port Identifier). A TCP connection is bound to an iFCP session using the CBIND message. Before a new TCP connection to a remote iFCP gateway is established, IKE shall negotiate a phase 2 security association using Quick Mode to protect that new connection. Once the phase 2 security association is established, it shall protect the TCP setup process and all subsequent TCP traffic, regardless of whether the connection has been bound to an iFCP session. When a TCP connection is closed by one of the iFCP gateways supporting the connection, the corresponding phase 2 security association MUST also be terminated. This shall only occur after expiration of the TIME WAIT timeout period for the TCP connection. If the iFCP gateway becomes aware that a TCP connection has failed, then it SHOULD delete the associated phase 2 security association. iSNS [52] is an invariant in all iFCP deployments. iFCP gateways use iSNS for discovery services, and MAY use security policies configured in the iSNS as the basis for algorithm negotiation in IKE. Aboba, et al. Standards Track [Page 16]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 5. Security considerations 5.1. Transport mode versus tunnel mode This document proposes that iSCSI security utilize transport mode ESP, and that iFCP utilize tunnel mode ESP. With respect to storage protocols, the major differences between the two modes are as follows: [1] MTU considerations. Tunnel mode introduces extra overhead that reflects itself in a corresponding decrease in the MTU. [2] Dynamic address assignment. Where tunnel mode is used in situations where IP addresses are dynamically assigned (such as with hosts implementing iSCSI), support for address assignment within IPsec tunnel mode is required. The use of DHCP within IPsec tunnel mode has been proposed for this, as described in [55]. However, this mechanism is not yet widely deployed within IPsec security gateways. [3] NAT traversal. As noted in [20], IPsec tunnel mode ESP can traverse NAT in limited circumstances, whereas transport mode ESP cannot traverse NAT. To enable NAT traversal in the general case, the IPsec NAT traversal functionality described in [21]-[23] can be implemented. [4] Connection-specific selectors. For both transport and tunnel mode, it is possible to negotiate connection-specific selectors, so that only a single iSCSI/iFCP connection will be protected by an IKE Phase 2 SA. However, while negotiation of connection-specific selectors is common within IPsec transport mode implementations, it is more common for IPsec security gateway implementations to negotiate "ANY to ANY" selectors by default. [5] Firewall traversal. Where a storage protocol is to traverse administrative domains, the firewall administrator may desire to verify the integrity and authenticity of each transiting packet, rather than opening a hole in the firewall for the storage protocol. IPsec tunnel mode lends itself to such verification, since the firewall can terminate the tunnel mode connection while still allowing the endpoints to communicate end-to-end. If desired, the endpoints can in addition utilize IPsec transport mode for end- to-end security, so that they can also verify authenticity and integrity of each packet for themselves. In contrast, carrying out this verification with IPsec transport mode is more complex, since the firewall will need to terminate the IPsec transport mode connection and will need to act as an iSCSI/iFCP gateway or TCP proxy, originating a new IPsec transport Aboba, et al. Standards Track [Page 17]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 mode connection from the firewall to the internal endpoint. Such an implementation cannot provide end-to-end authenticity or integrity protection, and therefore negotiation of an application-layer CRC would be desirable. [6] IPsec-application integration. Where IPsec and the application layer protocol are implemented on the same device or host, it is possible to enable tight integration between them. For example, the application layer protocol can request and verify that connections are protected by IPsec, and can be informed when IKE Phase 1 and Phase 2 delete messages are received. While in transport mode implementations the IPsec and application protocol implementations typically reside on the same host, with IPsec tunnel mode, they may reside on different hosts. Where IPsec is implemented on an external gateway, integration between the application protocol and IPsec is typically not possible. 5.2. IKE issues There are situations where it is necessary for IKE to be implemented in firmware. In such situations, it is important to keep the size of the IKE implementation within strict limits. An upper bound on the size of an IKE implementation might be considered to be 800 KB, with 80 KB enabling implementation in a wide range of situations. As noted in Table 1 on the next page, IKE implementations currently exist which meet the requirements. Therefore, while removal of seldomly used IKE functionality (such as the nonce authentication methods) would reduce complexity, implementations typically will not require this in order to fit within the code size budget. 5.3. Rekeying issues It is expected that iSCSI and iFCP implementations will need to operate at high speed. For example, implementations operating at 1 Gbps are currently in design, with 10 Gbps implementations to follow shortly thereafter. At these speeds, a single IPsec SA could rapidly cycle through the 32-bit IPsec sequence number space. For example, a single SA operating at 1 Gbps line rate and sending 64 octet packets would exhaust the 32-bit sequence number space in 2200 seconds, or 37 minutes. With 1518 octet packets, exhaustion would occur in 14.5 hours. At 10 Gbs, exhaustion would occur in 220 seconds or 3.67 minutes. With 1518 octet packets, this would occur within 1.45 hours. Aboba, et al. Standards Track [Page 18]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Code size | | |Implementation | (octets) | Release | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Linux | | Pluto | 258KB | FreeSWAN | |(FreeSWAN) | | x86 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Racoon | 400KB | NetBSD 1.5 | | (KAME) | | x86 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Isakmpd | 283KB | NetBSD 1.5 | | (Erickson) | | x86 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | WindRiver | 142KB | PowerPC | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Cisco | 222KB | PowerPC | | VPN1700 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Cisco | 350K | PowerPC | | VPN3000 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Cisco | 228KB | MIPS | | VPN7200 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Table 1 - Code Size for IKE implementations Aboba, et al. Standards Track [Page 19]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 As a result, iSCSI or iFCP implementations operating at speeds of 1 Gbps or less MAY implement the IPsec sequence number extension, described in [49]. 10 Gbps or faster implementations SHOULD implement the extension specification. Note that depending on the transform in use, it is possible that rekeying will be required prior to exhaustion of the sequence number space. Bellare et. al. have formalized this in [51], showing that the insecurity of CBC mode increases as O(s^2/2^n), where n is the block size in bits, and s is the total number of blocks encrypted. These conclusions do not apply to counter mode. This formula sets a limit on the bytes that can be sent on a CBC SA before a rekey is required: B = s * n/8 = (n/8) * 2^(n/2) Where: B = maximum bytes sent on the SA n = block size in bits This means that cipher block size as well as key length need to be considered in the rekey decision. 3DES uses a block size n = 64 bits (2^3 bytes); this implies that the SA must be rekeyed before B = (64/8) * (2^32) = 2^35 bytes are sent. At 1 Gbps, this implies that a rekey will be required every 274.9 seconds (4.6 minutes); at 10 Gbps, a rekey is required every 27.5 seconds. In practice, a safety margin is required so the required rekey times will be even smaller. In terms of the sequence number space, for a 3DES encrypted message of 512 = 2^9 bytes (2^6 blocks) this implies that the key has become insecure after about 2^26 messages. This is s = 2^26 * 2^6 = 2^32 blocks and (2^32)^2/2^64 = 1. With the 3DES cipher in CBC mode, it would be prudent to rekey more often, such as every 2^20 messages or 2^29 bytes. This would imply a rekey time of 4.29 seconds at 1 Gbps or 0.43 seconds at 10 Gbps. In comparision, AES-CBC uses a block size of 128 bits (2^4 bytes). This enables B = (128/8) * (2^64) = 2^68 bytes to be sent prior to requiring a rekey. This means that the required rekey times are 2^33 times longer than for 3DES. In terms of the sequence number space, for an AES encrypted message of 512 = 2^9 bytes (2^5 blocks) this implies that the key has become insecure after about 2^59 messages (2^59 * 2^5)^2/2^128 = 1. This means that the entire current ESP sequence space of 2^32 messages could be consumed without compromising the key. AES would still permit a safe CBC mode construction if the ESP sequence space were expanded to 48 bits, Aboba, et al. Standards Track [Page 20]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 since (2^48 * 2^5)^2/2^128 = 2^-22. 5.4. Transform issues Since iSCSI and iFCP implementations may operate at speeds of 1 Gbps or greater, the ability to offer IPsec security services at high speeds is of intense concern. Since support for multiple algorithms multiplies the complexity and expense of hardware design, one of the goals of the transform selection effort is to find a minimal set of confidentiality and authentication algorithms implementable in hardware at speeds of up to 10 Gbps, as well as being efficient for implementation in software at speeds of 100 Mbps. In this specification, we primarily concern ourselves with IPsec transforms that have already been specified, and for which parts are available that can run at 1 Gbps line rate. Where existing algorithms do not gracefully scale to 10 Gbps, we further consider algorithms for which transform specifications are not yet complete, but for which parts are expected to be available for inclusion in products shipping within the next 12 months. As the state of the art advances, the range of feasible algorithms will broaden and additional mandatory-to-implement algorithms may be considered. Section 5 of RFC 2406 [4] states: "A compliant ESP implementation MUST support the following mandatory-to-implement algorithms: - DES in CBC mode - HMAC with MD5 - HMAC with SHA-1 - NULL Authentication algorithm - NULL Encryption algorithm " The DES algorithm is specified in [29]; implementation guidelines are found in [30], and security issues are discussed in [31],[43], [17]. The DES IPsec transform is defined in [32] and the 3DES in CBC mode IPsec transform is specified in [33]. The MD5 algorithm is specified in [8]; HMAC is defined in [19] and security issues with MD5 are discussed in [19]. The HMAC-MD5 IPsec transform is specified in [24]. The HMAC-SHA1 IPsec transform is specified in [25]. Aboba, et al. Standards Track [Page 21]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 In addition to these existing algorithms, NIST is currently evaluating the following modes [37] of AES, defined in [34],[35]: AES in Electronic Codebook (ECB) confidentiality mode AES in Cipher Block Chaining (CBC) confidentiality mode AES in Cipher Feedback (CFB) confidentiality mode AES in Output Feedback (OFB) confidentiality mode AES in Counter (CTR) confidentiality mode AES CBC-MAC authentication mode The Modes [36] effort is also considering a number of additional algorithms, including the following: PMAC To provide authentication, integrity and replay protection, iSCSI and iFCP security implementations MUST support HMAC-SHA1 for authentication, and AES in CBC MAC mode with XCBC extensions SHOULD be supported. HMAC-SHA1 [25] is to be preferred to HMAC-MD5, due to concerns that have been raised about the security of MD5 [9]. HMAC-SHA1 parts are currently available that run at 1 Gbps, the algorithm is implementable in hardware at speeds up to 10 Gbps, and an IPsec transform specification [25] exists. As a result, it is most practical to utilize HMAC-SHA1 as the authentication algorithm for products shipping in the near future. The HMAC-SHA2 algorithm [28] is also under development, including an IPsec transform [45], so that this may merit consideration in the future. AES in CBC-MAC authentication mode with XCBC extensions was selected since it avoids adding substantial additional code if AES is already being implemented for encryption; an IPsec transform document [38] is available. Authentication transforms also exist that are considerably more efficient to implement than HMAC-SHA1, HMAC-SHA2 or AES in CBC-MAC authentication mode. UMAC [27],[44] is more efficient to implement in software and PMAC [26] is more efficient to implement in hardware. PMAC is currently being evaluated as part of the NIST modes effort [36] but an IPsec transform does not yet exist; neither does a UMAC transform. For confidentiality, the ESP mandatory-to-implement algorithm (DES) is unacceptable. As noted in [17], DES is crackable with modest computation resources, and so is inappropriate for use in situations requiring high levels of security. To provide confidentiality, 3DES in CBC mode [33] MUST be supported and AES in Counter Mode [39] SHOULD be supported. Note that for use in high speed implementations, 3DES has significant disadvantages. However, a 3DES IPsec transform has been specified and parts are available that can Aboba, et al. Standards Track [Page 22]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 run at 1 Gbps, so that it is practical to implement 3DES in products for the short term. As described in Appendix A, 3DES software implementations make excessive computational demands at speeds of 100 Mbps or greater, effectively ruling out software-only implementations at speeds of 100 Mbps or faster. In addition, 3DES implementations require rekeying prior to exhaustion of the current 32-bit IPsec sequence number space, and thus would not be able to make use of sequence space extensions, if they were available. This means that 3DES will require very frequent rekeying at speeds of 10 Gbps or faster. Thus, 3DES is inconvenient for use at high speeds, as well as being impractical for implementation in software at slower speeds (100 Mbps). 5.5. IKE and application-layer authentication IPsec IKE negotiation MUST negotiate an authentication method specified in the IKE RFC 2409 [7]. In addition to IKE authentication, iSCSI implementations utilize their own authentication methods, such as those described in [48]. Currently, work is underway on Fibre Channel security, so that a similar authentication process may eventually also apply to iFCP as well. While iSCSI provides initial authentication, it does not provide per- packet authentication, integrity or replay protection. This implies that the identity verified in the iSCSI logon is not subsequently verified on reception of each packet. With IPsec, when the identity asserted in IKE is authenticated, the resulting derived keys are used to provide per-packet authentication, integrity and replay protection. As a result, the identity verified in the IKE conversation is subsequently verified on reception of each packet. Let us assume that the identity claimed in iSCSI logon is a user identity, while the identity claimed within IKE is a machine identity. Since only the machine identity is verified on a per-packet basis, there is no way for the recipient to verify that only the user authenticated via iSCSI logon is using the IPsec SA. In fact, IPsec implementations that only support machine authentication typically have no way to distinguish between user traffic within the kernel. As a result, where machine authentication is used, once an iSCSI/IPsec SA is opened, another user on a multi-user machine may be able to send traffic down the IPsec SA. To limit the potential vulnerability, iSCSI and iFCP security implementations MUST negotiate a separate IPsec Phase 2 SA for each Aboba, et al. Standards Track [Page 23]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 connection, with descriptors specific to that connection. This will prevent traffic for other connections from traveling within the IPsec SA negotiated for another connection. As a result, if access to the TCP socket used for the connection is exclusive, then access to the corresponding IPsec SA will also be exclusive, even if the IPsec implementation only supports machine authentication. If the IPsec implementation supports user authentication, the user identity asserted within IKE will be verified on a per-packet basis, and stronger assurances can be provided. In this case, the user identity asserted within IKE will be verified on a per-packet basis. In order to provide segregation of traffic between users when user authentication is used, the sender MUST ensure that only traffic from that particular user is sent down the SA. Enforcement of this restriction is the responsibility of the operating system. In kernel mode iSCSI or iFCP drivers there typically is no user context to perform user authentication. In this case the authentication is closer to machine authentication. In most operating systems device permissions would control the ability to read/write to the device prior to mounting. Once the device is mounted, ACLs set by the filesystem control access to the device. An administrator can access the blocks on the device directly (for instance, by sending pass through requests to the port driver directly such as in Windows NT). In the same way, an administrator can open raw socket and send IPsec protected packets to an iSCSI target or iFCP gateway. The situation is analagous, and in this respect no new vulnerablilty is created that didn't previously exist. The Operating system's ACLs need to be effective to protect a device (whether it is a SCSI device or an iSCSI device). 5.6. Fragmentation Issues When certificate authentication is used, and the certificate chains are long enough, then IKE fragmentation can occur. Routers in the path will frequently discard fragments after the initial one, since they typically will not contain full IP headers that can be compared against an Access List. As a result, the endpoints will be unable to establish an IPsec security association. The solution to this problem is to reduce the size of the certificate chain, or to install router code loads that can support fragment filtering. Fragmentation can become a concern when prepending IPsec headers to a frame. One mechanism which can be used to reduce this problem is to utilize path MTU discovery. For example, when TCP is used as the transport for iSCSI or iFCP, then path MTU discovery [11]-[13], can be used to enable the TCP endpoints to discover the correct MTU, including effects due to IPsec encapsulation. Aboba, et al. Standards Track [Page 24]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 However, Path MTU discovery fails when appropriate ICMP messages are not received by the host. This occurs in IPsec implementations which drop unauthenticated ICMP packets. This can result in blackholing in naive TCP implementations, as described in [14]. Appropriate TCP behavior is described in section 2.1 of [14]: "TCP should notice that the connection is timing out. After several timeouts, TCP should attempt to send smaller packets, perhaps turning off the DF flag for each packet. If this succeeds, it should continue to turn off PMTUD for the connection for some reasonable period of time, after which it should probe again to try to determine if the path has changed." If an ICMP PMTU is received by an IPsec implementation that processes unauthenticated ICMP packets, this value SHOULD be stored in the SA as proposed in [6], and IPsec should also provide notification of this event to TCP so that the new MTU value can be correctly reflected. 5.7. Security Checks When a connection is opened which requires security, iSCSI/iFCP MUST check to ensure that the connection is protected by IPsec. If IPsec protection is removed on a connection, iSCSI/iFCP MUST be notified, so that it can be reinstated. Since IPsec verifies that each packet arrives on the correct SA, as long as it can be ensured that IPsec protection is in place, then iSCSI/iFCP can be assured that each received packet was sent by a trusted peer. When used with iSCSI, IPsec will negotiate a separate Phase 2 SA for each TCP connection, with selectors specific to the TCP connection. As a result, only traffic for a single TCP connection will flow within each IPsec Phase 2 SA. iSCSI security implementations need not verify that the IP addresses and TCP port values in the packet match the socket information which was used to setup the iSCSI connection. This check will be performed by IPsec, preventing malicious peers from sending iSCSI commands on inappropriate Quick Mode SAs. 5.8. NAT traversal iSCSI security utilizes transport mode ESP, and iFCP security utilizes tunnel mode ESP. As noted in [20], tunnel mode ESP can traverse NAT in a limited set of circumstances. For example, if there is only one protocol endpoint behind a NAT, "ANY to ANY" selectors are negotiated, and the receiver does not perform source address validation, then tunnel mode ESP may successfully traverse NATs. Since ignoring source address validation introduces new security vulnerabilities, and negotiation of specific selectors is desirable so as to limit the traffic that can be sent down the tunnel, these conditions may not necessarily apply, and Aboba, et al. Standards Track [Page 25]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 tunnel mode NAT traversal will not always be possible. Transport mode ESP cannot traverse NAT, even though ESP itself does not include IP header fields within its message integrity check. This is because the 16-bit TCP checksum is calculated based on a "pseudo-header" that includes IP header fields, and the checksum is protected by the IPsec message integrity check. As a result, the TCP checksum will be invalidated by a NAT located between the two endpoints. Since TCP checksum calculation and verification is mandatory in both IPv4 and IPv6, it is not possible to omit checksum verification while remaining standards compliant. In order to enable traversal of NATs existing while remaining in compliance, iSCSI and iFCP security implementations MAY implement IPsec/IKE NAT traversal, as described in [20]-[23]. The IPsec/IKE NAT traversal specification [23] enables UDP encapsulation of IPsec to be negotiated if a NAT is detected in the path. By determining the IP address of the NAT, the TCP checksum can be calculated based on a pseudo-header including the NAT-adjusted address and ports. If this is done prior to calculating the IPsec message integrity check, TCP checksum verification will not fail. 5.9. Certificate authentication When X.509 certificate authentication is chosen within IKE, the iSCSI Target or iFCP gateway is expected to use an IKE Certificate Request Payload (CRP) to request from the Initiator a certificate issued by a particular certificate authority or may use several CRPs if several certificate authorities are trusted and configured in its IPsec IKE authentication policy. The iSCSI Target or iFCP gateway SHOULD be able to trust several certificate authorities in order to allow iSCSI Initiators or other iFCP gateways to connect to it using their own certificate credential from their chosen PKI. Client and server side certificate revocation list checking MAY be enabled on a per-CA basis, since differences in revocation list checking exist between different PKI providers. [Issue: more words of wisdom on certificate authentication go here. William Dixon to provide the text.] 5.10. Machine versus user certificates The certificate credentials provided by the iSCSI Initiator during the IKE negotiation MAY be those of the machine or of the iSCSI user. When machine authentication is used, the machine certificate is typically stored on the iSCSI Initiator and Target during an enrollment process. Aboba, et al. Standards Track [Page 26]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 When user certificates are used, the user certificate can be stored either on the machine or on a smartcard. For iFCP, the certificate credentials provided will almost always be those of the machine, and will be stored on the machine. Since the value of a machine certificate is inversely proportional to the ease with which an attacker can obtain one under false pretenses, it is advisable that the machine certificate enrollment process be strictly controlled. For example, only administrators may have the ability to enroll a machine with a machine certificate. While smartcard certificate storage lessens the probability of compromise of the private key, smartcards are not necessarily desirable in all situations. For example, some organizations deploying machine certificates use them so as to restrict use of non-approved hardware. Since user authentication can be provided within iSCSI logon (keeping in mind the weaknesses described earlier), support for machine authentication in IPsec makes it is possible to authenticate both the machine as well as the user. Since iFCP has no equivalent of iSCSI logon, this is not possible with iFCP, and only the machine is authenticated. In circumstances in which this dual assurance is considered valuable, enabling movement of the machine certificate from one machine to another, as would be possible if the machine certificate were stored on a smart card, may be undesirable. Similarly, when user certificate are deployed, it is advisable for the user enrollment process to be strictly controlled. If for example, a user password can be readily used to obtain a certificate (either a temporary or a longer term one), then that certificate has no more security value than the password. To limit the ability of an attacker to obtain a user certificate from a stolen password, the enrollment period can be limited, after which password access will be turned off. Such a policy will prevent an attacker obtaining the password of an unused account from obtaining a user certificate once the enrollment period has expired. 5.11. Pre-shared keys Use of pre-shared keys in IKE main mode is vulnerable to man-in-the- middle attacks when used with dynamically addressed Initiators. In main mode it is necessary for SKEYID_e to be used prior to the receipt of the identification payload. Therefore the selection of the pre-shared key may only be based on information contained in the IP header. However, where dynamic IP address assignment is typical, it is often not possible to identify the required pre-shared key based on the IP address. Aboba, et al. Standards Track [Page 27]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 Thus when main mode pre-shared keys are used with iSCSI Targets whose address is dynamically assigned (such as desktop workstations), the same pre-shared key is shared by a group of Initiators and is no longer able to function as an effective shared secret. In this situation, neither the client nor the server identifies itself during IKE phase 1; it is only known that both parties are a member of the group with knowledge of the pre-shared key. This permits anyone with access to the group pre- shared key to act as a man-in-the-middle. This vulnerability is typically not of concern with iFCP, since devices typically use statically defined addresses, so that individual pre-shared keys are possible within IKEM MM. This vulnerability also does not occur in aggressive mode since the identity payload is sent earlier in the exchange, and therefore the pre- shared key can be selected based on the identity. However, when aggressive mode is used the user identity is exposed and this is often considered undesirable. As a result, where main mode is used with pre-shared keys, unless iSCSI logon performs mutual authentication, the Target is not authenticated. This enables a rogue Target in possession of the group pre-shared key to successfully masquerade as the actual Target and mount a dictionary attack on legacy authentication methods such as CHAP [47]. Such an attack could potentially compromise many passwords at a time. This vulnerability is widely present in existing IPsec implementations. To avoid this problem, iSCSI security implementations SHOULD NOT use a pre-shared key for IKE authentication with main mode. If pre-shared keys are required, then aggressive mode SHOULD be used. IKE pre-shared authentication key values SHOULD be protected in a manner similar to the user's account password used in iSCSI logon. iFCP security implementations desiring use of pre-shared keys SHOULD use IKE main mode, since iFCP addresses are typically not dynamically assigned. 5.12. Use of AES in counter mode When AES in counter mode is used, it is important to avoid reuse of the counter with the same key, even across all time. Counter mode creates ciphertext by XORing generated key stream with plaintext. It is fairly easy to recover the plaintext from two messages counter mode encrypted under the same counter value, simply by XORing together the two packets. The implication of this is that it is almost always an error to use statically configured keys with counter mode, except when the implementation takes heroic measures to maintain state across sessions. Aboba, et al. Standards Track [Page 28]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 Another counter mode issue is it makes forgy of correct packets trivial. Counter mode should therefore never be used without also using data authentication. 6. References [1] Satran, J., et al., "iSCSI", Internet draft (work in progress), draft-ietf-ips-iSCSI-06.txt, April 2001. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Kent,S., Atkinson, R., "IP Authentication Header", RFC 2402, November 1998. [4] Kent,S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [5] Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998. [6] Atkinson, R., Kent, S., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [7] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [9] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996. [10] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [11] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. [12] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993. [13] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [14] Lahey, K., TCP Problems with Path MTU Discovery", RFC 2923, September 2000. Aboba, et al. Standards Track [Page 29]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 [15] Paxon, V., "End-to-end internet packet dynamics", IEEE Transactions on Networking 7,3 (June 1999) pg 277-292. [16] Stone J., Partridge, C., "When the CRC and TCP checksum disagree", ACM Sigcomm, Sept. 2000. [17] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000. [18] Krueger, M., et.al., "iSCSI Requirements and Design Considerations", draft-ietf-ips-iscsi-reqmts-05.txt, Work in Progress, July 2001. [19] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [20] Aboba, B., "IPsec-NAT Compatibility Requirements", draft-ietf- ipsec-nat-reqts-00.txt, Work in Progress, June 2001. [21] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets", draft- ietf-ipsec-udp-encaps-00.txt, June 2001 [22] Dixon, W. et. al., "IPsec over NAT Justification for UDP Encapsulation", draft-ietf-ipsec-udp-encaps-justification-00.txt, June 2001 [23] Kivinen, T., et al., "Negotiation of NAT-Traversal in the IKE", Internet draft (work in progress), draft-ietf-ipsec-nat-t- ike-00.txt, June 2001. [24] Madson, C., Glenn, R., "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998. [25] Madson, C., Glenn, R., "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [26] Rogaway, P., Black, J., "PMAC: Proposal to NIST for a parallelizable message authentication code", http://csrc.nist.gov/encryption/modes/proposedmodes/pmac/pmac- spec.pdf [27] Black, J., Halevi, S., Krawczyk, H., Krovetz, T., Rogaway, P., "UMAC: Fast and provably secure message authentication", Advances in Cryptology - CRYPTO '99, LNCS vol. 1666, pp. 216-233. Full version available from http://www.cs.ucdavis.edu/~rogaway/umac [28] "Descriptions of SHA-256, SHA-384, and SHA-512," http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf. Aboba, et al. Standards Track [Page 30]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 [29] U.S. DoC/NIST, "Data encryption standard (DES)", FIPS 46-3, October 25, 1999. [30] U.S. DoC/NIST, "Guidelines for implementing and using the nbs data encryption standard", FIPS 74, Apr 1981. [31] Biham, E., Shamir, A., "Differential Cryptanalysis of DES- like cryptosystems", Journal of Cryptology Vol 4, Jan 1991. [32] Madson, C., Doraswamy, N., "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998. [33] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998. [34] Daemen, J., Rijman, V., "AES Proposal: Rijndael," NIST AES Proposal, June 1998. http://csrc.nist.gov/encryption/aes/round2/ AESAlgs/Rijndael/Rijndael.pdf [35] Draft FIPS Publication ZZZZ, "Advanced Encryption Standard (AES)", U.S. DoC/NIST, summer 2001. [36] "Symmetric Key Block Cipher Modes of Operation," http://www.nist.gov/modes. [37] "Recommendation for Block Cipher Modes of Operation", National Institute of Standards and Technology (NIST) Special Publication 800-XX, CODEN: NSPUE2, U.S. Government Printing Office, Washington, DC, July 2001. [38] Frankel, S., Kelly, S., Glenn, R., "The AES Cipher Algorithm and Its Use with IPsec", Internet draft (work in progress), draft-ietf- ipsec-ciph-aes-cbc-01.txt, May 2001. [39] Etienne, J., "The counter-mode and its use with ESP", Internet draft (work in progress), draft-etienne-ipsec-esp-ctr-mode-00.txt, May 2001. [40] Lipmaa, H., Rogaway, P., Wagner, D., "CTR-MODE encryption", Comment on mode of operations NIST, Jan 2001. [41] Schneier, B., J. Kelsey, D. Whiting, D. Wagner, C. Hall, and N. Ferguson, "Performance Comparison of the AES Submissions", http://www.counterpane.com/AES-performance.html [42] A. Bosselaers, "Performance of Pentium implementations", http://www.esat.kuleuven.ac.be/~bosselae/ Aboba, et al. Standards Track [Page 31]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 [43] Bellovin, S., "An Issue With DES-CBC When Used Without Strong Integrity", Proceedings of the 32nd IETF, Danvers, MA, April 1995. [44] Krovetz, T., Black, J., Halevi, S., Hevia, A., Krawczyk, H., Rogaway, P., "UMAC: Message Authentication Code using Universal Hashing", Internet draft (work in progress), draft-krovetz- umac-01.txt, October 2000. [45] Frankel, S., Kelly, S., "The Use of SHA-256, SHA-384, and SHA-512 within ESP, AH and IKE," Work in progress. [46] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, November 1998. [47] Simpson, W.,"PPP Challenge Handshake Authentication Protocol (CHAP)," RFC 1994, August 1996. [48] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000. [49] Steve Kent, IPsec sequence number extension proposal, IETF 50. [50] American National Standard for Financial Services X9.52-1998, "Triple Data Encryption Algorithm Modes of Operation", American Bankers Association, Washington, D.C., July 29, 1998. [51] Bellare, Desai, Jokippi, Rogaway, "A Concrete Treatment of Symmetric Encryption: Analysis of the DES Modes of Operation", 1997, http://www-cse.ucsd.edu/users/mihir/ [52] Bakke, M., et.al., "iSCSI Naming and Discovery", draft-ietf-ips- iscsi-name-disc-02.txt, Work in Progress, August 2001. [53] Krueger, M., et.al., "iSCSI Requirements and Design Considerations", draft-ietf-ips-iscsi-reqmts-05.txt, Work in Progress, July 2001. [54] Maughan, D., Schertler, M., Schneider, M., Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP), RFC 2408, November 1998. [55] Patel, B., Aboba, B., Kelly, S., Gupta, V., "DHCPv4 Configuration of IPsec Tunnel Mode", Internet draft (work in progress), draft- ietf-ipsec-dhcp-13.txt, June 2001. Aboba, et al. Standards Track [Page 32]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 Appendix A - Software Performance of IPsec Transforms This Appendix provides data on the performance of IPsec encryption and authentication transforms in software. Since the performance of IPsec transforms is heavily implementation dependent, the data presented here may not be representative of performance in a given situation, and are presented solely for purposes of comparision. A.1 Authentication transforms Table A-1 presents the cycles/byte required by the AES-PMAC, AES-CBC- MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 algorithms at various packet sizes, implemented in software. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | Data | AES- | AES-CBC- | AES- | HMAC- | HMAC- | | Size | PMAC | MAC | UMAC | MD5 | SHA1 | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 64 | 31.22 | 26.02 | 19.51 | 93.66 | 109.27 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128 | 33.82 | 28.62 | 11.06 | 57.43 | 65.04 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192 | 34.69 | 26.02 | 8.67 | 45.09 | 48.56 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 256 | 33.82 | 27.32 | 7.15 | 41.63 | 41.63 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 320 | 33.3 | 27.06 | 6.24 | 36.42 | 37.46 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 384 | 33.82 | 26.88 | 5.42 | 34.69 | 34.69 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 448 | 33.45 | 26.76 | 5.39 | 32.71 | 31.96 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 512 | 33.82 | 26.67 | 4.88 | 31.22 | 30.57 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 576 | 33.53 | 26.59 | 4.77 | 30.64 | 29.48 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 640 | 33.3 | 26.54 | 4.42 | 29.66 | 28.62 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Aboba, et al. Standards Track [Page 33]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | Data | AES- | AES-CBC- | AES- | HMAC- | HMAC- | | Size | PMAC | MAC | UMAC | MD5 | SHA1 | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 768 | 33.82 | 26.88 | 4.23 | 28.18 | 27.32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 896 | 33.45 | 27.13 | 3.9 | 27.5 | 25.64 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1024 | 33.5 | 26.67 | 3.82 | 26.99 | 24.71 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1152 | 33.53 | 27.17 | 3.69 | 26.3 | 23.99 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1280 | 33.56 | 26.8 | 3.58 | 26.28 | 23.67 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1408 | 33.58 | 26.96 | 3.55 | 25.54 | 23.41 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1500 | 33.52 | 26.86 | 3.5 | 25.09 | 22.87 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Table A-1: Cycles/byte consumed by the AES-PMAC, AES-CBC-MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 authentication algorithms at various packet sizes. Source: Jesse Walker, Intel (See also http://www.cs.ucdavis.edu/~rogaway/umac/perf00.html for additional data) Aboba, et al. Standards Track [Page 34]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 Table A-2 presents the cycles/second required by the AES-PMAC, AES-CBC- MAC, AES-UMAC, HMAC-MD5, and HMAC-SHA1 algorithms, implemented in software, assuming a 1500 byte packet. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec | | Transform | octet | @ | @ | @ | | | (software) | 100 Mbps | 1 Gbps | 10 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | AES-UMAC | 3.5 | 43,750,000 | 437,500,000 | 4.375 B | | (8 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | HMAC-SHA1 | 22.87 | 285,875,000 | 2.8588 B | 28.588 B | | (20 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | HMAC-MD5 | 25.09 | 313,625,000 | 3.1363 B | 31.363 B | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | AES-CBC-MAC | 26.86 | 335,750,000 | 3.358 B | 33.575 B | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | AES-PMAC | 33.52 | 419,000,000 | 4.19 B | 41.900 B | | (8 octets) | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Table A-2: Software performance of the HMAC-SHA1, HMAC-MD5, AES-CBC-MAC and AES-PMAC authentication algorithms at 100 Mbps, 1 Gbps, and 10 Gbps line rates (1500 byte packet). Source: Jesse Walker, Intel At speeds of 100 Mbps, AES-UMAC is implementable with only a modest processor, and the other algorithms are implementable, assuming that a single high-speed processor can be dedicated to the task. At 1 Gbps, only AES-UMAC is implementable on a single high-speed processor; multiple high speed processors (1+ Ghz) will be required for the other algorithms. At 10 Gbps, only AES-UMAC is implementable even with multiple high speed processors; the other algorithms will require a prodigious number of cycles/second. Thus at 10 Gbps, hardware acceleration will be required for all algorithms with the possible exception of AES-UMAC. Aboba, et al. Standards Track [Page 35]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 A.2 Encryption and Authentication transforms Table A-3 presents the cycles/byte required by the AES-CBC, AES-CTR and 3DES-CBC encryption algorithms (no MAC), implemented in software, for various packet sizes. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | Data size | AES-CBC | AES-CTR | 3DES-CBC | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 64 | 31.22 | 26.02 | 156.09 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128 | 31.22 | 28.62 | 150.89 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192 | 31.22 | 27.75 | 150.89 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 256 | 28.62 | 27.32 | 150.89 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 320 | 29.14 | 28.1 | 150.89 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 384 | 28.62 | 27.75 | 148.29 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 448 | 28.99 | 27.5 | 149.4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 512 | 28.62 | 27.32 | 148.29 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 576 | 28.33 | 27.75 | 147.72 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 640 | 28.62 | 27.06 | 147.77 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Aboba, et al. Standards Track [Page 36]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | Data size | AES-CBC | AES-CTR | 3DES-CBC | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 768 | 28.18 | 27.32 | 147.42 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 896 | 28.25 | 27.5 | 147.55 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1024 | 27.97 | 27.32 | 148.29 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1152 | 28.33 | 27.46 | 147.13 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1280 | 28.1 | 27.58 | 146.99 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1408 | 27.91 | 27.43 | 147.34 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1500 | 27.97 | 27.53 | 147.85 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Table A-3: Cycles/byte consumed by the AES-CBC, AES-CTR and 3DES-CBC encryption algorithms at various packet sizes, implemented in software. Source: Jesse Walker, Intel Aboba, et al. Standards Track [Page 37]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 Table A-4 presents the cycles/second required by the AES-CBC, AES-CTR and 3DES-CBC encryption algorithms (no MAC), implemented in software, at 100 Mbps, 1 Gbps, and 10 Gbps line rates (assuming a 1500 byte packet). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec | | Transform | octet | @ | @ | @ | | | (software) | 100 Mbps | 1 Gbps | 10 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | AES-CBC | 27.97 | 349,625,000 | 3.4963 B | 34.963 B | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | AES-CTR | 27.53 | 344,125,000 | 3.4413 B | 34.413 B | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | 3DES -CBC | 147.85 | 1.84813 B | 18.4813 B | 184.813 B | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Table A-4: Software performance of the AES-CBC, AES-CTR, and 3DES encryption algorithms at 100 Mbps, 1 Gbps, and 10 Gbps line rates (1500 byte packet). Source: Jesse Walker, Intel At speeds of 100 Mbps, AES-CBC and AES-CTR mode are implementable with a high-speed processor, while 3DES would require multiple high speed processors. At speeds of 1 Gbps, multiple high speed processors are required for AES-CBC and AES-CTR mode. At speeds of 1+ Gbps for 3DES, and 10 Gbps for all algorithms, implementation in software is infeasible, and hardware acceleration is required. Aboba, et al. Standards Track [Page 38]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 Table A-5 presents the cycles/byte required for combined encryption/authentication algorithms: AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB at various packet sizes, implemented in software. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | AES | AES | AES | | | Data size | CBC + | CTR + | CTR + | AES- | | | CBCMAC | CBCMAC | UMAC | OCB | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 64 | 119.67 | 52.03 | 52.03 | 57.23 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128 | 70.24 | 57.23 | 39.02 | 44.23 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192 | 58.97 | 55.5 | 36.42 | 41.63 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 256 | 57.23 | 55.93 | 35.12 | 40.32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 320 | 57.23 | 55.15 | 33.3 | 38.5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 384 | 57.23 | 55.5 | 32.95 | 37.29 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 448 | 58.72 | 55 | 32.71 | 37.17 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 512 | 58.54 | 55.28 | 32.52 | 36.42 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Aboba, et al. Standards Track [Page 39]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | AES | AES | AES | | | Data size | CBC + | CTR + | CTR + | AES- | | | CBCMAC | CBCMAC | UMAC | OCB | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 576 | 57.81 | 55.5 | 31.8 | 37 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 640 | 57.75 | 55.15 | 31.74 | 36.42 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 768 | 57.67 | 55.5 | 31.65 | 35.99 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 896 | 57.61 | 55.75 | 31.22 | 35.68 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1024 | 57.56 | 55.61 | 31.22 | 35.45 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1152 | 57.52 | 55.21 | 31.22 | 35.55 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1280 | 57.75 | 55.15 | 31.22 | 36.16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1408 | 57.47 | 55.34 | 30.75 | 35.24 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1500 | 57.72 | 55.5 | 30.86 | 35.3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Table A-5: Cycles/byte of combined encryption/authentication algorithms: AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB at various packet sizes, implemented in software. Aboba, et al. Standards Track [Page 40]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 Table A-6 presents the cycles/second required for the AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB encryption and authentication algorithms operating at line rates of 100 Mbps, 1 Gbps and 10 Gbps, assuming 1500 byte packets. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Cycles/ | Cycles/sec | Cycles/sec | Cycles/sec | | Transform | octet | @ | @ | @ | | | (software) | 100 Mbps | 1 Gbps | 10 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | AES | | | | | | CBC + CBCMAC | 57.72 | 721,500,000 | 7.215 B | 72.15 B | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | AES | | | | | | CTR + CBCMAC | 55.5 | 693,750,000 | 6.938 B | 69.38 B | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | AES | | | | | | CTR + UMAC | 30.86 | 385,750,000 | 3.858 B | 38.58 B | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | | | AES-OCB | 35.3 | 441,250,000 | 4.413 B | 44.13 B | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Table A-6: Cycles/second required for the AES CBC + CBCMAC, AES CTR + CBCMAC, AES CTR + UMAC, and AES-OCB encryption and authentication algorithms, operating at line rates of 100 Mbps, 1 Gbps and 10 Gbps, assuming 1500 octet packets. Source: Jesse Walker, Intel At speeds of 100 Mbps, the algorithms are implementable on a high speed processor. At speeds of 1 Gbps, multiple high speed processors are required, and none of the algorithms are implementable in software at 10 Gbps line rate. Acknowledgments Thanks to Steve Bellovin of AT&T Research for useful discussions of this problem space. Aboba, et al. Standards Track [Page 41]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 425 936 6605 EMail: bernarda@microsoft.com William Dixon Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 425 703 8729 EMail: wdixon@microsoft.com David L. Black EMC Corporation 42 South Street Hopkinton, MA 01748 Phone: +1 508 435 1000 x75140 EMail: black_david@emc.com Joshua Tseng Nishan Systems 3850 North First Street San Jose, CA 95134-1702 Phone: +1 408 519 3749 EMail: jtseng@nishansystems.com Joseph J. Tardo Broadcom 3151 Zanker Road San Jose, CA 95134 Phone: +1 408 501 8445 Fax: +1 408 501 8460 EMail: jtardo@broadcom.com Mark Bakke Cisco Systems, Inc. 6450 Wedgwood Road, Suite 130 Maple Grove, MN 55311 Aboba, et al. Standards Track [Page 42]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 Phone: +1 763 398 1000 Fax: +1 763 398 1001 EMail: mbakke@cisco.com Steve Senum Cisco Systems, Inc. 6450 Wedgwood Road, Suite 130 Maple Grove, MN 55311 Phone: <TBD> Fax: +1 763 398 1001 EMail: ssenum@cisco.com Howard Herbert Intel Corporation 5000 West Chandler Blvd. M/S CH7-404 Chandler, Arizona 85226 Phone: +1 480 554 3116 EMail: howard.c.herbert@intel.com Jesse Walker Intel Corporation 2211 NE 25th Avenue Hillboro, Oregon 97124 Phone: +1 503 712 1849 Fax: +1 503 264 4843 Email: jesse.walker@intel.com Julian Satran IBM, Haifa Research Lab MATAM - Advanced Technology Center Haifa 31905, Israel Phone +972 4 829 6264 EMail: Julian_Satran@vnet.ibm.com Ofer Biran IBM, Haifa Research Lab MATAM - Advanced Technology Center Haifa 31905, Israel Phone +972 4 829 6253 Email: biran@il.ibm.com Aboba, et al. Standards Track [Page 43]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 Charles Kunzinger IBM Corporation Research Triangle Park, NC 27709 Phone: +1 919 254 4142 EMail: kunzinge@us.ibm.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE Aboba, et al. Standards Track [Page 44]
INTERNET-DRAFT Securing iSCSI & iFCP 13 September 2001 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Expiration Date This memo is filed as <draft-ietf-ips-security-00.txt>, and expires February 19, 2002. Aboba, et al. Standards Track [Page 45]
