IP Storage (ips) WG Meeting Minutes - FINAL Wednesday, July 12, 2006 - 1510-1610 Montreal, Quebec, Canada ----------------------------------- Administrivia, agenda bashing, draft status review, etc. - 15 min David L. Black, EMC (chair) Blue sheets Note Well Draft status - projected from I-D tracker - Lots of published RFCs - iSER and DA drafts are paused waiting for the RDDP drafts that they depend on. The RDDP drafts are starting to move. - iSNS MIB has received MIB Doctor review, and a revised draft is in preparation (significant work is involved) - Implementers Guide is in WG, but not much activity. Likely to be WG Last Called before next IETF. Most important material in that draft involves task management operations that may affect more than one task (e.g., ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET RESET) - please review this material. Not on today's agenda - Node Architecture draft. Will be worked on today. Milestones - Dec 2006 for Node Architecture Draft - Jan 2007 for Implementers Guide Draft - Both appear reasonable. WG chair will be pushing ISER, DA, and iSNS MIB drafts through the process. iSCSI X#NodeArchitecture Key: Dave Wysochanski, Network Appliance - 30 min (draft-ietf-ips-iscsi-nodearch-key.txt) WG Discussion: - Key should be allowed only after Authentication. Revise draft to impose this restriction - Make sure it's a regular-size text key (not a big one, like the one used for the large numbers involved in some authentication methods). - "protocol logic": crucial point is that **behavior** is the same independent of presence, absence, or content of the key. Add or revise text to make this point. - Document behavior of RFC 3720-compliant implementation that receives this new key and does not understand it, and how the other side deals with the resulting response. - "configure different levels" text needs to be rephrased to be specific that the amount of detail is what changes across levels. - Align ability to configure amount of details with "SHOULD NOT" in Section 1.2 about administrative setting of key value. (the prior "SHOULD NOT" appears to conflict with this "SHOULD"). - Double-check there is a 3720-format definition of the key, including description clearly in the draft. - Make the examples phony (no real company names), and remove the double quotes ("), as they don't appear on the wire. - Spaces are forbidden in text strings. See RFC 3720, Section 5.1, and feel free to ask on the list for options on how to deal with this. iSCSI Security Mechanisms: WG Members - time remaining (if any) The IETF Security Area has requested that IETF Working Groups plan to transition away from usage of MD5. iSCSI CHAP currently uses MD5 in a fashion not directly threatened by the hash collision results known for MD5. If time is available in the meeting, it will be used to discuss what to do instead, as using a different hash with CHAP is not the only option. Above description is copied verbatim from Dallas agenda. There are two other related concerns: a) The Kerberos support in iSCSI is frowned upon by Kerberos experts. iSCSI Kerberos is not GSSAPI-based, and hence can't be used with GSSAPI-only Kerberos implementations. b) The SPKM-1 and SPKM-2 methods are arguably obsolete. SASL is a potential means of addressing all of these problems: - SASL has and/or will have methods based on SHA-256, the next hash of choice (according to the IETF Security Area) - SASL has GSSAPI-based Kerberos support that has been designed by Kerberos experts - SASL has an SPKM-3 method. The approach would be to add SASL methods to iSCSI by doing mapping the SASL tokens into iSCSI and providing authentication mechanism names (e.g., the SASL mechanism is negotiated by iSCSI as the SASL- mechanism). These would be additions - the current must-implement CHAP mechanism is not broken, and would not be removed. There may be a draft forthcoming that will add SASL to iSCSI - the sense of the room is that this would be a good thing to do, although it is not of immediate urgency. Open Mike - Roger Cummings noted that RFC 3720 is based on SAM-2; SAM-3 has appeared resulting in SCSI work in T10 that requires SAM-3. One example is encrypting tape drive work in T10 that relies upon a new well-known logical unit definition that is only in SAM-3. This is a reason to work on updating iSCSI to SAM-3. The WG chair commented that such an update would be backwards compatible, and would require the active involvement of a SCSI guru to ensure that the interactions with the SAM-3 specification are correct.