|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI login phasing
> The security purists will object (with good reason) to the names being
> disclosed before security is established
> when they are not needed for security.
>
> Mandating always 2 phases is wastefull for those cases in which the
> security negotiation is in fact bypassed.
>
> Stating the phase explicitly solves both those problems.
>
> Julo
Julian:
1. Requiring the InitiatorName and TargetName keys on the login is
independent of whether the phase is stated explicitly.
a) If the phase is explicitly stated, we could still mandate that
these keys always be required in the security phase.
This makes your proposal identical to mine with respect to
this issue.
b) If the phase is not explicitly stated, we could drop the mandate
that these keys always be required. This makes my proposal identical
to yours with respect to this issue.
As you state, security purists would argue that these keys not be
required before security is established. Fine, but that does not
argue either for or against your new proposal to explicitly state
the phase.
2. Your new proposal to require a handshake at the end of both the
security phase and the operational phase can also be considered
wasteful, because now it will require two handshakes when
both security and operational parameters are to be negotiated,
whereas only one handshake is required in my approach.
To compare the two approaches:
a) No security, no operational:
New proposal - no handshakes (if this is legal, see below)
Previous proposal - 1 handshake
b) Security, no operational:
New proposal - 1 handshake
Previous proposal - 1 handshake
c) No security, operational:
New proposal - 1 handshake
Previous proposal - 1 handshake
d) Security, operational
New proposal - 2 handshakes
Previous proposal - 1 handshake
So which is more wasteful -- your new proposal that requires 2 handshakes
in case d, or my previous proposal that requires 1 handshake in case a?
Note also that my previous proposal always required exactly 1 handshake,
wherease your new proposal has a varying number, depending on the context.
3. I do not believe the new proposal solves either problem, nor do I believe
it simplifies anything. Attached is an ASCII text file containing the
state diagram of the target for your new proposal as I interpret it,
and I would welcome your comments/corrections to it, as I may not be
interpreting it correctly.
If my interpretation of your new proposal is correct, then your target
requires 7 states and 14 transitions, instead of 5 states and 7
transitions in my previous target state diagram. Clearly the previous
target is simpler by the measure of the number of states and/or the
number of transitions. I have not had time to produce a detailed
diagram for the initiator, but your proposal does not seem to either
add or delete states from my previous initiator state diagram.
To make this new diagram easier to compare with my previous diagram
for the target, I labeled the new states T6 and T7, and the new
transitions Z8 through Z14. If this new proposal is accepted,
I would certainly relabel the states and transitions to be easier
to follow.
In his e-mail of 27-July Steve Senum asked 2 questions, which I repeat
here:
1. Is the Initiator required to start with either a
SecurityPhase=start or an OperationalPhase=start
on the initial login command?
2. If the Initiator started with OperationalPhase=start,
does the target have any way to force a SecurityPhase=start?
In your reply of 28-July you did not answer either question directly,
so I am assuming that the answer to both questions is No.
Is this a correct assumption?
If this is not true for question 1, (i.e., if the login must
contain either SecurityPhase=start or OperationalPhase=start), then
just eliminate the transition labeled Z9 in my new diagram.
If this is not true for question 2, (i.e., if the target can
force SecurityPhase=start), then there will be a need to add
additional states and/or transitions to the new diagram.
One final point about simplification -- your new proposal requires
the addition of 4 new key-value pairs (SecurityPhase=start,
SecurityPhase=end, OperationalPhase=start, OperationalPhase=end) and
the elimination of 1 existing key-value pair (SecurityContextComplete=yes).
My proposal keeps the SecurityContextComplete=yes key, and introduces no
new keys. (I believe the OpParmReset key would be eliminated in both
proposals.) Which is simpler and by what measure? Clearly there is a
direct cost to your proposal in terms of added states and transitions.
Comments please.
Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774
Login Phase Processing for an iSCSI Target
Based on the proposal by Julian Satran in his e-mail of 27-July
The target has 7 states:
T1: Await Login
T2: Negotiate Security
T3: Leave Security
T6: Await Continuation
T4: Negotiate Operational
T7: Leave Operational
T5: Full Feature Phase
There are 14 allowed transitions:
From \ To-> T1 | T2 | T3 | T4 | T5 | T6 | T7 |
------\---+--------+-------+-------+-------+-------+-------+-------+
T1 | | Z1 | | Z8 | Z9 | | Z10 |
-------+--------+-------+-------+-------+-------+-------+-------+
T2 | | Z2 | Z3 | | | Z4 | |
-------+--------+-------+-------+-------+-------+-------+-------+
T3 | | | | | | Z5 | |
-------+--------+-------+-------+-------+-------+-------+-------+
T6 | | | | Z11 | Z12 | | Z13 |
-------+--------+-------+-------+-------+-------+-------+-------+
T4 | | | | | | | Z14 |
-------+--------+-------+-------+-------+-------+-------+-------+
T7 | | | | Z6 | Z7 | | |
-------+--------+-------+-------+-------+-------+-------+-------+
T5 | | | | | | | |
-------+--------+-------+-------+-------+-------+-------+-------+
Initial state:
T1 - entered when Target successfully accepts a TCP connection with an
initiator
Final state:
T5 - a transition into this state enters Full Feature Phase
Transitions:
Z1: Taken when: Target receives Login Command from initiator with F=0,
with SecurityPhase=start,
optionally with SessionType=Normal key, and with
security keys offered by initiator
Action: Send Login Response
with F=0
and with status=0x0001 or 0x0002 as appropriate
and with replies to security keys offered by initiator
and with any additional security keys to offer to initiator
Z2: Taken when: Target receives Text Command from initiator with F=0,
with any replies to security keys offered on Z1 or
Z2, and with any security keys offered by initiator,
and possibly with SecurityPhase=end key
and Target wants to offer additional security keys to
initiator that require a reply from initiator
Action: Send Text Response
with F=0
and with any replies to security keys offered by initiator
and with any additional security keys to offer to initiator
Z3: Taken when: Target receives Text Command from initiator with F=0,
with any replies to security keys offered on Z1 or Z2,
and with any security keys offered by initiator
and Target does not want to offer additional security keys
to initiator that require a reply from initiator
Action: Send Text Response
with F=0
and with any replies to security keys offered by initiator
and with any additional security keys to offer to initiator
and with SecurityPhase=end
Z4: Taken when: Target receives Text Command from initiator with F=0,
with any replies to security keys offered on Z1 or Z2,
and with any security keys offered by initiator
and with SecurityPhase=end
and Target does not need to reply to security keys from
initiator
and Target does not want to offer additional security keys
to initiator
Action: 1. Send Text Response
with F=0
and with SecurityPhase=end as only key
2. Put all negotiated security measures into effect
Z5: Taken when: Target receives Text Command from initiator with F=0
and with SecurityPhase=end as only key
Action: Same as actions on Z4
Z6: Taken when: Target receives Text Command from initiator with F=1,
with any replies to operational keys target offered
on Z14, and with any operational keys offered by
initiator
and Target wants to offer additional operational keys
that require a reply from initiator
Action: Send Text Response
with F=0
and with any replies to operational keys offered by
initiator
and with all additional operational keys to offer to
initiator
Z7: Taken when: Target receives Text Command from initiator with F=1,
with any replies to operational keys target offered
on Z12 or Z14, with any operational keys offered by
initiator that do not require a reply from target, and
with OperationalPhase=end key
and Target does not want to offer additional operational
keys that require a reply from initiator
Action: Send Login Response
with F=1
and with status=0x0000
and with OperationalPhase=end as only key
Z8: Taken when: Target receives Login Command from initiator with F=0,
with OperationalPhase=start, and with any operational
keys offered by initiator
and Target wants to offer additional operational keys
that require a reply from initiator
Action: Send Login Response
with F=0
and with status=0x0001 or 0x0002 as appropriate
and with any replies to operational keys offered by initiator
and with all additional operational keys to offer to initiator
Z9: Taken when: Target receives Login Command from initiator with F=1,
and no security or operational keys offered by initiator
and Target does not want to offer additional operational keys
that require a reply from initiator
Action: Send Login Response
with F=1
and with status=0x0000
and with only informational keys to offer to initiator
Z10:Taken when: Target receives Login Command from initiator with F=0,
with OperationalPhase=start, and with any operational
keys offered by initiator
and Target does not want to offer additional operational keys
that require a reply from initiator
Action: Send Login Response
with F=0
and with status=0x0001 or 0x0002 as appropriate
and with any replies to operational keys offered by initiator
and with all additional operational keys to offer to initiator
(that do not require a reply from initiator)
and with OperationalPhase=end
Z11:Taken when: Target receives Text Command from initiator with F=0,
with OperationalPhase=start, and with any operational
keys offered by initiator
and Target wants to offer additional operational keys
that require a reply from initiator
Action: Same as action on Z6
Z12:Taken when: Target receives Text Command from initiator with F=1,
and no operational keys offered by initiator
Action: Send Login Response
with F=1
and with status=0x0000
and with only informational keys to offer to initiator
Z13:Taken when: Target receives Text Command from initiator with F=0,
with OperationalPhase=start, and with any operational
keys offered by initiator
and Target does not want to offer additional operational keys
that require a reply from initiator
Action: Send Text Response
with F= 0
and with any replies to operational keys offered by initiator
and with all additional operational keys to offer to initiator
(that do not require a reply from initiator)
and with OperationalPhase=end
Z14:Taken when: Target receives Text Command from initiator with F=0,
with replies to operational keys offered in Z6 or Z11,
and with any operational keys offered by initiator
and Target does not want to offer additional operational keys
that require a reply from initiator
Action: Same as action on Z13
Home Last updated: Tue Sep 04 01:04:08 2001 6315 messages in chronological order |