Subject: iSCSI - Change - Login/Text commands with the binary stage code

From: "Julian Satran" <[email-masked]>
Date: Wed, 22 Aug 2001 11:30:12 +0300

As was agreed in London I did attempt a rewrite of part 4 (Login Phase) and
added a binary current/next stage
to the all the PDUs involved in the Login Phase (Login/Text command and
response).

Here are the changed parts (2.8, 2.9, 2.10, 2.11 and 4). The Login Appendix
is also changed (attached).

There are some more changes in the appendixes but those are minor.

1.1  Text Command

   The Text Command is provided to allow the exchange of information and
   for future extensions. It permits the initiator to inform a target of
   its capabilities or to request some special operations.

   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|X|I| 0x04      |F|B|0 0| CNxSG | Reserved (0)                  |
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)  | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| Reserved (0)                                                  |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| Reserved (0)                                                  |
     +---------------+---------------+---------------+---------------+
   24| CmdSN                                                         |
     +---------------+---------------+---------------+---------------+
   28| ExpStatSN                                                     |
     +---------------+---------------+---------------+---------------+
   32| Reserved (0)                                                  |
     |                                                               |
     +---------------+---------------+---------------+---------------+
   40| Bookmark or Reserved (0)                                      |
     |                                                               |
     +---------------+---------------+---------------+---------------+
   48| Digests if any...                                             |
     +---------------+---------------+---------------+---------------+
     / DataSegment (Text)                                            /
    +/                                                               /
     +---------------+---------------+---------------+---------------+

1.1.1     F (Final) Bit

   When set to 1 it indicates that this is the last or only text command in
   a sequence of commands; otherwise it indicates that more commands will
   follow.

1.1.2     CNxSG

   Through this field, called Current-Next Stage (CNxSG), the textual
   negotiation commands and responses (Login and Text) are associated with
   a specific stage in the session (SecurityNegotiation,
   LoginOperationalNegotiation, FullPhaseOperationalNegotiations) and may
   indicate the next stage they want to move to (see 4).

   The current stage is coded in bits 0-1 and the next stage in bits 2-3.
   The next stage value is valid only when the F bit is 1 and can be
   ignored otherwise.

   The stage codes are:

      - 0 - SecurityNegotiation
      - 1 - LoginOperationalNegotiation
      - 3 - FullFeaturePhaseOperationalNegotiation

1.1.3     B (Bookmark-valid) Bit

   A value of 1 indicates that the Bookmark field is valid.

1.1.4     Initiator Task Tag

   The initiator assigned identifier for this Text Command.
   If the command is sent as part of a sequence of commands (e.g., the
   Login Phase or a sequence of Text commands) the Initiator Task Tag MUST
   be the same for all the commands within the sequence (similar to linked
   SCSI commands).

1.1.5     Bookmark

   An opaque handle copied from a previous text response.  It is supposed
   to allow a target to transfer a large amount of textual data over a
   sequence of text-command/text-response exchanges.  The target associates
   the bookmark it issues with the Initiator Task Tag and a received
   Bookmark is considered valid by the Target only if received with the
   same Initiator Task Tag and if the target did not receive on the same
   connection a text command with a different Initiator Text Tag since it
   issued the Bookmark.

   A target MAY reject an old Bookmark.

   The Bookmark field is valid only if the B bit is 1.

   Long text responses are handled as in the following example:

      I->T Text SendTargets=all (F=1,B=0)
      T->I Text <part 1> (F=0,B=1,Bookmark)
      I->T Text <empty> (F=1,B=1,Bookmark)
      T->I Text <part 2> (F=0,B=1,Bookmark)
      I->T Text <empty> (F=1,B=1,Bookmark)
      ...
      T->I Text <part n> (F=1,B=0)

1.1.6     Text

   The initiator sends the target a set of key=value or key=list pairs
   encoded in UTF-8 Unicode. All the text keys and text values specified in
   this document are to be presented and interpreted in the case they
   appear in this document (they are case sensitive). The key and value are
   separated by a '=' (0x3D) delimiter. Every key=value pair (including the
   last or only pair) MUST be followed by null (0x00) delimiter.  A list is
   a set of values separated by comma (0x2C). Large binary items can be
   encoded using their hexadecimal representation (e.g., 8190 is 0x1FFE) or
   decimal representation. The maximum length of an individual value (not
   its string representation) is 255 bytes.

   The data lengths of a text command or response MUST NOT exceed 4096
   bytes.  Key names MUST NOT exceed 63 bytes. Key values MUST NOT exceed
   255 characters.

   Character strings are represented as plain text. Numeric and binary
   values are represented using either decimal numbers or the hexadecimal
   0xFFFF notation. Upper and lower case letters may be used
   interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC and 0x1ABC
   are equivalent).

   The target responds by sending its response back to the initiator. The
   response text format is similar to the request text format.

   Some basic key=value pairs are described in Appendix A and Appendix D.
   All of these keys, except for the X- extension format, MUST be supported
   by iSCSI initiators and targets.

   Manufacturers may introduce new keys by prefixing them with X- followed
   by their (reversed) domain name, for example the company owning the
   domain acme.com can issue:

      X-com.acme.bar.foo.do_something=0000000000000003

   Any other key not understood by the target may be ignored by the target
   without affecting basic function. However the Text Response for a key
   that was not understood MUST be key=NotUnderstood.

   Text operations are usually meant for parameter setting/negotiations but
   can be used also to perform some long lasting operations.

   It is recommended that Text operations that will take a long time should
   be placed in their own Text command.

   A connection may have only one outstanding text command at any given
   time.

1.2

Text Response

   The Text Response PDU contains the target's responses to the initiator's
   Text Command. The format of the Text field matches that of the Text
   Command.

   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|1|1| 0x24      |F|B|0 0| CNxSG | Reserved (0)                  |
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)  | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| Reserved (0)                                                  |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| Reserved (0)                                                  |
     +---------------+---------------+---------------+---------------+
   24| StatSN                                                        |
     +---------------+---------------+---------------+---------------+
   28| ExpCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   32| MaxCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   36| Reserved (0)                                                  |
     +---------------+---------------+---------------+---------------+
   40| Bookmark or Reserved (0)                                      |
     |                                                               |
     +---------------+---------------+---------------+---------------+
   48| Digests if any...                                             |
     +---------------+---------------+---------------+---------------+
     / DataSegment (Text)                                            /
    +/                                                               /
     +---------------+---------------+---------------+---------------+

