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

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

Joshua,

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Joshua Tseng
> Sent: Monday, October 02, 2000 5:27 PM
> To: ips@ece.cmu.edu
> Subject: RE: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]
>
>
> Doug,
>
> >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.
>
> What about for proxies?  A proxy that routes storage data between IP
> addressing domains will need the original text name to resolve it to
> a different IP address in a different address domain.  NAT is quite
> common nowadays, and I would think iSCSI needs to preserve mechanisms
> that allow it to route between IP address domains.

Sorry, but that is not how a NAT works.  Yes NAT represents a problem only
from the perspective of the target.  The target should know what goes where
and who is authorized.  Once the client pokes through the NAT and identifies
in an opaque manner, end of problem.  A NAT does not use names, however your
LDAP server may provide a name to your browser for the purpose of finding
the gateway.  This name may only resolve locally within your enterprise and
not publicly as well.  Should you be attempting to connect over the Big I to
your drives, then you will need to access the providers authentication
database that would include the mapping you desire.  This mapping would not
be text but rather binary information.  The retrieval of this information
may be symbolic but those symbols would never touch the SCSI layer.

> As far as the security, is your problem with the ASCII text format
> itself being readable by a human?  If so, I see no difference between
> using text format compared to "asdj2342zssd" (or whatever), in
> addressing a remote LUN, as far as security is concerned.  On the
> other hand, if you believe ALL interactions between initiator & target
> must reference an SPI found in a secure remote authentication server,
> then IMO you are placing severe and unreasonable deployment
> requirements on the user. It reminds me of the LANE architecture
> in ATM--quite unscalable and burdensome.

Placing the authentication server within the SCSI transport does not improve
the ability to scale.  If anything, the authentication will occupy resources
needed for the retrieval of data.  Let a server specifically designed to
provide secure connections and access to the client and server perform that
function.  It makes no sense to conclude it becomes difficult to delegate
this function to a server already up and running.

> <snip...snip>
>
> >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?
>
> I see no way around a local authentication database in the target.
> If the target doesn't track which initiators can do what, then it
> will have to ask the remote authentication server, which affects
> performance.

Local?  You would use the local LDAP server to communicate with the SSP LDAP
server.  What problem do you see?  Each server would control the domain of
each entity.  Sounds like a good thing.  Only the Authentication server
would need to expose their IP via DNS and then emit private IPs to ensure
the load is balanced and the correct alternative routes are assigned.  You
should not trust that to DNS.

> <snip...snip>
>
> >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.
>
> I see no reason why a DNS lookup would be more costly or than
> an exchange of shared secrets with the authentication server.  If
> anything, the shared secret exchange is more costly, since
> it must be secured.

Yes, but not by the SCSI equipment.  Expensive for a seldom used server.
Not at all expensive for the SCSI transport.  The SCSI transport remains
dead simple.  Adding an authentication server to the SCSI transport together
with a naming database is not simple.  Just the opposite.

Doug


> Josh
>
> -----Original Message-----
> From: Douglas Otis [mailto:dotis@sanlight.net]
> Sent: Monday, October 02, 2000 2:47 PM
> To: Daniel Smith
> Cc: julian_satran@il.ibm.com; ips@ece.cmu.edu
> Subject: RE: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]
>
>
> 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
> >
>