One document matched: draft-rafiee-sdnauth-usecase-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 02:24:39 |