SDNauth Usecases and Requirements
draft-rafiee-sdnauth-usecase-00

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
                  <draft-rafiee-sdnauth-usecase-00.txt>

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]