Hi Martin,<div><br></div><div>I finally fixed this issue with RIM devices. The problem was the Reserved Field in the IDi sent by the RIM. It was putting junk in this field. The RFC says the receiver should ignore the field and use zeros but charon was using the junk.</div>
<div><br></div><div>I modified the get_reserved_id_bytes() function in  /src/libcharon/sa/ikev2/tasks/ike_auth.c to return zeros instead and it fixed the issue. It's just a simple one line change.</div><div><br></div>
<div><a href="https://github.com/alanrevans/strongswan/commit/57056bb8fcd809a87a7354a4301f785389462d5d">https://github.com/alanrevans/strongswan/commit/57056bb8fcd809a87a7354a4301f785389462d5d</a><br></div><div><br></div>
<div>Regards</div><div>AlanE</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Oct 22, 2012 at 2:07 PM, Alan Evans <span dir="ltr"><<a href="mailto:alanrevans@gmail.com" target="_blank">alanrevans@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Martin,<br>
<br>
I have increased the log levels, however it's impossible to do a side<br>
by side analysis of the working and non-working cases due to the<br>
random NONCE_MT included in the Mater Key algorithm, even if I make<br>
the GSM triplet RANDs the same the NONCE_MT is different every time<br>
which generates a completely different MK.<br>
<br>
I've studied the specs and the code and can't see where I have gone<br>
wrong, except it just doesn't work.<br>
<br>
If I ignore the AUTH4 failure and carry on then the RIM device just<br>
ignores the next message.<br>
<br>
So it seems it is a key mismatch rather than an incompatibility in the<br>
AUTH payload calculation.<br>
<br>
I agree, it's unlikely to be a stongSwan issue, I'm hoping someone out<br>
there has come across something similar and can point me down the<br>
right path.<br>
<br>
As an aside, I can dump the debug logs off the RIM device but the file<br>
is encrypted and needs to be decrypted by RIM, maybe someone on the<br>
list knows someone who could do this for me.<br>
<br>
Regards<br>
AlanE<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Oct 22, 2012 at 1:10 PM, Martin Willi <<a href="mailto:martin@strongswan.org">martin@strongswan.org</a>> wrote:<br>
> Hi Alan,<br>
><br>
>> 02[IKE] RADIUS authentication of '...' successful<br>
>> 02[IKE] EAP method EAP_SIM succeeded, MSK established<br>
><br>
>> 01[IKE] verification of AUTH payload with EAP MSK failed<br>
><br>
>> Bear in mind that the same SIM Card and Security Gateway works fine on<br>
>> Andorid.<br>
><br>
> It don't think it is related to strongSwan. As you're using a RADIUS<br>
> backend, EAP-SIM and MSK derivation happens outside of strongSwan.<br>
><br>
> As it works with Android, it might be that the Blackberry is calculating<br>
> the IKEv2 AUTH payload from the MSK differently.<br>
><br>
> You might try to increase the debug level on strongSwan to see what<br>
> values are used for AUTH payload calculation. If you can compare these<br>
> values with those one your UMA client, you might see a difference.<br>
><br>
> Regards<br>
> Martin<br>
><br>
</div></div></blockquote></div><br></div>