Yes, that’s the spec. We first discussed it in the core WG in June 2015, after an extensive internal MSFT review. https://lists.allseenalliance.org/pipermail/allseen-core/2015-June/002041.html
The main goal was to have a replacement for SRP, suitable for the TC. Once you have SPEKE, PSK becomes redundant, and prone to misuse (e.g., https://lists.allseenalliance.org/pipermail/allseen-core/2015-April/001580.html). In terms of further review, of course it’s welcome. As I discuss on page 4 of the spec, the only place where AllJoyn’s SPEKE implementation deviates from IEEE 1363.2 is the key derivation function that gets used, and the inputs to it are not exactly the same. I decided this was acceptable since the key derivation function in AllJoyn (the same as the TLS 1.2 KDF) is expected to provide the same security as the KDF options in 1363.2, and the equivalent information is included in key derivation and confirmation (but encoded differently). Matching the standard exactly would require major changes to the AllJoyn authentication code. In terms of process, it did not occur to me to bring this for review to the SSC (nor to anyone else in the Core group). The SSC hasn’t historically reviewed security features or security changes in Core (never once, to my knowledge). But again, if there are resources there to provide feedback, that’s great. Greg PS – Brian, I’m still working on AllJoyn. From: Josh Spain [mailto:[email protected]] Sent: Thursday, February 25, 2016 6:23 PM To: Brian Witten <[email protected]> Cc: Greg Zaverucha <[email protected]>; Swinson, Ken <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [Allseen-core] [AllSeen Alliance TSC] Deprecation (and replacement) of ECDHE_PSK Hi Brian, I think this<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwiki.allseenalliance.org%2f_media%2fcore%2falljoyn-ec-speke-draft-2.pdf&data=01%7c01%7cgregz%40microsoft.com%7c36584d54d9264fad8e0208d33e53bdb4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=U4G%2bvuIMaFUtwjR1e%2bq2d5DdDBSLVsr4weGASCxgvsM%3d> may be what you're looking for. -Josh On Thu, Feb 25, 2016 at 8:11 PM, Brian Witten <[email protected]<mailto:[email protected]>> wrote: Hi Greg, Can you send the SPEKE proposal that was mentioned earlier? Sent from my iPhone On Feb 25, 2016, at 11:31 AM, Greg Zaverucha <[email protected]<mailto:[email protected]>> wrote: Josh: In a security 2.0 deployment, PSK is only used for onboarding/claiming. In a security 1.0 deployment apps could choose to use it however they want. Ken: deprecation will follow the regular AllJoyn deprecation process. Here’s my understanding of the timeline: PSK will be annotated as deprecated in 16.04. It will be supported for two releases, then still present but unsupported for another two. Greg From: Josh Spain [mailto:[email protected]] Sent: Thursday, February 25, 2016 11:22 AM To: Swinson, Ken <[email protected]<mailto:[email protected]>> Cc: Lioy, Marcello <[email protected]<mailto:[email protected]>>; Greg Zaverucha <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [Allseen-core] [AllSeen Alliance TSC] Deprecation (and replacement) of ECDHE_PSK Greg, Can you describe the scenarios other than during onboarding in which ECDHE_PSK is currently or would potentially be used in AllJoyn? Thanks, Josh On Thu, Feb 25, 2016 at 8:59 AM, Swinson, Ken <[email protected]<mailto:[email protected]>> wrote: We discussed the planned deprecation of ECDHE_PSK on an HAE working group call this AM. A concern was raised regarding how quickly ECDHE_PSK will be deprecated. I recall from the core working group calls that there is a desire to deprecate this feature quickly once this new authentication method is added. The concern raised by HAE group is that they are launching their service frameworks on core 15.09 and will be using ECDHE_PSK for authentication. They need to plan a transition to the new method while supporting released products using ECDHE_PSK. I looked for and did not find a jira ticket tracking the deprecation of ECDHE_PSK. Is there one? From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Lioy, Marcello Sent: Thursday, December 10, 2015 2:58 PM To: Greg Zaverucha; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [AllSeen Alliance TSC] Deprecation (and replacement) of ECDHE_PSK As there has been no responses to this the Working Group decided in the call today to in fact deprecate this authentication mechanism. Thanks to Greg for driving the proves and volunteering to do the work. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Greg Zaverucha Sent: Thursday, December 03, 2015 2:23 PM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [Allseen-core] Deprecation (and replacement) of ECDHE_PSK The core working group discussed today whether to mark ECDHE_PSK as deprecated in 16.04, and have a new mechanism called ECDHE_SPEKE replace it. Information about the new mechanism is here: https://jira.allseenalliance.org/browse/ASACORE-2055<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fjira.allseenalliance.org%2fbrowse%2fASACORE-2055&data=01%7c01%7cgregz%40microsoft.com%7c4597341a44b94ecf9a4808d33e18ee60%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=V5tz5nrBvluL4E7ylsu6EHXgViccaK4ZzpOWs%2bJBjW4%3d> . The main difference between SPEKE and PSK is that SPEKE is secure even when the pre-shared secret is a low-entropy password, while for PSK the peers must share a key with high entropy (ideally, 128 bits). The reasons for deprecation are - There is no use case that ECDHE_PSK addresses that ECDHE_SPEKE doesn’t. The primary use case for PSK in Security 2.0 is onboarding, and SPEKE is appropriate for this use case. - ECDHE_PSK is easy to misuse, if an app uses a short password instead of a high entropy key, security is lost. - Having two ways to do similar things causes confusion, complicates the code (and increases TC memory footprint) Consensus on the call was to go ahead with deprecation, this email is to give those that weren’t on the call a chance to weigh in. We’ll finalize the decision on the core WG call next Thursday (Dec. 10th). If you have concerns about this change, please voice them before then. Greg _______________________________________________ Allseen-core mailing list [email protected]<mailto:[email protected]> https://lists.allseenalliance.org/mailman/listinfo/allseen-core<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flists.allseenalliance.org%2fmailman%2flistinfo%2fallseen-core&data=01%7c01%7cgregz%40microsoft.com%7c4597341a44b94ecf9a4808d33e18ee60%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6B7x4aFJ6l0%2bCFbgN9CicPufGVQGJl2nyvlruSu6yRo%3d> _______________________________________________ Allseen-core mailing list [email protected]<mailto:[email protected]> https://lists.allseenalliance.org/mailman/listinfo/allseen-core<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flists.allseenalliance.org%2fmailman%2flistinfo%2fallseen-core&data=01%7c01%7cgregz%40microsoft.com%7c36584d54d9264fad8e0208d33e53bdb4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=i3mmCBO0WepI%2b3%2fIhs7xJ4Vnxovy%2b6w%2fRItGBRshx08%3d>
_______________________________________________ Allseen-core mailing list [email protected] https://lists.allseenalliance.org/mailman/listinfo/allseen-core
