SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI Security mechanisms



    Bernard,
    
    I think this is an instance of brilliant minds
    thinking alike (or at least along parallel tracks)
    With the exception of your final paragraph, your
    comments have reproduced much of the rationale from
    the interim meeting for wanting to use SRP for ESP
    keying.  I apologize for the lack of detail
    in the minutes that lead you to have to reproduce
    this - it's hard to take good minutes and
    actively participate in the discussion at
    the same time.  I guess this is a backhanded
    confirmation that using SRP to key ESP is digging in
    a useful place :-).  iSCSI already has sufficient
    negotiation support to handle selection of
    prime/modulus, etc., provided that one is careful
    about how it's used (the negotiation is not
    authenticated/protected in the fashion that
    IKE's is).
    
    There are multiple concerns about IKE.  In addition
    to code size, there's a concern that the iSCSI
    identities that need to be authenticated (Node
    Names) are both foreign to IKE and have a greater
    span (i.e., IKE is not end-to-end wrt iSCSI
    because the identities of multiple iSCSI nodes
    that share a single <IP address, TCP port> pair
    can't be distinguished below the iSCSI layer).
    There's also a need for SRP by itself to be usable
    for inband authentication when/where ESP is not
    used (my mechanism summary email was about what
    MUST/SHOULD/MAY be implemented -- what MUST/SHOULD/MAY
    be used is a separate, but related, issue) - IKE
    is not a good fit for this sort of authentication.
    
    iSCSI does have to specify the ESP authentication/integrity
    transform - as things currently stand, a SHA-1 HMAC
    (RFC 2404 specifies HMAC-SHA-1-96) would be a likely
    choice, but an alternate could be an AES-related MAC if
    it's specification will be available in a suitable timeframe.
    
    I'll correct my usage of "manual" vs. "pre-shared" keys
    in the future - thanks for the clarification.
    
    Thanks,
    --David
    
    > -----Original Message-----
    > From:	Bernard Aboba [SMTP:aboba@internaut.com]
    > Sent:	Thursday, May 31, 2001 8:13 PM
    > To:	Black_David@emc.com
    > Cc:	ips@ece.cmu.edu
    > Subject:	Re: iSCSI Security mechanisms
    > 
    > > This leaves open the issue of where the key(s) for
    > > ESP come from.  IKE is OPTIONAL, and use of SRP to
    > > supply keys for ESP is NOT REQUIRED (not even
    > > specified - I need to find the time to work on
    > > writing this up).  This leaves pre-shared keys as
    > > the minimum mechanism, and hence I believe that
    > > a suitably secured administrative interface to
    > > supply pre-shared keys to ESP will have to be
    > > REQUIRED for interoperability even if a dynamic
    > > keying mechanism like IKE is implemented.
    > > 
    > Let me make sure I understand this:
    > 
    > a. You use SRP (which derives a key) only for authentication, but then
    > throw the derived keying material away. 
    > 
    > b. You then use IPSEC manual keying, along with an unspecified
    > transform, and key distribution mechanism. 
    > 
    > Note that what is described above is not really pre-shared secrets,
    > because those are used to authenticate DH in order to derive keying
    > material. Since you're not using derived keying material, we're really
    > talking about manual keying. 
    > 
    > I would suggest that the above manages to combine the computational
    > demands of IKE (and then some, since SRP is slower than ordinary DH)
    > the administrative headaches of manual keying and the interoperability
    > problems of specifying nothing. 
    > 
    > Ancient proverb: "The first step in removing yourself from a deep hole is
    > to stop digging." 
    > 
    > If you're going to do SRP for authentication, you might as well add in key
    > derivation, and negotiation of things like ciphersuites, prime
    > modulus/generator groups, etc. so you can use it for IPSEC keying. 
    > A rather small spec could accomplish this IF we decide it is necessary.
    > 
    > If don't want to use the SRP keying material, you might as well use a
    > slimmed down version of IKE (say, aggressive mode only) to address the
    > code size concern.
    > 
    


Home

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