RE: iSCSI extension algorithms (was no subject)

["Julian Satran" <Julian_Satran@il.ibm.com>]

Nick,

An administrator can configure them
by fixing the ordering.
The point that Steve Belovin was making
is that you should not allow a proprietary extension to force a "me
or None" solution and claim compliance.

Julo

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

08/01/03 20:20

To	Julian Satran/Haifa/IBM@IBMIL, "Steve Bellovin" <smb@research.att.com>, <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