[asterisk-dev] [Fwd: Re: [svn-commits] kpfleming: branch 1.4 r81442- /branches/1.4/channels/chan_sip.c]

[John Todd]

I hadn't thought of the last point Raj makes here, which is the core 
issue that I believe is of concern.  I agree that "403" is the 
appropriate answer for the second invalid request (though I don't 
have a problem with it being customizable for each peer between 
infinite 401 loops and a 403, as discussed in my prior message on 
this thread.)  Allowing a message to be customized as part of the 403 
reply would (should?) be passed along to the user on the screen of 
their SIP UA.  This could provide adequate information to the user 
about what the problem is with their credential data, and will 
hopefully satisfy the concerns about a 403 being mis-interpreted by 
the end user as something else.

Note: this also now re-opens the can of worms about information 
leakage if we do this in an incorrect manner.  If we accept an INVITE 
with a correct "user" but an incorrect authentication, we should NOT 
have a different response from how a reply is given for an incorrect 
user and an incorrect authentication, otherwise it is possible for a 
malicious third party to start to guess usernames by brute-forcing 
random invalid usernames in INVITEs and examining the responses.

JT



At 10:43 AM -0400 2007/9/8, Raj Jain wrote:
>
>I'm assuming that the discussion below is about how to reject an INVITE that
>contains a digest response to a previous challenge and the response is not
>acceptable to Asterisk i.e. the following scenario:
>
>    UAC        Asterisk
>     |             |
>     |-- INVITE -->|
>     |<--- 401 ----|
>     |---- ACK --->|
>     |-- INVITE -->|
>     |<--- ??? ----|   <== What response code to use here?
>     |---- ACK --->|
>
>
>The reason I stated this assumption is because, clearly the initial INVITE
>that does not carry a digest response in it but needs to be authenticated
>will have to be rejected with a 401 (so the UAC knows that it has to present
>its credentials). So, the question would be that once the Asterisk knows
>that a UAC does not have the right credentials then how to prevent the UAC
>from going into an INVITE-401 loop. I'm pretty sure that's the question that
>was asked (just wanted to confirm this for my own understanding).
>
>The interesting thing about this question is that according to RFC 3261
>(section 8.2.7), a UAS processes an INVITE-401 completely stateless fashion
>(even a transaction state is not maintained). This is a security feature to
>prevent DoS attacks on the UAS. So, in RFC 3261's opinion if a UAC goes into
>an INVITE-401 infinite then that loop is fine. They solved the problem by
>making the UAS stateless. 
>
>That said, there are a couple of things that can be done in Asterisk to
>solve this problem (I'm getting into implementation details, which have
>probably already been addressed in the branch in the email's subject line).
>First, the back-to-back INVITE-401 failures can be tracked in
>sip_user/sip_peer structs and that state can be used to reject the 2nd
>INVITE with a 403. The second option is that we know that whether an INVITE
>carries our nonce in it or not. If it does but the password doesn't match
>then the INVITE can be rejected with a 403. These behaviors should obviously
>be configurable and turned-off by default.
>
>I'd agree that 403 is the most appropriate response code in this case. If we
>want to send back some extra piece of information to the UAC's human user,
>then we can use reason phrase for that (e.g. "403 Invalid Credentials").
>
>Thanks,
>Raj
>
>
>
>>  -----Original Message-----
>>  From: asterisk-dev-bounces at lists.digium.com
>>  [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of
>>  Kevin P. Fleming
>>  Sent: Thursday, September 06, 2007 5:51 PM
>>  To: Asterisk Developers Mailing List
>>  Subject: [asterisk-dev] [Fwd: Re: [svn-commits] kpfleming:
>>  branch 1.4 r81442- /branches/1.4/channels/chan_sip.c]
>>
>>  Olle and I have been having a conversation regarding this
>>  commit, and I'd like to solicit comments from the community
>  > on whether they feel we should add back in the 'send 401
>  > forever and ever and ever' behavior with a configuration
>  > option (defaulting to off), and if so, what should the name
>>  of that option be?
>>
>>  > Olle E Johansson wrote:
>>
>>  The RFC says
>>
>>  "21.4.4 403 Forbidden
>>  The server understood the request, but is refusing to fulfill it.
>>  Authorization will not help, and the request SHOULD NOT be repeated."
>>
>>  In this case, proper authorization will help. If we send 403,
>>  we're telling the phone to stop trying sending INVITE to us
>>  regardless of authorization, time of day, phase of the moon
>>  and amount of youtube traffic in your network. That's not
>>  really what you want.
>>
>>  In another part of the RFC, it actually states another use
>>  for an INVITE scenario. If the callee refuses to answer, like
>>  pressing the red button on your cell phone, the RFC
>>  recommends sending 403. I believe that's a big contradicting,
>>  but - hey - we're talking about the SIP rfc
>>  :-) (or they might hint that this is a good way of adding a
>>  caller, ex- girlfriend, to a blacklist)...
>>
>>  But I agree, with a configuration option, we can send 403 to
>>  stop unneeded traffic. The phone needs a reconfiguration, so
>>  we might as well tell it to go away until it has sorted out
>>  it's life and approach us with a new, propably rebooted, attitude.
>>
>>  Cheers,
>>  /O
>>
>>  --
>>  Kevin P. Fleming
>>  Director of Software Technologies
>  > Digium, Inc. - "The Genuine Asterisk Experience" (TM)
>>