Landslide VoLTE: how to config landslide to pass IMS AKA authentication with real IMS/HSS and how to troubleshoot authentication failure during IMS AKAv1 authentication.

Doc ID: FAQ19312

Printer Friendly Email Article Link

Landslide VoLTE: how to config landslide to pass IMS AKA authentication with real IMS/HSS and how to troubleshoot authentication failure during IMS AKAv1 authentication.

Environment/Versions

Landslide 4G VoLTE or 5G Vo5G authentication test

Answer

This article shows how to configure Landslide using landslide client GUI to test VoLTE authentication with real MMS/HSS device,
and how to troubleshoot and debug in case of authentication failure, below setup suggestion is based on typical MME nodal with
VoLTE over IPsec option enabled.
The most important thing to such test is to make sure the UE's secret Key (also called Ki somewhere else) and OP
(or Opc value depends on carrier's choice of using OP or OPc) configured in landslide matched the values on HSS side, otherwise,
you'll get authentication failure.
Please refer to attached IMS call flow pdf document for the details of a typical IMS registration based on IMS AKA,
where HSS sends RAND, AUTN, XRES, CK, IK to CSCF, and CSCF returens RAND, AUTN value to UE, challenges UE
to sends back RES value computed based on RAND/secret key/OP(OPc) to prove UE has the correct credential.
Also, before UE sends back the RES value, it would also compute the MAC value based on RAND/AUTN/secret key/OP(OPc)
and verify if the computed MAC matches the MAC value in AUTN from IMS, if matched, client side's verification pass and only after that,
UE would send back the RES value. Once the CSCF receives the RES(which is part of the RESPONSE value in second register message),
it would compare it to the value that CSCF computes based on the XRES value from HSS and other parameter, if not matched,
CSCF would reject the registration request from UE.
Below is the setup guide on landslide based on IMS AKAv1:
1. In VoLTE tab of MME nodal, setup the correct value of OP or OPc, AKA version, IPsec ESP data mode, security algorithm and
Encryption algorithm in security Tab.
Those value shall match those on IMS/HSS side. Landslide support IMS AKA version V1 or V2, below example is based on V1.
one important thing is that, if your OP(OPc) and secret key value is HEX based, you need add a prefix "0x" before the real HEX values
to tell landslide it's HEX based values,
otherwise, Landslide would convert it into other values based on ASCII format which may not be the value you are expecting.

2. pay attention to the checkbox "add @domain to the username field" in the same tab, this option is to tell landslide whether to
include domain as a suffix appended to the username,see below message details. the username will be one of the input when
computing the RESPONSE value.

3. In the phonebook tab, the most important value to be configured is the secret key, public username, private username, realm,
domain, they should be also matched with those on IMS/HSS side.

The secret key is supposed to be unique for each UE, so if you are running mulitiple UEs test, you could setup the list of secret
keys by our auto-increment tool (if they are sequential) or by test data file (if they are not sequential).
The public username is the username in sip register and invite's request URI, while the private username here is the one that will
be used for authentication which is present in authorization header.

Remember, when troubleshooting authentication failure issue, below parameter matters to the final result of response value,
so the frist thing of debugging such issue is to check whether those values are matched on both sides:
Secret Key (Ki), OP (or Opc), private username for authentication (and whether include domain), AKA version (V1 or V2), and
constant value of C1/C2/C3/C4/C5/R1/R2/R3/R4/R5 for milenage algorithm used in authentication procedure.
The constant value of C1/C2/C3/C4/C5/R1/R2/R3/R4/R5 is defined by 3GPP standard and not configurable in landslide, so in most case,
you don't need to worry about those constant values as all carriers are supposed to use those default values.
The only exception is T-mobile, as T-mobile is using its own values for C1/C2/C3/C4/C5/R1/R2/R3/R4/R5 different from 3GPP standards,
if that's the case, refer to KB article https://docid.spirent.com/SOL14108 for how to configure landslide to use T-mobile based values.
If the C1/C2/C3/C4/C5/R1/R2/R3/R4/R5 values for milenage algorithm are not matched, you will aslo see authentication failure.
The default values of those constants defined in 3GPP spec could be found below.

Once you finish above configuration, if you see authentication failure issue in your test, follow the below steps to debug
and manually calculate the RESPONSE value,then manually compare it to the XRES from the HSS
(you need to get this debug info from HSS), by that, you could check whether Secret Key/OP is setup correctly.
Sometimes if HSS's XRES value is calculated based on OPc while landslide's RES value is calcuated based on OP,
you would also get mismtached RES/XRES value.
In that case, you can refer to the debug tool in KB article https://docid.spirent.com/SOL14108 to troubleshoot that.
Below is one example of how to manually calculate the response value in register message based on
RAND/AUTN/NONCE/secret key/OP and AKA version 1:
Attached .ste file and pcap file is one example of IMS AKAv1 authentication failure, it's caused by mismatched
username used by landslide and DUT to calculate RESPONSE value,
Landslide was using 996890000103000@one.att.net while DUT was using 996890000103000@private.att.net.
And we could manually calculate it to figure it out.

In this eample(refer to attached .ste file and pcap file), both secret key and OP was configured as
0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, to manually calculate RESPOSNE value,
we need to get NONCE value from 401 unauthorized message first, then retrieve RAND/AUTN value from NONCE,
then calcualte RES value based on milenage algorithm,
then calcualte the final RESPONSE value to be sent in second register message.

1. From the attache pcap file, we could see the NONCE value in 401 message is
“5Y6htWUK4hbrDJNoq/hkMQ0IYq3OpwD/sVdRtl57Z+w=”,according to RFC3310 (also attached),
the nonce value is a base64 encoded string with first 16 bytes as RAND value and second 16 bytes as AUTN value.

There is online tool https://cryptii.com/base64-to-hex whic you can use to manully decode the
base64 encoded values into raw hex values, with this tool,
we get the decoded value "e5 8e a1 b5 65 0a e2 16 eb 0c 93 68 ab f8 64 31 0d 08 62 ad ce a7 00 ff b1 57 51 b6 5e 7b 67 ec",
So according to RFC2045 which is the definition of base64 encoding, after base64 decoding,
the RAND and AUTN value should be e58ea1b5650ae216eb0c9368abf86431 and 0d0862adcea700ffb15751b65e7b67ec.

below is the details of RFC3310 definition about NONCE value and base64 encoding:
RFC3310:
3.2 Creating a Challenge
              nonce
      A parameter, which is populated with the Base64 [4] encoding of
      the concatenation of the AKA authentication challenge RAND, the
      AKA AUTN token, and optionally some server specific data, as in
      Figure 1.

      Example:


       0                               1                              2                             3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                                                                               |
      |                            RAND                                                                         |
      |                                                                                                               |
      |                                                                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                                                                              |
      |                            AUTN                                                                        |
      |                                                                                                               |
      |                                                                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Server Data...
      +-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: Generating the nonce value.

        RFC 2045                Internet Message Bodies            November 1996

                    Table 1: The Base64 Alphabet

     Value Encoding Value Encoding Value Encoding Value Encoding
         0 A            17 R            34 i            51 z
         1 B            18 S            35 j            52 0
         2 C            19 T            36 k            53 1
         3 D            20 U            37 l            54 2
         4 E            21 V            38 m            55 3
         5 F            22 W            39 n            56 4
         6 G            23 X            40 o            57 5
         7 H            24 Y            41 p            58 6
         8 I            25 Z            42 q            59 7
         9 J            26 a            43 r            60 8
        10 K            27 b            44 s            61 9
        11 L            28 c            45 t            62 +
        12 M            29 d            46 u            63 /
        13 N            30 e            47 v
        14 O            31 f            48 w         (pad) =
        15 P            32 g            49 x
        16 Q            33 h            50 y

2. Based on the above RAND value and AUTN value, secret key 0x aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa and
OP 0x aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
we could get RES value 5C33FEDD8A4E7295 using the support troubleshooting tool “milenage algorithm calculator".
The tool could be found in KB article https://docid.spirent.com/SOL14108
Also, based on below tool, we could let it compuate the MAC value based on RAND value and AUTN value,
secret key and OP, which is 0xb15751b65e7b67ec in our case.
It should match the last 8 bytes of AUTN which we retrieved from NONCE in 401 message from IMS.
If the mac value computed by lanslide doesn't match the value in AUTN from IMS, landslide client would fail the authentication
due to the mac verification on client side failed.
In this case, the mac computed by our tool match the value from AUTN in 401 message, it proves the secret key and OP
configured in landslide is correct, otherwise,
we would have got a mismatched MAC value already. So there must be other issue in configuration that caused currect
auth failure, let's continue debugging.

you can also let this tool print out the those constant values defined in 3GPP standards.

3.According to RFC2617, the final response value sent by client is calculated baesd on below formula:

        H(A1)       = hash(username-value: realm-value:passwd)

           where passwd is the RES value calculated in step2 
(RFC3310 chapter 3.3 defines The resulting AKA RES parameter is treated as a 
"passwd" when calculating the response directive of RFC 2617.)

        H(A2)   = hash(sip-Method:digest-uri-value)

        request-digest in final response  =  KD ( H(A1),nonce-value

                                          ":" nc-value

                                          ":" cnonce-value

                                          ":" qop-value

                                          ":" H(A2)

        Since previous calculated RES value is hex value 5C33FEDD8A4E7295,  and landslide would 
automatically use the private username and realm in phonebook for HA1, 
so the the H(A1) would be : Hash(996890000103000@one.att.net:one.att.net:\0x5C33FEDD8A4E7295’) in our case.

                  H(A2) should be: Hash(REGISTER:sip:one.att.net).
       the hash algorithm used here for H(A1) and H(A2) should be MD5 HASH which is specified
 in authorization header of 401 message from IMS.
4.  Convert the ascii value of the first part of A1 into hex before doing hash(A1), we got the
 hex value of the whole A1 is 
393936383930303030313033303030406F6E652E6174742E6E65743A6F6E652E6174742E6E65743A5C33FEDD8A4E7295.
5. Using the online MD5 Hash tool: https://cryptii.com/md5-hash, by inputing the above hex value,
we could get the MD5 hash value of H(A1) is:

ec9d3ff850fc4bff584550db50fef4b4.

FOR H(A2), using the same online tool, we got value 86e3f6ea2c0e12cdf079e89ac0eaba60.


6. The last step is to Calculate the final response based on HA1 and HA2.
    According to spec RFC 2617:

request-digest in final response 
 =  hash( H(A1),nonce-value":" nc-value":" cnonce-value":" qop-value":" H(A2) 
so in our case: it shouldb be:

request-digest in final response  
= hash(ec9d3ff850fc4bff584550db50fef4b4:5Y6htWUK4hbrDJNoq/hkMQ0IYq3OpwD/sVdRtl57Z+w=:00000001:298c:auth:86e3f6ea2c0e12cdf079e89ac0eaba60)
where NONCE,QOP could be found in 401 message, CNONCE(client random value) 
and NC-value(nonce count value) are generated by client and could be found in the second register's authorization header.

By input the ascii value ‘ec9d3ff850fc4bff584550db50fef4b4:5Y6htWUK4hbrDJNoq/hkMQ0IYq3OpwD/sVdRtl57Z+w=:00000001:298c:
auth:86e3f6ea2c0e12cdf079e89ac0eaba60' in online tool,
we got the final response value 92ac9933f846fb15a17707b0048dc1c9  which is the same as 
what we saw in second register sent by landslide.



So seems like the manually computed response value matches the one landslide sent out in
 second regsiter message, so nothing wrong? 
Then why IMS rejected it, interesting?
If we look into the details of the second register message, we could find out that the 
username value in authorization is "996890000103000@private.att.net". 
wait a minute, why "996890000103000@private.att.net"? the realm and domain we configured in 
phonebook is one.att.net, 
and the username we configured in phone is 996890000103000, 
so the username used for above mentioned H(A1) should be "996890000103000@one.att.net", 
and this is also the username value landslide used to compute H(A1) and how we used to compute 
H(A1) using online tools.
Now if we look into the sip message editor, we could find out that user manually customized the username 
value to "{from-uri-user}@private.att.net" for some reason, 
that must be the reason we saw such unexpected username value in final message sent out by landslide.
So in this case, IMS was using username "996890000103000@private.att.net" retrieved from
 second register message sent by landslide to compute H(A1), 
while Landslide was using the "private username" + "realm" configured in phonebook 
(which is 996890000103000@one.att.net) to compute H(A1), 
that's the root cause of mismatched response value reported by IMS. 
The reason of landslide doing this is that landslide would calculate the final response and populate 
the message first, then apply the customized header in message editor, 
so the replacment of username value by the one customized in message editor happens after final response calculation.
Now if we get the debug info from IMS/HSS, find the expected response value inside IMS, and we 
compute the same response based on username 
"996890000103000@private.att.net" with above mentioned tools, we could find out we will get a 
matched response value.
so the solution is just to make sure we send out a matched username in message with the one 
landslide used to compute H(A1), 
either change value in message edtior back to phonebook's value, or change phonebook accordingly.