RFC 2868

RADIUS Attributes for Tunnel Protocol Support

📅 published June 2000, from ietf

RFC 2868: RADIUS Attributes for Tunnel Protocol Support 🎀

  • Network Working Group ✨
  • Authors: G. Zorn (Cisco Systems, Inc.), D. Leifer (Ascend Communications), A. Rubens (Ascend Communications), J. Shriver (Intel Corporation), M. Holdrege (ipVerse), I. Goyret (Lucent Technologies)
  • Category: Informational 📚
  • Date: June 2000 🗓️
  • Updates: RFC 2865 🔄

Status of This Memo 📜

bestie, this memo gives information to the Internet community. It is not an Internet standard of any kind, and distribution of it is unlimited 🫶

Copyright (C) The Internet Society (2000). All Rights Reserved. 💜

Abstract 🌸

okay so this doc defines a set of RADIUS attributes built to support compulsory tunneling in dial-up networks. It's giving "the tunnel just happens to you" energy 💀

1. Motivation 🦋

so lots of tunneling protocols, like L2TP, get used for dial-up network access. Some setups are voluntary tunneling, where the user asks for a tunnel for a specific purpose. Think of accessing corporate intranets over the Internet. Other setups are compulsory tunneling, where the tunnel gets created with zero action from the user and zero choice on their part 😭

To make compulsory tunneling work, we need new RADIUS attributes that carry the tunneling info from the RADIUS server to the tunnel end points. That's exactly what this document defines ✨ If you want specific recommendations and examples of using these attributes with L2TP, go check RFC 2809 🧚

2. Specification of Requirements 📋

In this document, the key words "MAY", "MUST", "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as described in [14]. The rules are the rules, periodt 💅

3. Attributes 👑

Multiple instances of each attribute defined below can show up in a single RADIUS packet. When that happens, the attributes applied to any given tunnel SHOULD all contain the same value in their Tag fields. Otherwise, the Tag field SHOULD NOT be used 🎀

If the RADIUS server returns attributes describing multiple tunnels, the tunnel initiator SHOULD interpret those tunnels as alternatives. The server SHOULD also include an instance of the Tunnel-Preference Attribute in the set of Attributes for each alternative tunnel 🌈

Same vibe for the other direction: if the RADIUS client includes multiple sets of tunnel Attributes in an Access-Request packet, all the Attributes for a given tunnel SHOULD contain the same value in their Tag fields. Each set SHOULD also include an appropriately valued instance of the Tunnel-Preference Attribute 🫶

3.1. Tunnel-Type 🔥

Description

This Attribute says which tunneling protocol(s) to use (if you're the tunnel initiator) or which tunneling protocol is in use (if you're the tunnel terminator). It MAY be included in Access-Request, Access-Accept and Accounting-Request packets 💖

If the Tunnel-Type Attribute shows up in an Access-Request packet from a tunnel initiator, it SHOULD be taken as a hint to the RADIUS server about which tunneling protocols the tunnel end-point supports. The RADIUS server MAY ignore that hint, though 🙈

A tunnel initiator is not required to implement any of these tunnel types. But if a tunnel initiator gets an Access-Accept packet with only unknown or unsupported Tunnel-Types, it MUST behave as though an Access-Reject had been received instead 💀

If the Tunnel-Type Attribute shows up in an Access-Request packet from a tunnel terminator, it SHOULD be taken to signify the tunneling protocol in use. In this case, if the RADIUS server decides the communicated protocol is not authorized, it MAY return an Access-Reject packet 🦋

Last one for this section: if a tunnel terminator gets an Access-Accept packet with one or more Tunnel-Type Attributes, and none of them represent the tunneling protocol in use, the tunnel terminator SHOULD behave as though an Access-Reject had been received instead 🍓

A quick look at the Tunnel-Type Attribute format. The fields go 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: 64 for Tunnel-Type
  • Length: Always 6.
  • Tag: This is one octet long and groups attributes in the same packet that refer to the same tunnel. Valid values are 0x01 through 0x1F, inclusive. If the Tag field is unused, it MUST be zero (0x00). 🎀
  • Value: This is three octets and holds one of the following values, which tells you what type of tunnel to start 💅
