LDAP - problem with Authen-SASL & DIGEST-MD5

Author

problem with Authen-SASL & DIGEST-MD5

Jürgen Herz

2006-09-01, 7:05 pm

Hi,

I was testing Authen-SASL's DIGEST-MD5 mechanism in a script (Net::POP3)
but it failed. Server was Dovecot 0.99.14.

In order to find out which side is guilty, I used the SASL module in a
Net::SMTP script and tried with postfix server: login succeeded with
DIGEST-MD5.
Though I was pretty sure now, Dovecot is the one to blame, today I
tested POP3 retrieval with KMail 1.9 and latest Dovecot (1.0rc7) using
DIGEST-MD5 - and succeeded. KMail also worked with Dovecot 0.99.14.
But Net::POP3 still doesn't with either Dovecot version (note, CRAM-MD5
works, so password in is ok in general).

All in all I'm as far as at the beginning.

Dovecot 0.99 additionally gave the hint "Missing nonce parameter", but
looking at the logs I doubt that's correct.

Server Challenge was (here decoded)
realm="",nonce="S5hbmt7qeaQYOS/OLKOsYg==",qop="auth",charset="utf-8",
algorithm="md5-sess"

And client response (here decoded)
authzid="juergen",charset=utf-8,cnonce="7c1c927e756c9067dbf412c964a823c1",
digest-uri="pop/pico",nc=00000001,nonce="S5hbmt7qeaQYOS/OLKOsYg==",
qop=auth,realm="" ,response=fed55b47609e097fdf7d145635e845
ff,username="juergen"

So, what to do to find out what's wrong?

Regards,
Jürgen

Achim Grolms

2006-09-01, 7:05 pm

On Friday 01 September 2006 16:47, J=FCrgen Herz wrote:

> So, what to do to find out what's wrong?

Does the problem happen with Net::POP3 2.28
or with Net::POP3 2.28_2 ?

(I want to ensure that the changes=20
that made 2.28_2 are not the problem.).

You can use ->debug(1) method of a Net::POP3 object
to get debug output of POP3-communication.
Can you send debug-output if that kind?

Achim

Achim Grolms

2006-09-01, 7:05 pm

On Friday 01 September 2006 19:30, Achim Grolms wrote:
> On Friday 01 September 2006 16:47, J=FCrgen Herz wrote:
>
> Does the problem happen with Net::POP3 2.28
> or with Net::POP3 2.28_2 ?
>
> (I want to ensure that the changes
> that made 2.28_2 are not the problem.).

As i can see from Authen::SASL:Perl::DIGEST_MD5
code the servicename is part of authentication, too:

'digest-uri' =3D> $self->service . '/' . $self->host,

Can you please check if the change of servicename ('pop3' vs 'pop') causes =
the=20
problem? (I can not test DIGEST-MD5 here).

Thanky you,
Achim

Jürgen Herz

2006-09-01, 7:05 pm

Achim Grolms wrote:

I checked with both versions, but they're no different.
[color=darkred]
> You can use ->debug(1) method of a Net::POP3 object
> to get debug output of POP3-communication.
> Can you send debug-output if that kind?

Sure, but that's not really more than I already posted:

Net::POP3>>> Net::POP3(2.28)
Net::POP3>>> Net::Cmd(2.26)
Net::POP3>>> Exporter(5.58)
Net::POP3>>> IO::Socket::INET(1.29)
Net::POP3>>> IO::Socket(1.29)
Net::POP3>>> IO::Handle(1.25)
Net::POP3=GLOB(0x1019fff0)<<< +OK Dovecot ready.
Net::POP3=GLOB(0x1019fff0)>>> CAPA
Net::POP3=GLOB(0x1019fff0)<<< +OK
Net::POP3=GLOB(0x1019fff0)>>> AUTH DIGEST-MD5
Net::POP3=GLOB(0x1019fff0)<<< +
cmVhbG09IiIsbm9uY2U9ImtZUk1Ga1hDalRVVkxM
cjFET2FiYUE9PSIscW9wPSJhdXRoIixjaGFyc2V0
PSJ1dGYtOCIsYWxnb3JpdGhtPSJtZDUtc2VzcyI=

Net::POP3=GLOB(0x1019fff0)>>>
YXV0aHppZD0ianVlcmdlbiIsY2hhcnNldD11dGYt
OCxjbm9uY2U9IjU5MGRmMjU4M2YxY2MwNDFjOTUz
ZDZhNDY4NWNlZTVkIixkaWdlc3QtdXJpPSJwb3Az
L3BpY28iLG5jPTAwMDAwMDAxLG5vbmNlPSJrWVJN
RmtYQ2pUVVZMTHIxRE9hYmFBPT0iLHFvcD1hdXRo
LHJlYWxtPSIiLHJlc3BvbnNlPWE3MGUwOGRiNWMy
ZGM5OTIzOGI3OWE
5YWNlNjc1YmQ5LHVzZXJuYW1lPSJqdWVyZ2VuIg=
=
Net::POP3=GLOB(0x1019fff0)<<< -ERR Authentication failed.
Net::POP3=GLOB(0x1019fff0)>>> QUIT
Net::POP3=GLOB(0x1019fff0)<<< +OK Logging out

