Affichage des articles dont le libellé est ipsec. Afficher tous les articles
Affichage des articles dont le libellé est ipsec. Afficher tous les articles

dimanche 9 août 2009

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

samedi 8 août 2009

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

mercredi 31 décembre 2008

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