One document matched: draft-ietf-radius-tunnel-auth-04.txt
Differences from draft-ietf-radius-tunnel-auth-03.txt
Network Working Group G. Zorn
Internet-Draft Microsoft Corporation
Updates: RFC 2138 D. Leifer
Category: Standards Track A. Rubens
<draft-ietf-radius-tunnel-auth-04.txt> Ascend Communications
J. Shriver
Shiva Corporation
November 1997
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-04.txt>, and expires May 25, 1997. Please send com-
ments to the RADIUS Working Group mailing list (ietf-radius@liv-
ingston.com) or to the authors (leifer@del.com, acr@del.com,
jas@shiva.com and glennz@microsoft.com).
2. Abstract
This document defines a set of RADIUS attributes designed to support the
provision of compulsory tunneling in dial-up networks.
Zorn, Leifer, Rubens & Shriver [Page 1]
INTERNET-DRAFT RADIUS Tunnel Attributes November 1997
3. 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 tunnel initiator; this document defines those
attributes. Specific recommendations for, and examples of, the applica-
tion of these attributes for the L2TP and PPTP protocols can be found in
draft-ietf-radius-tunnel-imp-XX.txt.
4. 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].
5. 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 alterna-
tives and the server SHOULD include an instance of the Tunnel-Preference
Attribute in the set of Attributes pertaining to each alternative
Zorn, Leifer, Rubens & Shriver [Page 2]
INTERNET-DRAFT RADIUS Tunnel Attributes November 1997
tunnel. Similarly, if the RADIUS client includes multiple sets of tun-
nel Attributes in an Access-Request packet, all the Attributes pertain-
ing to a given tunnel SHOULD contain the same value in their respective
Tag fiels and each set SHOULD include an appropriately valued instance
of the Tunnel-Preference Attribute.
5.1. 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 tunnel ini-
tiator; 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 con-
tains only unknown or unsupported Tunnel-Types, the tunnel initia-
tor 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Value
The Value field is three octets and contains one of the following
values, indicating the type of tunnel to be started.
Zorn, Leifer, Rubens & Shriver [Page 3]
INTERNET-DRAFT RADIUS Tunnel Attributes November 1997
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) [5]
6 IP Authentication Header in the Tunnel-mode (AH) [6]
7 IP-in-IP Encapsulation (IP-IP) [7]
8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [8]
9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [9]
10 Generic Route Encapsulation (GRE) [10]
11 Bay Dial Virtual Services (DVS)
12 IP-in-IP Tunneling [11]
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 tunnel
initiator. 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 (0x0000).
Zorn, Leifer, Rubens & Shriver [Page 4]
INTERNET-DRAFT RADIUS Tunnel Attributes November 1997
Value
The Value field is three octets and contains one of the values
listed under "Address Family Numbers" in [15]. For the sake of
convenience, a relevant excerpt of this list is reproduced below.
1 IP (IP version 4)
2 IP6 (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
8 E.164 (SMDS, Frame Relay, ATM)
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
5.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. It SHOULD be included in Accounting-Request pack-
ets 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 tun-
nel 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zorn, Leifer, Rubens & Shriver [Page 5]
INTERNET-DRAFT RADIUS Tunnel Attributes November 1997
Type
66 for Tunnel-Client-Endpoint.
Length
>= 2
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 less than or equal to
0x1F, it SHOULD be interpreted as indicating which tunnel (of sev-
eral alternatives) this attribute pertains; otherwise, 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 IP (1) or IP6 (2), then this string is
either the fully qualified domain name 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 not IP or IP6, this string is a tag
referring to configuration data local to the RADIUS client that
describes the interface and medium-specific address to use.
5.4. 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 Tunnel-Client-Endpoint and Acct-
Tunnel-Connection-ID Attributes [12], 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.
Zorn, Leifer, Rubens & Shriver [Page 6]
INTERNET-DRAFT RADIUS Tunnel Attributes November 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 | 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. Valid values for this field are 0x01 through 0x1F,
inclusive. If the value of the Tag field is less than or equal to
0x1F, it SHOULD be interpreted as indicating which tunnel (of sev-
eral alternatives) this attribute pertains; otherwise, 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 IP (1) or IP6 (2), then this string is
either the fully qualified domain name 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 not IP or IP6, this string is a tag
referring to configuration data local to the RADIUS client that
describes the interface and medium-specific address to use.
5.5. 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
Zorn, Leifer, Rubens & Shriver [Page 7]
INTERNET-DRAFT RADIUS Tunnel Attributes November 1997
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag | Salt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Salt (cont) | 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. Valid values for this field are 0x01 through 0x1F,
inclusive. If the value of the Tag field is less than or equal to
0x1F, it SHOULD be interpreted as indicating which tunnel (of sev-
eral alternatives) this attribute pertains; otherwise, it 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
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 concate-
nating 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.
Zorn, Leifer, Rubens & Shriver [Page 8]
INTERNET-DRAFT RADIUS Tunnel Attributes November 1997
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 concatena-
tion):
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.
5.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-deter-
mine 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 particu-
lar group of users. For example, it may be used to facilitate
routing of unregistered IP addresses through a particular inter-
face. 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zorn, Leifer, Rubens & Shriver [Page 9]
INTERNET-DRAFT RADIUS Tunnel Attributes November 1997
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. Valid values for this field are 0x01 through 0x1F,
inclusive. If the value of the Tag field is less than or equal to
0x1F, it SHOULD be interpreted as indicating which tunnel (of sev-
eral alternatives) this attribute pertains; otherwise, 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.
5.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 tun-
neling 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 dedi-
cated 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 tun-
nel. Furthermore, it allows for sessions sharing multiplexed tun-
nels to be assigned to different multiplexed tunnels.
A particular tunneling implementation may assign differing charac-
teristics 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 pro-
vides 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 initia-
tor 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.
Zorn, Leifer, Rubens & Shriver [Page 10]
INTERNET-DRAFT RADIUS Tunnel Attributes November 1997
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-Sta-
tus-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 man-
ner:
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 Tun-
nel-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).
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zorn, Leifer, Rubens & Shriver [Page 11]
INTERNET-DRAFT RADIUS Tunnel Attributes November 1997
Type
?? 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. Valid values for this field are 0x01 through 0x1F,
inclusive. If the value of the Tag field is less than or equal to
0x1F, it SHOULD be interpreted as indicating which tunnel (of sev-
eral alternatives) this attribute pertains; otherwise, 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.
5.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 ini-
tiator 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
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 pack-
ets, 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
Zorn, Leifer, Rubens & Shriver [Page 12]
INTERNET-DRAFT RADIUS Tunnel Attributes November 1997
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Tag | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
?? 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.
Value
The Value field is three octets in length and indicates the pref-
erence to be given to the tunnel to which it refers; higher pref-
erence is given to lower values, with 0x000000 being most pre-
ferred and 0xFFFFFF least preferred.
6. 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 ?? Tunnel-Assignment-ID
0+ 0+ 0 0 0 ?? Tunnel-Preference
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, Leifer, Rubens & Shriver [Page 13]
INTERNET-DRAFT RADIUS Tunnel Attributes November 1997
7. 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 [16], the Access-Accept packet
SHOULD NOT contain an instance of the Tunnel-Password Attribute.
8. References
[1] Hamzeh, et. al., "Point-to-Point Tunneling Protocol -- PPTP",
draft-ietf-pppext-pptp-02.txt (work in progress), July 1997
[2] Valencia, Littlewood and Kolar, "Layer Two Forwarding (Protocol)
'L2F'", draft-valencia-l2f-00.txt (work in progress), October 1997
[3] Hamzeh, et. al., "Layer Two Tunnelling Protocol (L2TP)", work in
progress, draft-ietf-pppext-l2tp-08.txt, Movember 1997
[4] Hamzeh, "Ascend Tunnel Management Protocol - ATMP", RFC 2107,
February 1997
[5] Calhoun and Wong, "Virtual Tunneling Protocol (VTP)", draft-cal-
houn-vtp-protocol-00.txt (work in progress), July 1996 (expired)
[6] Kent and Atkinson, "IP Authentication Header", draft-ietf-ipsec-
auth-header-02.txt (work in progress), October 1997
[7] Perkins, "IP Encapsulation within IP", RFC 2003, October 1996
[8] Perkins, "Minimal Encapsulation within IP", RFC 2004, October 1996
[9] Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1827,
August 1995
[10] Hanks, et. al., "Generic Routing Encapsulation (GRE)", RFC 1701,
October 1994
[11] Simpson, "IP in IP Tunneling", RFC 1853, October 1995
[12] Zorn and Mitton, "RADIUS Accounting Modifications for Tunnel Proto-
col Support", draft-ietf-radius-tunnel-acct-00.txt (work in
Zorn, Leifer, Rubens & Shriver [Page 14]
INTERNET-DRAFT RADIUS Tunnel Attributes November 1997
progress), November 1997
[13] Rigney, et. al., "Remote Authentication Dialin User Service
(RADIUS)", RFC 2138, April 1997
[14] Bradner, "Key words for use in RFCs to Indicate Requirement Lev-
els", RFC 2119, March 1997
[15] Reynolds and Postel, "Assigned Numbers", STD 2, RFC 1700, October
1994
[16] Rigney and Willats, "RADIUS Extensions", draft-ietf-radius-
ext-01.txt (work in progress), September 1997
9. Acknowledgements
Thanks to Dave Mitton (dmitton@baynetworks.com) for pointing out a nasty
circular dependency in the original Tunnel-Password attribute definition
and (in no particular order) to Kory Hamzeh (kory@ascend.com), Bertrand
Buclin (Bertrand.Buclin@att.ch), Dave Mitton (dmitton@baynetworks.com),
Andy Valencia (vandys@cisco.com), Bill Westfield (billw@cisco.com), Kris
Michielsen (kmichiel@cisco.com), Gurdeep Singh Pall (gur-
deep@microsoft.com), Ran Atkinson (rja@home.net), Aydin Edguer
(edguer@MorningStar.com) and Bernard Aboba (aboba@internaut.com) for
useful input and review.
10. 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
E-Mail: cdr@livingston.com
11. Authors' Addresses
Questions about this memo can also be directed to:
Glen Zorn
Microsoft Corporation
One Microsoft Way
Zorn, Leifer, Rubens & Shriver [Page 15]
INTERNET-DRAFT RADIUS Tunnel Attributes November 1997
Redmond, Washington 98052
Phone: +1 425 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 781 687 1329
E-Mail: jas@shiva.com
Allan Rubens
Ascend Communications
1678 Broadway
Ann Arbor, MI 48105
Phone: +1 313 761 6025
E-Mail: acr@del.com
12. Expiration Date
This memo is filed as <draft-ietf-radius-tunnel-auth-04.txt>, and
expires May 25, 1997.
Zorn, Leifer, Rubens & Shriver [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-22 06:01:15 |