New subject: OpenBSC Digest, Vol 35, Issue 30

28 Sep 2017

HI,
My name is Goran, I have femto cell would like test osmo iuh. Installed libosmocore on
debian server, but got lot of problems with osmo IuH compiling. Curenlty I am stucked with
osmo-sccp library.
Also tried Vagrant IuH image, but there is issue with permisions,
Is there a way to get some help for solving this issues,
Thanks
Goran

-----Original Message-----
From: OpenBSC [mailto:openbsc-bounces@lists.osmocom.org] On Behalf Of
openbsc-request(a)lists.osmocom.org
Sent: Thursday, September 28, 2017 4:36 AM
To: openbsc(a)lists.osmocom.org
Subject: OpenBSC Digest, Vol 35, Issue 30

Send OpenBSC mailing list submissions to
	openbsc(a)lists.osmocom.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.osmocom.org/mailman/listinfo/openbsc
or, via email, send a message with subject or body 'help' to
	openbsc-request(a)lists.osmocom.org

You can reach the person managing the list at
	openbsc-owner(a)lists.osmocom.org

When replying, please edit your Subject line so it is more specific than "Re:
Contents of OpenBSC digest..."

Today's Topics:

   1. Re: branches in openbsc.git (Harald Welte)
   2. Re: randomness of identifiers (Harald Welte)
   3. Re: Retrieve OP from OPc and Ki (Harald Welte)
   4. Re: ctrl interface: GET a variable with parameter (Harald Welte)
   5. Re: Retrieve OP from OPc and Ki (Kathryn Heckman)
   6. Re: Retrieve OP from OPc and Ki (Mychaela Falconia)
   7. Re: Retrieve OP from OPc and Ki (Tomcs?nyi)

----------------------------------------------------------------------

Message: 1
Date: Thu, 28 Sep 2017 07:05:09 +0800
From: Harald Welte &lt;laforge(a)gnumonks.org&gt;
To: Neels Hofmeyr &lt;nhofmeyr(a)sysmocom.de&gt;
Cc: openbsc(a)lists.osmocom.org
Subject: Re: branches in openbsc.git
Message-ID: <20170927230509.pw4xug7jntrfvts2@nataraja>
Content-Type: text/plain; charset=us-ascii

On Thu, Sep 28, 2017 at 12:22:31AM +0200, Neels Hofmeyr wrote:
...
  another call for anyone aware of important branches on
openbsc.git to 
 please name them, so that they can be migrated to the new repositories.
 But foremost, please name them, thanks! 
...
 From "my" branches, I can see the following:
* laforge/bssgp_fc -> osmo-sgsn
* laforge/gprs-suspend -> osmo-bsc
* laforge/power_control -> osmo-bsc

-- 
- Harald Welte &lt;laforge(a)gnumonks.org&gt;           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

------------------------------

Message: 2
Date: Thu, 28 Sep 2017 07:15:01 +0800
From: Harald Welte &lt;laforge(a)gnumonks.org&gt;
To: Neels Hofmeyr &lt;nhofmeyr(a)sysmocom.de&gt;
Cc: openbsc(a)lists.osmocom.org
Subject: Re: randomness of identifiers
Message-ID: <20170927231501.zyqrali3onodi4iw@nataraja>
Content-Type: text/plain; charset=us-ascii

Hi Neels,

On Wed, Sep 27, 2017 at 06:06:48PM +0200, Neels Hofmeyr wrote:
...
  On Wed, Sep 27, 2017 at 07:57:43PM +0800, Harald Welte
wrote:
 > For TMSI allocation, my "cryptographic gut feeling"[tm] is that 
 > something like rand() or any other pseudo-random generator of 
 > significantly large period is sufficient *if* it is seeded by a 
 > non-predictable value.  So something like seeding with getrandom() result should be
fine? 
...
  Might also make sense to periodically re-seed from
/dev/urandom / 
 getrandom(), like every 100 TMSIs, or based on a timeout might be 
 easier to implement. 
I would try to avoid any predictability here.  Having a fixed time interval would be known
to an attackers.  So if he was somehow able to reduce/exhaust the entropy at the known
time for re-seeding, it would be bad.

Similar for "every 100 TMSIs", which is something under control of any attacker
as he can control the number of location updates via the public radio interface [to some
extent] and thus control the time at whcih re-seeding is done.

Maybe I'm going overboard here, but I think if you want to re-seed, you want to
ideally do it at a non-predictable and non-controllable point in time.  Like a random time
interval ;)

...
   For long-term
stable key (Ki/Op) generation for provisioning SIM 
 cards + populating a HLR, I would certainly opt for using stronger 
 randomness sources.  However, I don't think we actually implement 
 that anywhere, do we?  
 what does openssh use for public/private keypair generation? 
