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

From: peter van der Stok <[email-masked]>
Date: Fri, 02 Jan 2015 11:19:26 +0100

Dear Steve,

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

Greetings, Peter

[email-masked] 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>
> 
> 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>
> 
> 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>
> Thanks,
> Steve

---

From: <[email-masked]>
Date: Fri, 2 Jan 2015 18:26:50 +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:[email-masked]]
Sent: Friday, January 02, 2015 5:19 AM
To: Hanna Steve (IFNA CCS SMD AMR)
Cc: [email-masked]; [email-masked]; 
[email-masked]
Subject: Re: secdir review of draft-ietf-roll-admin-local-policy-02

Dear Steve,

Greetings, Peter

<peter>
Correct
</peter>
<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>
<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>

<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>

---

From: Robert Cragie <[email-masked]>
Date: Wed, 07 Jan 2015 13:25:46 +0000

Steve,

My comments inline, bracketed by <rcc></rcc>.

Robert

On 02/01/2015 18:26, [email-masked] wrote:
>> 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>
>> Such manipulation may permit nodes that
<rcc>Again, it has to have been authenticated to one or more networks 
and obtained the relevant key before it can do this.</rcc>
> all those devices to that extent? I think not.
<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>

---

From: peter van der Stok <[email-masked]>
Date: Wed, 14 Jan 2015 09:17:50 +0100

Hi all,

I propose the following additions to the draft:

-   Add a section 4.3 Encryption rules
With content:
Incoming MPL4 messages, encrypted at layer 2, MUST be encrypted at layer 
2 at all outgoing interfaces. This is done either by decrypting at the 
incoming interface and encrypting at the outgoing interface with the 
appropriate keys and encryption algorithm, or by sending the MPL4 
message unmodified at the outgoing interface. Incoming MPL4 messages 
which are not encrypted at layer 2 MUST not be encrypted at layer 2 at 
the outgoing interfaces.

- Add text to section 7
An attacker can send an MPL4 message with the effect that MPL4 messages 
are sent to the connected link or mesh. This possibly unwanted extension 
of the MPL4 zone is limited to the enveloping zone. Its duration is 
limited by MPL_CHECK_INT parameter. A manager of the MPL4 router can set 
MPL_enabled to FALSE on certain interfaces to restrict this misuse even 
more. In the worst case the attacker is located on an open wifi link 
where the IEEE802.11 interface is connected to a MPL4 router connected 
to other mesh interfaces. The rules of section 4.3 protect the integrity 
of the MPL4 messages, and prevent that MPL4 messages from the attacker 
are accepted by nodes that are part of a mesh protected at layer 2.

I think this covers the cases coming forward in the discussion.
Looking forward to improvements on the proposed text.

Greetings,

peter

Robert Cragie schreef op 2015-01-07 14:25:
> <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>
> 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.
>

---

From: <[email-masked]>
Date: Wed, 14 Jan 2015 22:08:42 +0000

Rob,

I have removed areas where we agree below and added new comments marked with
<steve2>.

Thanks,

Steve

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>

<rcc>

the MPL4 message.

superordinate entity.

</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>

---

From: <[email-masked]>
Date: Wed, 14 Jan 2015 22:08:45 +0000

Peter,

Thanks for addressing the issue that I raised.

Your proposal is not very strong. If the border router has interfaces on two 
networks that both have layer 2 encryption, any device on either of those 
networks can cause the boundaries of the admin-local scope to be changed. Am I 
wrong?

Thanks,

Steve

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]]
Sent: Wednesday, January 14, 2015 3:18 AM
To: [email-masked]
Cc: Hanna Steve (IFNA CCS SMD AMR); [email-masked]; 
[email-masked]; [email-masked]; 
[email-masked]
Subject: Re: secdir review of draft-ietf-roll-admin-local-policy-02

Hi all,

- Add text to section 7

Greetings,

peter

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Jan 2015 17:56:15 -0500

peter van der Stok <[email-masked]> wrote:
    > Incoming MPL4 messages, encrypted at layer 2, MUST be encrypted at
    > layer 2 at 
    > all outgoing interfaces. This is done either by decrypting at the
    > incoming 
    > interface and encrypting at the outgoing interface with the appropriate
    > keys

this works.

    > by sending the MPL4 message unmodified at the
    > outgoing interface.

This does not work in 15.4, it's just not how things work, because parts of
the packet changes, so the nonces change, etc.

<[email-masked]> wrote:
    Steve> Thanks for addressing the issue that I raised.

    Steve> Your proposal is not very strong. If the border router has
    Steve> interfaces on two networks that both have layer 2 encryption, any
    Steve> device on either of those networks can cause the boundaries of the
    Steve> admin-local scope to be changed. Am I wrong?

I don't understand the attack.
Can you explain ?
All nodes with access to the raw data can replicate it elsewhere.
I think that you are suggesting that some node can cause the border router to
change it's admin-local scope.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-