OpenIPSec: Introduction (Part 1)

This is the first part of a series of articles in which I will explain how I will develop an open source IPSec Framework (Ndis Driver, Crypto API and Command Line Tools) for Windows OS.
This Framework will be available under GPLv3 license and all the source code will be available for download.

This first part is an introduction to IPSec and a kick overview of OpenIPSec project.

1. IPSec

IPSec stands for Internet Protocol Security and has been specified by the Internet Engineering Task Force (IETF).
IPSec operates at at the Network Layer (OSI Layer 3). This imply that it can protect all upper protocols such as UDP, TCP or ICMP.
IPSec is a successor of the ISO standard Network Layer Security Protocol (NLSP). NLSP was based on the SP3 protocol that was published by the NIST but designed by the Secure Data Network System project of the National Security Administration (NSA). Because it operates at OSI layer 3 it must be integrated at the Kernel/OS Layer. On Windows OS all Network APIs (e.g. Windows Sockets 2 or Layered Service Provider) operate at the upper layers (user/application Layer).
An example of security protocols working at user/application layer are Secure Sockets Layer (SSL), Transport Layer Security (TLS) or Secure Shell (SSH).

1.1 Protocols

IPSec have three main protocols: AH, ESP and IKE. AH and ESP are commonly called Security Protocols.

=>AH: Stands for Authentication Header and has been defined in RFC4302. It is used to provide connectionless integrity and data origin authentication for IP datagrams and to provide protection against replays.


=>ESP: Stands for Encapsulating Security Payload and has been defined in RFC4303. It is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and (limited) traffic flow confidentiality. It may be applied alone or in combination with AH.

=>IKEv1/IKEv2: Stands for Internet Key Exchange and have been defined in RFC4109 and RFC4306 respectively. Both are used for mutual authentication between two parties and establishes an IKE security association (SA) that includes shared secret information that can be used to efficiently establish SAs for Encapsulating Security Payload (ESP) and/or Authentication Header (AH) and a set of cryptographic algorithms to be used by the SAs to protect the traffic that they carry.

1.2 Security Association (SA)

IPSec Security Association (SA) is a virtual unidirectional association between two or more peers/entities (IP:port) . This mean that you should create two SAs for bidirectional communications. Each SA has its own ID called SAID stored in the Security Association Database (SAD) as per RFC4301. The SA defines:

• A unique security parameter index (SPI)
• Shared security Keys
• Lifetime
• Encryption algorithm to use : DES, 3DES or AES (all supported by OpenSec)
• Authentication algorithm to use: HMAC-MD5-96, AES-XCBC-MAC-96 or HMAC-SHA-1-96 (all supported by OpenSec)
• Which Protocol to use: ESP or AH

1.3 Key Management

Key Management mechanism is used to exchange mandatory security keys to setup SAs. Can be manual or automated using IKE.
For Example, 3GPP IMS use SIP to exchange security information and manually setup SAs (e.g. using ipsec command line tools).

1.4 Mode of operation (transport and tunnel)

Both ESP and AH may be applied individually or in combination with each other to provide IPv4 and IPv6 security services. Both supports two modes of use: transport mode and tunnel mode. In transport mode, AH and ESP provide protection primarily for next layer protocols; in tunnel mode, AH and ESP are applied to tunneled IP packets.

==>Transport: only the payload (without IP header) of the IP packet is encrypted (ESP) and/or authenticated (ESP or AH) before (re)transmission. This is the default mode in 3GPP IMS context (Both UE and P-CSCF).

=>Tunnel: both the IP header and the payload are encrypted (ESP) and/or authenticated (ESP or AH) before (re)transmission. It is used to create Virtual Private Networks (VPN).

2. OpenIPSec Framework

OpenIPSec is an open source IPSec Framework for Windows XP/Vista/Blackcomb/CE. The Framework will include an API for software development, command line tools, open source code (GPLv3) and documentation.
Development is done from scratch and all dependent projects are my own projects (To ease bug fix; release a soft 100% free and open source). This project depends on OpenSec and libonid. The first, contains IPSec algorithms implementation and the second allows monitoring Network cards. These two projects are under development (OpenSec: 90% done - libonid: 40% done) and the source code is freely available for download. To ease adoption, command line tools (setkey, spdadd, add ...) will have same name and options than those provided on Linux.

2.1 Standards

