Re: [secdir] secdir review of draft-ietf-roll-admin-local-policy-02
<Steve.Hanna@infineon.com> Wed, 14 January 2015 22:08 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 8D3D91ACE01; Wed, 14 Jan 2015 14:08:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 uJQbq9v9D0Er; Wed, 14 Jan 2015 14:08:47 -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 0DD391ACE00; Wed, 14 Jan 2015 14:08:45 -0800 (PST)
X-SBRS: None
Received: from unknown (HELO mucxv002.muc.infineon.com) ([172.23.11.17]) by smtp2.infineon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jan 2015 23:08:44 +0100
Received: from MUCSE607.infineon.com (mucltm.muc.infineon.com [172.23.8.247]) by mucxv002.muc.infineon.com (Postfix) with ESMTPS; Wed, 14 Jan 2015 23:08:43 +0100 (CET)
Received: from MUCSE609.infineon.com (172.23.7.110) by MUCSE607.infineon.com (172.23.7.108) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 14 Jan 2015 23:08:42 +0100
Received: from MUCSE609.infineon.com ([172.23.103.71]) by MUCSE609.infineon.com ([172.23.103.71]) with mapi id 15.00.0995.032; Wed, 14 Jan 2015 23:08:42 +0100
From: Steve.Hanna@infineon.com
To: robert.cragie@gridmerge.com, consultancy@vanderstok.org
Thread-Topic: secdir review of draft-ietf-roll-admin-local-policy-02
Thread-Index: AdAff2eol7wcDrkvTNS1G9OE6YCkGQG7cxgAAA8u32AA8sgYAAF0A7KA
Date: Wed, 14 Jan 2015 22:08:42 +0000
Message-ID: <ded462d125cc48b0b667baf77b82ff49@MUCSE609.infineon.com>
References: <7e9a24ab8a294586bc19f23673551c24@KLUSE610.infineon.com> <5e5cc9fe445de45d78bc05604a308da6@xs4all.nl> <75d052c652b043c88c3ecc3c469b6bcb@KLUSE610.infineon.com> <54AD33DA.5080006@gridmerge.com>
In-Reply-To: <54AD33DA.5080006@gridmerge.com>
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_005F_01D0301C.BDE28160"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/HBA8Nowj5wHv4xgEkNQUugnU7fU>
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: Wed, 14 Jan 2015 22:08:52 -0000
Rob, I have removed areas where we agree below and added new comments marked with <steve2>. Thanks, 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. <rcc>I guess it depends what you mean by "fairly easily". An attacker in this case would have interfaces on more than one network and would have to be authenticated on all networks in question. The attack scenario may be just to attach to one network and then forward into other network(s) which would not originally be considered part of the admin-local scope (which is I think what you are saying below) but it still has to authenticate to the network being attacked and obtain the relevant key before its interface on that network can validly receive a MPL4 message.</rcc> <steve2>I don't see why the attacker would need to have interfaces on more than one network. See the ASCII art diagram below: H1 - R - H2 Border router R has two network interfaces. H1 and H2 are hosts connected to these interfaces. If both H1 and H2 send MPL4 messages and R has MPL4 enabled on those interfaces, R will put both networks into the same admin-local multicast scope. Am I wrong? </steve2> >> 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. <rcc>Again, it has to have been authenticated to one or more networks and obtained the relevant key before it can do this.</rcc> > <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> <rcc> The concept of scope, network boundary and security boundary are all somewhat orthogonal. RFC7346 acknowledges this with additional text and draft-ietf-roll-admin-local-policy explains how automatic configuration for realm-local scope occurs in relation to a network identifier, which then links network boundary and realm-local scope. However, there isn't necessarily a one-to-one correspondence between security boundary and network boundary even though it often happens in practice, e.g. a WPA2 key for an 802.11 WLAN or network key for ZigBee IP WPAN, for example. Assuming this link-layer encryption, I don't think the attacks can take place as an attacker would have to authenticate itself to the network being attacked first or else it would not be able to validly received the MPL4 message. It is true that a border router configured with multiple MPL-enabled interfaces does indeed by implication expand the admin-local scope, however it is not obliged to have all its interfaces MPL-enabled; this is part of configuration as well, potentially controllable by some superordinate entity. Perhaps we need some extra text to explain this. </rcc> <steve2> Certainly, if extending the admin-local scope has no security implications, there's no security problem here. However, that is probably not a universal understanding. You should explain this issue in the Security Considerations section and describe the circumstances when it is a problem and when it is not. This will equip the reader to decide what to do. Just because a host has the keys needed to join one network does not mean that they should be permitted to change the admin-local scope boundaries between that network and all other networks joined via border routers. </steve2>
- [secdir] secdir review of draft-ietf-roll-admin-l… Steve.Hanna
- Re: [secdir] secdir review of draft-ietf-roll-adm… peter van der Stok
- Re: [secdir] secdir review of draft-ietf-roll-adm… Steve.Hanna
- Re: [secdir] secdir review of draft-ietf-roll-adm… Robert Cragie
- Re: [secdir] secdir review of draft-ietf-roll-adm… peter van der Stok
- Re: [secdir] secdir review of draft-ietf-roll-adm… Steve.Hanna
- Re: [secdir] secdir review of draft-ietf-roll-adm… Steve.Hanna
- Re: [secdir] secdir review of draft-ietf-roll-adm… Michael Richardson
- Re: [secdir] secdir review of draft-ietf-roll-adm… peter van der Stok