RSA keypair, Radius and StokeOS for IKEv2-EAP Authentication

Posted: January 28, 2010 in technical
Tags: , , , , , , , , , , ,

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:

Stoke[local]#certificate device-certificate new ca-certfile cacert.pem format pemcertfile signed-ssx-ca.pem format pem name mypkcs12

— 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



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



session name ikev2

ip address pool

password encrypted 3A0C060A


radius strip-domain

radius session authentication profile

timeout 60

retry 3

max-outstanding 127

server port 1812 key ipsec


ip pool 1024

interface Mngmt management

arp arpa

ip source-address context-default

ip address


interface session1 session loopback

ip session-default

ip address


interface Untrust_1

arp arpa

ip address


interface Trust_1

arp arpa

ip address


ip route

ip route

ipsec policy ikev2 phase1 name RAv2


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



ipsec policy ikev2 phase2 name RAv2




port ethernet 0/0

bind interface Mngmt test




port ethernet 1/0

bind interface Untrust_1 test

ipsec policy ikev2 phase1 name RAv2

ipsec policy ikev2 phase2 name RAv2


service ipsec



port ethernet 1/2

bind interface Trust_1 test




Also, I had aย radius system (a freeradius 2.1.6) – with EAP enabled, MD5 default EAP-Type, and realm NULL enabled.
The main files of the configs are (default is not mentioned):
– the users file has:
DEFAULT Auth-Type := EAP, Cleartext-Password := “md5”
Service-Type = Framed-User,
Framed-IP-Address =,

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
file replacing:
vp = pairfind(request->packet->vps, PW_USER_NAME);
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 ๐Ÿ™‚
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.ย – 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 ๐Ÿ™‚
  1. vmp says:

    Close enough ๐Ÿ˜›

    We call mode-config “mode-config” because the name stuck from IKEv1 — the IKEv2 literature AFAIK calls it “configuration [payload]”; no mode.

    The freeradius patch is to work around Stoke’s inconsistent identities (which trip up a paranoia check). And it’s the wrong way of doing it — we should add a config option ๐Ÿ™‚

    draft-eronen-ipsec-ikev2-eap-auth-07 is about allowing EAP in IKEv2 as the sole authentication method (as opposed to requiring the Responder to authenticate with certificates, which is what RFC4306 says). You were probably thinking of RFC5106.

    RFC4739 is not strictly about EAP; you could e.g. have two rounds of authentication with (different) certificates. RTFRFC, it has examples ๐Ÿ˜€

  2. @vmp: I will ๐Ÿ˜€

  3. Andreas Steffen says:

    strongSwan both supports draft-eronen-ipsec-ikev2-eap-auth:

    and RFC3739 Multiple Authentication:

    Since the EAP_ONLY notification hasn’t been assigned yet by IANA, strongSwan uses a private value and sends a strongSwan Vendor ID. This will change as soon as draft-eronen-ipsec-ikev2-eap-auth has become an RFC.


  4. @Andreas: cool. Good to know I can always count on Strongswan to be up to date with everything ๐Ÿ™‚ Thank you.

  5. Andreas Steffen says:

    We are going to support IKEv2 EAP-TLS soon. Since EAP-TLS offers strong mutual authentication based on certificates there is not much sense in doing a certificate-based IKEv2 SGW authentication on top of that, so this will be a typical application for EAP_ONLY authentication.


  6. New StokeOS (4.6B1), new commands to bind the certs:
    certificate device-certificate new name SSX ca-certificate CA.cer format pem signed-certificate ssx-185.pem format pem private-key ssx-185.key

  7. Hi! I know this is kinda off topic but I’d figured I’d ask. Would you be interested in exchanging links or maybe guest authoring a blog post or vice-versa? My blog goes over a lot of the same subjects as yours and I believe we could greatly benefit from each other. If you happen to be interested feel free to shoot me an email. I look forward to hearing from you! Awesome blog by the way!

  8. Jimmy's Blog says:

    Linky, linky, blogs we likey…

    […]while the sites we link to below are completely unrelated to ours, we think they are worth a read, so have a look[…]…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s