In-Band Initiator-Target Authentication

During login, the target MAY authenticate the initiator and the initiator MAY authenticate the target. The authentication is

performed on every new iSCSI connection by an exchange of iSCSI Login PDUs using a negotiated authentication method.

The authentication method cannot assume an underlying IPsec

protection, because IPsec is optional to use. An attacker should gain as little advantage as possible by inspecting the authentication phase PDUs. Therefore, a method using cleartext (or equivalent) passwords MUST NOT be used; on the other hand, identity protection is not strictly required.

The authentication mechanism protects against an unauthorized login to storage resources by using a false identity (spoofing). Once the authentication phase is completed, if the underlying IPsec is not used, all PDUs are sent and received in the clear. The

authentication mechanism alone (without underlying IPsec) should only be used when there is no risk of eavesdropping or of message

insertion, deletion, modification, and replaying.

Section 12 defines several authentication methods and the exact steps that must be followed in each of them, including the iSCSI-text-keys and their allowed values in each step. Whenever an iSCSI initiator gets a response whose keys, or their values, are not according to the step definition, it MUST abort the connection.

Whenever an iSCSI target gets a request or response whose keys, or their values, are not according to the step definition, it MUST answer with a Login reject with the "Initiator Error" or "Missing Parameter" status. These statuses are not intended for

cryptographically incorrect values such as the CHAP response, for which the "Authentication Failure" status MUST be specified. The importance of this rule can be illustrated in CHAP with target authentication (see Section 12.1.3), where the initiator would have been able to conduct a reflection attack by omitting its response key (CHAP_R), using the same CHAP challenge as the target and reflecting the target’s response back to the target. In CHAP, this is prevented because the target must answer the missing CHAP_R key with a

Login reject with the "Missing Parameter" status.

For some of the authentication methods, a key specifies the identity of the iSCSI initiator or target for authentication purposes. The value associated with that key MAY be different from the iSCSI name and SHOULD be configurable (CHAP_N: see Section 12.1.3; SRP_U: see Section 12.1.2). For this reason, iSCSI implementations SHOULD manage authentication in a way that impersonation across iSCSI names via these authentication identities is not possible. Specifically, implementations SHOULD allow configuration of an authentication identity for a Name if different, and authentication credentials for that identity. During the login time, implementations SHOULD verify the Name-to-identity relationship in addition to authenticating the identity through the negotiated authentication method.

When an iSCSI session has multiple TCP connections, either concurrently or sequentially, the authentication method and

identities should not vary among the connections. Therefore, all connections in an iSCSI session SHOULD use the same authentication method, iSCSI name, and authentication identity (for authentication methods that use an authentication identity). Implementations SHOULD check this and cause an authentication failure on a new connection that uses a different authentication method, iSCSI name, or

authentication identity from those already used in the session. In

addition, implementations SHOULD NOT support both authenticated and unauthenticated TCP connections in the same iSCSI session, added either concurrently or sequentially to the session.

9.2.1. CHAP Considerations

Compliant iSCSI initiators and targets MUST implement the CHAP authentication method [RFC1994] (according to Section 12.1.3, including the target authentication option).

When CHAP is performed over a non-encrypted channel, it is vulnerable to an off-line dictionary attack. Implementations MUST support the use of up to 128-bit random CHAP secrets, 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.

An administrative entity of an environment in which CHAP is used with a secret that has less than 96 random bits MUST enforce IPsec

encryption (according to the implementation requirements in

Section 9.3.2) to protect the connection. Moreover, in this case, IKE authentication with group pre-shared cryptographic keys SHOULD NOT be used unless it is not essential to protect group members against off-line dictionary attacks by other members.

CHAP secrets MUST be an integral number of bytes (octets). A

compliant implementation SHOULD NOT continue with the login step in which it should send a CHAP response (CHAP_R; see Section 12.1.3) unless it can verify that the CHAP secret is at least 96 bits or that IPsec encryption is being used to protect the connection.

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:

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

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

c) 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.

d) 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.

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

When an iSCSI initiator or target authenticates itself to

counterparts in multiple administrative domains, it SHOULD use a different CHAP secret for each administrative domain to avoid propagating security compromises across domains.

Within a single administrative domain:

- A single CHAP secret MAY be used for authentication of an initiator to multiple targets.

- A single CHAP secret MAY be used for an authentication of a target to multiple initiators when the initiators use an

external server (e.g., RADIUS [RFC2865]) to verify the target’s CHAP responses and do not know the target’s CHAP secret.

If an external response verification server (e.g., RADIUS) is not used, employing a single CHAP secret for authentication of a target to multiple initiators requires that all such initiators know that target’s secret. Any of these initiators can impersonate the target to any other such initiator, and compromise of such an initiator enables an attacker to impersonate the target to all such initiators.

initiator when such risks are of concern; in this situation, it may be useful to configure a separate logical iSCSI target with its own iSCSI Node Name for each initiator or group of initiators among which such separation is desired.

The above requirements strengthen the security properties of CHAP authentication for iSCSI by comparison to the basic CHAP

authentication mechanism [RFC1994]. It is very important to adhere to these requirements, especially the requirements for strong (large randomly generated) CHAP secrets, as iSCSI implementations and

deployments that fail to use strong CHAP secrets are likely to be highly vulnerable to off-line dictionary attacks on CHAP secrets.

Replacement of CHAP with a better authentication mechanism is anticipated in a future version of iSCSI. The FC-SP-2 standard [FCSP2] has specified the Extensible Authentication Protocol Generalized Pre-Shared Key (EAP-GPSK) authentication mechanism

[RFC5433] as an alternative to (and possible future replacement for) Fibre Channel’s similar usage of strengthened CHAP. Another possible replacement for CHAP is a secure password mechanism, e.g., an updated version of iSCSI’s current SRP authentication mechanism.

9.2.2. SRP Considerations

The strength of the SRP authentication method (specified in

[RFC2945]) 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 Germain prime (of the form N = 2q + 1, where q is also prime) and the generator g is a primitive root of GF(N). In iSCSI authentication, the prime modulus N MUST be at least 768 bits.

The list of allowed SRP groups is provided in [RFC3723].

9.2.3. Kerberos Considerations

iSCSI uses raw Kerberos V5 [RFC4120] for authenticating a client (iSCSI initiator) principal to a service (iSCSI target) principal.

Note that iSCSI does not use the Generic Security Service Application Program Interface (GSS-API) [RFC2743] or the Kerberos V5 GSS-API security mechanism [RFC4121]. This means that iSCSI implementations supporting the KRB5 AuthMethod (Section 12.1) are directly involved in the Kerberos protocol. When Kerberos V5 is used for

authentication, the following actions MUST be performed as specified in [RFC4120]:

- The target MUST validate KRB_AP_REQ to ensure that the initiator can be trusted.

- When mutual authentication is selected, the initiator MUST validate KRB_AP_REP to determine the outcome of mutual authentication.

As Kerberos V5 is capable of providing mutual authentication,

implementations SHOULD support mutual authentication by default for login authentication.

Note, however, that Kerberos authentication only assures that the server (iSCSI target) can be trusted by the Kerberos client

(initiator) and vice versa; an initiator should employ appropriately secured service discovery techniques (e.g., iSNS; see Section 4.2.7) to ensure that it is talking to the intended target principal.

iSCSI does not use Kerberos v5 for either integrity or

confidentiality protection of the iSCSI protocol. iSCSI uses IPsec for those purposes as specified in Section 9.3.