Ciao,
Jürgen

Achim Grolms

2006-09-03, 8:02 am

On Friday 01 September 2006 16:47, J=FCrgen Herz wrote:

> And client response (here decoded)
> authzid=3D"juergen",charset=3Dutf-8,cnonce=3D"7c1c927e756c9067dbf412c964a=
823c1",
> digest-uri=3D"pop/pico",nc=3D00000001,nonce=3D"S5hbmt7qeaQYOS/OLKOsYg=3D=
=3D",
> qop=3Dauth,realm=3D"" ,response=3Dfed55b47609e097fdf7d145635e8
45ff,usernam=
e=3D"juerg
>en"

After beeing in contact with J=FCrgen by private Mail
we know now the 'authzid' is the problem because the pop3-serverside does n=
ot=20
support it.
=46rom my point of view (and RFC-2831) authzid is optional.
authzid is needed in case of the Authentication ID (username) differs
from the Authorization ID (authzid).
In case both are equal there is no need to send authzid.
More worse - authzid should not be sent because that breaks authentication
(For example in J=FCrgens case, Dovecot on serverside not supporting authzi=
d).

=46rom my point of view Authen::SASL::Perl::DIGEST_MD5 should be changed to

send authzid only in case of authzid ne username.

What do you think?

Achim

Achim Grolms

2006-09-03, 7:03 pm

On Sunday 03 September 2006 15:23, Achim Grolms wrote:
> On Friday 01 September 2006 16:47, J=FCrgen Herz wrote:
4a823c1"[color=darkred]
=3D=3D",[color=darkred]
ame=3D"jue[color=darkred]
>
> After beeing in contact with J=FCrgen by private Mail
> we know now the 'authzid' is the problem because the pop3-serverside does
> not support it.
> From my point of view (and RFC-2831) authzid is optional.
> authzid is needed in case of the Authentication ID (username) differs
> from the Authorization ID (authzid).
> In case both are equal there is no need to send authzid.
> More worse - authzid should not be sent because that breaks authentication
> (For example in J=FCrgens case, Dovecot on serverside not supporting
> authzid).
>
> From my point of view Authen::SASL::Perl::DIGEST_MD5 should be changed to
>
> send authzid only in case of authzid ne username.

I was wrong, not Authen::SASL::Perl::DIGEST_MD5 is the problem,
Net::POP3 caused the problem.

The code in Net::POP3 is this

$sasl =3D Authen::SASL->new(mechanism=3D> $mechanisms,
callback =3D> { user =3D> $username,
pass =3D> $password,
authname =3D> $username,
});

and should be

$sasl =3D Authen::SASL->new(mechanism=3D> $mechanisms,
callback =3D> { user =3D> $username,
pass =3D> $password,
});

because it is not usefull to set authzid ti the same value as username.

What do you think?

Achim

Graham Barr

2006-09-03, 7:03 pm

On Sep 3, 2006, at 4:48 PM, Achim Grolms wrote:
> I was wrong, not Authen::SASL::Perl::DIGEST_MD5 is the problem,
> Net::POP3 caused the problem.
>
> The code in Net::POP3 is this
>
>
> $sasl = Authen::SASL->new(mechanism=> $mechanisms,
> callback => { user => $username,
> pass => $password,
> authname => $username,
> });
>
>
> and should be
>
> $sasl = Authen::SASL->new(mechanism=> $mechanisms,
> callback => { user => $username,
> pass => $password,
> });
>
>
> because it is not usefull to set authzid ti the same value as
> username.
>
> What do you think?

Hm, I forget the exact details but I seem to remember they were both
set because some servers were using user while others where using
authzid. I guess we will find out later which servers needed authzid :-)

Graham.

Achim Grolms

2006-09-03, 7:03 pm

On Monday 04 September 2006 00:52, Graham Barr wrote:

> Hm, I forget the exact details but I seem to remember they were both
> set because some servers were using user while others where using
> authzid. I guess we will find out later which servers needed authzid :-)

That means 2 kinds of broken software:

1. servers that need authzid and always fail if not present.
2. server that always fail if present.

What kind of broken software ist the common case?
(I think Net::POP3 should support that case and make the special case
make us of passing of $sasl objects to auth()

Achim

Sponsored Links