Raja ashok
2017-07-13 12:39:30 UTC
Hi Goeran Selander,
I have gone through the OSCOAP and EDHOC drafts. And I am having few doubts in it. Please provide your comments on it.
This specification makes handshake(EDHOC) for deriving master secret as optional. And also a constraint node can skip handshake and establish a secure channel if master secret is preconfigured.
This may make a constraint node to use same session keys (sender and receiver key) for longer duration, if sequence number is not exhausted. Only solution for renewing session key is to negotiate new master secret by using EDHOC. But EDHOC supports only PSK_ECDHE and ECDSA_ECDHE mechanism. Here I feel we are missing PSK without (EC)DHE mechanism for establishing secure channel. I mean we are missing TLS_PSK_WITH_AES_128_CCM_8 kind of mechanism.
In DTLS, TLS_PSK_WITH_AES_128_CCM_8 uses same PSK every time for deriving session keys, and it doesn¡¯t support PFS. But the session key derived is different every time with the help of client and server random.
So I feel we can consider of exchanging random number also along with KID and Partial IV in the 1st Request and Response. To achieve TLS_PSK_WITH_AES_128_CCM_8 kind of mechanism in OSCoAP without ECDHE exchange. For this anyway we have to consider multiple factors like replay attack, DoS attack (client initiating key derivation for each request), client reboot case etc.
Regards,
Ashok
________________________________
[Company_logo]
Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com
________________________________
±ŸÓÊŒþŒ°ÆäžœŒþº¬ÓлªÎª¹«ËŸµÄ±£ÃÜÐÅÏ¢£¬œöÏÞÓÚ·¢ËÍžøÉÏÃæµØÖ·ÖÐÁгöµÄžöÈË»òȺ×é¡£œû
Ö¹ÈκÎÆäËûÈËÒÔÈκÎÐÎʜʹÓãš°üÀšµ«²»ÏÞÓÚÈ«²¿»ò²¿·ÖµØй¶¡¢žŽÖÆ¡¢»òÉ¢·¢£©±ŸÓÊŒþÖÐ
µÄÐÅÏ¢¡£Èç¹ûÄúŽíÊÕÁ˱ŸÓÊŒþ£¬ÇëÄúÁ¢ŒŽµç»°»òÓÊŒþÍšÖª·¢ŒþÈ˲¢ÉŸ³ý±ŸÓÊŒþ£¡
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
I have gone through the OSCOAP and EDHOC drafts. And I am having few doubts in it. Please provide your comments on it.
This specification makes handshake(EDHOC) for deriving master secret as optional. And also a constraint node can skip handshake and establish a secure channel if master secret is preconfigured.
This may make a constraint node to use same session keys (sender and receiver key) for longer duration, if sequence number is not exhausted. Only solution for renewing session key is to negotiate new master secret by using EDHOC. But EDHOC supports only PSK_ECDHE and ECDSA_ECDHE mechanism. Here I feel we are missing PSK without (EC)DHE mechanism for establishing secure channel. I mean we are missing TLS_PSK_WITH_AES_128_CCM_8 kind of mechanism.
In DTLS, TLS_PSK_WITH_AES_128_CCM_8 uses same PSK every time for deriving session keys, and it doesn¡¯t support PFS. But the session key derived is different every time with the help of client and server random.
So I feel we can consider of exchanging random number also along with KID and Partial IV in the 1st Request and Response. To achieve TLS_PSK_WITH_AES_128_CCM_8 kind of mechanism in OSCoAP without ECDHE exchange. For this anyway we have to consider multiple factors like replay attack, DoS attack (client initiating key derivation for each request), client reboot case etc.
Regards,
Ashok
________________________________
[Company_logo]
Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com
________________________________
±ŸÓÊŒþŒ°ÆäžœŒþº¬ÓлªÎª¹«ËŸµÄ±£ÃÜÐÅÏ¢£¬œöÏÞÓÚ·¢ËÍžøÉÏÃæµØÖ·ÖÐÁгöµÄžöÈË»òȺ×é¡£œû
Ö¹ÈκÎÆäËûÈËÒÔÈκÎÐÎʜʹÓãš°üÀšµ«²»ÏÞÓÚÈ«²¿»ò²¿·ÖµØй¶¡¢žŽÖÆ¡¢»òÉ¢·¢£©±ŸÓÊŒþÖÐ
µÄÐÅÏ¢¡£Èç¹ûÄúŽíÊÕÁ˱ŸÓÊŒþ£¬ÇëÄúÁ¢ŒŽµç»°»òÓÊŒþÍšÖª·¢ŒþÈ˲¢ÉŸ³ý±ŸÓÊŒþ£¡
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!