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

[Mark Michelson]

On 02/08/2013 09:52 AM, Olle E Johanson wrote:
> 8 feb 2013 kl. 16:01 skrev Mark Michelson <mmichelson at digium.com>:
>
>> On 02/08/2013 12:58 AM, Olle E. Johansson wrote:
>>> On the topic of authentication:
>>>
>>> The nonce in the current sip channel belongs to the transaction or dialog. It should not, it belongs to a specific set of credentials and is valid for a certain amount of time. That time should be settable for nonce-reuse, which is important for some service providers.
>> Hi Olle! We are not correlating nonces with dialogs or transactions. Instead, they are based on the time the challenge was sent and the source IP and port of the requester. The code currently sets a time of 32 seconds for the lifetime of the nonce, but it would be quite easy to make this configurable.
>>> This is particularly important in the case of REGISTER where the second REGISTER using the nonce from the first may have a completely different set of identifiers.
>> Exactly. REGISTER doesn't use a dialog, so it's perfectly acceptable for entities to send a REGISTER with completely different Call-ID and from-tag if they wish. I think it's also possible (though not necessarily recommended) for dialog-forming requests like INVITE or SUBSCRIBE to use different identifiers for the follow-ups since no dialog was established from the previous transaction. Our implementation will work fine since nonces are not tied in any way to dialogs or transactions.
>>
>>> Also look into the QoP specs for replay protection.
>> I certainly will!
> Another issue:
>
> An old Asterisk user, Kapejod, did some tests the other day. It took just a few minutes to brute-force a four character password with MD5.
>
> I think we should be among the first to migrate to SHA256 auth, so please code in a way that you can select algorithm or force one.

This should be doable with the authenticator API we have in place. You'd 
just have to write an authenticator module that put out the proper 
challenge and knew how to verify credentials. The only part that might 
be a bit difficult with this is that you wouldn't have the help of the 
pjsip_auth_srv API since it only supports MD5 as the digest algorithm.

Our configuration options for authentication sections includes an 
"auth_type" option. It's possible to expand to include auth_types other 
than what is currently provided.
>
> Also think about using TLS client certs for auth, especially on trunks to other SIP servers.

Like with the previous suggestion, I think this can be done by writing 
an alternative authenticator in place of the provided MD5 digest one.

I don't think we're going to get to these authentication suggestions 
immediately, but you've got us thinking and making sure the 
authentication API can handle these situations. AFAICT, in both cases, 
it means writing a new custom module rather than having to change APIs 
or anything more drastic.

>
> /O
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>     http://lists.digium.com/mailman/listinfo/asterisk-dev