Subject: FW: IPS-All: Reminder - Security draft last call ends Monday, Jul y 1 at 8am EST

From: [email-masked]
Date: Mon, 1 Jul 2002 11:43:33 -0400

One more round of lining up the iSCSI and IPS Security drafts.
 
--David
 
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Sunday, June 30, 2002 7:27 AM
To: Ofer Biran
Cc: [email-masked]; [email-masked]; Elizabeth Rodriguez
Subject: Re: IPS-All: Reminder - Security draft last call ends Monday, July
1 at 8am EST

see comments in text  - Julo 

	Ofer Biran 

06/30/2002 11:43 AM 

        To:        Elizabeth Rodriguez <[email-masked]>,
[email-masked], [email-masked], Julian
Satran/Haifa/IBM@IBMIL 
        cc:         
        From:        Ofer Biran/Haifa/IBM@IBMIL 
        Subject:        Re: IPS-All: Reminder - Security draft last call
ends Monday, July 1 at 8am EST Link
<Notes:///C225670D0041573F/38D46BF5E8F08834852564B500129B2C/3719071310B5B10A
C2256BE50077269A>  

These comments are from mandatory statements sync check 
I made with the iSCSI draft: 

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

2.3.1.  Transforms 
"When ESP is utilized, per-packet data origin authentication, integrity 
and replay protection MUST be used." 

In iSCSI, the replay protection is MUST implement (not MUST use): 
7.3.1 Data Integrity and Authentication 
"The ESP anti-replay service MUST also be implemented." 

(I'm not sure if the security or iSCSI should be changed ? I think the 
recent tendency was not to impose IPsec requirements unless they are 
justified by IPS uniqueness compare to other IPsec usage scenarios) 

+++ I assume security draft will be fixed +++ 
====================== 

2.3.3.  IKE 
"Conformant IP block storage security implementations MUST support IKE 
Main Mode and SHOULD support Aggressive Mode." 

in iSCSI both MUST be supported: 
7.3.3 Policy, Security Associations and Key Management 
"Both IKE Main Mode and Aggressive Mode MUST be supported." 

(this should be changed in iSCSI - was decided on last 
IETF Minneapolis)   

+++ will fix in iSCSI +++ 

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

2.3.3.  IKE 
"iSCSI security implementations SHOULD support 
the ID_USER_FQDN Identity Payload;" 

in iSCSI it's MAY: 
7.3.3 Policy, Security Associations and Key Management 
"ID_USER_FQDN MAY be supported." 

(either should be changed for sync) 

+++ will fix in iSCSI +++ 
====================== 
2.4.1.  CHAP 
"If CHAP is used with secret smaller than 96 bits, then IPsec encryption 
(according to the implementation requirements in [iSCSI] section 7.3.2) 
MUST be used to protect the connection. Moreover, in this case IKE 
authentication with group pre-shared keys MUST 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." 

I suggest to change this according to the last iSCSI text that separates 
the administration requirements (first par.) and the implementation 
requirements (second par.): 

7.2.1 CHAP Considerations 
"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 7.3.2 
Confidentiality) to protect the connection. Moreover, in this case IKE 
authentication with group pre-shared keys SHOULD NOT be used unless 
it is not essential to protect group members against off-line dictionary 
attacks by other members. 

A compliant implementation SHOULD NOT continue with the login step in 
which it should send a CHAP response (CHAP_R - Section 10.5 Challenge 
Handshake Authentication Protocol (CHAP)) unless it can verify that 
either the CHAP secret is at least 96 bits, or that IPsec encryption 
is being used to protect the connection." 

+++ I assume security draft will be fixed +++ 
====================== 
2.4.2.  SRP 
"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 included in Appendix A." 

This should be changed as iSCSI was changed according last consensus 
that no one will really implement these checks: 
7.2.2 SRP Considerations 
"Upon receiving N and g from the Target, the Initiator MUST verify 
that they match a well-known group that satisfies the above 
requirements and abort the connection if they do not match. 
Well- known SRP groups are provided in [SEC-IPS]." 

+++ I assume security draft will be fixed +++ 
====================== 

  Regards, 
    Ofer

Ofer Biran
Storage and Systems Technology   
IBM Research Lab in Haifa   
[email-masked]  972-4-8296253

Please respond to Elizabeth Rodriguez <[email-masked]> 

Sent by:        [email-masked] 

To:        [email-masked] 
cc:        [email-masked] 
Subject:        IPS-All: Reminder - Security draft last call ends Monday,
July 1 at 8am EST 

Just a reminder to all to get your last call comments on the security draft
in.
The cutoff is Monday July 1 at 8am EST

Thanks,

Elizabeth

---

From: Paul Koning <[email-masked]>
Date: Mon, 1 Jul 2002 15:27:43 -0400

> I made with the iSCSI draft: 

Because of the Bellovin attack on encryption-only ESP, I believe that
the first of the two statements is the right one.

There's a lot of argument that integrity should be mandatory in ESP
across the board.  The reason why it currently isn't (at least as far
as I understand from Steve Kent) is that integrity in the IPsec layer
is superfluous if cryptographic integrity is provided at a higher
layer.  That case doesn't apply in IPS, so the risk of Bellovin's
attack is real.

    paul