Internet DRAFT - draft-arkko-radext-multi-service-decisions
draft-arkko-radext-multi-service-decisions
RADEXT J. Arkko
Internet-Draft Ericsson
Expires: April 27, 2006 P. Eronen
Nokia
J. Korhonen
Teliasonera
October 24, 2005
Policy Decisions for Users with Access to Multiple Services
draft-arkko-radext-multi-service-decisions-02
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 April 27, 2006.
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. This draft discusses how to
use existing AAA and authentication protocols and extensions to
Arkko, et al. Expires April 27, 2006 [Page 1]
Internet-Draft Multi-Service Decisions October 2005
determine what service was provided, agree about this among all the
participating parties, and use this information as a basis for policy
decisions.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements language . . . . . . . . . . . . . . . . . . . . 4
3. Policy Decisions . . . . . . . . . . . . . . . . . . . . . . . 5
4. Deployment Considerations in a Roaming Setting . . . . . . . . 6
5. Ensuring Parties Have the Same Information . . . . . . . . . . 7
6. Determining the Type of Service . . . . . . . . . . . . . . . 8
6.1. Service-Type Attribute . . . . . . . . . . . . . . . 8
6.2. NAS-Port-Type Attribute . . . . . . . . . . . . . . 8
6.3. Tunnel-Type and Tunnel-Medium-Type Attributes . . . 10
6.4. Discussion . . . . . . . . . . . . . . . . . . . . . 11
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . 14
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 16
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Arkko, et al. Expires April 27, 2006 [Page 2]
Internet-Draft Multi-Service Decisions October 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) [6].
Such credentials could be used to access a 802.11 Wireless LAN,
802.16 networks, PANA-based DSL [8], or to gain VPN access via a
gateway that supports IKEv2 [7].
Among other things, 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.
Similarly, it can be useful to ensure that the client, NAS, and AAA
server all know what service was provided, or even ensure that the
client knows the NAS has provided a service that the AAA server has
authorized.
Earlier work in this space includes [11], [12], and [10] to which
this work is in debt.
Arkko, et al. Expires April 27, 2006 [Page 3]
Internet-Draft Multi-Service Decisions October 2005
2. Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [1].
Arkko, et al. Expires April 27, 2006 [Page 4]
Internet-Draft Multi-Service Decisions October 2005
3. Policy Decisions
Security-related policies can be required when potential service
types have different perceived security levels. For instance,
network access using a particular link layer type might be considered
insecure, while other link layer types or VPN access would be secure.
A more subtle need knowledge about the provided service relates to
possibility of compromised nodes. In a large distributed network it
is often desirable that the compromise of a single node does not
affect other nodes. For instance, it would be desirable that a
compromised 802.11 access point can not be turned into a company VPN
gateway.
An example of a business-related policy is a subscription that
applies only to a particular type of an access.
Arkko, et al. Expires April 27, 2006 [Page 5]
Internet-Draft Multi-Service Decisions October 2005
4. 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.)
Due to these problems, we typically rely on information transferred
in the AAA protocols to make policy decisions. For instance, many
service parameters (interface speed, type) are carried in the
protocols and an informed decision is possible. Nevertheless, as
discussed in [10], such information is vulnerable to lying NASes.
Arkko, et al. Expires April 27, 2006 [Page 6]
Internet-Draft Multi-Service Decisions October 2005
5. Ensuring Parties Have the Same Information
Where EAP is used, [10] can provide a channel that ensures the NAS
has provided the same information to the client and the AAA server.
This solution requires support from EAP methods. As a result, it may
not always apply, if an EAP method that does not support it is used.
While the specification supports most popular EAP methods, no
deployment of this solution is known to date.
Arkko, et al. Expires April 27, 2006 [Page 7]
Internet-Draft Multi-Service Decisions October 2005
6. Determining the Type of Service
6.1. 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.
6.2. NAS-Port-Type Attribute
The current assignment of NAS-Port-Type values is shown below:
Arkko, et al. Expires April 27, 2006 [Page 8]
Internet-Draft Multi-Service Decisions October 2005
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, for instance between 802.11 Wireless LANs (value
19) and Token Ring (20) [4]. 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.
Some additional values have also been suggested in [13]:
30 PPPoA (PPP over ATM [RFC3336])
31 PPPoEoA (PPP over Ethernet [RFC2516] over ATM)
32 PPPoEoE (PPP over Ethernet [RFC2516] over Ethernet
33 PPPoEoVLAN (PPP over Ethernet [RFC2516] over VLAN)
34 PPPoEoQinQ (PPP over Ethernet [RFC2516] over IEEE
802.1QinQ)
38 IPSEC [RFC2411]
Arkko, et al. Expires April 27, 2006 [Page 9]
Internet-Draft Multi-Service Decisions October 2005
6.3. Tunnel-Type and Tunnel-Medium-Type Attributes
Tunnel attributes defined in RFC 2868 [3] make it possible to
distinguish between different types of tunnel types and media over
which the tunnel is run. The current tunnel types are:
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).
Note that the role of the tunnel (incoming or outgoing) is not
Arkko, et al. Expires April 27, 2006 [Page 10]
Internet-Draft Multi-Service Decisions October 2005
explicitly communicated. If this information is needed, it can be
recovered by comparing the NAS-IP-Address attribute to the Tunnel-
Client-Endpoint and Tunnel-Server-Endpoint addresses. This
comparison assumes, however, that the addressing domains are the
same, which may not always be the case. For instance, a typical VPN
gateway would provide a Tunnel-Server-Endpoint of its public IP
address and a NAS-IP-Address of its internal network interface.
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 [9] or IKEv2 [7] is used to
key IPsec-based VPNs. Other alternatives do exist, however.
6.4. Discussion
As long as a suitable NAS-Port-Type value exists, it can be reliably
be used to determine the type of the service. What remains is
distinguishing different virtual services from each other. Both NAS-
Port-Type value additions (see [13] and tunnel attribute approaches
have been suggested.
One open issue is whether the proposed NAS-Port-Type value "IPsec"
should be used instead of "Virtual" when using an IPsec-based virtual
service. Another question is under what assumptions the tunnel
attribute support is sufficient when both incoming and outgoing
tunnels are considered.
Arkko, et al. Expires April 27, 2006 [Page 11]
Internet-Draft Multi-Service Decisions October 2005
7. 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". The question of whether PANA
and other "layer 2.5" solutions should be categorized as tunnels
deserves some discussion.)
Existing RFC 2868 attributes are sufficient for some situations, but
not all. We have not determined whether the remaining cases are
important enough to need specific support. If such support would be
needed, one option would be to provide additional distinguishing
tunnel attributes, such as tunnel role. Another approach would be to
provide an independent attribute model.
A common scenario is where both physical (e.g., 802.11) access and a
VPN service is being deployed using the same credential. One
approach for distinguishing these two in an AAA transaction is to use
the values NAS-Port-Type = 5 (Virtual ) or NAS-Port-Type = 38 (IPSEC)
to represent a VPN service, and all other values to represent a
physical access. Value 38 is currently not defined in any RFC or
even active draft, and hence only value 5 would be a practical
choice. However, this approach is not guaranteed to operate
correctly when types of services are being developed.
It has been suggested that this approach could in addition use of
tunnel attributes, but this is not recommended due the overloading of
their semantics for both incoming and outgoing tunnels.
Arkko, et al. Expires April 27, 2006 [Page 12]
Internet-Draft Multi-Service Decisions October 2005
8. 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 [5] for further discussion.
Note that while providing information from a NAS to a AAA server
helps enforce policies, it is unable to deal with rogue NASes, as
there is no way forgeries by legitimate (but turned rogue) NASes can
be detected. Where EAP is used for authentication, the end-to-end
secure channel between the EAP peer and the EAP server can help
ensure that all parties at least agree on what the provided service
was [10]. That is, the NAS would be forced to tell the same
information both to the peer and the AAA server.
Arkko, et al. Expires April 27, 2006 [Page 13]
Internet-Draft Multi-Service Decisions October 2005
9. References
9.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] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE
802.1X Remote Authentication Dial In User Service (RADIUS) Usage
Guidelines", RFC 3580, September 2003.
[5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[6] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
June 2004.
[7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-17 (work in progress), October 2004.
[8] 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.
9.2. Informative References
[9] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[10] Arkko, J. and P. Eronen, "Authenticated Service Identities for
the Extensible Authentication Protocol (EAP)",
draft-arkko-eap-service-identity-auth-00 (work in progress),
April 2004.
[11] Mariblanca, D., "EAP lower layer attributes for AAA protocols",
draft-mariblanca-aaa-eap-lla-01 (work in progress), June 2004.
[12] Lebovitz, G., "EAP lower layer attributes for AAA protocols",
draft-lebovitz-ipsec-scalable-ikev2cp-00.txt (unpublished)
Arkko, et al. Expires April 27, 2006 [Page 14]
Internet-Draft Multi-Service Decisions October 2005
(work in progress), March 2003.
[13] Zorn, G., "Additional Values for the NAS-Port-Type Attribute",
draft-zorn-radius-port-type-00 (work in progress),
February 2005.
Arkko, et al. Expires April 27, 2006 [Page 15]
Internet-Draft Multi-Service Decisions October 2005
Appendix A. Contributors
Glen Zorn and David Mariblanca were members of our team, and
contributed greatly to the discussions.
Arkko, et al. Expires April 27, 2006 [Page 16]
Internet-Draft Multi-Service Decisions October 2005
Appendix B. Acknowledgements
We would like to thank Jouni Korhonen, Dave Nelson, and Bernard Aboba
for interesting discussions in this problem space.
Arkko, et al. Expires April 27, 2006 [Page 17]
Internet-Draft Multi-Service Decisions October 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
Jouni Korhonen
Teliasonera Corporation
P.O. Box 970
FI-00051 Sonera
Finland
Email: jouni.korhonen@teliasonera.com
Arkko, et al. Expires April 27, 2006 [Page 18]
Internet-Draft Multi-Service Decisions October 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, et al. Expires April 27, 2006 [Page 19]