1      Point-to-Point Tunneling Protocol (PPTP) [1]
2      Layer Two Forwarding (L2F) [2]
3      Layer Two Tunneling Protocol (L2TP) [3]
4      Ascend Tunnel Management Protocol (ATMP) [4]
5      Virtual Tunneling Protocol (VTP)
6      IP Authentication Header in the Tunnel-mode (AH) [5]
7      IP-in-IP Encapsulation (IP-IP) [6]
8      Minimal IP-in-IP Encapsulation (MIN-IP-IP) [7]
9      IP Encapsulating Security Payload in the Tunnel-mode (ESP) [8]
10     Generic Route Encapsulation (GRE) [9]
11     Bay Dial Virtual Services (DVS)
12     IP-in-IP Tunneling [10]

3.2. Tunnel-Medium-Type 🌸

Description

The Tunnel-Medium-Type Attribute says which transport medium to use when creating a tunnel, for protocols (like L2TP) that can run over multiple transports. It MAY be included in both Access-Request and Access-Accept packets. If it shows up in an Access-Request packet, it SHOULD be taken as a hint to the RADIUS server about which tunnel media the tunnel end-point supports. The RADIUS server MAY ignore the hint, though 🧚

Here's the format. The fields go 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: 65 for Tunnel-Medium-Type
  • Length: 6
  • Tag: This is one octet long and groups attributes in the same packet that refer to the same tunnel. Valid values are 0x01 through 0x1F, inclusive. If the Tag field is unused, it MUST be zero (0x00). 🦋
  • Value: This is three octets and holds one of the values listed under "Address Family Numbers" in [14]. To make life easier, here's a relevant excerpt of that list 💖
1      IPv4 (IP version 4)
2      IPv6 (IP version 6)
3      NSAP
4      HDLC (8-bit multidrop)
5      BBN 1822
6      802 (includes all 802 media plus Ethernet "canonical format")
7      E.163 (POTS)
8      E.164 (SMDS, Frame Relay, ATM)
9      F.69 (Telex)
10     X.121 (X.25, Frame Relay)
11     IPX
12     Appletalk
13     Decnet IV
14     Banyan Vines
15     E.164 with NSAP format subaddress

3.3. Tunnel-Client-Endpoint 🫧

Description

This Attribute holds the address of the initiator end of the tunnel. It MAY be included in both Access-Request and Access-Accept packets, to show the address a new tunnel should start from 🍓

If the Tunnel-Client-Endpoint Attribute is in an Access-Request packet, the RADIUS server should treat the value as a hint. The server isn't obligated to honor it, though 🙈

This Attribute SHOULD be included in Accounting-Request packets that contain Acct-Status-Type attributes with values of either Start or Stop. In that case, it shows the address the tunnel was started from 👑

This Attribute, along with the Tunnel-Server-Endpoint and Acct-Tunnel-Connection-ID attributes, may be used to give you a globally unique way to identify a tunnel for accounting and auditing. Iconic, honestly 🌈

Here's the format. The fields go 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: 66 for Tunnel-Client-Endpoint.
  • Length: >= 3
  • Tag: This is one octet long and groups attributes in the same packet that refer to the same tunnel. If the Tag value is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (out of several alternatives) this attribute pertains to. If the Tag value is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field. 🎀
  • String: The format of the address in this field depends on the value of the Tunnel-Medium-Type attribute.

If Tunnel-Medium-Type is IPv4 (1), the string is either the fully qualified domain name (FQDN) of the tunnel client machine, or a "dotted-decimal" IP address. Conformant implementations MUST support the dotted-decimal format and SHOULD support the FQDN format for IP addresses. 💖

If Tunnel-Medium-Type is IPv6 (2), the string is either the FQDN of the tunnel client machine, or 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. 🧚

Heads up: if Tunnel-Medium-Type is neither IPv4 nor IPv6, the string is a tag that refers to configuration data local to the RADIUS client. That data describes the interface and the medium-specific address to use. 🔥

3.4. Tunnel-Server-Endpoint ✨

Description 🌸

okay so this Attribute tells you the address of the server end of the tunnel 🦋 the Tunnel-Server-Endpoint Attribute MAY be tossed into the Access-Request packet as a hint for the RADIUS server 💜 and it MUST show up in the Access-Accept packet if you actually want the tunnel to get started 🔥 it SHOULD also be in Accounting-Request packets that carry an Acct-Status-Type of either Start or Stop and are about a tunneled session 📝 bestie, this Attribute plus the Tunnel-Client-Endpoint and Acct-Tunnel-Connection-ID [11] can team up to give you a globally unique way to identify a tunnel for accounting and auditing 👑 it's giving main character energy for tracking.

