Stoke is quite a cool company when it comes to VPN gateways, and I mention here the SSX-3000, the only device I had the pleasure of working with. I could see on their website that new investments are made in LTE technologies, which should make this company even more attractive for me.

Well, this post is going to be about a specific thinggie of the SSX-3000 and StokeOS, that funky colored box, namely how they work with digital certificates. The scenario I am using them on is a classic Remote-Access scenario, for IKEv2. The StokeOS gateway is getting authenticated by the roadwarrior via digital certificate, while the roadwarrior authenticates via EAP.

First of all, we need digital certificates for the StokeOS. Following the User Guide got me nowhere, so we had to be inventive

A. The official version

1. Create a CSR on the Stoke:

Stoke[local]#certificate request new name newcsr.pem days 100 keylength 1024

2. Copy – paste the content of the CSR (or copy the file onto an ftp/tftp server), then generate a certificate using a CA (I had a Windows 2003 Server) => results a signed certificate – I used to download them in base64 format

3. Copy – paste the CA’s certificate and the Stoke’s certificate we’ve just signed onto Stoke and run the command:

— This command should “link” the CA, the signed certificate and the Stoke’s private RSA key to a PKCS12 file that this device uses for authentication. This is how Stoke authenticates

*** PROBLEM: when generating the CSR, the private key doesn’t get saved anywhere. I have looked everywhere:  ” -r” : /hd/…, /cfint, /cfext… – so, the latest mightiest command is not working.

B.  The working version

1. Do not create the CSR on the DUT

2. Generate a “Server Certificate” from IE and download it to a tftp/ftp server – it will be in pfx format

3. Export the private key to a separate key file – I have used openssl

4. Upload the CA’s certificate, signed certificate and the private key file on SSX and run the command (assuming I have put these files on /hd/Certs directory):

Stoke[local]#certificate device-certificate new name SSX format pem ca-certfile /hd/Certs/cacert.pem format pem signed-certificate /hd/Certs/signed-ssx-ca.pem format pem private-key /hd/Certs/signed-ssx-ca-key.pem

and now it works

as you can see from

Stoke[local]#sh certificate device-certificate all

Certificate Name

————————

SSX

Further on, create a context – I have called it test and a name for the radius session – I have called it ikev2, instruct the Stoke to do session authentication on radius, create a management interface on the same subnet as the radius machine, configure a radius server (where the Stoke should connect for session authentication) and, of course, the IKEv2 policies that make it work and the Configuration Payload (as we like to call the famous “mode-configuration” in IKEv2). The config should look like this:

context test

aaa profile

user authentication local

session authentication radius

service authorization local

exit

session name ikev2

ip address pool

password encrypted 3A0C060A

exit

radius strip-domain

radius session authentication profile

timeout 60

retry 3

max-outstanding 127

server 10.205.17.172 port 1812 key ipsec

exit

ip pool 40.0.0.2 1024

interface Mngmt management

arp arpa

ip source-address context-default

ip address 10.205.17.238/24

exit

interface session1 session loopback

ip session-default

ip address 40.0.0.1/32

exit

interface Untrust_1

arp arpa

ip address 200.0.0.1/24

exit

interface Trust_1

arp arpa

ip address 201.0.0.1/24

exit

ip route 50.0.0.0/16 200.0.0.2

ip route 70.0.0.0/16 201.0.0.2

ipsec policy ikev2 phase1 name RAv2

custom

gw-authentication certificate name SSX password encrypted 3A0C060A

peer-authentication eap

hard-lifetime 3600 secs

encryption triple-des

hash md5

d-h group2

prf md5

exit

exit

ipsec policy ikev2 phase2 name RAv2

any

exit

exit

port ethernet 0/0

bind interface Mngmt test

exit

enable

exit

port ethernet 1/0

bind interface Untrust_1 test

ipsec policy ikev2 phase1 name RAv2

ipsec policy ikev2 phase2 name RAv2

exit

service ipsec

enable

exit

port ethernet 1/2

bind interface Trust_1 test

exit

enable

exit

DEFAULT Auth-Type := EAP, Cleartext-Password := “md5″

Service-Type = Framed-User,

Framed-IP-Address = 255.255.255.254,

As I am a nutcase sometimes, this time I wanted to run with full Stoke power, which is 240K IPsec sessions, this is why I didn’t want to be concerned with the Radius authentication, and this is why I have this DEFAULT entry in my users file

- in the proxy.conf file I have:

realm NULL {

authhost        = LOCAL

}

*** GIVEN SITUATION:  StokeOS uses the notion of contexts in order to identify virtual separate router configurations. Basically, this machine has 4 slots, each with 4 ports on. I can define simultaneously a large (I don’t know _how_ large) number of configurations that reside in parallel on the machine. In order to apply one of them (or more) on the actual physical ports, I assign a port to a specific context (as you can see above in the config). It’s like… I have my any number of router configurations running and I apply on the actual ports either one I want, or more routers, on more ports, keeping in mind the rule: one port can only belong to one router – fair enough, I’d say

*** PROBLEM: In the Remote-Access scenarios, more exactly, at the user authentication on the machine, StokeOS identifies the users by matching them against a given context, so that, even if a user defined on context X arrives on a port belonging to context Y, the authentication fails. The problem this thing imposes when doing EAP versus Radius is that the StokeOS strips the context name, so:

- I have a user called roadwarrior1 in context test. The string this client should send to Stoke is roadwarrior1@test, otherwise Stoke fails to authenticate it

- Once Stoke authenticates the user, it forwards the username (roadwarrior1), to the Radius server, so that in radius this user arrives with realm NULL

- The problem appears when doing the actual radius authentication, because radius gives an error:

Identity does not match User-Name, setting from EAP Identity

I have looked around the Internet, but found none actual solution to this.

So, I have called a friend again – a friend of mine, _and_ a friend of C and we hacked into

freeradius-server-2.1.6/src/modules/rlm_eap/eap.c

file replacing:

vp = pairfind(request->packet->vps, PW_USER_NAME);

with:

vp = NULL;

everywhere (2 places) and recompiled the EAP so (thanks, vmp )

Now everything is fine, I have 240K IPsec roadwarriors happily authenticated via EAP on Stoke’s SSX-3000.

Me Happy

***CLARIFICATIONS:

As far as I know (and with lots of help from vmp ), there are 3 documents that “deal” with IKEv2-EAP authentication thinggie:

a. RFC 4306 - 3.16. Extensible Authentication Protocol (EAP) Payload – which treats EAP as an IKEv2 extension that appears in the IKE_AUTH packets (the first IKE_AUTH packet, coming from the IKEv2 Initiator actually contains no Authentication Payload, then the IKE_AUTH reply from the IKEv2 Responder contains the Responder’s digital certificate and an EAP-Identity Request method) —or some varying interpretations..

b. http://tools.ietf.org/html/draft-eronen-ipsec-ikev2-eap-auth-07 - which identifies basically an EAP-IKEv2 method, meaning that IKEv2 is a method of EAP’s, and, as far as vmp could explain to me the EAP in this case deals with the Authentication and IKEv2 does the negotiation “inside” EAP

c. RFC 4739 - Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol – which should be some twisted multiple authentication, one EAP authentication after another – vmp stopped explaining at this point and I didn’t have enough time to dig through that

Tags: csr, digital certificates, eap, freeradius, md5, openssl, p7b, PFX, PKCS12, PKI, techie, X509