DIGEST-MD5 authzid question

[Matthias Wimmer]

Remko Tronçon schrieb:
>> I would guess that it's to avoid the case where a server
>> implementation always rejects any request for an authzid.
> 
> Well, I have this problem with an XMPP server, but in XMPP, the
> authzid for a user is different from its authid, so the check doesn't
> help. Luckily, an authzid in XMPP can never be used as an authid, so
> we don't have a problem with the equality check.

But it matters on the server-side of an XMPP implementation.

In the DIGEST-MD5 server implementation does set the authorization id to 
the authentication id, if no or an empty authorization id has been sent 
by the client. This does not match what is needed by XMPP.

Let me show an example:

User sends: authid=mawis, realm=example.com, no authzid
With XMPP this means: client wants to authorize as "mawis at example.com"
But Cyrus passes to the application: client wants to authorize as "mawis"

The problem here is that in XMPP "mawis" is a valid (but different!) 
authorization id as well.

So in the context of XMPP the following two things are different:

authid=example.com, realm=example.com, no authzid
authid=example.com, realm=example.com, authzid=example.com

... but Cyrus passes the same authzid to the application for both cases.

Cyrus SASL really seems to be broken here, as RFC 4422, section 3.4.1 
states that for an absent or empty authorization identity string the 
authorization id is the one, that the server associates with the 
client's credentials. This isn't something a SASL library can do by just 
copying the authentication id.


Tot kijk
     Matthias

-- 
Matthias Wimmer      Fon +49-700 77 00 77 70
Züricher Str. 243    Fax +49-89 95 89 91 56
81476 München        http://ma.tthias.eu/