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
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
