SDNAuth H. Rafiee INTERNET-DRAFT Huawei Technologies Duesseldorf GmbH Intended Status: Informational Alexandru Petrescu Expires: August 6, 2015 February 6, 2015 SDNauth Usecases and Requirements Abstract This document aims to explain the requirement and usecases for a secure authentication and authorization of an app to foreign controllers to enforce policy in order to offer better services to end systems. It also covers the automation of authentication of two controllers and the possibility of two controllers to exchange any information to each other, e.g. end system's master key. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current. 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." This Internet-Draft will expire on February 6, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Rafiee & Petrescu Expires August 6, 2015 [Page 1] INTERNET DRAFT SDNauth usecases February 6, 2015 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Limited UI devices connections to public hotspot areas . 5 3.2. App transparency - a general view . . . . . . . . . . . . 6 3.3. Other use cases . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Rafiee & Petrescu Expires August 6, 2015 [Page 2] INTERNET DRAFT SDNauth usecases February 6, 2015 1. Terminology There is already a good SDN terminology available [RFC74269]. Here is the list of terms that has special meaning in this document. - End system: any device that is used by a user to start its communication ? a laptop, a smartphone, etc. - Network element: any physical or logical network devices such as a switch, a router, virtual switch (vswitch), etc. - Application (App): In this document, application is any piece of software that wants to communicate with SDN controller to exchange information or enforce any policy via SDN controller on target certain switch(es). e.g. an authentication/authorization app - Traffic flow : a group of traffic with the similar source or destination and port - Foreign SDN controller: a SDN controller that an application is not authorized to run anything on it. - Home SDN controller: a SDN controller that an application is pre-configured with to enforce any policy on. 2. Introduction Today, the advances of technology provide us with new capabilities and the possibility to use scalable logical networks and flexible and programmable virtual network devices (which uses Software Defined Network (SDN), Network Function Virtualization (NFV) ?based techniques or the combination of these two techniques. SDN is an approach which decouples network control from other components of the network infrastructure. SDN makes network administration easier by providing fully programmable networks. One example is to define packet flows that are distributed to target switches. The packet flow policy is distributed by a SDN controller that manages the flow tables on switches. This is why a SDN controller needs to be aware of the whole network topology and receive information on un-managed flows to enforce a correct policy on target network elements. Therefore, any topology changes need to be sent to the controller so that it can enforce a policy for load balancing on network elements. Virtualization techniques reduce the cost of hardware installation and the requirements for large physical space to install and place this hardware ? switches, router, etc. In other word, to allow customers to use flexible, fast, and reliable services without the need of having their own server rooms or buying different switches, routers, servers, etc. The use of SDN in virtual environment improves the network scalability and flexibility by allowing dynamic policy enforcement and easy network manageability to any new dynamically Rafiee & Petrescu Expires August 6, 2015 [Page 3] INTERNET DRAFT SDNauth usecases February 6, 2015 added network elements. However, authentication and authorization is still not clear and there are no common standards to be used in this environment especially when SDN is in use and an end system is supposed to send its credential information via a SDN controller to any verifier apps running on different controller. Furthermore, when a first connection of end system?s , e.g. an access point (AP), in a visited network is controlled by different SDN controller, then the exchange of any master key or any other information might be needed to provide this automation for the end system and avoid session re-association request. This is true that AP networks might use different approaches for user authentication. One example is http redirection, the other example is EAP and RADIUS. When the SDN solution is deployed by different vendors and used at different network infrastructures, then it is more likely to see the existing user authenticaion approaches as apps. Some example of these apps might be Remote Authentication Dial-In User Service (RADIUS) [RFC2865]; Open Standard for Authorization (OAuth) [RFC6749]; Diameter [RFC6733], etc. The purpose of this document is to introduce use cases for secure authentication and authorization of apps running on home controller to access and run on foreign controller. It also focuses on the automation of this process as much as possible and provide common standards for authentication and authorizations in virtual environment where SDN-based approaches are in use. This document addresses the following problems: - Secure authentication and authorization of app to foreign controller in order to enforce policy in foreign controller. (It is required to have a level of trust between home controller and foreign controller and then exchange authentication and authorization information via home network) - Provide a possibility to submit user information to foreign controller via existing signaling protocols. e.g. Home SDN controller submits master key of user to foreign SDN controller to avoid session re-association. - The authorization of app to controller is in the scope of SDNAuth but the distribution of policy over the network is out of the scope of SDNauth. This can be done via other standards such as Openflow. - Backward compatibility with existing network as much as possible. e.g. the use of an openflow switch between AP and controller to support such feature - Automation of authentication and authorization of two controllers for exchanging user session information. e.g. using PKI mechanism. 3. Use cases Rafiee & Petrescu Expires August 6, 2015 [Page 4] INTERNET DRAFT SDNauth usecases February 6, 2015 The following subsections explain an example use case scenario that SDNAuth can be used. 3.1. Limited UI devices connections to public hotspot areas A growing number of constrained devices are equipped with WiFi interfaces. But since they are not featuring full-blown User Interfaces traditionally used in larger devices (screens and keyboards on smartphones, tablets, PCs) these devices can connect to WiFi Access Points only by using pre-configured WiFi parameters, like the "ESSID" and network passwords. The pre-configuration operation involves using a smartphone or other device carrying a full UI. Under mobility conditions, it would be very difficult to manually re-configure these parameters such as to connect to public WiFi hotspots. It is impossible to stop by and and re-set the ESSID on a smartwatch without much additional effort. Other use-case involves devices requiring continuous Internet connection during mobility. For example, a multimedia personal device (mp3 player) needs to stream content from a server while the person moves from one hotspot to another. On these devices it is very difficult to re-set the ESSID and password at each public WiFi hotspot. Finally, On-Board Units carried by automobiles also need to connect to public WiFi hotspots. Whereas OBUs may be easily equipped with large screens and keyboards, the driver is forbidden from using these while driving the automobile - safety first. In this situation again, it is impossible to manually change the ESSID and password when moving from one public WiFi hotspot to another. It should be mentioned that ESSID and password are given only as examples of parameters which need to be re-configured in mobility situations from one public WiFi hotspot to another. Other examples of such parameters are related to the captive web portals: in some cases ESSID/passwords are not used for access control, but web portals are. The range of parameters need to open access through a web portal is very wide: from simple username and password to more complex procedures requiring, for example, to agree on the terms of use every 15 minutes. Rafiee & Petrescu Expires August 6, 2015 [Page 5] INTERNET DRAFT SDNauth usecases February 6, 2015 3.2. App transparency - a general view An app running on home SDN controller might need to enforce policy on foreign SDN controller. At the moment, two controllers might only exchange routing information via common routing protocols --iBGP, etc. If these controllers belong to two different vendors then it is unlikely to exchange any information. In case of agreement between them, only routing optimization information might be exchanged. There is no defined way for an app running on its home controller to be authorized in a foreign controller which has trust agreement with home controller. One example scenario is where this app following the activities of an end system to offer it a better service and provide it with all possible resources. This end system is mobile and moves to foreign network under the control of foreign SDN controller. This can be also a use case for cell phone networks during roaming. 3.3. Other use cases TBD 4. Requirements This section defines the scope of this document and introduces the requirement. [1] It needs to provide high security and privacy especially for end systems [2] It needs to automate the process as much as possible [3] It needs to support different clients with different resources (Memory, Battery, CPU, etc.) -- Laptops, IPod, Smartphone, etc. Good performance for constrained devices. [4] It needs to consider privacy and flexible to policies [5] It needs to provide a protocol for information exchange between two controllers after authentication and authorization where SDN based techniques are in use. [6] It needs to allow authorized third party app running on home controller to enforce policy via home controller to foreign controller [7] Backward compatibility with current infrastructures until all infrastructure fully support SDN solutions 5. Security Considerations Rafiee & Petrescu Expires August 6, 2015 [Page 6] INTERNET DRAFT SDNauth usecases February 6, 2015 There is no security consideration 6. IANA Considerations There is no IANA consideration 7. Acknowledgements The authors would like to thank people who directly or indirectly helped to improve this work. 8. References 8.1. Normative References [RFC2865] Rigney, C., Willens, S., Rubens, A., Simpson, W., " Remote Authentication Dial In User Service (RADIUS)",RFC 2865, June 2000 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., Zorn, G., "Diameter Base Protocol" RFC 6733, October 2012. [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012. [RFC6698] Hoffman, P., Schlyter, J., "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA",RFC 6698, August 2012 [RFC7426] Haleplidis, E., Pentikousis , K., Denazis , S., Hadi Salim, J., Meyer, D., Koufopavlou , O., "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, January 2015 Rafiee & Petrescu Expires August 6, 2015 [Page 7] INTERNET DRAFT SDNauth usecases February 6, 2015 Authors' Addresses Hosnieh Rafiee HUAWEI TECHNOLOGIES Duesseldorf GmbH Riesstrasse 25, 80992 Munich, Germany Phone: +49 (0)162 204 74 58 E-mail: ietf@rozanak.com Alexandru Petrescu Email: alexandru.petrescu@gmail.com Rafiee & Petrescu Expires August 6, 2015 [Page 8]