* RFC1825 - Security Architecture for the Internet Protocol (Obsoleted by: 2401)
* RFC2401 - Security Architecture for the Internet Protocol (Obsoletes: 1825 and Obsoleted by: 4301 and Updated by: 3168)
* RFC2402 - IP Authentication Header (Obsoleted by: 4302, 4305 and Obsoletes: 1826)
* RFC2410 - The NULL Encryption Algorithm and Its Use With IPsec
* RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV
* RFC2406 - IP Encapsulating Security Payload (ESP) (Obsoleted by: 4303, 4305 and Obsoletes: 1827)
* RFC2407 - The Internet IP Security Domain of Interpretation for ISAKMP (Obsoleted by: 4306)
* RFC2408 - Internet Security Association and Key Management Protocol (ISAKMP) (Obsoleted by: 4306)
* RFC2409 - The Internet Key Exchange (IKE) (Obsoleted by: 4306 and Updated by: 4109)
* RFC2481 - A Proposal to add Explicit Congestion Notification (ECN) to IP (Obsoleted by: 3168)
* RFC3168 - The Addition of Explicit Congestion Notification (ECN) to IP (Updates: 2474, 2401, 793 and Obsoletes: 2481)
* RFC3602 - The AES-CBC Cipher Algorithm and Its Use with IPsec
* RFC4109 - Algorithms for Internet Key Exchange version 1 (IKEv1) (Updates: 2409)
* RFC4301 - Security Architecture for the Internet Protocol
* RFC4302 - IP Authentication Header
* RFC4303 - IP Encapsulating Security Payload (ESP) (Obsoletes: 2406)
* RFC4305 - Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) (Obsoleted by: 4835 and Obsoletes: 2404, 2406 )
* RFC4306 - Internet Key Exchange (IKEv2) Protocol
* RFC4307 - Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
* RFC4835 - Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) (Obsoletes: 4305)

/!\ OpenSec is now available for download at http://code.google.com/p/opensec/

References:
http://en.wikipedia.org/wiki/IPsec

OpenSec Beta 0.3

First beta version of OpenSec is now available for download.
To download source code:
- go to http://code.google.com/p/opensec/ or
- use command line "svn checkout http://opensec.googlecode.com/svn/trunk/ opensec-read-only"

OpenSec is an Open-Source Security API. This project is part of OpenIPSec project.
This API contains all mandatory or recommanded security algorithms needed to implement an IPSec Framework.

Already supported algorithms: MD5, SHA-1, HMAC-MD5-96, HMAC-SHA-1-96, DES-ECB, DES-CBC, 3DES-ECB, 3DES-CBC, AES[128,192,256]-ECB, AES[128,192,256]-CBC and AES[128]-XCBC-MAC-96.

The source code includes a test application to see how these algorithms can be used.

Standards

* RFC1321 - The MD5 Message-Digest Algorithm
* RFC1829 - The ESP DES-CBC Transform
* RFC1853 - IP in IP Tunneling
* RFC2104 - HMAC: Keyed-Hashing for Message Authentication
* RFC2402 - IP Authentication Header
* RFC2403 - The Use of HMAC-MD5-96 within ESP and AH
* RFC2404 - The Use of HMAC-SHA-1-96 within ESP and AH (Obsoleted by RFC4305)
* RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV
* RFC2406 - IP Encapsulating Security Payload (ESP) (Obsoleted by RFC4305)
* RFC2451 - The ESP CBC-Mode Cipher Algorithms
* RFC3174 - US Secure Hash Algorithm 1 (SHA1)
* RFC3566 - The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec
* RFC3602 - The AES-CBC Cipher Algorithm and Its Use with IPsec
* RFC4305 - Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)

* FIPS 197 - AES (Advanced Encryption Standard)
* FIPS-46-1/3 - DES and Triple DES (Data Encryption Standard)
* FIPS 81 - DES MODES OF OPERATION

* RFC2144 - The CAST-128 Encryption Algorithm

* RFC2202 - Test Cases for HMAC-MD5 and HMAC-SHA-1

Google Android NDK

Weeks ago, Google announced the first public release of Android NDK.

I was so excited because the IMS Client I'm developing is written in pure C/C++ (Only Java was supported).
Before Android NDK, I have looked at Google's Android SDK and I found that they are using non-standard JVM. This mean that applications developed using J2ME can't run on Android devices. Thanks to Dalvik virtual machine.
It was clear that I won't rewrite xxx thousand lines of code for Android mobile devices which represent less than 1 percent of all mobile devices.
It's amazing to think that Android OS will gain momentum without compliant embedded JVM. First deception.

