Thanks Alex for clearing up the bit about the NONCE, that's what I was trying to remember when I said CallID :)<br><br>Good explanation by the way! :)<br><br><div class="gmail_quote">On Thu, May 5, 2011 at 7:17 AM, Alex Balashov <span dir="ltr"><<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Bilal,<div class="im"><br>
<br>
On 05/05/2011 08:08 AM, bilal ghayyad wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When the endpoint register on Asterisk or initiate a call, so they<br>
exchange the sip username and password. What is the possibility that<br>
this will be capture by the hacker and how to avoid this problem?<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
-- <br><font color="#888888">
Alex Balashov - Principal<br>
Evariste Systems LLC<br>
260 Peachtree Street NW<br>
Suite 2200<br>
Atlanta, GA 30303<br>
Tel: +1-678-954-0670<br>
Fax: +1-404-961-1892<br>
Web: <a href="http://www.evaristesys.com/" target="_blank">http://www.evaristesys.com/</a></font><div><div></div><div class="h5"><br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
<a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Sherwood McGowan<br>Telecommunications and VOIP Consultant<br><br>