[Home]

Summary:ASTERISK-02866: [patch] Re-use registration credentials
Reporter:Olle Johansson (oej)Labels:
Date Opened:2004-11-21 14:45:55.000-0600Date Closed:2008-01-15 15:18:57.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) sipregister.txt
Description:This patch makes asterisk re-use authentication credentials when re-registering to another SIP proxy.

According to the RFC 3261, we are recommended to re-use the same credentials as long as we have the same call ID.

****** ADDITIONAL INFORMATION ******

Disclaimer on file

The patch corrects an error in signalling according to the RFC recommendation. I recommend applying it to both CVS head and stable.
-----------------------------------
* From RFC3261, section 22.3:

"If a UA receives a Proxy-Authenticate header field value in a 401/407 response to a request with a particular
Call-ID, it should incorporate credentials for that realm in all subsequent requests that contain the same Call-
ID. These credentials MUST NOT be cached across dialogs; however, if a UA is configured with the realm of
its local outbound proxy, when one exists, then the UA MAY cache credentials for that realm across dialogs."
Comments:By: Olle Johansson (oej) 2004-11-21 14:58:09.000-0600

This is the patch known as the "Broadvoice" patch. However, it is not specific to a certain provider or vendor of SIP servers or phones. It makes Asterisk send less packets for re-registration with a SIP proxy.
By: khb (khb) 2004-11-22 13:37:52.000-0600

Looking at this patch I have several remarks:

(I) In reply_digest() the retained digest data is always stored into the registry.
However, reply_digest is not only called for registration purposes but also for other methods. Therefore the data needs to be saved from somewhere else rather than reply_digest.
The digest parsing and the digest building functions should really be kept separate and not the way this is intermingled right now.

(II) When you are re-using a cached nonce you must update the nonce count in the new transaction.  This has been hardcoded to 1 sofar.

(III) When caching a nonce over some period of time you also must check if the server has sent a notification whether the nonce has become stale. The server decides how long it will accept cached nonces.  Therefore you must parse the stale="true/false" parameter in the server response.

(IV) the patch creates some kind of processing for response code 403 (Forbidden) and issues messages regarding failed authentication. This is wrong.
Return code 403 is NOT the proper response for failed authentication. It should be the 401 that is returned/checked for and Asterisk already does that.  403 would indicate that the call was rejected for some other reason even though the credentials may be correct.

I posted a different parsing module the other day for the fellow with the registration auth problems (still in testing I guess). If you start from that, which does all the parsing needed, it's not far to a correct solution.  That code was in use until some time ago so it should still be ok.

edited on: 11-22-04 13:52
By: Olle Johansson (oej) 2004-11-22 14:56:02.000-0600

khb: Feel free to update the patch, however I feel that the patch, even if not perfect, is a big step forward.

(I) I save the digest data ONLY if we have a registry, meaning only if reply_digest is called for an proxy registration.
(II) I'll check on the nonce count, thank you for the note. Where in all the RFCs can I find that info to learn more?
(III) Do you know any device that use this? I've never seen it.
(IIII) I'll check the 403.

Why don't you release your SIP code in full, so we can check if it's a good platform to continue from?
By: Olle Johansson (oej) 2004-11-22 15:01:57.000-0600

FOund this in RFC2617, for reference:
stale
    A flag, indicating that the previous request from the client was
    rejected because the nonce value was stale. If stale is TRUE
    (case-insensitive), the client may wish to simply retry the request
    with a new encrypted response, without reprompting the user for a
    new username and password. The server should only set stale to TRUE
    if it receives a request for which the nonce is invalid but with a
    valid digest for that nonce (indicating that the client knows the
    correct username/password). If stale is FALSE, or anything other
    than TRUE, or the stale directive is not present, the username
    and/or password are invalid, and new values must be obtained.
By: Olle Johansson (oej) 2004-11-22 15:06:41.000-0600

Also from RFC2617, for reference:
nonce-count
    This MUST be specified if a qop directive is sent (see above), and
    MUST NOT be specified if the server did not send a qop directive in
    the WWW-Authenticate header field.  The nc-value is the hexadecimal
    count of the number of requests (including the current request)
    that the client has sent with the nonce value in this request.  For
    example, in the first request sent in response to a given nonce
    value, the client sends "nc=00000001".  The purpose of this
    directive is to allow the server to detect request replays by
    maintaining its own copy of this count - if the same nc-value is
    seen twice, then the request is a replay.   See the description
    below of the construction of the request-digest value.

