Re: [secdir] secdir review of draft-ietf-roll-admin-local-policy-02

<Steve.Hanna@infineon.com> Fri, 02 January 2015 18:26 UTC

Return-Path: <steve.hanna@infineon.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6691B1A01CB; Fri, 2 Jan 2015 10:26:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.012
X-Spam-Level:
X-Spam-Status: No, score=-5.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26qyjSh80zhw; Fri, 2 Jan 2015 10:26:56 -0800 (PST)
Received: from smtp2.infineon.com (smtp2.infineon.com [217.10.52.18]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF7D1A1B6C; Fri, 2 Jan 2015 10:26:55 -0800 (PST)
X-SBRS: None
Received: from unknown (HELO mucxv001.muc.infineon.com) ([172.23.11.16]) by smtp2.infineon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jan 2015 19:26:54 +0100
Received: from MUCSE609.infineon.com (mucltm01.eu.infineon.com [172.23.8.248]) by mucxv001.muc.infineon.com (Postfix) with ESMTPS; Fri, 2 Jan 2015 19:26:52 +0100 (CET)
Received: from KLUSE612.infineon.com (172.28.156.138) by MUCSE609.infineon.com (172.23.7.110) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 2 Jan 2015 19:26:52 +0100
Received: from KLUSE610.infineon.com (172.28.156.137) by KLUSE612.infineon.com (172.28.156.138) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 2 Jan 2015 19:26:51 +0100
Received: from KLUSE610.infineon.com ([172.28.148.8]) by KLUSE610.infineon.com ([172.28.148.8]) with mapi id 15.00.0995.032; Fri, 2 Jan 2015 19:26:51 +0100
From: <Steve.Hanna@infineon.com>
To: <consultancy@vanderstok.org>
Thread-Topic: secdir review of draft-ietf-roll-admin-local-policy-02
Thread-Index: AdAff2eol7wcDrkvTNS1G9OE6YCkGQG7cxgAAA8u32A=
Date: Fri, 2 Jan 2015 18:26:50 +0000
Message-ID: <75d052c652b043c88c3ecc3c469b6bcb@KLUSE610.infineon.com>
References: <7e9a24ab8a294586bc19f23673551c24@KLUSE610.infineon.com> <5e5cc9fe445de45d78bc05604a308da6@xs4all.nl>
In-Reply-To: <5e5cc9fe445de45d78bc05604a308da6@xs4all.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [172.23.8.247]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0A15_01D0268F.C1F40D00"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/EdVerhLI5pH3BTvBthL6XZfA4Ec
Cc: iesg@ietf.org, draft-ietf-roll-admin-local-policy.all@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-roll-admin-local-policy-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 02 Jan 2015 18:27:00 -0000

Peter,

Thanks for your prompt response. I have added some more comments below, 
delimited with <steve>.

Steve

-----Original Message-----
From: peter van der Stok [mailto:stokcons@xs4all.nl]
Sent: Friday, January 02, 2015 5:19 AM
To: Hanna Steve (IFNA CCS SMD AMR)
Cc: secdir@ietf.org; iesg@ietf.org; 
draft-ietf-roll-admin-local-policy.all@tools.ietf.org
Subject: Re: secdir review of draft-ietf-roll-admin-local-policy-02

Dear Steve,

thanks for the comments. I will respond below to the points you raise.

Greetings, Peter

Steve.Hanna@infineon.com schreef op 2014-12-30 13:55:

> This document describes a technique for automatically managing the
> boundaries of the admin-local multicast scope in a border router,
> using MPL (Multicast Protocol for Low power and Lossy Networks).
<peter>
Correct
</peter>
>
> In my view, this document is Not Ready.
>
> The document is hard to understand. For example, the acronyms MPL and
> MPL4 are used throughout the document but they are not defined.
<peter>
You are the third to remark on this point. Adrian did suggestions to
improve the document with a definition of MPL, that we will take over.
MPL4 concepts are defined in section 1.2.
</peter>
<steve>
I'm happy to see that you'll be adding a definition of MPL. That's good.

While it's true that section 1.2 defines several terms that include MPL4
(e.g., "MPL4 message"), the term "MPL4" is never defined anywhere.
I found that confusing.
</steve>
>
> After reading the document several times, I have concluded that
> section 3.2 contains the most important part of the document: an
> algorithm for automatically defining the boundaries of the admin-local
> multicast scope using MPL. This section basically says that a border
> router should periodically send an MPL message on all interfaces to
> the ALL_MPL_FORWARDERS multicast address with admin-local scope. It
> should also listen for such messages on all interfaces. If it receives
> such a message, that interface should be marked as part of the
> admin-local scope.
>
> This algorithm seems problematic from a security standpoint. Because
> any device on a network can send an MPL message to the
> ALL_MPL_FORWARDERS multicast address with admin-local scope, the
> boundaries of the admin-local multicast scope can be expanded by
> attackers fairly easily. Such manipulation may permit nodes that
> should be outside a particular administrative domain to join that
> domain and participate in receiving and sending multicast traffic
> within that domain. The implications of such an attack are not clear
> to me because I am not familiar with the protocols and devices that
> use admin-local multicast scope. However, it seems likely that
> expanding the admin-local multicast scope will permit external
> attackers to more easily monitor multicast traffic that should be
> private and to inject multicast messages into a relatively trusted
> domain.
<peter>
In the discussion with Joel, we came to the conclusion that we were not
very clear with respect to the administrative zone specification.
We suggested to limit the mpl admin-local scope within one zone.
The text will be extended to include this extra limit on the boundary of
admin-local-scope.
The extent of the scope does not specify anything about the contents of
the MPL messages.
It is expected that MPL messages are encrypted depending on the wanted
security level.
Monitoring by an attacker limits itself to counting messages, which is
already possible on wireless links any way.
To inject messages, the attacker should know the keys necessary to
encrypt.
When messages are not encrypted they are already readable on the
wireless links, and the monitoring by extending the mpl-admin-local
scope does not increase the vulnerability to snooping the messages.
</peter>
<steve>
Please send me a copy of your new text limiting the admin-local scope
to one zone. I don't see how this will help but maybe the new text will
make it clear.

You just stated that "It is expected that MPL messages are encrypted".
However, this is never stated in draft-ietf-roll-trickle-mcast-11.txt or in
draft-ietf-roll-admin-local-policy-02.txt. In fact, there's no mention of
encryption in those documents at all. If the security of your design
depends on this encryption, you'd better talk about it somewhere!

Now I'd like to investigate the security provided by this encryption.
Are you expecting that application-layer encryption will be used?
I suppose not because that would require extensive description
And you provided none. Probably you're thinking about link-layer
encryption such as that provided by IEEE 802.11i. However, I don't
think that such encryption will prevent the attacks that I described.

A border router frequently spans networks that are part of multiple
administrative domains. Your current design (even with link encryption)
means that any device connected to any of these networks can dictate
the boundaries of the admin-local scope. Is it really desirable to trust
all those devices to that extent? I think not.
</steve>

>
> In addition to this fundamental concern, I have a few minor concerns
> about the readability of the document. However, I seem to have mislaid
> my notes during the holidays. Because this review is already late and
> I'm on vacation, I will send the review now and follow up with the
> minor concerns at a later date if I can find them when I return to the
> office.
<peter>
If you find terms which are not defined in this draft,
ietf-rol-trickle-mcast or RFC7346, I will be happy to extend the
definitions of section 1.2.
</peter>
<steve>
OK, I'll look for my notes. However, the most important aspect of
my review is the security issue described above.
</steve>