Re: [Cfrg] Proposed PAKE Selection Process // Integration in TLS ?

["Björn Haase" <[e-mail]>]

Dear Eric,

thank you for your feedback! I do agree with and understand your points.

I am having several questions/remarks which I would like to address in separate threats, starting with the possibly most controversial side-aspects to consider for TLS integration.

> Eric Crocket wrote:
>1. We would like to see the standardization of both a standalone scheme and its integration into TLS, similar to SRP (RFCs 2945 and 5054) or OPAQUE

I fully agree with you and also would also like to see PAKE integrated as a component in TLS. The important aspect to consider, when doing this, IMO will be that we are then integrating components into the TLS stack which today mostly are assigned to the "application layer" (which often should be expected not to consider security adequately). 

E.g. after a successful TLS-managed login the application on the server will need to know which user is just logged-in, e.g. in order to find out which authorization rights to attribute to the current session.This means that the interface to the TLS system would become somewhat more powerful and complex, by providing interfaces regarding user accounts.

Also for some use-cases, the application will have the need to request a re-authentication of a HMI user: Consider, e.g. the use-case of a "Do you really want to trigger the self-destruction functionality? Please re-enter the password" mask.

I.e. for the use-case that you did sketch (similar to my use-case U2)  I'd see the need for interfaces between the TLS system and the "application layer" for

- Querying which user is logged in and optionally mange authorization rights
- Arranging for a re-authentication upon application request, possibly with another account (similar to a "su" shell command on unix systems).
- Optionally: Managing user accounts (e.g. Password changes, changes of authorizations).

The key question that makes above components mandatory (IMO) is: Does the application layer need to consider user accounts with different authorization levels? 

In the settings that I have in mind (my use case U2) the answer is: Definitely "yes, we need to deal with the complexity of user authorization levels."
How is the situation in your AWS use-cases?

IMO the aspect of a possibly more complex TLS interface will generate a lot of discussions, but this is definitely manageable. We have been doing this specifically in our proprietary TLS-like security stack for our industrial HMI service app (E+H SmarBlue). The advantage of integrating the account management in our security/networking stack is that this way, we were able to clearly modularize the software into a security-submodule and an application-module.

I expect a lot of discussions, but the overall advantages also regarding usability on the HMI interface and the ease-of use for the security configuration together with the improved security would be definitely worth the effort IMO!


Note that all of this complexity does not show up for the use case U1 (PAKE as replacement for PSK) from my earlier mail, since distinction between several authorization levels was not relevant. 

Yours,

Björn.