Re: iSCSI: SecurityContextComplete without operational parameters

["Robert D. Russell" <rdr@mars.iol.unh.edu>]

Julian:

As a further simplification to the login process, I believe the
InitiatorName and TargetName keys should both be required in the
login command sent by the initiator.

According to draft 7 page 158 and 159, these keys already
"MUST be provided by the initiator of the TCP connection to the remote
endpoint before the end of the login phase", and given that there is
now a separate session type for discovery, I don't see any benefit in
allowing the initiator to postpone sending these keys beyond the login
command itself, and I do see lots of simplification possible if they
are required on the login.  (Could you please give me a situation for
"normal" logins where there is a benefit to not having these keys in
the login? Does that benefit outweigh the simplifications I am suggesting
here?)

This change simplifies the wording just quoted, which becomes
"MUST be provided on the login command".

It also eliminates the phrase "Some targets MAY require this key before
authenticating." that is currently in the description of the 13 TargetName
key on page 158 of draft 7.

It also eliminates the phrase "the iSCSI Initiator Name MUST be sent
before the target is required to disclose its LUs." in section 4.1 on
page 99 of draft 7.

It also eliminates the phrase "If the iSCSI Target Name is going to be used
in determining the security mode or it is implicit part of authentication,
then the iSCSI Target Name MUST be sent in the login command for the first
connection of a session to identify the storage endpoint of the session."
in section 4.1 on page 99 of draft 7.

It also eliminates the phrase "If the iSCSI Target Name is going to be used
only for access control, it can be sent after the Security Context Complete
is achieved." in section 4.1 on page 99 of draft 7.

It also eliminates the need for status code 0x0002 in the login response
(page 73 of draft 7).

It is also my belief that coding for the login phase is simplified by this
requirement, due to the following:

  In draft 7 a target MAY need to check the login to see if it contains the
  TargetName in order to set the status code in the login response,
  and if it is missing, may need to go into a "wait for TargetName"
  state before proceeding with security checking.

  In the new version a target MUST check the login to see if it contains
  the TargetName (and InitiatorName) keys and can immediately reject
  the connection if they are missing -- no new target state is needed.

  The wording quoted above from section 4.1 talks about how these keys
  "may" be used by the target.  The problems that I see with this current
  wording is there is no way for the initiator to know in advance how the
  target will use the information (so it doesn't know exactly when in the
  login sequence to send them), and there is no way for the target to
  inform the initiator about this in advance -- the initiator must simply
  try something and hope it works.  If it doesn't, in most cases the
  connection will be rejected with "parameters missing".  Of course,
  in the case when the TargetName is missing on the login, the partial login
  response has a special code to inform the initiator of the problem --
  but suppose the target also needs the InitiatorName?  How does the
  target inform the initiator of that?  There currently does not seem to
  be a way, so after responding to the login partial response with the
  TargetName the initiator will still find the connection dropped anyway.

  I believe as a result of this complexity, most initiators will simply
  send both the TargetName and InitiatorName keys on the login command
  anyway (is there a good reason not to?), and so requiring that they
  MUST be on the login is not a hardship and will bring about the
  simplifications I just mentioned.

Thanks for your consideration,

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