Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3723

Securing Block Storage Protocols over IP

Pages: 70
Proposed Standard
Updated by:  7146
Part 1 of 3 – Pages 1 to 28
None   None   Next

Top   ToC   RFC3723 - Page 1
Network Working Group                                           B. Aboba
Request for Comments: 3723                                     Microsoft
Category: Standards Track                                       J. Tseng
                                                      McDATA Corporation
                                                               J. Walker
                                                                   Intel
                                                               V. Rangan
                                     Brocade Communications Systems Inc.
                                                           F. Travostino
                                                         Nortel Networks
                                                              April 2004


                Securing Block Storage Protocols over IP

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

This document discusses how to secure block storage and storage discovery protocols running over IP (Internet Protocol) using IPsec and IKE (Internet Key Exchange). Threat models and security protocols are developed for iSCSI (Internet Protocol Small Computer System Interface), iFCP (Internet Fibre Channel Storage Networking) and FCIP (Fibre Channel over TCP/IP), as well as the iSNS (Internet Storage Name Server) and SLPv2 (Service Location Protocol v2) discovery protocols. Performance issues and resource constraints are analyzed.

Table of Contents

1. Introduction ................................................. 3 1.1. iSCSI Overview ......................................... 3 1.2. iFCP Overview .......................................... 4 1.3. FCIP Overview .......................................... 4 1.4. IPsec Overview ......................................... 4 1.5. Terminology ............................................ 6 1.6. Requirements Language .................................. 7
Top   ToC   RFC3723 - Page 2
   2.  Block Storage Protocol Security ..............................  7
       2.1.  Security Requirements  .................................  7
       2.2.  Resource Constraints ................................... 10
       2.3.  Security Protocol ...................................... 12
       2.4.  iSCSI Authentication ................................... 16
       2.5.  SLPv2 Security ......................................... 18
       2.6.  iSNS Security .......................................... 24
   3.  iSCSI security Inter-Operability Guidelines .................. 28
       3.1.  iSCSI Security Issues .................................. 28
       3.2.  iSCSI and IPsec Interaction ............................ 29
       3.3.  Initiating a New iSCSI Session ......................... 30
       3.4.  Graceful iSCSI Teardown ................................ 31
       3.5.  Non-graceful iSCSI Teardown ............................ 31
       3.6.  Application Layer CRC .................................. 32
   4.  iFCP and FCIP Security Issues ................................ 34
       4.1.  iFCP and FCIP Authentication Requirements .............. 34
       4.2.  iFCP Interaction with IPsec and IKE .................... 34
       4.3.  FCIP Interaction with IPsec and IKE .................... 35
   5.  Security Considerations ...................................... 36
       5.1.  Transport Mode Versus Tunnel Mode ...................... 36
       5.2.  NAT Traversal .......................................... 39
       5.3.  IKE Issues ............................................. 40
       5.4.  Rekeying Issues ........................................ 40
       5.5.  Transform Issues ....................................... 43
       5.6.  Fragmentation Issues ................................... 45
       5.7.  Security Checks ........................................ 46
       5.8.  Authentication Issues .................................. 47
       5.9.  Use of AES in Counter Mode ............................. 51
   6.  IANA Considerations .......................................... 51
       6.1.  Definition of Terms .................................... 52
       6.2.  Recommended Registration Policies ...................... 52
   7.  Normative References ......................................... 52
   8.  Informative References ....................................... 54
   9.  Acknowledgments .............................................. 58
   Appendix A - Well Known Groups for Use with SRP  ................. 59
   Appendix B - Software Performance of IPsec Transforms  ........... 61
       B.1.  Authentication Transforms .............................. 61
       B.2.  Encryption and Authentication Transforms ............... 64
   Authors' Addresses ............................................... 69
   Full Copyright Statement ......................................... 70
Top   ToC   RFC3723 - Page 3

1. Introduction

This specification discusses use of the IPsec protocol suite for protecting block storage protocols over IP networks (including iSCSI, iFCP and FCIP), as well as storage discovery protocols (iSNS and SLPv2).

1.1. iSCSI Overview

iSCSI, described in [RFC3720], 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 document 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). 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 application layer entities that are independent of TCP ports and IP addresses. Initiators and targets have names whose syntax is defined in [RFC3721]. iSCSI sessions between a given initiator and target are run over one or more TCP connections between those entities. That is, the login process establishes an association between an iSCSI Session and the TCP connection(s) over which iSCSI PDUs will be carried. 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. Rather, it relies upon the IPsec protocol suite to provide per-packet data confidentiality and
Top   ToC   RFC3723 - Page 4
   integrity and authentication services, with IKE as the key management
   protocol.  iSCSI uses TCP to provide congestion control, error
   detection and error recovery.

1.2. iFCP Overview

iFCP, defined in [iFCP], is a gateway-to-gateway protocol, which provides transport services to Fibre Channel devices over a TCP/IP network. iFCP allows interconnection and networking of existing Fibre Channel devices at wire speeds over an IP network. iFCP implementations emulate fabric services in order to improve fault tolerance and scalability by fully leveraging IP technology. Each TCP connection is used to support storage traffic between a unique pair of Fibre Channel N_PORTs. iFCP does not have a native, in-band security mechanism. Rather, it relies upon the IPsec protocol suite to provide data confidentiality and authentication services, and IKE as the key management protocol. iFCP uses TCP to provide congestion control, error detection and error recovery.

1.3. FCIP Overview

FCIP, defined in [FCIP], is a pure FC encapsulation protocol that transports FC frames. Current specification work intends this for interconnection of Fibre Channel switches over TCP/IP networks, but the protocol is not inherently limited to connecting FC switches. FCIP differs from iFCP in that no interception or emulation of fabric services is involved. One or more TCP connections are bound to an FCIP Link, which is used to realize Inter-Switch Links (ISLs) between pairs of Fibre Channel entities. FCIP Frame Encapsulation is described in [RFC3643]. FCIP does not have a native, in-band security mechanism. Rather, it relies upon the IPsec protocol suite to provide data confidentiality and authentication services, and IKE as the key management protocol. FCIP uses TCP to provide congestion control, error detection and error recovery.

