Subject: Re: [Cfrg] I like PKEX

From: David Jacobson <[email-masked]>
Date: Sat, 2 Dec 2017 19:46:46 -0800

I'm not a web protocol expert, nor a PKEX/PAKE expert, so what I'm about 
to mention might be already solved.

1.  I'd like some advocates of PKEX/PAKE to give a brief explanation of 
what has to be added to browsers to make this work.  And, in particular, 
how can the end-user be sure that the thing asking for her account 
number and password is the genuine browser implementation of the client 
side of PKEX or PAKE, not some imposter?

2.  How do you bootstrap the security?    The connection can't be secure 
until the client presents some credentials.  But the client doesn't want 
to send credentials in the clear during the setup. And the client wants 
to be certain that the entity she is communicating with is genuine.  So 
it looks like we have to use the present protocols for creating an 
account.   So we haven't really gotten rid of having to trust a CA.

3.  And a similar problem arises around anonymous browsing. Suppose our 
end user wants to browse women's apparel and wants to look around and 
not identify herself unless she sees something she likes and wants to 
buy it.  There are many people who advocate using HTTPS for everything 
to make it hard for an attacker to inject a malicious web page.  But 
with PKEX/PAKE the client either has to fall back on present protocols 
or be vulnerable to injected attacks until she has decided to reveal her 
identity.

    --David Jacobson

