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: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] 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)
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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
