Questions on OPAQUE Implementations

[afbase]

Hello @chris-wood ,

I have some questions regarding some of the inputs, outputs, and implementation ideas i have in my head. Hopefully they don't sound too off the mark here.

1. Offline Registration: Can the offline registration server be different than the server in the online AKE?

   • I feel like the answer is yes, and if that is the case, as the offline registration server, I could then push any RegistrationRecord (or the subset of the registration record of the client_public_key and encrypted envelope and the online AKE server can query an HSM/KMS for the masking key) to any Online AKE server. Here is an example with a Client, (offline) Registration Server, (online) AKE'ing Microservice, and a Cloud HSM/KMS:

     sequenceDiagram
     participant Client
     participant Registration Server
     participant AKE'ing Microservice
     participant Cloud HSM/KMS
     Client->>Registration Server: registration request
     Registration Server->>Client: registration response
     Client->>Registration Server: record
     Registration Server->>AKE'ing Microservice: (record.envelope, record.client_public_key)
     Registration Server->>Cloud HSM/KMS: store record.masking_key @ HSM/KMS
     Client->>AKE'ing Microservice: KE1
     AKE'ing Microservice->>Cloud HSM/KMS: Runs Expand with record.masking_key @ HSM/KMS
     AKE'ing Microservice->>Client: KE2
     Client->>AKE'ing Microservice: KE3

   • ⬆️ I feel like I'm missing a problematic assumption about the server_private_key here, i.e. the AKE'ing Microservice and Registration Server share the server_private_key. Maybe it helps if it is also on the HSM/KMS???

2. password: Does it need to be a password? A couple of ideas here, each separate and distinct but regard this question:
   • Can this be a Client's private key instead that is different from the client_private_key?
     • I've not really given much thought here nor am I sure why I would.
3. If I'm an SSO provider (and acting as an offline registration server), I feel like I might just want to use OPAQUE as a third way to authenticate Clients instead of composing it with say SAML or OIDC as the two usual ways authentication + authorization is done, yes?
   • I just can't imagine composing OPAQUE registration or AKE'ing protocols with say OIDC ID tokens, access tokens, or refresh tokens, or SAML assertions.
   • On the other hand, Can I use ID tokens, access tokens, or refresh tokens, or SAML assertions as a client_identity? I don't know what is gained (or lost) by doing that. I welcome any and all pointers on thinking about this in a different way.
4. Application Layer Idea: Apologies if this is very high level and not a lot of details explained.
   • HTTPS REST API Requests: It would be really "inefficient" to use OPAQUE over HTTPS assuming the underlying TLS session provides communication security; but I might want to use OPAQUE to authentication an HTTPS REST API client with a password and not suffer from the have I been pwned problem. So suppose I am an HTTPS REST API client and have authenticated and have my session_key.
     • If I'm the client and I go through the AKE to get the session_key, can I use my client_private_key to sign the session key and submit that to an authorization server that has my client_public_key to get a some kind of authorization token like a biscuit?
     • can I use the session_key as-is for a bearer token for HTTPS requests? (This feels very wrong :zipper_mouth_face:)
5. Protocols that don't use TLS: I'm drawing a bit of a blank as to other protocols that aren't TLS based that could stand to benefit from OPAQUE right now. I would love to do a survey of protocols where OPAQUE might be better suited.

[stef]

regarding your 2nd 1st question, it's an PAKE where the P stands for password, and the password is treated as such (hashing it to a curve with a password hashing algorithm) - so if you have a private key instead of a password, then you could of course use it, but your public key would go unused, and if you already have a pub/priv keypair then there are other better protocols to achieve what opaque does. actually you only need the ake then, and can skip the OP part, so that means naked 3dh...

[stef]

re 4: i wrote this blogpost https://www.ctrlc.hu/~stef/blog/posts/Running_around_with_an_OPAQUE_hammer.html and later i realised the answer to be SASL, for which i wrote a mech: https://github.com/stef/libopaque/tree/master/sasl and even a mod for nginx https://github.com/stef/ngx_http_auth_sasl_module/ (but then https is already tls based)

[stef]

can I use the session_key as-is for a bearer token for HTTPS requests? (This feels very wrong zipper_mouth_face)

you should use the session_key as an ephemeral HOTP shared secret and do HMAC(kdf(session_key,domain_seperator), counter++) as a bearer token.

[stef]

On the other hand, Can I use ID tokens, access tokens, or refresh tokens, or SAML assertions as a client_identity

if those tokens stay constant over the life-time of an account? if these tokens are not constant over the life-time of an account, but need to be stored for some time, then you might consider this approach https://ctrlc.hu/~stef/blog/posts/How_to_recover_static_secrets_using_OPAQUE.html

[chris-wood]

@afbase it seems like @stef helped address most of your questions. Are there still things you're unsure about?

[chris-wood]

Closing due to lack of activity. @afbase, please do re-open if you still have unanswered questions!