1dictionary(5)                 File Formats Manual                dictionary(5)
2
3
4

NAME

6       dictionary - RADIUS dictionary file
7

DESCRIPTION

9       The master RADIUS dictionary file resides in /etc/raddb/dictionary.  It
10       references other dictionary files  located  in  /usr/share/freeradius/.
11       Each  dictionary  file contains a list of RADIUS attributes and values,
12       which the server uses to map between descriptive names and  on-the-wire
13       data.   The  names have no meaning outside of the RADIUS server itself,
14       and are never exchanged between server and clients.
15
16       That is, editing the dictionaries will have NO EFFECT on anything other
17       than  the server that is reading those files.  Adding new attributes to
18       the dictionaries will have NO EFFECT on RADIUS clients,  and  will  not
19       make RADIUS clients magically understand those attributes.  The dictio‐
20       naries are solely for local administrator convenience, and are specific
21       to each version of FreeRADIUS.
22
23       The  dictionaries  in  /usr/share  SHOULD NOT be edited unless you know
24       exactly what you are doing.  Changing them will most likely break  your
25       RADIUS deployment.
26
27       If  you  need to add new attributes, please edit the /etc/raddb/dictio‐
28       nary file.  It's sole purpose is to contain site-local defintions  that
29       are added by the local administrator.
30
31

FORMAT