Because performance is critical for us and we don't have time and money to rewrite an application which will only run on Android devices, we decided to wait for the Android NDK.

The first release of Android NDK only comes with these native libraries:
# libc (C library)
# libm (math library)
# libz (Zlib compression)
# liblog (Android logging)

This mean that you don't have:
# STL support (string, list, map, queue, ....)
# C++ exceptions handling
# Threading support
# Cryptography support
# Secure sockets/transport (SSL, TLS, S/MIME, ...)
# Classes to access the system resources (webcam, soundcard, drivers, ...)
# .... to be continued

Of course, you must use JNI if you want to have access to the native libraries. I let you imagine about performance ...
Second deception.

Mercuro with MMS

Support for MMS (Multimedia Messaging Service) messaging has been added in the last release of Mercuro IMS Client.
MMS messages are sent over the network using MSRP/SMIL to one or multiple contacts (using conference factory).

libSigComp Beta 0.2

First beta version of libSigComp is now available for download.
To download source code:
- go to http://code.google.com/p/libsigcomp or
- use command line "svn checkout http://libsigcomp.googlecode.com/svn/trunk/ libsigcomp-read-only"

Released under LGPLv3

libSigComp: THE Open-Source SigComp framework

I’m writing today to announce the launch of libSigComp, an Open-Source SigComp Framework. This project is intended to develop a complete and compliant SigComp Framework to speed-up SigComp integration in Open-Source IMS projects.

As many operators have begun to commercially deploy IMS, the relevance of using SigComp to lower bandwidth usage will come quickly. In my own opinion I think that most operators (especially those using RCS) will question how to reduce SIP signaling (registration, billing, presence, messaging …) bandwidth usage (who will pay bits?).

These questions will especially concern using SIP (or all other text-based protocols) in wireless handsets as part of 2.5G and 3G cellular networks.

SigComp stands for Signaling Compression and has been defined in RFC 3320 by Internet Engineering Task Force (IETF) ROHC working group.

Many application protocols used for multimedia communications are text-based and engineered for bandwidth rich links. As a result the messages have not been optimized in terms of size. For example, typical IMS/SIP messages range from a few hundred bytes up to two thousand bytes or more. For this reason, SigComp is a mandatory part of 3GPP IMS.

SigComp could also be useful for RCS (Rich Communication Suite) networks because of the size of the SIP packets (more than three thousand bytes for presence publication). Using SigComp in IMS/RCS context will reduce the round-trip over slow radio links.

The goal of this project is to provide a SigComp framework which:

- Could be used as an external API or Framework

- Highly portable (Coded in C/C++ without any external dependencies)

- Easily configurable (memory usage, priorities in static dictionaries, stateful/stateless modes, dynamic/static/shared compression types …)

- Easy to integrate with any existing SIP/IMS stack, Proxy-CSCF, PoC client …

- Allow to easily plug your own compressor (DEFLATE –RFC 1951- will be the default)

- Robust

- Efficiently run on mobile handsets (small footprint)

- Use small memory (UDVM decompression)

- Run fast without high CPU usage

COMPLIANCE:

RFC 3320: Signaling Compression (SigComp)

RFC 3321: Signaling Compression (SigComp) - Extended Operations

RFC 4464: Signaling Compression (SigComp) Users' Guide

RFC 4465: Signaling Compression (SigComp) Torture Tests

RFC 4077: A Negative Acknowledgement Mechanism for Signaling Compression

RFC 3485: The Session Initiation Protocol (SIP) and Session Description Protocol

(SDP) Static Dictionary for Signaling Compression (SigComp)

RFC 5112: The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp)

RFC 1951: DEFLATE Compressed Data Format Specification version

3GPP TR23.979 Annex C: Required SigComp performance

Released under LGPLv3

MORE INFORMATION:

• To have feedbacks or if you are interested for IOTs don’t hesitate to contact me at diopmamadou{at yahoo}dot fr.
• libSigComp homepage: http://code.google.com/p/libsigcomp/

GSMA Rich Communication Suite Experience

1. Presentation

