Any objections? I think we're pretty much OK. I also think that after 2.2.7, we will EOL the version 2 series. This means that security fixes will be added, but we will no longer be having regular releases. Now that 3.0 is available, we recommend that new deployments use that, instead of version 2. Alan DeKok.
On Mon, Mar 30, 2015 at 01:38:01PM -0400, Alan DeKok wrote:
Any objections? I think we're pretty much OK.
No objections here.
I also think that after 2.2.7, we will EOL the version 2 series. This means that security fixes will be added, but we will no longer be having regular releases. Now that 3.0 is available, we recommend that new deployments use that, instead of version 2.
Sounds like a good idea to me. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 30 Mar 2015, at 18:17, Matthew Newton <mcn4@LEICESTER.AC.UK> wrote:
On Mon, Mar 30, 2015 at 01:38:01PM -0400, Alan DeKok wrote:
Any objections? I think we're pretty much OK.
Maybe disable TLS v1.2 for compatibility...
I also think that after 2.2.7, we will EOL the version 2 series. This means that security fixes will be added, but we will no longer be having regular releases. Now that 3.0 is available, we recommend that new deployments use that, instead of version 2.
Sounds like a good idea to me.
Kill it with fire. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Mon, Mar 30, 2015 at 07:05:06PM -0400, Arran Cudbard-Bell wrote:
On Mon, Mar 30, 2015 at 01:38:01PM -0400, Alan DeKok wrote:
Any objections? I think we're pretty much OK.
Maybe disable TLS v1.2 for compatibility...
Compatibility with what? If there's a compelling security reason to get rid of it then by all means. Otherwise I would freeze v2 as-is. If there is something in v2 that currently breaks stuff, all the more reason to leave it there :) Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 30 Mar 2015, at 20:09, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Mon, Mar 30, 2015 at 07:05:06PM -0400, Arran Cudbard-Bell wrote:
On Mon, Mar 30, 2015 at 01:38:01PM -0400, Alan DeKok wrote:
Any objections? I think we're pretty much OK.
Maybe disable TLS v1.2 for compatibility...
Compatibility with what?
eapol_test, booo. Noticed today that with TLS 1.2 FR and eapol_test 2.4 (and so presumably wpa_supplicant) disagreed on the MPPE keys. Not sure where the fault lies there. Both were running on the same machine, linked against the same version of OpenSSL. Only allowing TLS 1.0 and 1.1 fixed the problem. eapol_test also doesn't send the RFC 5077 session ticket extension in the client hello. Stupid eapol_test *grumble*.
If there's a compelling security reason to get rid of it then by all means. Otherwise I would freeze v2 as-is. If there is something in v2 that currently breaks stuff, all the more reason to leave it there :)
This is true, and it is fixable in the config using some hidden config items :) -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Noticed today that with TLS 1.2 FR and eapol_test 2.4 (and so presumably wpa_supplicant) disagreed on the MPPE keys. Not sure where the fault lies there. Both were running on the same machine, linked against the same version of OpenSSL.
Only allowing TLS 1.0 and 1.1 fixed the problem.
eapol_test also doesn't send the RFC 5077 session ticket extension in the client hello. Stupid eapol_test *grumble*.
Something to raise with Jouni perhaps... Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
On Mon, Mar 30, 2015 at 08:17:03PM -0400, Arran Cudbard-Bell wrote:
Maybe disable TLS v1.2 for compatibility...
Compatibility with what?
eapol_test, booo.
Hmmm, booo indeed.
Noticed today that with TLS 1.2 FR and eapol_test 2.4 (and so presumably wpa_supplicant) disagreed on the MPPE keys. Not sure where the fault lies there. Both were running on the same machine, linked against the same version of OpenSSL.
Only allowing TLS 1.0 and 1.1 fixed the problem.
That seems like the wrong fix :(
eapol_test also doesn't send the RFC 5077 session ticket extension in the client hello. Stupid eapol_test *grumble*.
Looks like it would be best to try and find what the actual cause is - if it's eapol_test then that should be fixed, rather than removing TLS 1.2 from FreeRADIUS. A config option in FR would IMHO be the best way for this, like the allow broken openssl one. And something that touches as little code as possible in the stable release.
This is true, and it is fixable in the config using some hidden config items :)
I'd document them and leave it as-is :) I guess the only reason to do otherwise is to stop timewasting questions being posted to this list... Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Hmm... While poking around, it's just noticed it's not possible in an all TLS 1.2 environment to prohibit TLS 1.0 from being used in FreeRADIUS. This is very atypical desire today but the ability to configure this is likely to be useful down the line. Nick
-I've- just noticed... On Tue, Mar 31, 2015 at 11:00 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
Hmm... While poking around, it's just noticed it's not possible in an all TLS 1.2 environment to prohibit TLS 1.0 from being used in FreeRADIUS.
This is very atypical desire today but the ability to configure this is likely to be useful down the line.
Nick
On Mar 31, 2015, at 6:00 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
Hmm... While poking around, it's just noticed it's not possible in an all TLS 1.2 environment to prohibit TLS 1.0 from being used in FreeRADIUS.
This is very atypical desire today but the ability to configure this is likely to be useful down the line.
I've pushed a fix. It will be in 2.2.7 and 3.0.8. Alan DeKok.
On 31 Mar 2015, at 11:29, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 31, 2015, at 6:00 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
Hmm... While poking around, it's just noticed it's not possible in an all TLS 1.2 environment to prohibit TLS 1.0 from being used in FreeRADIUS.
This is very atypical desire today but the ability to configure this is likely to be useful down the line.
I've pushed a fix. It will be in 2.2.7 and 3.0.8.
Following Jouni's helpful hint, there's also a fix for MPPE key calculation for TLS 1.2, which will go into 2.2.7 and 3.0.8. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Cool! :) I can only see it in the 3.0.x branch at the moment and not 2.x.x and 3.1.x. Just a thought, I wonder if FreeRADIUS should error more explicitly if somebody decides to be stupid and disable TLS 1.0, 1.1 and 1.2. Cheers, Nick On Tue, Mar 31, 2015 at 4:29 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 31, 2015, at 6:00 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
Hmm... While poking around, it's just noticed it's not possible in an all TLS 1.2 environment to prohibit TLS 1.0 from being used in FreeRADIUS.
This is very atypical desire today but the ability to configure this is likely to be useful down the line.
I've pushed a fix. It will be in 2.2.7 and 3.0.8.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Mar 31, 2015, at 5:04 PM, Nick Lowe <nick.lowe@gmail.com> wrote:
I can only see it in the 3.0.x branch at the moment and not 2.x.x and 3.1.x.
I'll push it to 3.1.x.
Just a thought, I wonder if FreeRADIUS should error more explicitly if somebody decides to be stupid and disable TLS 1.0, 1.1 and 1.2.
Sure... if you're crazy and break your configuration, error messages are a lower priority. Alan DeKok.
On Tue, Mar 31, 2015 at 3:17 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 30 Mar 2015, at 20:09, Matthew Newton <mcn4@leicester.ac.uk> wrote: Compatibility with what?
eapol_test, booo.
Compatibility with any correct TLSv1.2 -based implementation..
Noticed today that with TLS 1.2 FR and eapol_test 2.4 (and so presumably wpa_supplicant) disagreed on the MPPE keys. Not sure where the fault lies there. Both were running on the same machine, linked against the same version of OpenSSL.
FreeRADIUS has incorrect key derivation for TLSv1.2. eaptls_gen_mppe_keys() has not taken into account that the PRF algorithm changes in the new TLS version. That PRF() call there would need to be modified to take into acocunt that difference between TLS versions. Or likely much more easily, you could move to using SSL_export_keying_material() whenever building with OpenSSL 1.0.1 or newer. That has some complexities for EAP-FAST (not supported by that OpenSSL function because someone thought that it would be create to design EAP-FAST in a way that is different from others..). Anyway, EAP-FAST is not supported yet by FreeRADIUS and has interop issues with TLS v1.2 anyway, so it is unclear when it is going to need new key derivation.. wpa_supplicant, and as such, eapol_test, too, uses SSL_export_keying_material() in this case to get the correct keys out from OpenSSL.
Only allowing TLS 1.0 and 1.1 fixed the problem.
Well, yes. That avoids the case where eaptls_gen_mppe_keys() needs to use another PRF.
eapol_test also doesn't send the RFC 5077 session ticket extension in the client hello. Stupid eapol_test *grumble*.
If only the deployed authentication servers were to support TLS extensions.. Clients have to disable session tickets due to so many broken RADIUS servers out there with TLS implementation rejecting any attempt to connect with such an extension included. - Jouni
Jouni, Isn't it about time to, by default, include TLS extensions in the Client Hello and have an option to switch it off for any broken servers? Incidentally, just looking at the code in wpa_supplicant, only when OpenSSL is used is TLS 1.2 used/supported. It's hard coded for TLS 1.0 with all the other SSL/TLS implementations. Cheers, Nick
If only the deployed authentication servers were to support TLS extensions.. Clients have to disable session tickets due to so many broken RADIUS servers out there with TLS implementation rejecting any attempt to connect with such an extension included.
On Tue, Mar 31, 2015 at 1:33 PM, Nick Lowe <nick.lowe@gmail.com> wrote:
Isn't it about time to, by default, include TLS extensions in the Client Hello and have an option to switch it off for any broken servers?
Are you talking of any specific TLS extension here? It does not look reasonable yet to enable session tickets by default. There is not much real benefit from them to EAP-TLS/PEAP/TTLS (and EAP-FAST uses session tickets in its own peculiar ways) and since there continue to be reports of failures to connect to various WPA2-Enterprise networks, the default behavior is unlikely to change any time soon. If there are real use cases that would benefit from session tickets, a configurable option to do so could be added. Other TLS extensions are used based on what the TLS library does and OCSP (status request extension) can be enabled through configuration.
Incidentally, just looking at the code in wpa_supplicant, only when OpenSSL is used is TLS 1.2 used/supported. It's hard coded for TLS 1.0 with all the other SSL/TLS implementations.
I'm not sure what this is based on, but it is not correct. Both the GnuTLS and internal TLS implementation can use TLS v1.1 and v1.2 (though, the internal TLS implementation is quite limited in 1.2 support). - Jouni
On 31 Mar 2015, at 07:15, Jouni Malinen <jkmalinen@gmail.com> wrote:
On Tue, Mar 31, 2015 at 1:33 PM, Nick Lowe <nick.lowe@gmail.com> wrote:
Isn't it about time to, by default, include TLS extensions in the Client Hello and have an option to switch it off for any broken servers?
Are you talking of any specific TLS extension here? It does not look reasonable yet to enable session tickets by default. There is not much real benefit from them to EAP-TLS/PEAP/TTLS (and EAP-FAST uses session tickets in its own peculiar ways) and since there continue to be reports of failures to connect to various WPA2-Enterprise networks, the default behavior is unlikely to change any time soon. If there are real use cases that would benefit from session tickets, a configurable option to do so could be added.
It means that session resumption works against a cluster of RADIUS servers with a front end load balancer, without the need for a common session data store. Granted, that's only strictly true for EAP-TLS and EAP-TTLS/PEAP (if anonymous outer identities are disallowed), but it's still useful. An option to allow it would be appreciated. If OpenSSL presented a sane API or serialised ex_data, we could've embedded the session-state list in the ticket, and stored the inner identity too. That would have negated the need for a common database or store for anonymous outer identities. Unfortunately OpenSSL doesn't do either of those things... After commenting out SSL_OP_NO_TICKET in the wpa_supplicant I can see sessions being resumed successfully. I've tested the case where the client presents the session ticket extension and support is not enabled on the server, it doesn't cause issues, at least not with OpenSSL 1.0.1f. Other SSL implementations or versions might not be so forgiving. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Tue, Mar 31, 2015 at 5:01 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
It means that session resumption works against a cluster of RADIUS servers with a front end load balancer, without the need for a common session data store.
Granted, that's only strictly true for EAP-TLS and EAP-TTLS/PEAP (if anonymous outer identities are disallowed), but it's still useful. An option to allow it would be appreciated.
It should actually already be possible to enable this by adding phase1="tls_disable_session_ticket=0" into the network profile in wpa_supplicant/eapol_test. This workaround (of not sending session ticket) can also be disabled with eap_workaround=0, but it looks like that actually results in other issues with FreeRADIUS (mismatch in EAP-MSCHAPv2 header length when used within PEAP), so at least for now, the phase1 parameter to do this looks like the way to go, if you want to use TLS session ticket.
If OpenSSL presented a sane API or serialised ex_data, we could've embedded the session-state list in the ticket, and stored the inner identity too. That would have negated the need for a common database or store for anonymous outer identities. Unfortunately OpenSSL doesn't do either of those things...
I've done something similar with EAP-FAST, but that is all handled outside OpenSSL.
I've tested the case where the client presents the session ticket extension and support is not enabled on the server, it doesn't cause issues, at least not with OpenSSL 1.0.1f. Other SSL implementations or versions might not be so forgiving.
I don't know which TLS implementation is involved in the problem cases or whether the EAP server implementation manages to break this on its own. Anyway, none of the reported interop issues with TLS session ticket extension have been with FreeRADIUS. - Jouni
On Mar 31, 2015, at 10:53 AM, Jouni Malinen <jkmalinen@gmail.com> wrote:
It should actually already be possible to enable this by adding phase1="tls_disable_session_ticket=0" into the network profile in wpa_supplicant/eapol_test.
That's good to know.
This workaround (of not sending session ticket) can also be disabled with eap_workaround=0, but it looks like that actually results in other issues with FreeRADIUS (mismatch in EAP-MSCHAPv2 header length when used within PEAP),
Hmm... I don't see that here. Do you have packet traces / debug logs? And the inner EAP data in PEAP is... stupid. Very, very, stupid. <sigh>
I don't know which TLS implementation is involved in the problem cases or whether the EAP server implementation manages to break this on its own. Anyway, none of the reported interop issues with TLS session ticket extension have been with FreeRADIUS.
That's good to know. Alan DeKok.
On Tue, Mar 31, 2015 at 7:16 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 31, 2015, at 10:53 AM, Jouni Malinen <jkmalinen@gmail.com> wrote:
This workaround (of not sending session ticket) can also be disabled with eap_workaround=0, but it looks like that actually results in other issues with FreeRADIUS (mismatch in EAP-MSCHAPv2 header length when used within PEAP),
Hmm... I don't see that here. Do you have packet traces / debug logs?
I was going to say that I cannot reproduce it anymore, but then I remembered that I tested with number of FreeRADIUS versions today. This does not show up with 2.2.6, but does show up with 3.0.2. I didn't have a more recent 3.0.x compiled in the earlier tests, but now that I checked with 3.0.7, it looks like the issue has been fixed. The error with 3.0.2 when eap_workaround=0 is used looked like this: EAP-PEAP: TLS done, proceed to Phase 2 ... EAP-PEAP: Selected Phase 2 EAP vendor 0 method 26 EAP-MSCHAPV2: Invalid header: len=71 ms_len=33 Anyway, with that having already been addressed, eap_workaround=0 seems to work fine with both 2.2.6 and 3.0.7 and that does allow TLS session ticket to be used.
And the inner EAP data in PEAP is... stupid. Very, very, stupid. <sigh>
Indeed.. And to make it even worse, the behavior is different between PEAP v0 and v1 (or v2 that almost no one supports).. - Jouni
On Mar 31, 2015, at 1:00 PM, Jouni Malinen <jkmalinen@gmail.com> wrote:
I was going to say that I cannot reproduce it anymore, but then I remembered that I tested with number of FreeRADIUS versions today. This does not show up with 2.2.6, but does show up with 3.0.2. I didn't have a more recent 3.0.x compiled in the earlier tests, but now that I checked with 3.0.7, it looks like the issue has been fixed.
That's good. We've added a lot of regression tests in the last 6 months. It helps enormously.
The error with 3.0.2 when eap_workaround=0 is used looked like this: EAP-PEAP: TLS done, proceed to Phase 2 ... EAP-PEAP: Selected Phase 2 EAP vendor 0 method 26 EAP-MSCHAPV2: Invalid header: len=71 ms_len=33
Ah... the extended EAP packets. That came up on the list: http://lists.freeradius.org/pipermail/freeradius-users/2015-March/075995.htm... The supplicant was sending an entire EAP packet inside of an extended EAP packet. i.e. the extended EAP packet didn't contain the data for EAP type 26. Instead, it contain a complete EAP packet. Is that really what's supposed to happen? I don't see that in the RFCs.
Anyway, with that having already been addressed, eap_workaround=0 seems to work fine with both 2.2.6 and 3.0.7 and that does allow TLS session ticket to be used.
OK.
And the inner EAP data in PEAP is... stupid. Very, very, stupid. <sigh>
Indeed.. And to make it even worse, the behavior is different between PEAP v0 and v1 (or v2 that almost no one supports)..
Yeah... Alan DeKok.
On Tue, Mar 31, 2015 at 8:13 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 31, 2015, at 1:00 PM, Jouni Malinen <jkmalinen@gmail.com> wrote:
The error with 3.0.2 when eap_workaround=0 is used looked like this: EAP-PEAP: TLS done, proceed to Phase 2 ... EAP-PEAP: Selected Phase 2 EAP vendor 0 method 26 EAP-MSCHAPV2: Invalid header: len=71 ms_len=33
Ah... the extended EAP packets. That came up on the list:
http://lists.freeradius.org/pipermail/freeradius-users/2015-March/075995.htm...
This "EAP vendor 0 method 26" is not actually a case of an expanded EAP header. wpa_supplicant prints out "vendor 0" for simplicity with the same debug routines, but that IETF vendor code would never use an expanded header. The EAP-MSCHAPv2 header mismatch seems to be something that was fixed somewhere between FreeRADIUS 3.0.2 and 3.0.3. There were number of fixes in that area, so I did not confirm which one was the exact change that addressed this part. Anyway, that's working fine since 3.0.3.
The supplicant was sending an entire EAP packet inside of an extended EAP packet. i.e. the extended EAP packet didn't contain the data for EAP type 26. Instead, it contain a complete EAP packet.
Is that really what's supposed to happen? I don't see that in the RFCs.
I'm not sure what to say about PEAP v0 and various incarnations of it from Microsoft, but PEAP v1 and other tunneling EAP methods should allow expanded EAP header to be used within the tunnel. MS-PEAP is a bit strange on this due to the lovely optimization of not included the inner header in _some_ cases.. There is no point in using the expanded header with IETF vendor 0. I think it is allowed (with the potential caveat of MS-PEAP having an exception), though. As an example, if I configure wpa_supplicant to use expanded EAP header for EAP-MSCHAPv2 within PEAP tunnel, authentication does work against hostapd as the EAP server. Actually, this seemed to work both with PEAPv0 (four bytes of the inner EAP header removed) and PEAPv1 (full inner EAP header included). Not that I would expect anyone to use such a setup with EAP-MSCHAPv2, but anyway, yes, the expanded header can be used even within a PEAP tunnel. As far as that specific log in the "MACSEC on Cisco 3750-X and FreeRADIUS 2.2.5" thread is concerned, that does look very similar to the output I see in my test that forced expanded EAP header to be used in the tunnel. I can reproduce the same result against FreeRADIUS 3.0.7 with my modified eapol_test version: (8) eap_peap: Session established. Decoding tunneled attributes (8) eap_peap: PEAP state phase2 (8) eap_peap: EAP type unknown (254) (8) eap_peap: Got tunneled request (8) eap_peap: EAP-Message = 0x0208004efe0000000000001a0208004231d9f55a7fcffb4ef8c1cf17df47726130000000000000000066e764105cf7c78c7e33f67d8aa85334cf6e71900dd9ee6a006a6b6d2d6d73636861707632 (8) eap_peap: Setting User-Name to jkm-mschapv2 (8) eap_peap: Sending tunneled request to inner-tunnel (8) eap_peap: EAP-Message = 0x0208004efe0000000000001a0208004231d9f55a7fcffb4ef8c1cf17df47726130000000000000000066e764105cf7c78c7e33f67d8aa85334cf6e71900dd9ee6a006a6b6d2d6d73636861707632 This is then failing here: (8) # Executing group from file /home/jm/FreeRADIUS/307/etc/raddb/sites-enabled/inner-tunnel (8) authenticate { (8) eap: Badly formatted EAP Message: Ignoring the packet (8) eap: Failed in handler (8) [eap] = invalid (8) } # authenticate = invalid (8) Failed to authenticate the user So the outer handling looks fine, but the inner tunnel handler is clearly unwilling to accept expanded EAP header. I would say that it would be reasonable to make FreeRADIUS support expanded EAP header here. RFC 3748 has following to say about this: "An implementation that supports the Expanded attribute MUST treat EAP Types that are less than 256 equivalently, whether they appear as a single octet or as the 32-bit Vendor-Type within an Expanded Type where Vendor-Id is 0." I guess it would be fair to say that FreeRADIUS doesn't currently support the Expanded attribute, so in that sense the MUST requirement does not apply. Anyway, it would not be that difficult to add support for this if there are real EAP clients that do decide to use expanded header with vendor=0 for some strange reason. eapol_test supports this if you want to run a test yourself. It is not configurable, though, so the following change would be needed for such a test: diff --git a/src/eap_common/eap_common.c b/src/eap_common/eap_common.c index 1de1328..f1f65c3 100644 --- a/src/eap_common/eap_common.c +++ b/src/eap_common/eap_common.c @@ -131,8 +131,11 @@ struct wpabuf * eap_msg_alloc(int vendor, EapType type, size_t payload_len, struct wpabuf *buf; struct eap_hdr *hdr; size_t len; + int expanded = vendor != EAP_VENDOR_IETF; - len = sizeof(struct eap_hdr) + (vendor == EAP_VENDOR_IETF ? 1 : 8) + + if (type == EAP_TYPE_MSCHAPV2 && code == EAP_CODE_RESPONSE) + expanded = 1; /* TESTING */ + len = sizeof(struct eap_hdr) + (expanded ? 8 : 1) + payload_len; buf = wpabuf_alloc(len); if (buf == NULL) @@ -143,7 +146,7 @@ struct wpabuf * eap_msg_alloc(int vendor, EapType type, size_t payload_len, hdr->identifier = identifier; hdr->length = host_to_be16(len); - if (vendor == EAP_VENDOR_IETF) { + if (!expanded) { wpabuf_put_u8(buf, type); } else { wpabuf_put_u8(buf, EAP_TYPE_EXPANDED); (sorry about the lack of indentation.. not feeling like fixing this with gmail) - Jouni
On Mar 31, 2015, at 2:42 PM, Jouni Malinen <jkmalinen@gmail.com> wrote:
There is no point in using the expanded header with IETF vendor 0. I think it is allowed (with the potential caveat of MS-PEAP having an exception), though. As an example, if I configure wpa_supplicant to use expanded EAP header for EAP-MSCHAPv2 within PEAP tunnel, authentication does work against hostapd as the EAP server. Actually, this seemed to work both with PEAPv0 (four bytes of the inner EAP header removed) and PEAPv1 (full inner EAP header included). Not that I would expect anyone to use such a setup with EAP-MSCHAPv2, but anyway, yes, the expanded header can be used even within a PEAP tunnel.
OK.
As far as that specific log in the "MACSEC on Cisco 3750-X and FreeRADIUS 2.2.5" thread is concerned, that does look very similar to the output I see in my test that forced expanded EAP header to be used in the tunnel. I can reproduce the same result against FreeRADIUS 3.0.7 with my modified eapol_test version:
(8) eap_peap: Session established. Decoding tunneled attributes (8) eap_peap: PEAP state phase2 (8) eap_peap: EAP type unknown (254) (8) eap_peap: Got tunneled request (8) eap_peap: EAP-Message = 0x0208004efe0000000000001a0208004231d9f55a7fcffb4ef8c1cf17df47726130000000000000000066e764105cf7c78c7e33f67d8aa85334cf6e71900dd9ee6a006a6b6d2d6d73636861707632 (8) eap_peap: Setting User-Name to jkm-mschapv2 (8) eap_peap: Sending tunneled request to inner-tunnel (8) eap_peap: EAP-Message = 0x0208004efe0000000000001a0208004231d9f55a7fcffb4ef8c1cf17df47726130000000000000000066e764105cf7c78c7e33f67d8aa85334cf6e71900dd9ee6a006a6b6d2d6d73636861707632
I suppose that should work.
So the outer handling looks fine, but the inner tunnel handler is clearly unwilling to accept expanded EAP header.
Yeah. The EAP module just refuses to decode expanded types.
I would say that it would be reasonable to make FreeRADIUS support expanded EAP header here. RFC 3748 has following to say about this: "An implementation that supports the Expanded attribute MUST treat EAP Types that are less than 256 equivalently, whether they appear as a single octet or as the 32-bit Vendor-Type within an Expanded Type where Vendor-Id is 0."
Oops.
I guess it would be fair to say that FreeRADIUS doesn't currently support the Expanded attribute, so in that sense the MUST requirement does not apply. Anyway, it would not be that difficult to add support for this if there are real EAP clients that do decide to use expanded header with vendor=0 for some strange reason.
There are vendors doing this, I think. I'll take a look at fixing FR, but it's not overly a priority.
eapol_test supports this if you want to run a test yourself. It is not configurable, though, so the following change would be needed for such a test:
OK, thanks. Alan DeKok.
On Mar 31, 2015, at 2:42 PM, Jouni Malinen <jkmalinen@gmail.com> wrote:
if you want to run a test yourself. It is not configurable, though, so the following change would be needed for such a test:
Tested && pushed new code to FreeRADIUS. That will be in 3.0.8. It will now accept expanded types, with Vendor-ID 0, and Vendor-Types < 255. Alan DeKok.
On 31 Mar 2015, at 06:19, Jouni Malinen <jkmalinen@gmail.com> wrote:
On Tue, Mar 31, 2015 at 3:17 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 30 Mar 2015, at 20:09, Matthew Newton <mcn4@leicester.ac.uk> wrote: Compatibility with what?
eapol_test, booo.
Compatibility with any correct TLSv1.2 -based implementation..
:)
Noticed today that with TLS 1.2 FR and eapol_test 2.4 (and so presumably wpa_supplicant) disagreed on the MPPE keys. Not sure where the fault lies there. Both were running on the same machine, linked against the same version of OpenSSL.
FreeRADIUS has incorrect key derivation for TLSv1.2. eaptls_gen_mppe_keys() has not taken into account that the PRF algorithm changes in the new TLS version. That PRF() call there would need to be modified to take into acocunt that difference between TLS versions. Or likely much more easily, you could move to using SSL_export_keying_material() whenever building with OpenSSL 1.0.1 or newer. That has some complexities for EAP-FAST (not supported by that OpenSSL function because someone thought that it would be create to design EAP-FAST in a way that is different from others..). Anyway, EAP-FAST is not supported yet by FreeRADIUS and has interop issues with TLS v1.2 anyway, so it is unclear when it is going to need new key derivation..
wpa_supplicant, and as such, eapol_test, too, uses SSL_export_keying_material() in this case to get the correct keys out from OpenSSL.
Ok, i'll take a look at fixing that. Thanks! -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Any objections? I think we're pretty much OK. I also think that after 2.2.7, we will EOL the version 2 series. This means that security fixes will be added, but we will no longer be having regular releases. Now that 3.0 is available, we recommend that new deployments use that, instead of version 2.
And the RHEL/CentOS 6.5 crowd cry... ;-) In all seriousness, v3 is pretty stable for that platform. Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
participants (6)
-
Alan DeKok -
Arran Cudbard-Bell -
Jouni Malinen -
Matthew Newton -
Nick Lowe -
Stefan Paetow