Cyrus-SASL 2.1.22 DIGEST-MD5 and RFC2831

[Alexey Melnikov]

Andreas Winkelmann wrote:

>On Monday 29 January 2007 15:59, Alexey Melnikov wrote:
>
>Thanks for the answer.
>  
>
>>>In another list someone shows an Error-Message from the digest-md5 Plugin:
>>>
>>>"xxx: realm changed: authentication aborted".
>>>      
>>>
>>I would like to get more information on this error. This error message
>>is a good indicator that the client is broken.
>>    
>>
>*Shall happen with Outlook 2007 and something which is called "40tude".* I've 
>none of them. Maybe someone else can test this?
>  
>
>>>This happens if the Realm (Server->Client) in Step 1 is diffrent from the
>>>Realm (Client->Server) in Step 2.
>>>
>>>In RFC 2831 the Description of the Realm out of Step 2 is described as:
>>>
>>>  realm
>>>     The realm containing the user's account. This directive is
>>>     required if the server provided any realms in the
>>>     "digest-challenge", in which case it may appear exactly once and
>>>     its value SHOULD be one of those realms. If the directive is
>>>     missing, "realm-value" will set to the empty string when computing
>>>     A1 (see below for details).
>>>
>>>The Value in Step 2 "SHOULD" be one of the Values passed in Step 1.
>>>The "SHOULD" is realized as a "MUST" in Cyrus-SASL. Is this really ok or
>>>is this something which should better be changed?
>>>      
>>>
>>Here is some background for why the SHOULD is used in the text you
>>quoted: The server can support one or more realms, but it might not
>>advertise some of them (i.e. not send them to the client). The client
>>can pick one of the realms sent by the server or it can pick something
>>else if it specifically configured to do so. That "something else" still
>>has to be accepted by the server.
>>    
>>
>Yes, and I think there does Cyrus-SASL something different.
>  
>
Hi Andreas,
 From your response it is not clear where you think the problem might 
be, so I will just comment on the actual code below.

>Out of the Sourcecode from step2 (plugins/digestmd5.c):
>
>...
>realm is the catched Realm from step 2, text->realm the one from step 1.
>...
>
>    /* Sanity check the parameters */
>    if (realm == NULL) {
>
>... Realm is "something else" and not empty, so we can skip this...
>  
>
According to RFC 2831, if the client didn't send any realm, it is the 
same as if the client sent 'realm=""'.
So if the server doesn't use empty string as the realm (and Cyrus SASL 
never does), then the client is broken.

>    /* CLAIM: realm is not NULL below */
>    } else if ((strcmp(realm, text->realm) != 0) &&
>        (text->realm[0] != 0)) {
>  
>
Client has sent a realm that the server didn't advertise ==> fail

Note that in practice text->realm (the realm advertised by the server) 
is never empty.

>        SETERROR(sparams->utils,
>                 "realm changed: authentication aborted");
>        result = SASL_BADAUTH;
>        goto FreeAllMem;
>    }
>
>This is an easy strcmp between the Realm in step1 and the Realm from step2. If 
>both are different, it jumps out with SASL_BADAUTH. 
>  
>
Yes, because the client didn't use one of the realms the server sent to it.

>If I see this correct and the Realm is "something else", it fails. Maybe I'm 
>wrong. Please correct me if I write nonsense.
>  
>
>>Cyrus SASL server never "hides" any of the realms it supports, so the
>>client must pick one of the ones sent by the server. So I think the
>>current coded behavior is correct.
>>    
>>