1.2.1     F (Final) Bit

   When set to 1 in response to a text command with the Final bit set to 1
   the F bit indicates that the target has finished the current stage of
   the operation or the whole operation.  Otherwise if set to 0 in response
   to a text command with the Final Bit set to 1 it indicates that the
   target has more work to do (invites a follow-on text command).  A text
   response with the F bit set to 1 in response to a text command with the
   F bit set to 0 is a protocol error.

   A text response with a F bit set to 1 MUST NOT contain key=value pairs
   that may require additional answers from the initiator.

1.2.2     B (Bookmark-valid) Bit

   A value of 1 indicates that the Bookmark field is valid.
   F bit must be 0.

1.2.3     Initiator Task Tag

   The Initiator Task Tag matches the tag used in the initial Text Command
   or the Login Initiator Task Tag.

1.2.4     Bookmark

   An opaque handle to be copied to the next text command by the initiator.
   It is supposed to allow a target to transfer a large amount of textual
   data over a sequence of text-command/text-response exchanges.  The
   target associates the bookmark it issues with the Initiator Task Tag and
   a received Bookmark is considered valid by the Target only if received
   with the same Initiator Task Tag and if the target did not receive on
   the same connection a text command with a different Initiator Text Tag
   since it issued the Bookmark.

   A target MAY reject an old Bookmark.

   The Bookmark is valid only if the F bit is 0 and the B bit is 1.

1.2.5     Text Response Data

   The Text Response Data Segment contains responses in the same key=value
   format as the Text Command and with the same length and coding
   constraints. Appendix C lists some basic Text Commands and their
   Responses.

   Although the initiator is the requesting party and controls the
   request-response initiation and termination the target can offer
   key=value pairs of its own as part of a sequence and not only in
   response to an identical key=value pair offered by the initiator.

1.3

Login Command

   After establishing a TCP connection between an initiator and a target,
   the initiator MUST issue a Login Command to gain further access to the
   target's resources.

   A Login Command MUST NOT be issued more than once on an iSCSI TCP
   connection.

   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|X|I| 0x03      |F|0 0 0| CNxSG | Version-max   | Version-min   |
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)  | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| CID                           | Reserved (0)                  |
     +---------------+---------------+---------------+---------------+
   12| ISID                          |TSID                           |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| Reserved (0)                                                  |
     +---------------+---------------+---------------+---------------+
   24| CmdSN   or   Reserved (0)                                     |
     +---------------+---------------+---------------+---------------+
   28| ExpStatSN   or   Reserved (0)                                 |
     +---------------+---------------+---------------+---------------+
   32/ Reserved (0)                                                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48/ DataSegment - Login Parameters in Text Command Format         /
    +/                                                               /
     +---------------+---------------+---------------+---------------+

1.3.1     X - Restart

   If this bit is set to 1 then this command is an attempt to reinstate a
   failed connection. CID does not change and this command performs first
   the logout function of the old connection if an explicit logout was not
   performed earlier. In sessions with a single connection, this may imply
   the opening of a second connection with the sole purpose of cleaning-up
   the first. Targets should support opening a second connection even when
   not supporting multiple connections in full feature phase.  A restart
   login indicates to the target that commands may be missing and therefore
   it should be handled immediately.

1.3.2     F (Final) Bit

   If set to 1 indicates that the initiator has no more parameters to set.

1.3.3     Version-max

   Maximum Version number supported.

1.3.4     Version-min

   Minimum Version supported
   The version number of the current draft is 0x2.

1.3.5     CID

   This is a unique ID for this connection within the session.

1.3.6     ISID

   This is an initiator-defined session-identifier.  It MUST be the same
   for all connections within a session.  A SCSI initiator port is uniquely
   identified by the value pair (InitiatorName, ISID).

   When a target is detecting an attempt to open a new session by the same
   SCSI initiator port (same InitiatorName and ISID) to the same target
   portal group it MUST check if the old session is still active.  If it is
   not active and the target has failed to realize that the old-session
   must be reset by the target and the new session established. Otherwise
   the Login MUST be terminated with a Login Response of "Session already
   open with this initiator".

1.3.7     CmdSN

   CmdSN is either the initial command sequence number of a session (for
   the first Login of a session - the "leading" login) or the command
   sequence number in the command stream (e.g., if the leading login
   carries the CmdSN 123 the next command carries the number 124 etc.).

1.3.8     ExpStatSN

   This is ExpStatSN for the old connection.
   This field is valid only if the X bit is set to 1.

1.3.9     Login Parameters

   The initiator MAY provide some basic parameters in order to enable the
   target to determine if the initiator may use the target's resources and
   the initial text parameters for the security exchange.  The format of
   the parameters is as specified for the Text Command.    Keys and their
   explanations are listed in the Appendixes.

1.4  Login Response

   The Login Response indicates the progress and/or end of the login phase.
   Note that after security is established, the login response is
   authenticated.

   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |
     |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
     +---------------+---------------+---------------+---------------+
    0|1|1| 0x23      |F|0 0 0| CNxSG | Version-max   | Version-active|
     +---------------+---------------+---------------+---------------+
    4| Reserved (0)  | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| Reserved (0)                                                  |
     +---------------+---------------+---------------+---------------+
   12| ISID                          |TSID                           |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| Reserved (0)                                                  |
     +---------------+---------------+---------------+---------------+
   24| StatSN                                                        |
     +---------------+---------------+---------------+---------------+
   28| ExpCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   32| MaxCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   36| Status-Class  | Status-Detail | Reserved (0)                  |
     +---------------+---------------+---------------+---------------+
   40/ Reserved (0)                                                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48| Digests if any...                                             |
     +---------------+---------------+---------------+---------------+
     / DataSegment - Login Parameters in Text Command Format         /
    +/                                                               /
     +---------------+---------------+---------------+---------------+

1.4.1     F (Final) bit

   Final bit is set to one as an indicator of end of stage and if the next
   stage part in CNxSG is FullFeaturePhaseOperationalNegotiation the this
   is also the Final Login Response (see 4). A Final bit of 0 indicates a
   "partial" response, which means "more negotiation needed".

   A login response with a F bit set to 1 MUST NOT contain key=value pairs
   that may require additional answers from the initiator within the same
   stage.

1.4.2     Version-max

   This is the highest version number supported by the target.

1.4.3     Version-active/lowest

   Indicates the version supported (the highest version supported by the
   target and initiator). If the target is not supporting a version within
   the range specified by the initiator, the target rejects the login and
   this field indicates the lowest version supported by the target.

1.4.4     TSID

   The TSID is an initiator SCSI port identifying tag set by the target.
   It MUST be valid only in the final response.

