IPSec using Security Agreement (in 3GPP R5)

In this post I will try to explain how security mechanisms are negotiated between an IMS Client and the Proxy CSCF (only SIP headers) and how to setup SAs using Linux IPSec tools.
The main purpose of Security agreement is to agree on which mechanisms, algorithms or security parameters to use.

There are five main mechanisms used in VoIP networks:

1. digest
2. tls
3. ipsec-ike
4. ipsec-man
5. ipsec-3gpp

We will focus on 3GPP IPSec because the IMS makes it mandatory.

The security mechanism to use is known after the negotiation between the IMS Client and the Proxy CSCF succeeds. This negotiation is performed during the IMS registration and authentication procedures.

Three new SIP header fields have been defined, namely Security-Client, Security-Server and Security-Verify.

Call Flow

IMS Client         P-CSCF              S-CSCF

|                    |                  |

|----(1)REGISTER---->|                  |

|                    |                  |

|                    |---(2)REGISTER--->|

|                    |                  |

|                    |<-----(3) 401 ----|

|                    |                  |

|<----(4) 494/401----|                  |

|                    |                  |

|<==IPSec in place==>|                  |

|                    |                  |

|----(5)REGISTER---->|                  |

|                    |----(6)REGISTER-->|

|                    |                  |

|                    |<---(7) 200 OK----|

|<---(8) 200 OK------|                  |

|                    |                  |

In step (1) the IMS Client sends an unprotected registration request including the security-client header. The Client must indicate that it is able to negotiate security mechanism by adding “Require” and “Proxy-Require” headers. The security-client header includes two ports (client and server ports) that the client wants to negotiate with the proxy CSCF.

In step (2) the Proxy CSCF forwards the request to the Serving CSCF.

In step (3) the Serving CSCF (registrar) challenges the Proxy CSCF. The 401 response is sent to the Proxy CSCF (challenge parameters are under WWW-Authenticated header). The Serving CSCF must include the security-server header.

In step (4) the Proxy CSCF forwards the 401/494 response to the IMS Client. At this stage the Proxy CSCF opens the IPsec security association (SA) for the IMS Client. The IMS Client also setup a SA (this is a temporary SA).

The lifetime of the created SA (between the IMS Client and the Proxy CSCF) is equal to the value of reg-await-auth timer.

In step (5) the IMS Client sends a new registration (to the Proxy CSCF) request including its credentials and copies the content of security-server header to the security-verify header. Before forwarding the request to the Serving CSCF, the Proxy CSCF will check that the previous security-server header and the security-verify headers (added by the IMS Client) are the same. If these values are different, the Proxy CSCF sends an error message to the IMS Client and terminates the created SAs.

In step (6) the Proxy CSCF forwards the request to the Serving CSCF.

In step (7) the Serving CSCF authenticates the IMS Client, and responds with 200 OK.

In step (8) the Proxy CSCF forwards the response to the IMS Client. At this step new SAs will be created. The temporary SAs will be destroyed (or not) by the Proxy CSCF.

Messages

(1)
REGISTER sip:pcscf.open-ims.test SIP/2.0
Security-Client: ipsec-3gpp; alg=hmac-md5-96; spi-c=1111; spi-s=2222; port-c=5062; port-s=5064
Require: sec-agree
Proxy-Require: sec-agree

(4)
SIP/2.0 [494 Security Agreement Required / 401 Unauthorized]
Security-Server: ipsec-3gpp; q=0.1; alg=hmac-md5-96; spi-c=3333; spi-s=4444; port-c=5066; port-s=5068

(5)
REGISTER sip:pcscf.open-ims.test SIP/2.0
Security-Client: ipsec-3gpp; alg=hmac-md5-96; spi-c=1111; spi-s=2222; port-c=5062; port-s=5064
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-md5-96; spi-c=3333; spi-s=4444; port-c=5066; port-s=5068
Require: sec-agree
Proxy-Require: sec-agree

--> Captures done with Mercuro IMS Client.

Setting up SAs using Linux Tools

Here we suppose that:
- We are using Ubuntu (Linux Kernel 2.6 + KAME-tools)
- the Proxy-CSCF address is '192.168.0.10' and Mercuro IMS Client address is '192.168.0.11'
- for secure ports see above SIP capture
- protocol is esp
- algorithm is 'hmac-md5'
- encrypt-algorithm is 'des-ede3-cbc'
- mode is 'transport'
- confidentiality key is '123456789012123456789012' (see function f2345 in 3GPP milenage algorithms)
- integrity key is '1234567890123456' (see function f2345 in 3GPP milenage algorithms)

1. Install the tools

sudo apt-get install ipsec-tools

2. Edit /etc/ipsec-tools file and add the following script

#Incoming Requests [US <- PC]
spdadd 192.168.0.10/32[5066] 192.168.0.11/32[5064] udp -P in ipsec esp/transport//require;
add 192.168.0.10 192.168.0.11 esp 2222 -m transport -E des-ede3-cbc "123456789012123456789012" -A hmac-md5 "1234567890123456";

#Incoming Replies [UC <- PS]
spdadd 192.168.0.10/32[5068] 192.168.0.11/32[5062] udp -P in ipsec esp/transport//require;
add 192.168.0.10 192.168.0.11 esp 1111 -m transport -E des-ede3-cbc "123456789012123456789012" -A hmac-md5 "1234567890123456";

#Outgoing Requests [UC -> PS]
spdadd 192.168.0.11/32[5062] 192.168.0.10/32[5068] udp -P out ipsec esp/transport//unique:1;
add 192.168.0.11 192.168.0.10 esp 4444 -m transport -u 1 -E des-ede3-cbc "123456789012123456789012" -A hmac-md5 "1234567890123456";

#Outgoing Replies [US -> PC]
spdadd 192.168.0.11/32[5064] 192.168.0.10/32[5066] udp -P out ipsec esp/transport//unique:2;
add 192.168.0.11 192.168.0.10 esp 3333 -m transport -u 2 -E des-ede3-cbc "123456789012123456789012" -A hmac-md5 "1234567890123456";

3. Run the script

sudo /etc/init.d/setkey start

The same can be done under Windows vista using WFP(Windows Filtering Platform) API. For more information on How IPSec (in IMS context) feature could be implemented under Windows you can contact Mercuro Team at [tech dot mercuro -at- inexbee dot com].

For more information visit:
http://www.mercuro.net
http://www.ietf.org/rfc/rfc3329.txt
http://www.arib.or.jp/IMT-2000/V310Sep02/T63/Rel5/33/A33203-520.pdf
http://www.arib.or.jp/IMT-2000/V310Sep02/S3g/Rel5/24/24229-510.pdf
http://www.3gpp.org/FTP/TSG_SA/WG3_Security/TSGS3_24_Helsinki/Docs/PDF/S3-020385.pdf

Proxy and Service Route discovery in IMS

In this post I will try to explain how these two SIP extensions are used in IMS context and show differences between them.
Service Route discovery is an important mechanism in IMS context. The Service Route discovery mechanism usage is explained in RFC 3608 and 3GPP TS 24.229 and Path extension in RFC 3327.

Syntax

Service-Route = "Service-Route" HCOLON sr-value *( COMMA sr-value)
sr-value = name-addr *( SEMI rr-param )
Path = "Path" HCOLON path-value *( COMMA path-value )
path-value = name-addr *( SEMI rr-param )

Usage

Header field          where   proxy ACK BYE CAN INV OPT REG

___________________________________________________________

Path                    R       ar   -   -   -   -   -   o

Path                   2xx      -    -   -   -   -   -   o

Service-Route          2xx      ar   -   -   -   -   -   o

