SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: SecurityContextComplete without operational parameters



    Robert,
    
    I DO UNDERSTAND both the complexity of writing and implementing a protocol.
    I do also understand that as long as we require negotiations to be atomic
    with regard to a complete sequence
    buffering and keeping temporary values must be implemented anyhow and
    adding restrictions does not simplify the task - as any restriction in the
    protocol adds a test.
    
    What I really do not understand is your apparent belief that by making the
    language of your statements "stronger" your will make your arguments more
    convincing.
    
    Julo
    
    "Robert D. Russell" <rdr@mars.iol.unh.edu> on 25-07-2001 21:07:26
    
    Please respond to "Robert D. Russell" <rdr@mars.iol.unh.edu>
    
    To:   Julian Satran/Haifa/IBM@IBMIL
    cc:   ips@ece.cmu.edu
    Subject:  Re: iSCSI: SecurityContextComplete without operational parameters
    
    
    
    
    Julian:
    
    I think this exchange between you and Eddy illustrates the fundamental
    problem with login that everyone at the plugfest realized:
    the login process is too complex, we need to simplify it.
    
    Eddy was asking for a simplification -- that operational parameters
    NOT be sent with SCC=yes.  The change you made does not do that,
    and the response you gave below "If not you should be able to
    handle them as you should be able to handle any set of parameters
    on the same PDU." illustrates to me that you do not understand the
    problem, which is that login is too complex "to handle any set of
    parameters on the same PDU".  The combinations and misinterpretations
    of these combinations are horrendous.  It needs to be simplified,
    and that is what Eddy is asking -- do NOT allow these arbitrary
    combinations.
    
    In the rewording you added the phrase "that need to be protected" in
    two places.  Please remove that phrase from both places,
    because it defeats the whole purpose of the change and introduces more
    ambiguity -- who decides what needs to be protected and what
    doesn't?  Suppose the target decides one thing and the initiator the
    other?  Where is the defined list of parameters that "need" to be
    protected and those that do not "need" to be protected.  etc.
    
    A big simplification is one requested a long time back by
    Barry Reinhold and recently reiterated in a new request by
    Rod Harrison of Wind River, which I strongly support, to mandate
    that the login PDU MUST only contain security parameters -- no
    operational parameters.  Then the login MUST ALWAYS start with
    the security subphase, and MUST end with a handshake of messages
    that contained ONLY SecurityContextComplete from both target and
    initiator.  Only then would the operational parameter negotiation
    start.  I would also add to this recommendation that for normal
    logins (as opposed to discovery logins) the login MUST ALWAYS
    contain the TargetName and InitiatorName keys too.  Furthermore,
    if the SessionType parameter is offered, it MUST be offered on
    the login.
    
    These changes would also clean up the wording in the standard, because:
    
    1. By prohibiting any operational parameter negotiation before the
       security subphase was completed, there would be no need for the
       new OpParmReset key (there is no way they could have changed).
    
    2. By prohibiting any operational parameter negotiation before the
       security subphase was completed, there would be no need for the
       wording in 4.3 that talks about "Operational parameters negotiated
       inadvertently before the security/integrity negotiation"
       (a standard really shouldn't be allowing "inadvertent" things to
       happen).
    
    3. The discussion in 4.1 about the TargetName and InitiatorName would
       be considerably simplified, since there would be no need for
       phrases like "If the iSCSI Target Name is going to be used in
       determining the security mode or it is implicit part of
       authentication," because it should just ALWAYS be sent.
       Phrases like the one just quoted cause enormous interoperability
       problems, because they introduce ambiguity that different
       implementers can resolve in different ways (who determines if
       the TargetName is going to be used? How? Who determines if it is
       implicit? How? etc.)
    
    I believe these suggestions, most of which have been made before,
    would simplify the login process.  This is done by placing restrictions
    on what can be done when.  It may involve the exchange of a few
    extra PDUs (ie. the text commands containing only
    SecurityContectComplete=yes), but logins are not part of the critical
    fast path and are not under tight time constraints -- it is more
    important that they be correct, unambiguous and easily interoperable
    than that they be superfast.
    
    Thank you,
    
    Bob Russell
    InterOperability Lab
    University of New Hampshire
    rdr@iol.unh.edu
    603-862-3774
    
    
    On Wed, 25 Jul 2001, Julian Satran wrote:
    
    > Eddy,
    >
    > I understood what you are asking but I don't necessarily agree.
    Operational
    > parameters are problematic if you want them exchanged in a secure
    > environment. If not you should be able to handle them as you should be
    able
    > to handle
    > any set of parameters on the same PDU. The need to keep them and perhaps
    > reset them is part of the negotiation process.
    >
    > Julo
    >
    > "Eddy Quicksall" <ESQuicksall@hotmail.com> on 24-07-2001 20:35:18
    >
    > Please respond to "Eddy Quicksall" <ESQuicksall@hotmail.com>
    >
    > To:   Julian Satran/Haifa/IBM@IBMIL
    > cc:   ips@ece.cmu.edu
    > Subject:  Re: iSCSI: SecurityContextComplete without operational
    parameters
    >
    >
    >
    >
    > What I was actually asking for is that the target would not send any
    > operational parameters in the same PDU as the SecurityContextComplete.
    > Rationalization given below.
    >
    > Eddy
    >
    > ----- Original Message -----
    > From: "Julian Satran" <Julian_Satran@il.ibm.com>
    > To: <ips@ece.cmu.edu>
    > Sent: Tuesday, July 24, 2001 10:08 AM
    > Subject: Re: iSCSI: SecurityContextComplete without operational
    parameters
    >
    >
    > > the new text will read:
    > >
    > >       If the initiator has been the last to complete the handshake it
    > MUST
    > >       NOT start sending operational parameters that need to be
    protected
    > >       within the same text command; a text response including only
    > >       SecurityContextComplete=yes concludes the security sub-phase.
    Only
    > >       the following PDU exchange is protected by digests (if any).
    > >
    > > If the target has been the last to complete the handshake, the
    initiator
    > > can start the operational parameter negotiation with the next text
    > command;
    > > the security negotiation sub-phase ends with the target text response.
    > > However, the target handshake concluding response MUST NOT include
    > > operational parameters that need to be protected. Only the following
    PDU
    > > exchange is protected by digests (if any).
    > >
    > > Julo
    > >
    > > "Eddy Quicksall" <EQuicksall@mediaone.net> on 24-07-2001 15:55:05
    > >
    > > Please respond to "Eddy Quicksall" <EQuicksall@mediaone.net>
    > >
    > > To:   Julian Satran/Haifa/IBM@IBMIL
    > > cc:   ips@ece.cmu.edu
    > > Subject:  iSCSI: SecurityContextComplete without operational parameters
    > >
    > >
    > >
    > >
    > > In section "4.2 iSCSI Security and Integrity Negotiation", it would be
    > best
    > > if the target is required to send SecurityContextComplete=yes without
    any
    > > new operational parameters within the same PDU.
    > >
    > > It makes coding cleaner because the initiator can have a simple
    > > send/receive
    > > loop that pops out when security is complete. If operational parameters
    > are
    > > allowed with SecurityContextComplete=yes, the initiator's security
    module
    > > must also have operational parameter code or it must set flags, leave
    > > information in buffers, etc that all create messy code.
    > >
    > > The spec says:
    > >
    > >            If the initiator has been the last to complete the handshake
    > it
    > >            MUST NOT start sending operational parameters within the
    same
    > >            text command.
    > >
    > > How about if we say the same thing for the target? There shouldn't be
    any
    > > harm because I suspect everyone is doing that anyway.
    > >
    > > Comments?
    > >
    > >
    > > Eddy_Quicksall@iVivity.com
    > >
    > >
    > >
    > >
    > >
    >
    >
    >
    
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:04:12 2001
6315 messages in chronological order