Re: [cf-dev] Request/Response Layer with DTLS Usage on CoAP Server Side

["Maier Daniel (INST/ECS4)" <Daniel.Maier@xxxxxxxxxxxx>]

Thanks for your feedback. I created the issue: https://github.com/eclipse/californium/issues/104


> -----Ursprüngliche Nachricht-----
> Von: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] Im
> Auftrag von Hudalla Kai (INST/ESY1)
> Gesendet: Donnerstag, 6. Oktober 2016 10:21
> An: cf-dev@xxxxxxxxxxx
> Betreff: 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
> _______________________________________________
> 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