diff options
Diffstat (limited to 'doc/rfc/rfc2868.txt')
| -rw-r--r-- | doc/rfc/rfc2868.txt | 1123 |
1 files changed, 1123 insertions, 0 deletions
diff --git a/doc/rfc/rfc2868.txt b/doc/rfc/rfc2868.txt new file mode 100644 index 0000000..29ec9ec --- /dev/null +++ b/doc/rfc/rfc2868.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group G. Zorn +Request for Comments: 2868 Cisco Systems, Inc. +Updates: RFC 2865 D. Leifer +Category: Informational A. Rubens + Ascend Communications + J. Shriver + Intel Corporation + M. Holdrege + ipVerse + I. Goyret + Lucent Technologies + June 2000 + + + RADIUS Attributes for Tunnel Protocol Support + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + This document defines a set of RADIUS attributes designed to support + the provision of compulsory tunneling in dial-up networks. + +1. Motivation + + Many applications of tunneling protocols such as L2TP involve dial-up + network access. Some, such as the provision of access to corporate + intranets via the Internet, are characterized by voluntary tunneling: + the tunnel is created at the request of the user for a specific + purpose. Other applications involve compulsory tunneling: the tunnel + is created without any action from the user and without allowing the + user any choice in the matter. In order to provide this + functionality, new RADIUS attributes are needed to carry the + tunneling information from the RADIUS server to the tunnel end + points; this document defines those attributes. Specific + recommendations for, and examples of, the application of these + attributes for L2TP can be found in RFC 2809. + + + + + + +Zorn, et al. Informational [Page 1] + +RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 + + +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]. + +3. Attributes + + Multiple instances of each of the attributes defined below may be + included in a single RADIUS packet. In this case, the attributes to + be applied to any given tunnel SHOULD all contain the same value in + their respective Tag fields; otherwise, the Tag field SHOULD NOT be + used. + + If the RADIUS server returns attributes describing multiple tunnels + then the tunnels SHOULD be interpreted by the tunnel initiator as + alternatives and the server SHOULD include an instance of the + Tunnel-Preference Attribute in the set of Attributes pertaining to + each alternative tunnel. Similarly, if the RADIUS client includes + multiple sets of tunnel Attributes in an Access-Request packet, all + the Attributes pertaining to a given tunnel SHOULD contain the same + value in their respective Tag fields and each set SHOULD include an + appropriately valued instance of the Tunnel-Preference Attribute. + +3.1. Tunnel-Type + + Description + + This Attribute indicates the tunneling protocol(s) to be used (in + the case of a tunnel initiator) or the the tunneling protocol in + use (in the case of a tunnel terminator). It MAY be included in + Access-Request, Access-Accept and Accounting-Request packets. If + the Tunnel-Type Attribute is present in an Access-Request packet + sent from a tunnel initiator, it SHOULD be taken as a hint to the + RADIUS server as to the tunnelling protocols supported by the + tunnel end-point; the RADIUS server MAY ignore the hint, however. + A tunnel initiator is not required to implement any of these + tunnel types; if a tunnel initiator receives an Access-Accept + packet which contains only unknown or unsupported Tunnel-Types, + the tunnel initiator MUST behave as though an Access-Reject had + been received instead. + + If the Tunnel-Type Attribute is present in an Access-Request + packet sent from a tunnel terminator, it SHOULD be taken to + signify the tunnelling protocol in use. In this case, if the + RADIUS server determines that the use of the communicated protocol + is not authorized, it MAY return an Access-Reject packet. If a + tunnel terminator receives an Access-Accept packet which contains + + + +Zorn, et al. Informational [Page 2] + +RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 + + + one or more Tunnel-Type Attributes, none of which represent the + tunneling protocol in use, the tunnel terminator SHOULD behave as + though an Access-Reject had been received instead. + + A summary of the Tunnel-Type 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 + 64 for Tunnel-Type + + 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 and contains one of the following + values, indicating the type of tunnel to be started. + + 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] + + + + + + + + +Zorn, et al. Informational [Page 3] + +RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 + + +3.2. Tunnel-Medium-Type + + Description + + The Tunnel-Medium-Type Attribute indicates which transport medium + to use when creating a tunnel for those protocols (such as L2TP) + that can operate over multiple transports. It MAY be included in + both Access-Request and Access-Accept packets; if it is present in + an Access-Request packet, it SHOULD be taken as a hint to the + RADIUS server as to the tunnel media supported by the tunnel end- + point. The RADIUS server MAY ignore the hint, however. + + A summary of the Tunnel-Medium-Type Attribute format is given below. + The fields are transmitted 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 + 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 and contains one of the values + listed under "Address Family Numbers" in [14]. For the sake of + convenience, a relevant excerpt of this list is reproduced below. + + 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) + + + +Zorn, et al. Informational [Page 4] + +RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 + + + 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 contains the address of the initiator end of the + tunnel. It MAY be included in both Access-Request and Access- + Accept packets to indicate the address from which a new tunnel is + to be initiated. If the Tunnel-Client-Endpoint Attribute is + included in an Access-Request packet, the RADIUS server should + take the value as a hint; the server is not obligated to honor the + hint, however. This Attribute SHOULD be included in Accounting- + Request packets which contain Acct-Status-Type attributes with + values of either Start or Stop, in which case it indicates the + address from which the tunnel was initiated. This Attribute, + along with the Tunnel-Server-Endpoint and Acct-Tunnel-Connection- + ID attributes, may be used to provide a globally unique means to + identify a tunnel for accounting and auditing purposes. + + A summary of the Tunnel-Client-Endpoint 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 + 66 for Tunnel-Client-Endpoint. + + Length + >= 3 + + + + + + + + + + + +Zorn, et al. Informational [Page 5] + +RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 + + + 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 + The format of the address represented by the String field depends + upon the value of the Tunnel-Medium-Type attribute. + + If Tunnel-Medium-Type is IPv4 (1), then this string is either the + fully qualified domain name (FQDN) of the tunnel client machine, + or it is 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), 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 neither IPv4 nor 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. + +3.4. Tunnel-Server-Endpoint + + Description + + This Attribute indicates the address of the server end of the + tunnel. The Tunnel-Server-Endpoint 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 the initiation of a + tunnel is desired. 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. + This Attribute, along with the Tunnel-Client-Endpoint and Acct- + Tunnel-Connection-ID Attributes [11], may be used to provide a + globally unique means to identify a tunnel for accounting and + auditing purposes. + + + + + + +Zorn, et al. Informational [Page 6] + +RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 + + + A summary of the Tunnel-Server-Endpoint 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 + 67 for Tunnel-Server-Endpoint. + + 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 + The format of the address represented by the String field depends + upon the value of the Tunnel-Medium-Type attribute. + + If Tunnel-Medium-Type is IPv4 (1), then this string is either the + fully qualified domain name (FQDN) of the tunnel client machine, + or it is 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), 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 + 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 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 used by the tunnel terminator + 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. + + A summary of the Tunnel-Server-Auth-ID Attribute format is shown + below. The fields are transmitted from left to right. + + + + + + +Zorn, et al. Informational [Page 14] + +RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 + + + 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 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 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 provides a guide to which of the above attributes + may be found in which kinds of packets, and in what quantity. + +Request Accept Reject Challenge Acct-Request # Attribute +0+ 0+ 0 0 0-1 64 Tunnel-Type +0+ 0+ 0 0 0-1 65 Tunnel-Medium-Type +0+ 0+ 0 0 0-1 66 Tunnel-Client-Endpoint +0+ 0+ 0 0 0-1 67 Tunnel-Server-Endpoint +0 0+ 0 0 0 69 Tunnel-Password +0+ 0+ 0 0 0-1 81 Tunnel-Private-Group-ID +0 0+ 0 0 0-1 82 Tunnel-Assignment-ID +0+ 0+ 0 0 0 83 Tunnel-Preference +0+ 0+ 0 0 0-1 90 Tunnel-Client-Auth-ID +0+ 0+ 0 0 0-1 91 Tunnel-Server-Auth-ID + + The following table defines the meaning of the above table entries. + +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. + + + +Zorn, et al. Informational [Page 15] + +RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 + + +5. Security Considerations + + The Tunnel-Password Attribute may contain information which should + only be known to a tunnel endpoint. However, the method used to hide + the value of the attribute is such that intervening RADIUS proxies + will have knowledge of the contents. For this reason, the Tunnel- + Password Attribute SHOULD NOT be included in Access-Accept packets + which may pass through (relatively) untrusted RADIUS proxies. In + addition, the Tunnel-Password Attribute SHOULD NOT be returned to an + unauthenticated client; if the corresponding Access-Request packet + did not contain a verified instance of the Signature Attribute [15], + the Access-Accept packet SHOULD NOT contain an instance of the + Tunnel-Password Attribute. + + Tunnel protocols offer various levels of security, from none (e.g., + PPTP) to strong (e.g., IPSec). Note, however, that in the compulsory + tunneling case any security measures in place only apply to traffic + between the tunnel endpoints. In particular, end-users SHOULD NOT + rely upon the security of the tunnel to protect their data; + encryption and/or integrity protection of tunneled traffic MUST NOT + be considered as a replacement for end-to-end security. + +6. IANA Considerations + + This document defines a number of "magic" numbers to be maintained by + the IANA. This section explains the criteria to be used by the IANA + to assign additional numbers in each of these lists. The following + subsections describe the assignment policy for the namespaces 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. + + + + +Zorn, et al. Informational [Page 16] + +RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 + + + [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. + + + +Zorn, et al. Informational [Page 17] + +RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 + + +8. Acknowledgements + + Thanks to Dave Mitton for pointing out a nasty circular dependency in + the original Tunnel-Password attribute definition and (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 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 + + + + + + + + + +Zorn, et al. Informational [Page 18] + +RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 + + + 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 + + + + + + + + + + + + + + + + + +Zorn, et al. Informational [Page 19] + +RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 + + +11. Full Copyright Statement + + 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. + + + + + + + + + + + + + + + + + + + +Zorn, et al. Informational [Page 20] + |