[Serusers] proxy_authorize and radius_proxy_authorize doesn't work for ACK

[Jiri Kuthan]

At 08:35 09/11/2007, Klaus Darilion wrote:


>Tomasz Zieleniewski schrieb:
>> Hi Piotr:)
>> 
>> RFC only implies that proxy should not challenge the ACK message and
>> moreover it says that client sending ACK should duplicate
>> Authorization and Proxy-Authorization headers. This it what my client
>> does. But according to the description of the proxy_authorize function
>> it only verifies that credentials are valid. This function doesn't
>> cause the challenge response to be sent to the client. This is
>> performed with the usage of proxy_challenge function.
>> "The function verifies credentials according to RFC2617. If the
>> credentials are verified successfully then the function will succeed
>> and mark the credentials as authorized (marked credentials can be
>> later used by some other functions). If the function was unable to
>> verify the credentials for some reason then it will fail and the
>> script should call proxy_challenge  which will challenge the user
>> again."
>> In my opinion, that is why proxy_authorize function should generate
>> the uid avp for ACK request if verification of credential gives
>> positive result.
>
>
>Authentication of ACK and CANCEL is very difficult.
>
>>>   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
>
>As the nonce has only a certain lifetime, which could be expired between 
>receiving the INVITE and ACK, the SIP proxy would have to be dialog 
>stateful and remember the nonce of the INVITE. As ser is not dialog 
>stateful you can not authenticate ACKs.

You are right, we can't authenticate, but we could (which was the initial question) keep uid
for authenticated transaction (and we actually do, I'm just not sure how to
acceess it from within ACK processing). Anyhow, I'm not sure we need that
at all.

-jiri


>regards
>klaus
>
>
>> Waiting for any feedback.
>> Regards
>> Tomasz
>> 
>> On Nov 8, 2007 4:51 PM, Piotr Grabowski <pgrabowski at gmail.com> wrote:
>>> Hi Tomek,
>>> I think this is your answer ;) :
>>>
>>> RFC 3261 22.1
>>>
>>> While a server can legitimately challenge most SIP requests, there
>>>   are two requests defined by this document that require special
>>>   handling for authentication: ACK and CANCEL.
>>>   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.
>>>
>>> --
>>> PG
>>>
>>>
>>> 2007/11/8, Tomasz Zieleniewski <tzieleniewski at gmail.com>:
>>>
>>>> Hi,
>>>>
>>>> When I invoke proxy_authorize and radius_proxy_authorize for an ACK
>>>> message the is no uid avp present.
>>>> All other messages which are authorized work fine.
>>>> Why is that so??
>>>> Is it the right behaviour??
>>>>
>>>> Bests regards
>>>> Tomasz
>>>>
>>> _______________________________________________
>>> Serusers mailing list
>>> Serusers at lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>
>> _______________________________________________
>> Serusers mailing list
>> Serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>_______________________________________________
>Serusers mailing list
>Serusers at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers



--
Jiri Kuthan            http://iptel.org/~jiri/