From: Alexander C. <ale...@gm...> - 2011-10-21 17:45:27
|
Hi David, Thanks for the response. I vote for the option (2), as it's much, much cleaner. On Fri, Oct 21, 2011 at 21:15, David A. Burgess <dbu...@jc...> wrote: > Alexander, Bassam - > > In C2.8, we do the authentication in sipauthserve, not in OpenBTS itself. OpenBTS talks SIP to sipauthserve, using the same REGISTER/401/REGISTER/200 message exchange as in SIP digest authentication, but using A3/A8 instead of MD5, RAND as the nonce, etc., mimicking the procedure used in IMS. (If authentication is not used, sipauthserve can respond to the first REGISTER with 200, as it does in the public release.) Ki is stored in the sip_buddies table when a new SIM is provisioned. We invoke A3/A8 as an external program through exec(), so a customer can plug in whatever A3/A8 their SIMs support and we don't care about the license. This is all in keeping with the design principles of OpenBTS: Don't implement anything in OpenBTS itself above L3. Use SIP-based protocols when they are available, HTTP/S when they are not. Use external applications as-is when they are available. Give the customer flexibility without forcing them to hack the code themselves. > > I can think of two potential ways to add A5/x encryption to this system. In both approaches, Kc is generated in sipauthserve when it runs A3/A8. In both approaches, the transaction table is extended to store Kc and there is a cipher-stream generator added to L1. The difference between the approaches is in how Kc gets from sipautherve to OpenBTS. > > (1) Have sipauthserve store Kc and the ciphering key sequence number in the sip_buddies table, which OpenBTS can then access through methods in the subscriberRegistry class. OpenBTS does not access the sip_buddies table directly in the current release, so this approach would introduce a new interaction path. This approach does avoid exposing Kc on the SIP interface, but user traffic runs unencrypted on that same interface anyway, so there's little or no practical security advantage. > > (2) Have sipauthserve return Kc and the sequence number in an optional header in the final 200 OK. Sipauthserve would still store Kc in the sip_buddies table for future reference via a sequence number, but OpenBTS would not need to access that table directly since it received a copy of Kc via SIP. Since OpenBTS does *not* directly access sip_buddies in the current design, this approach would not introduce any new interfaces or interaction paths among the components, just a few more lines of code somewhere in SIPEngine to grab Kc and put it in the transaction table. This approach does assume a reasonable degree of security in the SIP path, but we assume that already. > > I think approach (2) is better, if that can be done without too much abuse of the SIP spec. I supose we can borrow some session key header from HTTPS if SIP doesn't offer anything in its current form. > > Also, sipautherve is already GPL-licensed, even in the commercial release, so no CLA is required for someone to work on that. > > > -- David > > > On Oct 20, 2011, at 1:57 AM, Alexander Chemeris wrote: > >> Hi David, >> >> So, in an order to coordinate - could you please describe this architecture? > > -- Regards, Alexander Chemeris. |