A summary of the Tunnel-Server-Endpoint Attribute format is shown below 💅 the fields go left to right, no cap.

    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 🎀

  • Type: 67 for Tunnel-Server-Endpoint.

Length 🧚

  • Length: >= 3

Tag 🍓

ngl the Tag field is one octet and it's basically how you group attributes in the same packet that all point at the same tunnel 💖 if the Tag value is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as saying which tunnel (out of several alternatives) this attribute is about 🌈 if the Tag is greater than 0x1F, it SHOULD be read as the first byte of the String field that comes next 🙈

String 🫶

the format of the address in the String field depends on what the Tunnel-Medium-Type attribute says 🔥

  • If Tunnel-Medium-Type is IPv4 (1), the string is either the fully qualified domain name (FQDN) of the tunnel client machine, or a "dotted-decimal" IP address. Conformant implementations MUST support the dotted-decimal format and SHOULD support the FQDN format for IP addresses 💅
  • If Tunnel-Medium-Type is IPv6 (2), the string is either the FQDN of the tunnel client machine, or 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, the string is a tag pointing at configuration data local to the RADIUS client that describes the interface and medium-specific address to use 🦋

3.5. Tunnel-Password 🔐

Description 💜

this Attribute may hold a password that's used to authenticate to a remote server 🎀 it may only be included in an Access-Accept packet, so don't you dare put it anywhere else 🙅‍♀️

A summary of the Tunnel-Password Attribute format is shown below 🌸 fields go left to right, periodt.

    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 🎀

  • Type: 69 for Tunnel-Password

Length 🧚

  • Length: >= 5

Tag 🍓

the Tag field is one octet and it's there to group attributes in the same packet that refer to the same tunnel 💖 valid values are 0x01 through 0x1F, inclusive 🌈 if the Tag value is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as saying which tunnel (out of several alternatives) this attribute is about; otherwise, the Tag field SHOULD be ignored 🙈

Salt 🧂

the Salt field is two octets and it keeps the encryption key unique for each Tunnel-Password attribute in a given Access-Accept packet 🔑 the most significant bit (leftmost) of the Salt field MUST be set (1) 💅 and the contents of each Salt field in a given Access-Accept packet MUST be unique 🦋 no copycats allowed.

String 🫶

the plaintext String field has three logical sub-fields: the Data-Length and Password sub-fields (both of which are required), plus an optional Padding sub-field 🌸 the Data-Length sub-field is one octet and holds the length of the unencrypted Password sub-field 💜 the Password sub-field holds 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 🔥 when it's there, its length is variable, anywhere from 1 to 15 octets ✨ the String field MUST be encrypted like this before it gets sent 👑

Here's how the encryption goes, step by step 📝

  • Build a plaintext version of the String field by concatenating the Data-Length and Password sub-fields. If needed, pad the result 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 matching 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 gets reversed to pull out the plaintext String 🔄 it's like unlocking a diary with the right key 💖

3.6. Tunnel-Private-Group-ID 🌈

Description 🦋

this Attribute tells you 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 that a particular connection will end up in 🌸 it SHOULD be included in the Access-Accept packet if this tunnel session is supposed to be treated as belonging to a particular private group 👑 private groups can be used to link a tunneled session with a certain group of users 💅 for example, they can help with routing unregistered IP addresses through a particular interface 🧚 and it SHOULD be included in Accounting-Request packets that carry an Acct-Status-Type of either Start or Stop and are about a tunneled session 📝

A summary of the Tunnel-Private-Group-ID Attribute format is shown below 💜 fields go 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 🎀

  • Type: 81 for Tunnel-Private-Group-ID.

Length 🧚

  • Length: >= 3

Tag 🍓

the Tag field is one octet and it groups attributes in the same packet that refer to the same tunnel 💖 if the Tag value is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as saying which tunnel (out of several alternatives) this attribute is about 🌈 if the Tag is greater than 0x1F, it SHOULD be read as the first byte of the String field that comes next 🙈

String 🫶

this field must be present 🔥 the group is represented by the String field, and there's no restriction on the format of group IDs, so get creative 🌸✨

3.7. Tunnel-Assignment-ID 🦋

Description

okay so this attribute tells the tunnel initiator which particular tunnel a session should get put into 🚇 Some tunneling protocols, like PPTP and L2TP, let sessions between the same two tunnel endpoints get multiplexed over one shared tunnel, and they also let a session have its own dedicated tunnel all to itself. This attribute gives RADIUS a way to tell the tunnel initiator (e.g. PAC, LAC) whether to assign the session to a multiplexed tunnel or a separate one. It's also giving sorting: sessions sharing multiplexed tunnels can be assigned to different multiplexed tunnels 💅

