Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2

"Dan Harkins" <dharkins@lounge.org> Mon, 30 November 2009 23:06 UTC

Return-Path: <dharkins@lounge.org>
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 E413728C156 for <ipsec@core3.amsl.com>; Mon, 30 Nov 2009 15:06:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Level:
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
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 l-uABkRR4YWW for <ipsec@core3.amsl.com>; Mon, 30 Nov 2009 15:06:23 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 0E6CB28C148 for <ipsec@ietf.org>; Mon, 30 Nov 2009 15:06:23 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id EB5D81022407E; Mon, 30 Nov 2009 15:06:15 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 30 Nov 2009 15:06:16 -0800 (PST)
Message-ID: <c68fdff7883b6e69d045524b2013af00.squirrel@www.trepanning.net>
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.co m>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E04EE@il-ex01.ad.checkpoint.com>
Date: Mon, 30 Nov 2009 15:06:16 -0800
From: Dan Harkins <dharkins@lounge.org>
To: Yaron Sheffer <yaronf@checkpoint.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2
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, 30 Nov 2009 23:06:24 -0000

  Hello,

  I do not believe this is a reasonable activity to spend WG time on.
The reason is that for this proposal to be useful for more than a
small, specific, edge condition the following must apply:

  - both sides MUST implement both client- and server-side EAP state
    machines.
  - both sides MUST possess the shared secret.

And in that case EAP encapsulation of the underlying key exchange would
be completely pointless and extraneous, would double the number of
messages required to complete the exchange, and would increase the amount
of security-critical code. More work for no benefit...not a good idea.

  In addition, EAP-only authentication increases potential insecurity,
where an external EAP server can authenticate any identity an IKEv2
gateway wants to claim-- the "lying NAS problem". Authentication depends
on a verifiable identity and if one side can claim any identity it chooses
then the mutual authentication properties of IKE cannot be met.

  Even if one believes that the small, specific, edge condition is really
important there is an alternative to address that case, one that can also
address other peer-to-peer, subnet-to-subnet, and tranport mode, use
cases. That is the "Secure PSK authentication" option as defined in
draft-harkins-ipsecme-spsk-auth-00.txt.

  It seems to me that EAP-only authentication in IKEv2:

     1. does not solve a general problem;
     2. solves the specific problem it is aimed at poorly-- doubling of
        the number of messages, requiring writing and testing of new
        state EAP state machines that are, otherwise, unnecessary; and,
     3. is insecure (unless something used nowhere today is employed: EAP
        channel bindings).

  To provide the benefits of EAP-only authentication-- certificate-less
mutual authentication based only on a password-- it would be much better
to support the inclusion of "Secure PSK authentication" as a work item.
That work item will not only address the small use case that EAP-only
authentication is aimed at, it will also address other peer-to-peer,
subnet-to-subnet, and transport-mode use cases. And it will do so in a
manner that ensures security.

  regards,

  Dan.

On Sun, November 29, 2009 9:18 am, Yaron Sheffer wrote:
> This draft proposes an IKEv2 extension to allow mutual EAP-based
> authentication in IKEv2, eliminating the need for one of the peers to
> present a certificate. This applies to a small number of key-generating
> EAP methods that allow mutual authentication.
>  
> Proposed starting point:
> http://tools.ietf.org/id/draft-eronen-ipsec-ikev2-eap-auth-07.txt.
>  
> Please reply to the list:
>  
> - If this proposal is accepted as a WG work item, are you committing to
> review multiple versions of the draft?
> - Are you willing to contribute text to the draft?
> - Would you like to co-author it?
>  
> Please also reply to the list if:
>  
> - You believe this is NOT a reasonable activity for the WG to spend time
> on.
>  
> If this is the case, please explain your position. Do not explore the fine
> technical details (which will change anyway, once the WG gets hold of the
> draft); instead explain why this is uninteresting for the WG or for the
> industry at large. Also, please mark the title clearly (e.g. "DES40-export
> in IPsec - NO!").
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>