Security

Hi folks,

has anyone been able to setup radsec between controller an radsec proxy successfully?

This feature is driving me crazy. The radsec proxy(Version 1.6.6) is talking radsec successfully with freeradius(Version 3.0.2) but i do not get it working with the controller(Version 6.4.4.1).

I there something special that need to get configured on the proxy site to work with aos?

The controller certifcated is uploaded and configured as Server Cert.

The radsec proxy cert ist uploaded as Public Cert and Configured as Client Cert.

Looking at the logs it seems that the connections fails during SSL-Handshake.

Dec 21 13:57:20 :121042:  <DBUG> |authmgr|  radsec_connect_single_socket: Server FQDN is 'radsec.nwag.lab', IP Address is '10.65.240.254'.
Dec 21 13:57:20 :124004:  <DBUG> |authmgr|  Starting SSL connection to server radsecproxy.domain.lab
Dec 21 13:57:20 :124004:  <DBUG> |authmgr|  tac_connect: connected to 10.65.240.254.
Dec 21 13:57:20 :124004:  <DBUG> |authmgr|  TCP connect success on socket 63
Dec 21 13:57:20 :124004:  <DBUG> |authmgr|  Setting keepalive options for socket 63
Dec 21 13:57:20 :199802:  <ERRS> |authmgr|  radsec.c, RadsecTLSNegotiationHandler:940: Failed to open TLS socket error for radsecproxy.domain.lab
Dec 21 13:57:20 :124004:  <DBUG> |authmgr|  Cleaning up socket 63

Any Ideas?

best regards

Kevin

You should turn on security debugging while you are doing this:

config t

logging level debugging security

When you are attempting to setup/connect, type "show log security 50" to see what it reveals.

Hi Colin,

thanks for your quick reply.

Debugguing is already enabled. The log does not give more than these lines repeatedly.

best regards

Kevin

Are you using public certificates, or private certificates?

Within our Test-Lab i use private certifcates generated by tinyCA.

1. The CA cert for Tiny CA should be uploaded into the controller with type “Trusted CA” - Remember the friendly name you give it when you do this.

2. The Cert to identify the controller to Free Radius or the Radsec Proxy is a server cert and it needs to be uploaded to the controller with the type “ServerCert”.  Remember the friendly name you give the Server Cert when you upload it to the controller.

Later when you configure the Radius Server, you need to enter the friendly names that you uploaded them.  The radius trusted CA name parameter should be the friendly name you assigned when uploading in step 1.  The Radsec Server cert name should be the friendly name you gave it when you uploaded it Step #2.  Lastly, remember that the radius secret is hardcoded to "radsec" as per the RFC.

It does not allow me to configure

- Radsec Trusted CA Name

and

- Radsec Server Cert Name

(Hope i got you correct)

If i try to it throws the message:

radsec-trusted-ca-cert-name is configured. Please unconfigure with "no radsec-trusted-ca-cert-name" and then configure "radsec-trusted-server-cert-name"

If i configure:

- the CAs Certificate (uploaded as Trusted CA) friendly name as Radsec Trusted CA Name

OR

- the Radsec proxys certificate (uploaded as public cert)  friendliy name as Radsec Server Cert

AND

- controllers certifcate(Uploaded as Server cert) fiendly name as Radius Client Cert

...it accepts my configuration - but does not work. :-( 

I got this explaniation from SE:

• For the controller to authenticate the Radsec Server, there are two options:

=> If Radsec server uses a certificate signed by a CA, then the CA certificate should be uploaded as a "Trusted CA".

=> If Radsec server uses a self-signed certificate, then that certificate should be uploaded as a "PublicCert"

     on the controller.

• The controller also needs to send  a TLS client certificate to the Radsec server. For this there are two options.

=> Upload a certificate on the controller as "ServerCert" and configure Radsec to use it.  Also, the necessary configuration must be made on the Radsec server so that it accepts the controller's certificate.

Note: The term "ServerCert"  is used here as traditionally Aruba controllers act as TLS servers (for webUI access   for example). It is actually used as a TLS client certificate by the controller in this case.

Hi Kevin,

Do you still facing the issue? then please copy the output of radsec server profile..

# show aaa authentication-server radius radsecproxy.domain.lab

Thanks,

Vijay

Great..config looks fine. Now we want to check the certificates.

I need the following logs.

1. Enable #logging level debugging security process authmgr.

    Start capture packets on radsecproxy ..

    Example: tcpdump -i <interfacename> host <controller-ip> -s 1518 -w radsec.pcap

    Disable and enable the radsec as follows

    #aaa authentication-server radius radsec.nwag.lab

    #no enable-radsec

    #enable-radsec

2. send the radsec.pcap file and output of show log security 30

Thanks,

Vijay

Hi Vijay,

thanks for following up - i'm going to collect the data next week.

best regards

Kevin

I'm sorry for the delay in getting back. The dev guys found that this was an radsecproxy issue:

Radsecproxy is trying to negotiate TLS 1.0 which is not supported by Aruba Radsec as per RFC.

RFC Link:
https://tools.ietf.org/html/draft-ietf-radext-radsec-12

"Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2
[RFC5246] ]) is REQUIRED. To prevent known attacks on TLS
versions prior to 1.1, implementations MUST NOT negotiate TLS
versions prior to 1.1."

There are two ways to solve that issue:

Either the way that was recommended by the aruba dev team as follows:

So they have requested to follow the below procedure in order to negotiate TLS 1.2 by Radsecproxy.

1) Edit the file /root/radsecproxy-1.6.6/tlscommon.c and put TLSv1_1_method() instead TLSv1_method();

#ifdef RADPROT_TLS
case RAD_TLS:
ctx = SSL_CTX_new(TLSv1_1_method());

2) Re-compile the code using the make and make install again.
3) Copy the certificates and key files
4) Start the radsecproxy server.

...or by updating radsecproxy to version 1.6.7 which adresses this issue:

https://project.nordu.net/browse/RADSECPROXY-62