A tunneling implementation can give different tunnels different characteristics. For example, different tunnels might get different QoS parameters 👀 Those tunnels might carry one session or a bunch of them. So the Tunnel-Assignment-ID lets the RADIUS server say "put this session in a tunnel with the right level of service" ✨ It's expected that any QoS-related RADIUS tunneling attributes defined in the future that come along with this attribute will be linked by the tunnel initiator to the ID given by this attribute. Until then, whatever a particular ID string means is totally up to local configuration in the tunnel initiator 🧚

The Tunnel-Assignment-ID is only relevant to RADIUS and the tunnel initiator. The ID is meant to be purely local, just between RADIUS and the tunnel initiator. The ID the tunnel initiator assigns is not sent along to the tunnel peer 🤐

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

If a tunnel initiator supports the Tunnel-Assignment-ID Attribute, then it should assign a session to a tunnel like this:

  • 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). 🚫

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 sent 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 long and is meant to group attributes in the same packet that 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 to. 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 the RADIUS server sends back more than one set of tunneling attributes to the tunnel initiator, this Attribute SHOULD be included in each set to show the relative preference given to each tunnel 🥇 For example, say the server returns attributes describing two tunnels: one with a Tunnel-Type of PPTP and one with a Tunnel-Type of L2TP. If the tunnel initiator only supports one of the returned Tunnel-Types, it'll start a tunnel of that type. But if it supports both tunnel protocols, it SHOULD use the value of the Tunnel-Preference Attribute to decide which tunnel to start 🤔 The tunnel with the numerically lowest value in the Value field of this Attribute SHOULD be given the highest preference. The values given to two or more instances of the Tunnel-Preference Attribute within a single Access-Accept packet MAY be identical. In that 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 sent 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 long and is meant to group attributes in the same packet that 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 long and shows the preference given to the tunnel it refers to. Higher preference goes to lower values, with 0x000000 being most preferred and 0xFFFFFF least preferred. 🏆

3.9. Tunnel-Client-Auth-ID 🔐

Description

This Attribute specifies the name the tunnel initiator uses 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 wanted. This Attribute SHOULD be included in Accounting-Request packets that contain Acct-Status-Type attributes with values of either Start or Stop and that pertain to a tunneled session 📦

A summary of the Tunnel-Client-Auth-ID Attribute format is shown below. The fields are sent 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 The Tag field is one octet long and is meant to group attributes in the same packet that 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 to. 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 String field contains the authentication name of the tunnel initiator. The authentication name SHOULD be represented in the UTF-8 charset 🌈

3.10. Tunnel-Server-Auth-ID 🌙

Description

This Attribute specifies the name the tunnel terminator uses 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 wanted. This Attribute SHOULD be included in Accounting-Request packets that contain Acct-Status-Type attributes with values of either Start or Stop and that pertain to a tunneled session 📦

A summary of the Tunnel-Server-Auth-ID Attribute format is shown below. The fields are sent 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 91 for Tunnel-Server-Auth-ID.

Length >= 3

Tag The Tag field is one octet long and is meant to group attributes in the same packet that 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 to. 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 String field contains the authentication name of the tunnel terminator. The authentication name SHOULD be represented in the UTF-8 charset 🌸

4. Table of Attributes 📋

The following table is a handy guide to which of the above attributes can show up in which kinds of packets, and how many of each 💜

Okay bestie, before we get to the security stuff, here's the legend for that table 💅 Read the key before you read the chart 🎀

0     This attribute MUST NOT be present in packet.
0+    Zero or more instances of this attribute MAY be present in packet.
0-1   Zero or one instance of this attribute MAY be present in packet.

5. Security Considerations 🔥

This part is serious, so pay attention 😭 The Tunnel-Password Attribute may contain information that should only be known to a tunnel endpoint. However, the method used to hide the value of the attribute means intervening RADIUS proxies will know what's inside. For this reason, the Tunnel-Password Attribute SHOULD NOT be included in Access-Accept packets that may pass through (relatively) untrusted RADIUS proxies. Also, the Tunnel-Password Attribute SHOULD NOT be returned to an unauthenticated client. If the matching Access-Request packet did not contain a verified instance of the Signature Attribute [15], then the Access-Accept packet SHOULD NOT contain an instance of the Tunnel-Password Attribute 🙈

Tunnel protocols come in different levels of security, from none (e.g., PPTP) to strong (e.g., IPSec) 🦋 But here's the catch: in the compulsory tunneling case, whatever security is in place only covers traffic between the tunnel endpoints. So end-users SHOULD NOT rely on the tunnel to protect their data 💀 Encryption and/or integrity protection of tunneled traffic MUST NOT be treated as a replacement for end-to-end security. No shortcuts, periodt ✨

6. IANA Considerations 🧚

This document defines a bunch of "magic" numbers that the IANA is going to maintain. This section explains the criteria the IANA should use when it assigns more numbers to each of these lists. The following subsections describe the assignment policy for the namespaces that are defined elsewhere in this document.

6.1. Tunnel-Type Attribute Values

Values 1-12 of the Tunnel-Type Attribute are defined in Section 5.1. The remaining values are available for assignment by the IANA with IETF Consensus [16] 🌸

6.2. Tunnel-Medium-Type Attribute Values

Values 1-15 of the Tunnel-Medium-Type Attribute are defined in Section 5.2. The remaining values are available for assignment by the IANA with IETF Consensus [16] 🍓

7. References 📚

[1]  Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and
     G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637,
     July 1999.

[2]  Valencia, A., Littlewood, M. and T. Kolar, T., "Cisco Layer Two
     Forwarding (Protocol) 'L2F'", RFC 2341, May 1998.

[3]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
     B. Palter, "Layer Two Tunnelling Protocol (L2TP)", RFC 2661,
     August 1999.

[4]  Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC
     2107, February 1997.

[5]  Kent, S. and R. Atkinson, "Security Architecture for the
     Internet Protocol", RFC 2401, November 1998.

[6]  Perkins, C., "IP Encapsulation within IP", RFC 2003, October
     1996.

[7]  Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
     October 1996.

[8]  Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC
     1827, August 1995.

[9]  Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
     Encapsulation (GRE)", RFC 1701, October 1994.

[10] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.

[11] Zorn, G. and D. Mitton, "RADIUS Accounting Modifications for
     Tunnel Protocol Support", RFC 2867, June 2000.

[12] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
     Authentication Dial in User Service (RADIUS)", RFC 2865, June
     2000.

[13] Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997.

[14] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
     October 1994.

[15] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC
     2869, June 2000.

[16] Narten, T. and H. Alvestrand, "Guidelines for writing an IANA
     Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[17] Hinden, R. and S. Deering, "IP Version 6 Addressing
     Architecture", RFC 2373, July 1998.

8. Acknowledgements 🫶

Huge thanks to Dave Mitton for spotting a nasty circular dependency in the original Tunnel-Password attribute definition 👑 Thanks also (in no particular order) to Kory Hamzeh, Bertrand Buclin, Andy Valencia, Bill Westfield, Kris Michielsen, Gurdeep Singh Pall, Ran Atkinson, Aydin Edguer, and Bernard Aboba for the useful input and review ✨

9. Chair's Address 🎀

The RADIUS Working Group can be contacted via the current chair:

Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California  94588

Phone: +1 510 426 0770
EMail: cdr@livingston.com

10. Authors' Addresses 💜

Questions about this memo can also be directed to:

Glen Zorn
Cisco Systems, Inc.
500 108th Avenue N.E., Suite 500
Bellevue, Washington 98004
USA

Phone: +1 425 438 8218
FAX:   +1 425 438 1848
EMail: gwz@cisco.com


Dory Leifer
Ascend Communications
1678 Broadway
Ann Arbor, MI 48105

Phone:  +1 734 747 6152
EMail: leifer@del.com

John Shriver
Intel Corporation
28 Crosby Drive
Bedford, MA  01730

Phone:  +1 781 687 1329
EMail: John.Shriver@intel.com


Allan Rubens
Ascend Communications
1678 Broadway
Ann Arbor, MI 48105

Phone:  +1 313 761 6025
EMail: acr@del.com


Matt Holdrege
ipVerse
223 Ximeno Ave.
Long Beach, CA 90803

EMail: matt@ipverse.com


Ignacio Goyret
Lucent Technologies
One Ascend Plaza
1701 Harbor Bay Parkway
Alameda, CA 94502

Phone:  +1 510 769 6001
EMail: igoyret@lucent.com

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society 🦋✨

📦 where this page comes from