search

dequbed / draft-reitzenstein-auth-opaque

Other
0 stars 0 forks source link

registration issue #3

Open stef opened 1 year ago

stef commented 1 year ago

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.

dequbed commented 1 year ago

The SASL protocol does not concern itself with matter of registration and password changes. It's also not a new topic, SCRAM has the same issue. Registration/Password Changes has always been responsibility of the higher level protocol or server software.

I would absolutely love the ability of safe registration in SASL, but sadly we don't have that at the moment. SASL2 as is proposed for use in XMPP has some ideas for solutions regarding that.

If something like SASL2 becomes a thing I'll glady add features regarding that to this specification or a new draft.

stef commented 1 year ago

i think this deserves a mention in the security considerations at least

dequbed commented 1 year ago

i think this deserves a mention in the security considerations at least

That's a fair point. I will add it to the security considerations.

Additionally after some further discussion with Thilo Molitor it's sensible to add a specified encoding for registration messages because he does have a XEP in the works that could make sensible use of this.

stef commented 1 year ago

yay.

i was also thinking, that OPAQUE as a protocol specifies both, registration and ake. if sasl only does the ake, is it still opaque? maybe it would be better to refer to a partial opaque protocol then.

dequbed commented 1 year ago

i was also thinking, that OPAQUE as a protocol specifies both, registration and ake. if sasl only does the ake, is it still opaque? maybe it would be better to refer to a partial opaque protocol then.

The OPAQUE draft calls OPAQUE "a secure asymmetric password-authenticated key exchange [protocol]". My draft is titled "A […] Mechanism using the asymmetric password-authenticated key agreement OPAQUE" so no, the name is very much appropiate as the core feature of OPAQUE is the aPAKE, which is also the part that the mechanism is using.

stef commented 1 year ago

the setup phase very much part of the protocol. but yeah, your title is more nuanced, but only for people reading very closely.