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]