Expansion of acct-unique-session-id query

classic Classic list List threaded Threaded
4 messages Options
| Threaded
Open this post in threaded view
|

Expansion of acct-unique-session-id query

Users mailing list
Hi all,
  Me again ☺
I’m having an issue with the creation of the Acct-Unique-Session-Id control attribute in v4. In v3, the policy did something like the following :

(545)       else {
(545)         update request {
(545)           EXPAND %{md5:%{User-Name},%{Acct-Session-ID},%{NAS-IP-Address},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}
(545)           --> 0a28ca134cc4f141e97cacdf91f7551f
(545)           Acct-Unique-Session-Id := "0a28ca134cc4f141e97cacdf91f7551f"

If I do something like :

echo -n "00c0b7869f20,001E00000002,192.168.105.142,IT-2530-2,,5" | md5sum
I get the same md5 hash, good:

0a28ca134cc4f141e97cacdf91f7551f  -

In v4, (I’ve altered the attributes used in the calculation to match the v3 calculation, to try and demonstrate the issue). The output should in theory be the same?
I get:

(0)      else {
(0)        update request {
(0)          EXPAND %{User-Name}
(0)            --> 00c0b7869f20
(0)          EXPAND %{Acct-Session-ID}
(0)            --> 001E00000002
(0)          EXPAND %{NAS-IP-Address}
(0)            --> 192.168.105.142
(0)          EXPAND %{NAS-Identifier}
(0)            --> IT-2530-2
(0)          EXPAND %{NAS-Port-ID}
(0)            --> ,
(0)          EXPAND %{NAS-Port}
(0)            --> 5
(0)          EXPAND %{md5:%{User-Name},%{Acct-Session-ID},%{NAS-IP-Address},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}
(0)                (%{md5:00c0b7869f20,001E00000002,192.168.105.142,IT-2530-2,,5})
(0)            --> 0xa5850401f8c9f7ffdd43a04100ca8190
(0)          &Acct-Unique-Session-Id := "\245\205\004\001\370\311\367\377\335C\240A\000ʁ\220"

Everything expands ok, and it says it’s doing an md5 on the correct resulting “string”, but the output looks pretty odd. Should the md5 come out in hex format? I guess it’s maybe that part at fault, instead of the hex->string conversion?
Thanks
Andy


********************************************************************************************************************

This message may contain confidential information. If you are not the intended recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take any action in relation to its contents. To do so is strictly prohibited and may be unlawful. Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff in England and Scotland. NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and other accredited email services.

For more information and to find out how you can switch, https://portal.nhs.net/help/joiningnhsmail

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Expansion of acct-unique-session-id query

Alan DeKok-2
On Jul 23, 2020, at 6:03 AM, FRANKS, Andy (SHREWSBURY AND TELFORD HOSPITAL NHS TRUST) via Freeradius-Users <[hidden email]> wrote:

> I’m having an issue with the creation of the Acct-Unique-Session-Id control attribute in v4. In v3, the policy did something like the following :
>
> (545)       else {
> (545)         update request {
> (545)           EXPAND %{md5:%{User-Name},%{Acct-Session-ID},%{NAS-IP-Address},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}
> (545)           --> 0a28ca134cc4f141e97cacdf91f7551f
> (545)           Acct-Unique-Session-Id := "0a28ca134cc4f141e97cacdf91f7551f"
>
> If I do something like :
>
> echo -n "00c0b7869f20,001E00000002,192.168.105.142,IT-2530-2,,5" | md5sum
> I get the same md5 hash, good:
>
> 0a28ca134cc4f141e97cacdf91f7551f  -

  That works in v4, too:

        update reply {
               &Filter-Id := "%{md5:00c0b7869f20,001E00000002,192.168.105.142,IT-2530-2,,5}"
        }

  You get 0a28ca134cc4f141e97cacdf91f7551f

> In v4, (I’ve altered the attributes used in the calculation to match the v3 calculation, to try and demonstrate the issue). The output should in theory be the same?
> I get:
>
> (0)      else {
> (0)        update request {
> (0)          EXPAND %{User-Name}
> (0)            --> 00c0b7869f20
> (0)          EXPAND %{Acct-Session-ID}
> (0)            --> 001E00000002
> (0)          EXPAND %{NAS-IP-Address}
> (0)            --> 192.168.105.142
> (0)          EXPAND %{NAS-Identifier}
> (0)            --> IT-2530-2
> (0)          EXPAND %{NAS-Port-ID}
> (0)            --> ,
> (0)          EXPAND %{NAS-Port}
> (0)            --> 5
> (0)          EXPAND %{md5:%{User-Name},%{Acct-Session-ID},%{NAS-IP-Address},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}
> (0)                (%{md5:00c0b7869f20,001E00000002,192.168.105.142,IT-2530-2,,5})
> (0)            --> 0xa5850401f8c9f7ffdd43a04100ca8190
> (0)          &Acct-Unique-Session-Id := "\245\205\004\001\370\311\367\377\335C\240A\000ʁ\220"
>
> Everything expands ok, and it says it’s doing an md5 on the correct resulting “string”, but the output looks pretty odd. Should the md5 come out in hex format? I guess it’s maybe that part at fault, instead of the hex->string conversion?

  There are a few differences here.  The expansions in v4 are now "binary safe".  In v3, every expansion printed data to a string, or parsed data from a string.  In v4, the data is passed "as-is" until the final conversion to string, IP, etc.

  This change means that there is less work done to print / parse data.  It also means that the MD5 above is operating on the *binary* data.  i.e. for the IP address, it's operating on the 4-byte value 0xc0a8..., and not on "192.168.105.142'.

  You can fix this (and see this for yourself) by doing:

        update reply {
                &Filter-Id := "%{md5:00c0b7869f20,001E00000002,192.168.105.142,IT-2530-2,,5}"
                &Filter-Id += "%{md5:%{User-Name},%{Acct-Session-ID},%{NAS-IP-Address},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}"
                &Filter-Id += "%{md5:%{string:%{User-Name},%{Acct-Session-ID},%{NAS-IP-Address},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}}"
        }

  The last line takes the input expansions, and converts them all to printable strings.  The MD5 is then done on that printable string.  The output is then:

(1)    Filter-Id = "\n(\312\023L\304\361A\351|\254ߑ\367U\037"
(1)    Filter-Id = "\245\205\004\001\370\311\367\377\335C\240A\000ʁ\220"
(1)    Filter-Id = "\n(\312\023L\304\361A\351|\254ߑ\367U\037"

  So the first and last line are now identical.  They're still binary blobs, but they're identical.

  In order to convert them to hex, you should wrap the MD5 output with a "hex" expansion:

                &Filter-Id += "%{hex:%{md5:%{string:%{Reply-Message},%{Acct-Session-ID},%{NAS-IP-Address},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}}}"

  Which then gets you:

(1)    Filter-Id = "0a28ca134cc4f141e97cacdf91f7551f"

  This is a little involved.  But all of the changes needed to be done for a host of reasons.

  I'll see if we can update the default Acct-Unique-Session-Id calculation with some comments about this subject.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

RE: Expansion of acct-unique-session-id query

Users mailing list
Ah, thanks Alan that all makes sense, I'm certainly learning a fair bit here! Apologies for my various mistakes as I convert over :-)
Kind Regards
Andy.

-----Original Message-----
From: Freeradius-Users <freeradius-users-bounces+andy.franks1=[hidden email]> On Behalf Of Alan DeKok
Sent: 23 July 2020 14:45
To: FreeRadius users mailing list <[hidden email]>
Subject: Re: Expansion of acct-unique-session-id query

On Jul 23, 2020, at 6:03 AM, FRANKS, Andy (SHREWSBURY AND TELFORD HOSPITAL NHS TRUST) via Freeradius-Users <[hidden email]> wrote:

> I’m having an issue with the creation of the Acct-Unique-Session-Id control attribute in v4. In v3, the policy did something like the following :
>
> (545)       else {
> (545)         update request {
> (545)           EXPAND %{md5:%{User-Name},%{Acct-Session-ID},%{NAS-IP-Address},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}
> (545)           --> 0a28ca134cc4f141e97cacdf91f7551f
> (545)           Acct-Unique-Session-Id := "0a28ca134cc4f141e97cacdf91f7551f"
>
> If I do something like :
>
> echo -n "00c0b7869f20,001E00000002,192.168.105.142,IT-2530-2,,5" |
> md5sum I get the same md5 hash, good:
>
> 0a28ca134cc4f141e97cacdf91f7551f  -

  That works in v4, too:

update reply {
       &Filter-Id := "%{md5:00c0b7869f20,001E00000002,192.168.105.142,IT-2530-2,,5}"
}

  You get 0a28ca134cc4f141e97cacdf91f7551f

> In v4, (I’ve altered the attributes used in the calculation to match the v3 calculation, to try and demonstrate the issue). The output should in theory be the same?
> I get:
>
> (0)      else {
> (0)        update request {
> (0)          EXPAND %{User-Name}
> (0)            --> 00c0b7869f20
> (0)          EXPAND %{Acct-Session-ID}
> (0)            --> 001E00000002
> (0)          EXPAND %{NAS-IP-Address}
> (0)            --> 192.168.105.142
> (0)          EXPAND %{NAS-Identifier}
> (0)            --> IT-2530-2
> (0)          EXPAND %{NAS-Port-ID}
> (0)            --> ,
> (0)          EXPAND %{NAS-Port}
> (0)            --> 5
> (0)          EXPAND %{md5:%{User-Name},%{Acct-Session-ID},%{NAS-IP-Address},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}
> (0)                (%{md5:00c0b7869f20,001E00000002,192.168.105.142,IT-2530-2,,5})
> (0)            --> 0xa5850401f8c9f7ffdd43a04100ca8190
> (0)          &Acct-Unique-Session-Id := "\245\205\004\001\370\311\367\377\335C\240A\000ʁ\220"
>
> Everything expands ok, and it says it’s doing an md5 on the correct resulting “string”, but the output looks pretty odd. Should the md5 come out in hex format? I guess it’s maybe that part at fault, instead of the hex->string conversion?

  There are a few differences here.  The expansions in v4 are now "binary safe".  In v3, every expansion printed data to a string, or parsed data from a string.  In v4, the data is passed "as-is" until the final conversion to string, IP, etc.

  This change means that there is less work done to print / parse data.  It also means that the MD5 above is operating on the *binary* data.  i.e. for the IP address, it's operating on the 4-byte value 0xc0a8..., and not on "192.168.105.142'.

  You can fix this (and see this for yourself) by doing:

update reply {
&Filter-Id := "%{md5:00c0b7869f20,001E00000002,192.168.105.142,IT-2530-2,,5}"
&Filter-Id += "%{md5:%{User-Name},%{Acct-Session-ID},%{NAS-IP-Address},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}"
&Filter-Id += "%{md5:%{string:%{User-Name},%{Acct-Session-ID},%{NAS-IP-Address},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}}"
}

  The last line takes the input expansions, and converts them all to printable strings.  The MD5 is then done on that printable string.  The output is then:

(1)    Filter-Id = "\n(\312\023L\304\361A\351|\254ߑ\367U\037"
(1)    Filter-Id = "\245\205\004\001\370\311\367\377\335C\240A\000ʁ\220"
(1)    Filter-Id = "\n(\312\023L\304\361A\351|\254ߑ\367U\037"

  So the first and last line are now identical.  They're still binary blobs, but they're identical.

  In order to convert them to hex, you should wrap the MD5 output with a "hex" expansion:

&Filter-Id += "%{hex:%{md5:%{string:%{Reply-Message},%{Acct-Session-ID},%{NAS-IP-Address},%{NAS-Identifier},%{NAS-Port-ID},%{NAS-Port}}}}"

  Which then gets you:

(1)    Filter-Id = "0a28ca134cc4f141e97cacdf91f7551f"

  This is a little involved.  But all of the changes needed to be done for a host of reasons.

  I'll see if we can update the default Acct-Unique-Session-Id calculation with some comments about this subject.

  Alan DeKok.


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


********************************************************************************************************************

This message may contain confidential information. If you are not the intended recipient please inform the
sender that you have received the message in error before deleting it.
Please do not disclose, copy or distribute information in this e-mail or take any action in relation to its contents. To do so is strictly prohibited and may be unlawful. Thank you for your co-operation.

NHSmail is the secure email and directory service available for all NHS staff in England and Scotland. NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and other accredited email services.

For more information and to find out how you can switch, https://portal.nhs.net/help/joiningnhsmail


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: Expansion of acct-unique-session-id query

Alan DeKok-2


> On Jul 23, 2020, at 9:53 AM, FRANKS, Andy (SHREWSBURY AND TELFORD HOSPITAL NHS TRUST) via Freeradius-Users <[hidden email]> wrote:
>
> Ah, thanks Alan that all makes sense, I'm certainly learning a fair bit here! Apologies for my various mistakes as I convert over :-)

  Mostly you've found mistakes on our end.  :(

  I've pushed fixes for Acct-Unique-Session-Id so that it does the same thing was v3 by default.  That will avoid surprises for people when they upgrade.

  Alan DeKok.


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