Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id h0G6VQK08939 for ips-outgoing; Thu, 16 Jan 2003 01:31:26 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h0G6VJW08934 for ; Thu, 16 Jan 2003 01:31:23 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0G6VClK030784; Thu, 16 Jan 2003 07:31:12 +0100 Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0G6VBEs212828; Thu, 16 Jan 2003 07:31:11 +0100 In-Reply-To: To: Bill Studenmund Cc: Black_David@emc.com, ips@ece.cmu.edu Subject: RE: iSCSI extension algorithms (was no subject) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 From: "Julian Satran" Message-ID: Date: Thu, 16 Jan 2003 08:31:09 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 16/01/2003 08:31:11, Serialize complete at 16/01/2003 08:31:11 Content-Type: multipart/alternative; boundary="=_alternative 0023677FC2256CB0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0023677FC2256CB0_= Content-Type: text/plain; charset="US-ASCII" Sorry Bill - "excuse" does not appear in the standard terms RFC. I will try to find some else. Julo Bill Studenmund 15/01/03 21:42 To Julian Satran/Haifa/IBM@IBMIL cc , Subject RE: iSCSI extension algorithms (was no subject) On Wed, 15 Jan 2003, Julian Satran wrote: > please have a look at the text on my site (it is out there for a while). > It says it all. Julo Ok, I looked at it, and it had text that was in the thread: Private or public extension algorithms MAY also be negotiated for authentication methods. Whenever a private or public extension algorithm is offered, the implementer MUST ensure that CHAP is listed as an alternative unless the setting is done by explicit administrative action Furthermore with private and public extensions "None" MUST NOT appear as an additional choice without explicit action by the administrator. The concern I have with that text is it doesn't differentiate between offering options to the admin and then offering negotiation choices to the other side of the login. It mushes them together, and as such becomes unclear. We're telling the initiator and the target what they MUST mention, when it strikes me that (shout is to the general audience, not specifically Julian) WE SHOULD ONLY OFFER/ACCEPT AUTH METHODS WE HAVE SECRETS FOR. If you don't have a secret for it, you shouldn't offer/accept it. We hit this idea clearly a few lines above this text, when we say, "Authentication is not mandatory to use but MUST be supported by the target and initiator." The most sensible thing would be to extend that to authentication methods; CHAP is not mandatory to use, but it MUST be supported by the target and initiator. But the text above says that you should offer CHAP as an option unless explicitly told otherwise. That's not the same thing. Say you (an initiator or target) neither have been told not to do CHAP nor have you been given any CHAP secrets. By the text above, you MUST offer CHAP, but you don't have any secrets to back it up, so what in the h*ll is going to happen? It won't work, we knew it wouldn't work, and it was silly to offer it initially. I am concerned that as long as we try to enforce things at the negotiation offer/accept stage, we will end up with a spec that either is clumsy, or is ignored. How about this for a replacement paragraph (I'm including the preceeding paragraph for clarity): The initiator and target MUST implement CHAP. All other authentication methods are OPTIONAL. Private or public extension algorithms MAY also be negotiated for authentication methods. A target or initiator implementation that supports an extention algorithm is still bound by the above CHAP requirement, and MUST offer CHAP as a configurable authentication option to the administrator. Support for an extension algorithm may NOT be used as an excuse to not implement CHAP. This text very bluntly states that you can't get around supporting CHAP, but we still leave it to the administrator to choose what authentication methods are in use; we don't set policy. Thoughts? Take care, Bill --=_alternative 0023677FC2256CB0_= Content-Type: text/html; charset="US-ASCII"
Sorry Bill - "excuse" does not appear in the standard terms RFC. I will try to find some else. Julo

Bill Studenmund <wrstuden@wasabisystems.com>

15/01/03 21:42

To	Julian Satran/Haifa/IBM@IBMIL
cc	<Black_David@emc.com>, <ips@ece.cmu.edu>
Subject	RE: iSCSI extension algorithms (was no subject)

On Wed, 15 Jan 2003, Julian Satran wrote: > please have a look at the text on my site (it is out there for a while). > It says it all. Julo Ok, I looked at it, and it had text that was in the thread: <text> Private or public extension algorithms MAY also be negotiated for authentication methods. Whenever a private or public extension algorithm is offered, the implementer MUST ensure that CHAP is listed as an alternative unless the setting is done by explicit administrative action Furthermore with private and public extensions "None" MUST NOT appear as an additional choice without explicit action by the administrator. </text> The concern I have with that text is it doesn't differentiate between offering options to the admin and then offering negotiation choices to the other side of the login. It mushes them together, and as such becomes unclear. We're telling the initiator and the target what they MUST mention, when it strikes me that (shout is to the general audience, not specifically Julian) WE SHOULD ONLY OFFER/ACCEPT AUTH METHODS WE HAVE SECRETS FOR. If you don't have a secret for it, you shouldn't offer/accept it. We hit this idea clearly a few lines above this text, when we say, "Authentication is not mandatory to use but MUST be supported by the target and initiator." The most sensible thing would be to extend that to authentication methods; CHAP is not mandatory to use, but it MUST be supported by the target and initiator. But the text above says that you should offer CHAP as an option unless explicitly told otherwise. That's not the same thing. Say you (an initiator or target) neither have been told not to do CHAP nor have you been given any CHAP secrets. By the text above, you MUST offer CHAP, but you don't have any secrets to back it up, so what in the h*ll is going to happen? It won't work, we knew it wouldn't work, and it was silly to offer it initially. I am concerned that as long as we try to enforce things at the negotiation offer/accept stage, we will end up with a spec that either is clumsy, or is ignored. How about this for a replacement paragraph (I'm including the preceeding paragraph for clarity): <text> The initiator and target MUST implement CHAP. All other authentication methods are OPTIONAL. Private or public extension algorithms MAY also be negotiated for authentication methods. A target or initiator implementation that supports an extention algorithm is still bound by the above CHAP requirement, and MUST offer CHAP as a configurable authentication option to the administrator. Support for an extension algorithm may NOT be used as an excuse to not implement CHAP. </text> This text very bluntly states that you can't get around supporting CHAP, but we still leave it to the administrator to choose what authentication methods are in use; we don't set policy. Thoughts? Take care, Bill
--=_alternative 0023677FC2256CB0_=--