[IPsec] PAKE Selection: HUSH

[Yaron Sheffer <[e-mail]>]

Per Paul's request, here is an evaluation of the HUSH proposal 
(http://tools.ietf.org/html/draft-sheffer-ipsecme-hush-00) according to 
Dan's criteria draft. Comments and questions are more than welcome.

In summary, HUSH is an adaptation of Bellovin's and Merritt's Encrypted 
Key Exchange (EKE) protocol into IKEv2. As such, it benefits from the 
two major advantages associated with EKE:

- EKE was published in 1992 and since then has had very extensive, 
published, review by eminent cryptographers. Although some protocol 
variants described in the original paper were broken, the variant we are 
using has been repeatedly analyzed and is believed secure to this day.

- EKE was promptly patented by AT&T. However the patent is due to expire 
by Oct. 2, 2011, which is probably around the time we can get the RFC 
published. In other words, the IPR situation is crystal clear and rather 
advantageous.

To save you the trouble (:-), I consider the protocol's two main 
disadvantages to be:

- The protocol has never been proven secure, while more recent protocols 
were designed with formal security proof in mind.

- Due to its cryptographic structure, new MODP DH groups have to be 
defined; EC groups are not supported, at least not currently.

And now to the criteria:

SEC1: The protocol is based on a zero-knowledge proof.  It is resistant 
to passive attack, active attack, and off-line dictionary attack.

SEC2: The protocol supports perfect forward secrecy and protection 
against the Denning-Sacco attack.

SEC3: The protocol does not require the loss of identity protection 
afforded by IKEv2 today. However if the WG so prefers, HUSH can be 
modified to eliminate one round trip at the cost of identity protection.

SEC4: The protocol does not constrain the "crypto agility" of IKEv2. It 
must not require fixed and unchangeable cryptographic primitives or 
Diffie-Hellman groups. HUSH does define its own selection of DH groups, 
which provides crypto agility for this portion as well (see MISC5 below).

SEC5: The base protocol (i.e. EKE) has received very extensive review. 
e.g. Patel's paper of 1997 and others. It has not been proven secure.

SEC6: This feature (deriving a long term shared credential, so that the 
password does not need to be reused) is not specified in HUSH but would 
be a simple change.

SEC7: A one-way hash of the password can be stored, instead of the 
cleartext password.

IPR1: The EKE protocol was published by Bellovin and Merritt in 1992.

IPR2: US patent 5,241,599 for EKE was filed Oct. 2, 1991, and issued 
Aug. 31, 1993. It is due to expire Oct. 2, 2011.

IPR3: I am in the process of filing an IPR statement related to the HUSH 
draft. I have no idea what licensing policy, if any, Lucent might have 
regarding this protocol.

MISC1: HUSH adds one round trip to the base IKEv2 exchange. This is 
comparable with or better than the IKEv2-with-EAP alternative.

MISC2: Compared with the base IKEv2 exchange, each of the HUSH peers 
performs two additional exponentiations, and a small number of symmetric 
crypto operations.

MISC3: Performance is independent of the password's length.

MISC4: Internationalization of character-based passwords is supported.

MISC5: The HUSH protocol defines its own DH groups, which use the same 
primes as IKE's group, but with different generators. As a result, an 
equivalent-strength group can be negotiated for each IKE MODP group. 
Sec. 6.1 of the draft explains the cryptographic motivation and provides 
an initial list of groups. The use of EC groups with EKE is at the 
moment unsupported, but may be possible in the future, following a paper 
by Black and Rogaway.

MISC6: HUSH perfectly fits into the request/response nature of IKE.

MISC7: The actual use of the protocol needs to be negotiated, and so 
does the HUSH-specific DH group.

MISC8: No need for a trusted third party, nor for clock synchronization.

MISC9: The protocol is crypto-agile. To the extent that long-term 
credential storage requires the use of one-time hash functions, this 
agility may be harder to implement. But the protocol's strength does 
*not* depend on the strength of this hash function, simply because 
guessing the password itself is easier than breaking a hash function, 
even if it's badly broken.

MISC10: As noted above, at the moment only MODP groups are supported.

MISC11: The related EAP-EKE 
(http://tools.ietf.org/html/draft-sheffer-emu-eap-eke-06) was 
implemented by two students as a term project. I do not expect any 
particular difficulties in implementing HUSH.

Thanks,
	Yaron