Re: [RPSEC] [secdir] [sidr] Authentication for OSPFv3
"Vishwas Manral" <vishwas.ietf@gmail.com> 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 6ED983A6C41; Wed, 1 Oct 2008 08:57:11 -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 0490A3A69EA for <rpsec@core3.amsl.com>; Tue, 30 Sep 2008 04:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.866
X-Spam-Level:
X-Spam-Status: No, score=-2.866 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, J_CHICKENPOX_48=0.6]
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 9lP1OlP5Ad7p for <rpsec@core3.amsl.com>; Tue, 30 Sep 2008 04:37:50 -0700 (PDT)
Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by core3.amsl.com (Postfix) with ESMTP id C95F93A69DB for <rpsec@ietf.org>; Tue, 30 Sep 2008 04:37:49 -0700 (PDT)
Received: by mu-out-0910.google.com with SMTP id w1so2149707mue.9 for <rpsec@ietf.org>; Tue, 30 Sep 2008 04:38:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=eclQdtcX5SqXeFO8a1LSsbbMqeV6nrM0ZtZWnndHXUw=; b=fLkj41ai4qQEhFfVMLQuA3N3DOeXxKu4MV5V31C1/l1l+0SugITpIxXhaBujaofunG XaOUcj6f9RMZJU/UJEXYJ1+2N+9r+F/QkBxiwFhFrvfg3OBdtHjcMuUCxmBgdi9V/fMv m7Q1h/l9myrMGR/y+vUCnv9wrFhPPcDvEzhwA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=YUrS6je77g8RgnAbuulzm48kJ5r0OpZZzG2JWa3F9y+gKMr2xn9eyBbS9JRCS9vxFU RX6uOPc9nCWavx/lLIBlUN5esnd7VaxZMFPKRBawHV60+uSHA8g3wS4L1VbiQ0j1bVIf g3BmtSCPgCvyB3G3r0Y1XEoAUfvQfyIpPkTGM=
Received: by 10.181.19.15 with SMTP id w15mr3013618bki.46.1222774688587; Tue, 30 Sep 2008 04:38:08 -0700 (PDT)
Received: by 10.180.226.2 with HTTP; Tue, 30 Sep 2008 04:38:08 -0700 (PDT)
Message-ID: <77ead0ec0809300438v5b126628t69d2388971eb6026@mail.gmail.com>
Date: Tue, 30 Sep 2008 17:08:08 +0530
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
In-Reply-To: <tsld4ilzyno.fsf@mit.edu>
MIME-Version: 1.0
Content-Disposition: inline
References: <48D96507.4000207@sri.com> <20080929200231.3E5DD3F443@pecan.tislabs.com> <77ead0ec0809291853t63940339xc826b13cf5515176@mail.gmail.com> <tsld4ilzyno.fsf@mit.edu>
X-Mailman-Approved-At: Wed, 01 Oct 2008 08:57:10 -0700
Cc: msec@ietf.org, tsvwg@ietf.org, edward.jankiewicz@sri.com, ospf@ietf.org, secdir@mit.edu, sidr@ietf.org, rpsec@ietf.org, dward@cisco.com, Sandy Murphy <sandy@tislabs.com>, rcallon@juniper.net
Subject: Re: [RPSEC] [secdir] [sidr] 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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: rpsec-bounces@ietf.org
Errors-To: rpsec-bounces@ietf.org
Hi Sam, Thanks for the queries. First off the draft is located at http://tools.ietf.org/html/draft-manral-rpsec-existing-crypto-05 and details issues in security even after the current set of security mechanisms are in place. Some issues are well known in the security community like trying to discourage the use of MD5 and instead use HMAC-SHA1 and HMAC-MD5. We have already got drafts for the same to support them in OSPF and ISIS. The issue we have here is the requirement in IPsec of the deployment of authentication identities and credentials and having a authenticating infrastructure (trusted third-party) reachable even before any of the routes are learned. What I was proposing was to instead start off using IPsec in BTNS mode (with say a GTSM check for IKE packets as the authentication mechanism for IKE packets - and no 3rd aprty authentication) and learn routes. Once this happens an optional second level of stronger authentication can be done as all routes are now available (if it is so desired). So we get the complete IPsec security - except for the fact that we rely on TTL mechanisms for the IKE at the beginning. Do let me know what you think about the idea? Thanks, Vishwas On 9/30/08, Sam Hartman <hartmans-ietf@mit.edu> wrote: >>>>>> "Vishwas" == Vishwas Manral <vishwas.ietf@gmail.com> writes: > > Vishwas> We can also solve the problem similarly by something like > Vishwas> BTNS(ofcourse Multicast part needs to be thought further) > Vishwas> which does not necessarily require any certificate > Vishwas> verification - so we may have unauthenticated IKE SA's > Vishwas> but then all keys for the CHILD_SA from there are > Vishwas> automatically generated. > > > Let me see if I understand this approach correctly. I want to > interact with OSPF. Somehow there is a group key that is in use on my > link. In order to obtain this key, I exchange in an unauthenticated > BTNS-style exchange with someone, and as a result of that exchange, > obtain the key? > > First, who do I perform this exchange with? Anyone who currently holds the > key? > > Second, what threats does this protect against? > > Finally, one of the things we typically desire from BTNS-style > protocols is a way to turn them into higher-infrastructure protocols when > the infrastructure is available. Can I do that with your approach? How? > > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www.ietf.org/mailman/listinfo/rpsec
- [RPSEC] Authentication for OSPFv3 Ed Jankiewicz
- Re: [RPSEC] [OSPF] [sidr] Authentication for OSPF… David Ward
- Re: [RPSEC] [OSPF] [sidr] Authentication for OSPF… Vishwas Manral
- Re: [RPSEC] Authentication for OSPFv3 Sandy Murphy
- Re: [RPSEC] [sidr] Authentication for OSPFv3 Vishwas Manral
- Re: [RPSEC] [secdir] [sidr] Authentication for OS… Sam Hartman
- Re: [RPSEC] [secdir] [sidr] Authentication for OS… Vishwas Manral
- Re: [RPSEC] [sidr] Authentication for OSPFv3 David Ward
- Re: [RPSEC] [OSPF] [sidr] Authentication for OSPF… Acee Lindem
- Re: [RPSEC] [OSPF] [sidr] Authentication for OSPF… Vishwas Manral
- Re: [RPSEC] [secdir] [OSPF] [sidr] Authentication… Sam Hartman
- Re: [RPSEC] [Tsvwg] Authentication for OSPFv3 Brian Weis
- Re: [RPSEC] [OSPF] [sidr] Authentication for OSPF… Sandy Murphy
- Re: [RPSEC] [OSPF] [sidr] Authentication for OSPF… Sandy Murphy
- Re: [RPSEC] [secdir] [OSPF] [sidr] Authentication… Stephen Kent
- Re: [RPSEC] [secdir] [OSPF] [sidr] Authentication… Steven M. Bellovin