dequbed/draft-reitzenstein-auth-opaque

draft-reitzenstein-auth-opaque's Issues

registration issue

The OPAQUE RFC only specifies the 4 step password-privacy-protecting registration procedure, which does not apply to how SASL (and i assume also gss-api) creates new/registers users. With SASL new users are usually added on the server by using a tool like saslpasswd2 which creates the accounts for all SASL supported mechanisms, and thus the users password is exposed to the server. On one hand this violates one of OPAQUEs security guarantees, never exposing the password to the server, but on the other hand it enables the server to enforce password quality rules.

Usage of Channel Binding

Moving this issue to not derail the original one:

Channel binding is about binding an authentication to an underlying encrypted channel like TLS and thus making sure that both sides see the same channel. That's very much not something that OPAQUE gives you implicitly.

ok, it might seem a dumb question, but it's genuine. what does it matter if a channel is encrypted or not, if the goal is to make sure that both sides see the same channel? and if the two parties can authenticate each other (which they do) then presuming that the ephemeral keys are indeed only used once, the authentication is bound to that tcp connection - limiting here to tcp like transports makes sense i hope, with udp this might not work. so i think opaque does indeed bind to a channel implicitly, and i think the fact of it being encrypted does not matter, as long as the channel is tcp-like connection-based.

Originally posted by @stef in cfrg/draft-irtf-cfrg-opaque#375 (comment)

Integrity protecting the authentication exchange

Link to the upstream issue required for this so I don't lose it: cfrg/draft-irtf-cfrg-opaque#375