RADEXT J. Arkko
Internet-Draft Ericsson
Expires: August 15, 2005 P. Eronen
Nokia
February 14, 2005
Policy Decisions for Users with Access to Multiple Services
draft-arkko-radext-multi-service-decisions-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 15, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This draft relates to the use of Authentication, Authorization, and
Accounting (AAA) where the same user credentials can be used on many
different types of devices, ranging from wireless access points to
Virtual Private Network (VPN) gateways. More specifically, this
draft discusses how AAA servers can determine what incoming service
was provided, and how they can use this information as a basis for
Arkko & Eronen Expires August 15, 2005 [Page 1]
Internet-Draft Multi-Service Decisions February 2005
policy decisions.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Deployment Considerations in a Roaming Setting . . . 4
2.2 Service-Type Attribute . . . . . . . . . . . . . . . 4
2.3 NAS-Port-Type Attribute . . . . . . . . . . . . . . 5
2.4 Tunnel-Type and Tunnel-Medium-Type Attributes . . . 5
2.5 Extending Tunnel Attributes . . . . . . . . . . . . 7
3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1 Normative References . . . . . . . . . . . . . . . . . 11
5.2 Informative References . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
Arkko & Eronen Expires August 15, 2005 [Page 2]
Internet-Draft Multi-Service Decisions February 2005
1. Introduction
This draft relates to the use of Authentication, Authorization, and
Accounting (AAA) where the same user credentials can be used on many
different types of devices, ranging from wireless access points to
virtual network gateways. For instance, a user may have credentials
that can be used in the Extensible Authentication Protocol (EAP) [5].
Such credentials could be used to access a 802.11 Wireless LAN,
PANA-based DSL [7], or to gain VPN access via a gateway that supports
IKEv2 [6].
Specifically, this draft discusses how AAA servers can determine what
service was provided. This is important in some situations where,
for policy reasons, the type of the service needs to be known. Such
policy may be based on, for instance, commercial or security
considerations.
For example, the AAA server may wish to deny 802.1X wireless LAN
access from a service for a specific subscriber, but allow the same
subscriber to use IKEv2-based VPNs. The attributes discussed in this
document will provide this information to the AAA server. The AAA
server uses this information at the moment of the authorization
decision, and once this decision is taken, the rest of the exchange
is not affected.
Earlier work in this space includes [9] and [10], to which this work
is in debt.
Arkko & Eronen Expires August 15, 2005 [Page 3]
Internet-Draft Multi-Service Decisions February 2005
2. Discussion
2.1 Deployment Considerations in a Roaming Setting
AAA servers may have full knowledge of what services specific NASes
offer. For instance, a AAA server may know that a NAS with one
address and a shared secret is a Wireless LAN access point, and
another NAS with a different address and secret is a VPN gateway.
This information can be configured in the AAA server and used for
making policy decisions. Generally, such configuration is, however,
infeasible in a roaming setting, due to the large number of potential
NASes and the different organizations involved.
There can be some situations where this is still possible even with
roaming. For instance, if the roaming network provides only Wireless
LAN access, and the operator's own device provides VPN access then it
is always possible to distinguish the two.
2.2 Service-Type Attribute
This attribute represents the highest level of service provided by a
NAS. The current allocation is shown below:
1 Login
2 Framed
3 Callback Login
4 Callback Framed
5 Outbound
6 Administrative
7 NAS Prompt
8 Authenticate Only
9 Callback NAS Prompt
10 Call Check
11 Callback Administrative
12 Voice
13 Fax
14 Modem Relay
15 IAPP-Register [IEEE 802.11f]
16 IAPP-AP-Check [IEEE 802.11f]
17 Authorize Only [RFC3576]
Most current network access falls under the "2 - Framed" value. New
values could be allocated, but generally it is more appropriate to
allocate new NAS-Port-Type values than a complete new Service-Type
value. It is also expected that implementations may deal with
Service-Type attribute in a special way, so changes to this attribute
would lead to code impacts.
Arkko & Eronen Expires August 15, 2005 [Page 4]
Internet-Draft Multi-Service Decisions February 2005
2.3 NAS-Port-Type Attribute
The current assignment of NAS-Port-Type values is shown below:
0 Async
1 Sync
2 ISDN Sync
3 ISDN Async V.120
4 ISDN Async V.110
5 Virtual
6 PIAFS
7 HDLC Clear Channel
8 X.25
9 X.75
10 G.3 Fax
11 SDSL - Symmetric DSL
12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase
Modulation
13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone
14 IDSL - ISDN Digital Subscriber Line
15 Ethernet
16 xDSL - Digital Subscriber Line of unknown type
17 Cable
18 Wireless - Other
19 Wireless - IEEE 802.11
20 Token-Ring
21 FDDI
22 Wireless - CDMA2000
23 Wireless - UMTS
24 Wireless - 1X-EV
25 IAPP
26 FTTP - Fiber to the Premises
This attribute can in general distinguish a number of different
physical port types. New port types can be allocated easily as new
access technologies come into use.
Distinguishing different virtual ports is not possible, however.
This is because just one value (5 - Virtual) has been allocated for
them.
2.4 Tunnel-Type and Tunnel-Medium-Type Attributes
One option is to use tunnel attributes are defined in RFC 2868 [3].
They make it possible to distinguish between different types of
tunnel types and media over which the tunnel is run. The current
tunnel types are:
Arkko & Eronen Expires August 15, 2005 [Page 5]
Internet-Draft Multi-Service Decisions February 2005
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)
12 IP-in-IP Tunneling
13 Virtual LANs (VLAN) [RFC3580]
And the medium types are:
1 IPv4 (IP version 4)
2 IPv6 (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 (POTS)
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
Together with the NAS-Port-Type attribute, these attributes make it
possible to distinguish, for instance, between IPsec- and L2TP-based
tunnels. Furthermore, it is possible to separate the medium over
which the tunnel runs from the tunnel itself. These attributes are
today primarily used to control mandatory tunneling from a NAS (i.e.,
from NAS to somewhere else, not between NAS and the client).
RFC 2868 does have some limitations, however. Some of these
limitations are related to the use of both voluntary and mandatory
tunneling (that is, both terminating a tunnel and initiating a tunnel
from the NAS for the same user). This is primarily because the role
of the tunnel is not explicitly communicated. It is expected that
the AAA server knows (upon receiving an Access-Request with a tunnel
attribute) that a particular NAS is either offering an option for
Arkko & Eronen Expires August 15, 2005 [Page 6]
Internet-Draft Multi-Service Decisions February 2005
mandatory tunneling or is already terminating a voluntary tunneling.
Similarly, if the NAS needs both types of tunnels simultaneously, the
attributes can not distinguish between them. For instance, if a NAS
has terminated an IPsec tunnel, the AAA server can not request it to
create another mandatory tunnel to another location. This is because
the NAS would interpret such request (in Access-Accept) as a
rejection of its incoming IPsec tunnel. This prevents, for instance,
the use of a AAA server to control which VLAN an incoming VPN users
should be directed to.
Another limitation is that RFC 2868 attributes do not explicitly
distinguish between different key management mechanisms for tunnels.
We do not know, however, to how large extent other than the default
key management mechanisms are being employed. For instance, it seems
fairly safe to assume that either IKEv1 [8] or IKEv2 [6] is used to
key IPsec-based VPNs. Other alternatives do exist, however.
2.5 Extending Tunnel Attributes
Generally, the RFC 2868 tunneling attributes are sufficient when
tunneling is either all-voluntary or all-mandatory, so that at least
for the same user, there is no question about which type of tunneling
information is being communicated.
Where this condition is not met, some protocol extensions may be
needed. Two possible extensions are discussed below:
New attributes can be defined to represent the voluntary tunneling
behavior. For instance, a new attribute attribute could represent
the virtual port type:
NAS-Virtual-Port-Type
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where
Value = IPsec, L2TP, and so on
A new attribute can be defined to distinguish between voluntary and
Arkko & Eronen Expires August 15, 2005 [Page 7]
Internet-Draft Multi-Service Decisions February 2005
mandatory tunnels. For instance:
Tunnel-Type-Direction
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where
Value = Voluntary, i.e., incoming (0)
Mandatory, i.e., outgoing (1)
This would allow the use of existing Tunnel-Type attributes for also
voluntary tunneling, without causing ambiquity.
Arkko & Eronen Expires August 15, 2005 [Page 8]
Internet-Draft Multi-Service Decisions February 2005
3. Recommendations
It is suggested that new physical interface types lead to the
allocation of new NAS-Port-Type values.
New higher-layer network access mechanisms, such as PANA, can acquire
either a new NAS-Port-Type value or new Tunnel-Type value. In the
former case, however, existing DSL or Ethernet port type allocations
are not used. This would also create an additional need to have
combinations represented in the port types, e.g., PANA over Ethernet
and PANA over DSL. As a result, it is recommended that a new
Tunnel-Type value, or another similar attribute be used for that
purpose. (Intuitively, PANA is not a "tunnel".)
Existing RFC 2868 attributes are sufficient for some situations.
Their use in a situation where both voluntary and mandatory tunneling
may be present is problematic, however. Some potential remedies for
this were listed earlier.
Arkko & Eronen Expires August 15, 2005 [Page 9]
Internet-Draft Multi-Service Decisions February 2005
4. Security Considerations
Security is one of the reasons for attempting to carry information
about the type of provided virtual service to the AAA servers, as
discussed in Section 1.
This draft does not add any new protocol mechanisms, and as such it
does not add new security issues beyond those that already exist for
general AAA usage. See [2] and [4] for further discussion.
Arkko & Eronen Expires August 15, 2005 [Page 10]
Internet-Draft Multi-Service Decisions February 2005
5. References
5.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
[3] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
2868, June 2000.
[4] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[5] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
June 2004.
[6] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-17 (work in progress), October 2004.
[7] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin,
"Protocol for Carrying Authentication for Network Access
(PANA)", draft-ietf-pana-pana-05 (work in progress), July 2004.
5.2 Informative References
[8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[9] Mariblanca, D., "EAP lower layer attributes for AAA protocols",
draft-mariblanca-aaa-eap-lla-01 (work in progress), June 2004.
[10] Lebovitz, G., "EAP lower layer attributes for AAA protocols",
draft-lebovitz-ipsec-scalable-ikev2cp-00.txt (unpublished)
(work in progress), March 2003.
Arkko & Eronen Expires August 15, 2005 [Page 11]
Internet-Draft Multi-Service Decisions February 2005
Authors' Addresses
Jari Arkko
Ericsson
Jorvas FI-02420
Finland
EMail: jari.arkko@ericsson.com
Pasi Eronen
Nokia Research Center
P.O. Box 407
FI-00045 Nokia Group
Finland
EMail: pasi.eronen@nokia.com
Arkko & Eronen Expires August 15, 2005 [Page 12]
Internet-Draft Multi-Service Decisions February 2005
Appendix A. Contributors
Glen Zorn and David Mariblanca were members of our team, and
contributed greatly to the discussions.
Arkko & Eronen Expires August 15, 2005 [Page 13]
Internet-Draft Multi-Service Decisions February 2005
Appendix B. Acknowledgements
We would like to thank Dave Nelson and Bernard Aboba for interesting
discussions in this problem space.
Arkko & Eronen Expires August 15, 2005 [Page 14]
Internet-Draft Multi-Service Decisions February 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Arkko & Eronen Expires August 15, 2005 [Page 15]