Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Thu, 27 May 2010 23:02 UTC

Return-Path: <manav.bhatia@alcatel-lucent.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 134143A69EB for <secdir@core3.amsl.com>; Thu, 27 May 2010 16:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
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 syV-iZR-g+XB for <secdir@core3.amsl.com>; Thu, 27 May 2010 16:02:19 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 0022E3A69DE for <secdir@ietf.org>; Thu, 27 May 2010 16:02:16 -0700 (PDT)
Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o4RN1xb2010781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 May 2010 18:02:02 -0500 (CDT)
Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o4RN1vJA000556 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 28 May 2010 04:31:57 +0530
Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.59]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 28 May 2010 04:31:57 +0530
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: Sam Hartman <hartmans-ietf@mit.edu>, Nicolas Williams <Nicolas.Williams@oracle.com>
Date: Fri, 28 May 2010 04:31:55 +0530
Thread-Topic: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04
Thread-Index: Acr9zStFnVtOJ7J9Shy7FXBVK4VIRwAImYKg
Message-ID: <7C362EEF9C7896468B36C9B79200D8350CCEB21839@INBANSXCHMBSA1.in.alcatel-lucent.com>
References: <20100520172310.GQ9605@oracle.com> <tsl632918s3.fsf@mit.edu>
In-Reply-To: <tsl632918s3.fsf@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31
X-Mailman-Approved-At: Mon, 31 May 2010 08:13:49 -0700
Cc: "shares@nexthop.com" <shares@nexthop.com>, "jjaeggli@checkpoint.com" <jjaeggli@checkpoint.com>, "vishwas@ipinfusion.com" <vishwas@ipinfusion.com>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Review of draft-ietf-opsec-routing-protocols-crypto-issues-04
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: Thu, 27 May 2010 23:02:20 -0000

Hi Sam,

> 
> This document talks a lot about collision attacks against MD5 and then
> draws the conclusion that MD5 should not be used as part of a MAC.  I
> agree that it is prudent to provide alternatives to MD5.  However, I
> think the current text implies that collision attacks against MD5 are
> applicable to attacks against the use of MD5 in routing protocols.

Not really. We do mention this at the beginning:

"  The ability to produce a collision does not currently introduce any
   obvious or known attacks on routing protocols. Pre-image attacks have
   the potential to cause problems in the future albeit due to the
   message length there are serious limitations to the feasibility of
   mounting such an attack.

   Protocols themselves have some built-in protection against collision
   attacks. This is because a lot of values for fields in a protocol
   packet are invalid or will produce an unusable packet. For example,
   in OSPF the LSA type can be from 1 to 11. Any other value in the
   field will result in the packet being discarded.

   Assume two packets M and M' are generated which have the same hash.
   The above condition will further reduce the ability to produce a
   message which is also a correct message from the protocol
   perspective, as a lot of potential values are themselves not valid."


> 
> There is an introductory section that describes the difference between
> pre image and collision attacks, but the rest of the document seems to
> ignore the advice of that section.

I think what we're trying to say is the following:

Routing Protocols currently use MD5. There are attacks against MD5, but they may not lead to routing vulnerabilities (Sec 1.1). However, we discourage the use of such algorithms. The exact text that we used for OSPF is this - "Attacks on many applications of MD5 are practical on modern computers. For this reason the general use of these algorithms should to be discouraged.[RFC5709] adds support for using HMAC-SHA with OSPF."

We have currently not found direct vulnerabilities when using MD5 with Routing protocols, but going forward one could actually construct a packet that could adversely affect routing protocol functioning.

Manav

>