Adding upstream version 3.2.3+dfsg.upstream/3.2.3+dfsg

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 185 insertions, 0 deletions

diff --git a/man/man5/dictionary.5 b/man/man5/dictionary.5
new file mode 100644
index 0000000..ec63309
--- /dev/null
+++ b/man/man5/dictionary.5
@@ -0,0 +1,185 @@
+.\"     # DS - begin display
+.de DS
+.RS
+.nf
+.sp
+..
+.\"     # DE - end display
+.de DE
+.fi
+.RE
+.sp
+..
+.TH dictionary 5 "12 Jun 2015"
+.SH NAME
+dictionary \- RADIUS dictionary file
+.SH DESCRIPTION
+The master RADIUS dictionary file resides in
+\fI/etc/raddb/dictionary\fP.  It references other \fIdictionary\fP
+files located in \fI/usr/local/share/freeradius/\fP.  Each dictionary
+file contains a list of RADIUS attributes and values, which the server
+uses to map between descriptive names and on-the-wire data.  The names
+have no meaning outside of the RADIUS server itself, and are never
+exchanged between server and clients.
+.PP
+That is, editing the dictionaries will have NO EFFECT on anything
+other than the server that is reading those files.  Adding new
+attributes to the dictionaries will have NO EFFECT on RADIUS clients,
+and will not make RADIUS clients magically understand those
+attributes.  The dictionaries are solely for local administrator
+convenience, and are specific to each version of FreeRADIUS.
+.PP
+The dictionaries in \fI/usr/local/share\fP SHOULD NOT be edited unless
+you know exactly what you are doing.  Changing them will most likely
+break your RADIUS deployment.
+.PP
+If you need to add new attributes, please edit the
+\fI/etc/raddb/dictionary\fP file.  It's sole purpose is to contain
+site-local definitions that are added by the local administrator.
+
+.SH FORMAT
+Every line starting with a hash sign
+.RB (' # ')
+is treated as comment and ignored.
+.PP
+Each line of the file can contain one of the following strings:
+.TP 0.5i
+.B ATTRIBUTE name  oid  type [flags]
+Define a RADIUS attribute name to number mapping.
+
+The \fIname\fP field is a printable field, taken from various
+specifications or vendor definitions.  It is most commonly used as a
+series of words, separated by hyphens.  e.g. "User-Name".
+Vendor-specific attributes (VSAs) are prefixed by the vendor name,
+e.g. "Cisco-AVPair".  The names should be globally unique, as they are
+used as a key to look up the properties of the attribute.
+
+The \fIoid\fP field is taken from the relevant specification for that
+name.  In most cases, it is a decimal number, such as "256".  For
+certain attributes, a "dotted number" notation is used, e.g. "1.2".
+The "dotted number" notation is used only for certain attributes.
+
+The \fItype\fP field can be one of the standard types:
+
+     string       UTF-8 printable text (the RFCs call this "text")
+     octets       opaque binary data (the RFCs call this "string")
+     ipaddr       IPv4 address
+     date         Seconds since January 1, 1970 (32-bits)
+     integer      32-bit unsigned integer
+     ipv6addr     IPv6 Address
+     ipv6prefix   IPV6 prefix, with mask
+     ifid         Interface Id (hex:hex:hex:hex)
+     integer64	  64-bit unsigned integer
+
+The \fItype\fP field can be one of the following non-standard types:
+
+     ether        Ethernet MAC address
+     abinary      Ascend binary filter format
+     byte         8-bit unsigned integer
+     short        16-bit unsigned integer
+     signed       31-bit signed integer (packed into 32-bit field)
+     tlv          Type-Length-Value (allows nested attributes)
+     ipv4prefix   IPv4 Prefix as given in RFC 6572.
+
+The last (optional) field of an attribute definition are additional
+flags for that attribute, in a comma-separated list.  Previous
+versions of the server allowed these flags to include a vendor name.
+This behavior may still work, but it is deprecated, and is not
+recommended.
+
+The options are:
+
+     encrypt=#    set encryption type 1, 2, or 3.
+     has_tag      The attribute can have an RFC 2868 style tag
+
+The "encrypt" flag marks the attribute as being encrypted with one of
+three possible methods.  "1" means that the attribute is encrypted
+with the method as defined in \fIRFC2865\fP for the User-Password
+attribute.  "2" means that the password is encrypted with the method
+as defined in \fIRFC2868\fP for the Tunnel-Password attribute.  "3"
+means that the attribute is encrypted as per Ascend's definitions for
+the Ascend-Send-Secret attribute.
+
+The "has_tag" flag marks the attribute as being permitted to have a
+tag, as defined in \fIRFC2868\fP.  The purpose of the tag is to allow
+grouping of attributes for tunneled users.  See \fIRFC2868\fP for
+more details.
+
+When the server receives an encoded attribute in a RADIUS packet, it
+looks up that attribute by number in the dictionary, and uses the
+definition found there for printing diagnostic and log messages.  When
+the server sees an attribute name in a configuration file, it looks up
+that attribute by name in the dictionary, and uses the definition
+found there.
+
+.TP 0.5i
+.B VALUE attribute-name value-name number
+Define an attribute value name to number mapping, for an attribute of
+type \fIinteger\fP.  The \fIattribute-name\fP field MUST be previously
+defined by an \fIATTRIBUTE\fP entry.  The \fIvalue-name\fP field can
+be any non-space text, but is usually taken from \fIRFC2865\fP, or
+other documents..  The \fInumber\fP field is also taken from the
+relevant documents, for that name.
+
+When the server receives an encoded value in a RADIUS packet, it looks
+up the value of that attribute by number in the dictionary, and uses
+the name found there for printing diagnostic and log messages.
+.TP 0.5i
+.B VENDOR vendor-name number [format=...]
+Define a Vendor Specific Attribute encapsulation for \fIvendor-name\fP
+to \fInumber\fP.  For a list of vendor names and numbers, see
+http://www.iana.org/enterprise-numbers.txt.
+
+The "format=t,l" statement tells the server how many octets to use to
+encode/decode the vendor "type" and "length" fields in the attributes.
+The default is "format=1,1", which does not have to be specified.  For
+USR VSA's, the format is "format=4,0", for Lucent VSA's it's
+"format=2,1", and for Starent VSA's it's "format=2,2".
+
+The supported values for the number of type octets (i.e. the first
+digit) are 1, 2, and 4.  The support values for the number of length
+octets (i.e. the second digit) are 0, 1, and 2.  Any combination of
+those values will work.
+
+.TP 0.5i
+.B BEGIN-VENDOR vendor-name
+Define the start of a block of Vendor-Specific attributes.  All of the
+following \fIATTRIBUTE\fP  definitions are interpreted as being for the
+named vendor, until the block is closed by an "END-VENDOR" statement.
+
+This practice is preferred to placing the vendor name at the end of an
+\fIATTRIBUTE\fP  definition.
+
+For VSAs in the RFC 6929 "Extended vendor-specific" space, a format
+can be specified following the "vendor-name".  The format should be
+"format=Extended-Vendor-Specific-1", through
+"format=Extended-Vendor-Specific-6".  The matching "END-VENDOR" should
+just have the "vendor-name", without the format string.
+.TP 0.5i
+.B END-VENDOR vendor-name
+End a previously defined BEGIN-VENDOR block.  The "vendor-name" must match.
+.TP 0.5i
+.B $INCLUDE filename
+Include dictionary entries from the file \fIfilename\fP.  The
+\fIfilename\fP is taken as relative to the location of the file which
+is asking for the inclusion.
+.TP 0.5i
+.B BEGIN-TLV name
+This feature is supported for backwards compatibility with older
+dictionaries.  It should not be used.  The new "oid" form for defining
+the attribute number should be used instead.
+.TP 0.5i
+.B END-TLV name
+This feature is supported for backwards compatibility with older
+dictionaries.  It should not be used.  The new "oid" form for defining
+the attribute number should be used instead.
+.PP
+.SH FILES
+.I /etc/raddb/dictionary,
+.I /usr/share/freeradius/dictionary.*
+.SH "SEE ALSO"
+.BR radiusd (8),
+.BR RFC2865,
+.BR RFC2866,
+.BR RFC2868
+.BR RFC6929