updates authenticated by opaque

[stef]

would it make sense to write a short blurb recommending that password updates and envelope and configuration updates can be simply constructed by first running an opaque to authenticate the user and then to run the registration based on this? or is this obvious?

[kevinlewi]

I don't believe there is another (safe) way to do password / envelope / configuration updates other than running registration again. I think this is covered by the text in the Application Considerations section:

Configuration and envelope updates: Applications may wish to update or change their configuration or other parameters that affect the client's RegistrationRecord over time. Some reasons for changing these are to use different cryptographic algorithms, e.g., a different KSF with improved parameters, or to update key material that is cryptographically bound to the RegistrationRecord, such as the server's public key (server_public_key). Any such change will require users to re-register to create a new RegistrationRecord. Supporting these types of updates can be helpful for applications that anticipate such changes in their deployment setting.

[stef]

ok, maybe my question was ambiguous, the point is how to authenticate the re-registration. and in case there is no compromise of the server, i think a regular opaque login would suffice for authenticating a re-registration.

[kevinlewi]

Oh, I see. I suppose this depends on the application though. One way to do it might be to do a regular opaque login. But maybe if this is implemented on a website which relies on 2-factor authentication (via SMS/email for instance), then a password reset could be triggered through the 2-factor authentication mechanism (and not rely on OPAQUE login at all). I think this is also outside of the scope, since at the protocol level we can't really make recommendations for what the right way for an application to handle this scenario would be without getting too specific.

[stef]

sure, it does depend on the application. but in a closed universe where only opaque exists this would be a reasonable way to do it. but if we step out of this universe, there can be all kind of other authentication mechanisms piled on top. so maybe something like:

"An implementation can chose any other and more sophisticated authentication mechanism to authorize a re-registration. However the simplest - given OPAQUE is already implemented, and there is no direct compromise of the server known - method to authorize a re-registration flow by a user is to be authenticated by using a normal OPAQUE login flow, which upon success executes the re-registration."

[Imberflur]

IIUC authenticating with the normal login flow followed by re-registration works for simple password changes. But if this includes configuration updates like changing the KSF, I think additional complexity is necessary since the client needs to know what configuration to use for the login flow? Such as one of these:

1. The client somehow already locally knows whether the configuration has been updated (e.g. by storing state, prompting the user(?)).
2. The login flow is ran for all possible configurations at once as described in Update algorithm #294 (comment).
3. External authentication is used (e.g. 2-factor auth method mentioned above).
4. Current configuration is exposed in a way that allows user enumeration.

While writing this I thought of another potential approach and potential issues with it:

The client tries the login flow with the latest configuration version first, and iteratively tries the next older version if that fails. I don't know whether there would be an issue with an attacker forcing the client to try older versions? If so, that probably also applies to (2). Unlike (2), this would allow someone listening to know what version the client was on before they updated to the latest version (could reveal rough information on when the client last logged in). Hmmm, any actual login failure from invalid credentials would also lead to trying all possible versions.

[stef]

the server is unaware of the ksf used. and the client knowing the configuration is not an issue i believe, part of the configuration is also the server's address and port, and indeed the client itself - that can have all kind of hard-coded info.

i think it is an implementation detail - and maybe an upgrade path config - that an update first uses the previous config for authentication and then the new config for the recreation.