KHB: Do you have code for a proper QoP, to replace the hack in chan_sip?
By: Olle Johansson (oej) 2004-11-22 15:29:28.000-0600

khb: What should we send if we get a Digest Auth and it is not working, IE,
bad password or anything else wrong?

Seems like some providers send 403 when we have a bad password.

401/407 is only used if we have *no* auth header, not when the auth is wrong - or?
By: Olle Johansson (oej) 2004-11-22 15:32:00.000-0600

RFC 3261:
Finally, note that even if a UAC can locate credentials that are associated with the proper realm, the potential
exists that these credentials may no longer be valid or that the challenging server will not accept these
credentials for whatever reason (especially when “anonymous” with no password is submitted). In this
instance a server may repeat its challenge, or it may respond with a 403 Forbidden. A UAC MUST NOT
re-attempt requests with the credentials that have just been rejected (though the request may be retried if the
nonce was stale).

----
Seems like a 403 is OK to use for rejected/bad auth.
By: khb (khb) 2004-11-23 02:05:50.000-0600

>>What should we send if we get a Digest Auth and it is not working, IE,
>>bad password or anything else wrong?

You should send 401 again and again and again, but typically this is only done twice and then the client waits a while to regroup, maybe get new password from user and tries agan.   See for example RFC-3665 for call flow scenarios.
The 403 should be for other rejections. The best interpretation really is to just strictly read the definitions of the responses, I think.
If there is something technically wrong with the response, ie bad syntax, it should be 400 Bad Request,  if we can't fullfill the request even if auth is ok, for example if the user is not authorized to use a service although he has sucessfully authenticated, or we, from the example above, when we don't support anonymous access,  then we can send a 403,  it's an aggrevated response over and above 401.




21.4.2 401 Unauthorized

  The request requires user authentication.  This response is issued by
  UASs and registrars, while 407 (Proxy Authentication Required) is
  used by proxy servers.

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.

edited on: 11-23-04 02:18

edited on: 11-23-04 02:22
By: khb (khb) 2004-11-23 02:14:51.000-0600

>>Do you have code for a proper QoP, to replace the hack in chan_sip?

It's not complete either, don't handle auth-int yet, but can live without that for now. nonce-count, yes, that was in the fragment in the other post, I think.
By: Olle Johansson (oej) 2004-11-23 04:42:46.000-0600

KHB: Seems like there are different interpretations in the RFC about 403... :-)
Thank you for the clarifications.

Just to check: Did you disclaim the patch in the other report, so we can use it?
By: khb (khb) 2004-11-23 13:02:24.000-0600

It is open to interpretation, sure. In this case, I think, RFC definitions and local policy overlap a bit, with the 403 most customizable. I can see where one would have a local policy to issue a 403 after repeated failed attempts (responded to with 401) at some level to tell the UA to stop trying, since the RFC does specify not to retry after 403.  This doesn't stop a malicious UA, but the server tried anyways.  But for a general implementation here we should first program basic behavior closest to accepted behavior which RFC 3665 represents for some cases.

And yes, the patch is disclaimed, feel free to use it. There are some hooks in there for other auth methods than digest which are not needed here. Nobody uses Basic in SIP and the Certificate method still hasn't gone very far (still pretty esoteric usage, but will be important when we need to positively verify a caller's identity)
By: Olle Johansson (oej) 2004-11-23 14:12:04.000-0600

Isn't Basic auth depreciated in 3261?

Agree, certificate is the way forward. We need to discuss this off-bug ;-)
By: Mark Spencer (markster) 2004-12-11 23:29:39.000-0600

Added to CVS head with modifications.
By: Russell Bryant (russell) 2004-12-30 13:35:46.000-0600

fixed in 1.0
By: Digium Subversion (svnbot) 2008-01-15 15:16:25.000-0600

Repository: asterisk
Revision: 4435

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r4435 | markster | 2008-01-15 15:16:25 -0600 (Tue, 15 Jan 2008) | 2 lines

Merge SIP authentication reuse patch (bug ASTERISK-2866) aka "The Broadvoice Patch" with modifications

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=4435
By: Digium Subversion (svnbot) 2008-01-15 15:18:57.000-0600

Repository: asterisk
Revision: 4604

U   branches/v1-0/channels/chan_sip.c

------------------------------------------------------------------------
r4604 | russell | 2008-01-15 15:18:57 -0600 (Tue, 15 Jan 2008) | 2 lines

Re-use SIP authentication, aka "The Broadvoice patch" (bug ASTERISK-2866)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=4604