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]