One document matched: draft-rafiee-secauth-usecase-00.txt
Secauth H. Rafiee
INTERNET-DRAFT Huawei Technologies Duesseldorf GmbH
Intended Status: Informational Track
Expires: February 26, 2015 August 26, 2014
Secauth Usecases and Requirements
<draft-rafiee-secauth-usecase-00.txt>
Abstract
This document explains the use cases and requirements for secure
authentication in other layers above the network layer, e.g. an
application layer and the use of network layer security approaches
for this purpose. It also introduces the requirement for privacy
consideration.
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 26, 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
include Simplified BSD License text as described in Section 4.e of
Rafiee Expires February 26, 2015 [Page 1]
INTERNET DRAFT secauth usecases August 26, 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Authentication/Authorization of a User to a Device . . . 5
3.1.1. Biometric Authentication . . . . . . . . . . . . . . 5
3.1.1.1. Advantages . . . . . . . . . . . . . . . . . . . 5
3.1.1.2. Disadvantages . . . . . . . . . . . . . . . . . . 5
3.1.2. Password Authentication . . . . . . . . . . . . . . . 5
3.1.2.1. Advantages . . . . . . . . . . . . . . . . . . . 6
3.1.2.2. Disadvantages . . . . . . . . . . . . . . . . . . 6
3.1.3. External Hardware Authentication . . . . . . . . . . 6
3.1.3.1. Advantages . . . . . . . . . . . . . . . . . . . 6
3.1.3.2. Disadvantages . . . . . . . . . . . . . . . . . . 6
3.1.4. Proxy Server Scenario . . . . . . . . . . . . . . . . 6
3.1.5. NAT Scenario . . . . . . . . . . . . . . . . . . . . 6
3.1.6. Valid IP address . . . . . . . . . . . . . . . . . . 7
3.2. Authentication and Authorization of two Devices . . . . . 7
3.2.1. A proxy server . . . . . . . . . . . . . . . . . . . 7
3.2.2. No Intermediate Device Scenario . . . . . . . . . . . 7
3.3. Authentication and Authorization of Virtual Devices . . 7
3.3.1. Openflow to virtual node authentication . . . . . . 8
3.3.2. SDN control plane authentication . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Functionality . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Implementation and Operational View . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Rafiee Expires February 26, 2015 [Page 2]
INTERNET DRAFT secauth usecases August 26, 2014
1. Introduction
Today, various authentication, authorization and accounting
approaches are 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. Some examples of these approaches are
Remote Authentication Dial-In User Service (RADIUS) [RFC6929], Host
Identity Protocol (HIP) [RFC4423], Open Standard for Authorization
(OAuth) [RFC6749], Diameter [RFC6733] and DANE [6698].
Usually, Internet Protocol security (IPsec) [RFC 4301], Transport
Layer Security (TLS) [RFC5246] or Secure Socket Layer (SSL) [RFC6101]
is used to secure these communications and provide data
confidentiality for users. 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). This is of
course costly. It is because for every node that can be any end user
or servers who offer a service or also in some cases where an end
user/device might want to use a service, there should be a valid
certificate signed by a CA. In other words, all those nodes need to
have a valid domain name and possibly a global IP address to point to
those domains. In this case, a proxy server or intermediate devices
might cause a problem and break this trust. This is , of course, true
for end users/devices. Because usually the servers are not behind
Network Address Translate (NAT). 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.
- Nodes should be pre-configured with the list of Trusted Anchor
(TA). The first problem would be the installation and configuration
of these TAs when they do not already exist. The second problem would
be pre-configuration of each single device (verifier nodes) with a
list of TAs manually set a list of these TAs. This is especially not
easy when nodes are dynamic in a network.
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 API plans to address and eliminates this security gap as
much as possible without or with minimal human interactions and
without the need of CAs. One example of the use of secauth API is the
use of network layer security for important protocols, i.e., DNS in
Rafiee Expires February 26, 2015 [Page 3]
INTERNET DRAFT secauth usecases August 26, 2014
order to have a secure authentication for last mile of Internet
[cga-tsig]. Another example is the use of this protocol to
authenticate one mail server to another one without the use of CAs.
This document addresses the following problems:
- The use public key cryptography. A light public cryptography
algorithm such 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.
- Secure authentication
- Remove the dependency to CAs to provide the this trust
- Privacy and data confidentiality (if necessary to handle by this
API)
- Secure authentication of devices in case of proxy servers
- etc.
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 words, this API 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 using a combination of network layer and
application layer security approaches.
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
Rafiee Expires February 26, 2015 [Page 4]
INTERNET DRAFT secauth usecases August 26, 2014
Accounting: act of collecting info on resource usage and logging user
activities after authorization step.
TBD
3. Use cases
The following subsections explains different use case scenarios
3.1. Authentication/Authorization of a User to a Device
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.
3.1.1. Biometric Authentication
3.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.
3.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
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!
3.1.2. Password Authentication
Rafiee Expires February 26, 2015 [Page 5]
INTERNET DRAFT secauth usecases August 26, 2014
3.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
3.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.
3.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.
3.1.3.1. Advantages
- The user does not need to memorize any password
3.1.3.2. Disadvantages
- It can be stolen
- It can be damaged
There are two different use cases under this category that are
explained in the following sections
3.1.4. Proxy Server Scenario
Alice is behind a proxy server and any request to the device is first
received by the proxy
3.1.5. NAT Scenario
Rafiee Expires February 26, 2015 [Page 6]
INTERNET DRAFT secauth usecases August 26, 2014
Alice does not have any valid IP address and needs to be
authenticated on an application server
3.1.6. Valid IP address
Alice has a valid IP address and needs to be authenticated on an
application server.
3.2. Authentication and Authorization of two Devices
3.2.1. A proxy server
For example, node A establishes Session Initiation Protocol (SIP) to
node B. There is SIP proxy in between. SIP proxy receives messages
from node A. SIP proxy needs to authenticate node A. After this step
SIP proxy forwards all packets from node B. Node B authenticates SIP
proxy and accepts all packets intercepts by SIP proxy.
3.2.2. No Intermediate Device Scenario
For example, node A establishes SIP session to node B. This
communication can be end-to-end.
3.3. Authentication and Authorization of Virtual Devices
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 are separate from the data plane. 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), security as a service and infrastructure as a service
Rafiee Expires February 26, 2015 [Page 7]
INTERNET DRAFT secauth usecases August 26, 2014
to offer so flexible and transparent services to customers.
This section describes the authentication of different virtual open
flows with controller plane
3.3.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.
3.3.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.
4. Requirements
This section defines the scope of this document and introduces the
requirement of an API.
4.1. Functionality
- Operates in both IPv4 and IPv6 networks
- 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
- 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.
Rafiee Expires February 26, 2015 [Page 8]
INTERNET DRAFT secauth usecases August 26, 2014
- Compatible to be used or combined with other protocols -- DNS,
HTTP, email, etc. -- easily.
4.2. Implementation and Operational View
- Platform independent. In other words, supports multiple platforms
(Windows, Linux, UNIX, etc.)
- Easily integrate with any other application layer authentication
mechanisms
- Provide an easy framework for distributing unique identity but at
the same time aware of privacy.
- Provide supports for Software Defined Networks (SDN)
5. Security Considerations
There is no security consideration
6. IANA Considerations
There is no IANA consideration
7. References
7.1. Normative References
[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
Rafiee Expires February 26, 2015 [Page 9]
INTERNET DRAFT secauth usecases August 26, 2014
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
[RFC6929] DeKok, A., Lior, A., "Remote Authentication
Dial-In User Service (RADIUS) Protocol Extensions",RFC
6929, April 2013
7.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 February 26, 2015 [Page 10]
INTERNET DRAFT secauth usecases August 26, 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 February 26, 2015 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 02:23:06 |