Sorry, this isn't answering your question of "how secure ...", but this might side-step your problem.
Have you tried xauth_psk_server and putting "save_passwd on;" into your mode_cfg section of racoon.conf?
This let my old iPod (Version 4.2.1) cache an XAuth username & password. Here is my racoon.conf:
path pre_shared_key "/etc/racoon/psk.txt";
listen {
adminsock disabled;
}
remote anonymous {
exchange_mode aggressive;
my_identifier address;
proposal_check strict;
generate_policy on;
nat_traversal on;
dpd_delay 20;
ike_frag on;
proposal {
encryption_algorithm aes;
hash_algorithm sha1;
authentication_method xauth_psk_server;
# pre_shared_key
# rsasig (for plain RSA authentication)
# gssapi_krb
# hybrid_rsa_server hybrid_rsa_client
# xauth_rsa_server xauth_rsa_client
# xauth_psk_server xauth_psk_client
dh_group modp1024;
}
}
mode_cfg {
network4 10.99.99.2;
pool_size 253;
netmask4 255.255.255.0;
auth_source pam;
# dns4 10.99.99.1;
# wins4 10.0.12.1;
banner "/etc/racoon/motd";
pfs_group 2;
# Allow client to cache password:
save_passwd on;
split_dns "ad5ey.net";
split_network include 10.99.99.0/24;
}
sainfo anonymous {
pfs_group 2;
lifetime time 1 hour;
encryption_algorithm aes;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}
With my iPod (and my MacBook), I select "Cisco IPSec" for the VPN type, and then invent a group name and shared secret for your psk.txt.
# Example psk.txt
coolgroup bigsecret
Now the question is, How secure is xauth_psk with a shared group secret? (This might not be secure for a corporate environment, because other employees might recycle the group shared secret to spoof being the vpn server to other employees and then sniff usernames and passwords... (runonsentencefun) but it's fine enough for my iPod when I don't share my group with anyone.)
I haven't found official confirmation that Mac OS X doesn't support PEAP-EAP-MSCHAPv2, but I can't get it to work either (Windows SBS 2003 R2 and L2TP-over-ESP with a Mac OS X 10.8 client here). I'm not even seeing the login attempts in the IAS log file. (The Security Event Log is full of all kinds of stuff, so I haven't read through it very closely.) I did confirm to my satisfaction that at least ISAKMP and IPsec ESP were working by inspecting /var/log/racoon.log on the Mac, where I saw entries similar to the following (here 198.51.100.200 is the Mac and 192.0.2.100 is SBS):
DEBUG: agreed on pre-shared key auth.
INFO: NAT detected: ME PEER
INFO: ISAKMP-SA established 198.51.100.200[4500]-192.0.2.100[4500] spi:0123456789abcdef:0123456789abcdef
INFO: NAT detected -> UDP encapsulation (ENC_MODE 2->61444).
INFO: IPsec-SA established: ESP/Transport 192.0.2.100[4500]->198.51.100.200[4500] spi=01234567(0x012345)
INFO: IPsec-SA established: ESP/Transport 198.51.100.200[4500]->192.0.2.100[4500] spi=89abcdef(0x6789ab)
I also looked at /var/log/ppp.log, which has stuff like the following in it:
IPSec connection started
IPSec phase 1 client started
IPSec phase 1 server replied
IPSec phase 2 started
IPSec phase 2 established
IPSec connection established
L2TP sent SCCRQ
L2TP received SCCRP
L2TP sent SCCCN
L2TP sent ICRQ
L2TP received ICRP
L2TP sent ICCN
L2TP connection established.
This recaps the successful IPsec connection shown in racoon.log and adds a successful L2TP connection (which makes sense - L2TP is itself unauthenticated). Next, the Mac tries to build a PPP connection over L2TP, as expected, and this is where I start to see errors that I don't understand:
lcp_reqci: rcvd unknown option 13
lcp_reqci: rcvd unknown option 23
lcp_reqci: returning CONFREJ.
Followed by:
sent [LCP ConfRej id=0x0...
rcvd [LCP ConfAck id=0x1...
rcvd [LCP ConfReq id=0x1 <mru 1400> <auth eap>...
lcp_reqci: returning CONFNAK.
sent [LCP ConfNak id=0x1 <auth chap MS-v2>]
rcvd [LCP ConfReq id=0x2 <mru 1400> <auth eap>...
lcp_reqci: returning CONFNAK.
sent [LCP ConfNak id=0x2 <auth chap MS-v2>]
rcvd [LCP ConfReq id=0x3 <mru 1400> <auth eap>...
lcp_reqci: returning CONFNAK.
sent [LCP ConfNak id=0x3 <auth chap MS-v2>]
rcvd [LCP ConfReq id=0x4 <mru 1400> <auth eap>...
lcp_reqci: returning CONFNAK.
sent [LCP ConfNak id=0x4 <auth chap MS-v2>]
rcvd [LCP ConfReq id=0x5 <mru 1400> <auth eap>...
lcp_reqci: returning CONFNAK.
sent [LCP ConfNak id=0x5 <auth chap MS-v2>]
rcvd [LCP ConfReq id=0x6 <mru 1400> <auth eap>...
lcp_reqci: returning CONFREJ.
sent [LCP ConfRej id=0x6 <auth eap>]
rcvd [LCP TermReq id=0x7...
sent [LCP TermAck id=0x7]
Fatal signal 6
Note the 'auth eap' and 'auth chap MS-v2' in the above.
I'm going to try backing out some of the changes I made to the remote access policy:
- re-enable all encryption types (no/basic/strong/strongest, was strongest only)
- remove all EAP types and enable only MSCHAPv2 (was Protected EAP [PEAP]/EAP-MSCHAPv2)
Given that the entire exchange is protected by IPsec, I wonder about my actual risk. If someone's compromised a client such that they have access to the PSK or certificate used with IPsec, I'm not sure if having only PEAP to authenticate the PPP connection will matter (at least, for my threat model).
UPDATE: I re-enabled MSCHAPv2 in both the RRAS server properties and in the IAS policy that controls VPN access, and I enabled all encryption types. After making these changes the Mac was able to connect to the L2TP-over-IPsec VPN again, using MSCHAPv2 to authenticate over PPP. I toggled PEAP on and off in the IAS policy just to confirm that PEAP would not work, and in fact, with PEAP enabled (but MSCHAPv2 disabled), I now receive an authentication failure message, and Mac OS X logs the following:
MS-CHAP authentication failed: E=649 No dialin permission
sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"]
I suppose the more ambiguous behavior before was due to the fact that I disabled MSCHAPv2 in RRAS itself as well as in the IAS policy, whereas my current test configuration has MSCHAPv2 enabled in RRAS but disabled in the IAS policy.
Best Answer
RADIUS Accounting in the eap-radius plugin does not require XAuth authentication. It actually works with any kind of authentication, via RADIUS or not, as long as the client requests a virtual IP address (for IKEv2 even this requirement can be disabled). With some IKEv1 clients there are some issues in case of reauthentication, though (see issue #937 and related).
EAP-TLS makes it possible to delegate the certificate authentication for IKEv2 clients to the AAA server, but this is unrelated to RADIUS Accounting.