<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://reviewboard.asterisk.org/r/1362/">https://reviewboard.asterisk.org/r/1362/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On August 12th, 2011, 2:14 a.m., <b>Tilghman Lesher</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;">
<thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;">
<a href="https://reviewboard.asterisk.org/r/1362/diff/1/?file=18288#file18288line1713" style="color: black; font-weight: bold; text-decoration: underline;">/branches/10/channels/chan_sip.c</a>
<span style="font-weight: normal;">
(Diff revision 1)
</span>
</th>
</tr>
</thead>
<tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
<tr>
<td colspan="2"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<td colspan="2"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">static void report_failed_acl(struct sip_pvt *p)</pre></td>
</tr>
</tbody>
<tbody>
<tr>
<th bgcolor="#b1ebb0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2"></font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "></pre></td>
<th bgcolor="#b1ebb0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">1713</font></th>
<td bgcolor="#c5ffc4" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="k">static</span> <span class="kt">void</span> <span class="nf">report_inval_password</span><span class="p">(</span><span class="k">struct</span> <span class="n">sip_pvt</span> <span class="o">*</span><span class="n">p</span><span class="p">)</span></pre></td>
</tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">It is helpful to know whether the invalid password is different from the previous invalid password from this peer (if possible). You don't need to know what that previous guess was, as a security watcher can be expected to keep history. This can be important, to distinguish a misconfigured phone with the wrong password (false positive) from a scan attack.</pre>
</blockquote>
<p>On August 12th, 2011, 3:36 p.m., <b>elguero</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Hmm... not sure how we would report that with the current framework as it is.
We would have to somehow store the previous guess, so that we could compare the new guess and determine if they are the same. Is that being done anywhere? Any quick suggestions?
Then we would need to add an element to this security event structure, such as, new_password_attempt and make it optional.
Let me know if I am over thinking this.</pre>
</blockquote>
<p>On August 12th, 2011, 4:19 p.m., <b>Kevin Fleming</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">No, that's the right strategy, but I'm not sure it's achievable. All you have as a response in an authentication attempt is a digest computed from the shared secret password, a nonce and some other bits. When you get a second authentication attempt which fails, you don't have any way to determine whether they used the same wrong password or not, because the digest value is going to be different by virtue of the nonce being different. It would be possible to reuse the nonce in order to determine whether the attempts are using different passwords or not, but that's a larger change that shouldn't be included in this patch.</pre>
</blockquote>
<p>On August 12th, 2011, 7:05 p.m., <b>rmudgett</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Reusing the nonce is a bad thing because it allows replay attacks.</pre>
</blockquote>
<p>On August 13th, 2011, 9:55 a.m., <b>Tilghman Lesher</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Reusing the nonce is only a problem in the case of a successful authentication. What would be the value in replaying a failed authentication?
Asterisk doesn't need to know the previous value, as long as it is delivering a constant algorithmic result (i.e. the same attempted password delivers the same hash) to the backend for comparison. It can be safely expected that the monitoring system will keep a history state and do appropriate analysis of the stream.</pre>
</blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I believe that we've had a hallway conversation about this in the past (maybe at an AstriCon), and the result of that conversation was that we'd be OK with using the same nonce two (or three) times but *only* when the first usage resulted in failed authentication. As Tilghman says, there's no value in replaying a failed authentication, and reusing the nonce could provide very valuable information to a monitoring tool.
With that said, though, modifying chan_sip's behavior in this regard really shouldn't be part of this patch; as long as the security event includes the nonce and password hash that the UAC provided (for a failed authentication attempt), then it will be possible to enable this behavior in chan_sip.</pre>
<br />
<p>- Kevin</p>
<br />
<p>On August 12th, 2011, 1:07 a.m., elguero wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers.</div>
<div>By elguero.</div>
<p style="color: grey;"><i>Updated Aug. 12, 2011, 1:07 a.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Security Events Framework was added in 1.8 and support was added for AMI to generate events at that time.
This patch attempts to add support in chan_sip to generate security events. Hopefully we can get this into Asterisk 10.
I am looking forward to hearing feedback on where this patch can be improved especially from those who have an intimate knowledge of chan_sip.
Thanks</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Local dev machine and a softphone. Generated events by using the wrong username, wrong password, wrong auth name, successful authentication.</pre>
</td>
</tr>
</table>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="https://issues.asterisk.org/jira/browse/18264">18264</a>
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>/branches/10/channels/chan_sip.c <span style="color: grey">(331633)</span></li>
<li>/branches/10/configs/logger.conf.sample <span style="color: grey">(331633)</span></li>
<li>/branches/10/CHANGES <span style="color: grey">(331633)</span></li>
</ul>
<p><a href="https://reviewboard.asterisk.org/r/1362/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>