Re: [Cfrg] I like PKEX

[Dan Harkins <[e-mail]>]

   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.

>    --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 <[e-mail] 
>> <mailto:[e-mail]>>:
>>
>>     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 <[e-mail]
>>     <mailto:[e-mail]>>:
>>
>>         Sorry, what is PKEX?
>>
>>         On Thu, Nov 16, 2017 at 3:11 PM, Salz, Rich <[e-mail]
>>         <mailto:[e-mail]>> 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
>>             [e-mail] <mailto:[e-mail]>
>>             https://www.irtf.org/mailman/listinfo/cfrg
>>             <https://www.irtf.org/mailman/listinfo/cfrg>
>>
>>
>>
>>         _______________________________________________
>>         Cfrg mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.irtf.org/mailman/listinfo/cfrg
>>         <https://www.irtf.org/mailman/listinfo/cfrg>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg
>
>
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg