|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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. 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. <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. <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. 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 >
Home Last updated: Tue Sep 04 01:06:54 2001 6315 messages in chronological order |