iSCSI: The new security normative statements in 09

["Ofer Biran" <BIRAN@il.ibm.com>]

Following are the new security normative statements which we intend
to add in iSCSI version 09. They are result of the sync effort with
the security draft, the tunnel / transport mode discussion and the
SRP groups discussion in the security team.

For the mode statements - there is a clear preference for tunnel mode,
and at this point we have to put a MUST. Actually there was only one
supporter of transport mode (Saqib Jang) with the argument:
"to avoid folks playing 'marketing' games with positioning their
products as iSCSI compliant". This is not really a technical argument,
in anyway, an implementation that doesn't provide IKE, ESP in tunnel
mode with 3DES in CBC mode... will not be iSCSI compliant, no matter
what marketing people say.

======================================================================
10.2 In-band Initiator-Target Authentication

(SRP)
"As described in [RFC2945], N is required to be a Sophie-German prime
(of the form N = 2q + 1, where q is also prime) and the generator g is
a primitive root of GF(n). For use in iSCSI authentication, the prime
modulus N MUST be at least 768 bits.

Upon receiving N and g from the Target, the Initiator MUST verify that
they satisfy the above requirements (and abort the connection otherwise).
This verification MAY start by trying to match them with a well-known
group that satisfies the above requirements. SRP well-known groups are
given in [SEC-IPS]."


10.3.1 Data Integrity and Authentication

"An iSCSI compliant initiator or target MUST provide data integrity and
authentication by implementing IPsec [RFC2401] with ESP in tunnel mode
[RFC2406] with the following..."

"At the high speeds iSCSI is expected to operate, a single IPsec SA could
rapidly cycle through the 32-bit IPsec sequence number space.
In view of this, iSCSI implementation operating at speeds of 1 Gbps or
less MAY implement the IPsec sequence number extension [SEQ-EXT].
Implementation operating at speeds of 10 Gbps or faster SHOULD implement
the sequence number extension."


10.3.2 Confidentiality

"An iSCSI compliant initiator or target MUST provide confidentiality by
implementing IPsec [RFC2401] with ESP in tunnel mode [RFC2406] with
the following..."

"DES in CBC mode SHOULD NOT be used due to its inherent weakness."


10.3.3 Security Associations and Key Management

"Authentication, security association negotiation and key management MUST
be provided by implementing IKE [RFC2409] using the IPsec DOI [RFC2407]
with the following iSCSI specific requirements:

  - Peer authentication using a pre-shared key MUST be supported, and
  certificate-based peer authentication using digital signatures MAY be
  supported. Peer authentication using the public key encryption methods
  outlined in IKE's sections 5.2 and 5.3[7] SHOULD NOT be used.

  - When digital signatures are used to achieve authentication, an IKE
  negotiator SHOULD use IKE Certificate Request Payload(s) to specify the
  certificate authority. IKE negotiators SHOULD check the pertinent
  Certificate Revocation List (CRL) before accepting a PKI certificate
  for use in IKE's authentication procedures.

  - Both IKE Main Mode and Aggressive Mode MUST be supported. IKE main
  mode with pre-shared key authentication method SHOULD NOT be used when
  either the initiator or the target uses dynamically assigned IP addresses
  (while pre-shared keys in many cases offer good security, situations
  where dynamically assigned addresses are used force the use of a group
  pre-shared key which creates vulnerability to man-in-the-middle attack)."

"Manual keying MUST NOT be used since it does not provide the necessary
rekeying support."

======================================================================

 Regards,
   Ofer

Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
biran@il.ibm.com  972-4-8296253