[OPSEC] draft-bhatia-manral-igp-crypto-requirements-00.txt

"Bhatia, Manav \(Manav\)" <manav@alcatel-lucent.com> Thu, 09 October 2008 07:59 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 B94743A6C79; Thu, 9 Oct 2008 00:59:03 -0700 (PDT)
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 BBC823A6C68 for <opsec@core3.amsl.com>; Thu, 9 Oct 2008 00:59:02 -0700 (PDT)
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 vcGATjhkBCIA for <opsec@core3.amsl.com>; Thu, 9 Oct 2008 00:58:57 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id AB7D33A6C79 for <opsec@ietf.org>; Thu, 9 Oct 2008 00:58:57 -0700 (PDT)
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id m997xWwb014188; Thu, 9 Oct 2008 02:59:33 -0500 (CDT)
Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 02:59:32 -0500
Received: from INEXC1U01.in.lucent.com ([135.254.223.26]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Oct 2008 13:29:28 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 09 Oct 2008 13:29:27 +0530
Message-ID: <6D26D1FE43A66F439F8109CDD42419650200B154@INEXC1U01.in.lucent.com>
In-Reply-To: <AF93875118CE454893CE91658901DAA106BD884F@xmb-ams-333.emea.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-bhatia-manral-igp-crypto-requirements-00.txt
Thread-Index: AcklyL0wFx8h/26sQoiIn+iEsW4zFAB2XYAQAIoBOfA=
References: <92c950310808250646t50c00ce0w8a778dc19c08188b@mail.gmail.com> <77ead0ec0809302014p336614afp433ea8de040713c5@mail.gmail.com><6D26D1FE43A66F439F8109CDD424196501ED2F61@INEXC1U01.in.lucent.com> <48E6D46B.7020401@bogus.com> <AF93875118CE454893CE91658901DAA106BD884F@xmb-ams-333.emea.cisco.com>
From: "Bhatia, Manav (Manav)" <manav@alcatel-lucent.com>
To: "Steinthor Bjarnason (sbjarnas)" <sbjarnas@cisco.com>, opsec@ietf.org
X-OriginalArrivalTime: 09 Oct 2008 07:59:28.0386 (UTC) FILETIME=[F43F9620:01C929E4]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Subject: [OPSEC] draft-bhatia-manral-igp-crypto-requirements-00.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

Hi,

> > 
> > http://tools.ietf.org/html/draft-bhatia-manral-igp-crypto-requ
> irements-00
> > 
> > I have concerns about this document making protocol 
> > requirements within the scope of our charter. Making this a 
> > set of protocol best practices I think hews more closely to 
> > our charter (and doesn't belong in routing).
> > 
> > any thoughts on that?
> > 
> I see the benefit in having a document which recommends which routing
> protocol authentication schemes to use.  Having such a document
> available, will automatically put pressure on the routing protocol
> developers to implement what's missing (in case there are still some
> implementations out there which still do not support this).

Agree. 

I think this document too falls in the purview of OPSEC as this would
ensure interop between disparate router implementations where at least
one strong crypto algorithm is available that's implemented by all
vendors.

For example, we need to move folks using OSPF away from keyed MD5 and
there should be some document that suggests that. It should also be
noted that an algorithm that's considered strong today can be broken
tomorrow and may have vulnerabilities that can be exploited. In such
cases, we must have a document that vendors/operators can look up
against, before implementing/using a routing protocol security scheme.

This document does exactly that - it, to cite the same example,
discourages people running OSPF from using keyed MD5 (it's a MUST-) and
encourages the use of HMAC-SHA-1 [x] and other stronger algorithms. 

> 
> So, I suggest this document should be adopted by the WG but 
> with a more
> "recommend/best practice" focus.

It should be a standards track document. Please look at RFC 4307, 4835,
etc. 

> 
> > problems with manual keying seems straight up our alley.
> > 
> > http://tools.ietf.org/html/draft-manral-rpsec-existing-crypto-05
> > 
> > and I have no reservations for taking that one to our ADs.
> > 
> Agree 100%

True.

Cheers,
Manav

[x] http://tools.ietf.org/html/draft-ietf-ospf-hmac-sha-02
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec