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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
