[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Request/Response Layer with DTLS Usage on CoAP Server Side
|
I think you're right, Daniel. The example you give could happen in that way
running Californium.
Can you open an issue on GitHub?
On Mi, 2016-10-05 at 13:15 +0000, Maier Daniel (INST/ECS4) wrote:
> Hi all,
>
> Californium implements in UdpMatcher.receiveResponse() discard of responses
> that do not belong to the same DTLS session as the request on CoAP-Client side.
> This implements the requirement of CoAP specification:
>
> “The following rules are added for matching a response to a request: The DTLS
> session MUST be the same, and the epoch MUST be the same.”
>
> But there seems to be no such mechanism for this requirement on server side,
> i.e. a CoAP Server may send a response to a newly established DTLS session that
> comes from the same IP:Port as the request. I think to accomplish the RFC it is
> also mandatory to ensure that no response gets sent to a DTLS session that is
> not the same as the one of the request.
>
> Example:
> - There is a CoAP-Server using DTLS with server certificate but
> without required Client authentication.
> - There is a CoAP-Client client1 with an established DTLS session that
> observes a resources of this server.
> - A second CoAP-Client client2 initiates a DTLS session using the same
> IP:Port as client1, e.g. they are behind the same NAT and the NAT devices
> reuses port mappings after inactivity.
> - Now client2 receives notifies (responses) that were intended for
> client1. Client2 can decrypt theses notifies because the CoAP-Server encrypts
> them for the newly created DTLS session. These responses might leak sensitive
> information.
>
> What do you think? Is this a problem of Californium implementation or did I get
> something wrong here?
>
> Best Regards,
> Daniel
> _______________________________________________
> cf-dev mailing list
> cf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cf-dev
