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

From: Paul Hoffman <[email-masked]>
Date: Sun, 2 May 2010 19:13:44 -0700

At 2:39 PM -0700 4/21/10, Paul Hoffman wrote:
>Greetings again. We have kicked around draft-ietf-ipsecme-eap-mutual and its predecessor for a long time, and it seems like there have been few substantial comments lately.
>
>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".

Zero comments so far. Without more input from the WG, we might want to just kill this draft, which would be quite sad.

--Paul Hoffman, Director
--VPN Consortium

---

From: Martin Willi <[email-masked]>
Date: Mon, 03 May 2010 11:13:30 +0200

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.

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.

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

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

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

Best regards
Martin

---

From: Yoav Nir <[email-masked]>
Date: Mon, 3 May 2010 13:00:30 +0300

Can't compete with Martin's "running code", but I have a few comments. Before that, the draft seems good, and easy to follow. I think developers who have never heard of the IPsec list should have no problem reading and implementing this correctly. Having said that, here's two comments.

The introduction says this:
   In some environments, requiring the deployment of PKI for just this
   purpose can be counterproductive.  Deploying new infrastructure can
   be expensive, and it may weaken security by creating new
   vulnerabilities.  Mutually authenticating EAP methods alone can
   provide a sufficient level of security in many circumstances, and
   indeed, IEEE 802.11i uses EAP without any PKI for authenticating the
   WLAN access points.

The way this is phrased, it sounds like you need to deploy a full PKI for the gateway to show a certificate. Web servers do HTTPS without all this. They use either a relatively cheap commercial certificate or a self-signed certificate. The question is what value is there in the client verifying the certificate. With a self-signed certificate (or a corporate certificate) it's really a one-time leap of faith ("do you approve the fingerprint...") like with SSH servers. To do any better, you would need a full PKI with all computers pre-installed with the root trust anchor (or using TAMP). And if you have all that in place, you might as well issue certificates to users and skip EAP altogether.  So I would rephrase it as:

   In order for the public key signature authentication of the gateway to be
   effective, a deployment of PKI is required, which has to include
   management of trust anchors on all supplicants. In many environments, 
   this is not realistic, and the security of the gateway public key is 
   the same as the security of a self-signed certificate. Mutually 
   authenticating EAP methods alone can...

Nowhere in the document does it say, why the EAP method needs to be key-generating. In fact, RFC 4306 says that it is recommended, but goes on to say what to do if the method is not key-generating. This document should make it clear why omitting the server-side signature changes things such that key generation has become crucial. The only thing I could find was section 6.1, which says:
   It is important to note that the IKEv2 SA is not authenticated by
   just running an EAP conversation: the crucial step is the AUTH
   payload based on the EAP-generated key.  Thus, EAP methods that do
   not provide mutual authentication or establish a shared secret key
   MUST NOT be used with the modifications presented in this document.
Why is it crucial?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Monday, May 03, 2010 5:14 AM
To: IPsecme WG
Subject: Re: [IPsec] Start of WG Last Call on draft-ietf-ipsecme-eap-mutual (EAP-Only Authentication)

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

Scanned by Check Point Total Security Gateway.

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 03 May 2010 22:36:02 +0300

Hi Martin,

thanks for your comments. Some responses below.

	Yaron

> our strongSwan open source IKEv2 daemon.
The proverbial proof of the pudding...

> degrade the security of the IKEv2 protocol.

I agree.
> this combination in the end any more secure than using IKEv2 PSK with

Yes, we need a better example.
> 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.
> method does not have the required properties. "May omit"?

I think "supports" usually means "supports and actually feels like doing 
it."

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 03 May 2010 23:32:38 +0300

Hi Yoav,

please see some comments below.

Thanks,
	Yaron

>     authenticating EAP methods alone can...
I'm OK with this new text, but even if enterprise deployment of limited 
PKI is easy in theory, we know that in practice, many people eventually 
disable validation of server certs in the context of EAP (top of this 
screen shot: 
http://www.wegotserved.com/wp-content/uploads/2008/03/settings1.jpg).

>     MUST NOT be used with the modifications presented in this document.
This is a very good question: the AUTH payloads very indirectly bind the 
IKE shared secret with the actual EAP payloads. So the generated key may 
not be so crucial after all. But AFAIK, all modern EAP methods are key 
generating, so the question is interesting but theoretical.

Also, for people that care about channel binding between IKE and the EAP 
method, the shared EAP key is used to enable the IKE peer to prove that 
it is either the EAP terminator, or at least trusted by it. So in this 
scenario the generated key is essential.
>> 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".
>

---

From: Andreas Steffen <[email-masked]>
Date: Mon, 03 May 2010 22:42:52 +0200

Hi Yaron,

I actually see a need for TLS-type IKEv2 EAP protocols in the context
of IPsec-based Network Endpoint Assessment (NEA, RFC 5209). The recent
proposal for an EAP-PT transport protocol

   http://tools.ietf.org/html/draft-hanna-nea-pt-eap-00

says in section 1. Introduction:

    ...

    EAP-TNC is designed to operate as an inner EAP [10] method over an
    EAP tunnel method that meets the Requirements for a Tunnel Based EAP
    Method [17]. PT-EAP therefore can operate over a number of existing
    access protocols that support EAP for authentication. Some examples
    of such access protocols include 802.1X [7] for wired and wireless
    networks and IKEv2 [15] for establishing VPNs over IP networks.

    This document defines a standard EAP inner method called EAP-TNC.  It
    also shows how EAP-TNC may be carried over two existing EAP tunnel
    EAP methods: EAP-FAST [14] and EAP-TTLS [16].

Thus we have a requirement to use e.g. EAP-FAST or EAP-TTLS via IKEv2.

Best regards

Andreas

> use this combination - and why.

======================================================================
Andreas Steffen                         [email-masked]
strongSwan - the Linux VPN Solution!                www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==