Subject: [core] CoAP observe notification after DTLS session resume

From: Julien Vermillard <[email-masked]>
Date: Thu, 16 Jul 2015 09:10:40 +0000

Hi,
I have a use case involving observe using Lightweight M2M.

A device register on LWM2M server (using queue mode), the server will
trigger different observe requests. Then the device will go off the network
(cellular network in my case) for power management reason or will remain
silent for few seconds. When the device want to push a notify it needs to
reconnect to the network or the NAT reached timeout and it needs to resume
the DTLS session before sending the observe notification.

Actually it's impossible because in the observe spec we have this sentence:

"All notifications resulting from a GET request with an Observe Option MUST
be returned within the same epoch of the same connection as the request."

AFAIK a DTLS session resume change the epoch so we are stuck.
Resending GET for observe after every DTLS session resume is also not a
possibility because it cost a lot in data traffic and annihilate the
benefit of using observe versus dumb polling.

The issue was discussed here:
https://github.com/OpenMobileAlliance/OMA-LwM2M-Public-Review/issues/2

Today this limitation make CoAP & LWM2M observe unusable for our use-case.
I would like to avoid breaking our compatibility with the standard.

Can someone explain the security risk with having observe notifications
across different DTLS epoch?

Julien

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 16 Jul 2015 18:10:57 +0200

Hi Julien,

using the epoch seemed the most secure way to handle this.
I vaguely remember some attack around session resumption that we were
discussing, and we just chose the safe side.  By the way, that already
happened in RFC 7252 (see section 9.1), so -observe is simply echoing
this decision.

But your point is a good one.  Similar points have come up with TLS
(without a D, i.e., over TCP).

We should use the IETF meeting to grab some TLS experts and see how we
can go beyond a single epoch.  We'll probably need some form of intent
signaling here, as right now an unsuspecting implementation will do (and
expect others to do) what section 9.1 says.  Ideas welcome.

Grüße, Carsten

Julien Vermillard wrote:
> trigger different observe requests. Then the device will go off the
> network (cellular network in my case) for power management reason or
> will remain silent for few seconds. When the device want to push a
> notify it needs to reconnect to the network or the NAT reached timeout
> and it needs to resume the DTLS session before sending the observe
> notification.
> 
> "All notifications resulting from a GET request with an Observe Option
> MUST be returned within the same epoch of the same connection as the
> request."
> 
> Today this limitation make CoAP & LWM2M observe unusable for our
> use-case. I would like to avoid breaking our compatibility with the
> standard.
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Julien Vermillard <[email-masked]>
Date: Thu, 16 Jul 2015 18:48:15 +0000

Hi Carsten,
Thanks for the reply.

As far as I understand cross epoch attack, it's about exploiting different
sessions with different level of security. For example sending a answer on
a less secure session than the one used for sending the query. In our LWM2M
scenario we could only accept observe notification on a session with the
same level of security than the one which started the observation (anyway
in LWM2M we always have session authenticated both way). It's more complex
than just stating and implementing "do not cross epoch" but it would solve
our problem safely.

Also reading RFC 7252 again the way section 9.1.1 is phrased it doesn't
prevent sending the ack on the same epoch and then the answer correlated
with the token on another epoch. But that's probably a mistake?

Thanks
Julien

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 16 Jul 2015 21:11:07 +0200

> with the token on another epoch. But that's probably a mistake?

9.1.1 is about the message layer.
9.1.2 then has the equivalent limitation on the request/response layer.

Let's try to find a good definition for "same level of security"!

Grüße, Carsten

---

From: Julien Vermillard <[email-masked]>
Date: Sat, 18 Jul 2015 11:52:56 +0000

> 9.1.2 then has the equivalent limitation on the request/response layer.

Ok silly me :)

> Let's try to find a good definition for "same level of security"!
This would work for me:

replacing

"The DTLS session MUST be the same, and the epoch MUST be the same."

by

"The DTLS session MUST be the same, and the epoch or the ciphering strategy
MUST be the same (for example a resumed session)."

Julien