rfc6929 radius ext - nested tlv format question

[Vereecke, Katrien (Katrien)]

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 at 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 at 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