Re: [IPsec] WESP - Roadmap Ahead

Stephen Kent <kent@bbn.com> Thu, 12 November 2009 04:07 UTC

Return-Path: <kent@bbn.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 A0A5B3A682E for <ipsec@core3.amsl.com>; Wed, 11 Nov 2009 20:07:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.518
X-Spam-Level:
X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 c-hwN5V5oPG9 for <ipsec@core3.amsl.com>; Wed, 11 Nov 2009 20:07:33 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id DD7A33A63EB for <ipsec@ietf.org>; Wed, 11 Nov 2009 20:07:33 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15] helo=[133.93.16.246]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from <kent@bbn.com>) id 1N8QyW-0001HR-A4; Wed, 11 Nov 2009 23:08:00 -0500
Mime-Version: 1.0
Message-Id: <p0624080ec7213743dc05@[133.93.16.246]>
In-Reply-To: <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com>
References: <dc8fd0140911110805q67759507t6cf75a1e9d81c5aa@mail.gmail.com> <p06240800c720d4538dd2@[133.93.112.234]> <7C362EEF9C7896468B36C9B79200D8350A681DDBDB@INBANSXCHMBSA1.in.alcatel-luce nt.com> <p0624080ac7212e67c860@[133.93.16.246]> <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com>
Date: Wed, 11 Nov 2009 23:07:56 -0500
To: Merike Kaeo <merike@doubleshotsecurity.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>, Jack Kohn <kohn.jack@gmail.com>
Subject: Re: [IPsec] WESP - Roadmap Ahead
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: Thu, 12 Nov 2009 04:07:34 -0000

At 7:49 PM -0800 11/11/09, Merike Kaeo wrote:
>All of the standards I've seen that explicitly define how IPsec is 
>to be used for authentication (including RFC 4552 - 
>Authentication/Confidentiality for OSPFv3) say that for 
>authentication ESP-Null MUST be used and AH MAY.
>
>Which RFCs specify AH specifically as a MUST for authentication/integrity?
>
>Now on the flip side, in practical implementations, most vendors I 
>know of started off with AH being used for OSPFv3 and I doubt in 
>practice people are using ESP-Null.  Would love to be wrong here :)
>
>- merike

Whoops, I was wrong. I looked at 4552 and they do cite ESP-NULL 
(although they never refer to it that way) as a MUST, and AH as a MAY.

I probably was confused because the authors did not understand the 
IPsec model as per RFC 4301, when I sat down and talked with them 
over 3 years ago, with Sam Hartman in his SEC AD role. I am amazed 
that, in the final analysis, they did try to adhere to the 4301 model 
(see section 11)!

I don't know if any other apps have done what I thought (erroneously) 
had been done here.

Steve