Hi Martin,
thanks for your comments. Some responses below.
Yaron
On 05/03/2010 12:13 PM, Martin Willi wrote:
Hi,
Thus, this starts the two-week WG Last Call on "An Extension for
EAP-Only Authentication in IKEv2",
<http://tools.ietf.org/html/draft-ietf-ipsecme-eap-mutual-01>. Please
send any comments on the document to the mailing list. Support,
criticism, and suggestions for additions or changes are all
appropriate. At a minimum, I would like to see a handful of people say
"I have read the draft".
We have added experimental support for this draft to version 4.3.6 of
our strongSwan open source IKEv2 daemon.
The proverbial proof of the pudding...
I think the draft looks good from an implementors perspective, here some
comments:
- Section 4 lists two requirements for EAP methods: mutual
authentication and key generation. As noted in section 6.3, an active
attacker can intercept plain EAP packets. I think it would be a good
idea to add a "dictionary-attack-resistant" property to the requirement
list. There are methods that have the other two properties, but are not
a good candidate for use with this draft. The widely deployed
EAP-MSCHAPv2 is such an example. Using it with the draft will highly
degrade the security of the IKEv2 protocol.
I agree.
- The example of using EAP-GSS with with Kerberos in section 2 to
replace KINK is probably not the best one for the reason above. Or is
this combination in the end any more secure than using IKEv2 PSK with
weak passwords?
Yes, we need a better example.
- What's the reason for not adding EAP-TLS to the list of save methods?
I think EAP-TLS is a perfect candidate. It might be questionable to use
TLS within IKEv2 at all, but there actually are higher level protocols
that exactly use this combination. EAP-SIM is another candidate probably
worth to mention, having very similar properties as EAP-AKA.
EAP-TLS is mentioned right before the table - and could be added. The
table is not meant to be all-inclusive. I think using EAP-TLS here is
crazy in practice, and I'd love to hear more about the protocols that
use this combination - and why.
- Section 3:
If the responder supports this notification, it omits the public key
based AUTH payload and CERT payloads from message 4.
This might be misleading, as the responder can ignore this notify even
if it supports the extension. This would make sense if the selected EAP
method does not have the required properties. "May omit"?
I think "supports" usually means "supports and actually feels like doing
it."
Best regards
Martin
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
