Subject: [core] CoAP observation in NATed environment using DTLS

From: Simon Bernard <[email-masked]>
Date: Thu, 3 Nov 2016 19:03:43 +0100

Hi list,

I have attended meeting of the T2T RG in Ludwigsburg, there is a 
discussion around CoAP observation in NATed environment using DTLS (1.2).

I would like to share my thought here about that:

     The problem :
Currently the CoAP spec say :
"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."
Currently, in TLS, a connection is identified by its IP/Port address.
So when your IP address changed because of the NAT expiration, you must 
create a new TLS connection and so create a new CoAP observation relation.

     Behind this practical problem, I understand there is 2 separated 
issue :
1) Define a long term identifier for CoAP instead of limited CoAP 
interaction to the same DTLS connection. At CoAP level users would like 
to know from which or to which they send data.
2) Be able to use DTLS with dynamic IP address (e.g. NAT) without the 
need to redo full handshake or resume handshake.

     Possible Solutions ?
1) Using the DTLS identity (PSK identity for PSK, public key for RPK, CN 
for certificate, ...) and only if there is no authentication the DTLS 
Session as constraint for CoAP exchange. (we remove the same epoch/same 
connection constraint)
2) Using the "connectionId" extension proposed in the 
draft-fossati-tls-iot-optimizations-00.

Does it make sense  ?

Simon

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Nov 2016 18:58:57 +0000

Just on one snippet (and sorry, I've not fully followed the
recent threads on this) but...

On 03/11/16 18:03, Simon Bernard wrote:
> Define a long term identifier for CoAP

That's not an "issue," that's a design. And a potentially
very privacy unfriendly one too.

A sequence of identifiers that can be correlated by the
intended parties but nobody else is another solution.

There are probably more too.

Cheers,
S.

---

From: Lauri Piikivi <[email-masked]>
Date: Fri, 4 Nov 2016 08:20:21 +0000

Hi,

I have battled with these issue a while. I think there are 2 very separate issues: COAP identity and DTLS connection ID, neither of which is only an observation issue

= COAP identity =
> 1) Define a long term identifier for CoAP instead of limited CoAP interaction to the same DTLS connection. At CoAP level users would like to know from which or to which they send data.

With the strong focus on security, COAP starts with  the DTLS certificate or raw public key  information
“9.1.3.3.  X.509 Certificates
The discovery process used in the system
   would build up the mapping between IP addresses of the given devices
   and the subject for each device.”

COAP is based on URLs. And the URL must have a host part. Host can be IP address (with problems when IP changes) or a DNS name (that needs to be mapped and maintained in DNS registry) or some other long term identifier like certificate subject name.
“   6.1.  coap URI Scheme
   If host is a registered name, then that name is considered an indirect identifier
   and the endpoint might use a name resolution service, such as DNS, to
   find the address of that host.  The host MUST NOT be empty”

So there is mechanisms to define a long lasting name or identifier for the host and the resources it publishes.

I would suggest for the observation problem that the responses have the URI-Host option with the long lasting identifier of the device? The spec needs changing so that the DTLS session can change. If the DTLS session changes, but is accepted on DTLS layer, the application layer gets the new information that it maps using  it’s own mechanism of URI-host. Additional checking can be done that the host id matches the certificate subject for example. Newest IP and port is then known

Having the URI-host in responses supports the nosec mode, which is still mandatory in 7252.

This is a minor issue for the draft https://tools.ietf.org/html/draft-ietf-core-resource-directory-09. For registry (publishing COAP URLs) there might be need to define more structure to the host part, is it a DNS resolvable name or is a mapping that is understood in the registry itself? How is a client of the registry to know? Should there be a service that maps the non-DNS identity to IP?

= (D)TLS Connection ID =
> 2) Be able to use DTLS with dynamic IP address (e.g. NAT) without the need to redo full handshake or resume handshake.

This is not tied to observation, any long lasting session where there is very little data sent will fail due to NAT in the path. I think the problem is most in DTLS, since there the NAT's ip/port mapping timeout is more aggressive and the devices usually communicate only  seldomly. It is almost guaranteed that the DTLS connection will not stay alive in NAT.  RFC5382 for TCP talks of 2-hours, and RFC4787 for UDP NAT behaviour talks of 4-minutes

So to map the sent DTLS records at receiver, even if a NAT mapping changes along the way, the record would need the connection ID so that the servers find the correct DTLS context for the record. Now the spec says the context is found with ip/port information.

I understand the privacy concerns for IoP (internet of people), but could there be something easy for IoT — if privacy is not an issue? Mechanism that allows t meet both concerns.

BR
- Lauri

