Re: [cf-dev] Request/Response matching for DTLS-Secured exchange

[Simon Bernard <contact@xxxxxxxxxxxxxxx>]

I'm agree with the "strict mode", I think we could do that in a second time. Do you think there is a chance we will be able to change the spec ?

About exchangeBy*, I thought  to the same thing.

The complexity will be to get the security context from scandium to the Matcher class in an elegant way. The principle is not really needed, we need :
- the session ID + the epoch for strict mode.
- the session ID + the cipher suite for flexible mode.
I suppose we could add Security Contex at message level in a same way we add the principle but this is done only at request reception and we need it when we send a message too. (to fill the exchangeBy* maps).
Maybe we could had a getSecurityContext(InetSocketAddress) on Connector, we can call it to fill the exchangeBy* maps before we send a message ? But this solution seems to have a "transactional" issue. (I mean If an handshake is done between the "getSecurityContext" and the "Connector.send" :(

Le 10/09/2015 15:13, Kovatsch Matthias a écrit :

Hi Simon

 

Great! I agree with your assumptions and also would like to focus on a solution that supports matching based on the security context (i.e., it works even when the endpoint address changed). There should, however, be some kind of “strict mode” that people could activate…

 

For the implementation, I imagine a more flexible way for the exchangesBy* hashmap keys that uses a context provided by the messages: for CoAP it is the endpoint address, for CoAPS the security context.

 

Currently, only the Request provides a principle through getSenderIdentity(). Is it enough to have it there and then rely on secure matching? Or should there maybe be something similar for responses and more importantly for notifications?

 

Ciao

Matthias

 

 

From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On Behalf Of Simon Bernard
Sent: Donnerstag, 10. September 2015 14:42
To: Californium (Cf) developer discussions <cf-dev@xxxxxxxxxxx>
Subject: [cf-dev] Request/Response matching for DTLS-Secured exchange

 

Hi,
   I would like to implement the request/response matching on DTLS-Secured CoAP.
  
   If I well understand the code : Currently californium does not manage it at all. It only do the matching on peer address and token, As it was describe in the spec for non secured exchange :

5.3.2.  Request/Response Matching Rules
".... The source endpoint of the response MUST be the same as the destination endpoint of the original request. ...
... In a piggybacked response, the Message ID of the Confirmable request and the Acknowledgement MUST match, and the tokens of the response and original request MUST match.  In a separate response, just the tokens of the response and original request MUST match ..."

For DTLS-Secured exchange the spec say :
9.1.1.  Messaging Layer
"... The following rules are added for matching an Acknowledgement message or Reset message to a Confirmable message, or a Reset message to a Non-confirmable message: The DTLS session MUST be the same, and the epoch MUST be the same. ... "

9.1.2.  Request/Response Layer
"... 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. ..."

  I know there have been some discussions about the epoch constraint which could be too strict. And something like the "same session and the same cipher suite" could be acceptable. The "source/destination endpoint matching" constraints should not be needed too in secured exchange.
  Does it sounds good for you ?

Simon

_______________________________________________
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