[Fwd: Re: XMPP auth: Proper action if a GSSAPI authentication request fails and more mechs are available]]

[Evan Schoenberg]

FYI.

Summary of below conversation:

SASL authentication for XMPP should (in the sense of SHOULD) respond  
to a not-authorized message by trying the next mechanism down the line  
rather than bailing out with an incorrect password message.

-Evan

Begin forwarded message:

> From: Peter Saint-Andre <stpeter at stpeter.im>
> Date: March 25, 2008 9:32:49 AM EDT
> To: Evan Schoenberg <evan at adiumx.com>
> Subject: [Fwd: Re:         [Fwd: Re: XMPP auth: Proper action if a  
> GSSAPI authentication request fails and more mechs are available]]
>
> A SASL expert speaks. :)
>
> I'll include some text about this in the next version of rfc3920bis.
>
> Peter
>
> -------- Original Message --------
> Date: Tue, 25 Mar 2008 12:02:51 +0000
> From: Alexey Melnikov <alexey.melnikov at isode.com>
> To: Peter Saint-Andre <stpeter at stpeter.im>
> Subject: Re:         [Fwd: Re: XMPP auth: Proper action if a GSSAPI
> authentication request fails and more mechs are available]
>
> Peter Saint-Andre wrote:
>
>> Hi Alexey, do you think the approach outlined below is sensible?
>>
>>
> Yes, this is very reasonable and some text needs to be added to the
> document.
>
> I would also suggest that you say that SASL mechanisms MUST be tried  
> in
> the order of their strength as perceived by the client (assuming the
> client has this information).
> I.e., if the server advertises "PLAIN DIGEST-MD5 GSSAPI" or "DIGEST- 
> MD5
> GSSAPI PLAIN", the client should try GSSAPI first, then DIGEST-MD5,  
> then
> PLAIN. The client should also be able to disallow some mechanisms  
> (e.g.
> PLAIN).
>
>> Peter
>>
>> -------- Original Message --------
>> Date: Mon, 24 Mar 2008 15:15:58 -0600
>> From: Peter Saint-Andre <stpeter at stpeter.im>
>> To: Evan Schoenberg <evan at adiumx.com>
>> Subject: Re: XMPP auth: Proper action if a GSSAPI authentication  
>> request
>> fails and more mechs are available
>>
>> Evan Schoenberg wrote:
>>
>>> On Mar 24, 2008, at 2:25 PM, Peter Saint-Andre wrote:
>>>
>>>> Evan Schoenberg wrote:
>>>>
>>>>> Peter,
>>>>>
>>>>> I've scoured the XEPs and can't come up with a definitive answer;
>>>>> perhaps I just missed something.  Is it allowable to respond to  
>>>>> a "not
>>>>> authorized" message from one auth mechanism by trying another?
>>>>> Specifically, I'm trying to cope with the situation in which  
>>>>> GSSAPI is
>>>>> enabled on the server and set to be the preferred auth  
>>>>> mechanism, the
>>>>> client is compiled such that it knows how to do GSSAPI auth, and  
>>>>> the
>>>>> client is not actually authorized to connect via GSSAPI but is
>>>>> authorized to connect via PLAIN or another password-based  
>>>>> mechanism.
>>>>>
>>>>> What do you think best practice is for the client when presented  
>>>>> with a
>>>>> GSSAPI 'not authorized' message?
>>>>>
>>>>>
>>>> Do you mean a change of SASL mechanism after a SASL failure, as  
>>>> here?
>>>>
>>>> http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-04.html#sasl-process-neg-failure
>>>>
>>>>
>>> Yes, precisely.  The text there sounds like one might reprompt for a
>>> password and retry the same mechanism... but is it acceptable to
>>> immediately proceed to another mechanism?
>>>
>> That is currently undefined.
>>
>> However, it seems to me that we might want to do this (as you outline
>> above):
>>
>> C: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
>>        mechanism='DIGEST-MD5'>=</auth>
>>
>> challenge + response etc.
>>
>> S: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
>>    <not-authorized/>
>>  </failure>
>>
>> C: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
>>        mechanism='PLAIN'/>
>>
>> Let me run this by my SASL friends for a sanity check.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20080327/1fa18cac/attachment.html>