|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] FW: IPS-All: Reminder - Security draft last call ends Monday, July 1 at 8am ESTOne more
round of lining up the iSCSI and IPS Security drafts.
--David
-----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, June 30, 2002 7:27 AM To: Ofer Biran Cc: bernard_aboba@hotmail.com; Black_David@emc.com; Elizabeth Rodriguez Subject: Re: IPS-All: Reminder - Security draft last call ends Monday, July 1 at 8am EST see comments in text - Julo
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 biran@il.ibm.com 972-4-8296253 Please respond to Elizabeth Rodriguez <elizabeth.g.rodriguez@123mail.net> Sent by: owner-ips@ece.cmu.edu To:
ips@ece.cmu.edu
Home Last updated: Mon Jul 01 16:18:49 2002 11048 messages in chronological order |