> On 03 Nov 2016, at 20:03, Simon Bernard <[email-masked]> wrote:
>
> Hi list,
>
> I have attended meeting of the T2T RG in Ludwigsburg, there is a discussion around CoAP observation in NATed environment using DTLS (1.2).
>
> "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."
> So when your IP address changed because of the NAT expiration, you must create a new TLS connection and so create a new CoAP observation relation.
>
>    Behind this practical problem, I understand there is 2 separated issue :
> 1) Define a long term identifier for CoAP instead of limited CoAP interaction to the same DTLS connection. At CoAP level users would like to know from which or to which they send data.
> 2) Be able to use DTLS with dynamic IP address (e.g. NAT) without the need to redo full handshake or resume handshake.
>
>    Possible Solutions ?
> 1) Using the DTLS identity (PSK identity for PSK, public key for RPK, CN for certificate, ...) and only if there is no authentication the DTLS Session as constraint for CoAP exchange. (we remove the same epoch/same connection constraint)
> 2) Using the "connectionId" extension proposed in the draft-fossati-tls-iot-optimizations-00.
>
> Does it make sense  ?
>
> Simon
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Simon Bernard <[email-masked]>
Date: Fri, 4 Nov 2016 11:00:52 +0100

I'm not sure to understand.
Please can you explain why the current constraint about same 
connection/same epoch is better in term of privacy than using DTLS identity.

---

From: Simon Bernard <[email-masked]>
Date: Fri, 4 Nov 2016 11:45:28 +0100

You're right both issue is not directly linked to observation.

1)About using host option, How does it works for DTLS session without 
authentication? I still prefer just adding the constraint "same DTLS 
identity or same session is there is no DTLS authentication" and let 
more flexibility to application on top of CoAP to handle this 
information. Each part of the stack have its own responsibility:
- DTLS provides authentication + encryption.
- CoAP ensure that request/response exchange are done for the same 
Identity. (when there is no authentication we just warranty exchange is 
done in the same session, this is the best we can do)
- Application layer authorize request based on this identity.

2) it's seems we head for a consensus about connectionID 
(draft-fossati-tls-iot-optimizations-00). The privacy concern could be 
handle by hash chain but would not be mandatory.
(https://mailarchive.ietf.org/arch/msg/core/a_cZN9nTkHoeETLXhBJAQWfYlp4)

---

From: Lauri Piikivi <[email-masked]>
Date: Tue, 8 Nov 2016 09:26:04 +0000

Hi,

In the approach you describe “same DTLS identity or same session” I see the problem that this ends at the front end server (of a web service) or at a proxy. Modern web services are distributed, and I think we would need a way to add device identity information to coap messages propagating deeper in a system. So even when DTLS is sued to verify the endpoint, we need mechanism to carry that information in the message itself.

I am sure you know JWT (https://tools.ietf.org/html/rfc7519) which is in good use at front ends, to add trusted authentication and authorisation tokens to the HTTP requests. It is used for front end server tokens that end servers can verify and trust, and also used for client authentication by giving it in the user authentication and adding to all subsequent method calls to a service. Should we define something similar?

Host for unauthenticated DTLS (or no sec) is sufficient to me, in addition to a good token, as described in the coap spec. If the risk analysis is such that this is acceptable in that system. But as stated above, I think might need a better option as well.

- Lauri

> On 04 Nov 2016, at 12:45, Simon Bernard <[email-masked]> wrote:
>
> 1)About using host option, How does it works for DTLS session without authentication? I still prefer just adding the constraint "same DTLS identity or same session is there is no DTLS authentication" and let more flexibility to application on top of CoAP to handle this information. Each part of the stack have its own responsibility:
> - CoAP ensure that request/response exchange are done for the same Identity. (when there is no authentication we just warranty exchange is done in the same session, this is the best we can do)
> 2) it's seems we head for a consensus about connectionID (draft-fossati-tls-iot-optimizations-00). The privacy concern could be handle by hash chain but would not be mandatory.

---

From: Simon Bernard <[email-masked]>
Date: Tue, 8 Nov 2016 11:23:46 +0100

Maybe we don't target exactly the same thing.

Currently there is this constraint for Observation:
"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."[1]
and more generally for all request/response :
"This means the response to a DTLS secured request MUST always be DTLS 
secured using the same security session and epoch."[2]

I just want to relax it to be able to make it works on unstable IP 
address use-cases (like NAT environment). As I said before I let 
authorization to the application layer.

If we relax this constraint, I suppose we will be able to add this kind 
of authorization token at application layer level.

[1]https://tools.ietf.org/html/rfc7641#section-7
[2]https://tools.ietf.org/html/rfc7252#section-9.1.2

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 8 Nov 2016 13:01:09 +0100

> Hi,
[...]
>
> I am sure you know JWT (https://tools.ietf.org/html/rfc7519) which is
> in good use at front ends, to add trusted authentication and
> authorisation tokens to the HTTP requests. It is used for front end
> server tokens that end servers can verify and trust, and also used
> for client authentication by giving it in the user authentication and
> adding to all subsequent method calls to a service. Should we define
> something similar?
>
[...]

Note that there is some ongoing work on adapting OAuth and JWT for use 
with CoAP in the ACE WG.

For example check out CWT 
(https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token) and the 
OAuth framework for CoRE 
(https://tools.ietf.org/html/draft-ietf-ace-oauth-authz)

/Ludwig

-- 
Ludwig Seitz, PhD   SICS Swedish ICT AB
Ideon Science Park, Building Beta 2
Scheelevägen 17, SE-223 70 Lund
Phone +46(0)70-349 92 51

The RISE institutes SP, Swedish ICT and Innventia are merging in order
to create a unified institute sector and become a stronger innovation
partner for businesses and society. At the end of the year we will
change our name to RISE. Read more at www.ri.se/en/about-rise