Dear Ms. <ME is Here>,

On behalf of the Editorial Board it is my pleasure to inform you that your chapter has been provisionally accepted for publication in the book under the working title  ”Cryptography / Book 1″, ISBN 979-953-307-478-7.

Your next step is to write the full chapter. After the full chapter review, you will receive notification regarding the definitive acceptance of your work in the book.

In the attachment you can find the complete review outcome. From now on, you will be able to see the tentative list of contributing authors and read the accepted chapter proposals.

http://www.wseas.us/e-library/transactions/communications/2010/89-825.pdf

A Solution for Secure SIP Conferencing over IMS and SAE

CRISTINA Bucharest, ROMANIA <email>

Abstract: Over the latest few years, most of the major telephony and services providers have got their attention on the LTE/SAE solution, in the attempt of getting the most bandwidth and features at the least implementation and operating price. One of the major challenges that 3GPP, the creator of LTE/SAE architecture, has faced is the IMS integration with SAE. The latest standard version available at this moment on IMS integration and its security challenges is TS 33.203, which is focused on 3G security aspects. When talking about IMS- SIP security, there are several studies that propose end-to-end security for a SIP conversation over EPS infrastructure.

This paper reviews the security issues that resides in the SAE-IMS interaction and, looking at the specificities of the SIP conferencing, proposes a security model that uses GDOI management to secure the SIP conference data over IMS and SAE. One important aspect of conferencing in the mobile world is to realize the user is never stationary. One chapter of this paper describes the most complicated type of mobility scenario and also introduces the role of the Diameter server into this architecture.

Keywords: SAE, LTE, EPS, EPC, IMS, security, SIP, conference, GDOI, GCKS, IPsec, key management

Although it has its minuses, like any device on earth, the pretty SSX-3000 solution I’ve got my hands on knew most of the Remote-Access scenarios I could think of and EAP authentication on top. Besides that, I could do my work undisturbed, while my colleagues were experimenting on their own. Why? Because of the contexts: each one of these “virtual” routers minds its own business, permitting me to play around with my stuff, while the others could work very well, without having to worry about Cristina’s ideas. Now, 240k IPsec tunnels in remote-access with EAP authentication versus Radius and support for digital certificates sounds pretty good if you were to ask me. Mwell…not good enough for the Stoke guys…it seems. So they came up with an even more interesting idea: LAN-to-LAN. Now..hmm..this powerful machine, able of doing so much on RA…could it also be doing site-to-site? So, I’ve contacted my favorite Japanese techie and asked for instructions.

This is the way it works:

Let’s assume there are 2 security gateways, Tokyo (10.1.1.2) and Bucharest (10.1.1.1). Tokyo gateway protects a network (5.1.1.0/24), while in Bucharest we have another network (6.1.1.0/24). Stoke has the concept of “tunnel-enabled interface”, which is a only /32 IP address of an interface type “tunnel”. The following services are not allowed on a tunnel-enabled interface: static IP hosts, ARP, and routing protocols.

So, in our case, let’s assume the tunnel interface for Tokyo is 9.9.9.1/32 and for Bucharest it is 9.9.9.2/32.

As everything on an SSX is done via a context, let’s assume that Tokyo has a context called TB1 and Bucharest has a context called BT1, on which they have this LAN-to-LAN configuration. The configuration on Tokyo would look something like this:

context TB1

interface Tokyo-LAN

arp arpa

ip address 5.1.1.0/24

exit

interface Tokyo-Bucharest

arp arpa

ip address 10.1.1.2/24

exit

interface Tokyo-Tunnel tunnel

ip address 9.9.9.1/32

exit

ipsec policy ikev2 phase1 name si_p1

suite3

gw-authentication psk open_sesame

peer-authentication psk

exit

exit

ipsec policy ikev2 phase2 name si_p2

suite4

exit

exit

exit

tunnel Tokyo-Bucharest-TUN type ipsec protcol ip44 context TB1

