Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ambiguous Client validation #2840

Open
mark-grayson opened this issue Aug 2, 2019 · 4 comments

Comments

@mark-grayson
Copy link

commented Aug 2, 2019

Issue type

  • Defect - Unexpected behaviour (obvious or verified by project member).

Defect

In FreeRADIUS, version 3.0.18, with unlang used to verify client OID expansions via listen:TLS-Client-Cert-Subject-Alt-Name-Dns, if a RADIUS client makes a request, the value of the SAN object is null ("") which creates an ambiguous validation rule. Unlang must be able to distinguish RADSEC access-requests with a TLS listener from standard RADIUS client requests with no TLS listener.

Background

This issue is being raised on behalf of Wireless Broadband Alliance.
WBA is currently evolving its WRIX RADIUS Roaming system to enable support of RADSEC.
RADSEC testing has been performed by multiple WBA members, including:
Accuris Networks, BSG Wireless, Cablelabs, Cisco and iPass/Pareteum

@arr2036

This comment has been minimized.

Copy link
Member

commented Aug 2, 2019

Worst case you could just bind the TLS listener to a different virtual server and use common policies between a virtual server with a UDP listener and a virtual server with a TLS listener.

@alandekok

This comment has been minimized.

Copy link
Member

commented Aug 2, 2019

In FreeRADIUS, version 3.0.18, with unlang used to verify client OID expansions via listen:TLS-Client-Cert-Subject-Alt-Name-Dns, if a RADIUS client makes a request, the value of the SAN object is null ("")

What does that man? If the SAN OID exists, it's added to the listener, and is available via that expansion.

Do you have debugging output which shows the problem?

@restena-sw

This comment has been minimized.

Copy link

commented Aug 5, 2019

I've been staring at the report for a few minutes now. Did you maybe mean...

"if a RADIUS UDP client makes a request, the value of the SAN object is null ("") " ?

Which would then be both true and trivial.

If you want an expression which contains a value both for UDP and for TLS clients, then that's possible with a fallback substitution in unlang:

'%{%{TLS-Client-Cert-Subject-At-Name-Dns}:-"UDP Client - no name"}'

?

Stefan

@alandekok

This comment has been minimized.

Copy link
Member

commented Aug 5, 2019

Reading between the lines, I think Stefan is correct. But a clear description of the use-case would help.

I've updated v3 to add:

  • %{listen:tls} which returns yes for TLS connections, and no for normal connections
  • %{proxy_listen:...}which does the same thing as%{listen:...}`, but for outgoing packets.

So you can now do:

if ("%{listen:tls}" == "yes") {
    # it's a TLS connection

    if ("%{listen:TLS-Client-Cert-Subject-Alt-Name-Dns}" == "client.example.com") {
         # client has that DNS
    }
}

I think this is what you're asking for. But it's difficult to tell, because the description of the problem isn't clear.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.