Re: iSCSI:SRP

["Bernard Aboba" <bernard_aboba@hotmail.com>]

>I would be very comfortable saying just do CHAP over an encrypted >link, so 
>you don't have the vulnerabilities of CHAP because the link >is protected 
>by a must implement IPsec layer...

The problem is that IPsec is *must implement* not *must use*. Therefore an 
iSCSI authentication mechanism needs to be secure even when IPsec is not 
turned on.

The problem is that CHAP is a very weak solution when used with passwords; 
offline dictionary attacks are easy to carry out. It also does not provide 
for mutual authentication, and has been pointed out, doing two one-way 
authentications in each direction is not the same as an interlocked mutual 
authentication. Substituting HMAC-SHA1 for MD5 doesn't help enough to be 
worth considering.

For one thing, there is the possibility of a reflection attack -- the Target 
sends you a challenge, the Initiator sends the same challenge back to the 
Target. However, if the Initiator is even allowed to send the challenge 
first, then it can precompute the dictionary and crack a weak password 
online. There are plenty of algorithms that interlock the two 
authentications in a way that makes use of liveness on both sides and takes 
care of these issues.

I should also add that the argument "we do CHAP because that's what RADIUS 
supports" doesn't hold water. RFC 2869 supports extensible authentication, 
and most RADIUS servers (including FreeRADIUS) now support this. That means 
that a plug-in can be added to RADIUS or Diameter to support almost any 
algorithm. So let's figure out what makes sense and then think about making 
AAA server do that, rather than the other way around.

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com