enable

ip local 10.1.1.2 remote 10.1.1.1

bind interface Tokyo-Tunnel TB1

ip route 6.1.1.0/24

ip route 9.9.9.2/32

exit

ipsec policy ikev2 phase1 name si_p1

exit

ipsec policy ikev2 phase2 name si_p2

exit

port ethernet 1/1

bind interface Tokyo-LAN TB1

exit

enable

exit

port ethernet 1/0

bind interface Tokyo-Bucharest TB1

exit

service ipsec

enable

exit

While the Bucharest config should be like this:

context BT1

interface Bucharest-LAN

arp arpa

ip address 6.1.1.0/24

exit

interface Bucharest-Tokyo

arp arpa

ip address 10.1.1.1/24

exit

interface Bucharest-Tunnel tunnel

ip address 9.9.9.2/32

exit

ipsec policy ikev2 phase1 name si_p1

suite3

gw-authentication psk open_sesame

peer-authentication psk

exit

exit

ipsec policy ikev2 phase2 name si_p2

suite4

exit

exit

exit

tunnel Bucharest-Tokyo-TUN type ipsec protcol ip44 context BT1

enable

ip local 10.1.1.1 remote 10.1.1.2

bind interface Tokyo-Tunnel TB1

ip route 5.1.1.0/24

ip route 9.9.9.1/32

exit

ipsec policy ikev2 phase1 name si_p1

exit

ipsec policy ikev2 phase2 name si_p2

exit

port ethernet 2/1

bind interface Bucharest-LAN BT1

exit

enable

exit

port ethernet 2/0

bind interface Bucharest-Tokyo BT1

exit

service ipsec

enable

exit

To verify the config, run:

Stoke [TB1]# sh ike-session list

—————————————————————————-

SLOT : 1

Session Handle : f4100214

IKE Version : 2 <LAN<->LAN>

Remote IP : 10.1.1.1

IKE-SA ID : 10.1.1.1

Session State : IPSEC-ESTABLISHED, IKE-SA DONE, CHILD-SA MATURE

——————————————————————————-

While

Stoke[TB1]#sh ike-session detail handle f4100214

displays a lot of details about this session, like ports, type of authentication, lifetime values and algorithms.

Stoke[local]#sh tun

Name CctHdl Type Admin State

—————————— ——– ———- ——- ———–

Tokyo-Bucharest-TUN ce000013 ipsec:ip44 enable up

Bucharest-Tokyo-TUN ce000014 ipsec:ip44 enable up

2 objects displayed.

Stoke[local]#sh tun name Tokyo-Bucharest-TUN

will display the details of this particular tunnel.

For the moment, afaik, this is only IPv4-over-IPv4, but I can’t hardly wait to have another e-mail from these guys saying that I can also play with mixed transport on one of their new StokeOSes.

]]>

http://tech-invite.com/

The reason this is one of my favorite sites is that it is, firstly, VERY TECHNICAL of course. There are several sections where the articles are placed: Organizations, Standardization work, IETF topics, 3GPP topics, ETSI topics and…Other topics. I have to thank my VoIP guru colleague Alin for telling me about this site.

To be honest, I’ve never used any other categories, other than 3GPP and IETF topics. But these ones I have used extensively. Ranging from packet by packet IPsec negotiation, to SIP headers description, example, and a lot of scenarios, database infrastructure to UMTS and SAE architecture and scenarios, with a very welcome RFC and TS classification, I believe this site is one of the best locations where one could go to clarify technical things, to view scenarios and to take a look at packets and headers along with their analysis.

The latest link I’ve used is a secure SIP basic call from roaming, using the IMS architecture over UMTS. There are diagrams with each step of the flow, the packet dump and explanations for each packet. Gold, I say

So take a look.

Basically, the “Compression” part of this IPsec traffic is negotiated just as  any other protocol: AH, ESP, EAP…via IKE, or manually configured on a device. Now…as I’ve got to devices….good question: _what_ device could I use if I want IPsec IPCompression?

Look at this: http://www.vpnc.org/vpnc-ipsec-features-chart.html. Scroll down to “Features (HTML table). The vendors that actually implement this, as per VPN Consortium (and for some of them I could tell you from direct experience), are CheckPoint, Cisco, McAfee, SafeNet, StoneSF and TeamF1. A bit disappointed that I didn’t have the opportunity of working on all of these devices, I am redirecting my attention to what I do have: a big, shiny and fluffy Debian, with Strongswan installed and xfrm module also on.

So, lets get down to business. I have taken the simplest scenario I could think of at the moment, a transport mode scenario, having as Initiator 192.168.0.10 and as Responder 192.168.0.1. These two hosts negotiate 3des-md5-dh2 algorithms, doing PSK authentication. No PFS, no other kinky stuff. Just basic IKEv2 negotiation. The Strongswan config is as simple as possible.

*Note 1 : on strongswan.org people say that IKEv2 does not support compression – I have run a test with IKEv2 and compression and it works very well But, in order to humor the strongswan guys, I have used IKEv1 in the following scenario

*Note 2 : in order to actually _see_ the encapsulated packets, I have used ESP-NULL Encryption for data encapsulation. Yes, I could have used a NetCocoon analyzer, but that – in the next episode

So: IKEv1, Transport mode, Main Mode, Null Encryption, ESP only, IP Comp:

# ipsec status

000 “network1″: 192.168.0.1[192.168.0.1]…192.168.0.10[192.168.0.10]; erouted; eroute owner: #3

000 “network1″:   newest ISAKMP SA: #2; newest IPsec SA: #3;

000

000 #3: “network1″ STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 2488s; newest IPSEC; eroute owner

000 #3: “network1″ esp.525b0b48@192.168.0.10 (0 bytes) esp.5511d8c2@192.168.0.1 (0 bytes) comp.1169@192.168.0.10 comp.527e@192.168.0.1; transport

000 #2: “network1″ STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 2488s; newest ISAKMP

000

Yes, it worked.

Now…I am not sure what exact compression algorithms this Strongswan daemon has, but I can tell you for sure it uses at least DEFLATE (  RFC 2394 ). Cisco on the other hand, uses only LZS (RFC 2395 ) – as far as I have seen – to be updated if anybody else tested it versus DEFLATE.

The process of actually obtaining this cute ESP packets is the following:

a. get the Data from the upper layers of the TCP stack – doh, we need data

b. compress the Data above using the chosen algorithm – you will notice the CPI – Compression Parameter Index – which has well know identifiers for the well known compression algorithms

c. set the Next Header value of the IPComp header to the layer 4 protocol (in this case, TCP)

d. encapsulate everything in ESP, put on the corresponding SPI, set the Next Header value of the ESP header to 108 (0x6c)

e. wrap it up in IP and… we are all set

— You can admire the ESP of IKEv1 in the screenshot attached

Now, what happens differently with IKEv2? I was telling you before the on Strongswan, IKEv2 and AH is a no-no for the moment, ESP with null encryption does a weird thinggie that vmp was so kind to point it out for me (while I was feeling actually quite happy about myself being able to do an IPComp test via IKEv1).

The thing is that, unlike the (correct) way of doing IPComp in IKEv1 (see the aboe a. to e. steps), IKEv2 implementation of Strongswan does a weird thing:

a. get the Data ..blah-blah

b. compress the Data with whatever compression algorithm and put on the IPComp header with CPI value and all

* c. put on another IP header (the internal one, in case of a tunnel mode scenario)

d. put on the ESP header

e. wrap everything up

— Unfortunately, you CANNOT admire the ESP of IKEV2 in a screenshot, because my current wireshark has no idea on how to do decompression of this type of packet. Once it does, I will update

These guys are not quite the interop gurus ever, but they strive to implement the crankiest drafts that ever appeared from IETF. Running this on my own, the interop even with this device worked well, but trying to make it work with StrongswanI’ve got into big trouble.

Why? Well, let’s take a look at the most common IPsec – IKEv1 implementations. They usually pick one/more of the following standards:

- RFC 2407

- RFC 2408

- RFC 2409

- RFC 3706 – should you like DPD – Dead Peer Detection

- RFC 3947 and RFC 3948 for NAT-T

- mode-cfg-02 draft – for the most common Mode-Configuration operations (perfectly inter-operable by Cisco, Juniper’s ScreenOS, Strongswan, Sonicwall, Stoke and Clavister) – as you may have guessed, NO, NOT with CheckPoint

- draft-beaulieu-ike-xauth-02 – for xAuth authentication of clients – inter-operable on Cisco, NetScreen, Stoke and Sonicwall (not sure about Clavister – haven’t tried it yet) – and, yes, not on CheckPoint

As a nice old guy would say: “Security through obscurity” , not quite my favorite idea of _security_. Still, a good to follow idea for CheckPoint. Why? Because, even though they implement the RFC 2407, 2408 and 2409, they have decided not to implement the most common xAuth draft (presented above), feeling that symmetrical authentication is just too lame, so they have implemented draft-zegman-ike-hybrid-auth-01, which defines how to do uni-directional independent authentication on the remote-access scenarios – procedure enforced by the CheckPoint VPN Client (only, if you ask me, though I haven’t tried too many others).

Once you bypass this authentication procedure, configuring the UTM to authenticate the clients using X.509 certificates, you end up in yet another dead-end: the so-called Office-Mode, which is the CheckPoint way of saying “Mode-Configuration”, with a significant difference: the actual packet exchange is not standard. We have tried, me and my programmer fellows (by the way: thanks for enduring this by my side), to “reverse-engineer” this mighty exchange, but even with the CheckPoint debug and hacking into our friend pluto, we didn’t manage to get it right.

I have talked to a tech-support guy from CKP, a very nice person, still incapable of saying anything about their solution without first asking for permission from his PM/Management/whatever. So, up until today, I haven’t been able to pull this through. This is why the things I’m going to describe below are only ALMOST CheckPoint IPsec…

So, once you have installed NGX R65 (of course, I only  had a trial version), define a main interface, generate a self-signed certificate for the UTM, and allow GUI clients to administer the device via SmartDashboard:

1. Open SmartDashboard > Network Objects > CheckPoint > double-click the name you gave to the current UTM (mine is CKP-R65) > General Properties > check the VPN box under “Check Point Products”

still on CKP-R65- > under Topology tab, Edit the networks there as to identify as “This network” the main IP address, the one you bound to the RSA, and put the secondary one (of course, you’ve defined a secondary one) as “External”

still on CKP-R65- > under VPN tab, Add “Remote Access” to the upper Area, stating that “This module participates in the following VPN Communities”

still on CKP-R65- > under Remote Access > under Office Mode I have checked the “Do not offer Office Mode” option

Hit OK, then go to Menu > Policy > Install Database… and install it on the UTM.

2. In the main Dashboard window > Network Objects > right-click on Networks > Create new network, give it a name and then configure it. This shall be the Remote-Access pool for Office Mode (which we won’t do, cuz we don’t get till there with pluto)

3. In the main Dashboard window > (fifth tab) Users > right-click Users Group, create a new group, then right-click on Users and create a new user, assigning it to the previously created Remote-Access group

4. Now would be a good moment to save everything on the UTM > Install Policies.

5 – version 1. What I’ve done next is to create a new (external) CA (which is a 2003 Server CA I had at hand), enroll the CheckPoint to this CA and try to create a user certificate for my CheckPoint user. I thought of exporting this user certificate on my Strongswan and authenticate it to the gateway. Unfortunately, I’ve seen no way of indicating to which CA the user certificate gets enrolled – the user certificate I have created from the user page always got enrolled to the CheckPoint’s self-signed CA – not exactly what I had in mind

5 – version 2. I have done some more reading on the Internet, and found a procedure of actually exporting the CheckPoint’s self-signed cert from the UTM, to a p12 file. God-like! I have exported the CKP-R65′s certificate, then put it under the …/ipsec.d/cacerts directory on debian. This way, it seems that strongswan passes the authentication stage – still not hybrid, but still authentication

[Show as slideshow]

My Strongswan machine has an IP address (20.0.0.2) and tries to do Remote-Access to the CheckPoint. The Strongswan config looks like this:

having ipsec.secrets:

: RSA /usr/local/etc/ipsec.d/private/user1_key.pem “password”

Now, the solution may seem simple, BUUUT:

a. CheckPoint does not want to use its DNS name as Identification Payload for IKEv1 for the Remote-Access scenarios

b. Also, the certificate cannot be generated for external networks, so there has to be 10.205.17.251.

c. ALSO, although not recommended for security purposes, even if I configure Strongswan to identify the DUT per its 10.205.17.251 IP address, still I get the INVALID_KEY_INFORMATION error.

*** Now, should any one of you nice readers have solved this scenario and actually get a CheckPoint device to work with another solution (not necessarily open-source), please have mercy on my poor soul and let me know

Some other vendors decide to overcome the entire negotiation fuss and use predefined keys for the IPsec traffic, bypassing all the IKE negotiation and using manual keying. Here we have Cisco, Juniper, Sonicwall or our lovely Linux solutions.

In order to manually configure IPsec, the admin alters the SAD (Security Association Database) and SPD(Security Policy Database) databases of the device/kernel. The SAD contains specific traffic transformations, like the encryption/authentication algorithms, while the SPD indicates the traffic selectors/proxy-ids for the traffic that is to be transformed by the stuff described in SAD and indexed by an SPI.

An SAD entry would include:

• Dest IP address
• Ipsec proto (SA or ESP)
• SPI (cookie)
• Sequnce counter
• Seq O/F flag
• anti-replay window info
• AH type and info
• ESP type and info
• Lifetime info
• tunnel/transport mode flags
• PATH MTU info

An SPD entry would contain:

• pointer to active SAs
• Selector fields

***Let’s take a simple site-to-site tunnel mode case, where the security gateways are 2001::1 (local gateway) and 2001::2 (remote gateway) and the subnet behind the local gateway is 2002::/112 and the one behind the remote gateway is 2003::/112. As you can imagine, I want to encrypt traffic between 2002::/112 and 2003::/112 with aes-cbc, let’s say and authenticate it with hmac-md5.

In order to configure manual keying on linux, we need to have:

- xfrm modules in ze kernel:

xfrm4_mode_transport     1792  0

- and a small script that instructs the kernel on how to populate those two databases:

ip xfrm state add src 2001:0::2 dst 2001:0::1 proto esp spi 0×1000 enc “cbc(aes)”  0x12345678abcdef12f4f71dbccd2c1b07bce4e63b4c315414  auth “hmac(md5)” 0x012345abd9abcdeff1e0d3c2b5a4909a

ip xfrm state add src 2001:0::1 dst 2001:0::2 proto esp spi 0×2000 enc “cbc(aes)” 0xf4f71123452c1b07bce4e63b4c31541d12345678abcdef12  auth “hmac(md5)” 0x912345abd9abcdeff1e0d3c2b5a49080

ip xfrm policy add dir in src 2003::/112 dst 2002::/112 tmpl src 2001:0::2 dst 2001:0::1 proto esp mode tunnel

ip xfrm policy add dir out src 2002::/112 dst 2003::/112 tmpl src 2001:0::1 dst 2001:0::2 proto esp mode tunnel

ip xfrm policy add dir fwd src 2003::/112 dst 2002::/112 tmpl src 2001:0::2 dst 2001:0::1 proto esp mode tunnel