9 Nov
2007
9 Nov
'07
3:13 p.m.
At 08:35 09/11/2007, Klaus Darilion wrote:
Tomasz Zieleniewski schrieb:
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
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. regards
klaus
--
Jiri Kuthan http://iptel.org/~jiri/
Waiting for any feedback.
Regards
Tomasz
On Nov 8, 2007 4:51 PM, Piotr Grabowski <pgrabowski(a)gmail.com> wrote:
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers 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(a)gmail.com>om>:
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers