Hi Dieter,

On Sun, Jul 12, 2009 at 04:50:48PM +0200, Dieter Spaar wrote:

To implement it in a clean way in my opinion requires some discussion about how to do it so that it fits into the architecture:

• When do the authentication, most certainly during the first Loacation Update, but when else ?

I think first location update (until imsi detach) is fine for now. It can always be extended later on.

What's probably more important is to enable the encryption (CIPHERING MODE COMMAND) for every radio channel that we establish for that MS.

The entire auth+crypto should be enabled/disabled by a global switch, in case somebody wants to typically have it, but disable it temporarily in order to be able to obtain plaintext Um interface traces.

• Where to store the subscriber Ki for authentication and the information about which algorithm is used ? Also store for each subscriber if authentication and/or encryption should to be used.

yes, each subscriber needs the following information: * which auth algorithm to use (none,xor,comp128v1) * which crypto algorithm to use (a5/0,1,2) * the secret data (Ki) for that particular algorithm * the currently-allocated Kc

I would simply also store all that it in the sqlite database.

It makes sense to put all this authentication related information into a separate table, indexed and referenced by the subscriber ID. The rationale is that later (when using real SQL databases) we might want to have different permissions on the regular subscriber data than on the authentication data.

• Where to cache Kc, its not necessary to authenticate every time when encryption for a channel is turned on. Kc from a previous authentication can be used several times.

yes. I think a typical value in production networks is: something like 4 calls / sms and then re-authenticate. The Kc should be cached in the sqlite database, too.

• Where to turn on encryption, every time a channel is allocated ?

yes, of course only if the subscriber database indicates that this subscriber is to use encryption.

Those are just a few thoughts. I guess discussion about the details probably takes longer than if you or Holger implement it during your ongoing work on OpenBSC.

I'm not so sure about that. I'm very busy and have a long todo list, so I'm always happy to see somebody else taking care of relatively self-contained features...

Currently you both are the main people working on OpenBSC at several places of the implementation and a clean integration of authentication and encryption affects a lot of those places too. I am reluctant to interfere here, not because of the time it takes (its not that much) but because any changes should fit to what you plan to do. If anyone want to see the technical details, I can provide them, its rather simple and straightforward.

Mh. If Holger thinks it is causing interference with his work, I think we should probably delay encryption/authentication until the BSC/MSC functional split has been matured and merged in the code.

As for myself, I'm doing a lot of GSM related work right now, but it's not actually extending OpenBSC that much, more reverse engineering some more bits about the ip.access protocol extensions, writing wireshark code, as well as work on a A-bis proxy (between BTS and BSC), allowing for OML and RSL packet injection into the live connection, as well as a scapy plugin for crafting/fuzzing 04.08, RSL and OML packets. Using that infrastructure it should be possible to do a lot of things such as * fuzzing packets sent to the MS (MS software stability) * fuzzing packets sent to the BTS (BTS software stability) * fuzzing packets sent to BSC/MSC (network software stability)

Among other things, this can also be used to generate test cases for OpenBSC and to work on OpenBSC protocol parsing stability, too.

The only part of OpenBSC that I plan to work on during the next weeks is the SMS implementation and system information generation. And if I find more time after that, GPRS.

None of that should clash with support for encryption/authentication.