NAS-Filter-Rule incorrectly encoded as string

[Pablo Nogueira]

Hello,
first post here.
I'm trying to implement dynamic access lists for 802.1X authenticated
users. To do so, I'm using attribute NAS-Filter-Rule, as defined in
RFC 4849 and FreeRADIUS Version 3.0.21 as the RADIUS server.

To do so, I've modified users file with the following entry
user1      Cleartext-Password := "pass1"
               Service-Type = Framed-User,
               Nas-filter-Rule = "permit in tcp from any to 10.2.3.4/24",
               Nas-filter-Rule += 0x00,
               Nas-filter-Rule += "permit in ip from 192.168.101.5/32
to 192.168.101.1",
               Nas-filter-Rule += 0x00,
               Nas-filter-Rule += "deny in ip from any to any",
               Nas-filter-Rule += 0x00

According to RFC 4849
"The String field is one or more octets.  It contains filter rules
      in the IPFilterRule syntax defined in [RFC3588], Section 4.3, with
      individual filter rules separated by a NUL (0x00).  A NAS-Filter-
      Rule attribute may contain a partial rule, one rule, or more than
      one rule.  Filter rules may be continued across attribute
      boundaries, so implementations cannot assume that individual
      filter rules begin or end on attribute boundaries.

      The set of NAS-Filter-Rule attributes SHOULD be created by
      concatenating the individual filter rules, separated by a NUL
      (0x00) octet.  The resulting data should be split on 253-octet
      boundaries to obtain a set of NAS-Filter-Rule attributes.  On
      reception, the individual filter rules are determined by
      concatenating the contents of all NAS-Filter-Rule attributes, and
      then splitting individual filter rules with the NUL octet (0x00)
      as a delimiter.
"

In my example above, RADIUS server is sending NAS-Filter-Rule as a
string, thus converting 0x00 into strings "0x00".
If I remove the 0x00, then rules are not NUL separated which goes
against the RFC,

share/dictionary/radius/dictionary.rfc4849 defines NAS-Filter-Rule as
ATTRIBUTE    NAS-Filter-Rule                92    string

I've been able to make it work as I think it should adding the
following line to my dictionary
# override NAS-Filter-Rule to convey NUL character between rules
ATTRIBUTE       NAS-Filter-Rule                         92      octets

My question is, is there any other way to force freeradius to send the
entry rules as strings with NUL terminated character? Should I report
this as an issue (bug) to freeradius developers so that they change
the dictionary.rfc4849 entry?

I hope my question is clear. Best regards
Pablo
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan DeKok-2]

On Feb 16, 2021, at 6:23 AM, Pablo Nogueira <[hidden email]> wrote:

> I'm trying to implement dynamic access lists for 802.1X authenticated
> users. To do so, I'm using attribute NAS-Filter-Rule, as defined in
> RFC 4849 and FreeRADIUS Version 3.0.21 as the RADIUS server.
>
> To do so, I've modified users file with the following entry
> user1      Cleartext-Password := "pass1"
>               Service-Type = Framed-User,
>               Nas-filter-Rule = "permit in tcp from any to 10.2.3.4/24",
>               Nas-filter-Rule += 0x00,
>               Nas-filter-Rule += "permit in ip from 192.168.101.5/32
> to 192.168.101.1",
>               Nas-filter-Rule += 0x00,
>               Nas-filter-Rule += "deny in ip from any to any",
>               Nas-filter-Rule += 0x00

  That really won't do what you want.

  The "+=" operator adds multiple attributes of the same name.  It doesn't concatenate strings for the same attribute.  See "man unlang".

  Further, adding "0x00" to a "string" attribute doesn't add a zero byte.  It appends the literal string "0x00".

> I've been able to make it work as I think it should adding the
> following line to my dictionary
> # override NAS-Filter-Rule to convey NUL character between rules
> ATTRIBUTE       NAS-Filter-Rule                         92      octets

  That still doesn't quite do what the RFC says.  That change sends *multiple* NAS-Filter-Rule attributes, some with string values, and some with a 0x00 byte.  It doesn't follow the RFC guidelines of packing all of the strings together.

  If it works... it's OK for now.  But it's not really the correct approach.

> My question is, is there any other way to force freeradius to send the
> entry rules as strings with NUL terminated character? Should I report
> this as an issue (bug) to freeradius developers so that they change
> the dictionary.rfc4849 entry?

  The developers read this list.  Don't worry about that.

  Changing the data type sort of works.  But it means that when the server is receiving proxied Access-Accept packets, it won't print out the NAS-Filter-Rule correctly.

  For now, your changes work for you.  We'll see if we can get some fixes into the next release.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan DeKok-2]

  FYI I've pushed changes to v3 which will automatically do this for 3.0.22 (when that's released)

https://github.com/FreeRADIUS/freeradius-server/commit/310083864657543a8968f10beff90e971fc2fb4d

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Pablo Nogueira]

Hi Alan,
that is absolutely awesome!!
I've checked your commits (three if I'm not mistaken) and going
through your code I realized that I was incorrectly assuming that
there had to be a \0 after the last NAS-Filter-Rule entry.
So thank you very much for the fast response, patch provided and
correct interpretation of the RFC.
Best regards
Pablo



On Tue, Feb 16, 2021 at 4:17 PM Alan DeKok <[hidden email]> wrote:

>
>   FYI I've pushed changes to v3 which will automatically do this for 3.0.22 (when that's released)
>
> https://github.com/FreeRADIUS/freeradius-server/commit/310083864657543a8968f10beff90e971fc2fb4d
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html