I'm not sure you can compare the requirements for generation of RSA public/private
keys with those for generation of symmetric keys. You can find different recommendations
in the literature.  But I guess that's mainly due to the fact that people usually
assume you have long-term stable public/private keys and short-lived symmetric session
keys.  In our case, it's long-lived symmetric keys.

But as indicated, I think our focus is to find a proper solution for generation of TMSIs
and for random numbers used in authentication challenges.  K/OPc pair generation is not
supported in current Osmocom tools anyway, as we presume the SIM cards already have
sufficiently random key material and those keys are entered into the HLR.

Regards,
	Harald

-- 
- Harald Welte &lt;laforge(a)gnumonks.org&gt;           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

------------------------------

Message: 3
Date: Thu, 28 Sep 2017 06:52:28 +0800
From: Harald Welte &lt;laforge(a)gnumonks.org&gt;
To: Kathryn Heckman &lt;exuberant.kathryn.heckman(a)gmail.com&gt;
Cc: &quot;openbsc(a)lists.osmocom.org&quot; &lt;openbsc(a)lists.osmocom.org&gt;
Subject: Re: Retrieve OP from OPc and Ki
Message-ID: <20170927225228.u4udbuhk2fyebrl5@nataraja>
Content-Type: text/plain; charset=us-ascii

Hi Kathryn,

On Wed, Sep 27, 2017 at 05:37:36PM -0400, Kathryn Heckman wrote:
...
  Is there any way to retrieve the value of OP from OPc
and Ki? 
No, that defeats the entire purpose of having card-individual OPc values.

If you could just revert that operation, there would be no [security] advantage of
card-individual OPc values over a global OP value, and hence that entire option could be
dropped from the specifications altogether.

Regards,
	Harald
-- 
- Harald Welte &lt;laforge(a)gnumonks.org&gt;           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

------------------------------

Message: 4
Date: Thu, 28 Sep 2017 06:50:03 +0800
From: Harald Welte &lt;laforge(a)gnumonks.org&gt;
To: Neels Hofmeyr &lt;nhofmeyr(a)sysmocom.de&gt;
Cc: Holger Freyther &lt;holger(a)freyther.de&gt;de>, openbsc(a)lists.osmocom.org
Subject: Re: ctrl interface: GET a variable with parameter
Message-ID: <20170927225003.ix4qgulake4gugyu@nataraja>
Content-Type: text/plain; charset="us-ascii"

Hi Neels,

On Wed, Sep 27, 2017 at 05:27:38PM +0200, Neels Hofmeyr wrote:
...
  Also we do have a concept of nesting CTRL nodes
separated by dots in 
 the variable name, looking at bsc_ctrl_node_lookup() and fsm_ctrl_node_lookup(). 
correct.

...
  I notice though that we do still have open doors for a
lot of nonsense 
 being sent to it without proper validation or error messages.

   GET 42 existing-variable.trailing.names.ignored more nonsense 
 following being ignored

 in effect is identical to:

   GET 42 existing-variable

 So we should probably enforce that there is no ignored nonsense... 
I agree.

...
  Should we also enforce a numeric command ID? 
I'm not following here. Where would that numeric command ID comning from?

...
    GET
currently-any-id-is-possible-even-\t-\n-is-accepted my-command 
this is also not intended, I'm quite sure.

...
  Going back to the OsmoHLR CTRL commands -- they are
implemented in a 
 way that doesn't match the CTRL interface ways. Let's collapse them.

   SET enable-ps <IMSI>
   SET disable-ps <IMSI>
   SET status-ps <IMSI> 
indeed, this is not proper.

...
    SET subscriber.by-imsi.123456789098765.ps-enabled 1
   SET subscriber.by-imsi.123456789098765.ps-enabled 0
   GET subscriber.by-imsi.123456789098765.ps-enabled 
makes a lot of sense to me.

...
  We can also expand this later to things like

   GET subscriber.by-imsi.123456789098765.status
   SET subscriber.by-imsi.123456789098765.msisdn 2345
   GET subscriber.by-msisdn.2342.status
   SET subscriber.by-msisdn.2342.ps-enabled 0
   GET subscriber.by-imei.987654321234565.imsi 
looks good!

...
  We could leave the enable-ps, disable-ps, status-ps
commands in place 
 in case anyone is using it yet. I assume no-one is though. 
I don't think we need to keep compatibility at this point.

-- 
- Harald Welte &lt;laforge(a)gnumonks.org&gt;           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

RE: OpenBSC Digest, Vol 35, Issue 30