Subject: Re: [Cfrg] Future applications of PAKEs

From: "StJohns, Michael" <[email-masked]>
Date: Sun, 31 Jul 2016 13:19:27 -0400

I've been finding the following construct useful and secure:

1) use ecdhe to derive a one-time shared secret
2) prepend your password to the shared secret
3) use that concatenated value as the master key for your KDF function.

The derived keys will only match if both sides input the exact same
password value gang you the authentication piece.

Mike

On Friday, July 29, 2016, Robert Moskowitz <[email-masked]> wrote:

> I have an IoT vendor that has an ECDH KE embedded in their protocol.  They
> have asked me to enhance this with a password.  Actually I have TWO such
> vendors (different industries so no conflict of interest).  I cannot
> provide details of what they do beyond there is an ECDH KE.
>
> So I need to turn their ECDH KE into a PAKE.
>
> I recognize that this is not directly an IETF problem, but if I point to
> an IETF protocol, they will be more willing to adopt change.
>
> Choices, choices...
>
> I would like to have a draft that provides the differences between the
> various proposed PAKEs.
>
> On 07/24/2016 08:24 AM, Станислав Смышляев wrote:
>
> Good afternoon, dear colleagues!
>
> We've had a very fruitful discussion with Watson Ladd and have both
> understood that to continue a productive work on PAKEs in CFRG (not only on
> SESPAKE and SPAKE2 drafts) it will be better if all of us now decide which
> PAKEs applications to consider as primary ones for IETF.
>
> The concrete questions that depend on this decision are more specific than
> the ones considered in the requirements draft (which is quite ready to be
> followed now)‎ - they are about how the defined protocols are to be
> integrated. For instance, if we need a PAKE to be ready for integration in
> some IoT initialization protocol (as we discussed with Hannes Tschofenig)
> or to be used separately for specific needs as securing channel between a
> key container and a CSP (as it is used in my company), we have to define a
> wise key confirmation part and surroundings (like the way of obtaining Q_PW
> in SESPAKE draft or the final key K' in Watson's SPAKE2 draft). Otherwise,
> if we primarily think about TLS or IKE, for example, we don't need to
> define anything except the core key exchange mechanism now - and leave all
> other important questions like the countermeasures against online password
> guessing until the future work on a corresponding TLS(/IKE/SSH/etc)-related
> draft.
>
> Kindest regards,
> Stanislav Smyshlyaev
>
>
>
>
>
>
> _______________________________________________
> Cfrg mailing [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>https://www.irtf.org/mailman/listinfo/cfrg
>
>
>

---

From: Watson Ladd <[email-masked]>
Date: Sun, 31 Jul 2016 10:43:28 -0700

On Sun, Jul 31, 2016 at 10:19 AM, StJohns, Michael
<[email-masked]> wrote:
> The derived keys will only match if both sides input the exact same password
> value gang you the authentication piece.

This is not secure. I leave it as an exercise to the reader to break.

>> vendors (different industries so no conflict of interest).  I cannot provide
>> details of what they do beyond there is an ECDH KE.
>>
>> some IoT initialization protocol (as we discussed with Hannes Tschofenig) or
>> to be used separately for specific needs as securing channel between a key
>> container and a CSP (as it is used in my company), we have to define a wise
>> key confirmation part and surroundings (like the way of obtaining Q_PW in
>> SESPAKE draft or the final key K' in Watson's SPAKE2 draft). Otherwise, if
>> we primarily think about TLS or IKE, for example, we don't need to define
>> anything except the core key exchange mechanism now - and leave all other
>> important questions like the countermeasures against online password
>> Cfrg mailing list
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>>
>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Robert Moskowitz <[email-masked]>
Date: Sun, 31 Jul 2016 13:44:57 -0400

Mike,

Name it, and write it up as a PAKE draft!  Seriously!

If you want a co-author, I would work with you on it, as I have some 
thoughts on the input to the KDF...

On 07/31/2016 01:19 PM, StJohns, Michael wrote:
> On Friday, July 29, 2016, Robert Moskowitz <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I have an IoT vendor that has an ECDH KE embedded in their
>     protocol.  They have asked me to enhance this with a password. 
>     Actually I have TWO such vendors (different industries so no
>     conflict of interest).  I cannot provide details of what they do
>     beyond there is an ECDH KE.
>
>     I recognize that this is not directly an IETF problem, but if I
>     point to an IETF protocol, they will be more willing to adopt change.
>
>     Choices, choices...
>
>     I would like to have a draft that provides the differences between
>     the various proposed PAKEs.
>
>>     We've had a very fruitful discussion with Watson Ladd and have
>>     both understood that to continue a productive work on PAKEs in
>>     CFRG (not only on SESPAKE and SPAKE2 drafts) it will be better if
>>     all of us now decide which PAKEs applications to consider as
>>     primary ones for IETF.
>>
>>     The concrete questions that depend on this decision are more
>>     specific than the ones considered in the requirements draft
>>     (which is quite ready to be followed now)‎ - they are about how
>>     the defined protocols are to be integrated. For instance, if we
>>     need a PAKE to be ready for integration in some IoT
>>     initialization protocol (as we discussed with Hannes Tschofenig)
>>     or to be used separately for specific needs as securing channel
>>     between a key container and a CSP (as it is used in my
>>     company), we have to define a wise key confirmation part and
>>     surroundings (like the way of obtaining Q_PW in SESPAKE draft or
>>     the final key K' in Watson's SPAKE2 draft). Otherwise, if we
>>     primarily think about TLS or IKE, for example, we don't need to
>>     define anything except the core key exchange mechanism now - and
>>     leave all other important questions like the countermeasures
>>     against online password guessing until the future work on a
>>     corresponding TLS(/IKE/SSH/etc)-related draft.
>>
>>     Kindest regards,
>>     Stanislav Smyshlyaev
>>
>>
>>
>>
>>
>>
>>     [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Robert Moskowitz <[email-masked]>
Date: Sun, 31 Jul 2016 13:45:46 -0400

> This is not secure. I leave it as an exercise to the reader to break.

Sigh.  Thought it was too easy...

---

From: "StJohns, Michael" <[email-masked]>
Date: Sun, 31 Jul 2016 13:48:43 -0400

Go for it.  I'm actually curious what you mean by not secure and what you
mean by break.

On Sunday, July 31, 2016, Watson Ladd <[email-masked]> wrote:

> <[email-masked] <javascript:;>> wrote:
> <javascript:;>> wrote:
> provide
> >> [email-masked] <javascript:;>

---

From: Michael StJohns <[email-masked]>
Date: Mon, 1 Aug 2016 12:44:00 -0400

*sigh* I hit the wrong reply button and this only went to Watson (who 
replied and I haven't yet read the reply).  It includes an edit I meant 
to make but didn't before sending with respect to my commentary on IOT 
on-line vs off-line attacks.

On 7/31/2016 1:49 PM, Watson Ladd wrote:
> What I mean is an active adversary can guess the password offline
> after one exchange.
>
> They do this by doing the exchange, then seeing which password lets
> them decrypt what you send/makes the key confirmation step work.

I kind of thought that's what you meant.  Translation:  If you have weak 
passwords then the authentication part of this isn't worth anything.

Yup.  We pretty much know this.

I generally figure that a well chosen password (e.g. no dictionary 
words, upper, lower case, special chracters) gives me about 3-4 bits of 
security per character.  So a 16 character password gives you 2^48 to 
2^64 possibilities to try and brute force.  Smaller passwords or weaker 
character sets or dictionary words give you somewhat less.

However, the confidentiality part remains intact due to the ECDH (at a 
strength equal to the key strength).

What I heard from Bob was "IOT" and "ECDH" and "password".   What I 
assumed was he could chose the lower bounds for password entropy because 
(a) the password wasn't sent over the wire so it was a don't care for 
length and (b) he would be smart enough to use a NHI (No humans 
involved) password generators.  What I also assumed was a severe 
constraint on new code and libraries (e.g. IOT).

Given that, and given a desire not to turn a two message protocol into a 
multi message protocol, or to require new software or hardware, I stand 
by my suggestion, for among other reasons, it can be done with existing 
libraries and hardware with no modifications.

Note that this is a derivative of the C(2,2) protocols described in the 
NIST ECDH document.

The question is whether the simplicity of the protocol assuming 
sufficiently long passphrases is a better choice - in this case - than a 
protocol that unconditionally prevents off-line brute forcing, but 
requires math constructs not currently found in the libraries?

I don't know - but I'll bet Bob can figure the tradeoffs.

Later, Mike

ps  - mostly for IOT, on-line attacks tend to be as possible (and as 
hard to detect) and with a similar order of difficulty as offline brute 
forcing.  I mostly don't consider it much of a differentiator.

<addition>
Sorry - meant to expand this.  In the weak password range, repeatedly 
opening up sessions with the target can be done fast enough that most 
PAKE systems - even those that are designed to defeat offline brute 
force attacks - can be brute forced.  If you can get the passwords 
somewhere in the middle range (call it 8-16 characters), then things 
like Watson's proposals provide some additional protection.  Getting 
above that range into the 16+ character passwords - there is little or 
no difference in effective security (vs theoretical security).
</addition>

Now I'll go read what Watson said... :-)

>
> On Sun, Jul 31, 2016 at 10:48 AM, StJohns, Michael

---

From: Dan Harkins <[email-masked]>
Date: Mon, 1 Aug 2016 11:37:46 -0700

Hi Bob,

On 7/29/16 2:59 PM, Robert Moskowitz wrote:
> I have an IoT vendor that has an ECDH KE embedded in their protocol.  
> They have asked me to enhance this with a password. Actually I have 
> TWO such vendors (different industries so no conflict of interest).  I 
> cannot provide details of what they do beyond there is an ECDH KE.
>
> I recognize that this is not directly an IETF problem, but if I point 
> to an IETF protocol, they will be more willing to adopt change.
>
> Choices, choices...
Among your choices, consider RFC 7664 (dragonfly). There are several 
implementations
of it for various transports as well as an open source version of it for 
IEEE 802.11.
That should make it easy to port to your application.

   regards,

   Dan.
>> understood that to continue a productive work on PAKEs in CFRG (not 
>> only on SESPAKE and SPAKE2 drafts) it will be better if all of us now 
>> decide which PAKEs applications to consider as primary ones for IETF.
>>
>> The concrete questions that depend on this decision are more specific 
>> than the ones considered in the requirements draft (which is quite 
>> ready to be followed now)‎ - they are about how the defined protocols 
>> are to be integrated. For instance, if we need a PAKE to be ready for 
>> integration in some IoT initialization protocol (as we discussed with 
>> Hannes Tschofenig) or to be used separately for specific needs as 
>> securing channel between a key container and a CSP (as it is used in 
>> my company), we have to define a wise key confirmation part and 
>> surroundings (like the way of obtaining Q_PW in SESPAKE draft or the 
>> final key K' in Watson's SPAKE2 draft). Otherwise, if we primarily 
>> think about TLS or IKE, for example, we don't need to define anything 
>> except the core key exchange mechanism now - and leave all other 
>> guessing until the future work on a corresponding 
>> TLS(/IKE/SSH/etc)-related draft.
>>
>> Kindest regards,
>> Stanislav Smyshlyaev
>>
>>
>>
>>
>>
>>

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 2 Aug 2016 17:14:29 -0400

On 08/01/2016 12:44 PM, Michael StJohns wrote:
> replied and I haven't yet read the reply).  It includes an edit I 
> meant to make but didn't before sending with respect to my commentary 
> on IOT on-line vs off-line attacks.
>
>
> I kind of thought that's what you meant.  Translation:  If you have 
> weak passwords then the authentication part of this isn't worth anything.
>
> words, upper, lower case, special chracters) gives me about 3-4 bits 
> of security per character.  So a 16 character password gives you 2^48 
> to 2^64 possibilities to try and brute force.  Smaller passwords or 
> weaker character sets or dictionary words give you somewhat less.
>
>
> assumed was he could chose the lower bounds for password entropy 
> because (a) the password wasn't sent over the wire so it was a don't 
> care for length and (b) he would be smart enough to use a NHI (No 
> humans involved) password generators.  What I also assumed was a 
> severe constraint on new code and libraries (e.g. IOT).
>
> Given that, and given a desire not to turn a two message protocol into 
> a multi message protocol, or to require new software or hardware, I 
> stand by my suggestion, for among other reasons, it can be done with 
> existing libraries and hardware with no modifications.
>
> Note that this is a derivative of the C(2,2) protocols described in 
> the NIST ECDH document.
>
> sufficiently long passphrases is a better choice - in this case - than 
> a protocol that unconditionally prevents off-line brute forcing, but 

And I am struggling as the vendor(s) will either print the PSK directly 
on the device or its packaging, or go with something really short and 
'sweet'.

One tradeoff on the offline attack, is that MOST deployments occur where 
the probablity of intercept is very low.  They ask why they even need a 
password it the only time this is run is at deployment, or controller 
replacement.  Thus I actually *like* the wire cutting trick.

> hard to detect) and with a similar order of difficulty as offline 
> brute forcing.  I mostly don't consider it much of a differentiator.
>
> <addition>
>>>>>> They
>>>>>> point
>>>>>> to
>>>>>> only on
>>>>>> specific
>>>>>> than
>>>>>> the ones considered in the requirements draft (which is quite 
>>>>>> ready to
>>>>>> be
>>>>>> integrated. For instance, if we need a PAKE to be ready for 
>>>>>> integration
>>>>>> in
>>>>>> to be used separately for specific needs as securing channel 
>>>>>> between a
>>>>>> key
>>>>>> container and a CSP (as it is used in my company), we have to 
>>>>>> define a
>>>>>> wise
>>>>>> key confirmation part and surroundings (like the way of obtaining 
>>>>>> Q_PW
>>>>>> in
>>>>>> SESPAKE draft or the final key K' in Watson's SPAKE2 draft). 
>>>>>> Otherwise,
>>>>>> if