IETF Logo Mail Archive

Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-03.txt

Joel Jaeggli <joelja@bogus.com> Sat, 06 December 2008 03:27 UTC

Return-Path: <opsec-bounces@ietf.org>
X-Original-To: opsec-archive@optimus.ietf.org
Delivered-To: ietfarch-opsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D57B3A682A; Fri, 5 Dec 2008 19:27:07 -0800 (PST)
X-Original-To: opsec@core3.amsl.com
Delivered-To: opsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EF8D3A682A for <opsec@core3.amsl.com>; Fri, 5 Dec 2008 19:27:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 YIQ2r+YMIKrg for <opsec@core3.amsl.com>; Fri, 5 Dec 2008 19:27:04 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 913313A6811 for <opsec@ietf.org>; Fri, 5 Dec 2008 19:27:04 -0800 (PST)
Received: from [192.168.1.118] (c-24-130-16-195.hsd1.ca.comcast.net [24.130.16.195]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id mB63QpVi017561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 6 Dec 2008 03:26:56 GMT (envelope-from joelja@bogus.com)
Message-ID: <4939F0FA.5030004@bogus.com>
Date: Fri, 05 Dec 2008 19:26:50 -0800
From: Joel Jaeggli <joelja@bogus.com>
User-Agent: Thunderbird 2.0.0.18 (X11/20081119)
MIME-Version: 1.0
To: Christopher Morrow <christopher.morrow@gmail.com>, opsec wg mailing list <opsec@ietf.org>
References: <6D26D1FE43A66F439F8109CDD424196502356DBA@INEXC1U01.in.lucent.com> <92c950310812030850q5c76f39ak1754c70dc216a354@mail.gmail.com> <4938D042.8090108@bogus.com> <75cb24520812050425p1a52602bydb18e3878d540eb@mail.gmail.com>
In-Reply-To: <75cb24520812050425p1a52602bydb18e3878d540eb@mail.gmail.com>
X-Enigmail-Version: 0.95.7
X-Virus-Scanned: ClamAV 0.93.3/8728/Fri Dec 5 15:44:27 2008 on nagasaki.bogus.com
X-Virus-Status: Clean
Subject: Re: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-03.txt
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: opsec-bounces@ietf.org
Errors-To: opsec-bounces@ietf.org

Christopher Morrow wrote:

> the secrets stay the same because someone though adding md5 auth to
> routing protocols was a good thing (which is probably is in some/many
> cases) but stopped there. There was never any thought put into the
> operations of the system, just the 'security'... Key rollover/change
> is significantly painful that pretty much no one actually does it.

solving this problem is safely outside the scope of our working group. ;)

That said one could imagine adding some additional element to the shared
secret that could be derived at startup of the protocol session
(wouldn't work for broadcast) like current time at transmission of the
first packet, that would make the actual shared secret on the wire only
relevant for the duration of a single session, (it would require clocks
have a certain minimum amount of syncronization) without further
negotiation.
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

v2.23.0 | Report a Bug | By Email