RE: iSCSI extension algorithms (was no subject)

[Black_David@emc.com]

Bill,

> On Thu, 16 Jan 2003 Black_David@emc.com wrote:
> 
> > 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.
> 
> But without administrative action (either to add CHAP names and
> passphrases or to configure a RADIUS server), how can we offer CHAP?
> 
> To paraphrase Julian's other message, are we trying to make interoperable
> implementations, or interoperable administators? If the adminsitrator
> won't be interoperable, what should we do?

As long as the administrator has made explicit choices that lead to
lack of interoperability, the results are her own fault.  The issue
is ensuring that implementations don't default to lack of interoperation.
 
> My concern is that the text we're talking about would make our
> implementation not compliant.
> 
> The way we do security is you tie an authentication entry (which matches
> an AUTH_MIB entry) describing an initiator to a target; that permits an
> initiator (or initiators) with a matching name to use the target, if
> security succeeds. The list of security methods the target will accept is
> the union of security credentials in the auth entry. If there's a CHAP
> entry, the target will do CHAP. If there's a None entry, we'll skip
> security. If there's a Kerberos entry, we'll do Kerberos. If X-com.bar.foo
> gets added and there's a X-com.bar.foo entry, we'll do X-com.bar.foo. We
> of course then look at what the initiator wants to do, and we go with the
> first one the initiator wants that is acceptable to us.
>  
> The point is that we won't do any form of security, neither ones listed in
> the iSCSI draft nor ones added later, unless the administrator
> specifically told us to.

That sounds like "explicit administrative action" to me.
 
> So what do we do if the only credential in the entry is for X-com.bar.foo?
> If it's there, it's there because the administrator put it there. If
> nothing else is there, then the admin chose not to add anything else. We
> can't do CHAP or anything else, since we don't have the credentials.
> 
> Would we be violating the spec if we didn't do CHAP in that case?

I believe that would be ok.  Let's assume the implementation ships with
no secrets - in the absence of administrative action, it only offers
"None", and treats the configuration of secrets as a explicit
administrative actions that enable the corresponding algorithms to be
offered.  The default of "None" is fine, as no extension algorithm
is offered, so the "SHOULD offer CHAP" requirement does not apply.
An extension algorithm can only be offered in this situation based
on the "explicit administrative action" of configuring a secret for
it, and hence there's no requirement to offer anything else.

Now, if someone took that implementation and configured only an
X-com.bar.foo secret as an example account and shipped the result as
product, that would be a problem because the result defaults to
the extension algorithm.  This is avoidable by configuring both
an X-com.bar.foo secret and a CHAP secret for the example account.

And to head off the next question, if the advocates of X-com.bar.foo
authentication want to get out from under the requirement in the
previous paragraph, they make the effort to have the IETF standardize
that authentication method.  If that succeeds, and the algorithm is
assigned something other than an X- key, none of this discussion
applies to it at that point.

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