Subject: (radius) FW: Problem with tunnel-auth-06 and Tag

From: "Beadles, Mark A." <[email-masked]>
Date: Wed, 2 Jun 1999 16:21:06 -0400

Forwarded at John's request.

+ Mark Anthony Beadles +  UUNET Product Development  + 
+  [email-masked]   + http://networking.us.uu.net +
+  Voice 614.723.1941  +       Fax 614.723.8407      +

-----Original Message-----
From: John Shriver [mailto:[email-masked]]
Sent: Wednesday, 02 June 1999 12:20 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: Problem with tunnel-auth-06 and Tag

I think what is going on with the tag is not about compatiblity with
earlier revs of the Internet-Draft.

I think it's about compatability with certain very popular RADIUS
servers.  In particular, the old free one from Livingston.  Probably
also the last of the free Merit servers.

But, really, adding the tags in the first place pushed the envelope of
the whole "data dictionary" idea from Livingston's first proposals for
RAIDUS.  The idea what that new AVP's could be designed, and
implemented in existing RADIUS servers by modifying the data
dictionary file, and not the source code of the server.

By adding the tag, we've changed from an AVP (attribute value pair) to
an AVVT (attribute value value triplet).

So, the idea is to design the definitions of the tags such that if you
are NOT using tags, there are special coding rules such that an old
data dictionary RADIUS server can be used without modification.  In
this case, the tags on numeric fields have value 0, and the tags for
string fields have the first character of the string (> 0x1f).

However, I see that this rule has not been applied uniformly.
Atttribute Tunnel-Password (69) is probably impossible to implement on
the old data dictionary RADIUS servers.  (Looking at the contents,
that makes sense.)  Still, we should probably say to send 0 in the tag
when tags are not in use.  (Or 0xFF, or something.)

I think if the motivation for the Tag field is better written, and an
explanation of why the strange values for the Tag field when it's not
in use, it would help a lot.

Let's give it a try (offering up 3 paragraphs before is how I became a
co-author):

5.  Attributes

There are two modes in which these set of attributes may be used.  In
the first, only one instance of each attribute may be included in a
single RADIUS packet, on the second, there may be multiple instances
of these attributes.  The coding of the Tag field differs in each
mode. 

5.1  Single Instance of Each Attribute

Implementation of single-instance mode is a MUST for RADIUS clients
(tunnel initiators) and RADIUS servers.

In the single-instance mode, there are special coding rules for the
Tag field.  The purpose of these codings rules is to be compatible
with the installed base of RADIUS servers that use the "data
dictionary" concept.  The coding of the Tag in numeric attributes is
0, so that the numeric attribute can be viewed by the RADIUS server as
a single 32-bit number.  The coding of the Tag in string attributes is
as the first character of the string, which must be greater than 0x1f.
(The coding of the Tunnel-Password attribute is so complicated that it
simply won't work with older RADIUS servers.)  [XXX Am I right here?]

In particalar, when the tunnel-initiator sends an Access-Request
packet, if there is only one instance, then this compatible encoding
MUST be used.

5.2  Multiple Instances of Each Attribute

Multiple-instance mode is a MAY for RADIUS clients (tunnel initiators)
and RADIUS servers.  Use of this mode must be controlled by user
configuration.  (This MAY be implicit by the nature of the data coded
into the RADIUS server.)

In the multiple-instance mode, there can be up to 15 instances of each
attribute, numbered 1-15 (0x01 - 0x1f).  The attributes come in
logical sets, each of which MUST have the same value in the Tag field.
Each of these sets SHOULD include the Tunnel-Preference attribute.

These sets of instances SHOULD be interpreted by the tunnel initiator
as alternatives.  They SHOULD be evaluated in order of the value of
the Tunnel-Preference attribute, comparing the set of instances to the
preferences and capabilities of the tunnel initiator.

Similary, the tunnel initiator MAY include multiple sets of tunnel
Attributes in an Access-Request packet.

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.