Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03A2126C22 for ; Sat, 2 Dec 2017 19:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sbcglobal.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFmT0l0znFiE for ; Sat, 2 Dec 2017 19:46:52 -0800 (PST) Received: from sonic315-18.consmr.mail.bf2.yahoo.com (sonic315.consmr.mail.bf2.yahoo.com [74.6.134.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAFEB124D6C for ; Sat, 2 Dec 2017 19:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1512272810; bh=eKkE4FF6CZcWrFGh42WLOKfdulur8g9SlrvQOwKn6A8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=TaE6jJ8GPwWs2ER2YBGXHR35Eb3kSogz8jjXTu/Jomrnm+6VsbcfyK41b5nYSUhAvfHIj3LS99iAj7eGV8KUDUysS2sBZH+uKMacffNYJHpgZvqNamJLIGVM8vMDPVmvrS3bze8wmX2QLMtx3UU8YDOZToX6IO/c6cVAq7dBwHplTbyyZuWmwQ+LYvM8OqLumb3lnV3X9qG0XVpr9GY8O21m/9JKyEGItNZupHJ8nPuS1fekm/vRJpWHjMaVtZTyQEZ6HcJSJdQaZNB3gmdcIRbwf1phCaxLhOCjaVGqGdpAwvEe8ZYo664NV+CEmhlmzmZyNe3PeWOeqscmnElXAg== X-YMail-OSG: Ga8jmeYVM1l3MbxnelsTgL_X63kiqB3vJoYAann0xQg9LLEqfmZ2Uew_G.1pK4l j31gQoTasNKAXQq4uCbOs1TqWwShJ6iczNlauDkXxRvUwyMjcl9s.vQfRyOqpwo7SXLsvYryVI7S ovTAwqHqOTZnBS7ZhAidWCtmclansKycE2sjLqS7u4k4jPP4xjnFigMNDBs40yvQ6fMO33Lx.hc7 0HqjTrWM8Cw68fbRnj8RXllZLqZXVHw7UYdfSb.Ecgq_IDvlge2t3GmCpsgjxDyP751_Xh6etduY SvXYLioOA2M7zhORRkUncod_GmkLgnojQAdSQNh50hDu8iGJylmBf2N5IeKK5pUBxt9oO6cQhgUz h_SLDlt3PG9H.5ERWZDnxUeQuiTUkuaTmYxO1EvukiTLnBXVP2sljR5BBzeLob_rHEVmSjJfFNPt 9HUqBOa6nMZVE8H2N0B.uS.QkHsiG6pKqNQ5ixiZFC2YPkQDEK4s7_g1ySWEGp3.RaxXgfJve64J DyHZvcrmo1Xrx1EEj Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Sun, 3 Dec 2017 03:46:50 +0000 Received: from smtp101.sbc.mail.bf1.yahoo.com (EHLO Davids-iMac.local) ([98.139.228.106]) by smtp414.mail.bf1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 1716476646; Sun, 03 Dec 2017 03:46:49 +0000 (UTC) To: "Stanislav V. Smyshlyaev" , Richard Barnes Cc: "cfrg@irtf.org" References: From: David Jacobson Message-ID: <4fa7e777-22e2-264f-1119-8f593b6487ef@sbcglobal.net> Date: Sat, 2 Dec 2017 19:46:46 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DD053119B569B3027A2891C2" Content-Language: en-US Archived-At: Subject: Re: [Cfrg] I like PKEX X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 03:46:55 -0000 This is a multi-part message in MIME format. --------------DD053119B569B3027A2891C2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 >: > > 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 >: > > Sorry, what is PKEX? > > On Thu, Nov 16, 2017 at 3:11 PM, Salz, Rich > 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 list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --------------DD053119B569B3027A2891C2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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 list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


--------------DD053119B569B3027A2891C2--