linphone-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-users] Some info about Digest Auth


From: Dermot McGahon
Subject: Re: [Linphone-users] Some info about Digest Auth
Date: Sun, 23 Apr 2006 12:10:47 -0000
User-agent: Opera M2/7.54 (Win32, build 3929)

Hi Aymeric,

I've been through the specs and the code and to be honest the
code looks good except for one small thing.

In this case, it is the server that insists on digest authentication.
When linphonec tries to register it gets back MISSING PASSWORD with
an auth header specifying to use qop=auth. The digest auth RFC says
that qop/nc/cnonce are optional for backwards compatibility reasons
with older servers but the SIP RFC says that if a server sends a qop
directive then the client must return qop/nc/cnonce.

The response generating code in exosip looks good to me for qop =
auth-int but I don't think it should be applying the auth-int algorithm
when the qop=auth. This is a minor thing as this code isn't compiled
in now anyway and there is a comment that something like auth1 would
be handled incorrectly.

My last test was to hardcode in some values for nc/cnonce and set
those readers in the second REGISTER request. This was to copy as
closely as possible the headers in the successful REGISTER from
the Grandstream phone. But it didn't work and instead of sending
back Forbidden the server just didn't respond at all. It might be
because the code was sending retries with the same nonce count over
and over which would look to the server exactly like the kind of
security violation that the nonce count is supposed to prevent.

So I don't really know what's happening. I have no insight into
what the server is doing. Your code looks good, it just needs some
small changes as you say, so I'll play around a bit more and see
what happens.

Thanks for the response.


Dermot.
--


On Sat, 22 Apr 2006 16:17:30 +0200 (CEST), Aymeric Moizard <address@hidden> wrote:


I've already tested the qop support with nonce count with osip/exosip
and it worked (in eXosip2) at least for one transaction with minor
change in exosip2. A few code should be written to make it really work.
(check the previous nonce count and reuse it for next header: really
simple if I remember!

however, exosip does not announe support for qop to server, thus there
is no reason a server would refuse its authentication!?

Tks
Aymeric

On Sat, 22 Apr 2006, Simon Morlat wrote:

Hi,

Thanks for this additional information.
I've asked Aymeric Moizard, author of libosip and exosip his point of view
about this problem.

Simon

Le Vendredi 21 Avril 2006 17:06, Dermot McGahon a écrit :
Hi Simon,

I've been looking into why Digest Auth isn't working when registering
to a Tadiran PABX, here's what I've found out so far.

RFC 2617 says that qop "SHOULD be used if the server indicated that qop
is supported by providing a qop directive in the WWW-Authenticate header field". And that if qop is sent, cnonce and nonce-count MUST be sent with
it.

The PABX seems to be requiring auth with qop=auth and cnonce/nonce-count
returned.

It would probably be good practice nonetheless to include these in auth
responses?

jauth.c/eXosip_create_authorization_header() sets CNonce to NULL but does
pass Qop and NonceCount into the digest calculation.

DigestCalcResponse() has some code that used these for qop=auth-int, and it looks wrong that it also applies this to qop=auth. But anyway, I don't
think any of that code is compiled in at present.

libosip seems to have enough support for adding qop/cnonce/nc to the
response header but I'm not sure how to go about choosing a valid value
for cnonce.

I'm not really sure how to proceed. What do others know about this?


Dermot.
--


_______________________________________________
Linphone-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/linphone-users


_______________________________________________
Linphone-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/linphone-users








reply via email to

[Prev in Thread] Current Thread [Next in Thread]