Re: [RPSEC] Topic 1: Section 3.1 Threat Sources

Stephen Kent <kent@bbn.com> Mon, 17 March 2003 15:26 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17079 for <rpsec-archive@odin.ietf.org>; Mon, 17 Mar 2003 10:26:27 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HFgqg08855 for rpsec-archive@odin.ietf.org; Mon, 17 Mar 2003 10:42:52 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HFgqO08852 for <rpsec-web-archive@optimus.ietf.org>; Mon, 17 Mar 2003 10:42:52 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17063 for <rpsec-web-archive@ietf.org>; Mon, 17 Mar 2003 10:25:55 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HFg1O08774; Mon, 17 Mar 2003 10:42:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HFfeO08745 for <rpsec@optimus.ietf.org>; Mon, 17 Mar 2003 10:41:40 -0500
Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17009 for <rpsec@ietf.org>; Mon, 17 Mar 2003 10:24:43 -0500 (EST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2HFQS5w018993; Mon, 17 Mar 2003 10:26:28 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@po2.bbn.com
Message-Id: <p05100308ba9b982b5f1e@[128.89.88.34]>
In-Reply-To: <Pine.GSO.4.44.0303141616110.1700-100000@yiya-u10.cisco.com>
References: <200303112234.h2BMYTK26435@raven.gw.tislabs.com> <Pine.GSO.4.44.0303141616110.1700-100000@yiya-u10.cisco.com>
Date: Mon, 17 Mar 2003 10:22:31 -0500
To: Yi Yang <yiya@cisco.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] Topic 1: Section 3.1 Threat Sources
Cc: rpsec@ietf.org
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: rpsec-admin@ietf.org
Errors-To: rpsec-admin@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Id: Routing Protocol Security Requirements <rpsec.ietf.org>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=subscribe>

At 4:40 PM -0500 3/14/03, Yi Yang wrote:
>Sandy,
>
>>  (2.a) That doesn't apply to some (many?) protocols.
>>
>>  For some protocols, there is no sense of an authorized peer.  For
>>  OSPF (that is, before the MD5 part got added), OSPF speaks to all
>>  routers on the local link that answer to the AllSPFRouters multicast
>>  address.  MANET protocols frequently speak over the broadcast link
>>  (as mentioned earlier in the draft).  And so forth.
>
>You are right. IMHO, however, this is because in most IGPs, authentication
>(such as MD5) is used a mechanism of authorization, instead of
>identication. And current implementations just don't care the
>identification in most cases.
>
>But in the future, we might also want to care about the identification as
>well.
>
>>  (2.c) It's misleading, security wise.
>>
>>  When I saw this in the draft, I got to thinking about what makes a
>>  threat source distinct.  A threat source should be considered
>>  separately if it has a capability that gives it extra power, if it can
>>  launch attacks that others cannot, or if there are security
>>  defenses that work against it and not against others.  Now an
>>  unauthorized router has the same capabilities and can perform the same
>>  attacks as a masquerader, but it can be eliminated by doing pure
>>  address based filtering of some sort where masqueraders cannot.
>>
>>  By that criterion, the unauthorized router is a separate threat source
>>  only if one considers pure address based filtering as a "security
>>  defense".
>>
>>  I don't.  In a big way, I don't.  To call such an easily circumvented
>>  mechanism a security defense makes me extremely uneasy.
>>
>>  I was emboldened to speak up about this by reading the IAS security
>>  mechanisms draft draft-iab-secmech-02.txt that came out a few weeks
>>  ago.  Bellovin, Kaufman and Schiller list address-based authentication
>>  as an "Insecurity Mechanism", along with plaintext passwords (emphasis
>>  on the "In").  To quote, "Some common security mechanisms are part of
>>  the problem rather than part of the solution."
>>
>>  I think if we left unauthorized routers as a distinct threat source,
>>  we'd see claims like ".. and our ACME router's address filtering
>>  eliminates unauthorized routers, recognized by the IETF as one of the
>>  biggest threats to routing.."
>
>I agree w/ you using a pure address filtering mechanism is insecure. But I
>don't think it is the only mechanism to seperate masqueraders from the
>unauthorized. For example, digital signature can be used for
>identification while MD5 can be used for authorization.
>
>Yi
>

MD5 is an un-keyed integrity mechanism. Hashed MACs, like HMAC, can 
be used for authentication to the extent that the key used with them 
is associated with known entities. The keyed MD5 checksum sometimes 
used with BGP is a cryptographically poor example of a hashed MAC.

In no case should one consider MD5 to be an authorization mechanism.

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