The Service-Route header is inserted by the S-CSCF in the 200 (OK) responses to SIP REGISTER requests. The Service-Route header contains the S-CSCF SIP URI with a character string indicating the request type (mobile-originating or mobile-terminating). It is stored by the P-CSCF and associated to the registered public user identity. The UE MAY also store the value of the Service-Route header field in an association with the address-of-record for which the REGISTER transaction had registered a contact.
For example: <sip:orig@scscf.v4.ims.test:6060;lr>.

Support for the Path header extension MAY be indicated by a UA by including the option-tag "path" in a Supported header field. The Path header is inserted by the P-CSCF while forwarding REGISTER requests and contains its own SIP URI. This value is inserted by the P-CSCF to inform the S-CSCF where all terminating requests MUST be routed.
For example: <sip:term@pcscf.v4.ims.test:4060;lr>.
Both headers are only applicable to the 200 (OK) response of REGISTER requests and shall be supported by the P-CSCF (but shall not be supported by the MGCF or the BGCF).

Call Flow

IMS Client         P-CSCF             ICSCF                  S-CSCF

|                    |                  |                       |

|----(1)REGISTER---->|                  |                       |

|                    |                  |                       |

|<----(2)401---------|                  |                       |

|                    |                  |                       |

|----(3)REGISTER---->|                  |                       |

|                    |                  |                       |

|<----(4)200---------|                  |                       |

|                    |                  |                       |

|----(5)SUBSCRIBE--->|                  |                       |

|                    |                  |                       |

|<----(6)200---------|                  |                       |

|                    |                  |                       |

|----(7)REGISTER---->|                  |                       |

|                    |                  |                       |

|<----(8)200---------|                  |                       |

|                    |                  |                       |

|----(9)REGISTER---->|                  |                       |

|                    |                  |                       |

|<----(10)200--------|

1-The UE sends the initial REGISTER request without Service-Route header and includes the option-tag "path" in the Supported header field. Before forwarding this request to the I-CSCF, the P-CSCF will add its SIP URI in the Path header to inform the S-CSCF where to route terminating requests.

REGISTER sip:v4.ims.test SIP/2.0
Supported: path
CSeq: 901 REGISTER

2-The P-CSCF sends an authentication challenge (401/407) to the UE. This response already contains Path header added by the P-CSCF in step 1.

SIP/2.0 401 Unauthorized - Challenging the UE
Path: <sip:term@pcscf.v4.ims.test:4060;lr>
CSeq: 901 REGISTER

3-The UE sends a new registration request with authentication information.

REGISTER sip:v4.ims.test SIP/2.0
Supported: path
CSeq: 902 REGISTER

4-The P-CSCF forwards the 200 OK (from the S-CSCF) response and stores the Service-Route value. At this point the Service-Route value is associated to the registered public user identity. In UE side the Service-Route value is also saved to be reused in next requests.

SIP/2.0 200 OK - SAR succesful and registrar saved
Path: <sip:term@pcscf.v4.ims.test:4060;lr>
Service-Route: <sip:orig@scscf.v4.ims.test:6060;lr>
CSeq: 902 REGISTER

5-The UE try a first presence subscription (watcher info package). New Route header MUST be added to all initial requests. This header contains the P-CSCF address, plus the associated S-SCSCF URI (Service Route) learnt during Service Route discovery.

SUBSCRIBE sip:mamadou@v4.ims.test SIP/2.0
Route: <sip:v4.ims.test:4060;lr=true;transport=tcp>,<sip:orig@scscf.v4.ims.test:6060;lr>
Event: presence.winfo
CSeq: 301 SUBSCRIBE

6-The P-CSCF forwards the response to the UE. You can notice that we new Record-Route header. This header contains that dialog routes.

SIP/2.0 200 OK
Record-Route: <sip:mo@scscf.v4.ims.test:6060;lr>,<sip:mo@pcscf.v4.ims.test:4060;lr>
CSeq: 301 SUBSCRIBE

