|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI - Change - Login/Text commands with the binary stage codeOk, I did get confused. I was thinking about packet authentication (ie HMAC-SHA1) not authentication methods (ie CHAP) Thank you for the clarification Bill -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Thursday, August 30, 2001 12:46 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - Change - Login/Text commands with the binary stage code It may decide to authenticate. This is an end-to-end authentication between two iSCSI entities not necesarily equivalent to the IPSec end-point. Julo "Bill Strahm" <bill@Sanera.net> on 30-08-2001 21:49:01 Please respond to "Bill Strahm" <bill@Sanera.net> To: Julian Satran/Haifa/IBM@IBMIL cc: "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu> Subject: RE: iSCSI - Change - Login/Text commands with the binary stage code Ok, I am confused here (or maybe it is just a lag effect for me) I thought we had decided in Irvine to use IPsec/IKE to negotiate security. So basically the process is this 1) Administrator makes several entries into a Security Policy Database 2) An iSCSI initiator attempts to send a TCP-SYN packet to a target machine 3) The IPsec packet filter detects this packet, realized there isn't a security association for it, and asks the Security Policy Database what to do about it 4) The security Policy Database may determine that an IPsec SA needs to be established so tells IKE to negotiate with the remote peer 5) An IKE negotiation proceeds until either it succeeds or fails 6) If it fails, packets are dropped 7) If it succeeds, the negotiated SAs are pushed to the IPsec packet filters 8) The origional TCP-SYN packet is now sent out under the IPsec SA that was negotiated. Now under this scenario there is no need for iSCSI to negotiate security at all. I DO now see the need to include an iSCSI Login phase that includes passing user identities across so targets and initiators can identify themselves, but this is over a secure link (see the above discussion) so I can just put ID= Bills-iSCSI-Initiator PW=BetYouCantGuessIt and the link will secure it for me... Bill Sanera Systems Inc. -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Wednesday, August 29, 2001 2:40 PM To: ips@ece.cmu.edu Subject: Re: iSCSI - Change - Login/Text commands with the binary stage code Steve, Implement and use are different terms. An administrator might set it up not to use security under specific conditions. Julo Steve Senum <ssenum@cisco.com>@ece.cmu.edu on 30-08-2001 00:12:28 Please respond to Steve Senum <ssenum@cisco.com> Sent by: owner-ips@ece.cmu.edu To: ietf-ips <ips@ece.cmu.edu> cc: Subject: Re: iSCSI - Change - Login/Text commands with the binary stage code Julian, In the following section: If the initiator decides to forego the SecurityNegotiation stage it issues the Login with the CNxSG set to LoginOperationalNegotiation in the current stage and the target may replay with a Login Response indicating that it is unwilling to accept the connection without SecurityNegotiation and terminate the connection. This seems contrary to the requirement to implement authentication (at least AuthMethod=SRP). I realize this could also be a configuration issue, but I wonder if the spec should at least strongly recommend starting with phase SecurityNegotiation, or better yet, make it a SHOULD? Regards, Steve Senum
Home Last updated: Tue Sep 04 01:03:49 2001 6315 messages in chronological order |