[RADIATOR] ServerRADSEC: TLSv1.1 and TLSv1.2 are by default disabled even if all software supports them
Hello, I am just now setting up a new incarnation of our RadSEC enabled Radiator server: Radiator 4.17 Net::SSLeay 1.78 OpenSSL 1.0.1e (newest CentOS 7.2 backports) All of which support TLS 1.2. I use a ServerRADSEC clause with UseTLS on but that only establishes TLS 1.0 connections. When poking the server from outside with openssl s_client -tls1_1 or -tls1_2 there is no connection with "SSL3_GET_RECORD:wrong version number". I was able to fix this by adding: TLS_Protocols TLSv1, TLSv1.1, TLSv1.2 and now all is fine on all three version levels. But: it is not exactly a "sane default" to pin all TLS to version 1.0 if newer versions are available on the system. The default that "UseTLS" should trigger is: all TLS versions that are supported in the system. Silently pinning 1.0 is an invitation to continue use of old and weak crypto protocols. Maybe this default could be changed in later versions... Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 0x8A39DC66.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthBy DIAMETER
Hi, > We are now preparing initial release of Radius to Diameter translation > gateway for Radiator. Currently we have implemented limited support for > DIAMETER base RFC 6377 and full support for NASREQ RFC 4005. You should probably not care about RC4005 any more. Its successor is almost ready, and was specifically created to address major deficiencies in RFC4005. The deficiencies were to such an extent that common belief in the IETF is "nobody uses this". See here for the successor draft spec: http://datatracker.ietf.org/doc/draft-ietf-dime-rfc4005bis/ > Our implementation is ready for public beta testing and we are looking > for volunteers for testing our translation gateway. > > If you are willing to test our Radius to Diameter translation gateway, > please reply directly to me and tell me about your intended test > environment and test plans. Out of curiosity: one of the many problems of RFC4005 was that it was syntactically impossible to translate a Diameter attribute of length >253 Bytes into a RADIUS attribute; for obvious reasons. RADIUS has meanwhile specified "long" attributes, making this translation possible. Does your Diameter gateway already include support for extended RADIUS attributes? I'm speaking of RFC6929: http://datatracker.ietf.org/doc/rfc6929/ Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthRADSEC and radsecproxy are incompatible!
Hi, > Does anyone know if creating secondary, tertiary, ... TCP connections > has worked fine? I'm thinking of the alternatives at hand: sticking with > Proxy-State extented IDs (using one TCP connection) or using the port > numbers (multiple TCP connections) for ID space extension? > > Thanks for your input! Well, I know that FreeRADIUS on UDP does it like that: for efficiency reasons it uses the same /source/ port to send requests from, and permanently listens on that same port. That seems to be quite efficient. If it finds that source port in full use, it opens the next port and has 256 new IDs. Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthRADSEC and radsecproxy are incompatible!
erly. Section 2.6.5 states: "The RADIUS ID field is one octet in size. As a result, any one TCP connection can have only 256 "in flight" RADIUS packets at a time. If more than 256 simultaneous "in flight" packets are required, additional TCP connections will need to be opened." So, this works fine without Proxy-State - just like with UDP. And it goes on to say: "Implementations SHOULD reserve ID zero (0) on each TCP connection for Status-Server packets. This value was picked arbitrarily, as there is no reason to choose any one value over another for this use." Which means you'd always have a free packet ID on your TCP connection. IMHO, the RFC couldn't be much clearer than that. > For UDP extended identifier space can also be useful. For example, when > there are strict firewall rules that restrict what the source ports can be. I agree that in such situations, Proxy-State helps (during authentication). If you want to stick to the same source port for Proxy-State, just do the analogous that RFC6613 suggests for TCP: reserve one packet ID code, so that you can always send Status-Server from that source port. If you don't want to statically take the "0" you could also see to it that only at max 255 authentications are in flight, and reserve the 256th for a potential Status-Server that might be coming up. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthRADSEC and radsecproxy are incompatible!
Hi, > in case of connection oriented RADSEC/TCP proxying, it's problem to > decide on client addresses and client ports, It's always the same peer > socket and 8 bits can be very soon to short on a heavy used proxy > connection. > > RADSEC/TCP or RADIUS/TCP came after RFC-2865, maybe we should make > an RFC addendum, that Proxy-State MUST ALWAYS be replied, even in > Status-Server requests. > > Meanwhile we could/should add a config flag in radsecproxy to allow > this. You only send Status-Server once in a long while, meaning you'll only have one packet in flight. You also send it only to servers from which you haven't heard from in a while, so the number of packet identifiers which are currently in use on the socket is always very near 0. Independently of this, it remains a bit unclear to me why Radiator needs the extended-IDs in Proxy-State anyway; if you run out of packet IDs on a given src/dest port/ip combination: you can choose a new source port to send your request from there! There's plenty of source ports. The only reason why identifiers really could run out is if you've used up all your source ports * 256 identifiers for one single destination server. And if you are that busy, you don't need Status-Server :-) Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthRADSEC and radsecproxy are incompatible!
Hi, > this may be true for Status-Server but not for the Access-Rejects > generated by the radsecproxy. This has to be corrected by radsecproxy. > > And yes, Radiator AuthRADSEC has to fix the problem with Status-Server. > Both together are incompatible but often used together in eduroam. Yes, the lack of returning Proxy-State when radsecproxy crafts its own Rejects is definitely a problem of radsecproxy; it violates RFC2865, section 5.33: " This Attribute is available to be sent by a proxy server to another server when forwarding an Access-Request and MUST be returned unmodified in the Access-Accept, Access-Reject or Access-Challenge." I've sent a notice to the radsecproxy mailing list, notifying them of the problem. I'm hoping to see a next release with a proper fix. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator and radsecproxy, status-server and failover algo, one step forward
Hi, > status-server musnt be proxiedits only for the first-hop check of > a remote proxy and not the end target - but that surely isnt the issue? > a Status-Server message is easy to deal with - you just send something back > to show you are alive - RADIATOR has been sending a basic statts page back > for status-server queries to it for years. This is about Status-Server requests *originating* from Radiator to check another server's alive state. Radiator sends a Proxy-State in the request (which is not supposed to be done), and then complains that it doesn't get it back (which is only supposed to happen with Access-Requests, not Status-Server). Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthRADSEC and radsecproxy are incompatible!
Hello, > Maybe someone can trigger the authors of radsecproxy too, to start > implementing Proxy-State RFC 2865 conform when *generating* responses. > Seems it makes everthing right on proxying but not on generating > packets. Status-Server is defined in RFC5997. It uses a distinct command-code - it's not an Access-Request, it's Status-Server. So all the "rules" of an Access-Request and corresponding responses are not relevant. In particular, the attribute Proxy-State is not expected to be in there. See section 5 of that RFC. Adding to that, there is also no reason to use Proxy-State at all because Radiator does not act as proxy - it's acting as a simple RADIUS Client, sending an initial request to some other server. Proxy-State (in Access-Requests) only comes into play when a server *receives* a packet from downstream, then sees that it needs to be sent elsewhere still, and then *forwards* it. Only then does it add Proxy-State. None of this is true with Status-Server; and proxying Status-Server packets is prohibited in section 4.4 of that same RFC. If Radiator generates a Proxy-State (even though it is not acting as a proxy - so why would it do that?), then it's at fault itself. It should not have any expectations of getting it back unharmed. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 signature.asc Description: OpenPGP digital signature ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
