Re: WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)
Jari Arkko <jari.arkko@piuha.net> Fri, 19 February 2010 13:38 UTC
Return-Path: <jari.arkko@piuha.net>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B00D63A7CBC; Fri, 19 Feb 2010 05:38:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.425
X-Spam-Level:
X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599]
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 82EU-9xvMQIz; Fri, 19 Feb 2010 05:37:59 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id C43983A7CD2; Fri, 19 Feb 2010 05:37:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 78A462D290; Fri, 19 Feb 2010 15:39:44 +0200 (EET)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoRTryoUc1wU; Fri, 19 Feb 2010 15:39:44 +0200 (EET)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 117D22D257; Fri, 19 Feb 2010 15:39:44 +0200 (EET)
Message-ID: <4B7E949F.4010104@piuha.net>
Date: Fri, 19 Feb 2010 15:39:43 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Pasi.Eronen@nokia.com
Subject: Re: WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)
References: <20100209190003.025AE3A75BF@core3.amsl.com> <4B7A8A8E.3030704@piuha.net> <808FD6E27AD4884E94820BC333B2DB7758416A0004@NOK-EUMSG-01.mgdnok.nokia.com>
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7758416A0004@NOK-EUMSG-01.mgdnok.nokia.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: IPsec WG <ipsec@ietf.org>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Feb 2010 13:38:01 -0000
Pasi, (Adding the working group mailing list to the discussion; previous discussion has been at ietf@ietf.org.) > You're right that implementing a "weak shared secret" EAP method (both > the EAP peer and EAP server roles) on both IPsec nodes, combined with > the "EAP mutual authentication" work item (also in the new charter) > could be used in this situation, and would result in roughly the same > functionality (perhaps with slightly more roundtrips/other overhead -- > but that's probably not a critical factor here). > OK. And yes, I agree about the significance of roundtrips. > NEW: > However, user-configured shared secrets are still useful for many > other IPsec scenarios, such as authentication between two servers > or routers. These scenarios are usually symmetric: both peers know > the shared secret, no back-end authentication servers are involved, > and either peer can initiate an IKEv2 SA. While it would be > possible to use EAP in such situations (by having both peers > implement both the EAP peer and the EAP server roles of an EAP > method intended for "weak" shared secrets) with the mutual > EAP-based authentication work item (above), a simpler solution may > be desirable in many situations. > This formulation is better than what we had previously. I can live with this. But for the record, I am still surprised that I am the only one worried about this. In my view this additional solution, while perhaps simpler on its own, will increase code size and complexity for most implementations. For instance, a device that serves remote access clients has to implement at least parts of EAP. To support gateway-gateway weak secrets it now has to add support for another, completely different authentication mode and associated configuration mechanisms & policies. Architecturally, it would be better to rely on few general solutions than to build special case "simpler" solutions that taken together, actually become more complex. Not to mention the impact on interoperability. Jari
- Re: WG Review: Recharter of IP Security Maintenan… Jari Arkko
- Re: WG Review: Recharter of IP Security Maintenan… Jari Arkko
- Re: WG Review: Recharter of IP Security Maintenan… Alfred Hönes
- RE: WG Review: Recharter of IP Security Maintenan… Pasi.Eronen
- Re: WG Review: Recharter of IP Security Maintenan… Jari Arkko
- Re: WG Review: Recharter of IP Security Maintenan… Dan Harkins
- Re: WG Review: Recharter of IP Security Maintenan… Bernard Aboba