[asterisk-dev] [Code Review] SIP authentication support

[Mark Michelson]

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

(Updated Feb. 7, 2013, 7:27 p.m.)


Review request for Asterisk Developers, Matt Jordan and jcolp.


Changes
-------

This addresses Joshua's problem with the possibility of replay attacks.

We now provide a nonce that is calculated based on several factors, to include the IP address and port where the request comes from and a timestamp. This means that we can verify that the request with the credentials can be verified to come from the same source and to come in a timely manner.

Does this mean that replay attacks are now impossible? No. But it also means that they're not trivial any more either.

This solution works well with out model because it does not introduce any contention between threads like storing authentication challenges in a global container would.


Summary
-------

This introduces inbound authentication support for the new SIP work.

I reworked the initial concept of authentication drastically. I realized that the original API I came up with was making it awkward to use any other authentication scheme than digest authentication. The newer authenticator callbacks are now simpler: there is one to find out whether an endpoint requires authentication and a second one to do whatever authentication is necessary, returning the results of such attempts.

This adds an authenticator, res_sip_authenticator_digest, that uses digest authentication in order to authenticate. Initially, I thought I was going to need some features from PJSIP trunk, but I realized after backporting them that they really didn't help the situation any. Thus I had to resort to using some thread-local storage in order to be able to access certain data in one of the PJSIP authentication callbacks. Due to the threading model in use, this is safe.

Authentication is configured via a type=auth section in res_sip.conf. Then an endpoint can specify auth=blah in order to tie authentication credentials to the endpoint. Endpoints can specify multiple auth sections if they have credentials for multiple realms. Similarly, multiple enpdoints may specify the same auth section if for whatever reason endpoints share credentials. This means that Asterisk may send multiple WWW-Authenticate headers out in an authentication challenge and can cope with multiple Authorization headers in requests.

I made a change to the sorcery API. The sorcery apply handler now returns an int instead of void. This way, if there is an error when applying an objectset, it can be detected. I did this because once an auth object has been constructed, I wasn't sure of another way to do some verification that the configured auth was sane. If a different change should be made, or if I was missing a simpler way to verify a constructed auth object, please let me know. IMO, this change makes good sense, though, especially as I was changing the transport apply handler to be able to return an error condition when it encounters problems.


This addresses bug ASTERISK-20953.
    https://issues.asterisk.org/jira/browse/ASTERISK-20953


Diffs (updated)
-----

  /team/group/pimp_my_sip/include/asterisk/res_sip.h 381009 
  /team/group/pimp_my_sip/include/asterisk/sorcery.h 381009 
  /team/group/pimp_my_sip/main/astobj2.c 381009 
  /team/group/pimp_my_sip/main/sorcery.c 381009 
  /team/group/pimp_my_sip/res/res_sip.c 381009 
  /team/group/pimp_my_sip/res/res_sip/config_transport.c 381009 
  /team/group/pimp_my_sip/res/res_sip/sip_configuration.c 381009 
  /team/group/pimp_my_sip/res/res_sip_authenticator_digest.c PRE-CREATION 
  /team/group/pimp_my_sip/res/res_sip_session.c 381009 
  /team/group/pimp_my_sip/tests/test_sorcery.c 381009 

Diff: https://reviewboard.asterisk.org/r/2310/diff


Testing
-------

Inbound calls have been made when authentication is configured and when it is not. I have ensured that endpoints with no configured authentication do not get challenged and that endpoints with configured authentication do get challenged.

I also tested both the password and md5_cred versions of storing authentication and verified that authentication worked properly.


Thanks,

Mark

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130208/14e0ad8b/attachment-0001.htm>