Re: UNH Plugfest 5

[Russell Lewis <russelll@us.ibm.com>]

Is there a reason not to allow different AuthMethods for Target and
Initator?  Either add new text messages TargetAuthMethod &
InitiatorAuthMethod, or perhaps allow initiators to encode combinations in
an AuthMethod:

      AuthMethod=CHAP/CHAP,CHAP/None,None/None,CHAP,None

      // CHAP/CHAP - means both are authenticated with CHAP
      // CHAP/None - means that the Initiator is authenticated but the
Target is not
      // None/None - means that neither is authenticated
      // CHAP - backwards compatibility
      // None - backwards compatibility





|---------+---------------------------->
|         |           "Robert D.       |
|         |           Russell"         |
|         |           <rdr@io.iol.unh.e|
|         |           du>              |
|         |           Sent by:         |
|         |           owner-ips@ece.cmu|
|         |           .edu             |
|         |                            |
|         |                            |
|         |           01/15/03 04:28 PM|
|         |                            |
|---------+---------------------------->
  >------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                              |
  |       To:       Julian Satran <Julian_Satran@il.ibm.com>, "" <ips@ece.cmu.edu>                                               |
  |       cc:                                                                                                                    |
  |       Subject:  Re: UNH Plugfest 5                                                                                           |
  |                                                                                                                              |
  |                                                                                                                              |
  >------------------------------------------------------------------------------------------------------------------------------|



Julian:

Two more questions arose at the plugfest today, 15-Jan-2003.

1.  A question arose as to the proper target response during the following
    CHAP authentication exchange.

    Assume that:
        I->T:   CHAP_A=5
        T->I:   CHAP_A=5 CHAP_I=<i> CHAP_C=<c>
    worked correctly.  The Initiator now sends:
        I->T:   CHAP_N=<n> CHAP_R=<r> CHAP_I=<i> CHAP_C=<c>
    Further assume that the values CHAP_N=<n> and CHAP_R=<r> are
    correct, so that the initiator is successfully authenticated by the
    target and the target will allow it access to the target's resources.

    The problem arises because the target does not want to be
    authenticated by the initiator, for whatever reason -- perhaps it has
    no CHAP_N value to return for this initiator, or it has no secret
    to use in calculating a value to return for CHAP_R, or whatever.
    If the initiator had not sent the CHAP_I and CHAP_C keys, both
    sides would have been happy and the login would proceed.  But the
    initiator did send those keys and the target does not want to see
    them.  So, what should happen?

    There appear to be at least the following 4 possibilities.

    a.  The target replies: CHAP_I=Reject CHAP_C=Reject
        This does not appear to be correct because the target is
        expected to reply to the pair of keys CHAP_I, CHAP_C with
        different keys (i.e., CHAP_N and CHAP_R), not the same keys.
        Furthermore, the target already sent CHAP_I and CHAP_C
        earlier in the exchange, so this would be sending the same
        key twice.  Certainly the initiator is not expecting to
        receive CHAP_I and CHAP_C again.

    b.  The target replies: CHAP_N=Reject CHAP_R=Reject
        This does not appear to be correct because these are not
        replies to offers of CHAP_N and CHAP_R, but to offers of
        different keys (i.e., CHAP_I and CHAP_C).  However, they
        could be considered "replies" of sorts to the initiator's
        "offer" of CHAP_N and CHAP_R, but that is stretching things.

    c.  The target replies with a login reject, but it is not
        clear what status code to use in this login reject pdu:
            0x0200  is not accurate, because it is not an initiator
                    error.
            0x0201  is not accurate, because the initiator WAS
                    successfully authenticated.
            0x0202  is also not accurate because the initiator
                    IS allowed access to the given target.
            0x0300  is not accurate, because it is not a target
                    error.
            A new access code could be invented "The target will not
                    authenticate itself".

        However, in this present situation, a login reject is probably
        not what the target wants to send, because it is willing to
        allow this initiator to proceed without target authentication,
        and thus the target does not want to terminate the login exchange.

    d.  The target replies with no keys, and if the initiator offered
        a transition out of security negotiation phase (i.e. T=1 and
        NSG=1 or NSG=3) then the target accepts the transition.  If the
        initiator does not like going on without having the target
        authentication, it can always just close the connection upon
        receiving this reply.  If the initiator did not offer a
        transition out of security negotiation phase, the target can
        only reply with T=0 and NSG=0, and will continue doing this for
        all subsequent login requests until either the initiator offers
        a transition or drops the connection.

    Solution d appears to be the most flexible, because the decision to
    ask for target authentication was made by the initiator, and solution
    d leaves it up to the initiator to decide whether or not it will
    proceed when the target refuses to provide this authentication.

    In any case, there appears to be a need for some clarification
    in the standard to cover this situation.


2.  The question arose with regard to how an initiator maps a scsi
    "bus reset" onto iscsi (this may be a legacy situation).  Some vendor
    initiators are simply doing a session logout, but other vendors claim
    this is not sufficient, and that to correctly emulate a "bus reset"
    the initiator needs to do a task management function TARGET WARM
    RESET, or, since that is optional to implement, when it is not
    implemented then the initiator needs to issue a task management
    function LOGICAL UNIT RESET for all active LUNs in that session.

    Can/should there be a "note to implementors" on this in the standard,
    so that a consistent result will be obtained in this situation?

Thank you for your consideration.


Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774