openbsc.git branch zecke/features/auth created. 0.14.0-113-g393b605

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-commitlog@lists.osmocom.org/.

gitosis at osmocom.org gitosis at osmocom.org
Mon Jun 15 12:01:55 UTC 2015


This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The OpenBSC GSM Base Station Controller (+MSC/HLR/SGSN)".

The branch, zecke/features/auth has been created
        at  393b605c1a0d747a4c36eca91aa48e9475c171ee (commit)

- Log -----------------------------------------------------------------
http://cgit.osmocom.org/openbsc/commit/?id=393b605c1a0d747a4c36eca91aa48e9475c171ee

commit 393b605c1a0d747a4c36eca91aa48e9475c171ee
Author: Holger Hans Peter Freyther <holger at moiji-mobile.com>
Date:   Mon Jun 8 18:33:28 2015 +0200

    nat: After we identified the bsc check the key
    
    We are using the token to find the right bsc_config and
    then we can use the last_rand of the bsc_connection to
    calculate the expected result and try to compare it with
    a time constant(???) memcmp.

http://cgit.osmocom.org/openbsc/commit/?id=f6ff44c023c93778f68bed67cc93253e31106d0d

commit f6ff44c023c93778f68bed67cc93253e31106d0d
Author: Holger Hans Peter Freyther <holger at moiji-mobile.com>
Date:   Mon Jun 8 18:02:10 2015 +0200

    bsc: Check for the rand and then generate a res
    
    Check if the NAT has sent 16 bytes of RAND and if a key
    has been configured in the system and then generate a
    result using milenage. The milenage res will be sent and
    noth the four byte GSM SRES derivation.

http://cgit.osmocom.org/openbsc/commit/?id=8885ce001fbf3bfe659f361c901014b41e4428db

commit 8885ce001fbf3bfe659f361c901014b41e4428db
Author: Holger Hans Peter Freyther <holger at moiji-mobile.com>
Date:   Mon Jun 8 16:28:15 2015 +0200

    nat: Send 16 bytes of rand to the BSC and remember it
    
    Generate 16 byte of random data to be used for A3A8 by
    the BSC in the response. We can't know which BSC it is
    at this point and I don't want to send another message
    once the token has been received so always send the data
    with an undefined code. The old BSCs don't parse the
    message and will happily ignore the RAND.
    
    /dev/urandom can give short reads on Linux so loop
    around it until the bytes have been read from the kernel.

http://cgit.osmocom.org/openbsc/commit/?id=7b608771dd1d4ded5ebf576b1462a0c12452f0fe

commit 7b608771dd1d4ded5ebf576b1462a0c12452f0fe
Author: Holger Hans Peter Freyther <holger at moiji-mobile.com>
Date:   Mon Jun 8 11:56:59 2015 +0200

    nat: Provide access to /dev/urandom for the code
    
    Instead of doing open/read/close all the time, open the
    FD in the beginning and keep it open. To scare me even
    more I have seen /dev/urandom actually providing a short
    read and then blocking but it seems to be the best way
    to get the random byes we need for authentication.
    
    So one should/could run the cheap random generator on
    the system (e.g. haveged) or deal with the NAT process
    to block.

http://cgit.osmocom.org/openbsc/commit/?id=ad46558c54c3de17af2df2ccae46361cb7743332

commit ad46558c54c3de17af2df2ccae46361cb7743332
Author: Holger Hans Peter Freyther <holger at moiji-mobile.com>
Date:   Wed Jun 10 11:51:16 2015 +0200

    bsc/nat: Fix the structure of the identity request message
    
    Unfortunately the basic structure of the response is broken.
    There is a two byte length followed by data. The concept of
    a 'tag' happens to be the first byte of the data.
    
    This means we want to write strlen of the token, then we
    want to write the NUL and then we need to account for the
    tag in front.
    
    Introduce a flag if the new or old format should be used.
    This will allow to have new BSCs talk to old NATs without
    an additional change. In the long run we can clean that up.

http://cgit.osmocom.org/openbsc/commit/?id=fc9a3ff9dc3801c4ec6927cc80ec2625d1332d65

commit fc9a3ff9dc3801c4ec6927cc80ec2625d1332d65
Author: Holger Hans Peter Freyther <holger at moiji-mobile.com>
Date:   Mon Jun 8 11:55:02 2015 +0200

    nat: Close the connection after we couldn't find the user
    
    In case the token was not correct, just close the connection.
    It is not clear that forcing a new TCP connection is going to
    give us any extra security here. But with the upcoming auth
    handling it does make sense to have both case look similar.

http://cgit.osmocom.org/openbsc/commit/?id=08ff087c9989822d2b0fe344264b95d0343b6676

commit 08ff087c9989822d2b0fe344264b95d0343b6676
Author: Holger Hans Peter Freyther <holger at moiji-mobile.com>
Date:   Mon Jun 8 09:54:45 2015 +0200

    nat: Factor out the config by token search
    
    In the upcoming authentication improvements it is nice to
    separate the finding of the config from the post-allow
    handling of it.

http://cgit.osmocom.org/openbsc/commit/?id=3d07ca5e2f23bc86b9f938efd93ef3331ddc41cd

commit 3d07ca5e2f23bc86b9f938efd93ef3331ddc41cd
Author: Holger Hans Peter Freyther <holger at moiji-mobile.com>
Date:   Mon Jun 8 18:31:02 2015 +0200

    nat: Add size check for the payload
    
    The msgb will always have these bytes but it is better practice
    to verify that the message really has space for the two bytes.

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


hooks/post-receive
-- 
The OpenBSC GSM Base Station Controller (+MSC/HLR/SGSN)



More information about the osmocom-commitlog mailing list