On 01/31/2007 8:45 AM, Peter Saint-Andre wrote: > Matthias Wimmer wrote: >> Peter Saint-Andre schrieb: >>> <aborted/> >>> <incorrect-encoding/> >>> <invalid-authzid/> >>> <invalid-mechanism/> >>> <mechanism-too-weak/> >>> <not-authorized/> >>> <temporary-auth-failure/> >>> >>> If we need more error conditions, we can define them in the next >>> version of the spec. >> >> I've had a look at man sasl_errors (from cyrus SASL) to check if all >> Cyrus errors map well on the above errors. >> >> The following errors have been interesting: >> >> - SASL_TRANS: One time use of plaintext password will enable requested >> mechanism for user. >> >> I think it would be interesting to have such a XMPP-SASL error >> condition as well. It's required if you have hashed passwords (e.g. >> salted SHA-1) on the server and need to get the plain password to >> verify them, and build a hash suitable to authenticate with DIGEST-MD5 >> the next time (DIGEST-MD5 as an example). > > Ah, I hadn't thought of that use case. :-) > >> - SASL_EXPIRED: Passphrase expired, must be reset. >> >> - SASL_DISABLED: Account disabled >> >> - SASL_NOVERIFY: User exists, but no verifier for user > > How much of that do we want to expose to the end user (or, perhaps, some > bot maquerading as the user)?
I have added the following SASL error conditions to rfc3920bis: <account-disabled/> (maps to SASL_DISABLED) <credentials-expired/> (maps to SASL_EXPIRED) <encryption-required/> (maps to SASL_ENCRYPT) <transition-needed/> (maps to SASL_TRANS) It's not clear to me what SASL_NOVERIFY means, and I worry about exposing the fact that the user exists (directory harvest attacks) so I have not yet added a SASL error condition for that. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
