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

Yaron Sheffer <yaronf.ietf@gmail.com> Mon, 03 May 2010 20:33 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA09728C276 for <ipsec@core3.amsl.com>; Mon, 3 May 2010 13:33:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.882
X-Spam-Level:
X-Spam-Status: No, score=-0.882 tagged_above=-999 required=5 tests=[AWL=-0.883, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urwqnC8AsoEg for <ipsec@core3.amsl.com>; Mon, 3 May 2010 13:33:04 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id F2F283A6A45 for <ipsec@ietf.org>; Mon, 3 May 2010 13:33:03 -0700 (PDT)
Received: by fxm4 with SMTP id 4so2801405fxm.31 for <ipsec@ietf.org>; Mon, 03 May 2010 13:32:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Z9WQRsE58jW4gmENKfJ5yqwYwKbK2NsAobXGYOsl3hc=; b=U6520lMu8GUuPoqR25UsGRgdgnb13z77f1rdXl5fKspTYNm32cb5cqAQ8AHvj35pbi BOJbktQgH57IusCU7n6dPuMJ4uUBrZUyKYO6BsVLZldOFuBLNLyleQN1PvCWUP0eKqLc 8d4u0fPGcNhQwQOgEhjSTVaiWjbNXJOluAZeU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=C4frN7QTX5+Cm9147qsbMScT+DLN77RSpJSWrBYLJ9LbAntCpY2iTTRL0Lt7WDDzDw /OEDN0ahPywoW6cLZCoQZxUEXkzv5JHGc9EZA1rXz5mYSpg7mKVTVOAUgzTgSn5gh0KH joKgIZzRyFSWi8FR6QaYb8ypSHCbCrY5CF7pg=
Received: by 10.86.124.4 with SMTP id w4mr410403fgc.54.1272918765895; Mon, 03 May 2010 13:32:45 -0700 (PDT)
Received: from [10.0.0.3] (bzq-79-181-18-85.red.bezeqint.net [79.181.18.85]) by mx.google.com with ESMTPS id 12sm9051878fgg.4.2010.05.03.13.32.41 (version=SSLv3 cipher=RC4-MD5); Mon, 03 May 2010 13:32:44 -0700 (PDT)
Message-ID: <4BDF32E6.1060606@gmail.com>
Date: Mon, 03 May 2010 23:32:38 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>
References: <p06240886c7f51f814274@[10.20.30.158]> <p06240802c803e1b7e96d@[10.20.30.158]> <006FEB08D9C6444AB014105C9AEB133FB37650C5DB@il-ex01.ad.checkpoint.com>
In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB37650C5DB@il-ex01.ad.checkpoint.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: IPsecme WG <ipsec@ietf.org>, 'Paul Hoffman' <paul.hoffman@vpnc.org>
Subject: Re: [IPsec] Start of WG Last Call on draft-ietf-ipsecme-eap-mutual (EAP-Only Authentication)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 May 2010 20:33:06 -0000

Hi Yoav,

please see some comments below.

Thanks,
	Yaron

On 05/03/2010 01:00 PM, Yoav Nir wrote:
> 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...
>
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).

>
>
> 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?
>
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.
>
> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@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