Re: iSCSI: PAK: an alternative to SRP and DH-CHAP

[Paul Koning <ni1d@arrl.net>]

Excerpt of message (sent 30 April 2002) by Philip MacKenzie:
> > Funny, iSCSI all ready has excellent protection from active attackers 
> > in the fact that IPsec has protection from active attackers.  If you 
> > need the protection, turn on the MUST implement IPsec and be done with
> > it.  If you don't need the protection, and want some extra performance
> > just turn off IPsec and go through your dedicated switched network that
> > doesn't have the ability for an unknown attacker to sit in the middle...
> > 
> > Why are we still wasting time on this ???
> > 
> > Bill
> > 
> 
> 
> Good question.  I did find the following reason
> in <draft-ietf-ips-security-11.txt>, Section 5.8.2:
> 
> > Thus when pre-shared key authentication is used in Main Mode  along with
> > entities whose address is dynamically assigned, the same pre-shared key
> > is shared by a group and is no longer able to function as an effective
> > shared secret.  In this situation, neither the Initiator nor Responder
> > identifies itself during IKE Phase 1; it is only known that both parties
> > are a member of the group with knowledge of the pre-shared key....
> > However, where IP addresses are dynamically assigned and Main Mode is
> > used along with pre-shared keys, the Responder is not authenticated
> > unless application-layer mutual authentication is performed (e.g. iSCSI
> > Login with SRP). This enables an attacker in possession of the group
> > pre-shared key to masquerade as the Responder. In addition to enabling
> > the attacker to present false data, the attacker would also be able to
> > mount a dictionary attack on legacy authentication methods such as CHAP
> > [RFC1994], potentially compromising many passwords at a time.  This
> > vulnerability is widely present in existing IPsec implementations.

I feel that this is a red herring.

It's been quite clearly stated that group secrets in IKE main mode are
a Bad Idea.  There are several solutions within IKE for this.

For one thing, if your threat environment is such that you need IPsec,
then you need IPsec done right.  It makes no sense to do it wrong
(group keying) and then pretend you're fixing the problem by layering
SRP or the like on top.  That may protect your initial login
handshake, but it does nothing to protect the rest of your traffic
from your assumed rogue group member.

(Conversely, if you trust group members to behave properly, then group
keying is in fact ok and its existence doesn't justify maximally
strong application layer authentication either.)

       paul