home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_q_t
/
draft-ietf-radius-tunnel-auth-01.txt
< prev
next >
Wrap
Text File
|
1997-03-25
|
16KB
|
503 lines
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]