SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: IKE normative guidelines



    Excerpt of message (sent 9 November 2001) by Black_David@emc.com:
    > Yes, these guidelines differ from those RFCs in a number of
    > ways, based on things learned since those RFCs were written.
    > Many of these are things that would go into revised versions
    > of the IPsec RFCs, but revising the IPsec RFCs turns out to
    > be intractable to the point of near-impossibility for the
    > security folks - you'll have to ask them why.  See the IPS
    > security draft for some further explanation of these changes.
    
    That's all well and good, but I see a major process problem with WG
    XYZ overriding the requirements created in another protocol that
    belongs to WG ABC on the grounds that WG ABC can't get the work done
    itself.  
    
    If that's what we want to do, we should be clear about it and not call
    the lower layer protocol we're relying on "IPSec" but rather something
    like "IPS-sec" to make it clear we're defining an IPS specific variant
    forked from the original standard.
    
    Perhaps IKE is less problematic than, say, not yet settled on modes
    such as XCBC, but the same principle applies in both places.
     
    > Main mode is not "at least as good" as aggressive mode when
    > group pre-shared keys are used; see the security draft and
    > the ipsec WG "improveike" draft for details.  Group pre-
    > shared keys are often used in practice because they
    > greatly simplify key management.
    
    Yes, that's covered by text I supplied a while back.  That case
    applies to dynamic IP addresses, which is an obscure corner case at
    best for IPS.  With static addresses, group keys are not needed and
    are very much not normal practice.
    
         paul
    
    


Home

Last updated: Mon Nov 12 14:17:38 2001
7763 messages in chronological order