Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id h0HEMoN20497 for ips-outgoing; Fri, 17 Jan 2003 09:22:50 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h0HEMlW20492 for ; Fri, 17 Jan 2003 09:22:48 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Jan 2003 09:22:34 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C7A8@corpmx14.us.dg.com> From: Black_David@emc.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: FW: Redirection (was UNH Plugfest 5) Date: Fri, 17 Jan 2003 09:21:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BE33.C4FF2420" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BE33.C4FF2420 Content-Type: text/plain; charset="iso-8859-1" I certainly don't want to forbid redirection w/o authentication. "SHOULD be accepted during authentication" is ok, although we should point out that there may be valid security concerns that lead an administrator to do otherwise. Thanks, --David -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, January 17, 2003 5:55 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: FW: Redirection (was UNH Plugfest 5) David, The only way to do it cleany the way you want it is to allow the redirect response (0101 and 0102) only in operational parameter stage. But that seems rather excessive. If we want to mandate a single way of handling I would suggest stating that 0101 and 0102 SHOULD be accepted even during authentication (Paul's POV). Again I don't thing it adds anything as local policy may prevent an initiator from considering those values. Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 17/01/03 01:11 To ips@ece.cmu.edu cc Subject FW: Redirection (was UNH Plugfest 5) Forwarding an off-list note on this topic - a SHOULD is useful here to express a preference for which redirection mechanism to use in the presence of authentication. I prefer the SHOULD for redirection after authentication because rogue target attacks are more dangerous to iSCSI than rogue initiator attacks because the initiator authenticates first when using CHAP. Redirection prior to authentication makes it easier to mount a rogue target attack. Thanks, --David -----Original Message----- From: Paul Koning [mailto:pkoning@equallogic.com] Sent: Thursday, January 16, 2003 3:57 PM To: Black_David@emc.com Cc: Julian_Satran@il.ibm.com Subject: RE: Redirection (was UNH Plugfest 5) >>>>> "Black" == Black David writes: Black> The most I could see doing here would be: - In the absence of Black> explicit administrative action, - If a target is contacted by Black> an Initiator requesting SecurityNegotiation, - And the target Black> would issue a redirect to that Initiator based on the target Black> name the initiator is trying to contact, - Then the target Black> SHOULD negotiate security before issuing the redirect. My preference is to swing the SHOULD in the other direction, because there is no security issue in doing so. (In other words, if the initiator requests security negotiation and the target replies with a redirect, the initiator SHOULD accept that redirect as valid without a full security negotiation.) But your proposal still serves to strengthen the spec. paul ------_=_NextPart_001_01C2BE33.C4FF2420 Content-Type: text/html; charset="iso-8859-1"

I certainly don't want to forbid redirection w/o authentication.

"SHOULD be accepted during authentication" is ok, although we

should point out that there may be valid security concerns that

lead an administrator to do otherwise.

Thanks,

--David

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, January 17, 2003 5:55 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: FW: Redirection (was UNH Plugfest 5)

David,

The only way to do it cleany the way you want it is to allow the redirect response (0101 and 0102) only in operational parameter stage.
But that seems rather excessive. If we want to mandate a single way of handling I would suggest stating that 0101 and 0102
SHOULD be accepted even during authentication (Paul's POV). Again I don't thing it adds anything as local policy may prevent an initiator from
considering those values.

Julo

Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu
17/01/03 01:11

To
ips@ece.cmu.edu

cc

Subject
FW: Redirection (was UNH Plugfest 5)

Forwarding an off-list note on this topic - a SHOULD is useful here to express a preference for which redirection mechanism to use in the presence of authentication. I prefer the SHOULD for redirection after authentication because rogue target attacks are more dangerous to iSCSI than rogue initiator attacks because the initiator authenticates first when using CHAP. Redirection prior to authentication makes it easier to mount a rogue target attack. Thanks, --David -----Original Message----- From: Paul Koning [mailto:pkoning@equallogic.com] Sent: Thursday, January 16, 2003 3:57 PM To: Black_David@emc.com Cc: Julian_Satran@il.ibm.com Subject: RE: Redirection (was UNH Plugfest 5) >>>>> "Black" == Black David <Black_David@emc.com> writes: Black> The most I could see doing here would be: - In the absence of Black> explicit administrative action, - If a target is contacted by Black> an Initiator requesting SecurityNegotiation, - And the target Black> would issue a redirect to that Initiator based on the target Black> name the initiator is trying to contact, - Then the target Black> SHOULD negotiate security before issuing the redirect. My preference is to swing the SHOULD in the other direction, because there is no security issue in doing so. (In other words, if the initiator requests security negotiation and the target replies with a redirect, the initiator SHOULD accept that redirect as valid without a full security negotiation.) But your proposal still serves to strengthen the spec. paul

------_=_NextPart_001_01C2BE33.C4FF2420--