7 Network Working Group G. Zorn
8 Request for Comments: 2868 Cisco Systems, Inc.
9 Updates: RFC 2865 D. Leifer
10 Category: Informational A. Rubens
21 RADIUS Attributes for Tunnel Protocol Support
25 This memo provides information for the Internet community. It does
26 not specify an Internet standard of any kind. Distribution of this
31 Copyright (C) The Internet Society (2000). All Rights Reserved.
35 This document defines a set of RADIUS attributes designed to support
36 the provision of compulsory tunneling in dial-up networks.
40 Many applications of tunneling protocols such as L2TP involve dial-up
41 network access. Some, such as the provision of access to corporate
42 intranets via the Internet, are characterized by voluntary tunneling:
43 the tunnel is created at the request of the user for a specific
44 purpose. Other applications involve compulsory tunneling: the tunnel
45 is created without any action from the user and without allowing the
46 user any choice in the matter. In order to provide this
47 functionality, new RADIUS attributes are needed to carry the
48 tunneling information from the RADIUS server to the tunnel end
49 points; this document defines those attributes. Specific
50 recommendations for, and examples of, the application of these
51 attributes for L2TP can be found in RFC 2809.
58 Zorn, et al. Informational [Page 1]
60 RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
63 2. Specification of Requirements
65 In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
66 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
71 Multiple instances of each of the attributes defined below may be
72 included in a single RADIUS packet. In this case, the attributes to
73 be applied to any given tunnel SHOULD all contain the same value in
74 their respective Tag fields; otherwise, the Tag field SHOULD NOT be
77 If the RADIUS server returns attributes describing multiple tunnels
78 then the tunnels SHOULD be interpreted by the tunnel initiator as
79 alternatives and the server SHOULD include an instance of the
80 Tunnel-Preference Attribute in the set of Attributes pertaining to
81 each alternative tunnel. Similarly, if the RADIUS client includes
82 multiple sets of tunnel Attributes in an Access-Request packet, all
83 the Attributes pertaining to a given tunnel SHOULD contain the same
84 value in their respective Tag fields and each set SHOULD include an
85 appropriately valued instance of the Tunnel-Preference Attribute.
91 This Attribute indicates the tunneling protocol(s) to be used (in
92 the case of a tunnel initiator) or the the tunneling protocol in
93 use (in the case of a tunnel terminator). It MAY be included in
94 Access-Request, Access-Accept and Accounting-Request packets. If
95 the Tunnel-Type Attribute is present in an Access-Request packet
96 sent from a tunnel initiator, it SHOULD be taken as a hint to the
97 RADIUS server as to the tunnelling protocols supported by the
98 tunnel end-point; the RADIUS server MAY ignore the hint, however.
99 A tunnel initiator is not required to implement any of these
100 tunnel types; if a tunnel initiator receives an Access-Accept
101 packet which contains only unknown or unsupported Tunnel-Types,
102 the tunnel initiator MUST behave as though an Access-Reject had
103 been received instead.
105 If the Tunnel-Type Attribute is present in an Access-Request
106 packet sent from a tunnel terminator, it SHOULD be taken to
107 signify the tunnelling protocol in use. In this case, if the
108 RADIUS server determines that the use of the communicated protocol
109 is not authorized, it MAY return an Access-Reject packet. If a
110 tunnel terminator receives an Access-Accept packet which contains
114 Zorn, et al. Informational [Page 2]
116 RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
119 one or more Tunnel-Type Attributes, none of which represent the
120 tunneling protocol in use, the tunnel terminator SHOULD behave as
121 though an Access-Reject had been received instead.
123 A summary of the Tunnel-Type Attribute format is shown below. The
124 fields are transmitted from left to right.
127 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
128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
129 | Type | Length | Tag | Value
130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
141 The Tag field is one octet in length and is intended to provide a
142 means of grouping attributes in the same packet which refer to the
143 same tunnel. Valid values for this field are 0x01 through 0x1F,
144 inclusive. If the Tag field is unused, it MUST be zero (0x00).
147 The Value field is three octets and contains one of the following
148 values, indicating the type of tunnel to be started.
150 1 Point-to-Point Tunneling Protocol (PPTP) [1]
151 2 Layer Two Forwarding (L2F) [2]
152 3 Layer Two Tunneling Protocol (L2TP) [3]
153 4 Ascend Tunnel Management Protocol (ATMP) [4]
154 5 Virtual Tunneling Protocol (VTP)
155 6 IP Authentication Header in the Tunnel-mode (AH) [5]
156 7 IP-in-IP Encapsulation (IP-IP) [6]
157 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [7]
158 9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [8]
159 10 Generic Route Encapsulation (GRE) [9]
160 11 Bay Dial Virtual Services (DVS)
161 12 IP-in-IP Tunneling [10]
170 Zorn, et al. Informational [Page 3]
172 RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
175 3.2. Tunnel-Medium-Type
179 The Tunnel-Medium-Type Attribute indicates which transport medium
180 to use when creating a tunnel for those protocols (such as L2TP)
181 that can operate over multiple transports. It MAY be included in
182 both Access-Request and Access-Accept packets; if it is present in
183 an Access-Request packet, it SHOULD be taken as a hint to the
184 RADIUS server as to the tunnel media supported by the tunnel end-
185 point. The RADIUS server MAY ignore the hint, however.
187 A summary of the Tunnel-Medium-Type Attribute format is given below.
188 The fields are transmitted left to right.
191 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
192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
193 | Type | Length | Tag | Value |
194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
199 65 for Tunnel-Medium-Type
205 The Tag field is one octet in length and is intended to provide a
206 means of grouping attributes in the same packet which refer to the
207 same tunnel. Valid values for this field are 0x01 through 0x1F,
208 inclusive. If the Tag field is unused, it MUST be zero (0x00).
211 The Value field is three octets and contains one of the values
212 listed under "Address Family Numbers" in [14]. For the sake of
213 convenience, a relevant excerpt of this list is reproduced below.
215 1 IPv4 (IP version 4)
216 2 IPv6 (IP version 6)
218 4 HDLC (8-bit multidrop)
220 6 802 (includes all 802 media plus Ethernet "canonical format")
222 8 E.164 (SMDS, Frame Relay, ATM)
226 Zorn, et al. Informational [Page 4]
228 RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
232 10 X.121 (X.25, Frame Relay)
237 15 E.164 with NSAP format subaddress
239 3.3. Tunnel-Client-Endpoint
243 This Attribute contains the address of the initiator end of the
244 tunnel. It MAY be included in both Access-Request and Access-
245 Accept packets to indicate the address from which a new tunnel is
246 to be initiated. If the Tunnel-Client-Endpoint Attribute is
247 included in an Access-Request packet, the RADIUS server should
248 take the value as a hint; the server is not obligated to honor the
249 hint, however. This Attribute SHOULD be included in Accounting-
250 Request packets which contain Acct-Status-Type attributes with
251 values of either Start or Stop, in which case it indicates the
252 address from which the tunnel was initiated. This Attribute,
253 along with the Tunnel-Server-Endpoint and Acct-Tunnel-Connection-
254 ID attributes, may be used to provide a globally unique means to
255 identify a tunnel for accounting and auditing purposes.
257 A summary of the Tunnel-Client-Endpoint Attribute format is shown
258 below. The fields are transmitted from left to right.
261 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
262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
263 | Type | Length | Tag | String ...
264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
267 66 for Tunnel-Client-Endpoint.
282 Zorn, et al. Informational [Page 5]
284 RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
288 The Tag field is one octet in length and is intended to provide a
289 means of grouping attributes in the same packet which refer to the
290 same tunnel. If the value of the Tag field is greater than 0x00
291 and less than or equal to 0x1F, it SHOULD be interpreted as
292 indicating which tunnel (of several alternatives) this attribute
293 pertains. If the Tag field is greater than 0x1F, it SHOULD be
294 interpreted as the first byte of the following String field.
297 The format of the address represented by the String field depends
298 upon the value of the Tunnel-Medium-Type attribute.
300 If Tunnel-Medium-Type is IPv4 (1), then this string is either the
301 fully qualified domain name (FQDN) of the tunnel client machine,
302 or it is a "dotted-decimal" IP address. Conformant
303 implementations MUST support the dotted-decimal format and SHOULD
304 support the FQDN format for IP addresses.
306 If Tunnel-Medium-Type is IPv6 (2), then this string is either the
307 FQDN of the tunnel client machine, or it is a text representation
308 of the address in either the preferred or alternate form [17].
309 Conformant implementations MUST support the preferred form and
310 SHOULD support both the alternate text form and the FQDN format
313 If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a
314 tag referring to configuration data local to the RADIUS client
315 that describes the interface and medium-specific address to use.
317 3.4. Tunnel-Server-Endpoint
321 This Attribute indicates the address of the server end of the
322 tunnel. The Tunnel-Server-Endpoint Attribute MAY be included (as
323 a hint to the RADIUS server) in the Access-Request packet and MUST
324 be included in the Access-Accept packet if the initiation of a
325 tunnel is desired. It SHOULD be included in Accounting-Request
326 packets which contain Acct-Status-Type attributes with values of
327 either Start or Stop and which pertain to a tunneled session.
328 This Attribute, along with the Tunnel-Client-Endpoint and Acct-
329 Tunnel-Connection-ID Attributes [11], may be used to provide a
330 globally unique means to identify a tunnel for accounting and
338 Zorn, et al. Informational [Page 6]
340 RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
343 A summary of the Tunnel-Server-Endpoint Attribute format is shown
344 below. The fields are transmitted from left to right.
347 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
348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
349 | Type | Length | Tag | String ...
350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
353 67 for Tunnel-Server-Endpoint.
359 The Tag field is one octet in length and is intended to provide a
360 means of grouping attributes in the same packet which refer to the
361 same tunnel. If the value of the Tag field is greater than 0x00
362 and less than or equal to 0x1F, it SHOULD be interpreted as
363 indicating which tunnel (of several alternatives) this attribute
364 pertains. If the Tag field is greater than 0x1F, it SHOULD be
365 interpreted as the first byte of the following String field.
368 The format of the address represented by the String field depends
369 upon the value of the Tunnel-Medium-Type attribute.
371 If Tunnel-Medium-Type is IPv4 (1), then this string is either the
372 fully qualified domain name (FQDN) of the tunnel client machine,
373 or it is a "dotted-decimal" IP address. Conformant
374 implementations MUST support the dotted-decimal format and SHOULD
375 support the FQDN format for IP addresses.
377 If Tunnel-Medium-Type is IPv6 (2), then this string is either the
378 FQDN of the tunnel client machine, or it is a text representation
379 of the address in either the preferred or alternate form [17].
380 Conformant implementations MUST support the preferred form and
381 SHOULD support both the alternate text form and the FQDN format
384 If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag
385 referring to configuration data local to the RADIUS client that
386 describes the interface and medium-specific address to use.
394 Zorn, et al. Informational [Page 7]
396 RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
403 This Attribute may contain a password to be used to authenticate
404 to a remote server. It may only be included in an Access-Accept
407 A summary of the Tunnel-Password Attribute format is shown below.
408 The fields are transmitted from left to right.
411 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
412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
413 | Type | Length | Tag | Salt
414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
415 Salt (cont) | String ...
416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
419 69 for Tunnel-Password
425 The Tag field is one octet in length and is intended to provide a
426 means of grouping attributes in the same packet which refer to the
427 same tunnel. Valid values for this field are 0x01 through 0x1F,
428 inclusive. If the value of the Tag field is greater than 0x00 and
429 less than or equal to 0x1F, it SHOULD be interpreted as indicating
430 which tunnel (of several alternatives) this attribute pertains;
431 otherwise, the Tag field SHOULD be ignored.
434 The Salt field is two octets in length and is used to ensure the
435 uniqueness of the encryption key used to encrypt each instance of
436 the Tunnel-Password attribute occurring in a given Access-Accept
437 packet. The most significant bit (leftmost) of the Salt field
438 MUST be set (1). The contents of each Salt field in a given
439 Access-Accept packet MUST be unique.
442 The plaintext String field consists of three logical sub-fields:
443 the Data-Length and Password sub-fields (both of which are
444 required), and the optional Padding sub-field. The Data-Length
445 sub-field is one octet in length and contains the length of the
446 unencrypted Password sub-field. The Password sub-field contains
450 Zorn, et al. Informational [Page 8]
452 RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
455 the actual tunnel password. If the combined length (in octets) of
456 the unencrypted Data-Length and Password sub-fields is not an even
457 multiple of 16, then the Padding sub-field MUST be present. If it
458 is present, the length of the Padding sub-field is variable,
459 between 1 and 15 octets. The String field MUST be encrypted as
460 follows, prior to transmission:
462 Construct a plaintext version of the String field by
463 concatenating the Data-Length and Password sub-fields. If
464 necessary, pad the resulting string until its length (in
465 octets) is an even multiple of 16. It is recommended that zero
466 octets (0x00) be used for padding. Call this plaintext P.
468 Call the shared secret S, the pseudo-random 128-bit Request
469 Authenticator (from the corresponding Access-Request packet) R,
470 and the contents of the Salt field A. Break P into 16 octet
471 chunks p(1), p(2)...p(i), where i = len(P)/16. Call the
472 ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
473 Intermediate values b(1), b(2)...c(i) are required. Encryption
474 is performed in the following manner ('+' indicates
477 b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1)
478 b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2)
482 b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i)
484 The resulting encrypted String field will contain
487 On receipt, the process is reversed to yield the plaintext String.
489 3.6. Tunnel-Private-Group-ID
493 This Attribute indicates the group ID for a particular tunneled
494 session. The Tunnel-Private-Group-ID Attribute MAY be included in
495 the Access-Request packet if the tunnel initiator can pre-
496 determine the group resulting from a particular connection and
497 SHOULD be included in the Access-Accept packet if this tunnel
498 session is to be treated as belonging to a particular private
499 group. Private groups may be used to associate a tunneled session
500 with a particular group of users. For example, it may be used to
501 facilitate routing of unregistered IP addresses through a
506 Zorn, et al. Informational [Page 9]
508 RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
511 particular interface. It SHOULD be included in Accounting-Request
512 packets which contain Acct-Status-Type attributes with values of
513 either Start or Stop and which pertain to a tunneled session.
515 A summary of the Tunnel-Private-Group-ID Attribute format is shown
516 below. The fields are transmitted from left to right.
519 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
520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
521 | Type | Length | Tag | String ...
522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
525 81 for Tunnel-Private-Group-ID.
531 The Tag field is one octet in length and is intended to provide a
532 means of grouping attributes in the same packet which refer to the
533 same tunnel. If the value of the Tag field is greater than 0x00
534 and less than or equal to 0x1F, it SHOULD be interpreted as
535 indicating which tunnel (of several alternatives) this attribute
536 pertains. If the Tag field is greater than 0x1F, it SHOULD be
537 interpreted as the first byte of the following String field.
540 This field must be present. The group is represented by the
541 String field. There is no restriction on the format of group IDs.
543 3.7. Tunnel-Assignment-ID
547 This Attribute is used to indicate to the tunnel initiator the
548 particular tunnel to which a session is to be assigned. Some
549 tunneling protocols, such as PPTP and L2TP, allow for sessions
550 between the same two tunnel endpoints to be multiplexed over the
551 same tunnel and also for a given session to utilize its own
552 dedicated tunnel. This attribute provides a mechanism for RADIUS
553 to be used to inform the tunnel initiator (e.g. PAC, LAC) whether
554 to assign the session to a multiplexed tunnel or to a separate
555 tunnel. Furthermore, it allows for sessions sharing multiplexed
556 tunnels to be assigned to different multiplexed tunnels.
562 Zorn, et al. Informational [Page 10]
564 RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
567 A particular tunneling implementation may assign differing
568 characteristics to particular tunnels. For example, different
569 tunnels may be assigned different QOS parameters. Such tunnels
570 may be used to carry either individual or multiple sessions. The
571 Tunnel-Assignment-ID attribute thus allows the RADIUS server to
572 indicate that a particular session is to be assigned to a tunnel
573 that provides an appropriate level of service. It is expected
574 that any QOS-related RADIUS tunneling attributes defined in the
575 future that accompany this attribute will be associated by the
576 tunnel initiator with the ID given by this attribute. In the
577 meantime, any semantic given to a particular ID string is a matter
578 left to local configuration in the tunnel initiator.
580 The Tunnel-Assignment-ID attribute is of significance only to
581 RADIUS and the tunnel initiator. The ID it specifies is intended
582 to be of only local use to RADIUS and the tunnel initiator. The
583 ID assigned by the tunnel initiator is not conveyed to the tunnel
586 This attribute MAY be included in the Access-Accept. The tunnel
587 initiator receiving this attribute MAY choose to ignore it and
588 assign the session to an arbitrary multiplexed or non-multiplexed
589 tunnel between the desired endpoints. This attribute SHOULD also
590 be included in Accounting-Request packets which contain Acct-
591 Status-Type attributes with values of either Start or Stop and
592 which pertain to a tunneled session.
594 If a tunnel initiator supports the Tunnel-Assignment-ID Attribute,
595 then it should assign a session to a tunnel in the following
598 If this attribute is present and a tunnel exists between the
599 specified endpoints with the specified ID, then the session
600 should be assigned to that tunnel.
602 If this attribute is present and no tunnel exists between the
603 specified endpoints with the specified ID, then a new tunnel
604 should be established for the session and the specified ID
605 should be associated with the new tunnel.
607 If this attribute is not present, then the session is assigned
608 to an unnamed tunnel. If an unnamed tunnel does not yet exist
609 between the specified endpoints then it is established and used
610 for this and subsequent sessions established without the
611 Tunnel-Assignment-ID attribute. A tunnel initiator MUST NOT
612 assign a session for which a Tunnel-Assignment-ID Attribute was
613 not specified to a named tunnel (i.e. one that was initiated by
614 a session specifying this attribute).
618 Zorn, et al. Informational [Page 11]
620 RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
623 Note that the same ID may be used to name different tunnels if
624 such tunnels are between different endpoints.
626 A summary of the Tunnel-Assignment-ID Attribute format is shown
627 below. The fields are transmitted from left to right.
630 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
631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
632 | Type | Length | Tag | String ...
633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
636 82 for Tunnel-Assignment-ID.
642 The Tag field is one octet in length and is intended to provide a
643 means of grouping attributes in the same packet which refer to the
644 same tunnel. If the value of the Tag field is greater than 0x00
645 and less than or equal to 0x1F, it SHOULD be interpreted as
646 indicating which tunnel (of several alternatives) this attribute
647 pertains. If the Tag field is greater than 0x1F, it SHOULD be
648 interpreted as the first byte of the following String field.
651 This field must be present. The tunnel ID is represented by the
652 String field. There is no restriction on the format of the ID.
654 3.8. Tunnel-Preference
658 If more than one set of tunneling attributes is returned by the
659 RADIUS server to the tunnel initiator, this Attribute SHOULD be
660 included in each set to indicate the relative preference assigned
661 to each tunnel. For example, suppose that Attributes describing
662 two tunnels are returned by the server, one with a Tunnel-Type of
663 PPTP and the other with a Tunnel-Type of L2TP. If the tunnel
664 initiator supports only one of the Tunnel-Types returned, it will
665 initiate a tunnel of that type. If, however, it supports both
666 tunnel protocols, it SHOULD use the value of the Tunnel-Preference
667 Attribute to decide which tunnel should be started. The tunnel
668 having the numerically lowest value in the Value field of this
669 Attribute SHOULD be given the highest preference. The values
670 assigned to two or more instances of the Tunnel-Preference
674 Zorn, et al. Informational [Page 12]
676 RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
679 Attribute within a given Access-Accept packet MAY be identical.
680 In this case, the tunnel initiator SHOULD use locally configured
681 metrics to decide which set of attributes to use. This Attribute
682 MAY be included (as a hint to the server) in Access-Request
683 packets, but the RADIUS server is not required to honor this hint.
685 A summary of the Tunnel-Preference Attribute format is shown below.
686 The fields are transmitted from left to right.
689 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
690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
691 | Type | Length | Tag | Value
692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
697 83 for Tunnel-Preference
703 The Tag field is one octet in length and is intended to provide a
704 means of grouping attributes in the same packet which refer to the
705 same tunnel. Valid values for this field are 0x01 through 0x1F,
706 inclusive. If the Tag field is unused, it MUST be zero (0x00).
709 The Value field is three octets in length and indicates the
710 preference to be given to the tunnel to which it refers; higher
711 preference is given to lower values, with 0x000000 being most
712 preferred and 0xFFFFFF least preferred.
714 3.9. Tunnel-Client-Auth-ID
718 This Attribute specifies the name used by the tunnel initiator
719 during the authentication phase of tunnel establishment. The
720 Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the
721 RADIUS server) in the Access-Request packet, and MUST be included
722 in the Access-Accept packet if an authentication name other than
723 the default is desired. This Attribute SHOULD be included in
724 Accounting-Request packets which contain Acct-Status-Type
725 attributes with values of either Start or Stop and which pertain
726 to a tunneled session.
730 Zorn, et al. Informational [Page 13]
732 RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
735 A summary of the Tunnel-Client-Auth-ID Attribute format is shown
736 below. The fields are transmitted from left to right.
739 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
740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
741 | Type | Length | Tag | String ...
742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
745 90 for Tunnel-Client-Auth-ID.
751 The Tag field is one octet in length and is intended to provide a
752 means of grouping attributes in the same packet which refer to the
753 same tunnel. If the value of the Tag field is greater than 0x00
754 and less than or equal to 0x1F, it SHOULD be interpreted as
755 indicating which tunnel (of several alternatives) this attribute
756 pertains. If the Tag field is greater than 0x1F, it SHOULD be
757 interpreted as the first byte of the following String field.
760 This field must be present. The String field contains the
761 authentication name of the tunnel initiator. The authentication
762 name SHOULD be represented in the UTF-8 charset.
764 3.10. Tunnel-Server-Auth-ID
768 This Attribute specifies the name used by the tunnel terminator
769 during the authentication phase of tunnel establishment. The
770 Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the
771 RADIUS server) in the Access-Request packet, and MUST be included
772 in the Access-Accept packet if an authentication name other than
773 the default is desired. This Attribute SHOULD be included in
774 Accounting-Request packets which contain Acct-Status-Type
775 attributes with values of either Start or Stop and which pertain
776 to a tunneled session.
778 A summary of the Tunnel-Server-Auth-ID Attribute format is shown
779 below. The fields are transmitted from left to right.
786 Zorn, et al. Informational [Page 14]
788 RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
792 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
793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
794 | Type | Length | Tag | String ...
795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
798 91 for Tunnel-Server-Auth-ID.
804 The Tag field is one octet in length and is intended to provide a
805 means of grouping attributes in the same packet which refer to the
806 same tunnel. If the value of the Tag field is greater than 0x00
807 and less than or equal to 0x1F, it SHOULD be interpreted as
808 indicating which tunnel (of several alternatives) this attribute
809 pertains. If the Tag field is greater than 0x1F, it SHOULD be
810 interpreted as the first byte of the following String field.
813 This field must be present. The String field contains the
814 authentication name of the tunnel terminator. The authentication
815 name SHOULD be represented in the UTF-8 charset.
817 4. Table of Attributes
819 The following table provides a guide to which of the above attributes
820 may be found in which kinds of packets, and in what quantity.
822 Request Accept Reject Challenge Acct-Request # Attribute
823 0+ 0+ 0 0 0-1 64 Tunnel-Type
824 0+ 0+ 0 0 0-1 65 Tunnel-Medium-Type
825 0+ 0+ 0 0 0-1 66 Tunnel-Client-Endpoint
826 0+ 0+ 0 0 0-1 67 Tunnel-Server-Endpoint
827 0 0+ 0 0 0 69 Tunnel-Password
828 0+ 0+ 0 0 0-1 81 Tunnel-Private-Group-ID
829 0 0+ 0 0 0-1 82 Tunnel-Assignment-ID
830 0+ 0+ 0 0 0 83 Tunnel-Preference
831 0+ 0+ 0 0 0-1 90 Tunnel-Client-Auth-ID
832 0+ 0+ 0 0 0-1 91 Tunnel-Server-Auth-ID
834 The following table defines the meaning of the above table entries.
836 0 This attribute MUST NOT be present in packet.
837 0+ Zero or more instances of this attribute MAY be present in packet.
838 0-1 Zero or one instance of this attribute MAY be present in packet.
842 Zorn, et al. Informational [Page 15]
844 RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
847 5. Security Considerations
849 The Tunnel-Password Attribute may contain information which should
850 only be known to a tunnel endpoint. However, the method used to hide
851 the value of the attribute is such that intervening RADIUS proxies
852 will have knowledge of the contents. For this reason, the Tunnel-
853 Password Attribute SHOULD NOT be included in Access-Accept packets
854 which may pass through (relatively) untrusted RADIUS proxies. In
855 addition, the Tunnel-Password Attribute SHOULD NOT be returned to an
856 unauthenticated client; if the corresponding Access-Request packet
857 did not contain a verified instance of the Signature Attribute [15],
858 the Access-Accept packet SHOULD NOT contain an instance of the
859 Tunnel-Password Attribute.
861 Tunnel protocols offer various levels of security, from none (e.g.,
862 PPTP) to strong (e.g., IPSec). Note, however, that in the compulsory
863 tunneling case any security measures in place only apply to traffic
864 between the tunnel endpoints. In particular, end-users SHOULD NOT
865 rely upon the security of the tunnel to protect their data;
866 encryption and/or integrity protection of tunneled traffic MUST NOT
867 be considered as a replacement for end-to-end security.
869 6. IANA Considerations
871 This document defines a number of "magic" numbers to be maintained by
872 the IANA. This section explains the criteria to be used by the IANA
873 to assign additional numbers in each of these lists. The following
874 subsections describe the assignment policy for the namespaces defined
875 elsewhere in this document.
877 6.1. Tunnel-Type Attribute Values
879 Values 1-12 of the Tunnel-Type Attribute are defined in Section 5.1;
880 the remaining values are available for assignment by the IANA with
883 6.2. Tunnel-Medium-Type Attribute Values
885 Values 1-15 of the Tunnel-Medium-Type Attribute are defined in
886 Section 5.2; the remaining values are available for assignment by the
887 IANA with IETF Consensus [16].
891 [1] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and
892 G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637,
898 Zorn, et al. Informational [Page 16]
900 RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
903 [2] Valencia, A., Littlewood, M. and T. Kolar, T., "Cisco Layer Two
904 Forwarding (Protocol) 'L2F'", RFC 2341, May 1998.
906 [3] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
907 B. Palter, "Layer Two Tunnelling Protocol (L2TP)", RFC 2661,
910 [4] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC
913 [5] Kent, S. and R. Atkinson, "Security Architecture for the
914 Internet Protocol", RFC 2401, November 1998.
916 [6] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
919 [7] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
922 [8] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC
925 [9] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
926 Encapsulation (GRE)", RFC 1701, October 1994.
928 [10] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
930 [11] Zorn, G. and D. Mitton, "RADIUS Accounting Modifications for
931 Tunnel Protocol Support", RFC 2867, June 2000.
933 [12] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
934 Authentication Dial in User Service (RADIUS)", RFC 2865, June
937 [13] Bradner, S., "Key words for use in RFCs to Indicate Requirement
938 Levels", BCP 14, RFC 2119, March 1997.
940 [14] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
943 [15] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC
946 [16] Narten, T. and H. Alvestrand, "Guidelines for writing an IANA
947 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
949 [17] Hinden, R. and S. Deering, "IP Version 6 Addressing
950 Architecture", RFC 2373, July 1998.
954 Zorn, et al. Informational [Page 17]
956 RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
961 Thanks to Dave Mitton for pointing out a nasty circular dependency in
962 the original Tunnel-Password attribute definition and (in no
963 particular order) to Kory Hamzeh, Bertrand Buclin, Andy Valencia,
964 Bill Westfield, Kris Michielsen, Gurdeep Singh Pall, Ran Atkinson,
965 Aydin Edguer, and Bernard Aboba for useful input and review.
969 The RADIUS Working Group can be contacted via the current chair:
972 Livingston Enterprises
974 Pleasanton, California 94588
976 Phone: +1 510 426 0770
977 EMail: cdr@livingston.com
979 10. Authors' Addresses
981 Questions about this memo can also be directed to:
985 500 108th Avenue N.E., Suite 500
986 Bellevue, Washington 98004
989 Phone: +1 425 438 8218
995 Ascend Communications
999 Phone: +1 734 747 6152
1000 EMail: leifer@del.com
1010 Zorn, et al. Informational [Page 18]
1012 RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
1020 Phone: +1 781 687 1329
1021 EMail: John.Shriver@intel.com
1025 Ascend Communications
1029 Phone: +1 313 761 6025
1036 Long Beach, CA 90803
1038 EMail: matt@ipverse.com
1044 1701 Harbor Bay Parkway
1047 Phone: +1 510 769 6001
1048 EMail: igoyret@lucent.com
1066 Zorn, et al. Informational [Page 19]
1068 RFC 2868 RADIUS Tunnel Authentication Attributes June 2000
1071 11. Full Copyright Statement
1073 Copyright (C) The Internet Society (2000). All Rights Reserved.
1075 This document and translations of it may be copied and furnished to
1076 others, and derivative works that comment on or otherwise explain it
1077 or assist in its implementation may be prepared, copied, published
1078 and distributed, in whole or in part, without restriction of any
1079 kind, provided that the above copyright notice and this paragraph are
1080 included on all such copies and derivative works. However, this
1081 document itself may not be modified in any way, such as by removing
1082 the copyright notice or references to the Internet Society or other
1083 Internet organizations, except as needed for the purpose of
1084 developing Internet standards in which case the procedures for
1085 copyrights defined in the Internet Standards process must be
1086 followed, or as required to translate it into languages other than
1089 The limited permissions granted above are perpetual and will not be
1090 revoked by the Internet Society or its successors or assigns.
1092 This document and the information contained herein is provided on an
1093 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1094 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1095 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1096 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1097 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1101 Funding for the RFC Editor function is currently provided by the
1122 Zorn, et al. Informational [Page 20]
projects / freeradius.git / blob