On 11/15/17 11:31 PM, Stanislav V. Smyshlyaev wrote:
> Though, unfortunately, I am not aware of any online banking systems or 
> messengers that use PAKEs for user authentication, I'd like to mention 
> (hope you consider it interesting) that there are some existing cloud 
> signature solutions (digital signature servers) in Russia that use one 
> of PAKEs to authenticate users to their private keys stored in a cloud 
> - in a way that is pretty similar to the one that has been mentioned 
> by Rich.
>
>
> Best regards,
> Stanislav
>
>
> 2017-11-16 15:23 GMT+08:00 Stanislav V. Smyshlyaev <[email-masked] 
> <mailto:[email-masked]>>:
>
>     In fact, PKEX (password-authenticated key exchange protocol by Dan
>     Harkins, https://tools.ietf.org/html/draft-harkins-pkex-04
>     <https://tools.ietf.org/html/draft-harkins-pkex-04> - for
>     Richard), as all secure PAKE protocols can help to upgrade most
>     cases of authentication, when some shared secret (password or, as
>     in Rich's example, an account number), to solutions which do not
>     require having a primary trust to someone you're authenticating to.
>
>     I'd also like to see PAKEs in the messengers, as I commented
>     during the CFRG meeting yesterday.
>
>
>     2017-11-16 15:21 GMT+08:00 Richard Barnes <[email-masked]
>     <mailto:[email-masked]>>:
>
>         Sorry, what is PKEX?
>
>         On Thu, Nov 16, 2017 at 3:11 PM, Salz, Rich <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             I think the PKEX stuff is very interesting.  It inverts
>             the trust model used on the Web. Suppose I want to do some
>             online banking with mybank.com <http://mybank.com>. My
>             browser checks the server cert, and decided to trust it if
>             the CA verifies the identity. I then type my name and
>             password into the website. There is a risk if I end up at
>             the wrong website.
>
>             With PKEX, I can use my name and password and the bank can
>             use something like my account number or other similar
>             info, and we exchange and get a shared secret. We then use
>             that secret to get an authenticated ECDSA key and then I
>             switch to TLS and get its benefits.  No third-party trust
>             is needed.
>
>             I think this solves an interesting use-case and it would
>             be nice to have it in our toolbox.
>
>
>             _______________________________________________
>             Cfrg mailing list
>             [email-masked] <mailto:[email-masked]>
>             https://www.irtf.org/mailman/listinfo/cfrg
>             <https://www.irtf.org/mailman/listinfo/cfrg>
>
>
>
>         _______________________________________________
>         Cfrg mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.irtf.org/mailman/listinfo/cfrg
>         <https://www.irtf.org/mailman/listinfo/cfrg>
>
>
>
>
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Sun, 3 Dec 2017 13:36:25 +0300

Dear David,

PKEX/PAKEs cannot be seen as a silver bullet, that can solve any
authentication problems.

My view on the second and the third questions that you've raised is the
following.
First of all, the usage of PAKE always assumes that there is a certain
password distributed among communicating parties - this type of protocols
is absolutely meaningless otherwise. That provides an answer to your third
question: PAKEs cannot provide any help for anonymous browsing.

On the second question and the security bootstrapping issue - PAKEs can
help in the following case: when some memorable secret is used for the
initial secure communication session, during which long-term secret keys
can be established and stored in the devices for all further authentication
purposes. But you're completely right that PAKEs can't be used without any
preceding actions (face-to-face communication, provision of some memorable
PINs to users, negotiation to some "security questions" etc).

Best regards,
Stanislav Smyshlyaev, Ph.D.,
Head of Information Security Department,
CryptoPro LLC

2017-12-03 6:46 GMT+03:00 David Jacobson <[email-masked]>:

> how can the end-user be sure that the thing asking for her account number
> and password is the genuine browser implementation of the client side of
> PKEX or PAKE, not some imposter?
>
> until the client presents some credentials.  But the client doesn't want to
> send credentials in the clear during the setup.  And the client wants to be
> certain that the entity she is communicating with is genuine.  So it looks
> like we have to use the present protocols for creating an account.   So we
> haven't really gotten rid of having to trust a CA.
>
> end user wants to browse women's apparel and wants to look around and not
> identify herself unless she sees something she likes and wants to buy it.
> There are many people who advocate using HTTPS for everything to make it
> hard for an attacker to inject a malicious web page.  But with PKEX/PAKE
> the client either has to fall back on present protocols or be vulnerable to
> injected attacks until she has decided to reveal her identity.
>
>    --David Jacobson
>
>
>
>
>
> signature solutions (digital signature servers) in Russia that use one of
> PAKEs to authenticate users to their private keys stored in a cloud - in
> a way that is pretty similar to the one that has been mentioned by Rich.
>
>
> Best regards,
> Stanislav
>
>
> 2017-11-16 15:23 GMT+08:00 Stanislav V. Smyshlyaev <[email-masked]>:
>
>> Harkins, https://tools.ietf.org/html/draft-harkins-pkex-04 - for
>> Richard), as all secure PAKE protocols can help to upgrade most cases of
>> authentication, when some shared secret (password or, as in Rich's example,
>> an account number), to solutions which do not require having a primary
>> trust to someone you're authenticating to.
>>
>> I'd also like to see PAKEs in the messengers, as I commented during the
>> CFRG meeting yesterday.
>>
>>
>> 2017-11-16 15:21 GMT+08:00 Richard Barnes <[email-masked]>:
>>
>>> Sorry, what is PKEX?
>>>
>>> On Thu, Nov 16, 2017 at 3:11 PM, Salz, Rich <[email-masked]> wrote:
>>>
>>>> I think the PKEX stuff is very interesting.  It inverts the trust model
>>>> used on the Web.   Suppose I want to do some online banking with
>>>> mybank.com. My browser checks the server cert, and decided to trust it
>>>> if the CA verifies the identity. I then type my name and password into the
>>>> website. There is a risk if I end up at the wrong website.
>>>>
>>>>
>>>>
>>>> With PKEX, I can use my name and password and the bank can use
>>>> something like my account number or other similar info, and we exchange and
>>>> get a shared secret. We then use that secret to get an authenticated ECDSA
>>>> key and then I switch to TLS and get its benefits.  No third-party trust is
>>>> needed.
>>>>
>>>>
>>>>
>>>> I think this solves an interesting use-case and it would be nice to
>>>> have it in our toolbox.
>>>>
>>>>
>>>>
> Cfrg mailing [email-masked]://www.irtf.org/mailman/listinfo/cfrg
>
>
>

---

From: Dan Harkins <[email-masked]>
Date: Sun, 3 Dec 2017 23:26:31 -0800

Hi David,