1.4.5     StatSN

   For the first Login Response this is the starting status Sequence Number
   for the connection (the next response of any kind will carry this number
   + 1). This field is valid only if the Status Class is 0.

1.4.6     Status-Class and Status-Detail

   The Status returned in a Login Response indicates the status of the
   login request. The status includes:

      Status-Class
      Status-Detail

   The Status-Class is sufficient for a simple initiator to use when
   handling errors, without having to look at the Status-Detail.  The
   Status-Detail allows finer-grained error recovery for more sophisticated
   initiators, as well as better information for error logging.

   The status classes are as follows:

      0 - Success - indicates that the iSCSI target successfully received,
      understood, and accepted the request. The numbering fields (StatSN,
      ExpCmdSN, MaxCmdSN are valid only if Status-Class is 0).

      1 - Redirection - indicates that further action must be taken by the
      initiator to complete the request. This is usually due to the target
      moving to a different address. All of the redirection status class
      responses MUST return one or more text key parameters of the type
      "TargetAddress", which indicates the target's new address.

      2 - Initiator Error - indicates that the initiator likely caused the
      error. This MAY be due to a request for a resource for which the
      initiator does not have permission.

      3 - Target Error - indicates that the target is incapable of
      fulfilling the request.

   The table below shows all of the currently allocated status codes.  The
   codes are in hexadecimal; the first byte is the status class and the
   second byte is the status detail.  The allowable state of the Final (F)
   bit in responses with each of the codes is also displayed.

   -----------------------------------------------------------------
   Status        | Code |Final|   Description
                 |(hex) | bit |
   -----------------------------------------------------------------
   Accept Login  | 0000 | 1/0 | Login is OK, moving to Full Feature
                 |      |     | Phase or LoginOperationalNegotiation
                 |      |     | stage (*1)
   -----------------------------------------------------------------
   Authenticate  | 0001 | 0   | The iSCSI TargetName (ITN) exists and
                 |      |     | authentication proceeds.
   -----------------------------------------------------------------
   iSCSI Target  | 0002 | 0   | The ITN must be provided
   Name required |      |     | for authentication to proceed.
   -----------------------------------------------------------------
   Target Moved  | 0101 | 1   | The requested ITN has moved
   Temporarily   |      |     | temporarily to the address provided.
   -----------------------------------------------------------------
   Target Moved  | 0102 | 1   | The requested ITN has moved
   Permanently   |      |     | permanently to the address provided.
   -----------------------------------------------------------------
   Proxy Required| 0103 | 1   | The initiator must use an iSCSI
                 |      |     | proxy for this target.
                 |      |     | The address is provided.
   -----------------------------------------------------------------
   Initiator     | 0200 | 1   | Miscellaneous iSCSI initiator
   Error         |      |     | errors
   -----------------------------------------------------------------
   Security Nego-| 0201 | 1   | The security negotiation failed
   tiation Failed|      |     |
   -----------------------------------------------------------------
   Forbidden     | 0202 | 1   | The initiator is not allowed access
   Target        |      |     | to the given target.
   -----------------------------------------------------------------
   Not Found     | 0203 | 1   | The requested ITN does not
                 |      |     | exist at this address.
   -----------------------------------------------------------------
   Target Removed| 0204 | 1   | The requested ITN has been
                 |      |     | removed. No forwarding address is
                 |      |     | provided.
   -----------------------------------------------------------------
   Target        | 0205 | 1   | Target is currently in use by
   Conflict      |      |     | another initiator and does
                 |      |     | not support multiple initiators.
   -----------------------------------------------------------------
   Initiator     | 0206 | 1   | Invalid TSID - no more connections
   SID error     |      |     | accepted
                 |      |     |
   -----------------------------------------------------------------
   Missing       | 0207 | 1   | Missing parameters (e.g., iSCSI
   parameter     |      |     | Initiator and/or Target Name)
   -----------------------------------------------------------------
   Can't include | 0208 | 1   | Target does not support session
   in session    |      |     | spanning to this connection (address)
   -----------------------------------------------------------------
   Session open  | 0209 | 1   | The iSCSI InitiatorName and ISID
   already with  |      |     | identify an existing session
   this Initiator|      |     | with this initiator
   -----------------------------------------------------------------
   Session type  | 020a | 1   | Target does not support this type of
   Not supported |      |     | of session (not from this Initiator)
   -----------------------------------------------------------------
   Target Error  | 0300 | 1   | Miscellaneous iSCSI target
                 |      |     | errors (out of resources, etc.).
   -----------------------------------------------------------------
   Service       | 0301 | 1   | The iSCSI service or target is not
   Unavailable   |      |     | currently operational.
   -----------------------------------------------------------------
   Unsupported   | 0302 | 1   | The required version is not
   version       |      |     | supported by the target.
   -----------------------------------------------------------------

   (*1)If the Status is "accept login" (0x0000) the initiator has stated
   the current stage as LoginOperationalNegotiation (and if the F bit was 1
   the next stage to FullFeaturePhaseOperationalNegotiation). If the
   response F bit is 1 (the next stage part is also
   FullFeaturePhaseOperationalNegotiation) the login phase is finished and
   the initiator may proceed to issue SCSI commands. If the Status is
   "accept login" (0x0000) and the F bit is 0, the initiator may proceed to
   negotiate operational parameters.

   If the Status Class is not 0, the initiator and target MUST close the
   TCP connection.

   If the target wishes to reject the login request for more than one
   reason, it should return the primary reason for the rejection.

 Part 4 (login) is now:

1.   Login Phase

   In the rest of this chapter, whenever we mention security we mean
   security and/or data integrity.

   The login phase establishes an iSCSI session between initiator and
   target. It sets the iSCSI protocol parameters, security parameters, and
   authenticates the initiator and target to each other.

   The login phase is implemented via login and text commands and responses
   only.  The whole login phase is considered as a single task and has a
   single Initiator Task Tag (similar to the linked SCSI commands).

   The login phase sequence of commands and responses proceeds as follows:

      - Login command (mandatory)
      - Login Partial-Response (optional)
      - Text Command(s) and Response(s) (optional)
      - Login Final-Response (mandatory)

   The Login Final-response accepts or rejects the Login Command.

   The Login Phase MAY include a SecurityNegotiation stage and a
   LoginOperationalNegotiation stage and MUST include at least one of them,
   but the included stage MAY be empty.

   The login and text commands and responses contain a field that indicates
   the negotiation stage (SecurityNegotiation or
   LoginOperationalNegotiation).  If both stages are used the
   SecurityNegotiation MUST precede the LoginOperationalNegotiation.

   Some operational parameters can be negotiated outside login, through
   text command response - called for uniformity -
   FullFeaturePhaseOperationalNegotiation.

   Security MUST be completely negotiated within the Login Phase or
   provided by external means (e.g., IPSec).

   In some environments, a target or an initiator is not interested in
   authenticating its counterpart. It is possible to bypass authentication
   through the Login Command and Response.

   The initiator and target MAY want to negotiate authentication and data
   integrity parameters. Once this negotiation is completed, the channel is
   considered secure.

   Authentication and a Secure Channel setup MAY be performed independent
   of iSCSI (as when using tunneling IPSec or some implementations of
   transport IPSec) in which case the Login phase can be reduced to
   operational parameter negotiations.

   Most of the negotiation keys are allowed only in a specific stage - the
   SecurityNegotiation keys appear all in Appendix A while the
   LoginOperationalNegotiation keys appear in Appendix D.
   Only a limited set of keys (marked as Declarative in Appendix D) may be
   used in any of the 2 stages.

   Any given Login or Text command or response belongs to a specific stage
   and this determines the negotiation keys allowed with the command or
   response.

   Stage transition is performed through a command exchange
   (request/response) carrying the F bit and the same current stage code.
   During this exchange, the next stage selected is the lower of the two
   next stage codes.  The initiator can request a transition whenever it is
   ready but a target can respond with a transition only after it is
   offered one by the initiator.

   In a negotiation sequence, the F bit settings in one pair of text/login
   request-responses have no bearing on the F bit settings of the next
   pair.  An initiator having F bit set to 1 in one pair and being answered
   with an F bit setting of 0 may issue the next request with F bit set to
   0.

   Stage transitions during login (including entering and exit) are
   possible only as outlined in the following table:

   +-----------------------------------------------------------+
   |From     To ->   | Security    | Operational | FullFeature |
   |  |              |             |             |             |
   |  V              |             |             |             |
   +-----------------------------------------------------------+
   | (start)         |  yes        |  yes        |  no         |
   +-----------------------------------------------------------+
   | Security        |  no         |  yes        |  yes        |
   +-----------------------------------------------------------+
   | Operational     |  no         |  no         |  yes        |
   +-----------------------------------------------------------+

   The Login Final-Response that accepts a Login Command can come only as a
   response to a Login command with the F bit set to 1 or a Text Command
   with the F bit set to 1 and both the command and response MUST have
   FullFeaturePhaseOperationalNegotiation in the next stage part of the
   CNxSG field.

1.1  Login Phase Start

   The login phase starts with a login request via a login command from the
   initiator to the target. The login request includes:

      -Protocol version supported by the initiator (currently 0x'02')
      -Session and connection Ids
      -The negotiation stage that the initiator is ready to enter

   Optionally the login request may include:

      -Security/Integrity parameters OR
      -iSCSI operational parameters AND/OR
      -The next negotiation stage that the initiator is ready to enter

   The target can answer the login in the following ways:

      -Login Response with Login Reject.  This is an immediate rejection
      from the target that causes the session to terminate. The F bit of
      the response MUST be set to 1 and the CNxSG is to be ignored
      -Login Response with Login Accept as a final response (F bit set to 1
      and the next part of CNxSG in both command a response are set to
      FullFeaturePhaseOperationalNegotiation). The response includes the
      protocol version supported by the target  and the session ID and may
      include iSCSI operational or security parameters (depending on the
      current stage).
      -Login Response with Login Accept as a partial response indicating
      the start of a negotiation sequence.  The response includes the
      protocol version supported by the target and either
      security/integrity parameters or iSCSI parameters (when no
      security/integrity mechanism is chosen) supported by the target.

   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.

   If the initiator is willing no negotiate security but it is unwilling to
   make the initial parameter offer and may accept a connection without
   security it issues the Login with the F bit set to 1, the CNxSG set to
   SecurityNegotiation in the current stage and LoginOperationalNegotiation
   in the next stage. If the target is also ready to forego security the
   Login response is empty and has F bit is set to 1 and the CNxSG set to
   SecurityNegotiation in the current stage and LoginOperationalNegotiation
   in the next stage.

   An initiator that can operate without security and with all the
   operational parameters taking the default values issues the Login with
   the F bit set to 1, the CNxSG set to LoginOperationalNegotiation in the
   current stage and FullFeaturePhaseOperationalNegotiation in the next
   stage. If the target is also ready to forego security and
   LoginOperationalNegotiation the Login response is empty and has F bit is
   set to 1 and the CNxSG set to LoginOperationalNegotiation in the current
   stage and FullFeaturePhaseOperationalNegotiation in the next stage.

   A target MAY use the iSCSI Initiator Name as part of its access control
   mechanism; therefore, the iSCSI Initiator Name MUST be sent before the
   target is required to disclose its LUs.

   If the iSCSI Target Name and/or iSCSI Initiator Name is going to be used
   in determining the security mode or it is implicit part of
   authentication, then the iSCSI Target Name and/or iSCSI Initiator Name
   MUST be sent in the login command for the first connection of a session
   to identify the storage endpoint of the session. If sent on new
   connections within an existing session it MUST be the same as the one
   used for the leading connection.  If the iSCSI Target Name and/or iSCSI
   Initiator Name is going to be used only for access control, it can be
   sent after the SecurityNegotiation stage. A target can be accessed
   without a Target Name only if the session type is a discovery session.

   The iSCSI Names MUST be in text command format.

1.2  iSCSI Security and Integrity Negotiation

   The security exchange sets the security mechanism and authenticates the
   user and the target to each other. The exchange proceeds according to
   the algorithms that were chosen in the negotiation phase and is
   conducted by the login and text commands key=value parameters.

   The negotiable security mechanisms include the following modes:

      -Initiator-target authentication - the host and the target
      authenticate themselves to each other. A negotiable algorithm such as
      Kerberos provides this feature.
      -PDU integrity - an integrity/authentication digest is attached to
      each packet.  The algorithm is negotiable.

      Using IPsec for encryption or authentication may eliminate part of
      the security negotiation at the iSCSI level but not necessarily all.

   If security is established in the login phase then after the security
   negotiation is complete, each iSCSI PDU MUST include the appropriate
   digest field if any.

   The negotiation proceeds as follows:

      -The initiator sends a login or text command with an ordered list of
      the options it supports for each subject (authentication algorithm,
      iSCSI parameters and so on). The options are listed in the
      initiator's order of preference.
      -The target MUST reply with the first option in the list it supports
      and is allowed for the specific initiator.  The parameters are
      encoded in UTF8 as key=value.  The initiator MAY also send
      proprietary options. The "none" option, if allowed, MUST be included
      in the list, which indicates that no algorithm is supported by the
      target. For a list of security parameters see Appendix A.

      -The initiator must be aware of the imminent completion of the
      SecurityNegotiation stage and MUST set the F bit to 1 and the next
      stage part of CNxSG to what it would like the next stage to be. The
      target will answer with a Login or Text response with the F bit set
      to 1 and the next stage part of CNxSG to what it would like the next
      stage to be. The next stage selected will be the "lower" of the two.
      If the next stage is FullFeaturePhase, the target MUST respond with a
      Login Response with the Session ID and the protocol version.

   All PDUs sent after the security negotiation stage MUST be built using
   the agreed security.

   If the security negotiation fails at the target then the target MUST
   send the appropriate Login Response PDU.  If the security negotiation
   fails at the initiator, the initiator shall drop the connection.

1.3  Operational Parameter Negotiation During the Login Phase

   Operational parameter negotiation during the login MAY be done:

      - starting with the Login command if the initiator does not offer
      any security/ integrity option
      - starting immediately after the security/integrity negotiation if
      the initiator and target perform such a negotiation

   An operational parameter negotiation on a connection MUST NOT start
   before the security negotiation if a security negotiation exists.

   Operational parameter negotiation MAY involve several request-response
   exchanges (login and/or text) started and terminated by the initiator.
   The initiator MUST indicate its intent to terminate the negotiation by
   setting the F bit to 1; the target sets the F bit to 1 on the last
   response. The last response MUST be the Login Response.
   If the target responds to a text or Login command with the F bit set to
   1, with a text response with the F bit set to 0, or a login response
   with the F bit set to 0, the initiator must keep sending the text
   command (even empty) with the F bit set to 1 until it gets the Login
   Response with the F bit set to 1.

   Whenever parameter action or acceptance is dependent of other parameters
   the dependent parameters MUST be sent after the parameters they are
   depending on.  If they are sent within the same command a response for a
   parameter might imply responses for others.

   A target MUST NOT send more than one Login Response with the F bit set
   to 0.

   An initiator MUST send a single Login command per connection, per
   session.

   For a list of operational parameters, see Appendix D.

 The Appendix A is now:

Appendix A.    iSCSI Security and Integrity

01   Security Keys and Values

   The parameters (keys) negotiated for security are:

      - Digests (HeaderDigest, DataDigest)
      - Authentication method (AuthMethod)

   Digests enable checking end-to-end data integrity beyond the integrity
   checks provided by the link layers and covering the whole communication
   path including all elements that may change the network level PDUs like
   routers, switches, proxies, etc.

   The following table lists cyclic integrity checksums that can be
   negotiated for the digests and MUST be implemented by every iSCSI
   initiator and target. Note that these digest options have only error
   detection significance.

   +---------------------------------------------+
   | Name          | Description     | Generator |
   +---------------------------------------------+
   | crc-32C       | 32 bit CRC      | 11EDC6F41 |
   +---------------------------------------------+
   | none          | no digest                   |
   +---------------------------------------------+

   The generator polynomial for this digest is given in hex-notation, for
   example 3b stands for 0011 1011 - the polynomial x**5+X**4+x**3+x+1.

   Padding bytes, when present, in a segment covered by a CRC, should be
   set to 0 and are included in the CRC. The CRC should be calculated as
   follows:

      - data are assumed to be  in the numbering order that appears in the
      draft - start with byte 0 bit 0 continue byte 1 bit 0 etc. (Big
      Endian on bytes / Little Endian on bits)
      - the CRC register is initialized with all 1s (equivalent to
      complementing the first 32 bits of the message)
      - the n PDU bits are considered coefficients of a polynomial M(x) of
      order n-1, with bit 0 of byte 0 being x^(n-1)
      - the polynomial is multiplied by x^32 and divided by G(x)- the
      generator polynomial - producing a remainder R(x) of degree <= 31
      - the coefficients of R(x) are considered a 32 bit sequence
      - the bit sequence is complemented and the result is the CRC
      - after the last bit of the original segment the CRC bits are
      transmitted with x^31 first followed by x^30 etc. ( whenever examples
      are given the value to be specified in examples follows the same
      rules of representation as the rest of this document)
      - a receiver of a "good" segment (data or header) built using the
      generator 0x11EDC6F41 will end-up having in the CRC register the
      value 0x1c2d19ed (this a register value and not a word as outlined in
      this draft)

   Implementations MAY also negotiate digests with security significance
   for data authentication and integrity as detailed in the following
   table:

   +-------------------------------------------------------------+
   | Name          | Description                   | Definition  |
   +-------------------------------------------------------------+
   | KRB5_MD5      | the SGN_CKSUM field (8 bytes) | RFC1964     |
   |               | of the GSS_GetMIC() token in  |             |
   |               | GSS_KRB5_INTEG_C_QOP_MD5 QOP  |             |
   |               | (partial MD5 ("MD2.5") )      |             |
   +-------------------------------------------------------------+
   | KRB5_DES_MD5  | the SGN_CKSUM field (8 bytes) | RFC1964     |
   |               | of the GSS_GetMIC() token in  |             |
   |               | GSS_KRB5_INTEG_C_QOP_DES_MD5  |             |
   |               | QOP (DES MAC of MD5)          |             |
   +-------------------------------------------------------------+
   | KRB5_DES_MAC  | the SGN_CKSUM field (8 bytes) | RFC1964     |
   |               | of the GSS_GetMIC() token in  |             |
   |               | GSS_KRB5_INTEG_C_QOP_ DES_MAC |             |
   |               | QOP (DES MAC)                 |             |
   +-------------------------------------------------------------+
   | SPKM          | the int-cksum field of the    | RFC2025     |
   |               | SPKM-MIC token, calculated    |             |
   |               | without the optional int-alg  |             |
   |               | and snd-seq fields of the     |             |
   |               | mic-header (i.e., the default |             |
   |               | I-ALG is used, and sequencing |             |
   |               | service is not used).         |             |
   +-------------------------------------------------------------+

   Note: the KRB5_* digests are allowed only when combined with KRB5
   authentication method (see below) (i.e., the initiator may offer one of
   these digests only if it also offers KRB5 as AuthMethod, and the target
   may respond with one of these digests only if it also responds with KRB5
   as the AuthMethod). Similarly, the SPKM digest is allowed only when
   combined with SPKM-1 or SPKM-2 authentication methods (see below).

   Other and proprietary algorithms MAY also be negotiated.
   The none value is the only one that MUST be supported.

   The following table details authentication methods:

   +------------------------------------------------------------+
   | Name          | Description                                |
   +------------------------------------------------------------+
   | KRB5          | Kerberos V5                                |
   +------------------------------------------------------------+
   | SPKM-1        | Simple Public-Key GSS-API Mechanism        |
   +------------------------------------------------------------+
   | SPKM-2        | Simple Public-Key GSS-API Mechanism        |
   +------------------------------------------------------------+
   | SRP           | Secure Remote Password                     |
   +------------------------------------------------------------+
   | CHAP          | Challenge Handshake Authentication Protocol|
   +------------------------------------------------------------+
   | none          | No authentication                          |
   +------------------------------------------------------------+

   KRB5 is defined in [RFC1510], SPKM-1, SPKM-2 are defined in
   [RFC2025], Secure Remote Password is defined in [RFC2945] and CHAP is
   defined in [RFC1994].

   Initiator and target MUST implement SRP.

02   Authentication

   The authentication exchange authenticates the initiator to the target,
   and optionally the target to the initiator.  Authentication is not
   mandatory and is distinct from the data integrity exchange.

   The authentication methods to be used are KRB5, SPKM-1, SPKM-2, SRP,
   CHAP, or proprietary.

   For KRB5 (Kerberos V5) [RFC1510], the initiator MUST use:

       KRB_AP_REQ=<KRB_AP_REQ>

   where KRB_AP_REQ is the client message as defined in [RFC1510].

   If the initiator authentication fails, the target MUST return an error.
   Otherwise, if the initiator has selected the mutual authentication
   option (by setting MUTUAL-REQUIRED in the ap-options field of the
   KRB_AP_REQ), the target MUST reply with:

       KRB_AP_REP=<KRB_AP_REP>

   where KRB_AP_REP is the server's response message as defined in
   [RFC1510].

   KRB_AP_REQ,KRB_AP_REP are large binaries encoded as hexadecimal strings.

   For SPKM-1,SPKM-2 [RFC2025], the initiator MUST use:

       SPKM-REQ=<SPKM-REQ>

   where SPKM-REQ is the first initiator token as defined in [RFC2025].

   [RFC2025] defines situations where each side may send an error token
   which may cause the peer to re-generate and resend his last token. This
   scheme is followed in iSCSI, and the error token syntax is:

       SPKM-ERROR=<SPKM-ERROR>

   However, SPKM-DEL tokens that are defined by [RFC2025] for fatal errors
   will not be used by iSCSI. If the target needs (by
   [RFC2025]) to send SPKM-DEL token, it will, instead, send a Login "login
   reject" message and terminate the connection. If the initiator needs to
   send SPKM-DEL token, it will just abort the connection.

   In the sequel, we assume that no SPKM-ERROR tokens are required:

   If the initiator authentication fails, the target MUST return an error.
   Otherwise, if the AuthMethod is SPKM-1 or if the initiator has selected
   the mutual authentication option (by setting mutual-state bit in the
   options field of the REQ-TOKEN in the SPKM-REQ), the target MUST reply
   with:

       SPKM-REP-TI=<SPKM-REP-TI>

   where SPKM-REP-TI is the target token as defined in [RFC2025].

   If mutual authentication was selected and target authentication fails,
   the initiator MUST abort the connection. Otherwise, if the AuthMethod is
   SPKM-1, the initiator MUST continue with:

       SPKM-REP-IT=<SPKM-REP-IT>

   where SPKM-REP-IT is the second initiator token as defined in [RFC2025].

   All the SPKM-* tokens are large binaries encoded as hexadecimal strings.

   For SRP [RFC2945], the initiator MUST use:

      U=<user> TargetAuth=yes   /* or TargetAuth=no */

   The target MUST either return an error or reply with:

      N=<N> g=<g> s=<s>

   The initiator MUST continue with:

      A=<A>

   The target MUST either return an error or reply with:

      B=<B>

   The initiator MUST either abort or continue with:

      M=<M>

   If the initiator authentication fails, the target MUST return an error.
   Otherwise, If the initiator sent TargetAuth=yes in the first message
   (requiring target authentication) the target MUST reply with:

     HM=<H(A | M | K)>

   Where U, N, g, s, A, B, M and H(A | M | K) are defined in [RFC2945].
   U is a text string, N,g,s,A,B,M and H(A | M | K) are numbers.

   For CHAP [RFC1994], the initiator MUST use:

      A=<A1,A2...>

   Where A1,A2... are proposed algorithms, in order of preference.

   The target MUST either return an error or reply with:

      A=<A> I=<I> C=<C>

   Where A is one of A1,A2... that were proposed by the initiator.

   The initiator MUST continue either with:

      N=<N> R=<R>

   or, if he requires target authentication, with:

      N=<N> R=<R> I=<I> C=<C>

   If the initiator authentication fails, the target MUST return an error.
   Otherwise, if the initiator required target authentication, the target
   MUST reply with

      N=<N> R=<R>

   Where N, (A,A1,A2), I, C, R are (correspondingly) the Name, Algorithm,
   Identifier, Challenge and Response as defined in [RFC1994]. N is a text
   string, A,A1,A2,I are numbers and C,R are large binaries encoded as
   hexadecimal strings.

   For the Algorithm, as stated in [RFC1994], one value is required
   to be implemented:
       5       (CHAP with MD5)
   To guarantee interoperability, initiators SHOULD always offer it as one
   of the proposed algorithms.

