rfc2868.txt

This program is a RADIUS RFC-compliant daemon, which is derived from original Livingston Enterprise

      If Tunnel-Medium-Type is IPv6 (2), then this string is either the
      FQDN of the tunnel client machine, or it is a text representation
      of the address in either the preferred or alternate form [17].
      Conformant implementations MUST support the preferred form and
      SHOULD support both the alternate text form and the FQDN format
      for IPv6 addresses.

      If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag
      referring to configuration data local to the RADIUS client that
      describes the interface and medium-specific address to use.







Zorn, et al.                 Informational                      [Page 7]

RFC 2868        RADIUS Tunnel Authentication Attributes        June 2000


3.5.  Tunnel-Password

   Description

      This Attribute may contain a password to be used to authenticate
      to a remote server.  It may only be included in an Access-Accept
      packet.

   A summary of the Tunnel-Password Attribute format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     Tag       |   Salt
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Salt (cont)  |   String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
      69 for Tunnel-Password

   Length
      >= 5

   Tag
      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  Valid values for this field are 0x01 through 0x1F,
      inclusive.  If the value of the Tag field is greater than 0x00 and
      less than or equal to 0x1F, it SHOULD be interpreted as indicating
      which tunnel (of several alternatives) this attribute pertains;
      otherwise, the Tag field SHOULD be ignored.

   Salt
      The Salt field is two octets in length and is used to ensure the
      uniqueness of the encryption key used to encrypt each instance of
      the Tunnel-Password attribute occurring in a given Access-Accept
      packet.  The most significant bit (leftmost) of the Salt field
      MUST be set (1).  The contents of each Salt field in a given
      Access-Accept packet MUST be unique.

   String
      The plaintext String field consists of three logical sub-fields:
      the Data-Length and Password sub-fields (both of which are
      required), and the optional Padding sub-field.  The Data-Length
      sub-field is one octet in length and contains the length of the
      unencrypted Password sub-field.  The Password sub-field contains



Zorn, et al.                 Informational                      [Page 8]

RFC 2868        RADIUS Tunnel Authentication Attributes        June 2000


      the actual tunnel password.  If the combined length (in octets) of
      the unencrypted Data-Length and Password sub-fields is not an even
      multiple of 16, then the Padding sub-field MUST be present.  If it
      is present, the length of the Padding sub-field is variable,
      between 1 and 15 octets.  The String field MUST be encrypted as
      follows, prior to transmission:

         Construct a plaintext version of the String field by
         concatenating the Data-Length and Password sub-fields.  If
         necessary, pad the resulting string until its length (in
         octets) is an even multiple of 16.  It is recommended that zero
         octets (0x00) be used for padding.  Call this plaintext P.

         Call the shared secret S, the pseudo-random 128-bit Request
         Authenticator (from the corresponding Access-Request packet) R,
         and the contents of the Salt field A.  Break P into 16 octet
         chunks p(1), p(2)...p(i), where i = len(P)/16.  Call the
         ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
         Intermediate values b(1), b(2)...c(i) are required.  Encryption
         is performed in the following manner ('+' indicates
         concatenation):

            b(1) = MD5(S + R + A)    c(1) = p(1) xor b(1)   C = c(1)
            b(2) = MD5(S + c(1))     c(2) = p(2) xor b(2)   C = C + c(2)
                        .                      .
                        .                      .
                        .                      .
            b(i) = MD5(S + c(i-1))   c(i) = p(i) xor b(i)   C = C + c(i)

         The resulting encrypted String field will contain
         c(1)+c(2)+...+c(i).

      On receipt, the process is reversed to yield the plaintext String.

3.6.  Tunnel-Private-Group-ID

   Description

      This Attribute indicates the group ID for a particular tunneled
      session.  The Tunnel-Private-Group-ID Attribute MAY be included in
      the Access-Request packet if the tunnel initiator can pre-
      determine the group resulting from a particular connection and
      SHOULD be included in the Access-Accept packet if this tunnel
      session is to be treated as belonging to a particular private
      group.  Private groups may be used to associate a tunneled session
      with a particular group of users.  For example, it may be used to
      facilitate routing of unregistered IP addresses through a




Zorn, et al.                 Informational                      [Page 9]

RFC 2868        RADIUS Tunnel Authentication Attributes        June 2000


      particular interface.  It SHOULD be included in Accounting-Request
      packets which contain Acct-Status-Type attributes with values of
      either Start or Stop and which pertain to a tunneled session.

   A summary of the Tunnel-Private-Group-ID Attribute format is shown
   below.  The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |     Tag       |   String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
      81 for Tunnel-Private-Group-ID.

   Length
      >= 3

   Tag
      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  If the value of the Tag field is greater than 0x00
      and less than or equal to 0x1F, it SHOULD be interpreted as
      indicating which tunnel (of several alternatives) this attribute
      pertains.  If the Tag field is greater than 0x1F, it SHOULD be
      interpreted as the first byte of the following String field.

   String
      This field must be present.  The group is represented by the
      String field.  There is no restriction on the format of group IDs.

3.7.  Tunnel-Assignment-ID

   Description

      This Attribute is used to indicate to the tunnel initiator the
      particular tunnel to which a session is to be assigned.  Some
      tunneling protocols, such as PPTP and L2TP, allow for sessions
      between the same two tunnel endpoints to be multiplexed over the
      same tunnel and also for a given session to utilize its own
      dedicated tunnel.  This attribute provides a mechanism for RADIUS
      to be used to inform the tunnel initiator (e.g. PAC, LAC) whether
      to assign the session to a multiplexed tunnel or to a separate
      tunnel.  Furthermore, it allows for sessions sharing multiplexed
      tunnels to be assigned to different multiplexed tunnels.





