RE: iSCSI extension algorithms (was no subject)

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Sat, 11 Jan 2003, Julian Satran wrote:

> David,
>
> What I wanted to convey is not a default action but an "ability to
> configure" because I thing that this is what we are after. If the
> administrator is not forced in configuring it with only the new
> auth-method then we are fine.
> I will try again tomorrow (too late in the weekend today :-)).

Julian,

I think you and I are in agreement on this. If I may suggest one way
around the difficulty is to not use the word "offer", since there are
really two different steps where an offer is made. Or to figure out some
way to differentiate the two different cases.

One "offering" is what the initiator offers to the target, or what a
target is configured to accept. I personally believe that this offering is
100% under the control of the administrator, and we should leave it that
way. If an administrator chooses to only use method X, so be it. She or he
may well loose, but choices have consequences.

Put another way, the above "offering" is 100% the domain of administrative
policy. An initiator or target should "offer" what the administrator
configured.

The other "offering," which is the one the IESG really cares about, is the
one where the administrator goes to configure what security the initiator
will offer or the target will accept. My belief is that at THIS step we
want all implementations to offer the administrator the option to use CHAP
as described in the spec. Also, it is my understanding of the MUST
surounding CHAP that if you don't offer CHAP at this point (as an option
for the administrator), you aren't living up to the RFC.

By differentiating the two cases, we get what we and the IESG wants, and
we have something that is easy and clear to implement.

Take care,

Bill