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 h0FJlWw07035 for ips-outgoing; Wed, 15 Jan 2003 14:47:32 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lion.ninthwonder.com (lion.ninthwonder.com [151.199.66.147]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h0FJlSW07029 for ; Wed, 15 Jan 2003 14:47:28 -0500 (EST) Received: by lion.ninthwonder.com (Postfix, from userid 1021) id CD9083070C; Wed, 15 Jan 2003 14:47:27 -0500 (EST) Date: Wed, 15 Jan 2003 11:42:57 -0800 (PST) From: Bill Studenmund X-X-Sender: To: Julian Satran Cc: , Subject: RE: iSCSI extension algorithms (was no subject) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk 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