[Standards] [Fwd: Re: jingle client authentication error in jabber server]
stpeter at stpeter.im
Fri May 30 15:56:00 UTC 2008
On 01/31/2007 8:45 AM, Peter Saint-Andre wrote:
> Matthias Wimmer wrote:
>> Peter Saint-Andre schrieb:
>>> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards