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
————————
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
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 = 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..
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
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[...]…