Hi Dan,
thank you for detecting this issue. We have just submitted a new version
of the draft
(http://tools.ietf.org/id/draft-kuegler-ipsecme-pace-ikev2-06.txt) that
resolves it by fixing the length of the nonce and mandating the use of
the corresponding unauthenticated encryption algorithm.
Regards,
Yaron
On 03/28/2011 02:10 PM, Dan Harkins wrote:
Hello,
I believe there is a problem with this draft that can void a claimed
security property: namely, resistance to dictionary attack. The issue is
not with the underlying key exchange itself, but with the way the key
exchange was added to IKEv2.
In this protocol, a random nonce is encrypted using the encryption
algorithm negotiated in IKEv2 with a key that is based on a password
and data known to an adversary launching an active attack. The initiator
of the protocol produces the encrypted random nonce and sends it to the
responder. If an adversary, acting as the responder, is able to determine
whether a decryption of the nonce is successful he is able to launch an
off-line dictionary attack.
When the negotiated encryption algorithm is used in an authenticated
encryption mode, like -GCM or -CCM, an integrity check value (ICV) is
encoded into the ciphertext produced by the encryption operation (see
RFC 5282). This provides a way for an adversary to determine whether a
decryption was successful and therefore whether the guessed password is
correct. The attack is simply to try each candidate password from the
dictionary, use it to compute a candidate key, and if the authenticated
decryption operation using the candidate key does not return FAIL then
exit, the password has been found.
There are many ways to address this issue. The simplest would be
to just forbid use of an AAD cipher mode when using this method of
authentication. That would be regrettable though due to the wide appeal
of GCM (less so with CCM). A better solution would be to just use ECB
mode of the underlying block cipher. The nonce is uniformly random and
there is no need to inject additional randomness into the encryption
operation (i.e. no IV needed).
I feel it is necessary to fix this issue before publication.
regards,
Dan.
On Sat, 26 Mar 2011 09:38:11 -0700, the IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Password Authenticated Connection Establishment with IKEv2'
<draft-kuegler-ipsecme-pace-ikev2-05.txt> as an Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf at ietf.org mailing lists by 2011-04-23. Exceptionally, comments
may be
sent to iesg at ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-kuegler-ipsecme-pace-ikev2/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-kuegler-ipsecme-pace-ikev2/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf