Network Working Group G. Zorn
Internet-Draft Microsoft Corporation
Updates: RFC 2058, RFC 2059 D. Leifer
Category: Standards Track Ascend Communications
<draft-ietf-radius-tunnel-auth-02.txt> John Shriver
Shiva Corporation
July 1997
RADIUS Attributes for Tunnel Protocol Support
11.. 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-02.txt>, and expires February 1, 1997. Please send
comments to the RADIUS Working Group mailing list (ietf-radius@liv-
ingston.com) or to the authors (liefer@del.com, jas@shiva.com and
glennz@microsoft.com).
22.. Abstract
This document defines a set of RADIUS attributes designed to support the
provision of compulsory tunneling in dial-up networks. RADIUS
attributes for both authorization and accounting are specified.
Zorn, Leifer & Shriver [Page 1]
INTERNET-DRAFT RADIUS Tunnel Attributes July 1997
33.. Motivation
Many applications of tunneling protocols such as PPTP and L2TP involve
dial-up network access. Some, such as the provision of secure access to
corporate intranets via the Internet, are characterized by voluntary
tunneling: the tunnel is created at the request of the user for a spe-
cific 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. 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 tunneling, would probably be pro-
vided 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 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 authenti-
cation data to be maintained in a central location, rather than on each
NAS. It makes sense to use RADIUS to centrally administer compulsory
tunneling, 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 accounting server; this document defines those attributes.
Specific recommendations for, and examples of, the application of these
attributes for the L2TP and PPTP protocols can be found in draft-ietf-
radius-tunnel-imp-XX.txt.
44.. Specification of Requirements
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
Zorn, Leifer & Shriver [Page 2]
INTERNET-DRAFT RADIUS Tunnel Attributes July 1997
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
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.
55.. 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.
55..11.. Tunnel-Type
Description
This Attribute indicates the tunneling protocol(s) to be used. 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, it SHOULD be taken as a hint to the RADIUS
server as to the tunnelling protocols 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
Zorn, Leifer & Shriver [Page 3]
INTERNET-DRAFT RADIUS Tunnel Attributes July 1997
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. If the Tag field is unused, it MUST be zero.
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)
2 Layer Two Forwarding (L2F)
3 Layer Two Tunneling Protocol (L2TP)
4 Ascend Tunnel Management Protocol (ATMP)
5 Virtual Tunneling Protocol (VTP)
6 IP Authentication Header in the Tunnel-mode (AH)
7 IP-in-IP Encapsulation (IP-IP)
8 Minimal IP-in-IP Encapsulation (MIN-IP-IP)
9 IP Encapsulating Security Payload in the Tunnel-mode (ESP)
10 Generic Route Encapsulation (GRE)
11 Bay Dial Virtual Services (DVS)
55..22.. 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.
Zorn, Leifer & Shriver [Page 4]
INTERNET-DRAFT RADIUS Tunnel Attributes July 1997
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. If the Tag field is unused, it MUST be zero
(0x0000).
Value
The Value field is three octets nd contains one of the following
values:
1 IP
2 X.25
3 ATM
4 Frame Relay
55..33.. 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 and auditing pur-
poses.
A summary of the Acct-Tunnel-Client-Endpoint Attribute format is
shown below. The fields are transmitted from left to right.
Zorn, Leifer & Shriver [Page 5]
INTERNET-DRAFT RADIUS Tunnel Attributes July 1997
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 | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
66 for Acct-Tunnel-Client-Endpoint.
Length
>= 2
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 IP (1), then this string is either the
fully qualified domain name, or it is a "dotted-decimal" IP
address.
If Tunnel-Medium-Type is X.25 (2), ATM (3), or Frame Relay (4),
this string is a tag referring to configuration data local to the
RADIUS client that describes the interface and medium-specific
address to use.
55..44.. Tunnel-Server-Endpoint
Description
This Attribute indicates the address of the server end of the tun-
nel. 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 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 and
auditing purposes.
A summary of the Tunnel-Server-Endpoint Attribute format is shown
below. The fields are transmitted from left to right.
0 1 2 3
Zorn, Leifer & Shriver [Page 6]
INTERNET-DRAFT RADIUS Tunnel Attributes July 1997
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 Tag field is unused, it MUST be zero
(0x0000).
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 IP (1), then this string is either the
fully qualified domain name, or it is a "dotted-decimal" IP
address.
If Tunnel-Medium-Type is X.25 (2), ATM (3), or Frame Relay (4),
this string is a tag referring to configuration data local to the
RADIUS client that describes the interface and medium-specific
address to use.
55..55.. Acct-Tunnel-Connection
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 and auditing
purposes.
A summary of the Acct-Tunnel-Connection Attribute format is shown
below. The fields are transmitted from left to right.
Zorn, Leifer & Shriver [Page 7]
INTERNET-DRAFT RADIUS Tunnel Attributes July 1997
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 | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
68 for Acct-Tunnel-Connection
Length
>= 2
String
The format of the identifier represented by the String field
depends upon the value of the Tunnel-Type attribute.
55..66.. 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 NAS can pre-determine the group
resulting from a particular connection and SHOULD be included in
the Access-Reply 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 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
Zorn, Leifer & Shriver [Page 8]
INTERNET-DRAFT RADIUS Tunnel Attributes July 1997
?? 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 Tag field is unused, it MUST be zero
(0x0000).
String
This field must be present. The group is represented by the
String field. There is no restriction on the format of group IDs.
66.. 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 Acct-Tunnel-Client-Endpoint
0+ 0+ 0 0 0-1 67 Tunnel-Server-Endpoint
0 0 0 0 0-1 68 Acct-Tunnel-Connection
0+ 0+ 0 0 0-1 ?? Tunnel-Private-Group-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.
77.. Security Considerations
None (submissions welcome).
88.. Acknowledgements
Thanks (in no particular order) to Kory Hamzeh (kory@ascend.com),
Bertrand Buclin (Bertrand.Buclin@att.ch), Dave Mitton (dmitton@baynet-
works.com), Andy Valencia (vandys@cisco.com), Bill Westfield
Zorn, Leifer & Shriver [Page 9]
INTERNET-DRAFT RADIUS Tunnel Attributes July 1997
(billw@cisco.com), Kris Michielsen (kmichiel@cisco.com), Gurdeep Singh
Pall (gurdeep@microsoft.com), Ran Atkinson (rja@home.net) and Bernard
Aboba (aboba@internaut.com) for salient input and review.
99.. 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
1100.. 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
Dory Leifer
Ascend Communications
1678 Broadway
Ann Arbor, MI 48105
Phone: +1 313 747 6152
E-Mail: leifer@ascend.com
John Shriver
Shiva Corporation
28 Crosby Drive
Bedford, MA 01730
Phone: +1 617 270 8329
E-Mail: jas@shiva.com
Zorn, Leifer & Shriver [Page 10]
