[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Even less strict request response matching
|
I pretty agree with Kay most of the time identity is not enough,
especially if client is not authenticate. (About PSK I think this is not
allowed to have 2 clients with the same identity but not the same key)
But I can see some cases (LWM2M ?), where clients must always
authenticate themself and have only one way to established DTLS session
(only one cipher allowed). In this case using identity is maybe acceptable.
So, maybe instead of using configuration option, we should just create a
CorrelationContextMatcher Interface with a default implementation (the
strict mode) and let users implement its own.
Simon
Le 22/08/2016 à 16:25, Hudalla Kai (INST/ESY1) a écrit :
Hi Daniel,
On Mo, 2016-08-22 at 13:48 +0000, Maier Daniel (INST/ECS4) wrote:
Hi all,
in Californium there exists the option
"USE_STRICT_RESPONSE_MATCHING". Setting this to false, Californium
does not consider the DTLS epoch to match responses/notifies to
requests. This is not strictly conform to the specification. But I
understand why this is useful. What do you think about to go even one
step further: Some kind of “LAX_RESPONSE_MAPPING” that only checks
that the DTLS identity is the same as the DTSL identity the request
was sent to?
I assume you are referring to the authenticated identity of the DTLS
client, right? This could work if Scandium is configured to make client
authentication mandatory (this is optional for non PSK based cipher
suites). However, in PSK based scenarios the "identity" of a client is
simply an arbitrary string that might be shared by multiple (even
unrelated) clients either by coincidence or on purpose, i.e. a client
using the same identity as another client (but different key) could be
mistaken for the "other" client if there is no match based on the
session ID.
Does anyone know why these strict restrictions were made in the CoAP
specification? In LWM2M for example it is allowed to receive
registration updates and de-registrations after a new handshake, but
because of this CoAP restriction it is not possible to receive
notifications.
This “LAX_RESPONSE_MAPPING” would make it possible to receive
notifies when there was a new DTLS handshake.
See above for why I think this is problematic ...
Thanks
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