03   Login Phase Examples

   In the first example, the initiator and target authenticate each other
   via Kerberos:

      I-> Login (CNxSG=0,1 F=1) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      HeaderDigest=KRB5_MD5,KRB5_DES_MAC,crc-32C,none
      DataDigest=crc-32C,none AuthMethod=SRP,KRB5,none

      T-> Login-PR (CNxSG=0,1 F=0) HeaderDigest=KRB5_MD5 DataDigest=crc-32C
      AuthMethod=KRB5

        (Login-PR stands for Login-Partial-Response)

      I-> Text (CNxSG=0,1 F=1) KRB_AP_REQ=<krb_ap_req>
      (krb_ap_req contains the Kerberos V5 ticket and authenticator with
      MUTUAL-REQUIRED set in the ap-options field)

      If the authentication is successful, the target proceeds with:

      T-> Text (CNxSG=0,1 F=1) KRB_AP_REP=<krb_ap_rep>
      (krb_ap_rep is the Kerberos V5 mutual authentication reply)

      If the authentication is successful, the initiator proceeds.

      From this point on, any Text command and each PDU thereafter has a
      KRB5_MD5 digest for the header and a crc-32C for the data.

      The initiator may proceed:

      I-> Text (CNxSG=1,3 F=0) ... iSCSI Operational Parameters
      T-> Text (CNxSG=1,3 F=0) ... iSCSI Operational Parameters

      And at the end:

      I-> Text (CNxSG=1,3 F=1) optional iSCSI parameters
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      T-> Login (CNxSG=1,3 F=1) "login accept"

      If the initiator authentication by the target is not successful, the
      target responds with:

      T-> Login "login reject"

      instead of the Text KRB_AP_REP message, and terminates the
      connection.

      If the target authentication by the initiator is not successful, the
      initiator terminates the connection (without responding to the Text
      KRB_AP_REP message).

   In the next example only the initiator is authenticated by the target
   via Kerberos:

      I-> Login (CNxSG=0,1 F=1) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      HeaderDigest=KRB5_MD5,KRB5_DES_MAC,crc-32C,none
      DataDigest=crc-32C,none AuthMethod=SRP,KRB5,none
      T-> Login-PR (CNxSG=0,1 F=0)HeaderDigest=KRB5_MD5 DataDigest=crc-32C
      AuthMethod=KRB5

      I-> Text (CNxSG=0,1 F=1)KRB_AP_REQ=krb_ap_req
      (MUTUAL-REQUIRED not set in the ap-options field of krb_ap_req)

      If the authentication is successful, the target proceeds with:

      T-> Text (CNxSG=0,1 F=1)

      From this point on, any Text command and each PDU thereafter MUST
      have a KRB5_MD5 digest for the header and a crc-32C for the data.

      I-> Text (CNxSG=1,3 F=0) ... iSCSI parameters
      T-> Text (CNxSG=1,3 F=0)... iSCSI parameters

      . . .

      T-> Login (CNxSG=1,3 F=1)"login accept"
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88

   In the next example, the initiator and target authenticate each other
   via SPKM-1:

      I-> Login (CNxSG=0,1 F=1) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      HeaderDigest=KRB5_MD5,KRB5_DES_MAC,SPKM,crc-32C,none
      DataDigest=crc-32C,SPKM,none AuthMethod=SPKM-1,KRB5,none

      T-> Login-PR (CNxSG=0,1 F=0) HeaderDigest=SPKM DataDigest=SPKM
      AuthMethod=SPKM-1

      I-> Text (CNxSG=0,1 F=0) SPKM-REQ=<spkm-req>
      (spkm-req is the SPKM-REQ token with the mutual-state bit in the
      options field of the REQ-TOKEN set)

      T-> Text (CNxSG=0,1 F=0) SPKM-REP-TI=<spkm-rep-ti>

      If the authentication is successful, the initiator proceeds:

      I-> Text (CNxSG=0,1 F=1) SPKM-REP-IT=<spkm-rep-it>

      If the authentication is successful, the target proceeds with:

      T-> Text (CNxSG=0,1 F=1)

      From this point on, any Text command and each PDU thereafter has SPKM
      digests for the header and data.

      The initiator may proceed:

      I-> Text  (CNxSG=1,3 F=0) ... iSCSI parameters
      T-> Text  (CNxSG=1,3 F=0) ... iSCSI parameters

      And at the end:

      I-> Text  (CNxSG=1,3 F=1) optional iSCSI parameters
      T-> Login (CNxSG=1,3 F=1) "login accept"
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88

      If the target authentication by the initiator is not successful, the
      initiator terminates the connection (without responding to the Text
      SPKM-REP-TI message).

      If the initiator authentication by the target is not successful, the
      target responds with:

      T-> Login "login reject"

      instead of the Text SecurityContextComplete=yes message, and
      terminates the connection.

   In the next example, the initiator and target authenticate each other
   via SPKM-2:

      I-> Login (CNxSG=0,1 F=0) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      HeaderDigest=SPKM,crc-32C,none
      DataDigest=crc-32C,SPKM,none AuthMethod=SPKM-1,SPKM-2

      T-> Login-PR (CNxSG=0,1 F=0) HeaderDigest=SPKM DataDigest=SPKM
      AuthMethod=SPKM-2

      I-> Text (CNxSG=0,1 F=1) SPKM-REQ=<spkm-req>

       (spkm-req is the SPKM-REQ token with the mutual-state bit in the
      options field of the REQ-TOKEN not set)

      If the authentication is successful, the target proceeds with:

      T-> Text (CNxSG=0,1 F=1)

      From this point on, any Text command and each PDU thereafter has SPKM
      digests for the header and data.

      The initiator may proceed:

      I-> Text (CNxSG=1,3 F=0) ... iSCSI parameters
      T-> Text (CNxSG=1,3 F=0) ... iSCSI parameters

      And at the end:

      I-> Text  (CNxSG=1,3 F=1) optional iSCSI parameters
      T-> Login (CNxSG=1,3 F=1) "login accept"
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88

   In the next example, the initiator and target authenticate each other
   via SRP:

      I-> Login (CNxSG=0,1 F=1) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      HeaderDigest=crc-32C,none DataDigest=crc-32C,none
      AuthMethod=KRB5,SRP,none
      T-> Login-PR  (CNxSG=0,1 F=0) HeaderDigest=crc-32C DataDigest=crc-32C
      AuthMethod=SRP

      I-> Text (CNxSG=0,1 F=0) U=<user> TargetAuth=yes
      T-> Text (CNxSG=0,1 F=0) N=<N> g=<g> s=<s>
      I-> Text (CNxSG=0,1 F=0) A=<A>
      T-> Text (CNxSG=0,1 F=0) B=<B>
      I-> Text (CNxSG=0,1 F=1) M=<M>

      If the initiator authentication is successful, the target proceeds:

      T-> Text (CNxSG=0,1 F=1) HM=<H(A | M | K)>

      Where N, g, s, A, B, M, and H(A | M | K) are defined in [RFC2945].

      If the target authentication is not successful, the initiator
      terminates the connection. Otherwise it proceeds.

      From this point on, any Text command and each PDU thereafter has a
      crc-32C digest for the header and the data.

      I-> Text(CNxSG=1,3 F=0) ... iSCSI parameters
      T-> Text(CNxSG=1,3 F=0) ... iSCSI parameters

      And at the end:

      I-> Text (CNxSG=1,3 F=1) optional iSCSI parameters
      T-> Login  (CNxSG=1,3 F=1) "login accept"
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88

      If the initiator authentication is not successful, the target
      responds with:

      T-> Login "login reject"

      Instead of the T-> Text HM=<H(A | M | K)>  message and terminates the
      connection.

   In the next example only the initiator is authenticated by the target
   via SRP:

      I-> Login (CNxSG=0,1 F=1) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      HeaderDigest=crc-32C,none DataDigest=crc-32C,none
      AuthMethod=KRB5,SRP,none
      T-> Login-PR (CNxSG=0,1 F=0) HeaderDigest=crc-32C DataDigest=crc-32C
      AuthMethod=SRP

      I-> Text (CNxSG=0,1 F=0) U=<user> TargetAuth=no
      T-> Text (CNxSG=0,1 F=0) N=<N> g=<g> s=<s>
      I-> Text (CNxSG=0,1 F=0) A=<A>
      T-> Text (CNxSG=0,1 F=0) B=<B>
      I-> Text (CNxSG=0,1 F=1) M=<M>

      If the initiator authentication is successful, the target proceeds:

      T-> Text (CNxSG=0,1 F=1)

      From this point on, any Text command and each PDU thereafter has a
      crc-32C digest for the header and the data.

      I-> Text (CNxSG=1,3 F=0) ... iSCSI parameters
      T-> Text (CNxSG=1,3 F=0) ... iSCSI parameters

      And at the end:

      I-> Text (CNxSG=1,3 F=1) optional iSCSI parameters
      T-> Login (CNxSG=1,3 F=1) "login accept"
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88

   In the next example the initiator and target authenticate each other via
   CHAP:

      I-> Login (CNxSG=0,1 F=0) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      HeaderDigest=crc-32C,none DataDigest=crc-32C,none
      AuthMethod=KRB5,CHAP,none
      T-> Login-PR (CNxSG=0,1 F=0) HeaderDigest=crc-32C DataDigest=crc-32C
      AuthMethod=CHAP

      I-> Text (CNxSG=0,1 F=0) A=<A1,A2>
      T-> Text (CNxSG=0,1 F=0) A=<A1> I=<I> C=<C>
      I-> Text (CNxSG=0,1 F=1) N=<N> R=<R> I=<I> C=<C>

      If the initiator authentication is successful, the target proceeds:

      T-> Text (CNxSG=0,1 F=1) N=<N> R=<R>

      If the target authentication is not successful, the initiator aborts
      the connection. Otherwise it proceeds.

      From this point on, any Text command and each PDU thereafter has a
      crc-32C digest for the header and the data.

      I-> Text (CNxSG=1,3 F=0) ... iSCSI parameters
      T-> Text (CNxSG=1,3 F=0) ... iSCSI parameters

      And at the end:

      I-> Text (CNxSG=1,3 F=1) optional iSCSI parameters
      T-> Login (CNxSG=1,3 F=1) "login accept"
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88

      If the initiator authentication is not successful, the target
      responds with:

      T-> Login "login reject"

      Instead of the Text R=<response> SecurityContextComplete=yes
      message and terminates the connection.

   In the next example only the initiator is authenticated by the target
   via CHAP:

      I-> Login (CNxSG=0,1 F=0) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      HeaderDigest=crc-32C,none DataDigest=crc-32C,none
      AuthMethod=KRB5,CHAP,none
      T-> Login-PR (CNxSG=0,1 F=0) HeaderDigest=crc-32C DataDigest=crc-32C
      AuthMethod=CHAP

      I-> Text (CNxSG=0,1 F=0) A=<A1,A2>
      T-> Text (CNxSG=0,1 F=0) A=<A1> I=<I> C=<C>
      I-> Text (CNxSG=0,1 F=1) N=<N> R=<R>

      If the initiator authentication is successful, the target proceeds:

      T-> Text (CNxSG=0,1 F=1)
      I-> Text (CNxSG=1,3 F=0) ... iSCSI parameters
      T-> Text (CNxSG=1,3 F=0) ... iSCSI parameters

      And at the end:

      I-> Text (CNxSG=1,3 F=1) optional iSCSI parameters
      T-> Login (CNxSG=1,3 F=1) "login accept"
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88

   In the next example, the initiator does not offer any security/integrity
   parameters, so it may offer iSCSI parameters on the Login PDU with the F
   bit set to 1, and the target may respond with a final Login Response PDU
   immediately:

      I-> Login (CNxSG=1,3 F=1) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88  ... iSCSI parameters
      T-> Login (CNxSG=1,3 F=1) "login accept"
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88  ... ISCSI parameters

   In the next example, the initiator does offer security/integrity
   parameters on the Login PDU, but the target does not choose any (i.e.,
   chooses the "none" values):

      I-> Login (CNxSG=0,1 F=1) InitiatorName=iqn.1999-07.com.os.hostid.77
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88
      HeaderDigest=crc-32C,none DataDigest=crc-32C,none
      AuthMethod:KRB5,SRP,none
      T-> Login-PR (CNxSG=0,1 F=1) HeaderDigest=none, DataDigest=none,
      AuthMethod=none

      I-> Text (CNxSG=1,3 F=0) ... iSCSI parameters
      T-> Text (CNxSG=1,3 F=0) ... iSCSI parameters

      And at the end:

      I-> Text (CNxSG=1,3 F=1) optional iSCSI parameters
      T-> Login (CNxSG=1,3 F=1) "login accept"
      TargetName=iqn.1999-07.com.acme.diskarray.sn.88

    Julo

---

From: Steve Senum <[email-masked]>
Date: Fri, 24 Aug 2001 17:54:47 -0500

Hi Julian,

A have two questions on your proposal with respect to the
new CNxSG field.

>    offered one by the initiator.

I assume from this that the target must always return the
same "current stage" as the initiator, so there is no
way for the stages to go backwards (which is fine with me).

>    SecurityNegotiation in the current stage and LoginOperationalNegotiation

So, if the initiator opens with:

I-> Login (CNxSG=0,1 F=1)

And the target responds with:

T-> Login-PR (CNxSG=0,1 F=0) AuthMethod=CHAP

And the initiator responds with:

I-> Text (CNxSG=0,1 F=0) AuthMethod=CHAP

The target should respond with a blank text message?

T-> Text (CNxSG=0,1 F=0)

Since all of the AuthMethods in Appendix A specify
that the initiator MUST start the authentication sequence
(which is fine with me).

Regards,
Steve Senum