Project

General

Profile

Actions

Bug #5652

open

Radius IETF Class Group Assignment - Incorrect Standard

Added by Jay Shepherd over 8 years ago. Updated over 4 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Authentication
Target version:
-
Start date:
12/17/2015
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2.5
Affected Architecture:

Description

When trying to use the Radius IETF Class(25) attribute to assign pfsense groups for webui administration several industry standard policy servers such as Cisco ISE, Aruba Clearpass, and Windows NPS will convert the string to an octect in accordance with RFC 2865 https://tools.ietf.org/html/rfc2865#section-5.25

Therefore admins becomes 0x61646d696e73

In some implementations of Radius, such as Windows NPS this can be modified to send as string resolving the issue. However in other implementations such as Aruba Clearpass and Cisco ISE the Radius Dictionary is fixed to the vendor ID code (0 for IETF) and modifying the behavior is a global action. Therefore it would break devices who use the Class attribute according to the RFC.

An alternative to a straight bug fix may be one of the following:

1) PFsense could allow the user to specify radius attribute mapping. Citrix takes this approach but it tends to confuse users new to Radius.
2) PFsense could implement group assignment via a more traditional Cisco-AV:Pair mapping. Vendor ID 9 attribute 1.

Actions #1

Updated by Jim Pingle over 8 years ago

FYI- FreeRADIUS sends it back as text and is extremely difficult to change, which is why we use text. It may be possible for it to be an option, would need to be investigated further however.

Actions #2

Updated by Phillip Hernandez over 7 years ago

I disagree with using Cisco-AV:Pair and believe that using Filter-Id is a better option.

Thanks

Actions #3

Updated by Jay Shepherd over 7 years ago

Phillip Hernandez wrote:

I disagree with using Cisco-AV:Pair and believe that using Filter-Id is a better option.

Any particular reason against using Cisco-AV:Pair? It's widely implemented by a lot of vendors both on the Radius Server side and on the client side.

I'm against using Filter-ID as it has the same problem the class attribute has in that the string must be represented as series of octets instead of plain text. Given that the first comment by Jim indicates FreeRADIUS does not correctly transpose to octets for the Class(25) attribute I'm uncertain if it would for Filter-ID.

Actions #4

Updated by Jim Pingle over 4 years ago

  • Category set to Authentication
Actions

Also available in: Atom PDF