On 12/2/17 7:46 PM, David Jacobson wrote:
> I'm not a web protocol expert, nor a PKEX/PAKE expert, so what I'm 
> about to mention might be already solved.
>
> 1.  I'd like some advocates of PKEX/PAKE to give a brief explanation 
> of what has to be added to browsers to make this work.  And, in 
> particular, how can the end-user be sure that the thing asking for her 
> account number and password is the genuine browser implementation of 
> the client side of PKEX or PAKE, not some imposter?

   The only way the PAKE can succeed is if both sides know the same 
password.
The advantage an attacker gains against the PAKE is based on interaction 
and not
computation so as long as the user limits the number of "oh I must've 
fat-fingered
my password, let me try again" the probability that the other side is 
not genuine
can be acceptably low-- it would be n/d where n is the number of "oh I 
must've
fat-fingered..." attempts attempted before giving up and d is the size 
of the pool
from which the password was drawn.

> 2.  How do you bootstrap the security?    The connection can't be 
> secure until the client presents some credentials.  But the client 
> doesn't want to send credentials in the clear during the setup.  And 
> the client wants to be certain that the entity she is communicating 
> with is genuine.  So it looks like we have to use the present 
> protocols for creating an account.   So we haven't really gotten rid 
> of having to trust a CA.

   Yes, this is a problem, we can't create security out of whole cloth. 
Depending
on the site the password could be set up face-to-face (think of a bank) 
or maybe
sent via SMS (think a social media sight). There is no need for a CA 
though because
the password, once established, is parlayed into a trusted public key. 
Once PKEX
is finished the password can be thrown away, or even exposed. It is of 
no use
anymore. The public key is now used.

   Why do PKEX if you're gonna bootstrap the whole thing face-to-face? 
Well, a password
is a more natural credential than a public key. It would be possible to 
do a PGP web
of trust type of interaction to exchange trusted public keys at the bank 
but that level
of sophistication is beyond your random teller and your random bank 
customer. Giving an
8 character password (abcd-wxyz) would be easy for teller to provide and 
for the
customer to understand how to use-- just enter it next time he or she 
points a browser
to the bank's website.

> 3.  And a similar problem arises around anonymous browsing.   Suppose 
> our end user wants to browse women's apparel and wants to look around 
> and not identify herself unless she sees something she likes and wants 
> to buy it.  There are many people who advocate using HTTPS for 
> everything to make it hard for an attacker to inject a malicious web 
> page.  But with PKEX/PAKE the client either has to fall back on 
> present protocols or be vulnerable to injected attacks until she has 
> decided to reveal her identity.

   This isn't a solution to the problem of anonymous browsing but I 
would imagine
that in the scenario you describe that if the sight was willing to 
support that
sort of thing the HTTPS connection could be set up with server-side only
authentication where the woman browsing authenticates the website with the
public key she obtained earlier from her run of PKEX. Then she can 
anonymously
browse to her heart's content until she finds something and then when 
she goes
to purchase the selected item(s) will do another run of TLS this time 
with mutual
authentication where she presents her public key, the one she provided 
during
her run of PKEX, as part of client authentication.

   regards,

   Dan.

>> Though, unfortunately, I am not aware of any online banking systems 
>> or messengers that use PAKEs for user authentication, I'd like to 
>> mention (hope you consider it interesting) that there are some 
>> existing cloud signature solutions (digital signature servers) in 
>> Russia that use one of PAKEs to authenticate users to their private 
>> keys stored in a cloud - in a way that is pretty similar to the one 
>> that has been mentioned by Rich.
>>
>>
>> Best regards,
>> Stanislav
>>
>>
>>     In fact, PKEX (password-authenticated key exchange protocol by
>>     Dan Harkins, https://tools.ietf.org/html/draft-harkins-pkex-04
>>             the trust model used on the Web.   Suppose I want to do
>>             some online banking with mybank.com <http://mybank.com>.
>>             My browser checks the server cert, and decided to trust
>>             it if the CA verifies the identity. I then type my name
>>             and password into the website. There is a risk if I end
>>             up at the wrong website.
>>
>>             With PKEX, I can use my name and password and the bank
>>             can use something like my account number or other similar
>>             info, and we exchange and get a shared secret. We then
>>             use that secret to get an authenticated ECDSA key and
>>             then I switch to TLS and get its benefits.  No
>>             third-party trust is needed.
>>