Re: [Cfrg] I like PKEX

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 <dmjacobson@sbcglobal.net>:

> 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 <smyshsv@gmail.com>:
>
>> In fact, PKEX (password-authenticated key exchange protocol by Dan
>> 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 <rlb@ipv.sx>:
>>
>>> Sorry, what is PKEX?
>>>
>>> On Thu, Nov 16, 2017 at 3:11 PM, Salz, Rich <rsalz@akamai.com> 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 list
>>>> Cfrg@irtf.org
>>>> https://www.irtf.org/mailman/listinfo/cfrg
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Cfrg mailing list
>>> Cfrg@irtf.org
>>> https://www.irtf.org/mailman/listinfo/cfrg
>>>
>>>
>>
>
>
> _______________________________________________
> Cfrg mailing listCfrg@irtf.orghttps://www.irtf.org/mailman/listinfo/cfrg
>
>
>