[secdir] [karp] FW: Non IPSec Authentication mechanism for OSPFv3 (fwd)

Sandra Murphy <Sandra.Murphy@sparta.com> Sun, 26 September 2010 20:24 UTC

Return-Path: <Sandra.Murphy@cobham.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13CF63A6BAD for <secdir@core3.amsl.com>; Sun, 26 Sep 2010 13:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.441
X-Spam-Level:
X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 6Fl5fNA-SQkp for <secdir@core3.amsl.com>; Sun, 26 Sep 2010 13:24:24 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 774EF3A6B82 for <secdir@ietf.org>; Sun, 26 Sep 2010 13:24:23 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o8QKP0FX003194 for <secdir@ietf.org>; Sun, 26 Sep 2010 15:25:00 -0500
Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o8QKP06S006919 for <secdir@ietf.org>; Sun, 26 Sep 2010 15:25:00 -0500
Received: from SMURPHY-LT.columbia.ads.sparta.com ([192.168.1.103]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Sep 2010 16:25:00 -0400
Date: Sun, 26 Sep 2010 16:24:59 -0400
From: Sandra Murphy <Sandra.Murphy@sparta.com>
To: secdir@ietf.org
Message-ID: <Pine.WNT.4.64.1009261614520.1784@SMURPHY-LT.columbia.ads.sparta.com>
X-X-Sender: sandy@mailbin.sparta.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-OriginalArrivalTime: 26 Sep 2010 20:25:00.0113 (UTC) FILETIME=[E49E3410:01CB5DB8]
Subject: [secdir] [karp] FW: Non IPSec Authentication mechanism for OSPFv3 (fwd)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Sep 2010 20:24:26 -0000

Authentication in OSPFv3 (for IPv6) differs from OSPFv2.  OSPFv2 has 
an authentication mechanism in-band in the mechanism (recently updated in 
5709).  OSPFv3 relies on IPSec, but with manual keying so it has no replay 
protection.  That's been an issue.

The draft below suggests a new authentication mechanism for ospfv3 other 
than ipsec.

I note that the abstact says:

       Currently OSPFv3 uses IPSec for authenticating the protocol
       packets. This draft proposes an alternative ? Generic
       Authentication that can be used so that OSPFv3 does not depend
       upon IPSec for security. The mechanism introduced in this draft
       is generic and can be used by any protocol that currently uses
       IPSec for authentication.

The proposed use of this mechanism for uses beyond ospfv3 seems like it 
might be interesting to this group.

I note also that the name given the proposed extension header is "Generic 
Authentication".

The draft is

http://tools.ietf.org/html/draft-bhatia-karp-non-ipsec-ospfv3-auth-00

--Sandy




---------- Forwarded message ----------
Date: Sat, 25 Sep 2010 06:05:11 +0530
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: "karp@ietf.org" <karp@ietf.org>
Subject: [karp] FW: Non IPSec Authentication mechanism for OSPFv3

Hi,

Currently OSPFv3 uses only IPSec for authentication. I have written a small draft that uses provides a different authentication mechanism - non IPSec based, for OSPFv3 as IPSec is generally considered inadequate for routing protocols. Would be great if folks can review and provide some feedback on this.

http://tools.ietf.org/html/draft-bhatia-karp-non-ipsec-ospfv3-auth-00

Cheers, Manav
_______________________________________________
karp mailing list
karp@ietf.org
https://www.ietf.org/mailman/listinfo/karp