[asterisk-dev] [Code Review] Don't re-auth subscriptions that are just re-transmissions (not re-subscriptions)

[reviewboard at asterisk.org]

> On 2010-11-09 12:33:45, Olle E Johansson wrote:
> > I think it's very dangerous to disable the verification of the auth. There has to be another way of fixing this. The retransmit should hit the same dialog and we still have the nonce. Why does the auth fail?
> 
> David Vossel wrote:
>     The auth fails because the nonce can only be responded to once...  When a retransmission comes in check_auth() sees that the nonce has already been responded to and issues a new challenge. I don't think this is correct behavior.  In the case of a retransmit the current nonce probably shouldn't be treated as a stale nonce.
> 
> Terry Wilson wrote:
>     We do the same thing in handle_request_invite.
>     
>         if (!p->lastinvite && !ast_test_flag(req, SIP_PKT_IGNORE) && !p->owner) {
>             /* This is a new invite */
>             /* Handle authentication if this is our first invite */
>             res = check_user(p, req, SIP_INVITE, e, XMIT_RELIABLE, sin);
>     
>     It is only disabling verification for retransmissions (unless I have messed up somewhere) and I checked that retransmissions that weren't authed aren't accepted. 
>     
>     It fails the verification with "Duplicate authentication received from ..." because the auth request has already been responded to and we treat the nonce as stale. We then re-generate a 401, which is what breaks the polycom implementation.
> 
> Klaus Darilion wrote:
>     I agree disabling authentication sounds weird. The problem is on the transaction layer and thus the only clean solution would be to add a transaction layer - and all these problems will disappear.

Then I think we should fix the way we handle all retransmission of an authenticated message, regardless of type. We should not bypass verification of the auth at all. If we do, we need to consider if that's a security issue.


- Olle E


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1005/#review2897
-----------------------------------------------------------


On 2010-11-09 12:21:48, Terry Wilson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1005/
> -----------------------------------------------------------
> 
> (Updated 2010-11-09 12:21:48)
> 
> 
> Review request for Asterisk Developers and David Vossel.
> 
> 
> Summary
> -------
> 
> From the issue:
> 0018075: Asterisk fails to recognize SUBSCRIBE retransmissions and tries to re-authenticate them, which breaks presence on polycom phones
> Description	 Here's what happens from asterisk point of view:
> -> SUBSCRIBE
> <- 401 Unauthorized
> -> SUBSCRIBE with auth
> <- 200 OK (lost)
> <- NOTIFY
> -> 200 OK for NOTIFY
> -> SUBSCRIBE with auth retransmission
> <- 401 Unauthorized
> At this point polycom phone received 2 "401 Unauthorized" in a row and it completely gives up on resubscribing to this hint until reboot. While polycom behavior is questionable, I believe asterisk should recognize retransmission and resubmit 200OK in this case
> 
> 
> This addresses bug 18075.
>     https://issues.asterisk.org/view.php?id=18075
> 
> 
> Diffs
> -----
> 
>   /branches/1.4/channels/chan_sip.c 294120 
> 
> Diff: https://reviewboard.asterisk.org/r/1005/diff
> 
> 
> Testing
> -------
> 
> I created a sipp scenario mimicking the issue, it now re-sends a 200 OK when an authed retransmission occurs. I also tested a scenario that sent a retransmission without authentication to ensure that we didn't accept un-authed retransmissions.
> 
> 
> Thanks,
> 
> Terry
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20101109/7881d7c2/attachment-0001.htm