Re: [Cfrg] I like PKEX

[David Jacobson <[e-mail]>]

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 <[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