Re: iSCSI Security rough consensus

[Bernard Aboba <aboba@internaut.com>]

> Although the approach of using SRP to key ESP has
> a lot of promise, making it a requirement in advance
> of a draft providing details that can be checked
> by other security experts seems premature ... and
> now I have to go help get that draft written
> in my "copious spare time" ;-).  Once that draft
> is in hand, we can make a concrete decision about
> requiring that mechanism.
> 

I agree that requiring SRP for use in IPSEC key exchange with iSCSI is
premature. We already have KINK and IKE key exchange methods, and before
creating a new application-specific method, we need to document why the
existing methods are inadequate. Also, RFC 2945 is an abstract protocol,
not a description of what bits flow over the wire. If SRP is going to be
adopted for IPSEC key exchange, then I'd argue that this should be handled
in the security area, not in the IPS WG, and should be available for any
application running over IPSEC, not just iSCSI.  

Also, given that another key exchange method is likely to be used (IKE,
KINK), this implies that another authentication has already taken place to
set up the IPSEC SA. Thus, requiring SRP in addition to IKE/KINK adds *yet
another* authentication and key exchange to the process of setting up an
IPSEC SA. Are we doing this purely in order to circumvent IKE's
limitations with respect to password-based authentication?

If so, then I'd be concerned that many other applications will encounter
the same limitations, and we may be setting ourselves up for the
proliferation of application-specific IPSEC key exchange mechanisms. I
believe that there is evidence that such a profileration is already in
progress. In the end, IPSEC may end up becoming little more than a
"framework" within which application and vendor-specific key exchanges
are developed.