Re: [strongSwan] Support for AKA-Identity and AKA-Reauthentication in the EAP-AKA plugin
Martin, Thanks for your swift reply. I've gone away and read the RFC on EAP-AKA and had a think about what you said. The problem with not supporting AKA-Identity is that it stops everything else (in an EAP-AKA environment) from working. Get AKA-Identity implemented and you do not need to do anything else. Trying to decipher the RFC, it seems that people might implement "Fast Reauthentication" not because it lightens the load on the client (as you state, it probably wont), nor because it lightens the network traffic (it uses the same number of messages) but to lighten the load on the AAA infrastructure behind the Security Gateway. I'm thinking of many clients requiring EAP-AKA authentication and the load they will place on the AAA provider. Fast Reauthentication (I guess) will restrict the heavy load to just the Security Gateway. Anyway, that apart, whereas responding to an AKA-Identity request is mandatory (when the EAP server sends it), taking any notice of the "Next Reauth ID" offered as part of the following AKA-Challenge request is entirely optional. So, the path we have chosen to follow is to implement support for AKA-Identity now, but to always get it to return the full, local, identity (e.g. the peer identity in EAP-speak), which is always 0+i...@realm in this case. Then to ignore the offered Next-Reauth-ID in the following AKA-Challenge - the existing code already does this, thank goodness. This means that the NEXT time we try to bring up the tunnel, the identity sent in the AKA-Identity response is STILL the full, local, identity, which forces the EAP server to go for another full AKA-Challenge. Not what the EAP server intended, I'm sure, but it gets us a tunnel until we can find the time and inclination to implement Fast Reauthentication. I can let you have the AKA-Identity support as a patch if you want. However, it looks a lot (*cough*) like the code you have already implemented to support SIM-Identity in the EAP-SIM module :-) Regards, Graham. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Child SAs fail to re-activate in IKE1 mode
Hello, Does anyone recognise this as a known issue. If no solution, shall I enter this into the bugtracker? Re-activation of child SA connections fail after physical Disconnect in IKE1 mode. I have one IKE SA and seven child SAs routed towards one remote peer (in responder mode). The local node is set to "auto=start" and "keyingtries=%forever". 1) I physically disconnect the ethernet cable, and get an "asynchronous network error". All child SA connections go to the inactive (down) state. 2) Reconnect the cable and ONLY child SA 0 and 7 recover. SA 2 to 6 stay in inactive state 3) TRACE OCT# ipsec status 000 "conn1": 192.168.205.0/24===192.168.205.201:17/500...192.168.205.102:17/500===192 .168.205.0/24; erouted; eroute owner: #195 000 "conn1": newest ISAKMP SA: #1; newest IPsec SA: #195; 000 "conn2": 192.168.206.0/24===192.168.205.201:17/500...192.168.205.102:17/500===192 .168.206.0/24; prospective erouted; eroute owner: #0 000 "conn2": newest ISAKMP SA: #0; newest IPsec SA: #0; 000 "conn3": 192.168.207.0/24===192.168.205.201:17/500...192.168.205.102:17/500===192 .168.207.0/24; prospective erouted; eroute owner: #0 000 "conn3": newest ISAKMP SA: #0; newest IPsec SA: #0; 000 "conn4": 192.168.208.0/24===192.168.205.201:17/501...192.168.205.102:17/501===192 .168.208.0/24; prospective erouted; eroute owner: #0 000 "conn4": newest ISAKMP SA: #0; newest IPsec SA: #0; 000 "conn5": 192.168.209.0/24===192.168.205.201:17/502...192.168.205.102:17/502===192 .168.209.0/24; prospective erouted; eroute owner: #0 000 "conn5": newest ISAKMP SA: #0; newest IPsec SA: #0; 000 "conn6": 192.168.210.0/24===192.168.205.201:17/503...192.168.205.102:17/503===192 .168.210.0/24; prospective erouted; eroute owner: #0 000 "conn6": newest ISAKMP SA: #0; newest IPsec SA: #0; 000 "conn7": 192.168.211.0/24===192.168.205.201:17/504...192.168.205.102:17/504===192 .168.211.0/24; erouted; eroute owner: #196 000 "conn7": newest ISAKMP SA: #194; newest IPsec SA: #196; 000 000 #195: "conn1" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 701s; newest IPSEC; eroute owner 000 #195: "conn1" esp.d9116...@192.168.205.102 (0 bytes) esp.52d5c...@192.168.205.201 (0 bytes); tunnel 000 #1: "conn1" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 75486s; newest ISAKMP 000 #196: "conn7" STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 165s; newest IPSEC; eroute owner 000 #196: "conn7" esp.f7fb9...@192.168.205.102 (0 bytes) esp.d98c5...@192.168.205.201 (0 bytes); tunnel 4) I need to issue the ipesec restart command to re-activate the other connections best regards, Steve ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] question about the EAP-SIM authentication
Hi, > I found RAND was read from triplet.dat rather than received from > Server. On the client, RAND is received from the server. But the client uses the RAND value to look up SRES and KC. The triplet.dat file contains RAND/SRES/KC triplets, on the client the RAND value is the key to look up SRES and KC. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
