Network Working Group G. Zorn Internet-Draft Microsoft Corporation Updates: RFC 2058, RFC 2059 24 March 1997 Category: Standards Track <draft-ietf-radius-tunnel-auth-01.txt> RADIUS Attributes for Tunnel Protocol Support 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working doc- uments as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as <draft-ietf- radius-tunnel-auth-01.txt>, and expires October 1, 1997. Please send comments to the RADIUS Working Group mailing list (ietf- radius@livingston.com) or to the author (glennz@microsoft.com). 2. Abstract This document specifies a set of RADIUS attributes designed to support the provision of mandatory tunneling in dial-up networks. RADIUS attributes for both authorization and accounting are specified. 3. Introduction Many of the most interesting applications of tunneling protocols such as PPTP [PPTP] and L2TP [L2TP] involve dial-up network access. Some, such as the provision of secure access to corporate intranets via the Inter- net, are characterized by voluntary tunneling: the tunnel is created at Zorn [Page 1]
INTERNET-DRAFT RADIUS Tunnel Attributes March 1997 the request of the user for a specific purpose. Other, potentially more compelling, applications involve compulsory tunneling: the tunnel is created automatically, without any action from the user and more impor- tantly, without allowing the user any choice in the matter. Examples of applications that might be implemented using compulsory tunnels are Internet software upgrade servers, software registration servers and banking services. These are all services which, without compulsory tun- neling, would probably be provided using dedicated networks or at least dedicated network access servers (NAS), since they are characterized by the need to limit user access to specific hosts. Given the existence of widespread support for compulsory tunneling, however, these types of services could be accessed via virtually any Internet service provider (ISP). The most popular means of authorizing dial-up network users today is through the RADIUS protocol. The use of RADIUS allows the dial-up users' authorization and authentication data to be maintained in a central location, rather than being subject to manual configuration. It makes sense to use RADIUS to centrally administer compulsory tunnel- ing, since RADIUS is widely deployed and was designed to carry this type of information. In order to provide this functionality, new RADIUS attributes are needed to carry the tunneling information from the RADIUS server to the NAS and to transfer accounting data from the NAS to the RADIUS server; this document defines those attributes. 4. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. SHOULD NOT This phrase means that there may exist valid reasons in par- ticular circumstances when the particular behavior is acceptable or even useful, but the full implications should Zorn [Page 2]
INTERNET-DRAFT RADIUS Tunnel Attributes March 1997 be understood and the case carefully weighed before imple- menting any behavior described with this label. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. 5. Attributes Multiple instances of each of the attributes defined below may be included in a single RADIUS packet. If this is done, the attributes to be applied to each distinct tunnel SHOULD all contain the same value in their respective Tag fields. 5.1. Tunnel-Type Description This Attribute indicates the tunneling protocol(s) to be used. 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 mediums supported by the NAS. The RADIUS server MAY ignore the hint, however. A NAS is not required to implement any of these tunnel types; If a NAS receives an Access-Accept packet which contains only unknown or unsupported Tunnel-Types, the NAS MUST 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 64 for Tunnel-Type Length Zorn [Page 3]
INTERNET-DRAFT RADIUS Tunnel Attributes March 1997 Always 4. 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. Value The Value field is one octet and contains one of the following values, indicating the type of tunnel to be started. 1 PPTP 2 L2F 3 L2TP 4 ATMP 5 VTP 6 AH 7 IP-IP 5.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 mediums supported by the NAS. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65 for Tunnel-Medium-Type Zorn [Page 4]
INTERNET-DRAFT RADIUS Tunnel Attributes March 1997 Length 4 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. Value The Value field is one octet. 1 IP 2 X.25 3 ATM 4 Frame Relay 5.3. Acct-Tunnel-Client-Endpoint Description This Attribute contains the address of the NAS end of the tunnel. It SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop. 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 purposes. A summary of the Acct-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 Acct-Tunnel-Client-Endpoint. Length >= 3 Zorn [Page 5]
INTERNET-DRAFT RADIUS Tunnel Attributes March 1997 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. String The format of the address represented by the String field depends upon the value of the Tunnel-Medium-Type attribute. 5.4. Tunnel-Server-Endpoint Description This Attribute indicates the address of the server end of the tun- nel. It SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop. This Attribute, along with the Acc-Tunnel-Client-Endpoint and Acct-Tunnel-Connection-ID attributes, may be used to provide a globally unique means to identify a tunnel for accounting pur- poses. 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. String Zorn [Page 6]
INTERNET-DRAFT RADIUS Tunnel Attributes March 1997 The format of the address represented by the String field depends upon the value of the Tunnel-Medium-Type attribute. 5.5. Acct-Tunnel-Connection-ID Description This Attribute indicates the identifier assigned to the call. It SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop. This attribute, along with the Acct-Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes, may be used to provide a glob- ally unique means to identify a call for accounting purposes. A summary of the Acct-Tunnel-Connection-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 68 for Acct-Tunnel-Connection-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. String The format of the identifier represented by the String field depends upon the value of the Tunnel-Type attribute. Zorn [Page 7]
INTERNET-DRAFT RADIUS Tunnel Attributes March 1997 5.6. Tunnel-Password Description This Attribute may contain a key or password. 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 | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 69 for Tunnel-Password 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. String If this field is present, it MUST be hidden in the same fashion as the User-Password Attribute, with the exception that the Response- Authenticator MUST be used in place of the Request-Authenticator (see RFC 2058, Section 5.2). 6. Security Considerations The Tunnel-Password Attribute may contain information which should only be known to a tunnel endpoint. The method used to hide the value of the attribute, however, 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. Zorn [Page 8]
INTERNET-DRAFT RADIUS Tunnel Attributes March 1997 7. Acknowledgements Thanks to Kory Hamzeh of Ascend Communications; Bertrand Buclin of AT&T Laboratries Europe; Andy Valencia, Bill Westfield and Kris Michielsen of cisco Systems; amd Gurdeep Singh Pall and Bernard Aboba of Microsoft Corporation for salient input and review. 8. Chair's Address The RAQDIUS Working Group can be contacted via the current chair: Carl Rigney Livingston Enterprises 6920 Koll Center Parkway, Suite 220 Pleasanton, California 94566 Phone: +1 510 426 0770 E-Mail: cdr@livingston.com 9. Author's Address Questions about this memo can also be directed to: Glen Zorn Microsoft Corporation One Microsoft Way Redmond, Washington 98052 Phone: +1 206 703 1559 E-Mail: glennz@microsoft.com Zorn [Page 9]