33       Every  line  starting  with a hash sign ('#') is treated as comment and
34       ignored.
35
36       Each line of the file can contain one of the following strings:
37
38       ATTRIBUTE name oid type [flags]
39            Define a RADIUS attribute name to number mapping.
40
41            The name field is a printable field, taken from various specifica‐
42            tions or vendor definitions.  It is most commonly used as a series
43            of words, separated by hyphens.   e.g.  "User-Name".   Vendor-spe‐
44            cific  attributes  (VSAs)  are  prefixed  by the vendor name, e.g.
45            "Cisco-AVPair".  The names should be globally unique, as they  are
46            used as a key to look up the properties of the attribute.
47
48            The  oid  field  is taken from the relevant specification for that
49            name.  In most cases, it is a decimal number, such as "256".   For
50            certain  attributes,  a  "dotted  number"  notation  is used, e.g.
51            "1.2".  The "dotted number" notation  is  used  only  for  certain
52            attributes.
53
54            The type field can be one of the standard types:
55
56                 string       UTF-8 printable text (the RFCs call this "text")
57                 octets       opaque binary data (the RFCs call this "string")
58                 ipaddr       IPv4 address
59                 date         Seconds since January 1, 1970 (32-bits)
60                 integer      32-bit unsigned integer
61                 ipv6addr     IPv6 Address
62                 ipv6prefix   IPV6 prefix, with mask
63                 ifid         Interface Id (hex:hex:hex:hex)
64                 integer64   64-bit unsigned integer
65
66            The type field can be one of the following non-standard types:
67
68                 ether        Ethernet MAC address
69                 abinary      Ascend binary filter format
70                 byte         8-bit unsigned integer
71                 short        16-bit unsigned integer
72                 signed       31-bit signed integer (packed into 32-bit field)
73                 tlv          Type-Length-Value (allows nested attributes)
74                 ipv4prefix   IPv4 Prefix as given in RFC 6572.
75
76            The  last  (optional)  field  of an attribute definition are addi‐
77            tional flags for that attribute, in a comma-separated list.   Pre‐
78            vious versions of the server allowed these flags to include a ven‐
79            dor name.  This behavior may still work, but it is deprecated, and
80            is not recommended.
81
82            The options are:
83
84                 encrypt=#    set encryption type 1, 2, or 3.
85                 has_tag      The attribute can have an RFC 2868 style tag
86
87            The "encrypt" flag marks the attribute as being encrypted with one
88            of three possible  methods.   "1"  means  that  the  attribute  is
89            encrypted with the method as defined in RFC2865 for the User-Pass‐
90            word attribute.  "2" means that the password is encrypted with the
91            method  as  defined  in RFC2868 for the Tunnel-Password attribute.
92            "3" means that the attribute is encrypted as per Ascend's  defini‐
93            tions for the Ascend-Send-Secret attribute.
94
95            The  "has_tag" flag marks the attribute as being permitted to have
96            a tag, as defined in RFC2868.  The purpose of the tag is to  allow
97            grouping  of  attributes for tunneled users.  See RFC2868 for more
98            details.
99
100            When the server receives an encoded attribute in a RADIUS  packet,
101            it  looks  up that attribute by number in the dictionary, and uses
102            the definition found there for printing diagnostic  and  log  mes‐
103            sages.   When the server sees an attribute name in a configuration
104            file, it looks up that attribute by name in  the  dictionary,  and
105            uses the definition found there.
106
107
108       VALUE attribute-name value-name number
109            Define an attribute value name to number mapping, for an attribute
110            of type integer.  The  attribute-name  field  MUST  be  previously
111            defined  by  an  ATTRIBUTE entry.  The value-name field can be any
112            non-space text, but is usually taken from RFC2865, or other  docu‐
113            ments..   The  number  field is also taken from the relevant docu‐
114            ments, for that name.
115
116            When the server receives an encoded value in a RADIUS  packet,  it
117            looks  up the value of that attribute by number in the dictionary,
118            and uses the name found there for printing diagnostic and log mes‐
119            sages.
120
121       VENDOR vendor-name number [format=...]
122            Define  a  Vendor Specific Attribute encapsulation for vendor-name
123            to  number.   For  a  list  of  vendor  names  and  numbers,   see
124            http://www.iana.org/enterprise-numbers.txt.
125
126            The "format=t,l" statement tells the server how many octets to use
127            to encode/decode the vendor "type"  and  "length"  fields  in  the
128            attributes.   The  default is "format=1,1", which does not have to
129            be specified.  For USR VSA's,  the  format  is  "format=4,0",  for
130            Lucent  VSA's  it's "format=2,1", and for Starent VSA's it's "for‐
131            mat=2,2".
132
133            The supported values for the number of type octets (i.e. the first
134            digit)  are  1,  2,  and  4.  The support values for the number of
135            length octets (i.e. the second digit) are 0, 1, and 2.  Any combi‐
136            nation of those values will work.
137
138
139       BEGIN-VENDOR vendor-name
140            Define the start of a block of Vendor-Specific attributes.  All of
141            the following ATTRIBUTE  definitions are interpreted as being  for
142            the  named  vendor,  until  the block is closed by an "END-VENDOR"
143            statement.
144
145            This practice is preferred to placing the vendor name at  the  end
146            of an ATTRIBUTE  definition.
147
148            For  VSAs in the RFC 6929 "Extended vendor-specific" space, a for‐
149            mat can be specified  following  the  "vendor-name".   The  format
150            should   be   "format=Extended-Vendor-Specific-1",  through  "for‐
151            mat=Extended-Vendor-Specific-6".  The matching "END-VENDOR" should
152            just have the "vendor-name", without the format string.
153
154       END-VENDOR vendor-name
155            End  a  previously  defined BEGIN-VENDOR block.  The "vendor-name"
156            must match.
157
158       $INCLUDE filename
159            Include dictionary entries from the file filename.   The  filename
160            is  taken  as relative to the location of the file which is asking
161            for the inclusion.
162
163       BEGIN-TLV name
164            This feature is supported for backwards compatibility  with  older
165            dictionaries.   It  should  not  be  used.  The new "oid" form for
166            defining the attribute number should be used instead.
167
168       END-TLV name
169            This feature is supported for backwards compatibility  with  older
170            dictionaries.   It  should  not  be  used.  The new "oid" form for
171            defining the attribute number should be used instead.
172

FILES

174       /etc/raddb/dictionary, /usr/share/freeradius/dictionary.*
175

SEE ALSO

177       radiusd(8), RFC2865, RFC2866, RFC2868 RFC6929
178
179
180
181                                  12 Jun 2015                    dictionary(5)
Impressum