Subject: [core] Doubts in draft-ietf-core-object-security

From: Raja ashok <[email-masked]>
Date: Thu, 13 Jul 2017 12:39:30 +0000

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!

---

From: Göran Selander <[email-masked]>
Date: Sat, 22 Jul 2017 06:42:50 +0000

Hi Ashok,

Thanks for your comments.

What amount of message data do you envision during the lifetime of the device? The same key can be used for a large number of messages (the number depending on the AEAD algorithm) and there is in principle no reason to change key before that. And after that you would probably want to anyway make a Diffie-Hellman key exchange since the entropy of the master secret is worn out.

In principle it is possible to have a new master salt seeded by (something random known to) client and server and derive a new session key, but for the reasons above we did not specify that. Another option is to use OSCOAP with some other key exchange protocol which supports key rollover.

Please let me know more about the use case if this doesn’t answer the question.

Thanks
Göran

From: Raja ashok <[email-masked]<mailto:[email-masked]>>
Date: Thursday 13 July 2017 at 14:39
To: Göran Selander <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Doubts in draft-ietf-core-object-security

Hi Goeran Selander,

Regards,
Ashok

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

---

From: Raja ashok <[email-masked]>
Date: Mon, 24 Jul 2017 08:29:08 +0000

Hi Göran,

Thanks for your clarifications.

I agree with your point, same session key can be used for large number of messages till the nonce of AEAD overflows. But as per my knowledge a same session key (16byte) should not be used for more than few days(5 to 10 days). Because it can be brute forced. So I am thinking like, we should consider of periodically deriving session keys from same master secret using different random numbers (master salt).

And also currently in OSCoAP, to handle reboot scenario, node should periodically updates (current sequence number + n) to persistent memory. I feel we can avoid this write on persistent memory, if we do random number exchange before deriving session keys. I mean, a rebooted client can initiate a request to derive new session key (need to consider DoS attack here). So we can store only master secret in persistent memory.

Please clarify me if my understanding is wrong.

Regards,
Ashok

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

From: Göran Selander [mailto:[email-masked]]
Sent: 22 July 2017 12:13
To: Raja ashok
Cc: [email-masked]; [email-masked]
Subject: Re: Doubts in draft-ietf-core-object-security

Hi Ashok,

Thanks
Göran

Hi Goeran Selander,

Regards,
Ashok

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

---

From: Jim Schaad <[email-masked]>
Date: Mon, 24 Jul 2017 15:51:59 +0200

From: core [mailto:[email-masked]] On Behalf Of Raja ashok
Sent: Monday, July 24, 2017 10:29 AM
To: Göran Selander <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [core] Doubts in draft-ietf-core-object-security

Hi Göran,

[JLS] If you have a method to do this then you would be doing something that I have no idea how to do.  Brute forcing a 128-bit key is currently thought to be a fairly lengthy exercise.  And simply bumping up to a 256-bit key would be a way to make that nearly impossible without breaking AES in it’s entirety.  

[JLS] I am not sure which I think would be more expensive. An occasional write to persistent memory (on the order of a couple of hundred messages sent) or at least one round trip of transmission costs.  However, if that is what you want to do then that is the purpose of the EDHOC draft.  This does have a feature that what you are asking for does not have, but would probably be the right answer.

Jim

Regards,

Ashok

  _____  

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com 

  _____  

From: Göran Selander [mailto:[email-masked]] 
Sent: 22 July 2017 12:13
To: Raja ashok
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: Doubts in draft-ietf-core-object-security

Hi Ashok,

Thanks

Göran

From: Raja ashok <[email-masked] <mailto:[email-masked]> >
Date: Thursday 13 July 2017 at 14:39
To: Göran Selander <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: Doubts in draft-ietf-core-object-security

Hi Goeran Selander,

Regards,

Ashok

  _____  

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com 

  _____

---

From: Raja ashok <[email-masked]>
Date: Tue, 25 Jul 2017 06:17:32 +0000

Hi Jim,

Please find my inlined comments.

Regards,
Ashok

From: Jim Schaad [mailto:[email-masked]]
Sent: 24 July 2017 19:22
To: Raja ashok; 'Göran Selander'
Cc: [email-masked]; [email-masked]
Subject: RE: [core] Doubts in draft-ietf-core-object-security

From: core [mailto:[email-masked]] On Behalf Of Raja ashok
Sent: Monday, July 24, 2017 10:29 AM
To: Göran Selander <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [core] Doubts in draft-ietf-core-object-security

Hi Göran,

[JLS] I am not sure which I think would be more expensive. An occasional write to persistent memory (on the order of a couple of hundred messages sent) or at least one round trip of transmission costs.  However, if that is what you want to do then that is the purpose of the EDHOC draft.  This does have a feature that what you are asking for does not have, but would probably be the right answer.
[Ashok] I feel there might be some case, where occasional write to persistent memory of sensor node is expensive than 1RTT cost. I understood that EDHOC (with PSK or X509) helps to derive new master secret, but ECDHE based key exchange is mandatory here. So that I thought of considering the case of deriving new session key (or master secret) with PSK and random nonce (without ECHDE).

Jim

Regards,
Ashok

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

From: Göran Selander [mailto:[email-masked]]
Sent: 22 July 2017 12:13
To: Raja ashok
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Doubts in draft-ietf-core-object-security

Hi Ashok,

Thanks
Göran

Hi Goeran Selander,

Regards,
Ashok

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com