Zorn, et al.                 Informational                     [Page 10]

RFC 2868        RADIUS Tunnel Authentication Attributes        June 2000


      A particular tunneling implementation may assign differing
      characteristics to particular tunnels.  For example, different
      tunnels may be assigned different QOS parameters.  Such tunnels
      may be used to carry either individual or multiple sessions.  The
      Tunnel-Assignment-ID attribute thus allows the RADIUS server to
      indicate that a particular session is to be assigned to a tunnel
      that provides an appropriate level of service.  It is expected
      that any QOS-related RADIUS tunneling attributes defined in the
      future that accompany this attribute will be associated by the
      tunnel initiator with the ID given by this attribute.  In the
      meantime, any semantic given to a particular ID string is a matter
      left to local configuration in the tunnel initiator.

      The Tunnel-Assignment-ID attribute is of significance only to
      RADIUS and the tunnel initiator.  The ID it specifies is intended
      to be of only local use to RADIUS and the tunnel initiator.  The
      ID assigned by the tunnel initiator is not conveyed to the tunnel
      peer.

      This attribute MAY be included in the Access-Accept.  The tunnel
      initiator receiving this attribute MAY choose to ignore it and
      assign the session to an arbitrary multiplexed or non-multiplexed
      tunnel between the desired endpoints.  This attribute SHOULD also
      be included in Accounting-Request packets which contain Acct-
      Status-Type attributes with values of either Start or Stop and
      which pertain to a tunneled session.

      If a tunnel initiator supports the Tunnel-Assignment-ID Attribute,
      then it should assign a session to a tunnel in the following
      manner:

         If this attribute is present and a tunnel exists between the
         specified endpoints with the specified ID, then the session
         should be assigned to that tunnel.

         If this attribute is present and no tunnel exists between the
         specified endpoints with the specified ID, then a new tunnel
         should be established for the session and the specified ID
         should be associated with the new tunnel.

         If this attribute is not present, then the session is assigned
         to an unnamed tunnel.  If an unnamed tunnel does not yet exist
         between the specified endpoints then it is established and used
         for this and subsequent sessions established without the
         Tunnel-Assignment-ID attribute.  A tunnel initiator MUST NOT
         assign a session for which a Tunnel-Assignment-ID Attribute was
         not specified to a named tunnel (i.e. one that was initiated by
         a session specifying this attribute).



Zorn, et al.                 Informational                     [Page 11]

RFC 2868        RADIUS Tunnel Authentication Attributes        June 2000


      Note that the same ID may be used to name different tunnels if
      such tunnels are between different endpoints.

   A summary of the Tunnel-Assignment-ID Attribute format is shown
   below.  The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |      Tag      |   String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
      82 for Tunnel-Assignment-ID.

   Length
      >= 3

   Tag
      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  If the value of the Tag field is greater than 0x00
      and less than or equal to 0x1F, it SHOULD be interpreted as
      indicating which tunnel (of several alternatives) this attribute
      pertains.  If the Tag field is greater than 0x1F, it SHOULD be
      interpreted as the first byte of the following String field.

   String
      This field must be present.  The tunnel ID is represented by the
      String field.  There is no restriction on the format of the ID.

3.8.  Tunnel-Preference

   Description

      If more than one set of tunneling attributes is returned by the
      RADIUS server to the tunnel initiator, this Attribute SHOULD be
      included in each set to indicate the relative preference assigned
      to each tunnel.  For example, suppose that Attributes describing
      two tunnels are returned by the server, one with a Tunnel-Type of
      PPTP and the other with a Tunnel-Type of L2TP.  If the tunnel
      initiator supports only one of the Tunnel-Types returned, it will
      initiate a tunnel of that type.  If, however, it supports both
      tunnel protocols, it SHOULD use the value of the Tunnel-Preference
      Attribute to decide which tunnel should be started.  The tunnel
      having the numerically lowest value in the Value field of this
      Attribute SHOULD be given the highest preference.  The values
      assigned to two or more instances of the Tunnel-Preference



Zorn, et al.                 Informational                     [Page 12]

RFC 2868        RADIUS Tunnel Authentication Attributes        June 2000


      Attribute within a given Access-Accept packet MAY be identical.
      In this case, the tunnel initiator SHOULD use locally configured
      metrics to decide which set of attributes to use.  This Attribute
      MAY be included (as a hint to the server) in Access-Request
      packets, but the RADIUS server is not required to honor this hint.

   A summary of the Tunnel-Preference Attribute format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     Tag       |     Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
      83 for Tunnel-Preference

   Length
      Always 6.

   Tag
      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  Valid values for this field are 0x01 through 0x1F,
      inclusive.  If the Tag field is unused, it MUST be zero (0x00).

   Value
      The Value field is three octets in length and indicates the
      preference to be given to the tunnel to which it refers; higher
      preference is given to lower values, with 0x000000 being most
      preferred and 0xFFFFFF least preferred.

3.9.  Tunnel-Client-Auth-ID

   Description

      This Attribute specifies the name used by the tunnel initiator
      during the authentication phase of tunnel establishment.  The
      Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the
      RADIUS server) in the Access-Request packet, and MUST be included
      in the Access-Accept packet if an authentication name other than
      the default is desired.  This Attribute SHOULD be included in
      Accounting-Request packets which contain Acct-Status-Type
      attributes with values of either Start or Stop and which pertain
      to a tunneled session.



Zorn, et al.                 Informational                     [Page 13]

RFC 2868        RADIUS Tunnel Authentication Attributes        June 2000


   A summary of the Tunnel-Client-Auth-ID Attribute format is shown
   below.  The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Length     |      Tag      |   String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
      90 for Tunnel-Client-Auth-ID.

   Length
      >= 3

   Tag