wakaama
wakaama copied to clipboard
eclipse-wakaama
PSK key length limitation up to 16 bytes
According to latest OMA-TS-LightweightM2M-V1_0-20170208, when using PSK mode it is recommended to provision a 16 byte (128 bit) key or longer up to 64 bytes. Currently tinydtls library limits PSK key to 16 bytes (DTLS_KEY_LENGTH 16). I think that it is major issue since during bootstrap the bootstrap server may provisioning psk key up to 64bytes.
Yes. it also wakaama issue.
On 3 Apr 2017 3:14 p.m., "Julien Vermillard" [email protected] wrote:
this is a Tinydtls issue no?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/eclipse/wakaama/issues/264#issuecomment-291125527, or mute the thread https://github.com/notifications/unsubscribe-auth/AF2KtU8_1r3nAZXlOCVoS6tbnON6457oks5rsOKegaJpZM4MxNJv .
The intention of my answer in the mailing list
https://dev.eclipse.org/mhonarc/lists/wakaama-dev/msg00417.html
was to make you creating an related issue in tinyDTLS. Did you? Without the change there, I'm not sure what you expect to be done in wakaama.
Wakaama has no dependency on the security layer. Thus you can switch easily to the one present on your target platform.
Hi Boris,
The drawbacks of what?
- Apache 2.0 license?
- Changing the
exampleDTLS mapping implementation?
The license is in my personal opinion not compatible to the Eclipse License.
Changing the example DTLS mapping implementation must simple be done.
I don't know, which approach is faster, asking tinyDTLS to provide a longer PSK secret key or implement a new example mapping for DTLS. But, though my feeling is, that the most have there own opinion about longer secret keys (they simply don't pay off :-) ), it's up to you to act, either ask tinyDTLS or implement :-).
The license is in my personal opinion not compatible with the Eclipse License.
It's interesting because EPL and ASL are compatibles (can be mixed) from the official point of view of the foundation. Can you clarify your concern here?
It's interesting because EPL and ASL are compatibles (can be mixed) from the official point of view of the foundation. Can you clarify your concern here?
In my opinion, it could be used "as it is", but if you want "changes" (via a contribution), section 3. Grant of Patent License, may be, depending on your companies policy, an issue :-).
But let me ask: Do you have positive experience with that mbed tls DTLS implementation? Do you feel, that enlarging the length of the secret key offers important advantages?
Hi, I don't have previous experience with mbedtls but this library looks really documented. i found this project https://github.com/ARMmbed/mbed-client-mbed-tls which can be a good reference for go/no go
Does this issue be fixed or not, I also found this issue , the sever may provisioning (24 bytes)psk key during boostrap. And the registration got failed with the 24 bytes psk key.
