osmo-auc-gen on 32bit systems allowed only --sqn up to 32bits width. However,
the recently added regression test for osmo-auc-gen includes an ivocation with
a 48bit wide --sqn, which now causes the builds to fail on 32bit systems.
Fix the --sqn argument parsing for larger integers by using strtoull(). Do away
with the intermediate variable 'ul' and place the value directly in the auth
data struct.
Change-Id: Ifb73b3b3de06576e36076ca573d52327f90a1f77
Prepare for the implementation of splitting SQN increments in SEQ and an IND
part; particularly to clearly show where the changes in auth/milenage_test's
expectations originate.
Rationale: the source of UMTS auth vectors, for us usually OsmoHLR, typically
stores the last used SQN, not the next one to be used. Particularly with the
upcoming fix of the SQN scheme, this change is important: the next SQN will
depend on which entity asks for it, because each auth consumer may have a
particular slot in the IND part of SQN. It does not make sense to store the
next SQN, because we will not know which consumer that will be for.
The milenage_test has always calculated a tuple for SQN == 34. To account for
the increment now happening before calculating a tuple, lower the test_aud->sqn
by one to 0x21 == 33, so that it is still calculating for SQN == 34.
Because we are no longer incrementing SQN after the tuple is generated,
milenage_test's expected output after doing an AUTS resync to 31 changes to the
next SQN = 32, the SQN used for the generated tuple.
(BTW, a subsequent patch will illustrate AUTS in detail.)
osmo-auc-gen now needs to pass the user requested SQN less one, because the SQN
will be incremented befor generating the auth vector. Also the SQN remains the
same after generating, so SQN output needs less decrementing. Note that the
expected output for osmo-auc-gen_test remains unchanged, hence the same input
arguments (particularly -s <sqn> and -A <auts>) still produce the same results.
Note: osmo-hlr regression tests will require adjustments when this patch is
merged, because it must now pass desired_sqn - 1 instead of just desired_sqn.
See osmo-hlr change-id I4ec5a578537acb1d9e1ebfe00a72417fc3ca5894 .
Related: OS#1968
Change-Id: Iadf43f21e0605e9e85f7e8026c40985f7ceff1a3
Upcoming patches will change the way SQN are incremented. Change the SQN
related output by osmo-auc-gen so that it also makes sense after these changes,
and so that its output is proven to remain unchanged for the same arguments:
Always show the SQN used for vector generation when a UMTS vector was generated.
Don't show the next SQN, it will not make sense anymore (see later patches).
The adjustments of expected output of osmo-auc-gen_test illustrates how the
output changes.
Related: OS#1968
Change-Id: I35d9c669002ff3e8570e07b444cca34ce57c3b0c
In the -h help output, list the names of available algorithms.
In case of option parsing failure, also print help() (so that e.g. for a typo
in the algorithm, the list of algorithms is printed along with the error
message).
If there are -2/-3 or -a missing, show an error message that explains this.
Change-Id: I76732b28d7a553a6293d1707fe398d28b5ef4886
When calculating a re-sync vector using AUTS, osmo-gen-vec used to print
SQN.MS + 2, the new SQN after vector generation, labeled 'SEQ.MS'.
Firstly, s/SEQ/SQN.
Secondly, print SQN.MS as umts.sqn - 2, which is the actual SQN recovered from
the AUTS. As explained in the comment, SQN.MS + 1 is used to generate the
vector, and then umts.sqn is increased a second time to indicate the next SQN.
With AUTS calculated from SQN.MS == 23, the output was:
AUTS success: SEQ.MS = 25
Output now:
AUTS success: SQN.MS = 23, generated vector with SQN = 24, next SQN = 25
Change-Id: I881bbe8246a5e7d3a5065b4b5b533255723b1a9e
GSUP transmits AUTS for UMTS authentication procedures, and OAP uses the same
procedures to authenticate. osmo-gen-vec is a utility program that passes AUTS
to our osmo_auth_gen_vec_auts() API.
According to 3GPP 33.102 6.3.3, AUTS = SQN^AK || MAC-S, which are 6 || 8 == 14
bytes. This is confirmed by 24.008 9.2.3a where the TLV has 16 bytes, TL = 2
and AUTS being the V = 14.
It is not harmful for milenage_gen_vec_auts() to pass two more AUTS bytes. But
writing 16 bytes to a GSUP struct is a potential problem when passing in a 14
byte long AUTS buffer to the GSUP API, which then reads past the AUTS buffer.
The API implies the length, so far to be 16, so passing in a 14 byte buffer to
GSUP would require copying to a larger buffer first.
Fix this by using a length of 14 for AUTS everywhere instead.
This constitues an ABI breakage, we may handle it as a "fix before an official
release", otherwise we need a version bump.
The OAP protocol document has also been updated, needs an update in the
osmo-gsm-manuals as well.
Change-Id: If25b173d9ec57ea4c504d860954912b7d82af455
When generating some authentication vectors using the osmo-auc-gen
utility, it used to print values like this:
AUTN: f7 55 bc 47 de d0 00 00 f9 ed 4b 3f 6c 2a 97 6f
which is quite difficult to copy+paste on the terminal. Now it
generates the following format:
Change-Id: I2805615e0c2087ca632e0658b37a9e06929620b6
AUTN: f755bc47ded00000f9ed4b3f6c2a976f
Reviewed-on: https://gerrit.osmocom.org/164
Reviewed-by: Harald Welte <laforge@gnumonks.org>
Tested-by: Jenkins Builder
CC osmo-auc-gen.o
osmo-auc-gen.c: In function 'main':
osmo-auc-gen.c:216:3: warning: implicit declaration of function
'time' [-Wimplicit-function-declaration]
osmo-auc-gen.c:217:3: warning: implicit declaration of function ‘time’ [-Wimplicit-function-declaration]
osmo-auc-gen.c:249:3: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘uint64_t’ [-Wformat]
Fixes: Coverity CID 1040668
If you want to use eap-sim-file with strongswan, you need a triplets.dat
file in a specific format. osmo-auc-gen can now generate the respective
format automatically.
Thsi tool usses libosmocore in order to generate 2G and 3G
authentication vectors from private key material, exactly like an AuC
would produce them in a real network.
Neels Hofmeyr
Harald Welte
Holger Hans Peter Freyther