|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI extension algorithms (was no subject)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 ----------------------------------------------------
Home Last updated: Thu Jan 16 19:19:05 2003 12198 messages in chronological order |