Internet DRAFT - draft-rafiee-secauth-usecase
draft-rafiee-secauth-usecase
Secauth H. Rafiee
INTERNET-DRAFT Huawei Technologies Duesseldorf GmbH
Intended Status: Informational
Expires: April 22, 2015 October 22, 2014
Secauth Usecases and Requirements
<draft-rafiee-secauth-usecase-02.txt>
Abstract
This document aims to explain the requirement and usecases for
reducing reliability gaps in first point of contact during secure
authentication of nodes without the need of any CA. It focuses on use
of network layer security approaches for this purpose. Privacy
requirement is also one of the important topic that will be addressed
in this draft. It also discusses the requirements and use cases for
having a common language (protocols) for authentication/authorization
in visualization environments where Software Defined Network (SDN) or
Network Function Visualization (NFV) approaches are in use.
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 April 22, 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
Rafiee Expires April 22, 2015 [Page 1]
INTERNET DRAFT secauth usecases October 22, 2014
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
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Existing Protection Mechanisms and Problem Statement . . 4
1.2. Analysis of Authentication and Authorization Mechanisms . 5
1.2.1. Biometric Authentication . . . . . . . . . . . . . . 5
1.2.1.1. Advantages . . . . . . . . . . . . . . . . . . . 5
1.2.1.2. Disadvantages . . . . . . . . . . . . . . . . . . 5
1.2.2. Password Authentication . . . . . . . . . . . . . . . 6
1.2.2.1. Advantages . . . . . . . . . . . . . . . . . . . 6
1.2.2.2. Disadvantages . . . . . . . . . . . . . . . . . . 6
1.2.3. External Hardware Authentication . . . . . . . . . . 6
1.2.3.1. Advantages . . . . . . . . . . . . . . . . . . . 6
1.2.3.2. Disadvantages . . . . . . . . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Overview of Secauth Design in an Example Scenario . . . . . . 7
4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Reliable authentication of a device to another device . . 8
4.1.1. Verification of two mail servers . . . . . . . . . . 8
4.1.2. Verification of IoT Devices to Clouds . . . . . . . . 9
4.1.3. Home Device with an Static IP Address (Valid IP) . . 9
4.2. Secure Authentication of Openflow to virtual nodes . . . 9
4.2.1. SDN control plane authentication . . . . . . . . . . 9
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 11
9.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Rafiee Expires April 22, 2015 [Page 2]
INTERNET DRAFT secauth usecases October 22, 2014
1. 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). Technologies
also go toward offering good quality of services with lower price to
customers without the need to have several physical devices. In other
words, 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. However, authentication
and authorization is still not clear and there are no common
protocols to be used in this environment especially if the end users
are supposed to use services from two/many different vendors/service
providers, there might be no compatibility between these services.
There are also no guidelines on how to use the current available
protocols for authentication and authorization purposes in this
virtual environemnt.
One example is the use of virtual switches instead of the need for
having a real switch in cloud environments. In these virtual devices,
usually, the control plane is separate from the data plane if
Software Defined Network (SDN) techniques are in use. In other words,
for example for virtual switches, the high level routing decision or
packet filtering are taken in another virtual device. These kinds of
virtual switches are called open flow switches. Since many open flow
switches are controlled by one centralized controller (SDN
centralized model), if one of customers is authorized to have access
to one of these open flow switches to define his own policy, he might
abuse his authorization and try to apply policies that impact other
customers who use this virtual device. So, introducing a good
authorization protocol to avoid this maltreat is critical. Other
problem would be the case that an attacker tries to change policy on
one virtual device so that this policy would be propagated to other
open flow devices execute by authorized open flow protocols. So,
authentication and authorization of these open flows to controller is
really important.
Furthermore, the current available authentication and authorization
approaches -- Remote Authentication Dial-In User Service (RADIUS)
[RFC2865]; Host Identity Protocol (HIP) [RFC4423]
(location-independent identifier); Open Standard for Authorization
(OAuth) [RFC6749]; Diameter [RFC6733] and DANE [RF6698] -- usually
cannot provide reliability in the beginning of communication easily
without involving too many human interactions for pre-configurations.
Therefore, any approach to reduce this gap would help the available
approaches to serve the end user/devices more reliably especially
when we are going toward smart cities, clouds services and virtual
devices.
The purpose of this document is to reduce this security gap during
Rafiee Expires April 22, 2015 [Page 3]
INTERNET DRAFT secauth usecases October 22, 2014
establishment of authentication (reliable first contact) between end
users and devices or devices to end devices where other
authentication or authorization approaches are unable to address this
problem easily without many pre-configurations. In other word, this
protocol aims to assist a secure authentication for the last mile of
the Internet. Secauth also plans to provide common standards for
authentication and authorizations in virtual environment where
SDN-based approaches are in use.
The following sections compare the different
authentication/authorization mechanisms:
1.1. Existing Protection Mechanisms and Problem Statement
Usually, Internet Protocol security (IPsec) [RFC 4301], Transport
Layer Security (TLS) [RFC5246] or Secure Socket Layer (SSL) [RFC6101]
is used to secure the communications during authentication and
authorization. This also provides a user with data. When IPsec is in
use, the key management might be a problem. When SSL or TLS is in use
the problems are as follows:
- Certificates signed by a Certificate Authority (CA); Firstly, using
a CA is costly. It is because for every node that wants to offer a
service and allow others to verify it, there needs to be a valid
certificate signed by a CA. In other words, all those nodes need to
have a valid domain name. Therefore there is a cost for registering a
domain and also having a certificate signed by a CA. In this case, a
proxy server or intermediate devices might cause a problem and break
this trust. The other problem with the use of CA would be the
likelihood of government?s surveillance since they might have access
to CA's databases. The last problem would be the case where CA
databases have been hacked. Thereby, all nodes around the world that
uses this CA are no longer secure. This is, of course, extra workload
for administrators of networks to replace the old keys (exposed one)
with the new one on all their nodes.
- Nodes should be pre-configured with the list of Trusted Anchor
(TA); The problem would be the installation and configuration of
these TAs when they do not already exist.
Therefore, in both prior cases, an infrastructure is one of
requirements to establish such trusts (either TA or CA servers).
To overcome the requirement for infrastructure, some mechanisms such
as SSH [opp-enc] trust a node during first time communication (first
point of contact) and stores the public key of this node for future
trust. When an attacker has an opportunity to play MITM at this
point, then the next communications also would be influenced by the
first trust. This is why it is really important to provide a level of
assurance for the verifier node in first point of contact. This is
what secauth protocol plans to address and eliminates this security
gap as much as possible without or with minimal human interactions
Rafiee Expires April 22, 2015 [Page 4]
INTERNET DRAFT secauth usecases October 22, 2014
and without the need of CAs.
This document addresses the following problems:
- Automation in providing reliable secure authentication during first
contact (minimal configuration for starting authentication process)
in all environment including IoT, virtual environment, etc.
- Remove the dependency to any separate infrastructure to have CAs
for providing reliability in first point of contact.
- Secure DNS and Uses it to provide reliability for first point of
contact.
Many current protocols use the names of devices instead of IP. In
case the device needs to use a domain name, secauth needs to provide
this security (secure authentication) for DNS and also uses DNS
resources to store authentication information.
- Privacy and data confidentiality
- Secure authentication of devices in case of intermediate devices in
virtual environment
- Common standards in authentication and authorization for virtual
environment where SDN and NFV based techniques are in use
1.2. Analysis of Authentication and Authorization Mechanisms
Usually for authentication of a user, biometric samples, a username
or a token is in use. Using each of these approaches has some
advantages and disadvantages.
1.2.1. Biometric Authentication
1.2.1.1. Advantages
- It is always with the user, dissimilar to passwords they cannot be
forgotten
- It might identify a person so that many services can be offered to
this user remotely.
1.2.1.2. Disadvantages
- They can be stolen
Rafiee Expires April 22, 2015 [Page 5]
INTERNET DRAFT secauth usecases October 22, 2014
An attacker can stole the finger print of a user when he touches, for
example, a glass.
- They will never change
When they are stolen, dissimilar to passwords, it is not possible to
change them since they are a scan sample part of a user's body
- They might cause threat for the user
When a criminal know that every password is the biometric information
of a user, he can kidnap this person and access to all information
that uses this kind of biometric samples.
It can also encourage criminals to kill a person to access to
biometric samples!
1.2.2. Password Authentication
1.2.2.1. Advantages
- A user can change it when it is stolen
- A user can use different username and passwords in different
systems
- It might not identify a person
1.2.2.2. Disadvantages
- It is not easy to memorize one to many passwords for different
systems (finding a strong password that can be memorized easily.)
- It can be hacked
- When a user uses one password for all systems, then he is prone to
data loss or privacy attack.
1.2.3. External Hardware Authentication
In recent years, it is common to use the external devices such as
chip cards, USBs, etc. that stores some secret keys to authorize a
user to access some systems or information over the internet or over
the network.
1.2.3.1. Advantages
- The user does not need to memorize any password
Rafiee Expires April 22, 2015 [Page 6]
INTERNET DRAFT secauth usecases October 22, 2014
1.2.3.2. Disadvantages
- It can be stolen
- It can be damaged
2. Terminology
Device: any digital hardware that has communication ability. A device
is more general than a node.
Node: routers and hosts in a network
Intermediate Device: a proxy server or a NAT device or any other node
that intercept the communication in no malicious way and by purpose
Authentication: An act of verifying a user
Authorization: act of determining whether requesting entity is
allowed access to a resource
Accounting: act of collecting info on resource usage and logging user
activities after authorization step.
TBD
3. Overview of Secauth Design in an Example Scenario
The purpose of this section is not to introduce any solution but only
discuss about a possible overview of secauth design model.
+-------------------+ +--------------+
| secure router or | |DNS resolVer |
| SAVI-DHCP | +---^----------+
+------+-------+----+ |
| | | 1
| |IP address of|DNS
+----------+ |Server |
| Alice's | <-+ |
| Computer <-+-+-------------+
+----------+ IP address of
+secauth example.com
verification
+ |
| | +-------+---+
| | 2 |SSH server |
| +------------>Example.com|
+ +-----------+
ssh Alice@example.com
Rafiee Expires April 22, 2015 [Page 7]
INTERNET DRAFT secauth usecases October 22, 2014
Figure 1 shows a very simple example of secauth design model for
authentication and authorization of a SSH server. A user uses a
domain name of SSH server. There are two scenarios here:
[1] a node can trust the network where it is connected in order to
receive the IP address of a DNS server. This scenario is only when a
node can receive the IP address of a resolver from secure Router
Advertisement (RA) or there is any switch-based security available.
The scope of secauth here is to securely authenticate the DNS
resolver and to securely authenticate an application or a device.
[2] a node cannot trust the network. The finger print of a DNS server
needs to be set in the node manually as explained in [cga-tsig] .
This manual step is out of scope of secauth. After this step, like
what explained in last scenario, secauth can verify the DNS resolver
and securely authenticate an application or a device.
[1] and [2] maps to number 1 in figure 1.
If the communication is only IP based and a node uses a valid IP
address.
- In IPv6, dissimilar to [1] and [2], secauth can automate the whole
process without any configuration.
- In IPv4, this is similar to [1] and [2].
As shown in figure 1, number 1 and 2 are where secauth can be used
for authentication and authorization without the need of CA to create
reliability in first point of contact. In other word, a node no
longer needs to worry about trusting other communicating parties for
the first time as it happens in SSH communication for the first time
or introduce SSH server?s keys manually to the SSH client; secauth
can be used to authenticate the other communicating parties even
during first point of contact with minimum configuration. This design
model can be similar for many other example scenarios.
4. Use cases
The following subsections explain some example use case scenarios
that secauth can be used.
4.1. Reliable authentication of a device to another device
4.1.1. Verification of two mail servers
Mail server A wants to send email to mail server B. Both uses TLS
protocol to provide data confidentiality. None of these mail servers
uses a certificate sign by a CA (because of problem explained in
Rafiee Expires April 22, 2015 [Page 8]
INTERNET DRAFT secauth usecases October 22, 2014
first section). It is not also possible to mail server A with
preconfigured value of all mail server available on the world. So,
mail server A needs to trust mail server B in first point of
communication. This increases the risk of attack in this point.
However, mail server A can use secauth to authenticate the resolver
and obtain the IP address of mail server B [cga-tsig]. Since secauth
can authenticate the node without any CA, mail server A can trust the
certificate provided by mail server B and establish the communication
in a secure manner.
4.1.2. Verification of IoT Devices to Clouds
A smart phone stores a copy of Alice's data on cloud storage. During
fetching or storing data from this cloud storage, this smart phone
needs to establish a reliable communication to this cloud storage
(smart phone needs to authenticate this cloud storage to avoid MITM
and then being authorized at the cloud storage to access the old
data.). If cloud storage doesn?t support CA, any security protocol in
use might not be able to provide this reliability in first point of
contact. Secauth here can provide this reliability for the
communication of IoT to Clouds.
Example 3: A SIP device uses current security protocols for
verification of other end point of communication. However, both
device needs to be pre-configured to be able to verified each other
or there needs to use CA for reliability in first point of contact.
To avoid the use of CA, secauth can be used to provide this
reliability.
4.1.3. Home Device with an Static IP Address (Valid IP)
Scenario 1: Alice needs to control its home gateway and add new rules
so that she can access a device inside her home network. Alice
remotely connects to this device. This device doesn?t support any
valid CA. The device needs to verify Alice (reliability in first
point of contact) before lets it control this device and add/modify
any new rule to this device.
4.2. Secure Authentication of Openflow to virtual nodes
There are no common protocols (same language) that can be used to
verify openflows on virtual nodes. Each vendor might use different
approaches and there are no compatibility between these approaches.
This is especially true when the interoperability between two vendors
is to be considered.
4.2.1. SDN control plane authentication
Before any rule can be propagated over all distributed control plane
Rafiee Expires April 22, 2015 [Page 9]
INTERNET DRAFT secauth usecases October 22, 2014
via the centralized control plane, the sender of this new rule (one
of the SDN control plane) should be authenticated on the centralized
control plane (controller) to avoid propagation of a malicious rule
on all SDN devices.
5. Requirements
This section defines the scope of this document and introduces the
requirement.
[1] It needs to be independent to IP network (supports both IPv4 and
IPv6)
[2] It needs to automate the process as much as possible especially
for reliability in first point of contact (requires minimal human
interactions
[3] It needs to support different clients with different resources
(Memory, Battery, CPU, etc.) -- Laptops, IPod, Smartphone, sensor
nodes, cars, etc.
Good performance for constrained devices.
[4] It needs to consider privacy and flexible to policies
[5] It needs to provide a protocol for authentication and
authorization in visualization environment (as explained in prior
section) where Software Defined Network (SDN) or Network Function
Virtualization (NFV) based techniques are in use.
[6] Backward compatibility to combine with current available
protocols such as TLS, SSH, DNS, etc.
[7] Requires minimum changes on the existing network (operational
view)
6. Security Considerations
There is no security consideration
7. IANA Considerations
There is no IANA consideration
8. Acknowledgements
Rafiee Expires April 22, 2015 [Page 10]
INTERNET DRAFT secauth usecases October 22, 2014
The author would like to thank people who helped to improve this
document with their constructive comments and suggestions. The names
of these people including (but not limited to) Hannes Tschofenig,
Paul Lambert, Viktor Dukhovni, Fernando Gont and Alan Dekok.
9. References
9.1. Normative References
[RFC2865] Rigney, C., Willens, S., Rubens, A., Simpson, W.,
" Remote Authentication Dial In User Service (RADIUS)",RFC
2865, June 2000
[RFC4301] Kent, S., Seo, K., "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4423] Moskowitz, R., Nikander, P., "Host Identity
Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4843] Nikander, P., Laganier, J., Dupont, F. , "An IPv6
Prefix for Overlay Routable Cryptographic Hash Identifiers
(ORCHID)", RFC 4843, April 2007.
[RFC6101] Freier, A., Karlton, P., Kocher, P. , "The Secure
Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, August
2011.
[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
9.2. Informative References
[opp-enc] Dukhovni, V., "Opportunistic Security: some
protection most of the time",
http://tools.ietf.org/html/draft-dukhovni-opportunistic-security-00,
July 2014
[cga-tsig] Rafiee, H., von Loewis, M., Meinel, C.,
"CGA-TSIG/e: Algorithms for Secure DNS Authentication and
Optional DNS Confidentiality",
http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-10,
August 2014
Rafiee Expires April 22, 2015 [Page 11]
INTERNET DRAFT secauth usecases October 22, 2014
Rafiee Expires April 22, 2015 [Page 12]
INTERNET DRAFT secauth usecases October 22, 2014
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
Rafiee Expires April 22, 2015 [Page 13]
