Re: [RPSEC] Authentication for OSPFv3

sandy@tislabs.com (Sandy Murphy) Wed, 01 October 2008 15:57 UTC

Return-Path: <rpsec-bounces@ietf.org>
X-Original-To: rpsec-archive@megatron.ietf.org
Delivered-To: ietfarch-rpsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1D193A68D4; Wed, 1 Oct 2008 08:57:10 -0700 (PDT)
X-Original-To: rpsec@core3.amsl.com
Delivered-To: rpsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6676F3A67F6; Mon, 29 Sep 2008 13:05:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 UL3gS8mK-8WI; Mon, 29 Sep 2008 13:05:00 -0700 (PDT)
Received: from nutshell.tislabs.com (nutshell.tislabs.com [192.94.214.100]) by core3.amsl.com (Postfix) with ESMTP id DE0EA3A67A5; Mon, 29 Sep 2008 13:04:59 -0700 (PDT)
Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id m8TK42iB014674; Mon, 29 Sep 2008 16:04:02 -0400 (EDT)
Received: from nodnsquery(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAjPaiQC; Mon, 29 Sep 08 16:04:02 -0400
Received: by pecan.tislabs.com (Postfix, from userid 2005) id 3E5DD3F443; Mon, 29 Sep 2008 16:02:31 -0400 (EDT)
To: dward@cisco.com, edward.jankiewicz@sri.com, msec@ietf.org, ospf@ietf.org, rcallon@juniper.net, rpsec@ietf.org, secdir@mit.edu, sidr@ietf.org, tsvwg@ietf.org
In-Reply-To: <48D96507.4000207@sri.com>
Message-Id: <20080929200231.3E5DD3F443@pecan.tislabs.com>
Date: Mon, 29 Sep 2008 16:02:31 -0400
From: sandy@tislabs.com
X-Mailman-Approved-At: Wed, 01 Oct 2008 08:57:10 -0700
Cc: sandy@tislabs.com
Subject: Re: [RPSEC] Authentication for OSPFv3
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Protocol Security Requirements <rpsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/rpsec>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: rpsec-bounces@ietf.org
Errors-To: rpsec-bounces@ietf.org

>What (if any) current initiatives are there that would support automated 
>key exchange for OSFPv3 authentication?

You have msec on the list of recipients, which is where I (not an active
participant, mind you) think the answer lies.  Both GDOI (RFC 3547) and
GSAKMP (RFC 4535) are group key management protocols, which is what
OSPFv3 needs.  Unfortunately, both assume the existence of a group
controller that plays an important role in distributing keys.  In other
words, the very democratic all-are-equal many-to-many model of OSPF might find it
difficult to map to the envisioned group security architecture.  I
suppose it might be possible to consider the Designated Router as the
group controller, but as the DR is elected, that might be a difficult fit.

Even if you solve the group key management problem for OSPFv3, you still
have the difficulty to doing anti-replay in a multicast environment.
Manral presented a draft some years ago to the rpsec working group about
the crypto vulnerabilities of routing protocols, and concentrated for
OSPFv3 on replay vulnerabilities.  Unfortunately, that did not go anywhere.

Just for fun, I'm adding the routing area ADs and the secdir on this list.
This is one of those cross-disciplinary concerns that has the right people
in several different wgs and areas.  The more the merrier, right?

The one quibble I have is that the tsvwg probably has little to do with this
problem - the transport for OSPFv3 is IP, not TCP, and IP is not the level
of stuff their charter looks at.

(And sorry for the late reply to your messages, I've been mulling the options.)

--Sandy

---------  In reply to ------------------------

Date: Tue, 23 Sep 2008 17:52:07 -0400
From: Ed Jankiewicz <edward.jankiewicz@sri.com>
To: ospf@ietf.org, rpsec@ietf.org, sidr@ietf.org, msec@ietf.org, tsvwg@ietf.org
Subject: [RPSEC] Authentication for OSPFv3

I am not an active follower of these lists but have a question.  Please 
reply off-list directly to ed.jankiewicz@sri.com or copy me if this 
triggers relevant discussion on your list.

What (if any) current initiatives are there that would support automated 
key exchange for OSFPv3 authentication?  RFC 4552 relies upon pre-shared 
secret keys for generating message digest, but some of my constituents 
have issues with manual generation, distribution and configuration of 
keys in their IPv6 network deployment.  Is any of the current work on 
IKE revisions applicable, any work being done in your working group, or 
do you know of any OSPF-specific solution being developed somewhere?

Thanks.

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  ed.jankiewicz@sri.com 

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/rpsec

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/rpsec