Re: [RADIATOR] Radiator Version 4.13 released
On 05/02/2014 03:24 PM, Hartmaier Alexander wrote: I've configured the outer PEAP Handler with EAPTLS_MaxFragmentSize 1350 and removed the value 1250 (1300 which we use for wired dot1x seems to be too large) from the inner TLS handler which makes it fail the same way as when configuring 1300. Is the other value too large or how is the inner size calculated? The inner size simply uses the outer fragment size minus 40 bytes. It appears this number is not large enough for all cases then. The correct number in your case is something between 1250 and 1300 when you have outer fragment size 1350? That is, when you have 1350 as outer fragment size, 1250 works but 1300 does not. Thanks, Heikki -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator Version 4.13 released
On 2014-05-05 13:53, Heikki Vatiainen wrote: On 05/02/2014 03:24 PM, Hartmaier Alexander wrote: I've configured the outer PEAP Handler with EAPTLS_MaxFragmentSize 1350 and removed the value 1250 (1300 which we use for wired dot1x seems to be too large) from the inner TLS handler which makes it fail the same way as when configuring 1300. Is the other value too large or how is the inner size calculated? The inner size simply uses the outer fragment size minus 40 bytes. It appears this number is not large enough for all cases then. The correct number in your case is something between 1250 and 1300 when you have outer fragment size 1350? That is, when you have 1350 as outer fragment size, 1250 works but 1300 does not. So what you're saying is that 1350 for the outer results in an inner calcuated one of 1310 bytes which is too large? Which fragment size should be configured, the outer or the inner one? If the inner is calculated from the outer I shouldn't configure the inner one but simply reduce the outer one until it works? The value is the number of bytes the EAP messages are split into and transmitted via the EAP-Message radius attribute, correct? So the number is depended on how much bytes all other radius attributes consume from the MTU which should be 1500 for both wired and wireless in our case? Thanks, Heikki BR Alex *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator Version 4.13 released
On 05/05/2014 03:01 PM, Hartmaier Alexander wrote: The correct number in your case is something between 1250 and 1300 when you have outer fragment size 1350? That is, when you have 1350 as outer fragment size, 1250 works but 1300 does not. So what you're saying is that 1350 for the outer results in an inner calcuated one of 1310 bytes which is too large? Yes, the inner EAP-TLS creates fragments of size 1310 and based on your message, I understand when these are given to outer PEAP for TLS tunneling and transport, the result is too large: it does not fit in 1350. Which fragment size should be configured, the outer or the inner one? If the inner is calculated from the outer I shouldn't configure the inner one but simply reduce the outer one until it works? It should have worked so that the inner fragmentation matches the outer. However, since it does not, you should configure the outer handler MaxFragmentSize to as large value as possible, for example 1350 and then configure the MaxFragmentSize for the inner AuthBy to as large value as possible. It seems 1250 seems to work for you. The value is the number of bytes the EAP messages are split into and transmitted via the EAP-Message radius attribute, correct? Yes, with the addition, that if you have for example an EAP message that is 1300 bytes long, it needs to be broken into EAP-Message attributes which have payload size of 253 bytes. So the number is depended on how much bytes all other radius attributes consume from the MTU which should be 1500 for both wired and wireless in our case? Yes. Also the inner AuthBy's MaxFragmentSize must track the outer fragment size so that the chunks that inner AuthBy produces do not grow too large after TLS processing. This is not a problem with EAP-MSCHAP-V2 but when EAP-TLS is the inner protocol, then the inner AuthBy requires MaxFragmentSize. Thanks, Heikki -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator Version 4.13 released
On 2014-05-05 15:02, Heikki Vatiainen wrote: On 05/05/2014 03:01 PM, Hartmaier Alexander wrote: The correct number in your case is something between 1250 and 1300 when you have outer fragment size 1350? That is, when you have 1350 as outer fragment size, 1250 works but 1300 does not. So what you're saying is that 1350 for the outer results in an inner calcuated one of 1310 bytes which is too large? Yes, the inner EAP-TLS creates fragments of size 1310 and based on your message, I understand when these are given to outer PEAP for TLS tunneling and transport, the result is too large: it does not fit in 1350. Can you add a critical logging for that case so the problem can quickly be found? With a calculated suggested value maybe? Which fragment size should be configured, the outer or the inner one? If the inner is calculated from the outer I shouldn't configure the inner one but simply reduce the outer one until it works? It should have worked so that the inner fragmentation matches the outer. However, since it does not, you should configure the outer handler MaxFragmentSize to as large value as possible, for example 1350 and then configure the MaxFragmentSize for the inner AuthBy to as large value as possible. It seems 1250 seems to work for you. The value is the number of bytes the EAP messages are split into and transmitted via the EAP-Message radius attribute, correct? Yes, with the addition, that if you have for example an EAP message that is 1300 bytes long, it needs to be broken into EAP-Message attributes which have payload size of 253 bytes. Where does the 253 come from? So the number is depended on how much bytes all other radius attributes consume from the MTU which should be 1500 for both wired and wireless in our case? Yes. Also the inner AuthBy's MaxFragmentSize must track the outer fragment size so that the chunks that inner AuthBy produces do not grow too large after TLS processing. This is not a problem with EAP-MSCHAP-V2 but when EAP-TLS is the inner protocol, then the inner AuthBy requires MaxFragmentSize. So the new feature in 4.13 only helps for PEAP-MSCHAPv2, not for PEAP-TLS? Thanks, Heikki *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator Version 4.13 released
On 05/05/2014 04:18 PM, Hartmaier Alexander wrote: Yes, the inner EAP-TLS creates fragments of size 1310 and based on your message, I understand when these are given to outer PEAP for TLS tunneling and transport, the result is too large: it does not fit in 1350. Can you add a critical logging for that case so the problem can quickly be found? With a calculated suggested value maybe? Good idea. I'll ask if it's possible to detect if the inner request fits in. Yes, with the addition, that if you have for example an EAP message that is 1300 bytes long, it needs to be broken into EAP-Message attributes which have payload size of 253 bytes. Where does the 253 come from? It's just the RADIUS attribute format: one byte for type, one for length and 253 for the payload size since the length field is only one octet long. Yes. Also the inner AuthBy's MaxFragmentSize must track the outer fragment size so that the chunks that inner AuthBy produces do not grow too large after TLS processing. This is not a problem with EAP-MSCHAP-V2 but when EAP-TLS is the inner protocol, then the inner AuthBy requires MaxFragmentSize. So the new feature in 4.13 only helps for PEAP-MSCHAPv2, not for PEAP-TLS? PEAP/EAP-MSCHAP-V2 should not run into fragmentation issue the EAP-MSCHAP-V2 message are short. It was meant for PEAP/EAP-TLS since EAP-TLS can create long requests. Any configuration that worked before 4.13 should work with 4.13 too. The idea was to make sure any new configurations would not need to worry about fragmentation issues when EAP-TLS was the tunnelled protocol. Thanks, Heikki -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator Version 4.13 released
On 2014-05-05 15:39, Heikki Vatiainen wrote: On 05/05/2014 04:18 PM, Hartmaier Alexander wrote: Yes, the inner EAP-TLS creates fragments of size 1310 and based on your message, I understand when these are given to outer PEAP for TLS tunneling and transport, the result is too large: it does not fit in 1350. Can you add a critical logging for that case so the problem can quickly be found? With a calculated suggested value maybe? Good idea. I'll ask if it's possible to detect if the inner request fits in. Thanks! Yes, with the addition, that if you have for example an EAP message that is 1300 bytes long, it needs to be broken into EAP-Message attributes which have payload size of 253 bytes. Where does the 253 come from? It's just the RADIUS attribute format: one byte for type, one for length and 253 for the payload size since the length field is only one octet long. So one RADIUS attribute can't get longer than 253 bytes so the EAP message is split into multiple EAP-Message attributes across multiple RADIUS request packets as well as multiple times in a single packet? Yes. Also the inner AuthBy's MaxFragmentSize must track the outer fragment size so that the chunks that inner AuthBy produces do not grow too large after TLS processing. This is not a problem with EAP-MSCHAP-V2 but when EAP-TLS is the inner protocol, then the inner AuthBy requires MaxFragmentSize. So the new feature in 4.13 only helps for PEAP-MSCHAPv2, not for PEAP-TLS? PEAP/EAP-MSCHAP-V2 should not run into fragmentation issue the EAP-MSCHAP-V2 message are short. It was meant for PEAP/EAP-TLS since EAP-TLS can create long requests. Any configuration that worked before 4.13 should work with 4.13 too. The idea was to make sure any new configurations would not need to worry about fragmentation issues when EAP-TLS was the tunnelled protocol. Yes, the manual configured values continued to work, our wireless PEAP-TLS config is a new one, the old used 1024/800. I just hoped that I could simplify the config and it still works. Should I try removing MaxFragmentSize from both the PEAP and the TLS handler? Thanks, Heikki *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator Version 4.13 released
Hi, the following new feature seems to not work as I'd expect it: PEAP and EAP-TTLS now make maximum fragment size available for inner authentication protocols. EAP-TLS was improved to use this information. This allows PEAP/EAP-TLS and EAP-TTLS/EAP-TLS to work better with environments with variable Framed-MTU sizes. I've configured the outer PEAP Handler with EAPTLS_MaxFragmentSize 1350 and removed the value 1250 (1300 which we use for wired dot1x seems to be too large) from the inner TLS handler which makes it fail the same way as when configuring 1300. Is the other value too large or how is the inner size calculated? Thanks, Alex On 2014-04-16 14:45, Heikki Vatiainen wrote: We are pleased to announce the release of Radiator version 4.13 This version contains one new module for authenticating against YubiKey validation server and YubiHSM, some significant new features and bug fixes. As usual, the new version is available to current licensees from: https://www.open.com.au/radiator/downloads/ and to current evaluators from: https://www.open.com.au/radiator/demo-downloads/ Licensees with expired access contracts can renew at: https://www.open.com.au/renewal.html An extract from the history file https://www.open.com.au/radiator/history.html is below: - Revision 4.13 (2014-04-16) Radius proxying, IPv6, TACACS+, Diameter and other enhancements. Bug fixes Selected compatibility notes and enhancements Unknown attributes can now be proxied instead of being dropped Diameter enhancements may require changes to custom Diameter modules Major IPv6 enhancements include: Attributes with IPv6 values can now be proxied without IPv6 support, Socket6 is no longer an absolute prerequisite. 'ipv6:' prefix is now optional and not prepended in attribute values TACACS+ authentication and authorization can now be decoupled Bind variables are now available for AuthLog SQL and Log SQL. Status-Server requests without correct Message-Identifier are ignored. Status-Server responses are now configurable. LDAP attributes can now be fetched with base scope after subtree scoped search. Useful for example, tokenGroups AD attributes which are not otherwise available Newly added check for CVE-2014-0160, the OpenSSL Heartbleed vulnerability may log false positives New AuthBy for authenticating against YubiKey validation server added See Radiator SIM pack revision history for supported SIM pack versions Detailed changes Added the attributes from RFC 6911 to dictionary (Framed-IPv6-Address, DNS-Server-IPv6-Address, Route-IPv6-Information, Delegated-IPv6-Prefix-Pool and Stateful-IPv6-Address-Pool). These attributes override a number of attributes that were previously commandeered by Ascend and Merit. The Ascend ones are still available in ascend.dictionary. The Merit attributes were added under the existing Merit VSA entry and the non-VSA Merit attributes were removed from the main dictionary. The non-VSA Merit attributes will continue to be available in a new file goodies/dictionary.merit AuthBy RADIUS and all its subclasses e.g., AuthBy SQLRADIUS, LDAPRADIUS, MULTICAST and proxy algorithm AuthBys, now support special characters in AuthPort and AcctPort. Suggested by David Zych. Added in dictionary: Huawei-Loopback-Address, vendor 6139 (Alcatel-Lucent OmniAccess), vendor 20942 (China Telecom-Guangzhou Research and Development Center) and vendor 27262 DANTE Ltd. Unknown attributes can now be proxied when the new global configuration flag ProxyUnknownAttributes is set to true. Unknown attributes are now alwasy available with special names such as Unknown-9048-120, where 9048 is the vendor id and 120 is the vendor attribute number. Unknown attributes are now logged with level WARNING instead of ERR. A warning is logged for each attribute once per sender IP address. Attribute names starting with Unknown are reserved in dictionary and ignored when the dictionary is loaded. Added in dictionary: Attributes from RFC 5447, RFC 6519, RFC 6677 and RFC 6930. Added support for dictionary type ipv4prefix required by RFC 6572. An example of ipv4prefix format is '192.168.1.0/24'. Added attributes from RFC 6572 in dictionary. Change in 4.12 caused ServerDIAMETER to always create new peer instances for new connections. This caused mainly WatchdogState DOWN log litter. AuthBy DIAMETER and other DiameterClient derived classes, such as Diameter Wx based EAP-SIM, EAP-AKA and EAP-AKAPRIME AuthBys, now support new option SCTPPeer. This option allows defining multiple SCTP peers for the initial SCTP association attempt. Added vendor Arista in dictionary. Updated Netscreen values. Contributed by Garry Shtern. Fixed AuthBy NTLM so it will not leave zombie processes around during reconfigure. Reported by Garry Shtern. AuthBy RATELIMIT now supports optional parameter MaxRateResult, which allows specifying the result when MaxRate
[RADIATOR] Radiator Version 4.13 released
We are pleased to announce the release of Radiator version 4.13 This version contains one new module for authenticating against YubiKey validation server and YubiHSM, some significant new features and bug fixes. As usual, the new version is available to current licensees from: https://www.open.com.au/radiator/downloads/ and to current evaluators from: https://www.open.com.au/radiator/demo-downloads/ Licensees with expired access contracts can renew at: https://www.open.com.au/renewal.html An extract from the history file https://www.open.com.au/radiator/history.html is below: - Revision 4.13 (2014-04-16) Radius proxying, IPv6, TACACS+, Diameter and other enhancements. Bug fixes Selected compatibility notes and enhancements Unknown attributes can now be proxied instead of being dropped Diameter enhancements may require changes to custom Diameter modules Major IPv6 enhancements include: Attributes with IPv6 values can now be proxied without IPv6 support, Socket6 is no longer an absolute prerequisite. 'ipv6:' prefix is now optional and not prepended in attribute values TACACS+ authentication and authorization can now be decoupled Bind variables are now available for AuthLog SQL and Log SQL. Status-Server requests without correct Message-Identifier are ignored. Status-Server responses are now configurable. LDAP attributes can now be fetched with base scope after subtree scoped search. Useful for example, tokenGroups AD attributes which are not otherwise available Newly added check for CVE-2014-0160, the OpenSSL Heartbleed vulnerability may log false positives New AuthBy for authenticating against YubiKey validation server added See Radiator SIM pack revision history for supported SIM pack versions Detailed changes Added the attributes from RFC 6911 to dictionary (Framed-IPv6-Address, DNS-Server-IPv6-Address, Route-IPv6-Information, Delegated-IPv6-Prefix-Pool and Stateful-IPv6-Address-Pool). These attributes override a number of attributes that were previously commandeered by Ascend and Merit. The Ascend ones are still available in ascend.dictionary. The Merit attributes were added under the existing Merit VSA entry and the non-VSA Merit attributes were removed from the main dictionary. The non-VSA Merit attributes will continue to be available in a new file goodies/dictionary.merit AuthBy RADIUS and all its subclasses e.g., AuthBy SQLRADIUS, LDAPRADIUS, MULTICAST and proxy algorithm AuthBys, now support special characters in AuthPort and AcctPort. Suggested by David Zych. Added in dictionary: Huawei-Loopback-Address, vendor 6139 (Alcatel-Lucent OmniAccess), vendor 20942 (China Telecom-Guangzhou Research and Development Center) and vendor 27262 DANTE Ltd. Unknown attributes can now be proxied when the new global configuration flag ProxyUnknownAttributes is set to true. Unknown attributes are now alwasy available with special names such as Unknown-9048-120, where 9048 is the vendor id and 120 is the vendor attribute number. Unknown attributes are now logged with level WARNING instead of ERR. A warning is logged for each attribute once per sender IP address. Attribute names starting with Unknown are reserved in dictionary and ignored when the dictionary is loaded. Added in dictionary: Attributes from RFC 5447, RFC 6519, RFC 6677 and RFC 6930. Added support for dictionary type ipv4prefix required by RFC 6572. An example of ipv4prefix format is '192.168.1.0/24'. Added attributes from RFC 6572 in dictionary. Change in 4.12 caused ServerDIAMETER to always create new peer instances for new connections. This caused mainly WatchdogState DOWN log litter. AuthBy DIAMETER and other DiameterClient derived classes, such as Diameter Wx based EAP-SIM, EAP-AKA and EAP-AKAPRIME AuthBys, now support new option SCTPPeer. This option allows defining multiple SCTP peers for the initial SCTP association attempt. Added vendor Arista in dictionary. Updated Netscreen values. Contributed by Garry Shtern. Fixed AuthBy NTLM so it will not leave zombie processes around during reconfigure. Reported by Garry Shtern. AuthBy RATELIMIT now supports optional parameter MaxRateResult, which allows specifying the result when MaxRate is exceeded. MaxRateResult defaults to IGNORE. Significant IPv6 changes. Socket6.pm is no longer required if the core Socket module provides the required IPv6 support. Attributes with IPv6 address or prefix type are now handled as binary if there is no Socket or Socket6 for IPv6 support. This fixes the problem with proxying when Socket6 was not installed. Prefix 'ipv6:' for IPv6 addresses is no longer required but will be accepted. Decoded values for IPv6 address type attributes will no longer have 'ipv6:' prefix. Startup log messages now contain information about the IPv6 support. Updated 3GPP (vendor 10415) attributes in dictionary. 3GPP-Allocate-IP-Type, 3GPP-External-Identifier and 3GPP-TWAN-Identifier were added. 3GPP-Charging-Gateway-Address,
