Hello Martin, RIM have told me that they have fixed this issue in in BBv6 and later but I'm not able to verify this. I need to support older versions so I will use the patch.
There doesn't appear to be a way to identify the device from the payload. I understand why you don't want to take the patch, no problem, I maintain my own fork anyway. Regards AlanE. On Wed, Nov 21, 2012 at 8:46 AM, Martin Willi <[email protected]> wrote: > Hi Alan, > > > 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. > > I see. > > > The RFC says the receiver should ignore the field and use zeros but > > charon was using the junk. > > This is not true for this special case. While RESERVED fields should be > ignored, here the full payload is part of the data that gets hashed for > the AUTH payload. > > We initially used just zeros to create the hash, but the general consent > is that it was wrong: we must use those bytes actually found in the > RESERVED field [1]. We changed this some time ago to fix compatibility > with other implementations. > > > It's just a simple one line change. > > It is, but I can't push this without breaking compatibility with other > implementations. The best thing would be if RIM can fix these two RFC > 5996 violations (or just one of them), send zero RESERVED bytes and use > the RESERVED bytes to calculate the AUTH payload. > > If RIM is unable to fix this, we need a way to detect such broken > devices (Vendor ID payload?) and use your work around just for them. > > Regards > Martin > > [1]http://tools.ietf.org/html/rfc5996#section-2.15 > > >
_______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
