|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: IKE and iSCSI AuthenticationDavid, I agree with most of what you said, but not comfortable with the Tape Application that you address, but it is NOT important that we agree on this at this time. I really did understand what it take to associate the iSCSI Initiator Name with the UserID. I said that an tight binding table was needed. I also said that you have to be sure that it is kept in sync with the Installations User/Password Database/Directory. You did not refute that, just attempted to trivialize the relationship table that needs to be built. We have never address this Table as part of iSCSI before, and it is important that everyone understands this, and that we understand how it is to be kept in sync with the installations User/Password Directory. As part of doing this, we need to really understand what directories prevent our use of iSCSI Node Names, and which permit it. We need to understand if it is possible to have more then one UserID associated with a single iSCSI Node Name, etc. The point is, this is all new information and has not been discussed, and no expert in UserID Directories have had a chance to tell us their thoughts. This needs to be completely understood (especially since it is not documented anywhere in our iSCSI Documents), and most folks on this Reflector did not have a clue about it. Discussions and thoughts about this is what I have been trying to get going. I would not like this to fade into the background until it is fully reviewed and commented upon. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136 Internet address: hufferd@us.ibm.com Black_David@emc.com@ece.cmu.edu on 08/30/2001 07:50:40 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: IKE and iSCSI Authentication Starting a new thread to try to roll up a number of related issues from the User vs. Machine Authentication thread and a few others. -- Concept of "user". This has been confusing due in part to lazy/sloppy use of terminology by yours truly. The term "machine" has been used to refer to IKE authentication that has a single identity associated with the network interface (i.e., IP address). Finer grain authentication at a higher level has been referred to as "user" authentication by analogy to remote access via ppp/l2tp/ipsec, where a "machine" is authenticated by IKE and a "user" is authenticated by ppp. For iSCSI, we do have a need to authenticate at a finer grain than one entity per network interface, but "user" is a poor choice of word for that. -- Need for finer grain authentication than "machine" As noted earlier, IKE starts up in response to the TCP SYN packet being queued for transmission to set up a TCP connection for iSCSI. IKE intercepts that packet and completes its its authentication and SA setup before allowing that packet to continue on its way (over the SA that was just set up). Hence IKE can't know what the iSCSI Initiator and Target names are. The usual result is that the IPsec implementation behind a single network interface has a single identity. We went to great efforts in iSCSI to allow multiple Initiators and Targets to share IP addresses, and hence if there's any authentication associated with those names, some other authentication mechanism is required that occurs at a later stage and higher level than IKE (i.e., iSCSI inband authentication). -- Need for authentication management A careful reader of RFC 2401 will note the ability to inject Name information into an IPsec SPD, and if one is careful about having Initiators or Targets that one wants to distinguish be associated with different OS user identities, this can be made to work when IPsec is on the same system as the Initiator or Target (it won't work with an outboard security gateway). This is not the best approach in many cases because it requires IKE keying material (a certificate or pre-shared key) per identity and these things are at best clumsy to administer. Due to the complexities involved in administering even the best IPsec systems, I expect to see deployments in which IPsec and IKE are simply not used, or the authentication is very coarse. One could load the same pre-shared key or certificate into multiple systems so that the IKE authentication only establishes that both systems are members of some "ok" group, and then another mechanism is used to determine who can actually access what - inband authentication provides that mechanism. The SRP mechanism is easy to set up in situations where one does not want to run IKE, and the other mechanisms are motivated by integration into existing scalable centrally managed authentication systems - Kerberos, CHAP (RADIUS), SPKM* (PKI). -- That "tape" example Obviously, I didn't explain this well, because nobody seems to understand it. Consider a SAN-accessible tape drive that is sequentially shared by multiple hosts for backup. To claim that the operating systems own the tape drive misses the point here - the multiple OSs will allow multiple backups from different systems to the same drive to start at the same time, and the result will be chaos. One plausible alternative view is that the SAN owns the tape drive, in which case authentication to the drive can be used to control who can access it when, and the backup application is the obvious entity to authenticate. Some backup applications have application-specific solutions to this problem that work among cooperating entities (i.e., each instance of the backup app knows that it has to ask permission) - requiring authentication can keep out the uncooperative entities that won't bother asking for permission. -- iSCSI names and authentication identities One could certainly use the same string as the iSCSI Initiator or Target name and the userid used to do inband authentication, but requiring that forces those strings into the existing authentication systems that we'd like to live with. The alternative of associating userids from those systems with iSCSI authentication information should be allowed to avoid forcing this. John complains mightily about the required translation, forgetting that there already has to be a table indicating which Initiators are allowed to access each Target; adding a userid column (or even a list) to this table is a minor addition for the benefit of being able to reuse the existing authentication infrastructure. Pierre's suggestion of issuing a certificate for every iSCSI initiator and target seems to prevent reuse of existing certificates that were already issued for some other reason, and that seems very wrong given the administrative difficulties already posed by certificate issuance and management. Mark's example of wanting to reuse his login ID on a local RADIUS server (which is highly unlikely to meet the uniqueness requirements of iSCSI Initiator and Target names) is a related situation in which this forcing causes problems. I'll stop here - I think I've caught most of the major points. Comments? Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------
Home Last updated: Tue Sep 04 01:03:49 2001 6315 messages in chronological order |