Subject: Re: [Cfrg] aPAKE Analysis / Why System-Level-View

From: Björn Haase <[email-masked]>
Date: Wed, 18 Sep 2019 07:41:47 +0000

Dear Jonathan, Dear Hugo,

> Hugo Krawcyzk wrote:
>Jonathan, I have not looked into making OPAQUE quantum annoying …

In my perception we should probably not make the mistake of over-estimating the risk of quantum-computing attacks. In my opinion when considering passwords the primary target would be to avoid the obvious known pitfalls. I don’t believe that the fact that OPAQUE is not “quantum annoying” would be any big problem in the real world setting.

In my opinion the key question to structure the future selection process might be that we don’t yet have a common
“system-level view” of the applications that would use PAKE. Most surely there is also not one type of “system” which
would like to use aPAKE.

OPAQUE will make integration into TLS somewhat easier, but I believe that integration of TLS-OPAQUE on the system-level into systems that are dealing with user credential database maintenance, password changes, user-authorization-level changes, user management, etc.
might be quite difficult.

My key questions today are for instance:

  1.  How could I neatly integrate TLS-PAKE with PAM on Linux.
  2.  How could I keep the pitfalls of security away from the normal application developpers.

In my opinion this would best require the feature of a message tunnel for “security subsystems” operating on both sides of the link in addition to the “application”’s payload channel. We would be having today’s application “TCP-like” channel and in addition the possibility to exchange messages between the security-subsystems. This is possibly a somewhat a larger change in TLS, but might be very helpful for neat integration on the system levels.

So in my opinion it’s not only the TLS-Designer perspective which needs to be considered but also the larger perspective of the system. In my opinion the situation for aPAKE is way more complex than for balanced PAKE. I believe that we don’t yet have a common understanding regarding the system level.

In my opinion we also should consider the use-case of “PASSWORD + second-factor” for TLS authentication where the password is protected by PAKE.

@Hugo: It seems that you had primarily use-cases in mind, where one specific secure channel is needed. E.g. for securing a remote VPN access by some user in its home environment? In this case neat integration with PAKE into systems such as PAM might not be the primary target and a simpler “TLS-only” approach will be the best solution with a separate application-specific user-credential database.

@CFRG: I’d appreciate your opinion regarding the system level view. Should we consider integration into systems like PAM or ActiveDirectory databases as important use-case or is our focus rather a “stand-alone” type of system with a small specific database for aPAKE.

Regarding the aPAKE protocols. In my opinion we have very good nominations which all meet (or could be made to meet) the important security targets. The question that I believe to be decisive is the “system view” that employs aPAKE as a subcomponent. Here I see different possible models and advantages and drawbacks of the different nominations.

Yours,

Björn.

Mit freundlichen Grüßen I Best Regards 

Dr. Björn Haase 

Senior Expert Electronics | TGREH Electronics Hardware
Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
Phone: +49 7156 209 377 | Fax: +49 7156 209 221
[email-masked] |  www.conducta.endress.com 

Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hauser-website) nach.

Disclaimer: 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.

---

From: Jonathan Hoyland <[email-masked]>
Date: Wed, 18 Sep 2019 12:50:22 +0100

Hi Björn,

I think the aPAKE candidates analysed in the UC model are taking the right
approach. I think it would be valuable for as
to give them composable features such that it is well defined how to bind
them to other protocols, and how to bind other
protocols to them. If we can define a channel binding for the aPAKE and
further allow the aPAKE to commit to ancillary
data then are well on our way to making it a useful primitive.

In terms of integration with other systems like PAM, ActiveDirectory or
even HTTP, I think it is better to go with a
flexible design, rather than directly cater for specific use cases.

Integrating TLS-PAKE with PAM doesn't strike me as likely to be
challenging. Admittedly I have never written a PAM
module before, but it would seem to be simple enough, at least with OPAQUE
with Exported Authenticators (EAs).  The PAM
database would store `EnvU, PubS, PubU, kU, kV`,  make the appropriate
challenge, which would be wrapped in the
appropriate TLS EA frames by the TLS stack, the responding certificate
would have the channel binding checked by the TLS
stack, before passing the certificate to the PAM module to verify the
signature proves knowledge of `PrivU`.

Presumably if the PAM database is being upgraded / goes away then people
won't be able to successfully authenticate,
which is at least fail closed.  If there were a reference PAM module then
'normal' application developers wouldn't need
to implement any code, especially if support were built in to servers
implementing TLS PAKE.

Things like password updates are also simple, in as much as, you just
repeat the registration step, with the application
logic handling who is allowed to do what and when.

Given that EAs are handled at the HTTP layer in the form of certificate
frames, I imagine that TLS-OPAQUE would also be
handled at the HTTP layer, so more complex logic would be done at the
higher layers.

The key thing I would say about separating off the aPAKE into a security
subsystem is that we need to make sure that the
binding to the TLS connection is strong, and in particular that there is no
way to pass the aPAKE protocol between two
different TLS connections.

Consider the current system: A user, `A`, connects to a server `B` and
reuses the same password that she established
with server `C`.  `B` can now take this password and use it to impersonate
`A` to `C`.

Now consider a system where an aPAKE is simply run inside a TLS connection
with no attempt to bind it to the underlying
TLS session: A user, `A`, connects to a server `B` and reuses the same
password that she established with server `C`.
`B`, instead of running the aPAKE honestly opens a new connection to `C`
and simply forwards the messages back and
forth.  The protocol succeeds, because in this scenario we assume that `A`
is not checking consistency between the TLS
connection and the aPAKE protocol.  `C` might now, incorrectly, assume that
the owner of the TLS connection, `B`, has
successfully authenticated himself as `A`. The key established between `A`
and `C` is not used to authenticate any
future data on the connection, and `B` can now perform any action for which
`A` is authorized.

All this to say, a strictly compartmentalized approach to constructing
TLS-PAKE is unlikely to be secure. Specifically,
the inner and outer protocols not only need to be aware of each other, they
need to interact.

If by security subsystem you only meant a way to separate application data
and aPAKE data then defining a new TLS record
type for authentication messages sent over TLS would be fairly trivial.

If we select a PAKE that is easy to compose with other protocols then it
should be versatile enough to handle anything
we need it to.

Second-factor authentication would be a good example of a protocol that
would be bound to a PAKE, and we should design
bindings accordingly, such that we don't need to consider second-factor
directly.

I think OPAQUE-EA has good composition properties, but all of the
candidates have scope.

Regards,

Jonathan

---

From: Natanael <[email-masked]>
Date: Thu, 19 Sep 2019 17:28:29 +0200

> data then are well on our way to making it a useful primitive.

I'd like to note that the U2F spec has a channel binding option. IIRC it
derives a session ID (or equivalent value) from the TLS key exchange and
commits to it.

Reference;
https://fidoalliance.org/fido-technotes-channel-binding-and-fido/

Unfortunately it isn't implemented in any U2F compatible browser - only
Chrome used to support it, but then they later removed it (citing
complexity, although I believe the security benefit justifies it). Firefox
never supported it. Hopefully it will regain support. But regardless, the
approach used in that spec might be a good starting point here too?

And a sidenote: as I've mentioned before, I'd really like to see a PAKE
protocol and a 2FA protocol like U2F being supported together. If both of
these protocols would also have proper channel binding, then this would
offer significantly improved security without sacrificing usability.

Being able to trigger a PAKE from a button press on your 2FA hardware token
would also be a significant UX improvement over many of the other options
with similar security level.

---

From: Björn Haase <[email-masked]>
Date: Sun, 22 Sep 2019 21:31:15 +0200

> Being able to trigger a PAKE from a button press on your 2FA hardware
> token would also be a significant UX improvement over many of the
> other options with similar security level.
>
Do I correctly understand that you had in mind: The user first
establishes a normal https:// connection and then presses the 2FA
hardware switch in order to run a PAKE in addition to the previous
certificate-based authentication?

This is not what I assumed. What I had in mind is rather the following
procedure. The server knows its requirements regarding security, etc. .
The user and the browser don't know the required procedure in advance
when connecting. If the server is needing 2FA, it would arrange the
client to provide the aPAKE password entry mask and provide a "Please
press authentication token switch for authentication".

Did I actually mis-understand your post?

---

From: Björn Haase <[email-masked]>
Date: Sun, 22 Sep 2019 21:24:05 +0200

Am 18.09.2019 um 13:50 schrieb Jonathan Hoyland:
> Hi Björn,
>
> I think the aPAKE candidates analysed in the UC model are taking the
> right approach. I think it would be valuable for as
> to give them composable features such that it is well defined how to
> bind them to other protocols, and how to bind other
> protocols to them. If we can define a channel binding for the aPAKE
> and further allow the aPAKE to commit to ancillary
In case of UC the natural way of channel binding would (IMO) be use of
the UC concept of the session ID. At the same time this concept might
also generate some complexity (see the separate threads).
> In terms of integration with other systems like PAM, ActiveDirectory
> or even HTTP, I think it is better to go with a
I agree. The important aspect for me is, that I would appreciate any
effort to keep away the authentication and user-credential part of the
"http://" protocol subsystem. In my experience this is exactly the part
of the application which is mostly developped by teams not experienced
with security. For this reason my reasoning was: How to keep away all of
the security and authentication complexity away from the "application"
channel that might use "http" or some other application protocol for HMI.
> module before, but it would seem to be simple enough, at least with
> OPAQUE with Exported Authenticators (EAs).  The PAM

I'd be reviewing this approach. However in my opinion this would mean
that, e.g. on an embedded linux system, we would have to convince the
PAM people to drop the conventional user credential database format and
use OPAQUE password verifiers also for the local logins.?

I fear, however that this approach would likely fail when considering
future rollouts of "aPAKE + 2FA" ? In this case, we would need most
surely some other communication prior to running OPAQUE? At least in
this case I don't see how to avoid some kind of handshake round between
client and server, if the client could not be assumed to know beforehand
what specific option the server needs.

> Presumably if the PAM database is being upgraded / goes away then
> people won't be able to successfully authenticate,
> which is at least fail closed.  If there were a reference PAM module
> then 'normal' application developers wouldn't need
I'd have to review the EA frame option. It might indeed be a good option.
> Given that EAs are handled at the HTTP layer in the form of
> certificate frames, I imagine that TLS-OPAQUE would also be

Note, that working with passwords on the http:// layer would be exactly
what I'd be trying to avoid. My personal assessment is "once we have the
clear-text passwords somewhere on the http:// or application layer the
evil will start to happen". Also using http:// as basis might make it
more complex to re-use the authentication method over non-http://
applications such as svn or git clients?

> The key thing I would say about separating off the aPAKE into a
> security subsystem is that we need to make sure that the
> binding to the TLS connection is strong, and in particular that there
> is no way to pass the aPAKE protocol between two

> with server `C`.  `B` can now take this password and use it to
> impersonate `A` to `C`.
>
> Now consider a system where an aPAKE is simply run inside a TLS
> connection with no attempt to bind it to the underlying
> `B`, instead of running the aPAKE honestly opens a new connection to
> `C` and simply forwards the messages back and
> forth.  The protocol succeeds, because in this scenario we assume that
> `A` is not checking consistency between the TLS
> connection and the aPAKE protocol.  `C` might now, incorrectly, assume
> that the owner of the TLS connection, `B`, has
> successfully authenticated himself as `A`.. The key established
> between `A` and `C` is not used to authenticate any
> future data on the connection, and `B` can now perform any action for
> which `A` is authorized.
>
I believe that I did yet not fully understand your reasoning, but this
seems to be closely what Franziskus Kiefer and Mark Manulis have pointed
out in their paper [MSKD16] "Secure modular password authentication for
the web using channel bindings".

> the inner and outer protocols not only need to be aware of each other,
> they need to interact.

Yes, and as pointed out in my post from some minutes ago, the channel
binding that I'd suggest is to use a session id that is established in
an initial "ClientHello"-"HelloRetry" communication.

I'd appreciate to have more things integrated in TLS since these people
tend really to know what they are doing securit-wise, however I fear
that we might better have some more modularity in order to keep TLS
maintainable.

>
> If by security subsystem you only meant a way to separate application
> data and aPAKE data then defining a new TLS record
Yes. That's about what I thought of.
> If we select a PAKE that is easy to compose with other protocols then
> it should be versatile enough to handle anything
> we need it to.
>
> Second-factor authentication would be a good example of a protocol
> that would be bound to a PAKE, and we should design
> bindings accordingly, such that we don't need to consider
> second-factor directly.
>
P.S.:

... I think that it would be good to have kind of Face2Face meeting on
all of these topics ...

---

From: Björn Haase <[email-masked]>
Date: Sun, 22 Sep 2019 21:56:43 +0200

In the last week I have spent some time regarding the patent situation
for hash-2-curve which is an important requirement for some
of the PAKE nominations.

We were aware of some patent pitfalls that drove us to include a patent
circumvention approach based on the TBPEKE construction in our paper
"for the case of need".

After some discussion with patent people and some further research I now
come to the conclusion that with the recent draft of the hash2curve RFC,
we should be keeping safely away from the patents. Methods such as the
circumvention approach from Appendix A of the AuCPace paper are most
surely not necessary and should not be used.

The important aspect is that it seems that in all relevant countries
divisional applications seem to be ruled out for patents that once have
been granted. Historically this was not the case everywhere, but
legislation seem to have been harmonized. This means that for the
existing patents that we only need to consider what is actually claimed
and not what might be interpreted successfully into the descriptive
text. My main concern so far was that the patent family of the joint
work of Icart and Coron might generate trouble in the context of
divisional applications because the descriptive text explicitly
references also to the use of any non-square special value as part of
the mapping algorithm for simplying SWU.

I now come to the conclusion, that as long we keep away from the exact
value of the non-square "-1" for simplified SWU constructions, we should
not be facing patent problems.

@Riad: Maybe you could also double check that what you are doing in the
RFC for your version of the simplified SWU is not covered by claim 1 of
US 8,718,276 B2.

Yours,

Björn.

---

From: Natanael <[email-masked]>
Date: Tue, 24 Sep 2019 12:15:27 +0200

> certificate-based authentication?

Wouldn't have to be the default, but I'm considering a version of this;

If the server tells the client that it supports both hardware 2FA and PAKE,
and that they are supported together (and this flag could be cached on the
client so it can alert on downgrade), then yes.

It would perform HW 2FA auth on button press (may include certificates) and
then trigger PAKE. The user types the password and hits OK. Done.

> Did I actually mis-understand your post?

Your approach seems to be slightly different. So the browser first opens
the PAKE prompt and you then verify with the token? Presumably the browser
informs the user that the current webpage has PAKE support, they click to
open the prompt, and confirm with HW 2FA verification?

While functionally similar, the difference is in the UX security.

With your approach one could more easily get the user password through
phishing by showing them fake login prompts (and in a targeted attack, the
token could then be stolen).

A user that has been successfully taught that the password must only be
entered in the prompt after pressing the HW 2FA button will not type their
password into phishing prompts.