SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI extension algorithms (was no subject)



    On Wed, 15 Jan 2003, Julian Satran wrote:
    
    > please have a look at the text on my site (it is out there for a while).
    > It says it all. Julo
    
    Ok, I looked at it, and it had text that was in the thread:
    
    <text>
    Private or public extension algorithms MAY also be negotiated for
    authentication methods. Whenever a private or public extension algorithm
    is offered, the implementer MUST ensure that CHAP is listed as an
    alternative unless the setting is done by explicit administrative action
    Furthermore with private and public extensions "None" MUST NOT appear as
    an additional choice without explicit action by the administrator.
    </text>
    
    
    The concern I have with that text is it doesn't differentiate between
    offering options to the admin and then offering negotiation choices to the
    other side of the login. It mushes them together, and as such becomes
    unclear. We're telling the initiator and the target what they MUST
    mention, when it strikes me that (shout is to the general audience, not
    specifically Julian) WE SHOULD ONLY OFFER/ACCEPT AUTH METHODS WE HAVE
    SECRETS FOR.
    
    If you don't have a secret for it, you shouldn't offer/accept it.
    
    We hit this idea clearly a few lines above this text, when we say,
    "Authentication is not mandatory to use but MUST be supported by the
    target and initiator." The most sensible thing would be to extend that to
    authentication methods; CHAP is not mandatory to use, but it MUST be
    supported by the target and initiator.
    
    But the text above says that you should offer CHAP as an option unless
    explicitly told otherwise. That's not the same thing.
    
    Say you (an initiator or target) neither have been told not to do CHAP nor
    have you been given any CHAP secrets. By the text above, you MUST offer
    CHAP, but you don't have any secrets to back it up, so what in the h*ll is
    going to happen? It won't work, we knew it wouldn't work, and it was silly
    to offer it initially.
    
    
    
    I am concerned that as long as we try to enforce things at the negotiation
    offer/accept stage, we will end up with a spec that either is clumsy, or
    is ignored.
    
    How about this for a replacement paragraph (I'm including the preceeding
    paragraph for clarity):
    
    <text>
    The initiator and target MUST implement CHAP. All other authentication
    methods are OPTIONAL.
    
    Private or public extension algorithms MAY also be negotiated for
    authentication methods. A target or initiator implementation that supports
    an extention algorithm is still bound by the above CHAP requirement, and
    MUST offer CHAP as a configurable authentication option to the
    administrator. Support for an extension algorithm may NOT be used as an
    excuse to not implement CHAP.
    </text>
    
    This text very bluntly states that you can't get around supporting CHAP,
    but we still leave it to the administrator to choose what authentication
    methods are in use; we don't set policy.
    
    Thoughts?
    
    Take care,
    
    Bill
    
    


Home

Last updated: Thu Jan 16 02:19:10 2003
12185 messages in chronological order