7-UE initiated reregistration. MUST not contain headers Path or Service-Route.

REGISTER sip:v4.ims.test SIP/2.0
Supported: path
CSeq:903 REGISTER

8-Reregistration response. This response contains both Path and Service-Route headers.

SIP/2.0 200 OK - SAR succesful and registrar saved
Path: <sip:term@pcscf.v4.ims.test:4060;lr>
Service-Route: <sip:orig@scscf.v4.ims.test:6060;lr>
CSeq: 903 REGISTER

9-UE initiated deregistration. MUST not contain headers Path or Service-Route.

REGISTER sip:v4.ims.test SIP/2.0

Supported: path
Contact: <sip:[::::]:1010>;expires=0
CSeq:90 4 REGISTER

10-Deregistration response.

SIP/2.0 200 OK - SAR succesful and registrar saved
Path: <sip:term@pcscf.v4.ims.test:4060;lr>
Service-Route: <sip:orig@scscf.v4.ims.test:6060;lr>
CSeq: 903 REGISTER

Conclusion

Requests	Routes
Initial REGISTER	None
REREGISTRATION	None
DEREGISTRATION	None
Initial requests (except REGISTER)	P-CSCF and Service Routes
Early* dialogs without dialog routes	P-CSCF and Service Routes
Early* dialogs with dialog routes	Dialog Routes
Confirmed* dialogs	Dialog Routes

(*) A dialog is in the "early" state when it is created with a provisional response, and then transition to the "confirmed" state when a 2xx final response arrives. For other responses, or if no response arrives at all on that dialog, the early dialog terminates.
Be careful:
- PUBLISH request does not create dialog
- SUBSCRIBE, INVITE, … requests create dialog

New Release of Mercuro IMS Client (4.0.1011)

The latest Beta release of Mercuro IMS Client(Version 4.0.1011) is now available for download at http://www.mercuro.net/.
This release comes with a lot of fixes and improvements. Here is a non-exhaustive list:

- Add P-Preferred-Identity for non-REGISTER dialogs and standalone
transactions
- Add loop detection on PUBLISH and SUBSCRIBE to deal with
mis-configured proxies
- Add support full support for rport parameter when registering
- Add pre-authorization of public identity in pres-rules to enable
self-presence awareness
- Add support for Do Not Disturb
- Add support for Auto-Answering in Voice/Visio calls
- Enhance shutdown time when closing the client (connected or not)
- Fix the route headers for non-REGISTER dialogs and standalone transactions
- Fix the handling of multiple Contact bindings
- Fix the handling of multiple P-Associated-Uri headers
- Fix the malformed fmtp parameter for iLBC and Speex codecs
- Fix the User-Agent string for XCAP request
- Fix the mis-saving of extended properties when using OMA Directory
discovery
- Fix the focus activation when receiving an INVITE request
- Fix a crash when using OMA Directory discovery with multiple document
per AUID
- Fix a crash when watcher-info document has no xmlns attribute
- Fix a crash when an Uri does not have a scheme in presence document
- Fix a crash when an INVITE has an incomplete Uri
- Fix a crash when an header contains an odd number of quotes.
- ....

