|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] iSCSI - Login changes and the latest agreementsHere are the latest Login changes including the new consensus items. Julo (See attached file: Login-changes.txt)
1.2.3 iSCSI Login
The purpose of the iSCSI login is to enable a TCP connection for iSCSI use, authenticate the parties, negotiate the session's parameters, open a security association protocol, and mark the connection as belonging to an iSCSI session.
A session is used to identify to a target all the connections with a given initiator that belong to the same I_T nexus (See 1.5.2 for more details on how a session relates to an I_T nexus).
The targets listen on a well-known TCP port or other TCP port for incoming connections. The initiator begins the login process by connecting to that well-known TCP port.
As part of the login process, the initiator and target MAY wish to authenticate each other and set a security association protocol for the session. This can occur in many different ways and is subject to negotiation.
Security associations established before the Login request are outside the scope of this document although they may realize a related function (e.g., establish a IPsec tunnel).
The iSCSI Login Phase is carried through Login requests and responses. Once suitable authentication has occurred and operational parameters have been set the initiator may start to send SCSI commands. How the target chooses to authorize an initiator is beyond the scope of this document. A more detailed description of the Login Phase can be found in chapter 4.
The login PDU includes a session ID that is composed of an initiator part ISID and a target part TSID. For a new session, the TSID is null. As part of the response, the target generates a TSID.
During session establishment, the target identifies the SCSI initiator port (the "I" in the "I_T nexus") through the value pair InitiatorName and ISID (InitiatorName is described later in this part). Any state associated with the SCSI initiator port that is persistent according to the SCSI standards (e.g., persistent reservations) is associated with the SCSI initiator port based on this identity. Any state associated with the SCSI target port (the "T" in the "I_T nexus") is identified externally by the TargetName and portal group tag (see 1.5.1) and internally in an implementation dependent way. As ISID is used to identify persistent state it is subject to reuse restrictions (see 1.5.3).
Before full feature phase is established, only Login PDUs are allowed. Any other PDU, when received at initiator or target, is a protocol error and MUST result in the connection being terminated.
Some text command parameters are also allowed only in full feature phase (e.g., SendTargets).
---------------------------
2.12 Login Request
After establishing a TCP connection between an initiator and a target, the initiator MUST start a Login phase to gain further access to the target's resources.
The Login Phase (see chapter 4) consists of a sequence of Login requests and responses) that carry the same Initiator Task Tag.
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|C 0 0| CNxSG | Version-max | Version-min |
+---------------+---------------+---------------+---------------+
4| Reserved | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| CID | Reserved |
+---------------+---------------+---------------+---------------+
12| ISID |TSID |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Reserved |
+---------------+---------------+---------------+---------------+
24| CmdSN |
+---------------+---------------+---------------+---------------+
28| ExpStatSN or Reserved |
+---------------+---------------+---------------+---------------+
32/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48/ DataSegment - Login Parameters in Text Command Format /
+/ /
+---------------+---------------+---------------+---------------+
2.12.1 X - Restart Connection/Session
If this bit is set to 1 then this command is an attempt to reinstate a failed connection or a failed session.
If TSID is not 0 then this is a connection restart. 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 MUST be issued as an immediate command.
The X bit MAY be set one ONLY on the first request of the Login phase.
2.12.2 I - Immediate
Login SHOULD be issued as an immediate request (I=1).
2.12.3 F (Final) Bit
If set to 1 indicates that the initiator has no more parameters to set.
2.12.4 C (Continuation) Bit
If set to 1 indicates that this is not the first Login request in the Login Phase
2.12.5 CNxSG
Through this field, called Current-Next Stage (CNxSG), the Login negotiation commands and responses are associated with a specific stage in the session (SecurityNegotiation, LoginOperationalNegotiation, FullPhaseOperationalNegotiations) and may indicate the next stage they want to move to (see chapter 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 - FullFeaturePhase
2.12.6 Version-max
Maximum Version number supported.
All Login requests within the Login phase MUST carry the same Version-max.
The target MUST use the value presented with the login request with C=0 and MAY check the value when C=1.
2.12.7 Version-min
Minimum Version supported
The version number of the current draft is 0x2.
All Login requests within the Login phase MUST carry the same Version-min.
The target MUST use the value presented with the login request with C=0 and MAY check the value when C=1.
2.12.8 Connection ID - CID
This is a unique ID for this connection within the session.
All Login requests within the Login phase MUST carry the same CID.
The target MUST use the value presented with the login request with C=0 and MAY check the value when C=1.
2.12.9 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 detects 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 close the old session and a establish a new session.
All Login requests within the Login phase MUST carry the same ISID.
The target MUST use the value presented with the login request with C=0 and MAY check the value when C=1.
2.12.10 TSID
The TSID is a tag (set by the target) that together with the
ISID identifies a unique session with the initiator. On a Login request a TSID value of 0 indicates a request to open a new session.
A non zero TSID indicates a request to add a connection to an existing session.
2.12.11 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.).
2.12.12 ExpStatSN
This is ExpStatSN for the old connection.
This field is valid only if the Login request restarts a connection (i.e., X bit is 1 and TSID is not zero).
2.12.13 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.
2.13 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 | DataSegmentLength |
+---------------+---------------+---------------+---------------+
8| Reserved |
+---------------+---------------+---------------+---------------+
12| ISID |TSID |
+---------------+---------------+---------------+---------------+
16| Initiator Task Tag |
+---------------+---------------+---------------+---------------+
20| Reserved |
+---------------+---------------+---------------+---------------+
24| StatSN |
+---------------+---------------+---------------+---------------+
28| ExpCmdSN |
+---------------+---------------+---------------+---------------+
32| MaxCmdSN |
+---------------+---------------+---------------+---------------+
36| Status-Class | Status-Detail | Reserved |
+---------------+---------------+---------------+---------------+
40/ Reserved /
+/ /
+---------------+---------------+---------------+---------------+
48| Digests if any... |
+---------------+---------------+---------------+---------------+
/ DataSegment - Login Parameters in Text Command Format /
+/ /
+---------------+---------------+---------------+---------------+
2.13.1 F (Final) bit
Final bit is set to 1 as an indicator of end of stage. If the next stage part in CNxSG is FullFeaturePhase and the F bit is set to 1 then this is also the Final Login Response (see chapter 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.
2.13.2 Version-max
This is the highest version number supported by the target.
All Login responses within the Login phase MUST carry the same Version-max.
The initiator MUST use the value presented as response to the login request with C=0 and MAY check the value otherwise.
2.13.3 Version-active
Indicates the version supported (the highest version supported by the target and initiator). If the target does not support 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.
All Login responses within the Login phase MUST carry the same Version-active.
The initiator MUST use the value presented as response to the login request with C=0 and MAY check the value otherwise.
2.13.4 TSID
The TSID is a tag set by the target that together with the
ISID identifies a unique session with the initiator. It MUST be valid only in the final response.
2.13.5 StatSN
For the first Login Response (the response to a Login Request with C=0) 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.
2.13.6 Status-Class and Status-Detail
The Status returned in a Login Response indicates the execution status of the login phase. 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. The request should not be tried again.
3 - Target Error - indicates that the target sees no errors in the initiator’s login request, but is currently incapable of fulfilling the request. The client may re-try the same login request later.
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.
-----------------------------------------------------------------
Initiator | 0200 | 1 | Miscellaneous iSCSI initiator
Error | | | errors
-----------------------------------------------------------------
Authentication| 0201 | 1 | The initiator could not be
Failure | | | successfully authenticated.
-----------------------------------------------------------------
Authorization | 0202 | 1 | The initiator is not allowed access
Failure | | | 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.
-----------------------------------------------------------------
Unsupported | 0205 | 1 | The requested iSCSI version range is
Version | | | not supported by the target.
-----------------------------------------------------------------
Initiator | 0206 | 1 | Invalid SID - 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 type | 0209 | 1 | Target does not support this type of
Not supported | | | of session (not from this Initiator)
-----------------------------------------------------------------
Target Error | 0300 | 1 | Target hardware or software error.
| | |
-----------------------------------------------------------------
Service | 0301 | 1 | The iSCSI service or target is not
Unavailable | | | currently operational.
-----------------------------------------------------------------
Out of | 0302 | 1 | The target has insufficient session,
Resources | | | connection, or other resources.
-----------------------------------------------------------------
(*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 FullFeaturePhase). If the response F bit is 1 (the next stage part is also FullFeaturePhase in both the request and the response) 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.
---------------------
4. 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 request 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 initial request (C bit set to 0)
- Login partial response (optional)
- More Login requests and responses (optional)
- Login Final-Response (mandatory)
The initial Login request MUST include the InitiatorName and SessionType key=value pairs. If the SessionType is not "discovery" then the initial Login Request MUST also include the key=value pair TargetName.
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 requests 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.
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 request 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 request 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 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 with the F bit set to 1 and both the command and response MUST have FullFeaturePhase in the next stage part of the CNxSG field.
4.1 Login Phase Start
The login phase starts with a login request from the initiator to the target. The initial 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
-The C bit set to 0 (first login request on a connection)
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 FullFeaturePhase). 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 reply 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 FullFeaturePhase 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 FullFeaturePhase 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.
4.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 request 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 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.
4.3 Operational Parameter Negotiation During the Login Phase
Operational parameter negotiation during the login MAY be done:
- starting with the first Login request 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 Login request-response exchanges 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 Login request with the F bit set to 1, with a Login response with the F bit set to 0, the initiator must keep sending the Login request (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 on other parameters the dependent parameters MUST be sent after the parameters they depend on. If they are sent within the same command a response for a parameter might imply responses for others.
An initiator MUST send a single Login request with the C bit set to 0 per connection, per session.
Session specific parameters can be specified only during the login phase begun by a login command containing a null TSID (e.g., the maximum number of connections that can be used for this session). Connection specific parameters, if any, can be specified during the login phase begun by any login command. Thus, a session is operational once it has at least one connection.
For a list of operational parameters, see Appendix D.
----------------------------
003 Login Phase Examples
In the first example, the initiator and target authenticate each other via Kerberos:
I-> Login (C=0, 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=SRP,KRB5,none
T-> Login (CNxSG=0,1 F=0)
HeaderDigest=CRC-32C
DataDigest=CRC-32C
AuthMethod=KRB5
I-> Login (C=1, 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-> Login (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 Login command and each PDU thereafter MUST have CRC-32C digests for the header and the data.
The initiator may proceed:
I-> Login (C=1, CNxSG=1,3 F=0)
... iSCSI Operational Parameters
T-> Login (CNxSG=1,3 F=0)
... iSCSI Operational Parameters
And at the end:
I-> Login (C=1, 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 Login 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 Login KRB_AP_REP message).
In the next example only the initiator is authenticated by the target via Kerberos:
I-> Login (C=0, 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=SRP,KRB5,none
T-> Login-PR (CNxSG=0,1 F=0)
HeaderDigest=CRC-32C
DataDigest=CRC-32C
AuthMethod=KRB5
I-> Login (C=1, 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-> Login (CNxSG=0,1 F=1)
From this point on, any Login command and each PDU thereafter MUST have CRC-32C digests for the header and the data.
I-> Login (C=1, CNxSG=1,3 F=0)
... iSCSI parameters
T-> Login (C=1, 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 (C=0, 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=SPKM-1,KRB5,none
T-> Login (CNxSG=0,1 F=0)
HeaderDigest=CRC-32C
DataDigest=SPKM
AuthMethod=SPKM-1
I-> Login (C=1, 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-> Login (CNxSG=0,1 F=0)
SPKM-REP-TI=<spkm-rep-ti>
If the authentication is successful, the initiator proceeds:
I-> Login (C=1, CNxSG=0,1 F=1)
SPKM-REP-IT=<spkm-rep-it>
If the authentication is successful, the target proceeds with:
T-> Login (CNxSG=0,1 F=1)
From this point on, any Login command and each PDU thereafter MUST have CRC-32C digests for the header and the data.
The initiator may proceed:
I-> Login (C=1, CNxSG=1,3 F=0) ... iSCSI parameters
T-> Login (CNxSG=1,3 F=0) ... iSCSI parameters
And at the end:
I-> Login (C=1, 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 Login 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 Login SecurityContextComplete=yes message, and terminates the connection.
In the next example, the initiator and target authenticate each other via SPKM-2:
I-> Login (C=0, 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=SPKM-1,SPKM-2
T-> Login-PR (CNxSG=0,1 F=0)
HeaderDigest=CRC-32C
DataDigest=CRC-32C
AuthMethod=SPKM-2
I-> Login (C=1, 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-> Login (CNxSG=0,1 F=1)
From this point on, any Login command and each PDU thereafter MUST have CRC-32C digests for the header and the data.
The initiator may proceed:
I-> Login (C=1, CNxSG=1,3 F=0)
... iSCSI parameters
T-> Login (CNxSG=1,3 F=0)
... iSCSI parameters
And at the end:
I-> Login (C=1, 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 (C=0, 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 (C=1, CNxSG=0,1 F=0)
HeaderDigest=CRC-32C
DataDigest=CRC-32C
AuthMethod=SRP
I-> Login (C=1, CNxSG=0,1 F=0)
U=<user>
TargetAuth=yes
T-> Login (CNxSG=0,1 F=0)
N=<N>
g=<g>
s=<s>
I-> Login (C=1, CNxSG=0,1 F=0)
A=<A>
T-> Login (CNxSG=0,1 F=0)
B=<B>
I-> Login (C=1, CNxSG=0,1 F=1)
M=<M>
If the initiator authentication is successful, the target proceeds:
T-> Login (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 Login command and each PDU thereafter MUST have CRC-32C digests for the header and the data.
I-> Login (C=1, CNxSG=1,3 F=0)
... iSCSI parameters
T-> Login (CNxSG=1,3 F=0)
... iSCSI parameters
And at the end:
I-> Login (C=1, 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-> Login 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 (C=0, 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-> Login (C=1, CNxSG=0,1 F=0)
U=<user>
TargetAuth=no
T-> Login (CNxSG=0,1 F=0)
N=<N>
g=<g>
s=<s>
I-> Login (C=1, CNxSG=0,1 F=0)
A=<A>
T-> Login (CNxSG=0,1 F=0)
B=<B>
I-> Login (C=1, CNxSG=0,1 F=1)
M=<M>
If the initiator authentication is successful, the target proceeds:
T-> Login (CNxSG=0,1 F=1)
From this point on, any Login command and each PDU thereafter MUST have CRC-32C digests for the header and the data.
I-> Login (C=1, CNxSG=1,3 F=0)
... iSCSI parameters
T-> Login (C=1, CNxSG=1,3 F=0)
... iSCSI parameters
And at the end:
I-> Login (C=1, 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 (C=0, 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-> Login (C=1, CNxSG=0,1 F=0)
A=<A1,A2>
T-> Login (CNxSG=0,1 F=0)
A=<A1>
I=<I>
C=<C>
I-> Login (C=1, CNxSG=0,1 F=1)
N=<N>
R=<R>
I=<I>
C=<C>
If the initiator authentication is successful, the target proceeds:
T-> Login (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 Login command and each PDU thereafter MUST have CRC-32C digests for the header and the data.
I-> Login (C=1, CNxSG=1,3 F=0)
... iSCSI parameters
T-> Login (CNxSG=1,3 F=0)
... iSCSI parameters
And at the end:
I-> Login (C=1, 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 Login 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 (C=0, 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-> Login (C=1, CNxSG=0,1 F=0)
A=<A1,A2>
T-> Login (CNxSG=0,1 F=0)
A=<A1>
I=<I>
C=<C>
I-> Login (C=1, CNxSG=0,1 F=1)
N=<N>
R=<R>
If the initiator authentication is successful, the target proceeds:
T-> Login (CNxSG=0,1 F=1)
I-> Login (C=1, CNxSG=1,3 F=0)
... iSCSI parameters
T-> Login (CNxSG=1,3 F=0)
... iSCSI parameters
And at the end:
I-> Login (C=1, 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 (C=0, 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 (C=0, 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-> Login (C=1, CNxSG=1,3 F=0)
... iSCSI parameters
T-> Login (CNxSG=1,3 F=0)
... iSCSI parameters
And at the end:
I-> Login (C=1, 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
Home Last updated: Wed Sep 12 17:17:13 2001 6523 messages in chronological order |