RE: [reSIProcate] Authentication+Authorization bugs

["Scott Godin" <slgodin@xxxxxxxxxxxx>]

OK – I’ve just finished re-writing the way ACK handling works.  The authorization headers are now correctly added.

 

Thanks,

 

Scott

 

---

From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Godin
Sent: Tuesday, October 11, 2005 11:47 AM
To: Meir Elberg; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] Authentication+Authorization bugs

 

I’ve modified ServerAuthManager to not challenge ACKs or CANCELs – still looking into the 2^nd issue.  : )

 

---

From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Meir Elberg
Sent: Sunday, October 09, 2005 11:14 AM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate] Authentication+Authorization bugs

 

Hi,

I found a bug in DUM:

ServerAuthManager tries challenging ACK requests.
Another problem is that Proxy-Authorization header isn't sent within ACK requests as it should.

According to the RFC:

   Under an authentication scheme that uses responses to carry values

   used to compute nonces (such as Digest), some problems come up for

   any requests that take no response, including ACK.  For this reason,

   any credentials in the INVITE that were accepted by a server MUST be

   accepted by that server for the ACK.  UACs creating an ACK message

   will duplicate all of the Authorization and Proxy-Authorization

   header field values that appeared in the INVITE to which the ACK

   corresponds.  Servers MUST NOT attempt to challenge an ACK.

I'll try to resolve the bug but I'm sure you'll do it faster and better than me...

Thanks,
Elberg Meir.