[strongSwan] questions on strongswan MSK handling during EAP-AKA with freeradius

[Mao, Zhiheng]

Hi,



I am using strongswan 5.0.1 server (Moon) with an external freeradius server (version 1.1.2) to authenticate the client (Carol) using EAP-AKA. When freeradius server sends Access-Accept with the MS-MPPE-Recv-Key and MS-MPPE-Send-Key, Moon tried to decrypt these two attributes (inside decrypt_mppe_key) and combine them to form the MSK. I then tried to locate the similar code on the Carol side, but I could not find where Carol is decrypting and constructing the MSK the same way as Moon does. This will ultimately cause Moon and Carol to hold different MSKs. So my questions are:



Does the client decrypt the recv and send keys at all?

Should the client do the same decryption and combining as the server, or should the server skip the decryption and simply construct the MSK as the client does?

Is it allowed by standard that the server can simply construct the MSK from the raw recv and send keys in the Access-Accept without decryption?



When Moon was decrypting these attributes, it did encounter a packet format problem. The freeradius's log shows:
        Sending Access-Accept of id 211 to 127.0.0.1 port 33549
        MS-MPPE-Recv-Key = 0x4d083a0fe3a364c0f3b67f8c6a32ea053a6794493e14aee3409b263e03f1c7c2
        MS-MPPE-Send-Key = 0xbbdb6202eef72abae47267b2f147f04cb8ab5cc6e45950c87472eb3cbf041c57

And the chron log shows:

Dec 17 12:03:32 nemo-iwf charon: 11[CFG]   16: A2 6F 8F 85 1A 28 00 00 01 37 11 22 4D 08 3A 0F

Dec 17 12:03:32 nemo-iwf charon: 11[CFG]   32: E3 A3 64 C0 F3 B6 7F 8C 6A 32 EA 05 3A 67 94 49

Dec 17 12:03:32 nemo-iwf charon: 11[CFG]   48: 3E 14 AE E3 40 9B 26 3E 03 F1 C7 C2 1A 28 00 00

Dec 17 12:03:32 nemo-iwf charon: 11[CFG]   64: 01 37 10 22 BB DB 62 02 EE F7 2A BA E4 72 67 B2

Dec 17 12:03:32 nemo-iwf charon: 11[CFG]   80: F1 47 F0 4C B8 AB 5C C6 E4 59 50 C8 74 72 EB 3C

Dec 17 12:03:32 nemo-iwf charon: 11[CFG]   96: BF 04 1C 57 4F 06 03 95 00 04 50 12 A6 58 A5



It looks like the freeradius simply sends the recv and send keys (32 bytes each), but there is no place for the "salt" according to the RFC2548. Or if the first two bytes are the "salt", then the remaining recv and send keys would be 30 bytes each (not multiple of 16), causing decryption to fail. So my question is:



Is this freeradius's version too old and does not follow the packet format as described in RFC2548? Is this a known problem?



Thanks a lot!



Zhiheng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130114/f1c4293c/attachment.html>