|
IMS |
||
|
Registration with Authentication
As in almost every communication system working in a large scale, the first step for IMS is also Registration process. Through this process, a UA (User Agent or IMS Client) is registered in a centrol control center (CSCF or IMS Server). Registration in any communication is very similar to the process we go through when we visit a company with high security (usually big companies). Basically a conversation as follows goes on during the registration. i) Hey, CSCF.. I want to register myself in your service database ii) OK.. may I have authentication information please ? (this is like 'May have your name and password please' ?) iii) Sure, here you go. iv) Thank you.. let me check in our security system..... OK. You are accepted by the system. If you look into the details of the protocol sequence and the contents of the message, you should be able to find all the information (parameters) mentioned above in common language. Actually from the details of these message and the contents, you can figure out the most of informations about a UA and the registration center (CSCF, Authentication Center).. and can do a lot of reverse engineering for troubleshooting.
Note 1 : In real life as an engineer working in this area, once you see the first 'REGISTER' message you can get a lot of information and use that information for various case of troubleshooting. However, there are many cases where you would not see the first REGISTER message at all. This is the trickest case... meaning 'I am sure that there are some critical issues.. but I have no idea on what would be the problem.. and I don't even know where to start for the troubleshooting'. In this case, I suggest you to refer to this Check List first.
Note 2 : As I mentioned, you would see a lot of the detailed information in the messages of the Registration process and you may ask 'Where are all these information from ?'. How a UA (UE) knows what kind of information it has to put in REGISTER message ? In early stage of IMS stack implementation (usually in development stage), it was stored or hardcoded in a file or protocol stack source code. But now (at the stage of commercialization) it usually come from USIM or ISIM (Mostly from ISIM). Refer to following pages for the details if you are interested.
Following is overall protocol sequence for IMS Registration and I also put down some examples of each message below the sequence diagram. (The Registra in this diagram can be considered as CSCF)
Following is an example for this process.
Step 1 : REGISTER -------------------------------- REGISTER sip:test.3gpp.com SIP/2.0 f: <sip:+11234567890@test.3gpp.com>;tag=2722997041 t: <sip:+11234567890@test.3gpp.com> CSeq: 575513373 REGISTER i: 2722997021_2363003016@2001::21f:29ff:fe7c:8f51 v: SIP/2.0/UDP [2001::21f:29ff:fe7c:8f51]:5060;branch=z9hG4bK656994275 Max-Forwards: 70 m: <sip:+11234567890@[2001::21f:29ff:fe7c:8f51]:5060> P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=3114800102FFFFFFF l: 0 Authorization: Digest uri="sip:test.3gpp.com", username="001010123456789@test.3gpp.com", response="", realm="test.3gpp.com", nonce="" Expires: 7200
Note 1 : Make it sure the 'realm' parameter matches Authentication server domain name. If this does not matches the authentication server, CSCF may send 'Error Code'.
Another Example : Basically it is up to network (CSCF) to perform Authentication or not. But sometimes UE may try to mandate the Authentication even with IPSec as shown in the following example. But still CSCF can ignore this requirement and go without Authentication and IPSec.. in this case (in case of skipping Authentication/IPSec) UE may not initiate any call (e.g, VoLTE). REGISTER sip:test.3gpp.com SIP/2.0 f: <sip:001010123456789@ims.mnc246.mcc081.3gppnetwork.org>;tag=2922225 t: <sip:001010123456789@ims.mnc246.mcc081.3gppnetwork.org> CSeq: 2922203 REGISTER i: 2922206_181933240@2001:0:0:1::3 v: SIP/2.0/TCP [2001:0:0:1::3]:5060;branch=z9hG4bK3941737881 Max-Forwards: 70 m: <sip:001010123456789@[2001:0:0:1::3]:5060>;+sip.instance="<urn:gsma:imei:35425006-000655-0>";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.smsip Route: <sip:[2001:0:0:1::2]:5060;lr> l: 0 Authorization: Digest uri="sip:test.3gpp.com", username="001010123456789@test.3gpp.com", response="", realm="test.3gpp.com", nonce="" Expires: 600000 Require: sec-agree Proxy-Require: sec-agree k: path,sec-agree Allow: INVITE,BYE,CANCEL,ACK,NOTIFY,UPDATE,REFER,PRACK,INFO,MESSAGE,OPTIONS Security-Client: ipsec-3gpp; alg=hmac-md5-96; ealg=des-ede3-cbc; spi-c=799251570; spi-s=1387593208; port-c=8006; port-s=8906, ipsec-3gpp; alg=hmac-md5-96; ealg=aes-cbc; spi-c=799251570; spi-s=1387593208; port-c=8006; port-s=8906, ipsec-3gpp; alg=hmac-md5-96; ealg=null; spi-c=799251570; spi-s=1387593208; port-c=8006; port-s=8906, ipsec-3gpp; alg=hmac-sha-1-96; ealg=des-ede3-cbc; spi-c=799251570; spi-s=1387593208; port-c=8006; port-s=8906, ipsec-3gpp; alg=hmac-sha-1-96; ealg=aes-cbc; spi-c=799251570; spi-s=1387593208; port-c=8006; port-s=8906, ipsec-3gpp; alg=hmac-sha-1-96; ealg=null; spi-c=799251570; spi-s=1387593208; port-c=8006; port-s=8906
Step 2 : 401 UNAUTHORIZED -------------------------------- SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP [2001::21f:29ff:fe7c:8f51]:5060;branch=z9hG4bK656994275 From: <sip:+11234567890@test.3gpp.com>;tag=2722997041 To: <sip:+11234567890@test.3gpp.com>;tag=T3E04A4B5 Call-ID: 2722997021_2363003016@2001::21f:29ff:fe7c:8f51 CSeq: 575513373 REGISTER Content-Length: 0 WWW-Authenticate: Digest realm="test.3gpp.com", nonce="qlWqVapVqlWqVapVqlWqVUUQA5HEt9VVZ3t1TM221cg=", qop="auth", opaque="MTcyMjU3ODA2NDo=SU1TLVNJUCBTZXJ2ZXI=", algorithm=AKAv1-MD5 P-Associated-URI: <sip:+11234567890@TEST.3GPP.COM> P-Associated-URI: <tel:+11234567890>
Note 1 : 'realm' parameter in this message should match the 'realm' parameter in Step 1. Otherwise, UE may not proceed to next step. Note 2 : 'algorithm' specified here should be the one supported by UE. Otherwise, UE may not proceed to next step. Note 3 : 'nonce' carries a kind of Authentication made up of "RAND + AUTN + Server Specific Data" Note 4: "nonce" is defined as follows in rfc3310. nonce is a parameter, which is populated with the Base64 encoding of the concatenation of the AKA authentication challenge RAND, the AKA AUTN token, and optionally some server specific data, as in following diagram from RFC 3310 Figure 1.
Base64 Encoding is based on following table defined in RFC 2045 6.8. Base64 Content-Transfer-Encoding.
Step 3 : REGISTER ----------------------------------- REGISTER sip:test.3gpp.com SIP/2.0 f: <sip:+11234567890@test.3gpp.com>;tag=2722997284 t: <sip:+11234567890@test.3gpp.com> CSeq: 575513374 REGISTER i: 2722997021_2363003016@2001::21f:29ff:fe7c:8f51 v: SIP/2.0/UDP [2001::21f:29ff:fe7c:8f51]:5060;branch=z9hG4bK843051065 Max-Forwards: 70 m: <sip:+11234567890@[2001::21f:29ff:fe7c:8f51]:5060> P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=3114800102FFFFFFF l: 0 Authorization: Digest username="001010123456789@test.3gpp.com", realm="test.3gpp.com", uri="sip:test.3gpp.com", qop=auth, nonce="qlWqVapVqlWqVapVqlWqVUUQA5HEt9VVZ3t1TM221cg=", nc=00000001, cnonce="11259375", algorithm=AKAv1-MD5, response="a3f549b13f477562f4445b7277cd83c1", opaque="MTcyMjU3ODA2NDo=SU1TLVNJUCBTZXJ2ZXI=" Expires: 7200
Note 1 : 'realm' parameter in this message should match the 'realm' parameter in Step 2. Note 2 : 'algorithm' parameter in this message should match the 'algorithm' parameter in Step 2. Note 3 : 'Expires : 7200' means that the registration should be 'renewed' within 7200 seconds.
Step 4 : 200 OK ----------------------------------- SIP/2.0 200 OK Via: SIP/2.0/UDP [2001::21f:29ff:fe7c:8f51]:5060;branch=z9hG4bK843051065 From: <sip:+11234567890@test.3gpp.com>;tag=2722997284 To: <sip:+11234567890@test.3gpp.com>;tag=T44F6AE74 Call-ID: 2722997021_2363003016@2001::21f:29ff:fe7c:8f51 CSeq: 575513374 REGISTER Contact: <sip:+11234567890@[2001::21f:29ff:fe7c:8f51]:5060>;q=0.500;expires = 7200 Content-Length: 0 Date: Mon, 22 Apr 2013 15:43:15 GMT Authentication-Info: qop=auth, rspauth="a3f549b13f477562f4445b7277cd83c1", cnonce="11259375", nc=00000001 P-Associated-URI: <sip:+11234567890@TEST.3GPP.COM> P-Associated-URI: <tel:+11234567890> P-Associated-URI: <sip:+11234567890@TEST.3GPP.COM> P-Associated-URI: <tel:+11234567890>
|
||
