rfc6929 radius ext - nested tlv format question
Hello, I have a question regarding the nesting of radius attributes according to rfc6929. I am using the freeradius-server version V3.0.x and I defined as test the following in my dictionary : ATTRIBUTE Test-Attr-50 241.50 tlv ATTRIBUTE Test-Attr-50_1 241.50.1 octets ATTRIBUTE Test-Attr-50_1_2 241.50.1.2 string And in the users file : Test-Attr-50_1 = 0x112233, Test-Attr-50_1_2 = "testString50", These attributes are sent in the access-accept: (156) Sent Access-Accept Id 247 from 138.203.10.191:1812 to 138.203.10.123:64395 length 0 (156) Test-Attr-50_1 = 0x112233 (156) Test-Attr-50_1_2 = "testString50" I expected that this would give problems because the attribute 241.50.1 is not defined as tlv in the dictionary, but the wireshark shows that the attribute includes both the octets for Test-Attr-50_1 and the nested attribute Test-Attr-50_1_2 . Is the above a valid configuration? When decoding this attribute, how can one distinguish whether 241.50.1 contains real data or again a nested attribute 241.50.1.2? f1 18 32 01 05 11 22 33 01 10 02 0e 74 65 73 74 53 74 72 69 6e 67 35 30 Thanks, Kind regards, Katrien.
On Sep 24, 2015, at 4:47 PM, Vereecke, Katrien (Katrien) <katrien.vereecke@alcatel-lucent.com> wrote:
Hello,
I have a question regarding the nesting of radius attributes according to rfc6929.
I am using the freeradius-server version V3.0.x and I defined as test the following in my dictionary : ATTRIBUTE Test-Attr-50 241.50 tlv ATTRIBUTE Test-Attr-50_1 241.50.1 octets ATTRIBUTE Test-Attr-50_1_2 241.50.1.2 string
That dictionary is wrong. The last attribute is a sub-TLV, but the parent isn't of type tlv. I've pushed a fix which causes the server to reject that dictionary, and refuse to start.
These attributes are sent in the access-accept: (156) Sent Access-Accept Id 247 from 138.203.10.191:1812 to 138.203.10.123:64395 length 0 (156) Test-Attr-50_1 = 0x112233 (156) Test-Attr-50_1_2 = "testString50"
I expected that this would give problems because the attribute 241.50.1 is not defined as tlv in the dictionary, but the wireshark shows that the attribute includes both the octets for Test-Attr-50_1 and the nested attribute Test-Attr-50_1_2 . Is the above a valid configuration? When decoding this attribute, how can one distinguish whether 241.50.1 contains real data or again a nested attribute 241.50.1.2?
You can't. The dictionary is wrong, so the attributes are wrong, so the encoder does the wrong thing. The encoder assumes that each VALUE_PAIR contains enough information to encode the VP. If the data in the VP is wrong, the encoder will encode the data according to the wrong definition. Fixing the parser means that the dictionary is rejected, and the wrong VALUE_PAIR isn't create, and the encoder will then only encode the correct thing. Alan DeKok.
Hello Alan, I took in your fix , but I am now getting errors on the defined vendor specific attributes which are not of tlv type? Copyright (C) 1999-2015 The FreeRADIUS server project and contributors There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License For more information about these matters, see the file named COPYRIGHT Starting - reading configuration files ... including dictionary file /usr/local/share/freeradius/dictionary Errors reading dictionary: dict_init: /usr/local/share/freeradius/dictionary.alcatel.sr.ext[56]: dict_addattr: ATTRIBUTE refers to unknown parent attribute VENDOR Alcatel-IPD-Ext 6527 BEGIN-VENDOR Alcatel-IPD-Ext format=Extended-Vendor-Specific-1 ATTRIBUTE Alcatel-IPD-Ext-1-TestAttr-1 1 integer ==> this is line 56 where I am getting an error on. ATTRIBUTE Alcatel-IPD-Ext-1-TestAttr-2 2 string ATTRIBUTE Alcatel-IPD-Ext-1-TestAttr-3 3 integer64 END-VENDOR Alcatel-IPD-Ext Thanks, Kind regards, Katrien. -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+katrien.vereecke=alcatel-lucent.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Friday, September 25, 2015 03:31 To: FreeRadius users mailing list Subject: Re: rfc6929 radius ext - nested tlv format question On Sep 24, 2015, at 4:47 PM, Vereecke, Katrien (Katrien) <katrien.vereecke@alcatel-lucent.com> wrote:
Hello,
I have a question regarding the nesting of radius attributes according to rfc6929.
I am using the freeradius-server version V3.0.x and I defined as test the following in my dictionary : ATTRIBUTE Test-Attr-50 241.50 tlv ATTRIBUTE Test-Attr-50_1 241.50.1 octets ATTRIBUTE Test-Attr-50_1_2 241.50.1.2 string
That dictionary is wrong. The last attribute is a sub-TLV, but the parent isn't of type tlv. I've pushed a fix which causes the server to reject that dictionary, and refuse to start.
These attributes are sent in the access-accept: (156) Sent Access-Accept Id 247 from 138.203.10.191:1812 to 138.203.10.123:64395 length 0 (156) Test-Attr-50_1 = 0x112233 (156) Test-Attr-50_1_2 = "testString50"
I expected that this would give problems because the attribute 241.50.1 is not defined as tlv in the dictionary, but the wireshark shows that the attribute includes both the octets for Test-Attr-50_1 and the nested attribute Test-Attr-50_1_2 . Is the above a valid configuration? When decoding this attribute, how can one distinguish whether 241.50.1 contains real data or again a nested attribute 241.50.1.2?
You can't. The dictionary is wrong, so the attributes are wrong, so the encoder does the wrong thing. The encoder assumes that each VALUE_PAIR contains enough information to encode the VP. If the data in the VP is wrong, the encoder will encode the data according to the wrong definition. Fixing the parser means that the dictionary is rejected, and the wrong VALUE_PAIR isn't create, and the encoder will then only encode the correct thing. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (2)
-
Alan DeKok -
Vereecke, Katrien (Katrien)