RE: iSCSI extension algorithms (was no subject)

[Black_David@emc.com]

It is also the case that in the absence of explicit administrative

action, an implementation MUST NOT default to extension

algorithms or to extension algorithms plus "None", and that in

the absence of explicit administrative action, CHAP SHOULD be

offered if an extension algorithm is offered.

 

Those are missing from Bill's proposed text, and are necessary.

 

Thanks,

--David

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, January 16, 2003 1:31 AM
To: Bill Studenmund
Cc: Black_David@emc.com; ips@ece.cmu.edu
Subject: RE: iSCSI extension algorithms (was no subject)

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