Re: [IPsec] Start of WG Last Call on draft-ietf-ipsecme-eap-mutual (EAP-Only Authentication)

[Yaron Sheffer <[e-mail]>]

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
>
>