RE: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]

["Douglas Otis" <dotis@sanlight.net>]

Daniel,

<snip>
> I'll reply to this piece-by-piece as there seem to be a lot of
> misconceptions.
>
> (On a side note, I haven't seen any alternative proposals put
> forward to the
> URL scheme as noted.  If things stay this way, then I'll put it forward as
> an Internet-Draft.)
>
> Okay, off we go.
>
> Douglas Otis wrote:
> >
> > If you wished to crack data being sent via IP, could you ask
> for a better
> > tag of such information- scsi://<domain-name>[/modifier] being
> sent in clear
> > text down the same connection?  Of course, the same is true for login as

You base this comment assuming there is no other means.  There is no reason
for sending the text equivalent of the address within the transport.  No
equipment will require a text name for routing or delivery. Adding it to the
SCSI transport weakens security.

> <domain-name> will always be sent "in the clear" at some point on the
> network.  There's not a lot we can do about that.  The IP address will
> always be visible in all packets.  (Insert comments here about
> why VPNs are
> a good thing here....)

Again, this is not true.  Again you assume that somehow sending a name is
required.  It is not. Communication to an authentication server could be
completely secure with no clear text.  Would you expect otherwise?

> In an SSL link, or IPsec the [/modifier] part will be encrypted.  Indeed,
> whenever security is tight, the [/modifier] will only be sent after
> clearance is granted.
>
> Why?

<snip>

> > well.  Here again "who, what, and where" are nicely presented in easy to
> > read form.  Neither SCSI clients nor servers are likely able to
> authenticate
> > independently or retain textual information.  Both the client and server
> > should depend on some outside database.  This compromise in security was
>
> If security is needed, then security is needed and there are no
> short cuts!
> Whether stored locally or remotely, that information needs to be
> somewhere,
> and securely accessible too.

There is just being sloppy.  Defer these parameters to a better designed
server and thus keep the transport layer clean.

>
> > done to eliminate an IP selection option but then a textual means of
> > including IP was included to ensure all modes of operation
> remain.  Rather
> > than using a secure and opaque means to establish a connection using an
> > independent means of authenticating on a different connection,
> the entire
> > function was included in this all encompassing draft.  This was
> not a good
> > choice in my view.
>
> There is no requirement that only the Initiator and Target MUST
> authenticate
> between /themselves/ only.  This may be desirable (in case the
> authentication database machine goes down.) There are many papers
> written on
> this subject; for a simple introduction, see "Secure Distributed
> Computing",
> Sci. Am., Nov 1994 pp72--76.  This will give you an idea of what
> the minimum
> requirements are in an open network authentication realm.

Once you allow IPv4 or 6 within URL target naming conventions, it is odd to
suggest that this scheme affords protection from changes to these standards.
There are many means to guard against a server failure besides leaving the
front door open.  This would suggest targets will contain an entire
authentication database.  What protocol would exchange this information in a
consistent fashion.  Perhaps LDAP?

> > By creating a separate draft to define an authentication database access
> > (LDAP structures), options remain possible without impact on
> the transport
> > specification.
>
> URLs have very little impact on the transport.  The iSCSI draft
> just handles
> arbitrary length text strings to identify resources---and that's all it
> cares about.  The only time interpretation of this is requred is for
> 3rd-party commands, when we don't have a choice about it---and technically
> the transport still doesn't care about it.  We DO want it
> standardized.  We
> DON'T want it tied to the transport.  In 2003 when iSCSIv5 over SCTP with
> Microsoft Active Super Directory v3 running over IPv8 on
> terrabit-RS232, the
> naming scheme should still be handled by the transport.

You have indeed tied it to the SCSI transport with the use of IP text.  You
could remove all such information from the spec and thus ensure no future
conflicts.  Have the authentication process do the mapping and then nothing
in the SCSI transport gets touched or exposed.  Would you wish to go back
and make changes to the transport spec to allow a means for target mapping
with additional attributes?  By planting this information within the
transport spec ensures extensive changes as time marches.  I seriously doubt
that IPvX will have anything to do with any of these changes.

> >                 The only aspect of authentication within the transport
> > should be a cookie.  Authentication provides access at some IP
> and port or
>
> Please forgive my ignorance, but isn't a cookie an arbitrary length text
> string (or can be mapped to and from an arbitrary length text string).
> Cookies as /constant/ entities is an extremely bad idea.  That's why we
> don't recommend it.  Okay, cookies are really small delicious disks,
> sometimes with chocolate chips---what do you mean by cookie?

It would be a binary digest of shared secrets good for leased use derived
from the authentication server.  I think you could use a few more chips in
your cookie however.  The means of fixing the spec is simply the removal of
text based mapping.  Requiring DNS lookup should be fun.  How many seconds
would you wait for a response?  What if it is required to then authenticate
with this third party?  Now how long would you wait then?  What a bad idea
to place this as a part of the real time operation of a SCSI.  I know, it is
only optional...  Then get rid of the option and specify a better means that
does not include the SCSI transport.  Sending these names in text is broken.
Fix it by removing it from the transport specification.

<snip>

Doug

> Daniel Smith.
>
> [Mmm.  Cookies.]
> --
> IBM Almaden Research Center, 650 Harry Road, San Jose, CA 95120-6099, USA
> K65B/C2 Phone: +1(408)927-2072 Fax: +1(408)927-3010
>