RCS (Rich Communication Suite) was 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 RCS is now managed by the GSM Association (GSMA). For more information about GSMA RCS program look at this dedicated website (http://www.gsmworld.com/rcs/programme.shtml)
The main goal of GSMA RCS is to provide a set of fully interoperable rich services to be used both in mobile and fixed network (Network/Access Convergence). These services will enrich call experience.
To be compliant with the GSMA RCS an IMS client MUST at least support these services:

- Enhanced Address Book (defined by the OMA –Open Mobile Alliance-)
- Enhanced Messaging (OMA)
- Content Sharing (GSMA)
- File Transfer (OMA)

An easy way to show how RCS work is to share with you RCS Experience using Mercuro IMS Client. Mercuro is one of the most complete and compliant IMS/RCS client used today.

Mercuro is developed by Inexbee.

2. Enhanced Address Book

This service (also called Enhanced Phonebook or EAB) is the main RCS Service and could be seen as an enriched buddy list with rich presence information. It should be possible to launch all other services (Image/Video Sharing, File transfer, SMS, MMS …) by selecting a contact from the phonebook.
The buddy list is expressed as XML documents and stored in various document repositories in the network where such documents can be located, accessed and manipulated (created, changed, deleted) by authorized principals.
Such documents are accessed and manipulated using IETF XML Configuration Access Protocol (XCAP).
Mercuro could be seen as a XDM Client (XDMC) and the server (XDMS) as a HTTP origin server.
Mercuro can automatically synchronize your EAB with your Terminal Address Book (TAB) to backup or restore your local buddies.
Synchronization between your TAB and the Network Address Book (NAB) must be done using a SyncML agent which will do translation from SyncML (OMA DS Synchronization) to OMA XDM.
Mercuro will support NAB synchronization in release 5.0.

Figure 1: Mercuro IMS Client EAB

2.1 XDM Storage

All contacts are remotely stored in the XDM server. Remote storage allows the user to get his buddy list everywhere and makes Convergence easier (Same contacts on your PC, PDA or mobile phone even if roaming). A contact is stored with some mandatory information (id and display-name) and extended with social information (e.g. nickname, e-mail, free text, dynamic avatar, birthday, labels, favorite link …). To keep XML documents compliant and interoperable, all Mercuro specific information are stored in separate documents.

Mercuro buddies are displayed with minimal information (nickname, msisdn …) and full profile is shown only when requested by the user. It is possible for the user to sort stored his contacts by nickname, e-mail, birthday …

2.2 History

All communications history is saved (for each contact) on behalf of the user. Retrieving a particular saved entry from the UI can be performed using dynamic filters.

Mercuro IMS Client allows the user to start new session (Voice/Video call, Image Sharing, Messaging …) from the history by selecting an entry. You can sort history by date, communication type...

2.3 Groups

Each contact could be part of one or many Groups (e.g. friends, family, biz …).

Mercuro buddies are displayed by Group. You can sort your buddies by group, name, sphere ….

2.4 Enhanced Address Book Presence

This feature is mainly based on OMA SIMPLE Presence 1.1 which partially uses IETF presence data model (RFC 4479).
Mercuro offers the possibility to publish your status (online, offline, out to lunch, on the phone …), dynamic avatar, favorite link, notes, availability, willingness, mood or per service/device capabilities at any time. Dynamic avatar publication (Based on OMA Presence Content) is an important element of EABP and gives Mercuro the look and feel of some well-known VoIP software (Skype or Windows Live Messenger).
It is possible to retrieve presence information for each contact in the phonebook using subscription mechanism (asynchronous). Presence could be retrieved one by one or per list.

All contacts are displayed with their presence information (all mentioned above). You have the possibility to sort your buddies by presence information (availability or willingness).
See below for capabilities indication.

2.5 Capabilities Enhanced Address Book

Mercuro can publish/store (persistent) end-user’s current communication capabilities and retrieve them later (new session). In the other side, capabilities information is retrieved for each contact using presence subscription. All contacts are displayed with their capabilities information. The list of capabilities to be shown to the user by Mercuro 4.x includes:

Video Call (3G CS video call)
Image Sharing (PRD IR.79 Image Share Interoperability Specification 1.0)
Video Sharing (PRD IR.74 Video Share Interoperability Specification, 1.0)
File Transfer (OMA SIMPLE IM 1.0)
Session Mode Messaging (OMA Instant Messaging using SIMPLE, 1.0)

Capabilities indication can be seen as “what type of communication I’m willing to accept”.

2.6 Presence authorization

Once your presence information is published you can choose with who you want to share it. At any time you can choose to accept, block, ignore or revoke an existing (or incoming request) authorization. Rules could be managed per lists (black-hat, white-hat …) or per buddy.

You can easily (UI) retrieve associated pres-rules (blocked, allowed …) for each contact.

2.7 Multimedia Element Integration

It is possible to integrate multimedia elements such as photos, portrait icon, free text …

3. Enhanced Messaging

Mercuro supports 1-to-1 and Ad-hoc mode messaging (Instant Messaging using SIMPLE v1.0 chapter 4.3.1). Peer-to-peer IM Session is also supported (chap. 4.3.2).
These services are supported as part of GSMA RCS Phase 1.

Mercuro also supports Pager mode (chap. 4.2.1) and Large Message Mode messaging (chap. 4.2.1).

Group Messages (chap. 4.2.2), Deferred Messages (chap. 4.2.3) and Predefined session mode messaging (chap. 4.3.1) will be supported in release 5.0.

Mercuro (PC version) uses Pager Mode and Large Message Mode messaging to simulate SMS/MMS services.
Mercuro uses OMA Final Delivery Reports (chap. 5.7) to simulate Negative/Positive Acknowledgement Mechanism for MMS messages.

For 1-to-1 mode the caller or callee can add new participants at any time. The exchanged message can contain both text and/or multimedia content (SMIL, images, videos ...).

End party activity (typing/composing) is indicated to all participants.

4. Content Sharing

4.1 Image Sharing

In 3GPP specifications Image sharing is defined as a service for sharing images between users during a mobile phone call (CS Call). These specifications were defined by the GSM Association for cellular network. For packet-only devices (e.g. Mercuro PC version) all these specifications do not apply. This mean that no CS voice call set up is required prior to sharing the images.
The Message Session Relay Protocol (MSRP), IETF RFC 4975, is mandatory for the Image Share Service. Image data information settings in SIP/SDP follow IETF File transfer RFC 5547 (previously [draft-ietf-mmusic-file-transfer-mech]).

To see how this feature is used in Mercuro IMS Client --> [http://imsclient.blogspot.com/2008/09/rcs-rich-communication-suite-image.html].

4.2 Video Sharing

This feature will be supported in release 5.0.

GSMA Video Sharing is vendor independent and a Peer-To-Peer service and doesn’t require special/dedicated server.
A compliant RCS Client shall be able to share live Video (by sharing the camera capture) and sharing pre-recorded Video is a handset implementation option.
Video codec H.263-2000 profile 0 level 45 is mandatory (QCIF). To have better Video quality MPEG4 Visual Simple Profile 0b and H.264/AVC Baseline Profile Level 1b could be optionally used.

5. File Transfer

Many technical references are common to GSMA Image Sharing but this service allows exchanging different types of content (text, documents, SMIL, videos …).
Both end clients (caller/callee) can start file transfer session during an ongoing session (CS/PS call) or without having an ongoing session.
Only 1-to-1 file transfer feature is supported in GSMA RCS phase 1 and only a single file can be transferred per session. Only sending/receiving files are supported and requesting files is not part of the GSMA RCS phase 1 use cases.

6. Main IETF/OMA specifications (3GPP omitted)

6.1 Enhanced address Book

[OMA-TS-XDM_Core-V1_1-20080627-A]
[OMA-WP-XDM_1_1_Implementation_Guidelines-20080627-C]
[OMA-TS-Presence-SIMPLE_Content_XDM-V1_0-20081223-C]
[OMA-TS-Presence_SIMPLE-V1_1-20080627-A]
[RFC 2387] + [RFC 3265] + [RFC 3857] + [RFC 3858] + [RFC 3863] + [RFC 3903] + [RFC 4662] + [RFC 4479] + [RFC 4480] + [RFC 4482] + [RFC 4483] + [RFC 4825] + [RFC 5025] + [RFC 5262] + [RFC 5264]

6.2 Enhanced Messaging (-minus those listed above)

[OMA-TS-SIMPLE_IM-V1_0-20080903-C]
[RFC 3862] + [RFC 3891] + [RFC 3994] + [RFC 4028] + [RFC 4145] + [RFC 4353] + [RFC 4488] + [RFC 4575] + [RFC 4579] + [RFC 4975] + [RFC 5366]

6.3 Image Sharing

[GSMA PRD IR.79 Image Share Interoperability Specification 1.0]
[RFC 4145] + [RFC 4575] + [RFC 4975] + [RFC 5547]

6.4 File Transfer

[OMA-TS-SIMPLE_IM-V1_0-20080903-C]
[RFC 4145] + [RFC 4575] + [RFC 4975] + [RFC 5547]