1.4. IPsec Overview

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 [RFC2401], IKE [RFC2409][RFC2412], IPsec Authentication Header (AH) [RFC2402] and IPsec Encapsulating Security Payload (ESP) [RFC2406] documents. IKE is the key management protocol while AH and ESP are used to protect IP traffic.
Top   ToC   RFC3723 - Page 5
   An IPsec SA is a one-way security association, uniquely identified by
   the 3-tuple: Security Parameter Index (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 [RFC2408],and the IP Security Domain of
   Interpretation (DOI) [RFC2407].  IKE has two phases, and accomplishes
   the following functions:

   [1]  Protected cipher suite and options negotiation - using keyed
        MACs and encryption and anti-replay mechanisms

   [2]  Master key generation - such as via MODP Diffie-Hellman
        calculations

   [3]  Authentication of end-points

   [4]  IPsec SA management (selector negotiation, options negotiation,
        create, delete, and rekeying)

   Items 1 through 3 are accomplished in IKE Phase 1, while item 4 is
   handled in IKE Phase 2.

   An IKE Phase 2 negotiation is performed to establish both an inbound
   and an outbound IPsec SA.  The traffic to be protected by an IPsec SA
   is determined by a selector which has been proposed by the IKE
   initiator and accepted by the IKE Responder.  In IPsec transport
   mode, the IPsec SA selector can be a "filter" or traffic classifier,
   defined as the 5-tuple: <Source IP address, Destination IP address,
   transport protocol (UDP/SCTP/TCP), Source port, Destination port>.
   The successful establishment of a IKE Phase-2 SA results in the
   creation of two uni-directional IPsec SAs fully qualified by the
   tuple <Protocol (ESP/AH), destination address, SPI>.

   The session keys for each IPsec SA are derived from a master key,
   typically via 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.
Top   ToC   RFC3723 - Page 6

1.5. Terminology

Fibre Channel Fibre Channel (FC) is a gigabit speed networking technology primarily used to implement Storage Area Networks (SANs), although it also may be used to transport other frames types as well, including IP. FC is standardized under American National Standard for Information Systems of the InterNational Committee for Informational Technology Standards (ANSI-INCITS) in its T11 technical committee. FCIP Fibre Channel over IP (FCIP) is a protocol for interconnecting Fibre Channel islands over IP Networks so as to form a unified SAN in a single Fibre Channel fabric. The principal FCIP interface point to the IP Network is the FCIP Entity. The FCIP Link represents one or more TCP connections that exist between a pair of FCIP Entities. HBA Host Bus Adapter (HBA) 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. iFCP iFCP is a gateway-to-gateway protocol, which provides Fibre Channel fabric services to Fibre Channel devices over a TCP/IP network. IP block storage protocol Where used within this document, the term "IP block storage protocol" applies to all block storage protocols running over IP, including iSCSI, iFCP and FCIP. iSCSI iSCSI is a client-server protocol in which clients (initiators) open connections to servers (targets).
Top   ToC   RFC3723 - Page 7
   iSNS
      The Internet Storage Name Server (iSNS) protocol provides for
      discovery and management of iSCSI and Fibre Channel (FCP) storage
      devices.  iSNS applications store iSCSI and FC device attributes
      and monitor their availability and reachability, providing a
      consolidated information repository for an integrated IP block
      storage network.  iFCP requires iSNS for discovery and management,
      while iSCSI may use iSNS for discovery, and FCIP does not use
      iSNS.

   initiator
      The iSCSI initiator connects to the target on well-known TCP port
      3260.  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.6. Requirements Language

In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHALL", "SHALL NOT", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119]. Note that requirements specified in this document apply only to use of IPsec and IKE with IP block storage protocols. Thus, these requirements do not apply to IPsec implementations in general. Implementation requirements language should therefore be assumed to relate to the availability of features for use with IP block storage security only. Although the security requirements in this document are already incorporated into the iSCSI [RFC3720], iFCP [iFCP] and FCIP [FCIP] standards track documents, they are reproduced here for convenience. In the event of a discrepancy, the individual protocol standards track documents take precedence.

2. Block Storage Protocol Security

2.1. Security Requirements

IP Block storage protocols such as iSCSI, iFCP and FCIP are used to transmit SCSI commands over IP networks. Therefore, both the control and data packets of these IP block storage protocols are vulnerable to attack. Examples of attacks include:
Top   ToC   RFC3723 - Page 8
   [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 packets into an IP block
        storage connection.

   [4]  An adversary may attempt to hijack TCP connection(s)
        corresponding to an IP block storage session.

   [5]  An adversary may launch denial of service attacks against IP
        block storage devices such as by sending a TCP reset.

   [6]  An adversary may attempt to disrupt security negotiation
        process, in order to weaken the authentication, or gain access
        to user passwords.  This includes disruption of application-
        layer authentication negotiations such as iSCSI Login.

   [7]  An adversary may attempt to impersonate a legitimate IP block
        storage entity.

   [8]  An adversary may launch a variety of attacks (packet
        modification or injection, denial of service) against the
        discovery (SLPv2 [RFC2608]) or discovery and management (iSNS
        [iSNS]) process.  iSCSI can use SLPv2 or iSNS.  FCIP only uses
        SLPv2, and iFCP only uses iSNS.

   Since iFCP and FCIP devices are the last line of defense for a whole
   Fibre Channel island, the above attacks, if successful, could
   compromise the security of all the Fibre Channel hosts behind the
   devices.

   To address the above threats, IP block storage security protocols
   must support confidentiality, data origin authentication, integrity,
   and replay protection on a per-packet basis.  Confidentiality
   services are important since IP block storage traffic may traverse
   insecure public networks.  The IP block storage security protocols
   must support perfect forward secrecy in the rekeying process.

   Bi-directional authentication of the communication endpoints MUST be
   provided.  There is no requirement that the identities used in
   authentication be kept confidential (e.g., from a passive
   eavesdropper).
Top   ToC   RFC3723 - Page 9
   For a security protocol to be useful, CPU overhead and hardware
   availability must not preclude implementation at 1 Gbps today.
   Implementation feasibility at 10 Gbps is highly desirable, but may
   not be demonstrable at this time.  These performance levels apply to
   aggregate throughput, and include all TCP connections used between IP
   block storage endpoints.  IP block storage communications typically
   involve multiple TCP connections.  Performance issues are discussed
   further in Appendix B.

   Enterprise data center networks are considered mission-critical
   facilities that must be isolated and protected from possible security
   threats.  Such networks are often protected by security gateways,
   which at a minimum provide a shield against denial of service
   attacks.  The IP block storage security architecture should be able
   to leverage the protective services of the existing security
   infrastructure, including firewall protection, NAT and NAPT services,
   and VPN services available on existing security gateways.

   When iFCP or FCIP devices are deployed within enterprise networks, IP
   addresses will be typically be statically assigned as is the case
   with most routers and switches.  Consequently, support for dynamic IP
   address assignment, as described in [RFC3456], will typically not be
   required, although it cannot be ruled out.  Such facilities will also
   be relevant to iSCSI hosts whose addresses are dynamically assigned.
   As a result, the IP block storage security protocols must not
   introduce additional security vulnerabilities where dynamic address
   assignment is supported.

   While IP block storage security is mandatory to implement, it is not
   mandatory to use.  The security services used depend on the
   configuration and security policies put in place.  For example,
   configuration will influence the authentication algorithm negotiated
   within iSCSI Login, as well as the security services
   (confidentiality, data origin authentication, integrity, replay
   protection) and transforms negotiated when IPsec is used to protect
   IP block storage protocols such as iSCSI, iFCP and FCIP.

   FCIP implementations may allow enabling and disabling security
   mechanisms at the granularity of an FCIP Link.  For iFCP, the
   granularity corresponds to an iFCP Portal.  For iSCSI, the
   granularity of control is typically that of an iSCSI session,
   although it is possible to exert control down to the granularity of
   the destination IP address and TCP port.

   Note that with IPsec, security services are negotiated at the
   granularity of an IPsec SA, so that IP block storage connections
   requiring a set of security services different from those negotiated
   with existing IPsec SAs will need to negotiate a new IPsec SA.
Top   ToC   RFC3723 - Page 10
   Separate IPsec SAs are also advisable where quality of service
   considerations dictate different handling of IP block storage
   connections.  Attempting to apply different quality of service to
   connections handled by the same IPsec SA can result in reordering,
   and falling outside the replay window.  For a discussion of the
   issues, see [RFC2983].

   IP block storage protocols can be expected to carry sensitive data
   and provide access to systems and data that require protection
   against security threats.  SCSI and Fibre Channel currently contain
   little in the way of security mechanisms, and rely on physical
   security, administrative security, and correct configuration of the
   communication medium and systems/devices attached to it for their
   security properties.

   For most IP networks, it is inappropriate to assume physical
   security, administrative security, and correct configuration of the
   network and all attached nodes (a physically isolated network in a
   test lab may be an exception).  Therefore, authentication SHOULD be
   used by IP block storage protocols (e.g., iSCSI SHOULD use one of its
   in-band authentication mechanisms or the authentication provided by
   IKE) in order to provide a minimal assurance that connections have
   initially been opened with the intended counterpart.

   iSNS, described in [iSNS], is required in all iFCP deployments.
   iSCSI may use iSNS for discovery, and FCIP does not use iSNS.  iSNS
   applications store iSCSI and FC device attributes and monitor their
   availability and reachability, providing a consolidated information
   repository for an integrated IP block storage network.  The iSNS
   specification defines mechanisms to secure communication between an
   iSNS server and its clients.

2.2. Resource Constraints

Resource constraints and performance requirements for iSCSI are discussed in [RFC3347] Section 3.2. iFCP and FCIP devices 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. Therefore, memory and CPU resources are generally not a constraining factor. iSCSI will be implemented on a variety of systems ranging from large servers running general purpose operating systems to embedded host bus adapters (HBAs). In general, a host bus adapter is the most constrained 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
Top   ToC   RFC3723 - Page 11
   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.
Top   ToC   RFC3723 - Page 12

2.3. Security Protocol

2.3.1. Transforms

All IP block storage security compliant implementations MUST support IPsec ESP [RFC2406] to provide security for both control packets and data packets, as well as the replay protection mechanisms of IPsec. When ESP is utilized, per-packet data origin authentication, integrity and replay protection MUST be used. To provide confidentiality with ESP, ESP with 3DES in CBC mode [RFC2451][3DESANSI] MUST be supported, and AES in Counter mode, as described in [RFC3686], SHOULD be supported. To provide data origin authentication and integrity with ESP, HMAC-SHA1 [RFC2404] MUST be supported, and AES in CBC MAC mode with XCBC extensions [RFC3566] SHOULD be supported. DES in CBC mode SHOULD NOT be used due to its inherent weakness. ESP with NULL encryption MUST be supported for authentication.

2.3.2. IPsec Modes

Conformant IP block storage protocol implementations MUST support ESP [RFC2406] in tunnel mode and MAY implement IPsec with ESP in transport mode.

2.3.3. IKE

Conformant IP block storage security implementations MUST support IKE [RFC2409] for peer authentication, negotiation of security associations, and key management, using the IPsec DOI [RFC2407]. Manual keying MUST NOT be used since it does not provide the necessary rekeying support. Conformant IP block storage security implementations MUST support peer authentication using a pre-shared key, and MAY support certificate-based peer authentication using digital signatures. Peer authentication using the public key encryption methods outlined in IKE's sections 5.2 and 5.3 [RFC2409] SHOULD NOT be used. Conformant IP block storage security implementations MUST support IKE Main Mode and SHOULD support Aggressive Mode. IKE Main Mode with pre-shared key authentication SHOULD NOT be used when either of the peers use a dynamically assigned IP address. While Main Mode with pre-shared key authentication offers good security in many cases, situations where dynamically assigned addresses are used force use of a group pre-shared key, which is vulnerable to man-in-the-middle attack.
Top   ToC   RFC3723 - Page 13
   When digital signatures are used for authentication, either IKE Main
   Mode or IKE Aggressive Mode MAY be used.  In all cases, access to
   locally stored secret information (pre-shared key,  or private  key
   for digital signing) must be suitably restricted, since compromise of
   the secret information nullifies the security properties of the
   IKE/IPsec protocols.

   When digital signatures are used to achieve authentication, an IKE
   negotiator SHOULD use IKE Certificate Request Payload(s) to specify
   the certificate authority (or authorities) that are trusted in
   accordance with its local policy.  IKE negotiators SHOULD check the
   pertinent Certificate Revocation List (CRL) before accepting a PKI
   certificate for use in IKE's authentication procedures.

   The IPsec DOI [RFC2407] provides for several types of identification
   data.  Within IKE Phase 1, for use within the IDii and IDir payloads,
   conformant IP block storage security implementations MUST support the
   ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6) and
   ID_FQDN Identity Payloads.  iSCSI security implementations SHOULD
   support the ID_USER_FQDN Identity Payload; other IP block storage
   protocols (iFCP, FCIP) SHOULD NOT use the ID_USER_FQDN Identity
   Payload.  Identities other than ID_IPV4_ADDR and ID_IPV6_ADDR (such
   as ID_FQDN or ID_USER_FQDN) SHOULD be employed in situations where
   Aggressive mode is utilized along with pre-shared keys and IP
   addresses are dynamically assigned.  The IP Subnet, IP Address Range,
   ID_DER_ASN1_DN, ID_DER_ASN1_GN formats SHOULD NOT be used for IP
   block storage protocol security; The ID_KEY_ID Identity Payload MUST
   NOT be used.  As described in [RFC2407], within Phase 1 the ID port
   and protocol fields MUST be set to zero or to UDP port 500.  Also, as
   noted in [RFC2407]:

      When an IKE exchange is authenticated using certificates (of any
      format), any ID's used for input to local policy decisions SHOULD
      be contained in the certificate used in the authentication of the
      exchange.

   The Phase 2 Quick Mode exchanges used by IP block storage protocol
   implementations MUST explicitly carry the Identity Payload fields
   (IDci and IDcr).  Each Phase 2 IDci and IDcr Payload SHOULD carry a
   single IP address (ID_IPV4_ADDR, ID_IPV6_ADDR) and SHOULD NOT use the
   IP Subnet or IP Address Range formats.  Other ID payload formats MUST
   NOT be used.

   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.  The receipt of an IKE Phase 2 delete
   message MUST NOT be interpreted as a reason for tearing down an IP
Top   ToC   RFC3723 - Page 14
   block storage connection.  Rather, it is preferable to leave the
   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 connections up and down.

2.3.4. Security Policy Configuration

One of the goals of this specification is to enable a high level of interoperability without requiring extensive configuration. This section provides guidelines on setting of IKE parameters so as to enhance the probability of a successful negotiation. It also describes how information on security policy configuration can be provided so as to further enhance the chances of success. To enhance the prospects for interoperability, some of the actions to consider include: [1] Transform restriction. Since support for 3DES-CBC and HMAC-SHA1 is required of all implementations, offering these transforms enhances the probability of a successful negotiation. If AES-CTR [RFC3686] with XCBC-MAC [RFC3566] is supported, this transform combination will typically be preferred, with 3DES-CBC/HMAC-SHA1 as a secondary offer. [2] Group Restriction. If 3DES-CBC/HMAC-SHA1 is offered, and DH groups are offered, then it is recommended that a DH group of at least 1024 bits be offered along with it. If AES-CTR/XCBC-MAC is the preferred offer, and DH groups are offered, then it is recommended that a DH group of at least 2048 bits be offered along with it, as noted in [KeyLen]. If perfect forward secrecy is required in Quick Mode, then it is recommended that the QM PFS DH group be the same as the IKE Phase 1 DH group. This reduces the total number of combinations, enhancing the chances for interoperability. [3] Key lifetimes. If a key lifetime is offered that is longer than desired, then rather than causing the IKE negotiation to fail, it is recommended that the Responder consider the offered lifetime as a maximum, and accept it. The key can then use a lesser value for the lifetime, and utilize a Lifetime Notify in order to inform the other peer of lifetime expiration.
Top   ToC   RFC3723 - Page 15
   Even when the above advice is taken, it still may be useful to be
   able to provide additional configuration information in order to
   enhance the chances of success, and it is useful to be able to manage
   security configuration regardless of the scale of the deployment.

   For example, it may be desirable to configure the security policy of
   an IP block storage device.  This can be done manually or
   automatically via a security policy distribution mechanism.
   Alternatively, it can be supplied via iSNS or SLPv2.  If an IP block
   storage endpoint can obtain the required security policy by other
   means (manually, or automatically via a security policy distribution
   mechanism) then it need not request this information via iSNS or
   SLPv2.  However, if the required security policy configuration is not
   available via other mechanisms, iSNS or SLPv2 can be used to obtain
   it.

   It may also be helpful to obtain information about the preferences of
   the peer prior to initiating IKE.  While it is generally possible to
   negotiate security parameters within IKE, there are situations in
   which incompatible parameters can cause the IKE negotiation to fail.
   The following information can be provided via SLPv2 or iSNS:

   [4]  IPsec or cleartext support.
        The minimum piece of peer configuration required is whether an
        IP block storage endpoint requires IPsec or cleartext.  This
        cannot be determined from the IKE negotiation alone without
        risking a long timeout, which is highly undesirable for a disk
        access protocol.

   [5]  Perfect Forward Secrecy (PFS) support.
        It is helpful to know whether a peer allows PFS, since an IKE
        Phase 2 Quick Mode can fail if an initiator proposes PFS to a
        Responder that does not allow it.

   [6]  Preference for tunnel mode.
        While it is legal to propose both transport and tunnel mode
        within the same offer, not all IKE implementations will support
        this.  As a result, it is useful to know whether a peer prefers
        tunnel mode or transport mode, so that it is possible to
        negotiate the preferred mode on the first try.

   [7]  Main Mode and Aggressive Mode support.
        Since the IKE negotiation can fail if a mode is proposed to a
        peer that doesn't allow it, it is helpful to know which modes a
        peer allows, so that an allowed mode can be negotiated on the
        first try.
Top   ToC   RFC3723 - Page 16
   Since iSNS or SLPv2 can be used to distribute IPsec security policy
   and configuration information for use with IP block storage
   protocols, these discovery protocols would constitute a 'weak link'
   were they not secured at least as well as the protocols whose
   security they configure.  Since the major vulnerability is packet
   modification and replay, when iSNS or SLPv2 are used to distribute
   security policy or configuration information, at a minimum, per-
   packet data origin authentication, integrity and replay protection
   MUST be used to protect the discovery protocol.

2.4. iSCSI Authentication

2.4.1. CHAP

Compliant iSCSI implementations MUST implement the CHAP authentication method [RFC1994] (according to [RFC3720], section 11.1.4), which includes support for bi-directional authentication, and the target authentication option. When CHAP is performed over non-encrypted channel, it is vulnerable to an off-line dictionary attack. Implementations MUST support random CHAP secrets of up to 128 bits, including the means to generate such secrets and to accept them from an external generation source. Implementations MUST NOT provide secret generation (or expansion) means other than random generation. If CHAP is used with secret smaller than 96 bits, then IPsec encryption (according to the implementation requirements in [RFC3720] section 8.3.2) MUST be used to protect the connection. Moreover, in this case IKE authentication with group pre-shared keys SHOULD NOT be used. When CHAP is used with a secret smaller then 96 bits, a compliant implementation MUST NOT continue with the iSCSI login unless it can verify that IPsec encryption is being used to protect the connection. Originators MUST NOT reuse the CHAP challenge sent by the Responder for the other direction of a bidirectional authentication. Responders MUST check for this condition and close the iSCSI TCP connection if it occurs. The same CHAP secret SHOULD NOT be configured for authentication of multiple initiators or multiple targets, as this enables any of them to impersonate any other one of them, and compromising one of them enables the attacker to impersonate any of them. It is recommended that iSCSI implementations check for use of identical CHAP secrets by different peers when this check is feasible, and take appropriate measures to warn users and/or administrators when this is detected. A single CHAP secret MAY be used for authentication of an individual
Top   ToC   RFC3723 - Page 17
   initiator to multiple targets.  Likewise, a single CHAP secret MAY be
   used for authentication of an individual target to multiple
   initiators.

   A Responder MUST NOT send its CHAP response if the initiator has not
   successfully authenticated.  For example, the following exchange:

      I->R     CHAP_A=<A1,A2,...>
      R->I     CHAP_A=<A1> CHAP_C=<C> CHAP_I=<I>
      I->R     CHAP_N=<N> CHAP_C=<C> CHAP_I=<I>

   (Where N, (A1,A2), I, C, and R are correspondingly the Name,
   Algorithms, Identifier, Challenge, and Response as defined in
   [RFC1994])

   MUST result in the Responder (target) closing the iSCSI TCP
   connection because the initiator has failed to authenticate (there is
   no CHAP_R in the third message).

   Any CHAP secret used for initiator authentication MUST NOT be
   configured for authentication of any target, and any CHAP secret used
   for target authentication MUST NOT be configured for authentication
   of any initiator.  If the CHAP response received by one end of an
   iSCSI connection is the same as the CHAP response that the receiving
   endpoint would have generated for the same CHAP challenge, the
   response MUST be treated as an authentication failure and cause the
   connection to close (this ensures that the same CHAP secret is not
   used for authentication in both directions).  Also, if an iSCSI
   implementation can function as both initiator and target, different
   CHAP secrets and identities MUST be configured for these two roles.
   The following is an example of the attacks prevented by the above
   requirements:

   Rogue wants to impersonate Storage to Alice, and knows that a
      single secret is used for both directions of Storage-Alice
      authentication.

   Rogue convinces Alice to open two connections to Rogue, and
      Rogue identifies itself as Storage on both connections.

   Rogue issues a CHAP challenge on connection 1, waits for Alice
      to respond, and then reflects Alice's challenge as the initial
      challenge to Alice on connection 2.

      If Alice doesn't check for the reflection across connections,
      Alice's response on connection 2 enables Rogue to impersonate
      Storage on connection 1, even though Rogue does not know the
      Alice-Storage CHAP secret.
Top   ToC   RFC3723 - Page 18
   Note that RADIUS [RFC2865] does not support bi-directional CHAP
   authentication.  Therefore, while a target acting as a RADIUS client
   will be able to verify the initiator Response, it will not be able to
   respond to an initiator challenge unless it has access to an
   appropriate shared secret by some other means.

2.4.2. SRP

iSCSI implementations MAY implement the SRP authentication method [RFC2945] (see [RFC3720], Section 11.1.3). The strength of SRP security is dependent on the characteristics of the group being used (i.e., the prime modulus N and generator g). As described in [RFC2945], N is required to be a Sophie-German prime (of the form N = 2q + 1, where q is also prime) the generator g is a primitive root of GF(n) [SRPNDSS]. SRP well-known groups are included in Appendix A and additional groups may be registered with IANA. iSCSI implementations MUST use one of these well-known groups. All the groups specified in Appendix A up to 1536 bits (i.e., SRP-768, SRP-1024, SRP-1280, SRP-1536) MUST be supported by initiators and targets. To guarantee interoperability, targets MUST always offer "SRP-1536" as one of the proposed groups.

2.5. SLPv2 Security

Both iSCSI and FCIP protocols use SLPv2 as a way to discover peer entities and management servers. SLPv2 may also be used to provide information on peer security configuration. When SLPv2 is deployed, the SA advertisements as well as UA requests and/or responses are subject to the following security threats: [1] An attacker could insert or alter SA advertisements or a response to a UA request in order to masquerade as the real peer or launch a denial of service attack. [2] An attacker could gain knowledge about an SA or a UA through snooping, and launch an attack against the peer. Given the potential value of iSCSI targets and FCIP entities, leaking of such information not only increases the possibility of an attack over the network; there is also the risk of physical theft. [3] An attacker could spoof a DAAdvert. This could cause UAs and SAs to use a rogue DAs.
Top   ToC   RFC3723 - Page 19
   To address these threats, the following capabilities are required:

   [a]  Service information, as included in SrvRply, AttrRply, SrvReg
        and SrvDereg messages, needs to be kept confidential.

   [b]  The UA has to be able to distinguish between legitimate and
        illegitimate service information from SrvRply and AttrRply
        messages.  In the SLPv2 security model SAs are trusted to sign
        data.

   [c]  The DA has to be able to distinguish between legitimate and
        illegitimate SrvReg and SrvDereg messages.

   [d]  The UA has to be able to distinguish between legitimate and
        illegitimate  DA Advertisements.  This allows the UA to avoid
        rogue DAs that will return incorrect data or no data at all.  In
        the SLPv2 security model, UAs trust DAs to store, answer queries
        on and forward data on services, but not necessarily to
        originate it.

   [e]  SAs may have to trust DAs, especially if 'mesh-enhanced' SLPv2
        is used.  In this case, SAs register with only one DA and trust
        that this DA will forward the registration to others.

   By itself, SLPv2 security, defined in [RFC2608], does not satisfy
   these security requirements.  SLPv2 only provides end-to-end
   authentication, but does not support confidentiality.  In SLPv2
   authentication there is no way to authenticate "zero result
   responses".  This enables an attacker to mount a denial of service
   attack by sending UAs a "zero results" SrvRply or AttrRply as if from
   a DA with whose source address corresponds to a legitimate DAAdvert.

   In all cases, there is a potential for denial of service attack
   against protocol service providers, but such an attack is possible
   even in the absence of SLPv2 based discovery mechanisms.

2.5.1. SLPv2 Security Protocol

SLPv2 message types include: SrvRqst, SrvRply, SrvReg, SrvDereg, SrvAck, AttrRqst, AttrRply, DAAdvert, SrvTypeRqst, SrvTypeRply, SAAdvert. SLPv2 requires that User Agents (UAs) and Service Agents (SAs) support SrvRqst, SrvRply, and DAAdvert. SAs must additionally support SrvReg, SrvAck, and SAAdvert. Where no Directory Agent (DA) exists, the SrvRqst is multicast, but the SrvRply is sent via unicast UDP. DAAdverts are also multicast. However, all other SLPv2 messages are sent via UDP unicast.
Top   ToC   RFC3723 - Page 20
   In order to provide the required security functionality, iSCSI and
   FCIP implementations supporting SLPv2 security SHOULD protect SLPv2
   messages sent via unicast using IPsec ESP with a non-null transform.
   SLPv2 authentication blocks (carrying digital signatures), described
   in [RFC2608] MAY also be used to authenticate unicast and multicast
   messages.

   The usage of SLPv2 by iSCSI is described in [iSCSISLP].  iSCSI
   initiators and targets may enable IKE mechanisms to establish
   identity.  In addition, a subsequent user-level iSCSI session login
   can protect the initiator-target nexus.  This will protect them from
   any compromise of security in the SLPv2 discovery process.

   The usage of SLPv2 by FCIP is described in [FCIPSLP].  FCIP Entities
   assume that once the IKE identity of a peer is established, the FCIP
   Entity Name carried in FCIP Short Frame is also implicitly accepted
   as the authenticated peer.  Any such association between the IKE
   identity and the FCIP Entity Name is administratively established.

   For use in securing SLPv2, when digital signatures are used to
   achieve authentication in IKE, an IKE negotiator SHOULD use IKE
   Certificate Request Payload(s) to specify the certificate authority
   (or authorities) that are trusted in accordance with its local
   policy.  IKE negotiators SHOULD check the pertinent Certificate
   Revocation List (CRL) before accepting a PKI certificate for use in
   IKE's authentication procedures.  If key management of SLPv2 DAs
   needs to be coordinated with the SAs and the UAs as well as the
   protocol service implementations, one may use certificate based key
   management, with a shared root Certificate Authority (CA).

   One of the reasons for utilizing IPsec for SLPv2 security is that is
   more likely that certificates will be deployed for IPsec than for
   SLPv2.  This both simplifies SLPv2 security and makes it more likely
   that it will be implemented interoperably and more importantly, that
   it will be used.  As a result, it is desirable that little additional
   effort be required to enable IPsec protection of SLPv2.

   However, just because a certificate is trusted for use with IPsec
   does not necessarily imply that the host is authorized to perform
   SLPv2 operations.  When using IPsec to secure SLPv2, it may be
   desirable to distinguish between certificates appropriate for use by
   UAs, SAs, and DAs.  For example, while a UA might be allowed to use
   any certificate conforming to IKE certificate policy, the certificate
   used by an SA might indicate that it is a legitimate source of
   service advertisements.  Similarly, a DA certificate might indicate
   that it is a valid DA.  This can be accomplished by using special CAs
   to issue certificates valid for use by SAs and DAs; alternatively, SA
   and DA authorizations can be employed.
Top   ToC   RFC3723 - Page 21
   Assume that the policy for issuing and distributing SLPv2 authorized
   certificates to SAs and DAs limits them only to legitimate SAs and
   DAs.  In this case, IPsec is used to provide SLPv2 security as
   follows:

   [a]  SLPv2 messages sent via unicast are IPsec protected, using ESP
        with a non-null transform.

   [b]  SrvRply and AttrRply messages from either a DA or SA are unicast
        to UAs.  Assuming that the SA used a certificate authorized for
        SLPv2 service advertisement in establishing the IKE Phase 1 SA,
        or that the DA used a certificate authorized for DA usage, the
        UA can accept the information sent, even if it has no SLPv2
        authentication block.

        Note that where SrvRqst messages are multicast, they are not
        protected.  An attacker may attempt to exploit this by spoofing
        a multicast SrvRqst from the UA, generating a SrvRply from an SA
        of the attacker's choosing.  Although the SrvRply is secured, it
        does not correspond to a legitimate SrvRqst sent by the UA.  To
        avoid this attack, where SrvRqst messages are multicast, the UA
        MUST check that SrvRply messages represent a legitimate reply to
        the SrvRqst that was sent.

   [c]  SrvReg and SrvDereg messages from a SA are unicast to DAs.
        Assuming that the SA used a certificate authorized for SLPv2
        service advertisement in establishing the IKE Phase 1 SA, the DA
        can accept the de/registration even if it has no SLPv2
        authentication block.  Typically, the SA will check the DA
        authorization prior to sending the service advertisement.

   [d]  Multicast DAAdverts can be considered advisory.  The UA will
        attempt to contact DAs via unicast.  Assuming that the DA used a
        certificate authorized for SLPv2 DAAdverts in establishing the
        IKE Phase 1 SA, the UA can accept the DAAdvert even if it has no
        SLPv2 authentication block.

   [e]  SAs can accept DAAdverts as described in [d].

2.5.2. Confidentiality of Service Information

Since SLPv2 messages can contain information that can potentially reveal the vendor of the device or its other associated characteristics, revealing service information constitutes a security risk. As an example, the FCIP Entity Name may reveal a WWN from which an attacker can learn potentially useful information about the Entity's characteristics.
Top   ToC   RFC3723 - Page 22
   The SLPv2 security model assumes that service information is public,
   and therefore does not provide for confidentiality.  However, storage
   devices represent mission critical infrastructure of substantial
   value, and so iSCSI and FCIP security implementations supporting
   SLPv2 security SHOULD encrypt as well as authenticate and integrity-
   protect unicast SLPv2 messages.

   Assuming that all unicast SLPv2 messages are protected by IPsec, and
   that confidentiality is provided, then the risk of disclosure can be
   limited to SLPv2 messages sent via multicast, namely the SrvRqst and
   DAAdvert.

   The information leaked in a multicast SrvRqst depends on the level of
   detail in the query.  If leakage is a concern, then a DA can be
   provided.  If this is not feasible, then a general query can be sent
   via multicast, and then further detail can be obtained from the
   replying entities via additional unicast queries, protected by IPsec.

   Information leakage via a multicast DAAdvert is less of a concern
   than the authenticity of the message, since knowing that a DA is
   present on the network only enables an attacker to know that SLPv2 is
   in use, and possibly that a directory service is also present.  This
   information is not considered very valuable.

2.5.3. SLPv2 Security Implications

Through the definition of security attributes, it is possible to use SLPv2 to distribute information about security settings for IP block storage entities. SLPv2 distribution of security policy is not necessary if the security settings can be determined by other means, such as manual configuration or IPsec security policy distribution. If an entity has already obtained its security configuration via other mechanisms, then it MUST NOT request security policy via SLPv2. Where SLPv2 is used to provide security policy information for use with IP block storage protocols, SLPv2 MUST be protected by IPsec as described in this document. Where SLPv2 is not used to distribute security policy information, implementations MAY implement SLPv2 security as described in this document. Where SLPv2 is used, but security is not implemented, IP block storage protocol implementations MUST support a negative cache for authentication failures. This allows implementations to avoid continually contacting discovered endpoints that fail authentication within IPsec or at the application layer (in the case of iSCSI Login). The negative cache need not be maintained within the IPsec implementation, but rather within the IP block storage protocol implementation.
Top   ToC   RFC3723 - Page 23
   Since this document proposes that hop-by-hop security be used as the
   primary mechanism to protect SLPv2, UAs have to trust DAs to
   accurately relay data from SAs.  This is a change to the SLPv2
   security model described in [RFC2608].  However, SLPv2 authentication
   as defined in [RFC2608] does not provide a way to authenticate "zero
   result responses", leaving SLPv2 vulnerable to a denial of service
   attack.  Such an attack can be carried out on a UA by sending it a
   "zero results" SrvRply or AttrRply, sent from a source address
   corresponding to a DA issuing a legitimate DAAdvert.

   In addition, SLPv2 security as defined in [RFC2608] does not support
   confidentiality.  When IPsec with ESP and a non-null transform is
   used to protect SLPv2, not only can unicast requests and replies be
   authenticated, but confidentiality can also be provided.  This
   includes unicast requests to DAs and SAs as well as replies.  It is
   also possible to actively discover SAs using multicast SA discovery,
   and then to send unicast requests to the discovered SAs.

   As a result, for use with IP block storage protocols, it is believed
   that use of IPsec for security is more appropriate than the SLPv2
   security model defined in [RFC2608].

   Using IPsec to secure SLPv2 has performance implications.  Security
   associations established between:

   -  UAs and SAs may be reused (the client on the UA host will use the
      service on the SA host).

   -  SAs and DAs may be reused (the SAs will reregister services)

   -  UAs and DAs will probably not be reused (many idle security
      associations are likely to result, and build up on the DA).

   When IPsec is used to protect SLPv2, it is not necessarily
   appropriate for all hosts with whom an IPsec security association can
   be established to be trusted to originate SLPv2 service
   advertisements.  This is particularly the case in environments where
   it is easy to obtain certificates valid for use with IPsec (for
   example, where anyone with access to the network can obtain a machine
   certificate valid for use with IPsec).  If not all hosts are
   authorized to originate service advertisements, then it is necessary
   to distinguish between authorized and unauthorized hosts.

   This can be accomplished by the following mechanisms:

   [1]  Configuring SAs with the identities or certificate
        characteristics of valid DAs, and configuring DAs with the
        identities of SAs allowed to advertise IP block storage
Top   ToC   RFC3723 - Page 24
        services.  The DAs are then trusted to enforce policies on
        service registration.  This approach involves manual
        configuration, but avoids certificate customization for SLPv2.

   [2]  Restricting the issuance of certificates valid for use in SLPv2
        service advertisement.  While all certificates allowed for use
        with IPsec will chain to a trusted root, certificates for hosts
        authorized to originate service advertisements could be signed
        by an SLPv2-authorized CA, or could contain explicit SLPv2
        authorizations within the certificate.  After the IPsec security
        association is set up between the SLPv2 entities, the SLPv2
        implementations can then retrieve the certificates used in the
        negotiation in order to determine whether the entities are
        authorized for the operations that are being performed.  This
        approach requires less configuration, but requires some
        certificate customization for use with SLPv2.

2.6. iSNS Security

The iSCSI protocol may use iSNS for discovery and management services, while the iFCP protocol is required to use iSNS for such services. In addition, iSNS can be used to store and distribute security policy and authorization information to iSCSI and iFCP devices. When the iSNS protocol is deployed, the interaction between iSNS server and iSNS clients are subject to the following additional security threats: [1] An attacker can alter iSNS protocol messages, directing iSCSI and iFCP devices to establish connections with rogue devices, or weakening IPsec protection for iSCSI or iFCP traffic. [2] An attacker can masquerade as the real iSNS server by sending false iSNS heartbeat messages. This could deceive iSCSI and iFCP devices into using rogue iSNS servers. [3] An attacker can gain knowledge about iSCSI and iFCP devices by snooping iSNS protocol messages. Such information could aid an attacker in mounting a direct attack on iSCSI and iFCP devices, such as a denial-of-service attack or outright physical theft. To address these threats, the following capabilities are needed: [a] Unicast iSNS protocol messages may need to be authenticated. In addition, to protect against threat [3] above, confidentiality support is desirable, and REQUIRED when certain functions of iSNS are used.
Top   ToC   RFC3723 - Page 25
   [b]  Multicast iSNS protocol messages such as the iSNS heartbeat
        message need to be authenticated.  These messages need not be
        confidential since they do not leak critical information.

   There is no requirement that the identities of iSNS entities be kept
   confidential.  Specifically, the identity and location of the iSNS
   server need not be kept confidential.

   In order to protect against an attacker masquerading as an iSNS
   server, client devices MUST support authentication of broadcast or
   multicast messages such as the iSNS heartbeat.  The iSNS
   authentication block (which is identical in format to the SLP
   authentication block) MAY be used for this purpose.  Note that the
   authentication block is used only for iSNS broadcast or multicast
   messages, and SHOULD NOT be used in unicast iSNS messages.

   Since iSNS is used to distribute authorizations determining which
   client devices can communicate, IPsec authentication and data
   integrity MUST be supported.  In addition, if iSNS is used to
   distribute security policy for iFCP and iSCSI devices, then
   authentication, data integrity, and confidentiality MUST be supported
   and used.

   Where iSNS is used without security, IP block storage protocol
   implementations MUST support a negative cache for authentication
   failures.  This allows implementations to avoid continually
   contacting discovered endpoints that fail authentication within IPsec
   or at the application layer (in the case of iSCSI Login).  The
   negative cache need not be  maintained within the IPsec
   implementation, but rather within the IP block storage protocol
   implementation.

2.6.1. Use of iSNS to Discover Security Configuration of Peer Devices

In practice, within a single installation, iSCSI and/or iFCP devices may have different security settings. For example, some devices may be configured to initiate secure communication, while other devices may be configured to respond to a request for secure communication, but not to require security. Still other devices, while security capable, may neither initiate nor respond securely. In practice, these variations in configuration can result in devices being unable to communicate with each other. For example, a device that is configured to always initiate secure communication will experience difficulties in communicating with a device that neither initiates nor responds securely.
Top   ToC   RFC3723 - Page 26
   The iSNS protocol is used to transfer naming, discovery, and
   management information between iSCSI devices, iFCP gateways,
   management stations, and the iSNS server.  This includes the ability
   to enable discovery of security settings used for communication via
   the iSCSI and/or iFCP protocols.

   The iSNS server stores security settings for each iSCSI and iFCP
   device interface.  These security settings, which can be retrieved by
   authorized hosts, include use or non-use of IPsec, IKE, Main Mode,
   Aggressive Mode, PFS, Pre-shared Key, and certificates.

   For example, IKE may not be enabled for a particular device
   interface.  If a peer device can learn of this in advance by
   consulting the iSNS server, it will not need to waste time and
   resources attempting to initiate an IKE Phase 1 SA with that device
   interface.

   If iSNS is used to distribute security policy, then the minimum
   information that should be learned from the iSNS server is the use or
   non-use of IKE and IPsec by each iFCP or iSCSI peer device interface.
   This information is encoded in the Security Bitmap field of each
   Portal of the peer device, and is applicable on a per-interface basis
   for the peer device.  iSNS queries to acquire security configuration
   data about peer devices MUST be protected by IPsec/ESP
   authentication.

2.6.2. Use of iSNS to Distribute iSCSI and iFCP Security Policies

Once communication between iSNS clients and the iSNS server are secured through use of IPsec, iSNS clients have the capability to discover the security settings required for communication via the iSCSI and/or iFCP protocols. Use of iSNS for distribution of security policies offers the potential to reduce the burden of manual device configuration, and decrease the probability of communications failures due to incompatible security policies. If iSNS is used to distribute security policies, then IPsec authentication, data integrity, and confidentiality MUST be used to protect all iSNS protocol messages. The complete IKE/IPsec configuration of each iFCP and/or iSCSI device can be stored in the iSNS server, including policies that are used for IKE Phase 1 and Phase 2 negotiations between client devices. The IKE payload format includes a series of one or more proposals that the iSCSI or iFCP device will use when negotiating the appropriate IPsec policy to use to protect iSCSI or iFCP traffic.
Top   ToC   RFC3723 - Page 27
   Note that iSNS distribution of security policy is not necessary if
   the security settings can be determined by other means, such as
   manual configuration or IPsec security policy distribution.  If an
   entity has already obtained its security configuration via other
   mechanisms, then it MUST NOT request security policy via iSNS.

   For further details on how to store and retrieve IKE policy proposals
   in the iSNS server, see [iSNS].

2.6.3. iSNS Interaction with IKE and IPsec

When IPsec security is enabled, each iSNS client that is registered in the iSNS database maintains at least one Phase 1 and one Phase 2 security association with the iSNS server. All iSNS protocol messages between iSNS clients and the iSNS server are to be protected by a phase-2 security association.

2.6.4. iSNS Server Implementation Requirements

All iSNS implementations MUST support the replay protection mechanisms of IPsec. ESP in tunnel mode MUST be implemented, and IPsec with ESP in transport mode MAY be implemented. To provide data origin authentication and integrity with ESP, HMAC- SHA1 MUST be supported, and AES in CBC MAC mode with XCBC extensions [RFC3566] SHOULD be supported. When confidentiality is implemented, 3DES in CBC mode MUST be supported, and AES in Counter mode, as described in [RFC3686], SHOULD be supported. DES in CBC mode SHOULD NOT be used due to its inherent weakness. If confidentiality is not required but data origin authentication and integrity is enabled, ESP with NULL Encryption MUST be used. Conformant iSNS implementations MUST support IKE for authentication, negotiation of security associations, and key management, using the IPsec DOI, described in [RFC2407]. IP block storage protocols can be expected to send data in high volumes, thereby requiring rekey. Since manual keying does not provide rekeying support, its use is prohibited with IP block storage protocols. Although iSNS does not send a high volume of data, and therefore rekey is not a major concern, manual keying SHOULD NOT be used. This is for consistency, since dynamic keying support is already required in IP storage security implementations. Conformant iSNS security implementations MUST support authentication using a pre- shared key, and MAY support certificate-based peer authentication using digital signatures. Peer authentication using the public key encryption methods outlined in [RFC2409] sections 5.2 and 5.3 SHOULD NOT be used.
Top   ToC   RFC3723 - Page 28
   Conformant iSNS implementations MUST support IKE Main Mode and SHOULD
   support Aggressive Mode.  IKE Main Mode with pre-shared key
   authentication SHOULD NOT be used when either of the peers use
   dynamically assigned IP addresses.  While Main Mode with pre-shared
   key authentication offers good security in many cases, situations
   where dynamically assigned addresses are used force use of a group
   pre-shared key, which is vulnerable to man-in-the-middle attack.

   When digital signatures are used for authentication, either IKE Main
   Mode or IKE Aggressive Mode MAY be used.  In all cases, access to
   locally stored secret information (pre-shared key or private key for
   digital signing) MUST be suitably restricted, since compromise of the
   secret information nullifies the security properties of the IKE/IPsec
   protocols.

   When digital signatures are used to achieve authentication, an IKE
   negotiator SHOULD use IKE Certificate Request Payload(s) to specify
   the certificate authority (or authorities) that are trusted in
   accordance with its local policy.  IKE negotiators SHOULD check the
   pertinent Certificate Revocation List (CRL) before accepting a PKI
   certificate for use in IKE's authentication procedures.



(page 28 continued on part 2)

Next Section