your feedback is welcomed (http://feedback.mercuro.net/).

New Release of Mercuro IMS Client (4.0.899)

The latest Beta release of Mercuro IMS Client(Version 4.0.899) is now available for download at http://www.mercuro.net/.
This release comes with a lot of fixes and improvements. Here is a non-exhaustive list:

- Change default document names in XDM (WARN: it can potentially breaks existing configuration)
- Add support for expiration negotiation in REGISTER (3GPP TS-24.229)
- Add full support for "qop" authorization attribute (RFC-2617)
- Add support for Uri negotiation in XDM RLS Services (RFC-4825)
- Add message waiting indication event package support (RFC-3842)
- Add support for XCAP Capabilities retrieval (RFC-4825)
- Add support for OMA XCAP Directory (OMA-TS-XDM_Core-V1_1)
- Add support for '423 Interval Too Brief' responses (RFC-3261)
- Add SHA-1 hash computation in 'file-selector' header for MSRP file transfers (IETF draft-ietf-mmusic-file-transfer-mech)
- Add meaningful status bar to make long-lasting operation bearable
- Fix missing authorization header in initial REGISTER (3GPP TS-24.229)
- Fix invalid PUBLISH request when dealing with 401/407 responses
- Fix authorization handling in MSRP dialogs (401/407 challenges)
- Fix invalid presence rules document when dealing with authorizations
- Fix a crash when making a call to a bogus Uri
- Fix minor UI problems

Mercuro IMS Client is in beta stage and has been tested with many IMS Core (provided by our technical partners). To improve interoperability between Mercuro IMS Client and your IMS Core/Client we are willing to give you some help and tips (send us a mail to [tech dot mercuro -at- inexbee dot com]).

For more information about Mercuro IMS Client visit http://www.mercuro.net/.

New Release of Mercuro IMS Client (4.0.864)

The latest Beta release of Mercuro IMS Client(Version 4.0.864) is now available for download at http://www.mercuro.net.
This release comes with a lot of fixes and improvements. Here is a non-exhaustive list:

- Add new audio and video codecs (GSM, Speex, Theora, etc)
- Full screen mode support
- Add the ability to choose the codecs used during Voice/Visio calls
- Add a better validation of Uri values
- Add ability to set custom XDMS documents
- Add a dialog box when a connection error occurs
- Add an anonymous crash report sending to ease feedback
- Add a DTMF sound feedback
- Fix a crash when running under Microsoft Remote Desktop
- Fix a crash when making a Voice call with IMS Communicator
- Fix the jitter buffer for a better sound quality
- Fix the session rejection with IM SIMPLE Session
- Fix the ugly noise when playing the ring tones
- Fix label alignment under Windows Vista
- Fix the tab-stop order of various screens
- ...

For more information about Mercuro IMS Client visit http://www.mercuro.net.

3GPP P-Headers

The Third Generation Partnership Project (3GPP) has defined some additional SIP P-headers ('P' stands for private or proprietary) to use in IMS (Release 5 requirements on SIP) context.

These headers are:

1. The P-Associated-URI header
2. The P-Called-Party-ID header
3. The P-Visited-Network-ID header
4. The P-Access-Network-Info header
5. The P-Charging-Function-Addresses header
6. The P-Charging-Vector header

In next posts I will explain how these headers are used in both UAC and UAS side.

For more information visit http://www.ietf.org/rfc/rfc3455.txt

Rich Communication Suite phase 1

RCS (Rich Communication Suite) is a join industry effort aiming to speed up the evolution of mobile phone communication towards rich communication. The RCS initiative includes network operators, network and device vendors (Orange, Telecom Italia, Telefonica, TeliaSonera, Ericsson, Nokia Siemens Networks, Nokia, SK Telecom, Sony Ericsson and Samsung).

The main purpose of RCS is to allow interoperability between network vendors and software editors.

RCS phase 1 defines 4 main features:

1. Enhanced Address Book (Service capabilities, presence contacts information, Video Call, …)
2. Content Sharing (Video Share, Image Share, …)
3. File Transfer (based on OMA Simple 1.0 specifications)
4. Converged Messaging (base on OMA Simple 1.0 specifications)

The RCS Initiative has defined a core feature set, developed reference implementations of the services and conducted interoperability testing in multi-vendor environment.

In next posts I will introduce all features mentioned above and explain how they are used in IMS Clients (Mercuro).

References:
http://en.wikipedia.org/wiki/Rich_Communication_Suite
http://www.nokiasiemensnetworks.com/global/Press/Press+releases/news-archive/Rich_Communication_Suite_Initiative.htm