[asterisk-users] SIP secruity: username and password

[Olle E. Johansson]

5 maj 2011 kl. 14.17 skrev Alex Balashov:

> Bilal,
> 
> On 05/05/2011 08:08 AM, bilal ghayyad wrote:
> 
>> When the endpoint register on Asterisk or initiate a call, so they
>> exchange the sip username and password. What is the possibility that
>> this will be capture by the hacker and how to avoid this problem?
> 
> Strictly speaking, there is no inherent connection between either registration or call initiation on the one hand, and authentication. Both of those scenarios can be performed in an authentication-free fashion.  In fact, in most cases the SIP UAC will first attempt to send both a REGISTER and an INVITE request without any authentication credentials.
Because they HAVE TO. In the 401/407 reply, there's a challenge (nonce) which is an important part of the MD5 Digest Auth scheme.
> 
> However, it is typical of a SIP UAS providing retail services to the public at large to reply to those requests with a 401 or 407 proxy challenge requesting authentication.  The UAC then resends the request with digest authentication headers, including a password encrypted via a cryptographic one-way hash function.  The entire mechanism was borrowed from HTTP digest authentication.
> 
> The authorisation username can absolutely be intercepted, as it is transmitted it in plain text.  But this is not news.  The password is encrypted, and while the encrypted version can be intercepted, it is encrypted using a one-time "nonce" value that is part of the 401 or 407 challenge sent by the UAS.  Nonce values typically have fairly stringent expiration times, at least on good implementations, but nonce replay attacks are possible in principle.
The password is NOT encrypted. It's is used as the basis of a textstring you calculate a hash from. That's very different :-)
> 
> This mechanism is reasonably secure, as a compromise with the interoperability requirements of providing SIP service across the public Internet.  In high-stakes situations, however, it may not be sufficient, and may call for SIP over a TLS transport, or encrypted tunnels.
I would say it may call for SIP with TLS client authentication - regardless if you need encryption or not...

Cheers,
/O