Re: [RADIATOR] Request for TLS_SubjectAltNameDNS check
Hi, On 02/21/2018 12:42 PM, Tuure Vartiainen wrote: how to configure this? My problem is that I need to initiate RadSec connection by IP adress this way: Identifiervsup_cz Host195.113.xx.x Secret radsec When I use HOST = IPaddress I've no option how to tell Radiator which value compare against SubjectAltName:DNS. SuljectAltName:DNS matches against configured Host, so it only works when using FQDNs. I changed the feature request to target adding TLS_SubjectAltNameDNS configuration option similar to TLS_SubjectAltNameURI. http://www.open.com.au/radiator/ref/TLS_SubjectAltNameURI.html#TLS_SubjectAltNameURI there’s now a new config option TLS_SubjectAltNameDNS in latest patches, which can be used to define expected FQDN for SubjectAltName:DNS. thanks for implementing new config option. I finally upgraded a week ago and it works perfectly. Exactly as I needed. Thank you -- --- Jan Tomasek aka Semik http://www.tomasek.cz/ ___ radiator mailing list radiator@lists.open.com.au http://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Request for TLS_SubjectAltNameDNS check
Hello, > On 2 Nov 2017, at 12.06, Tuure Vartiainen wrote: > >> On 31 Oct 2017, at 16.34, Jan Tomasek wrote: >> >> On 10/13/2017 06:57 PM, Tuure Vartiainen wrote: On 11 Oct 2017, at 20.28, Jan Tomasek wrote: Originally we were using hostnames, but as our eduroam federation was growing Radiator start was going to be slower and slower. Delay was indeterministic and was caused by hostname to IP translation, so we switched to IP addresses. But IP addresses are complicating peer verification. At this moment we are using TLS_ExpectedPeerName but our peers sometimes try to use a certificate which has no right SubjectDN, it would be better to be able to verify SubjectAltName:DNS. Is there any chance to get this implemented? Something like TLS_SubjectAltNameURI but for DNS? >>> >>> Radiator currently supports SubjectAltName:DNS when it’s an initiator >>> for RadSec connection. >> >> how to configure this? My problem is that I need to initiate RadSec >> connection by IP adress this way: >> >> >> Identifiervsup_cz >> >> Host195.113.xx.x >> Secret radsec >> >> When I use HOST = IPaddress I've no option how to tell Radiator which value >> compare against SubjectAltName:DNS. >> > > SuljectAltName:DNS matches against configured Host, so it only works when > using FQDNs. > > I changed the feature request to target adding TLS_SubjectAltNameDNS > configuration option similar to > TLS_SubjectAltNameURI. > > http://www.open.com.au/radiator/ref/TLS_SubjectAltNameURI.html#TLS_SubjectAltNameURI > there’s now a new config option TLS_SubjectAltNameDNS in latest patches, which can be used to define expected FQDN for SubjectAltName:DNS. BR -- Tuure Vartiainen 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@lists.open.com.au http://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Request for TLS_SubjectAltNameDNS check
Hi, > On 31 Oct 2017, at 16.34, Jan Tomasek wrote: > > On 10/13/2017 06:57 PM, Tuure Vartiainen wrote: >>> On 11 Oct 2017, at 20.28, Jan Tomasek wrote: >>> >>> Originally we were using hostnames, but as our eduroam federation >>> was growing Radiator start was going to be slower and slower. Delay >>> was indeterministic and was caused by hostname to IP translation, >>> so we switched to IP addresses. But IP addresses are complicating >>> peer verification. At this moment we are using TLS_ExpectedPeerName >>> but our peers sometimes try to use a certificate which has no right >>> SubjectDN, it would be better to be able to verify >>> SubjectAltName:DNS. Is there any chance to get this implemented? >>> Something like TLS_SubjectAltNameURI but for DNS? >>> >> >> Radiator currently supports SubjectAltName:DNS when it’s an initiator >> for RadSec connection. > > how to configure this? My problem is that I need to initiate RadSec > connection by IP adress this way: > > > Identifiervsup_cz > >Host195.113.xx.x >Secret radsec > > When I use HOST = IPaddress I've no option how to tell Radiator which value > compare against SubjectAltName:DNS. > SuljectAltName:DNS matches against configured Host, so it only works when using FQDNs. I changed the feature request to target adding TLS_SubjectAltNameDNS configuration option similar to TLS_SubjectAltNameURI. http://www.open.com.au/radiator/ref/TLS_SubjectAltNameURI.html#TLS_SubjectAltNameURI BR -- Tuure Vartiainen 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@lists.open.com.au http://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Request for TLS_SubjectAltNameDNS check
Hi Tuure, On 10/13/2017 06:57 PM, Tuure Vartiainen wrote: On 11 Oct 2017, at 20.28, Jan Tomasek wrote: Originally we were using hostnames, but as our eduroam federation was growing Radiator start was going to be slower and slower. Delay was indeterministic and was caused by hostname to IP translation, so we switched to IP addresses. But IP addresses are complicating peer verification. At this moment we are using TLS_ExpectedPeerName but our peers sometimes try to use a certificate which has no right SubjectDN, it would be better to be able to verify SubjectAltName:DNS. Is there any chance to get this implemented? Something like TLS_SubjectAltNameURI but for DNS? Radiator currently supports SubjectAltName:DNS when it’s an initiator for RadSec connection. how to configure this? My problem is that I need to initiate RadSec connection by IP adress this way: Identifiervsup_cz Host195.113.xx.x Secret radsec When I use HOST = IPaddress I've no option how to tell Radiator which value compare against SubjectAltName:DNS. Thanks -- --- Jan Tomasek aka Semik http://www.tomasek.cz/ ___ radiator mailing list radiator@lists.open.com.au http://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Request for TLS_SubjectAltNameDNS check
Hi, > On 11 Oct 2017, at 20.28, Jan Tomasek wrote: > > Originally we were using hostnames, but as our eduroam federation was growing > Radiator start was going to be slower and slower. Delay was indeterministic > and was caused by hostname to IP translation, so we switched to IP addresses. > But IP addresses are complicating peer verification. At this moment we are > using TLS_ExpectedPeerName but our peers sometimes try to use a certificate > which has no right SubjectDN, it would be better to be able to verify > SubjectAltName:DNS. Is there any chance to get this implemented? Something > like TLS_SubjectAltNameURI but for DNS? > Radiator currently supports SubjectAltName:DNS when it’s an initiator for RadSec connection. I created a feature request for adding the support also for RadSec responder. BR -- Tuure Vartiainen 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@lists.open.com.au http://lists.open.com.au/mailman/listinfo/radiator
