Subject: [core] Spoofing in CoAP

From: Thomas Fossati <[email-masked]>
Date: Mon, 1 Aug 2011 19:56:55 +0200

Hi all,

the Security Consideration section of draft-ietf-core-coap fails to acknowledge what I perceive as a major security threat in the CoAP protocol: IP address spoofing.

Due to the non-reliability of UDP (and to some extent to the duplicate messages processing strategy too), a rogue endpoint which is free to read and write messages carried by the constrained network (i.e. NoSec or SharedKey deployments, and also, though with a possibly narrower scope, MultiKey with nodes/key ratio > 1:1), may easily attack a single endpoint, a group of endpoints, as well as the whole network. E.g. by:

1 - spoofing RST in response to a CON message, thus making an endpoint "deaf"; or
2 - spoofing the entire response with forged payload/options (this has different levels of impact: from single response disruption, to much bolder attacks on the supporting infrastructure, e.g. poisoning proxy caches, or tricking validation / lookup interfaces in resource directories and, more generally, any component that stores global network state and uses CoAP as the messaging facility to handle state set/update's is a potential target.); or
3 - spoofing a multicast request for a target node which may result in both network congestion/collapse and victim DoS'ing / forced wakeup from sleeping; or
4 - spoofing observe messages, etc.

{{ 1-3 can be combined together (e.g. 3 to mute an endpoint, and 2 to act as the endpoint with respect to a client) if needed (e.g make 4 cleaner). }}

Practically every corner of the messaging layer can be abused in this way, which IMO asks for a clear warning sign to be exposed in the spec.

In principle, spoofing can be detected by CoAP only in case CON semantics is used, because of unexpected ACK/RSTs coming from the deceived endpoint.  But this imposes keeping track of the used MIDs which is not always possible, and moreover detection becomes available usually after the damage is already done.

Anyway, when the threat of a "bad thing" -- as opposed to the usual "bad guy" :-) -- is concrete and painful, the only real solution is to use MultiKey(1:1) or Certificate modes.  Any other security setup would lead (with different levels of ramification, and involving more or less complexity on the attacker side), to vulnerable deployments.

Bye, t.

PS about attack feasibility: I fear that getting crypto keys from a large, unattended, constrained network would not be a particularly hard task: one or more endpoints could be easily stolen, and key extraction (i.e. locate high entropy bytes out of a tiny storage) should be quite feasible with such simple devices.  In such scenarios (i.e. large, unattended deployments), infiltrating rogue endpoints could be really cheap and effective.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 02 Aug 2011 08:18:32 -0400

It is borderline impossible to defend against layer 3 attacks at layer 5 
(or 4 depending on where you place DTLS, but I look at it as 5).  This 
is fairly well understood and why I push for 'defense in depth' with all 
layers being secured:  MAC, IP, Transport (though perhaps TCPcrypt done 
right fits in here too).

Given this, you ARE allowed to state in your security considerations 
that this is a layer 3 attack and SHOULD be addressed with a layer 3 
security framework like ESP.

Of course, securing at all layers has its cost.  This can be mitigated 
by having a single KMP that works for them all.  It could be further 
addresses if we went after good security APIs, such that optimize 
security work when there really is overlap (say devices are only a 
single hop so MACsec could 'address' all needs).

On 08/01/2011 01:56 PM, Thomas Fossati wrote:
> Due to the non-reliability of UDP (and to some extent to the duplicate messages processing strategy too), a rogue endpoint which is free to read and write messages carried by the constrained network (i.e. NoSec or SharedKey deployments, and also, though with a possibly narrower scope, MultiKey with nodes/key ratio>  1:1), may easily attack a single endpoint, a group of endpoints, as well as the whole network. E.g. by:
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

-- 
Robert Moskowitz
Senior Technical Advisor
Security & Standards
Verizon Business Systems
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 2 Aug 2011 15:49:10 +0200

On Aug 2, 2011, at 2:18 PM, Robert Moskowitz wrote:
> It is borderline impossible to defend against layer 3 attacks at layer 5 (or 4 depending on where you place DTLS, but I look at it as 5).  This is fairly well understood and why I push for 'defense in depth' with all layers being secured:  MAC, IP, Transport (though perhaps TCPcrypt done right fits in here too).
> 
> Given this, you ARE allowed to state in your security considerations that this is a layer 3 attack and SHOULD be addressed with a layer 3 security framework like ESP.

Right.

It scares me thinking about how cheap for the attacker it'd be, and how wide the possible consequences on the CoAP infrastructure are (proxies, RDs, etc.)  Which, in turn, makes me wonder why we don't mandate IPsec instead of DTLS.

t.

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 2 Aug 2011 10:16:24 -0400

On Tue, Aug 2, 2011 at 9:49 AM, Thomas Fossati <[email-masked]> wrote:

> (or 4 depending on where you place DTLS, but I look at it as 5).  This is
> fairly well understood and why I push for 'defense in depth' with all layers
> being secured:  MAC, IP, Transport (though perhaps TCPcrypt done right fits
> in here too).
> >
> > Given this, you ARE allowed to state in your security considerations that
> this is a layer 3 attack and SHOULD be addressed with a layer 3 security
> framework like ESP.
>
> Right.
>
> It scares me thinking about how cheap for the attacker it'd be, and how
> wide the possible consequences on the CoAP infrastructure are (proxies, RDs,
> etc.)  Which, in turn, makes me wonder why we don't mandate IPsec instead of
> DTLS.
>
> t.
>

It seems an additional benefit to mandating IPsec is that it could secure
multicast as well as unicast CoAP traffic?

-K-

---

From: Robert Cragie <[email-masked]>
Date: Tue, 2 Aug 2011 15:38:30 +0100

I agree with Bob's assessment and agree with the 'defense in depth'
approach. Cross-layer key management and support for protocols and cipher
suites which can work across layers is also important.

IPsec has peer-to-peer security associations so multicast doesn't directly
work here. You would need group keys and group SAs for that to work in
IPsec.  I believe there are ways of carrying encapsulated multicast IP
datagrams across SAs using GRE or something similar.

Robert

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 02 Aug 2011 13:38:20 -0400

> It scares me thinking about how cheap for the attacker it'd be, and how wide the possible consequences on the CoAP infrastructure are (proxies, RDs, etc.)  Which, in turn, makes me wonder why we do…

This debate is almost 2 decades old and we will not resolve it here.  
Actually it would be mandating ESP with keying as the DTLS mandate does 
not mandate certificate-based key establishment.

Perhaps wording along the lines of if an API can disclose and manage IP 
layer security to CoAP, the IP layer security can be used instead of DTLS.

One arguement often used for TLS over ESP is packet size and resulting 
communication overhead.  You can have large TLS packets that span 
multiple IP datagrams.  This is often mentioned in cellular 
discussions.  But in CoAP, and DTLS this may NOT be an issue.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 02 Aug 2011 13:43:45 -0400

On 08/02/2011 10:16 AM, Kerry Lynn wrote:
> On Tue, Aug 2, 2011 at 9:49 AM, Thomas Fossati <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > It is borderline impossible to defend against layer 3 attacks at
>     layer 5 (or 4 depending on where you place DTLS, but I look at it
>     as 5).  This is fairly well understood and why I push for 'defense
>     in depth' with all layers being secured:  MAC, IP, Transport
>     (though perhaps TCPcrypt done right fits in here too).
>     >
>     > Given this, you ARE allowed to state in your security
>     considerations that this is a layer 3 attack and SHOULD be
>     addressed with a layer 3 security framework like ESP.
>
>     Right.
>
>     It scares me thinking about how cheap for the attacker it'd be,
>     and how wide the possible consequences on the CoAP infrastructure
>     are (proxies, RDs, etc.)  Which, in turn, makes me wonder why we
>     don't mandate IPsec instead of DTLS.
>
>     t.
>
>

ESP CAN support multicast, the challenge is the keying.  You can create 
a mulitcast overlay on a set of unicast security SAs, using the unicast 
security to transmit the multicast keys.  This could be a simplier 
implementation than adding a multicast key distribution independent of 
the unicast one you need anyway.

BTW, this is basically what we did for IEEE 802.11i.

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 3 Aug 2011 18:26:52 +0200

> multicast as well as unicast CoAP traffic?

Yes, with a caveat: the IPsec SAD support for multicast is limited to manual configuration.  So in cases where the lifetime of the SA is an issue, some other method for handling dynamic SAs configuration is needed.

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 3 Aug 2011 18:38:23 +0200

On Aug 2, 2011, at 7:43 PM, Robert Moskowitz wrote:
> ESP CAN support multicast, the challenge is the keying.  

Right, sorry for the delayed duplicate answer.

> You can create a mulitcast overlay on a set of unicast security SAs, using the unicast security to transmit the multicast keys.  This could be a simplier implementation than adding a multicast key distribution independent of the unicast one you need anyway.

In many use cases (low-to-medium group population) this can be a good solution.  SA lifetimes must be weighted against group cardinality in a sensible way, thus not saturating the medium with control traffic.

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 03 Aug 2011 14:04:52 -0400

> In many use cases (low-to-medium group population) this can be a good solution.  SA lifetimes must be weighted against group cardinality in a sensible way, thus not saturating the medium with contr…

If multicast is REALLY important to CoAP, we probably do need to look at 
a deployable multicast security method.  I would seriously recommend 
looking at the key heirarchy model in IEEE 802.1AE which allows for a 
single master key managed by some entity (out of scope of 1AE and 
addressed in 1X) but a heirarchy that allows for multiple senders.  Of 
course as with any multicast approach you loose source authenticity to 
some degree.

I have been thinking about this for the 802.15.4f situation where the 
sensor has a receive radio that can be used at join time for key 
distribution.  Otherwise a large 4f PAN would be totally unsecurable 
(key scaling problems).

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 3 Aug 2011 14:22:33 -0400

On Wed, Aug 3, 2011 at 2:04 PM, Robert Moskowitz
<[email-masked]>wrote:

>>  You can create a mulitcast overlay on a set of unicast security SAs,
>>> using the unicast security to transmit the multicast keys.  This could be a
>>> simplier implementation than adding a multicast key distribution independent
>>> of the unicast one you need anyway.
>>>
>> In many use cases (low-to-medium group population) this can be a good
>> solution.  SA lifetimes must be weighted against group cardinality in a
>> sensible way, thus not saturating the medium with control traffic.
>>
>
> If multicast is REALLY important to CoAP, we probably do need to look at a
> deployable multicast security method.  I would seriously recommend looking
> at the key heirarchy model in IEEE 802.1AE which allows for a single master
> key managed by some entity (out of scope of 1AE and addressed in 1X) but a
> heirarchy that allows for multiple senders.  Of course as with any multicast
> approach you loose source authenticity to some degree.
>
> distribution.  Otherwise a large 4f PAN would be totally unsecurable (key
> scaling problems).
>
> There are two main scenarios where multicast is indicated.  The first
is for resource discovery bootstrapping (i.e. finding resource directories
if they exist, without a priori configuration, and discovering CoAP
servers and resources directly of RDs don't exist in the network).  It's
not clear that these exchanges need to be secured (nobody seems
overly worried about mDNS or DNS spoofing at the moment) but I
can imagine concerns about this in some applications.

The second scenario is for applications that require near simultaneity
for user quality-of-experience and the oft-cited example is a single
switch controlling a floor of lighting controllers.

In both cases, I suspect that just being able to assert that you're a
"member of the tribe" is sufficient authentication.

-K-

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Aug 2011 12:31:20 -0600

<hat type='individual'/>

On 8/3/11 12:04 PM, Robert Moskowitz wrote:
>>> using the unicast security to transmit the multicast keys.  This
>>> could be a simplier implementation than adding a multicast key
>>> distribution independent of the unicast one you need anyway.
>> solution.  SA lifetimes must be weighted against group cardinality in
>> a sensible way, thus not saturating the medium with control traffic.
> 
> a deployable multicast security method.

Good question. I think it would be helpful for the group to decide how
important multicast is (or is not) to CoAP...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Zach Shelby <[email-masked]>
Date: Wed, 3 Aug 2011 21:40:02 +0300

> important multicast is (or is not) to CoAP...

Secure multicast is not urgent enough for us to solve as part of the current charter IMO, however I do think it is interesting upcoming work for CoRE, or in cooperation with the security area. Something to keep in mind for rechartering. 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 03 Aug 2011 14:51:18 -0400

On 08/03/2011 02:22 PM, Kerry Lynn wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>             You can create a mulitcast overlay on a set of unicast
>             security SAs, using the unicast security to transmit the
>             multicast keys.  This could be a simplier implementation
>             than adding a multicast key distribution independent of
>         In many use cases (low-to-medium group population) this can be
>         a good solution.  SA lifetimes must be weighted against group
>         cardinality in a sensible way, thus not saturating the medium
>         with control traffic.
>
>
>     If multicast is REALLY important to CoAP, we probably do need to
>     look at a deployable multicast security method.  I would seriously
>     recommend looking at the key heirarchy model in IEEE 802.1AE which
>     allows for a single master key managed by some entity (out of
>     scope of 1AE and addressed in 1X) but a heirarchy that allows for
>     multiple senders.  Of course as with any multicast approach you
>     loose source authenticity to some degree.
>
>     I have been thinking about this for the 802.15.4f situation where
>     the sensor has a receive radio that can be used at join time for
>     key distribution.  Otherwise a large 4f PAN would be totally
>     unsecurable (key scaling problems).
>

The switch talks to the energy controller to turn lights on/off (it was 
explained to me how BAD 'toggle' is in this usage; I chuckled at the 
image).  The switch instructs the lights all at once.  So there is a 
single direction of multicast, from the controller to all lights in the 
multicast group.  This is an 'easy' keying problem.  There is an admin 
process that defines the group, and in so doing results in the group key 
distribution:  "These and these lights are for the shop floor and these 
are the lobby."

The real challenge comes if there are multiple senders/listeners.  
Perhaps stress sensors on a bridge to multiple/redundant collectors.

> "member of the tribe" is sufficient authentication.

IF these apps use IP multicast (even broadcast), THEN we SHOULD provide 
IP security.

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 03 Aug 2011 14:58:42 -0400

> Secure multicast is not urgent enough for us to solve as part of the current charter IMO, however I do think it is interesting upcoming work for CoRE, or in cooperation with the security area. Some…

There are 'simple' solutions for things like controlling a bank of 
lights that take little text copying (this is a basic feature in 802.11 
architecture).  For the hard stuff, yeah, push it off :)

---

From: Don Sturek <[email-masked]>
Date: Wed, 03 Aug 2011 12:03:09 -0700

Hi Robert,

Here is a typical scene lighting solution:

1)  Multiple lamps grouped together (multicast group)
2)  Multiple switches (imagine a large room with switches on either end that
can switch on/off the grouped lamps)

I think it would be hard to define lighting to be just single sender to a a
multicast group.

Don

From:  Robert Moskowitz <[email-masked]>
Date:  Wed, 03 Aug 2011 14:51:18 -0400
To:  Kerry Lynn <[email-masked]>
Cc:  <[email-masked]>
Subject:  Re: [core] Spoofing in CoAP

 On 08/03/2011 02:22 PM, Kerry Lynn wrote:
>  
> On Wed, Aug 3, 2011 at 2:04 PM, Robert Moskowitz <[email-masked]>
> wrote:
>  
>>  
>>  
>>>>  You can create a mulitcast overlay on a set of unicast security SAs, using
>>>> the unicast security to transmit the multicast keys.  This could be a
>>>> simplier implementation than adding a multicast key distribution
>>>> independent of the unicast one you need anyway.
>>>>  
>> deployable multicast security method.  I would seriously recommend looking at
>> the key heirarchy model in IEEE 802.1AE which allows for a single master key
>> managed by some entity (out of scope of 1AE and addressed in 1X) but a
>>  I have been thinking about this for the 802.15.4f situation where the sensor
>> has a receive radio that can be used at join time for key distribution.
>> Otherwise a large 4f PAN would be totally unsecurable (key scaling problems).
>>  
>>  
>  
 
 The switch talks to the energy controller to turn lights on/off (it was
explained to me how BAD 'toggle' is in this usage; I chuckled at the image).
The switch instructs the lights all at once.  So there is a single direction
of multicast, from the controller to all lights in the multicast group.
This is an 'easy' keying problem.  There is an admin process that defines
the group, and in so doing results in the group key distribution:  "These
and these lights are for the shop floor and these are the lobby."
 
 The real challenge comes if there are multiple senders/listeners.  Perhaps
stress sensors on a bridge to multiple/redundant collectors.

> "member of the tribe" is sufficient authentication.
 
 IF these apps use IP multicast (even broadcast), THEN we SHOULD provide IP
security.

_______________________________________________ core mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/core

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 03 Aug 2011 15:24:43 -0400

On 08/03/2011 03:03 PM, Don Sturek wrote:
> 2)  Multiple switches (imagine a large room with switches on either 
> end that can switch on/off the grouped lamps)
>
> I think it would be hard to define lighting to be just single sender 
> to a a multicast group.

But do the switches directly communicate to the lights?  Not through an 
energy controller?  I can see a very high failure rate due to RF where 
some lights get the signal from a switch and others do not.  Or are we 
counting on multiple IP relays to get to all the lights so the RF 
reachablity is mitigated?  I suppose so.  It seems so chaotic to do this 
without a controller.  How do you define a lighting group?

Even with multiple switches (hey, my Dad is an electrician and I 
apprenticed under him and did 3-way and 4-way switch wirings), you want 
some intelligence in their control of the lights.

Thinking about this further and wanting to 'simplify' the risk 
boundaries, I can see a controller defining the environment but then 
allowing direct communication in case the controller has been taken down.

Rapping this up, if you go with a controller model, the security is a 
'simple' single sender.  If you go with the more open direct model, wait 
for us to work out the multisender model.

>
>
>
> From: Robert Moskowitz <[email-masked] 
> <mailto:[email-masked]>>
> To: Kerry Lynn <[email-masked] <mailto:[email-masked]>>
> Cc: <[email-masked] <mailto:[email-masked]>>
>>         In many use cases (low-to-medium group population) this can
>>         be a good solution.  SA lifetimes must be weighted against
>>         group cardinality in a sensible way, thus not saturating the
>>         medium with control traffic.
>>
>>
>>     look at a deployable multicast security method.  I would
>>     seriously recommend looking at the key heirarchy model in IEEE
>>     802.1AE which allows for a single master key managed by some
>>     entity (out of scope of 1AE and addressed in 1X) but a heirarchy
>>     that allows for multiple senders.  Of course as with any
>>     multicast approach you loose source authenticity to some degree.
>>
> The switch talks to the energy controller to turn lights on/off (it 
> was explained to me how BAD 'toggle' is in this usage; I chuckled at 
> the image).  The switch instructs the lights all at once.  So there is 
> a single direction of multicast, from the controller to all lights in 
> the multicast group.  This is an 'easy' keying problem.  There is an 
> admin process that defines the group, and in so doing results in the 
> group key distribution:  "These and these lights are for the shop 
> floor and these are the lobby."
>
> IF these apps use IP multicast (even broadcast), THEN we SHOULD 
> provide IP security.
>
>
>

---

From: Don Sturek <[email-masked]>
Date: Wed, 03 Aug 2011 12:34:40 -0700

Hi Robert,

I did several projects with leading lighting manufacturers and, for those
projects which targeted residential and light commercial, there was no
centralized lighting controller.   The switches were provisioned to directly
switch on/off the groups of lights.

Don

From:  Robert Moskowitz <[email-masked]>
Date:  Wed, 03 Aug 2011 15:24:43 -0400
To:  Don Sturek <[email-masked]>
Cc:  Kerry Lynn <[email-masked]>, <[email-masked]>
Subject:  Re: [core] Spoofing in CoAP

 But do the switches directly communicate to the lights?  Not through an
energy controller?  I can see a very high failure rate due to RF where some
lights get the signal from a switch and others do not.  Or are we counting
on multiple IP relays to get to all the lights so the RF reachablity is
mitigated?  I suppose so.  It seems so chaotic to do this without a
controller.  How do you define a lighting group?
 
 Even with multiple switches (hey, my Dad is an electrician and I
apprenticed under him and did 3-way and 4-way switch wirings), you want some
intelligence in their control of the lights.
 
 Thinking about this further and wanting to 'simplify' the risk boundaries,
I can see a controller defining the environment but then allowing direct
communication in case the controller has been taken down.
 
 Rapping this up, if you go with a controller model, the security is a
'simple' single sender.  If you go with the more open direct model, wait for
us to work out the multisender model.

>>>>> using the unicast security to transmit the multicast keys.  This could be
>>>>> a simplier implementation than adding a multicast key distribution
> of multicast, from the controller to all lights in the multicast group.  This
> is an 'easy' keying problem.  There is an admin process that defines the
> group, and in so doing results in the group key distribution:  "These and
> these lights are for the shop floor and these are the lobby."
>

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 3 Aug 2011 21:40:50 +0200

On Aug 3, 2011, at 9:34 PM, Don Sturek wrote:
> I did several projects with leading lighting manufacturers and, for those projects which targeted residential and light commercial, there was no centralized lighting controller.   The switches were provisioned to directly switch on/off the groups of lights.

In the scenario you are proposing there may be one only SA, selected by SPI and the lamps+switches multicast address.  

Formally it fits a many-to-many model, but all the (homomorphic) senders can be actually seen as one only entity.

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 3 Aug 2011 21:51:04 +0200

> important multicast is (or is not) to CoAP...

I'm implementing the humans/things bridging technology, so I'm interested in knowing if secure multicast is in the spec only from an "opportunistic" point of view.  

That said, I believe secure multicast is a basic building block for a number of very basic stuff: from efficient firmware update on a number of same sensors, to instructing coordinated actuators, plus resource discovery, etc.

So, for me it's a +1 both in this spec round or in the next -- but my vote may count less than one here, since I'm half a stakeholder WRT this specific requisite.

PS: I'm quite struck that no one (but Bob) has commented about the extremely easy spoofing issue I've posed at the beginning of this same thread.  Do you all think it is so much unlikely ?  It'd be interesting bringing in some "spoofer" box next CoRE plug fest :-)

---

From: Robert Cragie <[email-masked]>
Date: Wed, 3 Aug 2011 20:54:52 +0100

That's essentially how it needs to work in the sort of networks CoAP is
targeted at. The multicast group addressing needs to be associated with
group keying so 'zones' can be set up; the pairing of group addressing and
group keying can act as a convenient way of being a zone member or not. It
could also help with multicast echo suppression, although this can be
difficult to configure unless the network is completely static. There can be
no assumption of a central controller and it makes more sense to think of
the multi-link subnet model.

Robert

On Wed, Aug 3, 2011 at 8:40 PM, Thomas Fossati <[email-masked]> wrote:

> In the scenario you are proposing there may be one only SA, selected by SPI
> and the lamps+switches multicast address.
>

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 03 Aug 2011 15:58:38 -0400

On 08/03/2011 03:34 PM, Don Sturek wrote:
> Hi Robert,
>
> I did several projects with leading lighting manufacturers and, for 
> those projects which targeted residential and light commercial, there 
> was no centralized lighting controller.   The switches were 
> provisioned to directly switch on/off the groups of lights.

I can't see this as anything but madness and chaos. Too much 
decentralized smarts to group switches and lights.

Switches need to be dumb/cheap (unless they are multiple switches of 
bunches of buttons for bunches of actions).  "I turn on.  I turn off."  
Lights need to be dumb (I am on/off and tell me what to do, on/off).  
The cost in the controller with a UI to define groups of switches and 
groups of lights.

I know we want Grandma to be able to set this up (she is more with it 
than Grandpa who is too busy fishing to care about the lights).  But 
then Grandmas tend to be as computer savy as their Granddaughters (and 
more than their daughters)  :)

Wait...

Ah, 'Provisioned'.

So there was a provisioning system.  That controller I postulated that 
set up the group then stepped aside?  I have seen something like this in 
big convention halls (like in Vegas).  I  CAN define a group keying 
environment similar to 802.1AE.  But I don't know if there is the energy 
to write if up formally and get it through the process.

> To: Don Sturek <[email-masked] <mailto:[email-masked]>>
> Cc: Kerry Lynn <[email-masked] <mailto:[email-masked]>>, 
> <[email-masked] <mailto:[email-masked]>>
> But do the switches directly communicate to the lights?  Not through 
> an energy controller?  I can see a very high failure rate due to RF 
> where some lights get the signal from a switch and others do not.  Or 
> are we counting on multiple IP relays to get to all the lights so the 
> RF reachablity is mitigated?  I suppose so.  It seems so chaotic to do 
> this without a controller.  How do you define a lighting group?
>
> apprenticed under him and did 3-way and 4-way switch wirings), you 
> want some intelligence in their control of the lights.
>
> 'simple' single sender.  If you go with the more open direct model, 
> wait for us to work out the multisender model.
>
>>
>>
>>
>>>     I have been thinking about this for the 802.15.4f situation
>>>     where the sensor has a receive radio that can be used at join
>>>     time for key distribution.  Otherwise a large 4f PAN would be
>>>     totally unsecurable (key scaling problems).
>>>
>> the image).  The switch instructs the lights all at once.  So there 
>> is a single direction of multicast, from the controller to all lights 
>> in the multicast group.  This is an 'easy' keying problem.  There is 
>> an admin process that defines the group, and in so doing results in 
>> the group key distribution:  "These and these lights are for the shop

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 03 Aug 2011 16:00:40 -0400

> Formally it fits a many-to-many model, but all the (homomorphic) senders can be actually seen as one only entity.

There are key heirarchy challenges here.  Your IV space MUST be 
segmented somehow or you are up against some simple attacks.

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 03 Aug 2011 16:02:16 -0400

On 08/03/2011 03:51 PM, Thomas Fossati wrote:
> PS: I'm quite struck that no one (but Bob)

I jumped in pretty fast for many to give me a +1 vote on the layering 
challenges.

>   has commented about the extremely easy spoofing issue I've posed at the beginning of this same thread.  Do you all think it is so much unlikely ?  It'd be interesting bringing in some "spoofer" box next CoRE plug fest :-)

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 3 Aug 2011 16:04:25 -0400

On Wed, Aug 3, 2011 at 2:40 PM, Zach Shelby <[email-masked]> wrote:

> Secure multicast is not urgent enough for us to solve as part of the
> current charter IMO, however I do think it is interesting upcoming work for
> CoRE, or in cooperation with the security area. Something to keep in mind
> for rechartering.
>
> Let's remember that the beginning of this thread essentially posed the
question
of whether IPSec or DTLS should be the "must implement" solution.  That
issue
can probably be explored without rechartering.

-K-

Zach

---

From: Don Sturek <[email-masked]>
Date: Wed, 03 Aug 2011 13:04:17 -0700

Provisioned in such a system means:

           Button press on the device, button press on the remote control,
etcŠŠ

There does not need to be a sophisticated tool to do provisioning on lights
and switches.

Don

Date:  Wed, 03 Aug 2011 15:58:38 -0400

> switch on/off the groups of lights.
 
 I can't see this as anything but madness and chaos. Too much decentralized
smarts to group switches and lights.
 
 Switches need to be dumb/cheap (unless they are multiple switches of
bunches of buttons for bunches of actions).  "I turn on.  I turn off."
Lights need to be dumb (I am on/off and tell me what to do, on/off).  The
cost in the controller with a UI to define groups of switches and groups of
lights.
 
 I know we want Grandma to be able to set this up (she is more with it than
Grandpa who is too busy fishing to care about the lights).  But then
Grandmas tend to be as computer savy as their Granddaughters (and more than
their daughters)  :)

 Wait...
 
 Ah, 'Provisioned'.
 
 So there was a provisioning system.  That controller I postulated that set
up the group then stepped aside?  I have seen something like this in big
convention halls (like in Vegas).  I  CAN define a group keying environment
similar to 802.1AE.  But I don't know if there is the energy to write if up
formally and get it through the process.

> lights get the signal from a switch and others do not.  Or are we counting on
> multiple IP relays to get to all the lights so the RF reachablity is
>  Even with multiple switches (hey, my Dad is an electrician and I apprenticed
> under him and did 3-way and 4-way switch wirings), you want some intelligence
> in their control of the lights.
>  
>  Thinking about this further and wanting to 'simplify' the risk boundaries, I
> can see a controller defining the environment but then allowing direct
>>>> heirarchy that allows for multiple senders.  Of course as with any

-- 
  Standard Robert Moskowitz
  Senior Technical Advisor
  Security & Standards
  Verizon Business Systems
 C:      248-219-2059
  F:      248-968-2824
  E:      [email-masked]
 
  There's no limit to what can be accomplished if it doesn't matter who gets
the credit

---

From: Robert Cragie <[email-masked]>
Date: Wed, 3 Aug 2011 21:29:56 +0100

I +1'ed you, Bob. Unfettered access to any sort of network at L3 can cause
havoc in many areas, not just unreliable UDP. There is only so much
mitigation you can do there (e.g. SYN cookies, etc.). If these are
multi-link subnet/NBMA type of arrangement there will be control plane
issues to think about as well.

My preference is for L2 hop-by-hop security with (a) key(s) given out
through secure subnet access (e.g. EAPOL/PANA etc.). This puts a wall around
the subnet which makes the unfettered access that much harder.

Robert

On Wed, Aug 3, 2011 at 9:02 PM, Robert Moskowitz
<[email-masked]>wrote:

> **
> [email-masked]://www.ietf.org/mailman/listinfo/core
>
>
> --
> Robert Moskowitz
>  Senior Technical Advisor
>  Security & Standards
>  Verizon Business Systems
> C:**      **248-219-2059
>  F:**      **248-968-2824
>  E:**      [email-masked]
>

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 03 Aug 2011 16:38:27 -0400

On 08/03/2011 03:54 PM, Robert Cragie wrote:
> That's essentially how it needs to work in the sort of networks CoAP 
> is targeted at. The multicast group addressing needs to be associated 
> with group keying so 'zones' can be set up; the pairing of group 
> addressing and group keying can act as a convenient way of being a 
> zone member or not. It could also help with multicast echo 
> suppression, although this can be difficult to configure unless the 
> network is completely static. There can be no assumption of a central 
> controller and it makes more sense to think of the multi-link subnet 
> model.

AES-CCM (what is in your chipsets) is very intolerant of multiple 
packets with the same key and IV.  So you must segment the IV space by 
sender.  This is not naturally part of ESP of DTLS.  For ESP you either 
go with a separate SA for each sender (which IS the natural model for 
unicast ESP) or a segmented seq # (and with only 64 bits with 32 implied 
this can be a problem with lots of senders).  Probably be better to have 
a managed SA space and segment that by sender.

All the 'smarts' go into managing that segmentation and the keys.

>
> Robert
>
> On Wed, Aug 3, 2011 at 8:40 PM, Thomas Fossati <[email-masked] 
>     > I did several projects with leading lighting manufacturers and,
>     for those projects which targeted residential and light
>     commercial, there was no centralized lighting controller.   The
>     switches were provisioned to directly switch on/off the groups of
>     lights.
>
>     In the scenario you are proposing there may be one only SA,
>     selected by SPI and the lamps+switches multicast address.
>
>     Formally it fits a many-to-many model, but all the (homomorphic)
>     senders can be actually seen as one only entity.
>     [email-masked] <mailto:[email-masked]>

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 03 Aug 2011 16:52:42 -0400

On 08/03/2011 04:04 PM, Don Sturek wrote:
>            Button press on the device, button press on the remote 
> control, etc......
>
> There does not need to be a sophisticated tool to do provisioning on 
> lights and switches.

So do you press the buttons on all the lights and switches within a 
small time window?  Or if a switch connects to one light, that light 
instructs all the other lights?

Defining a group means that somewhere is a sense of the group.  Of 
course if all the group is a multicast address, the first system 
'claims' the address and each new device learns that address as it joins.

Drawing here on a napkin in front of my notebook....

Establish a unicast key between the new device and one establish 
device.  This can even be the 15.4 keying and the bootstraping of the 
group occurs just above the MAC.  Send the group key and 16 bit SA over 
this secure link.  The full 32 bit SA is this value plus the 16 bit 
short PAN address of the device (assumed unique thanks to 6lowpan).  If 
any device gets close to its 2^63 packets, it forces group rekeying.  Or 
get 'smarter' and further segment the SA to include a key number so have 
a hierarchy of sending keys.  Again, look at 802.1AE.

Then you work out things like when to rekey just because.

The only unicast keys in this case are the bootstrap keys and can even 
only be the MAC keys.  Assign a 6lowpan frame ID for handling this 
activity. (yeah toss it back to 6lowpan!)

But this is all drawing on a crumbled napkin left over from lunch.
> bunches of buttons for bunches of actions).  "I turn on.  I turn 
> off."  Lights need to be dumb (I am on/off and tell me what to do, 
> on/off).  The cost in the controller with a UI to define groups of 
> switches and groups of lights.
>
> set up the group then stepped aside?  I have seen something like this 
> in big convention halls (like in Vegas).  I  CAN define a group keying 
> environment similar to 802.1AE.  But I don't know if there is the 
> energy to write if up formally and get it through the process.
>
>>
>> Don
>>
>>
>>
>> RF reachablity is mitigated?  I suppose so.  It seems so chaotic to 
>> do this without a controller.  How do you define a lighting group?
>>
>>>>             security SAs, using the unicast security to transmit
>>>>             the multicast keys.  This could be a simplier
>>>>             implementation than adding a multicast key distribution
>>>>         group cardinality in a sensible way, thus not saturating
>>>>         the medium with control traffic.
>>>>
>>>>
>>>>     If multicast is REALLY important to CoAP, we probably do need
>>>>     to look at a deployable multicast security method.  I would
>>>>     entity (out of scope of 1AE and addressed in 1X) but a
>>>>     heirarchy that allows for multiple senders.  Of course as with
>>>>     any multicast approach you loose source authenticity to some
>>>>     degree.
>>>>
>>> is a single direction of multicast, from the controller to all 
>>> lights in the multicast group.  This is an 'easy' keying problem.  
>>> There is an admin process that defines the group, and in so doing 
>>> results in the group key distribution:  "These and these lights are 
>>> for the shop floor and these are the lobby."
>>>

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 03 Aug 2011 16:56:30 -0400

On 08/03/2011 04:29 PM, Robert Cragie wrote:
> I +1'ed you, Bob. Unfettered access to any sort of network at L3 can 
> cause havoc in many areas, not just unreliable UDP. There is only so 
> much mitigation you can do there (e.g. SYN cookies, etc.). If these 
> are multi-link subnet/NBMA type of arrangement there will be control 
> plane issues to think about as well.
>
> through secure subnet access (e.g. EAPOL/PANA etc.). This puts a wall 
> around the subnet which makes the unfettered access that much harder.

See my KMPIG over in 802.15.4.  I am providing for any KMP here; I 
prefer HIP or even IKEv2 and shudder at EAPOL/PANA especially 
considering this lighting discussion!

But I REQUIRE 15.4e to do this completely as a MAC function.  But once 
defined, 6lowpan could easily allocate a frame ID to carry it as part of 
6lowpan setup.

Join me at Okinawa and then Atlanta.

Oh I had slides for this for the saag session thrusday pm1.

>     I jumped in pretty fast for many to give me a +1 vote on the
>     layering challenges.
>
>     C: 248-219-2059 <tel:248-219-2059>
>     F: 248-968-2824 <tel:248-968-2824>
>     <mailto:[email-masked]>
>
>     There's no limit to what can be accomplished if it doesn't matter
>     who gets the credit
>

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 4 Aug 2011 01:09:51 +0200

On Aug 3, 2011, at 10:02 PM, Robert Moskowitz wrote:
> I jumped in pretty fast for many to give me a +1 vote on the layering challenges.

Perhaps I've worded my point in a misleading way.  So let me recap it.

What I am trying to say is that we have *very cheap* and clearly disruptive attacks spanning the whole CoAP spec (the base protocol, proxying, resource directories, etc.) which are all based on simple address spoofing.  Which means typically 50 lines of well indented C code that any of us could write -- I'm sure Jari could provide an assembly equivalent using less than 10 instructions :-)

Moreover, the "MUST implement" security protocol that the spec is proposing has 3 over 4 modes (basically all but the Certificate mode) that are in some way vulnerable to this kind of attacks. 

So, first of all, it'd be good if we had some text in the Security Consideration of core-coap that acknowledges this fact, in order that implementers/deployers are advised.

And secondly (also given the very interesting discussion about which layer / which crypto mechanism is better): are we sure that mandating DTLS instead of IPsec is a clever idea ?

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 03 Aug 2011 21:06:07 -0400

> And secondly (also given the very interesting discussion about which layer / which crypto mechanism is better): are we sure that mandating DTLS instead of IPsec is a clever idea ?

Those that know me know my bias to security where it belongs.  And to my 
work on MAC and IP layers more than TCP or session.  So no arguement 
from me.  Maybe why I jumped in so fast.

But I am aware of the challenges of API defining in IETF as well as the 
real issues found in developing the HIP API.  So how DO we add a 'good' 
API for security?  And over on the saag list, there has been a 
discussion just along these lines wrt tcpcrypt.  For example running 2 
browsers on a platform with different identities.

---

From: Robert Cragie <[email-masked]>
Date: Thu, 4 Aug 2011 06:17:52 +0100

+1

That's the way to do it - segment the nonce/IV space by sender. This is done
in 802.15.4

Robert

On Wed, Aug 3, 2011 at 9:38 PM, Robert Moskowitz
<[email-masked]>wrote:

> AES-CCM (what is in your chipsets) is very intolerant of multiple packets
> with the same key and IV.  So you must segment the IV space by sender.  This
> is not naturally part of ESP of DTLS.  For ESP you either go with a separate
> SA for each sender (which IS the natural model for unicast ESP) or a
> segmented seq # (and with only 64 bits with 32 implied this can be a problem
> with lots of senders).  Probably be better to have a managed SA space and
> segment that by sender.
>
>> those projects which targeted residential and light commercial, there was no
>>  In the scenario you are proposing there may be one only SA, selected by
>> SPI and the lamps+switches multicast address.
>>
> core mailing [email-masked]://www.ietf.org/mailman/listinfo/core
>
>
> --
> Robert Moskowitz
>  Senior Technical Advisor
>  Security & Standards
>  Verizon Business Systems
> C:**      **248-219-2059
>  F:**      **248-968-2824

---

From: Zach Shelby <[email-masked]>
Date: Thu, 4 Aug 2011 10:20:28 +0300

Hi Thomas,

Slow responses are likely caused from IETF recovery, at least in my case :-)

Thanks Thomas, this e-mail asks exactly the right questions.

> What I am trying to say is that we have *very cheap* and clearly disruptive attacks spanning the whole CoAP spec (the base protocol, proxying, resource directories, etc.) which are all based on sim…

Exactly, and I assume that a similar attack is possible on most other UDP based protocols? Do you happen to have any pointers how other IETF UDP based protocols have dealt with this issue? 

> Moreover, the "MUST implement" security protocol that the spec is proposing has 3 over 4 modes (basically all but the Certificate mode) that are in some way vulnerable to this kind of attacks. 

The WG found consensus in Quebec to make an update to the security specification. We are reducing our focus on pre-shared keys, and instead concentrating on the provisioning and efficient use of public keys. There is currently work going on to define the use of raw public keys and hashed identities with DTLS (this can also be used by IKEv2/IPSec) in addition to certificates. Thus we will end up with these modes:

1. NoSec
2. PreSharedKey - Reduced in importance, basically if you happen to have pre-shared keys you can use them, but be warned of the consequences (pointer to the attack that Thomas pointed out).
3. RawPublicKey - Currently being defined. Will include a pretty complete provisioning discussion.
4. Certificate - As now in the spec. 
  
> So, first of all, it'd be good if we had some text in the Security Consideration of core-coap that acknowledges this fact, in order that implementers/deployers are advised.

Yes, I 100% agree and will make a ticket to add a section with your contribution. Thanks!

> And secondly (also given the very interesting discussion about which layer / which crypto mechanism is better): are we sure that mandating DTLS instead of IPsec is a clever idea ?

Let's have that discussion again.

For a long time the CoAP specification described both DTLS and IPsec in a fairly balanced way, without requiring an implementer to do one or the other. However, we have been required to define a must implement mechanism for the specification, and the WG chose DTLS for that purpose. The reason is that DTLS is really the mechanism that an application layer developer can influence, and really the only one that makes sense to define as must implement in the CoAP specification.

We also have a section on IPsec, and we should also describe how the keying material (e.g. RawPublicKey) can be used with IPsec. But I don't see how in the world we could define IPsec as must implement in an application layer specification. How in the world does an application protocol implementor using an underlying IP protocol stack or OS force the implement of that? I definitely think we can recommend how IPsec should be used with CoAP when it is available and appropriate for the deployment scenario, but I don't see how we could require it as MTI in this specification. 

Zach

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 4 Aug 2011 10:58:03 +0300

> Secure multicast is not urgent enough for us to solve as part of the current charter IMO, however I do think it is interesting upcoming work for CoRE, or in cooperation with the security area. Some…
IMO multicast is important to CoAP, and we agree to work on it when we 
chartered this group

/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 4 Aug 2011 16:28:22 +0200

On Aug 4, 2011, at 9:20 AM, Zach Shelby wrote:
> Exactly, and I assume that a similar attack is possible on most other UDP based protocols?

Yes, in fact DNS people had to come up with DNSSEC to prevent cache poisoning.  

> Do you happen to have any pointers how other IETF UDP based protocols have dealt with this issue? 

Both NTP and SIP, just to mention a few going over UDP, have built-in authentication methods.

Perhaps we could add a 4.01 response code + "Authenticate" option to triggers a challange/response auth in CoAP ?

> 4. Certificate - As now in the spec. 

Good.  However, how are we supposed to handle raw public keys with DTLS ?  Shall we pack them into certificates on the fly ?  Or are they already supported with a format perhaps similar to PSK+identities ?
{{ This is a genuine question due to ignorance, I'm unaware of TLS support for raw pkeys :-) }}

> Yes, I 100% agree and will make a ticket to add a section with your contribution. Thanks!

Very good, thanks to you.

> We also have a section on IPsec, and we should also describe how the keying material (e.g. RawPublicKey) can be used with IPsec. But I don't see how in the world we could define IPsec as must imple…

If presented this way, I could argue that even DTLS is out of scope here.  An application protocol should define its own security mechanisms (e.g. like WWW-Authenticate in HTTP and/or SIP), and do not rely on other layers (be it 3 or 4.5) to provide its trust primitives.  Instead, bindings can in principle be defined with security protocols at any lower layer, if needed.

By the way, applications do have ways to tinker with the IPsec SADB (see RFC2367).

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 4 Aug 2011 18:00:27 +0200

On Aug 3, 2011, at 10:29 PM, Robert Cragie wrote:
> My preference is for L2 hop-by-hop security with (a) key(s) given out through secure subnet access (e.g. EAPOL/PANA etc.). This puts a wall around the subnet which makes the unfettered access that much harder.

L2 is ok to counteract on-path spoofing.  Instead an off-path spoofer can always use L3-provided routing to inject its garbage into the next-hop L2 subnet.  And a CoAP message can be really easy to guess, even for a blind attacker.

---

From: Zach Shelby <[email-masked]>
Date: Thu, 4 Aug 2011 15:43:33 +0300

On Aug 4, 2011, at 10:58 AM, Salvatore Loreto wrote:

> IMO multicast is important to CoAP, and we agree to work on it when we chartered this group

Multicast I agree, and we have ongoing work in the group communications draft, the building automation draft and basic CoAP support.

But *secure* multicast (and its key distribution) is a more difficult problem. I do think it is a good idea to include some more text in the CoAP spec on how IPsec could be used today for securing multicast using for example the multicast overlay using unicast SAs Thomas mentions above, and its limitations (if someone can contribute that text, that would be great). Assuming of course there is WG consensus on that. 

My knee-jerk reaction is that working on a *new* multicast security solution is pretty far beyond our current charter or even the App area, but something we should discuss in Taipei. 

Zach

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 04 Aug 2011 16:33:41 -0400

> around the subnet which makes the unfettered access that much harder.

Something I was totally glossing over in my thoughts yesterday 
crytalized last night while out walking.  To wit:  Multicasting at IP 
requires Broadcasting at MAC or why bother?  (much).

In my discussions over the past year in IEEE 802.15 I have been looking 
for decent broadcasting scenarios to work out challenges of group keying 
in a PAN.  No one I spoke to brought up this clear example we have been 
discussing here.  There must be some mechanism for IP to 'instruct' the 
MAC to send a datagram out as a broadcast.  As simple as the .15 MAC is 
we can't expect it to do data content inspection to figure this out.  I 
will ASSuME that 6lowpan has already addressed this.

We speak of multicast, but in v6-speak I might think that anycast would 
be used?  But basically the same issues.

So there needs to be a process for distributing a group key at join 
time, whether for MAC broadcasts or IP multicasts.  The MAC group key 
limits traffic to all members of the PAN.  Now there can be many 
enclaves within a PAN; in the home there could be the lighting, HVAC, 
and security for 3 such distinct enclaves.  Thus PAN membership is good 
but not necessarily sufficient.

This brings us back to looking at IP layered security.  Now I earlier 
said that you need layer 3 security to protect from layer 3 attacks.  
However, ESP does not protect the IP addresses.  They are 'malleable'; 
but then the idea is the SA provides the trust between the systems so 
there is little gained by the hacker in altering the addresses.  
Something to remember though.

Finally we need to discuss attacks against the keying in a multi-group 
transmission model where a counter-based AES mode is used (eg AES CCM).  
Basically you cannot reuse a counter with a key.  So the challenge comes 
in an encryptor to ALWAYS never do this.  What happens if the device 
looses state?  The easy example is power lose and reset of all 
operational values.  Somehow this device would need to reset the WHOLE 
group's master key or some other device would need to tell it were it 
left off with its counter or some similar mechinism.  This is a really 
challenging problem to fix, but fixed it must be.

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 5 Aug 2011 14:59:02 +0200

On Aug 4, 2011, at 10:33 PM, Robert Moskowitz wrote:
> This brings us back to looking at IP layered security.  Now I earlier said that you need layer 3 security to protect from layer 3 attacks.  However, ESP does not protect the IP addresses.  They are 'malleable'; but then the idea is the SA provides the trust between the systems so there is little gained by the hacker in altering the addresses.  Something to remember though.

Correct me if I'm wrong.  WRT the spoofing argument, the lesser ESP protection scope (compared to AH) means that spoofing a replayed CoAP response (by cut-and-paste'ing of a previous legitimate ESP+UDP+CoAP packet) will be caught only in case the anti-replay service is in place at the receiver.

If true, than we need to highlight that ESP needs to support the anti-replay service at least in "infrastructural" receivers such as RDs and proxies (where the spoofing threat has the worst impact).  These boxes should be typically enough "unconstrained" to implement the further state handling due to the receive window maintenance.

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 05 Aug 2011 09:24:58 -0400

> If true, than we need to highlight that ESP needs to support the anti-replay service at least in "infrastructural" receivers such as RDs and proxies (where the spoofing threat has the worst impact)…

Yes.  This is my view.  And tracking SA/sender/seq# for replay attack 
addresses how to inform a re-joinee where they left off to avoid seq# 
reuse attack.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 05 Aug 2011 23:58:43 +0900

I have one comment, please see below.

> 4. Certificate - As now in the spec.

If we use MultiKey, there is no spoofing issue because no PSK sharing
among different clients.

So I suggest to keep MultiKey option and just mention that
provisioning for MultiKey is out of scope.  Note that other forum such
as ETSI M2M does address provisioning for MultiKey.

Yoshihiro Ohba

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 5 Aug 2011 17:19:55 +0200

> If we use MultiKey, there is no spoofing issue because no PSK sharing

This is true for MultiKey with 1:1 key associations, but in circumstances with nodes/key ratio > 1 all the nodes sharing the same PSK can spoof any other node in the group.  So, in order to keep the MultiKey mode we should slightly change its semantics to strict 1:1 PSK per nodes' pair.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 06 Aug 2011 00:24:26 +0900

Off-path attackers will need to synch up with DTLS sequence number.
It is possible to mitigate spoofing attack from off-path attackers by
choosing a smaller size of DTLS sliding receive window.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 06 Aug 2011 00:25:45 +0900

(2011/08/06 0:19), Thomas Fossati wrote:
> This is true for MultiKey with 1:1 key associations, but in circumstances with nodes/key ratio>  1 all the nodes sharing the same PSK can spoof any other node in the group.  So, in order to keep the MultiKey mode we should slightly change its semantics to strict 1:1 PSK per nodes' pair.

Sure.

Yoshihiro Ohba

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 5 Aug 2011 17:57:57 +0200

> choosing a smaller size of DTLS sliding receive window.

A bit of ingress/egress filtering on router nodes could help too.

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 06 Aug 2011 10:42:12 +0300

On Fri, 5 Aug 2011 17:19:55 +0200, Thomas Fossati <[email-masked]>
wrote:
> This is true for MultiKey with 1:1 key associations, but in circumstances
> with nodes/key ratio > 1 all the nodes sharing the same PSK can spoof any
> other node in the group.  So, in order to keep the MultiKey mode we
should
> slightly change its semantics to strict 1:1 PSK per nodes' pair.

This is exactly what I had in mind. In the next version of the draft the
PreSharedKey mode would be strictly 1:1 key associations. In other words,
we drop the SharedKey mode all together.

Zach

---

From: Robert Cragie <[email-masked]>
Date: Mon, 08 Aug 2011 15:48:50 +0100

Indeed - it is unlikely a node would blindly route into a L2-protected 
subnet. So the off-path attack model is probably not as easy as it may seem.

Robert