RE: iSCSI extension algorithms (was no subject)

["Martin, Nick (Server Storage)" <Nick.Martin@hp.com>]

David,

I agree that an implementation which implements or includes only
proprietary extension algorithm Z should be unacceptable.
I am only questioning whether this paragraph acomplishes that goal.
I am reading "offer" in the negotiation sense, not in the implemented
feature set sense.

Although it makes little sense to me for the target which is configured
with no CHAP secrets to "offer" CHAP during negotiation, I can accept it
in this situation.  I would prefer to see implementation of CHAP listed
as the requirement, rather than offering CHAP when it is not configured
to work.  

It seems now that it is not intended that to "offer" CHAP in negotiation
should be interpreted as an indication that CHAP is configured work.

I hope an implementation which can "offer" CHAP but does not implement
CHAP, or one which can "offer" CHAP but does not allow CHAP to be
configured by an administrator will also be unacceptable.  

I have no problem with your etiquette.  No need to apologize.  I am not
trying to drag this out.  I am now satisfied my concern has been aired
and will be considered.

Thanks,
Nick

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com] 
Sent: Wednesday, January 08, 2003 1:30 PM
To: Martin, Nick (Server Storage)
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI extension algorithms (was no subject)


Nick,

Sorry to be blunt/brusque, but this is an IESG requirement and hot
button - an implementation that offers only proprietary extension
algorithm Z without also offering something else is viewed as forcing
the counterpart to implement Z, and that will not be acceptable to the
IESG, period.

> I have always seen a big distinction between what is required to be 
> implemented, versus what is offered during negotiation.  We appear to 
> be mandating that a stroage administrator must not be allowed to 
> configure a target to allow authentication Z  (an extension) and no 
> other.  In the future it may be the case that Z is a site standard and

> no other is acceptable.

The fact that Z may be proprietary is what forces us across this line.
To achieve the effect you desire, the administrator could configure the
target to offer Z and CHAP *in that order* (making Z preferred) and then
configure no CHAP secrets or access to external CHAP verification (e.g.,
RADIUS) into the target.  If the site you envision is properly
configured, the initiators all accept Z and everything is fine.  An
initiator that makes the mistake of accepting CHAP fails to authenticate
as the target is configured so that all CHAP authentications fail.

Note that this requirement is being imposed *only* on non-standard
authentication methods.

Sorry,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 **NEW**     FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

-----Original Message-----
From: Martin, Nick (Server Storage) [mailto:Nick.Martin@hp.com]
Sent: Wednesday, January 08, 2003 1:21 PM
To: Julian Satran; Steve Bellovin; Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI extension algorithms (was no subject)


Julian and All,
 
The "MUST also be offered" is the part I have a problem with.  
 
I have always seen a big distinction between what is required to be
implemented, versus what is offered during negotiation.  We appear to be
mandating that a stroage administrator must not be allowed to configure
a target to allow authentication Z  (an extension) and no other.  In the
future it may be the case that Z is a site standard and no other is
acceptable.  
 
If I understand correctly, the intention is that one can not claim iSCSI
compliance without implementing (at least one of) the currently
specified methods. I think this is a poor way to state/enforce that
intention.
 
The administrator of the target should select the preferred and/or
acceptable authentication methods (from the list implemented by his
vendor) to be offered (allowed to be selected during negotiation) by
each target under his administration.  The same for initiators.  
 
We say other algorithms may be implemented and negotiated.  However, we
are now saying that an administrator may not decide to offer (allow)
neither of the current authentication methods in favor of something
else.  I think we are also implying targets and initiators must enforce
this.
 
The iSCSI spec has to this point avoided prescribing such restrictions
on administration.
 
Thanks,
Nick
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com] 
Sent: Wednesday, January 08, 2003 5:18 AM
To: Steve Bellovin; Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: 



The intent of the "offending" statement in 11.1 was to have a strong
player with a new method forcing everybody into it by not offering
anything else. 
I guess the phrasing was bad.  Simply removing None will not do it since
None may still remain a valid option if both parties agree: 

I would suggest the new phrasing to be: 

Private or public extension algorithms MAY also be negotiated for
authentication methods. Whenever a private or public extension algorithm
is offered, at least one of the authentication methods defined in this
document MUST also be offered as an option. 

Julo