One document matched: draft-rafiee-secauth-usecase-01.txt
Differences from draft-rafiee-secauth-usecase-00.txt
Secauth H. Rafiee
INTERNET-DRAFT Huawei Technologies Duesseldorf GmbH
Intended Status: Informational
Expires: March 23, 2015 September 23, 2014
Secauth Usecases and Requirements
<draft-rafiee-secauth-usecase-01.txt>
Abstract
This document aims to explain the requirement and usecases for
reducing gaps in first point of trusts during secure
authentication/authorization of nodes without the need of any CA. It
focuses on the 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.
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 March 23, 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 Expires March 23, 2015 [Page 1]
INTERNET DRAFT secauth usecases September 23, 2014
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. Comparison of Authentication and Authorization Mechanisms 4
1.1.1. Biometric Authentication . . . . . . . . . . . . . . 4
1.1.1.1. Advantages . . . . . . . . . . . . . . . . . . . 4
1.1.1.2. Disadvantages . . . . . . . . . . . . . . . . . . 4
1.1.2. Password Authentication . . . . . . . . . . . . . . . 5
1.1.2.1. Advantages . . . . . . . . . . . . . . . . . . . 5
1.1.2.2. Disadvantages . . . . . . . . . . . . . . . . . . 5
1.1.3. External Hardware Authentication . . . . . . . . . . 5
1.1.3.1. Advantages . . . . . . . . . . . . . . . . . . . 5
1.1.3.2. Disadvantages . . . . . . . . . . . . . . . . . . 5
1.2. Existing Protection Mechanisms and Problem Statement . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Overview of Secauth Design in an Example Scenario . . . . . . 7
4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Authentication of a Mail server to Another Mail Server . 8
4.2. Verification of a User to an Application Over the Network 8
4.3. Home User Behind Firewall or a Proxy Server . . . . . . . 8
4.4. Home Gateway/Device with an Static IP Address (Valid IP) 9
4.5. Verification of an App. to an App. Over the Network . . . 9
4.5.1. Openflow to virtual node authentication . . . . . . 9
4.5.2. SDN control plane authentication . . . . . . . . . . 9
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 10
9.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Rafiee Expires March 23, 2015 [Page 2]
INTERNET DRAFT secauth usecases September 23, 2014
1. Introduction
Today, the advance of technology provides us with new capabilities.
One example is the use of smart devices in Internet of Things (IoT).
These devices can report their status and their level of health,
inform about technical problems, etc. to the owner or technical
sites. One explicit example of these smart devices are home equipment
(smart fridge, smart TV, smart wash machine, etc.). So, the
information that these devices send can expose social behavior of its
owner. For controlling these devices owners? can control them
remotely via Internet using their smart phones or other smart
devices. However, the authentication and authorization of these
devices to the controller application and vice versa is is really
critical. This is because information leakage might harm the owner?s
privacy and security or might allow an attacker to think about a
robbery or do other criminal plans.
There are also other examples of advancing technology and the
critical role of authentication and authorization -- technologies go
toward offering good quality 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. 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, 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. 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. There are also other security
concerns in other scenarios such as the use of software as a service
(SaaS), platform as a service and infrastructure as a service to
offer so flexible and transparent services to customers.
Since authentication and authorization play a really important role
in everyday life, there are various authentication, authorization and
accounting approaches available to be used for different purposes.
But the first point of trust is usually a problem and 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
Rafiee Expires March 23, 2015 [Page 3]
INTERNET DRAFT secauth usecases September 23, 2014
cities. Some examples of these approaches are 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].
Therefore, the purpose of this document is to reduce the security gap
between end users and devices or devices to end devices during
authentication and authorization 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 and authorization for the last mile of
the Internet. This document defines the problem statement and
identifies the requirements for a robust easy secure authentication
and authorization of nodes for this purpose by the use of network
layer security and making it available to other layers.
The following sections compare the different
authentication/authorization mechanisms:
1.1. Comparison 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.1.1. Biometric Authentication
1.1.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.1.1.2. Disadvantages
- They can be stolen
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
Rafiee Expires March 23, 2015 [Page 4]
INTERNET DRAFT secauth usecases September 23, 2014
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.1.2. Password Authentication
1.1.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.1.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.1.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.1.3.1. Advantages
- The user does not need to memorize any password
1.1.3.2. Disadvantages
- It can be stolen
- It can be damaged
Rafiee Expires March 23, 2015 [Page 5]
INTERNET DRAFT secauth usecases September 23, 2014
1.2. 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
and without the need of CAs.
This document addresses the following problems:
- The use of public key cryptography. A light public key cryptography
algorithm such as Curve can be used to exchange session keys (for
possible encryption) or other possible identity. For example, a self
certified SSH server that can be trusted even in first point of
contact. In other words, avoid identity forgery or IP spoofing by
using a network layer security.
Rafiee Expires March 23, 2015 [Page 6]
INTERNET DRAFT secauth usecases September 23, 2014
- Secure authentication in first points of trust
- Remove the dependency to CAs to provide the trust
- Privacy and data confidentiality (if necessary to handle by this
protocol)
- Secure authentication of devices in case of proxy servers
- etc.
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 the overview of secauth design model. Figure 1 shows a
very simple example of secauth design model for authentication and
authorization of a SSH server. In this figure, number 1(the example
use of secauth in DNS servers explained in [cga-tsig]) and 2 are
where secauth can be used for authentication and authorization
without the need of CA to create first point of trust. 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 for first point of trust with minimum configuration. This design
model can be similar for many other example scenarios.
Rafiee Expires March 23, 2015 [Page 7]
INTERNET DRAFT secauth usecases September 23, 2014
+-------------------+ +--------------+
| 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
4. Use cases
The following subsections explain some example use case scenarios
that secauth can be used.
4.1. Authentication of a Mail server to Another Mail Server
Mail server A wants to send email to mail server B. None of these
mail servers uses a certificate sign by a CA (because of problem
explained in 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.2. Verification of a User to an Application Over the Network
Alice turned on the wash machine at home and then went to work. Alice
can check the status of this wash machine using an application on her
Smartphone remotely at company x. Wash machine doesn?t support any
certificates signed by a CA. Alice needs to be authenticated in the
wash machine and wash machine needs to trust Alice to allow her
control it remotely. Since the application are usually provided by
third parties, the security of this communication is important and
the first point of trust is really important.
4.3. Home User Behind Firewall or a Proxy Server
Rafiee Expires March 23, 2015 [Page 8]
INTERNET DRAFT secauth usecases September 23, 2014
Alice?s device is behind a firewall or a proxy server. Alice wants to
use an application that uses SIP protocol to contact Bob. Bob rejects
any unknown calls to avoid advertisements/spam. Proxy server needs to
verify Alice and send the information to Bob?s device
4.4. Home Gateway/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 authenticate Alice before lets it
control this device and add/modify any new rule to this device.
Scenario 2: Alice?s wash machine technically has a problem. Its
application was configured by the vendors? in a way to report this
problem automatically to third party technical service (repair
place). Both the technical service application and wash machine need
to authenticate each other so that they can trust and exchange
information. Since the application are usually implemented by the
third party and there was not much effort to secure the
communications between the device and the application, the security
of them is a big concern.
4.5. Verification of an App. to an App. Over the Network
4.5.1. Openflow to virtual node authentication
A unique identifier is used to authenticate an openflow on a virtual
node. This virtual node (like a switch or a router) allows this
openflow to be executed when it can find this unique identifier in
its access list.
4.5.2. SDN control plane authentication
Before any rule can be propagated over all distributed control plane
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 of an protocol.
- Independent to IP network (supports both IPv4 and IPv6)
Rafiee Expires March 23, 2015 [Page 9]
INTERNET DRAFT secauth usecases September 23, 2014
- Requires minimum human interaction (automates the process as much
as possible)
- Supports different clients with different resources (Memory,
Battery, CPU, etc.) ? Laptops, IPod, Smartphone, sensor nodes, cars,
etc.
Good performance for constrained devices.
- Provides security and a user defined privacy (flexible to policy)
- Be able to authenticate and authorize nodes in case there are proxy
servers or other intermediate nodes in the middle of the
communications (provide the first point of trust)
- Enable the use of this approach in visualization environment (as
explained in prior section) and for the authentication of different
virtual nodes in clouds where Software Defined Network (SDN) or
Network Function Virtualization (NFV) techniques are in use.
- Compatible to be used in the combination of other protocols for
providing first point of trust such as TLS, SSH, DNS, etc.
- 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
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
Rafiee Expires March 23, 2015 [Page 10]
INTERNET DRAFT secauth usecases September 23, 2014
[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 March 23, 2015 [Page 11]
INTERNET DRAFT secauth usecases September 23, 2014
Authors' Addresses
Hosnieh Rafiee
HUAWEI TECHNOLOGIES Duesseldorf GmbH
Riesstrasse 25, 80992
Munich, Germany
Phone: +49 (0)162 204 74 58
E-mail: hosnieh.rafiee@huawei.com
Rafiee Expires March 23, 2015 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 02:21:37 |