[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Request/Response matching short term concern
|
That sounds good.
I think at long term we should be strict and add the remote address back
into KeyToken. For the 1.0.0 release, I'm ok if we just use the token.
As you said, this is not a secure use case anyway :).
Le 22/09/2015 16:22, Kovatsch Matthias a écrit :
I did not set a new date since there are still open issues and the review process will take another two weeks, once we have our RC ready. Since Leshan is the main client (of which I know) awaiting the release, but still has some "requests" for the release, I think we are fine.
Coming back to the tokens. Randomizing them is definitely on my list and we can include this for the 1.0.0 release. My way forward would be to actually remove the TokenLayer and put the generation into the Matcher. We can then create the tokens fully randomly and use the exchangesByToken map to check if a created token is currently in use.
I see since commit a3c178952b426da5afe9949d7922ab2cb10db9cb we only
use token when we do the request/response matching.
if the token value generation is not easily predictable, I think this is
acceptable at short term (we can even say this suits us) But it seems that is
not the case. Currently we create it randomly one time then we just
increment it each time we create a new request.
Using the exchangesByToken map also allows real per-endpoint tokens. Question is now, if we should be strict and add the remote address back into KeyToken or leave it to allow for changing IP addresses during observe (when using CoAP without DTLS). It is somewhat a security issue, but it actually starts with not using DTLS...
What do you think?
Ciao
Matthias
_______________________________________________
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
