Hello Martin,<div><br></div><div>RIM have told me that they have fixed this issue in in BBv6 and later but I'm not able to verify this.</div><div>I need to support older versions so I will use the patch.</div><div><br>
</div><div>There doesn't appear to be a way to identify the device from the payload. </div><div><br></div><div>I understand why you don't want to take the patch, no problem, I maintain my own fork anyway.</div><div>
<br></div><div>Regards</div><div>AlanE.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 21, 2012 at 8:46 AM, Martin Willi <span dir="ltr"><<a href="mailto:martin@strongswan.org" target="_blank">martin@strongswan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Alan,<br>
<div class="im"><br>
> I finally fixed this issue with RIM devices. The problem was the<br>
> Reserved Field in the IDi sent by the RIM. It was putting junk in this<br>
> field.<br>
<br>
</div>I see.<br>
<div class="im"><br>
> The RFC says the receiver should ignore the field and use zeros but<br>
> charon was using the junk.<br>
<br>
</div>This is not true for this special case. While RESERVED fields should be<br>
ignored, here the full payload is part of the data that gets hashed for<br>
the AUTH payload.<br>
<br>
We initially used just zeros to create the hash, but the general consent<br>
is that it was wrong: we must use those bytes actually found in the<br>
RESERVED field [1]. We changed this some time ago to fix compatibility<br>
with other implementations.<br>
<div class="im"><br>
> It's just a simple one line change.<br>
<br>
</div>It is, but I can't push this without breaking compatibility with other<br>
implementations. The best thing would be if RIM can fix these two RFC<br>
5996 violations (or just one of them), send zero RESERVED bytes and use<br>
the RESERVED bytes to calculate the AUTH payload.<br>
<br>
If RIM is unable to fix this, we need a way to detect such broken<br>
devices (Vendor ID payload?) and use your work around just for them.<br>
<br>
Regards<br>
Martin<br>
<br>
[1]<a href="http://tools.ietf.org/html/rfc5996#section-2.15" target="_blank">http://tools.ietf.org/html/rfc5996#section-2.15</a><br>
<br>
<br>
</blockquote></div><br></div>