-
Notifications
You must be signed in to change notification settings - Fork 365
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing Request/Response Session Check with DTLS Usage on CoAP Server Side #104
Comments
I think that Californium (currently) is exposed to this problem. However, in the LWM2M use case it is usually the CoAP server (the device = LWM2M client) that is behind the NAT, whereas the CoAP client (the LWM2M server) will usually keep the same IP:port. |
I agree with you that this issue is not that critical for LWM2M use case. Only responses of Register, Udpate, deregister are affected. (Even if someone gets control over LWM2M Server IP, the attacker needs to know the PSKs of clients (in case of using PSKs), Server certificate etc. to initiate new DTLS Session to LWM2M clients) |
I think this is a general issue. A scandium user is not able to know who we send a message to. Main DTLS implementation does not face this issue because, end users manipulate DTLS session. In this case, you can control exactly what you do. With scandium and element connector, the choice was to abstract this session/connection concept. This information will be used to ensure we send applicationData to the expected destination. At CoAP level, we should add a way to do the same thing. And we should probably need to know the SenderIdentity for all message (not only for request). |
I agree with Simon that we would need to introduce more context to the API for sending out CoAP messages. IMHO we should use the |
Maybe principal should be added to the |
you seem to disagree with my previous comment where I raised my concern that we might not know the client's identity. |
I agree with you I think we need to support this case too. But I understand you want to use a correlation context on send for asserting destination identity. I thought that's what you proposed ^^? Am I wrong ? |
Really?
May be I'm wrong, but I see, we use that CorrelationContext to match a received response. |
I think you right. At element-connector level, we already have a CorrelationContext but we use it only for matching received response. Scandium connector should use it to check that we send message to the right peer. (through the right DTLS Connection) I like this idea to introduce a CorrelationStrategy. I'm wondering if we need to add Principal (DTLS identity) in correlation context ? At CoAP level we probably need to add a way to send API to a specific peer and so adding CorrelationContext to Message ? |
My idea was to do the easy part first: The second part may be more difficult: (And I have to confess, that mainly I want to see more what we miss to use coap+tcp then to really fix this issue. But though there is an overlapping ...) |
ok ^^ Let's go for the first part ! |
@sbernard31 , @boaks , anybody working on this already? Based on the opinion expressed by Simon on the mailing list, I guess we should add this issue to the 2.0.0 milestone, right? |
"Weeks" ago I had a early prototype of the "correlation context strategy" (locally) but I got aware, that this would be too much for on PR together with the introduction of a CorrelationContext for the TCP protocols. Therefore I split the introduction into #148 and I'm currently working on "finalize" that. With some changes in Leshan its quite usable (right now, using the demo certs, also with x509 security). |
I'm ok to add this for the 2.0.0 milestones :) |
Hey guys, what is the current state of this issue ? I would like to move this forward for UDP for the 2.0.0. I'm a bit confuse about tcp ? I thought that this should be moved in a more long term branch as Kai said : |
Your right, I stumbled more into TLS and Certificate issues. |
requests. Replaces the isResponseRelatedToRequest in the Matcher with CorrelationStrategy.match(). Intended to be extended with a followup PR for matching messages on sending to fix issue eclipse-californium#104. Signed-off-by: Achim Kraus <achim.kraus@bosch-si.com>
requests. Replaces the isResponseRelatedToRequest in the Matcher with CorrelationStrategy.match(). Intended to be extended with a followup PR for matching messages on sending to fix issue eclipse-californium#104. Signed-off-by: Achim Kraus <achim.kraus@bosch-si.com>
requests. Replaces the isResponseRelatedToRequest in the Matcher with CorrelationStrategy.match(). Intended to be extended with a followup PR for matching messages on sending to fix issue eclipse-californium#104. Signed-off-by: Achim Kraus <achim.kraus@bosch-si.com>
requests. Replaces the isResponseRelatedToRequest in the Matcher with CorrelationStrategy.match(). Intended to be extended with a followup PR for matching messages on sending to fix issue eclipse-californium#104. Signed-off-by: Achim Kraus <achim.kraus@bosch-si.com>
requests. Replaces the isResponseRelatedToRequest in the Matcher with CorrelationStrategy.match(). Intended to be extended with a followup PR for matching messages on sending to fix issue eclipse-californium#104. Signed-off-by: Achim Kraus <achim.kraus@bosch-si.com>
requests. Replaces the isResponseRelatedToRequest in the Matcher with CorrelationContextMatcher.isResponseRelatedToRequest(). Intended to be extended with a followup PR for matching messages on sending to fix issue eclipse-californium#104. Signed-off-by: Achim Kraus <achim.kraus@bosch-si.com>
requests. Replaces the isResponseRelatedToRequest in the Matcher with CorrelationContextMatcher.isResponseRelatedToRequest(). Intended to be extended with a followup PR for matching messages on sending to fix issue eclipse-californium#104. Signed-off-by: Achim Kraus <achim.kraus@bosch-si.com>
requests. Replaces the isResponseRelatedToRequest in the Matcher with CorrelationContextMatcher.isResponseRelatedToRequest(). Intended to be extended with a followup PR for matching messages on sending to fix issue #104. Signed-off-by: Achim Kraus <achim.kraus@bosch-si.com>
I think we can close this one. |
I had the plan to add some explicit tests about this, but I'm too busy with other stuff ;-(. |
Fixed with introduction of endpoint context and endpoint context matcher. |
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 is no such 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. 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 Use Case:
I tried this out with the given example. But this example is of course not comprehensive. I think this issue also exists when clients do client authentication as long as the client has e.g. a valid PSK.
The text was updated successfully, but these errors were encountered: