SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI: keys/parameter dependence



    I have to agree with Steve.
    
    Will someone explain to me the "value add" of sending the keys in multiple PDUs? Or in some other other than shown?
    
    I sure don't see any value and see a bunch of interop problems if we allow it.
    
    Kevin Lemay
    
    
    -----Original Message-----
    From: Steve Senum [mailto:ssenum@cisco.com]
    Sent: Thursday, January 30, 2003 12:46 PM
    To: Robert D. Russell; Julian Satran
    Cc: ips@ece.cmu.edu
    Subject: Re: iSCSI: keys/parameter dependence
    
    
    Bob Russell and Julian:
    
    "Robert D. Russell" wrote:
    > 
    > Steve:
    > 
    > > I think allowing keys to be distributed over several PDUs
    > > breaks the curent CHAP authentication sequence.  Consider:
    > >
    > >     I->T: CHAP_A=<A1,A2...>
    > >
    > >     T->I: CHAP_A=<A> CHAP_I=<I> CHAP_C=<C>
    > >
    > >     I->T: CHAP_N=<N> CHAP_R=<R>
    > >     OR
    > >     I->T: CHAP_N=<N> CHAP_R=<R> CHAP_I=<I> CHAP_C=<C>
    > >
    > > The target does not know how many keys to expect,
    > > so it would not know when the step is complete.
    > 
    > Not exactly.  As soon as it receives both CHAP_N=<N> and CHAP_R=<R>,
    > regardless of whether it has CHAP_I=<I> or CHAP_C=<C>,
    > the target can immediately authenticate the initiator.
    > If that fails, it can immediately send a Login reject.
    > If that authentication succeeds, then the target sees what it has.
    > If it has both CHAP_I and CHAP_C then it replies with CHAP_N and CHAP_R.
    > If it has only one of CHAP_I and CHAP_C, but not both, it replies with
    > an empty login response and waits for a login request containing the
    > missing CHAP_I or CHAP_C.
    > If it has neither CHAP_I nor CHAP_C, then it looks at the T bit.
    > If the T bit is 1, the initiator is requesting a transition out
    > of security negotiation phase with this pdu, which means it is
    > not intending to send either CHAP_I or CHAP_C in the future.
    > In this case, the target accepts the transition and the security
    > negotiation stage is finished.
    > On the other hand, if the T bit is 0, the initiator MAY (or MAY NOT)
    > intend to send the CHAP_I or CHAP_C in later pdus, so the target
    > replies with a Login response containing no keys, and waits to
    > receive further information from the initiator.
    
    Okay, I forgot about the T bit in my last message.  But this only
    works because the "step" in question is also a possible termination
    point in the negotiation.  If you were to insert a variable number of
    keys in the middle of this sequence, it would not work.
    
    > 
    > Although this seems like a lot of combinatorics, it really isn't,
    > because the end of the security stage is always and only indicated
    > by the initiator sending the T bit = 1 and the target replying with
    > the T bit = 1.  Presence or absence of the CHAP keys just cause "step"
    > transitions within the security negotiation stage.
    > 
    > I believe the "step" in question is really 2 steps:
    > the step that ends when the target receives CHAP_N and CHAP_R,
    > at which point it completes its initiator authentication,
    > and the step that follows that one, which ends when the target
    > receives the T bit = 1, at which point, if it has received
    > CHAP_I and CHAP_C then it replies with CHAP_N and CHAP_R,
    > and if it has not received CHAP_I and CHAP_C, then it replies
    > with no keys.  In both cases, it accepts the transition out
    > of security negotiation by replying with T bit = 1.
    
    I think an implementation must be careful how they handle this,
    as not to weaken the effect of the following text from section
    section 8.2, "In-band Initiator-Target Authentication":
    
       Section 11 iSCSI Security Text Keys and Authentication Methods
       defines several authentication methods and the exact steps that must
       be followed in each of them, including the iSCSI-text-keys and their
       allowed values in each step. Whenever an iSCSI initiator gets a
       response whose keys, or their values, are not according to the step
       definition, it MUST abort the connection. Whenever an iSCSI target
       gets a response whose keys, or their values, are not according to
       the step definition, it MUST answer with a Login reject with the
       "Initiator Error" or "Missing Parameter" status. These statuses are
       not intended for cryptographically incorrect values such as the CHAP
       response, for which "Authentication Failure" status MUST be
       specified. The importance of this rule can be illustrated in CHAP
       with target authentication (see Section 11.1.4 Challenge Handshake
       Authentication Protocol (CHAP)) where the initiator would have been
       able to conduct a reflection attack by omitting his response key
       (CHAP_R) using the same CHAP challenge as the target and reflecting
       the target's response back to the target. In CHAP, this is prevented
       because the target must answer the missing CHAP_R key with a Login
       reject with the "Missing Parameter" status.
    
    I think allowing multiple login messages per "step" adds complexity
    without any gain.
    
    Regards,
    Steve Senum
    


Home

Last updated: Thu Jan 30 18:19:13 2003
12279 messages in chronological order