Internet DRAFT - draft-yang-ace-groupauth
draft-yang-ace-groupauth
ACE Working Group Hyunsik Yang
Internet Draft Youngki Park
Intended status: Informational Younghan Kim
Expires: April 2016 Soongsil University
Namhi Kang
HERIT
October 19, 2015
Authentication architecture for a group of constrained devices
draft-yang-ace-groupauth-01.txt
Abstract
Constrained devices have a limitation in adapting various general
cryptography mechanisms since they have limited processing power,
storage space and transmission capacities. Moreover, in an
environment that has a large number of constrained devices, the
device authentication and authorization procedure causes serious
burdens. Therefore, this draft proposes a group authentication
mechanism to solve existing problems.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November 10,
2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Yang, et al. Expires April 19, 2016 [Page 1]
Internet-Draft draft-yang-ace-groupauth-01 October 2015
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 15, 2016.
Copyright Notice
Copyright (c) 2015 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 the Trust
Legal Provisions and are provided without warranty as described in
the Simplified BSD License.
Yang, et al. Expires April 19, 2016 [Page 2]
Internet-Draft draft-yang-ace-groupauth-01 October 2015
Table of Contents
1. Introduction ................................................ 4
1.1. Terminology ............................................ 4
2. Use cases ................................................... 5
2.1.1. Wearable devices................................... 5
2.1.2. Requirements for wearable devices ................. 6
2.1.3. Mobile sink for isolated sensor environment........ 6
2.1.4. Requirements for mobile sink ...................... 6
2.1.5. Smart car ......................................... 6
2.1.6. Requirements for smart car ........................ 7
3. Group authentication architecture and procedures ............ 7
3.1. Architecture ........................................... 7
3.2. Group authentication procedure ......................... 8
3.2.1. Device registration ............................... 8
3.2.2. Resource discovery ................................ 9
3.3. Group authentication procedure (inbound) ............... 9
4. Consideration .............................................. 10
5. Security Considerations .................................... 10
6. IANA Considerations ........................................ 11
7. Conclusion ................................................. 11
8. References ................................................. 11
8.1. Normative References................................... 11
8.2. Informative References................................. 11
9. Acknowledgments ............................................ 11
Yang, et al. Expires April 19, 2016 [Page 3]
Internet-Draft draft-yang-ace-groupauth-01 October 2015
1. Introduction
Currently, many constrained devices are used for various applications
in various fields; therefore, their authentication issues should be
considered carefully. The general authentication method is based on
one-by-one communication (i.e. unicast). However, there will be
burdens in a scenario, where a node needs to authenticate large
number of devices at the same time. Moreover, when a lot of devices
are located in one place, it will cause a bottleneck. Furthermore,
constrained devices have a limitation in adopting various general
cryptography mechanisms since they have limited processing power,
storage space and transmission capacities.
This document considers various use cases for authentication and
authorization in constrained environments and proposes a mechanism
and a procedure for group authentication.
Based on the use cases, this document also defines a group entity
functionality and initiate procedure when operator of each device
wants to get mutual authentication.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
Group
Users can make a group based on application usage or authentication
method.
Group cluster header
Group cluster header is one of the group members and is a
representative of a specific group.
Group agent
Group agent can manage several groups and it also has a required
function for group authentication.
Group ID
It is a unique ID that identifies a specific group.
Yang, et al. Expires April 19, 2016 [Page 4]
Internet-Draft draft-yang-ace-groupauth-01 October 2015
Group shared key
It is used by the device and group agent to verify each other.
2. Use cases
Group authentication enables a node to authenticate all devices in a
group at once. Group authentication can reduce both computing and
signaling cost of the authentication procedure and enhance security
of the constrained devices.
This section describes use cases that prefer to use a group based
authentication rather than one-by-one authentication. Based on the
use cases, we list several requirements and considerations.
2.1.1. Wearable devices
Suppose that Alice has four devices; a heartbeat-monitoring device, a
blood pressure-monitoring device, smart glasses for virtual screen,
and a smart ring to control the virtual screen. There might be two
different groups. A group of devices, which includes the heartbeat-
monitoring device and blood pressure-monitoring device, is used for
health care of Alice. The other group is used for helping Alice in
her workplace. The smart glasses and the ring belong to the second
group.
When Alice arrives in her workplace, the smart glasses and smart ring
may need to get data from a database server or IT management server
of the company, and the server may need to update these devices'
firmware. Both of the scenarios require mutual authentication since
the company servers and Alice's devices must verify each other. In
this scenario, the two servers and the two devices are mutually
authenticated in a one by one manner (i.e. four different procedures
for each of the entity pairs). However, more increasing the number of
authentication entity (i.e. either server or device) results in
higher burden on the entity. Thus, a group authentication mechanism
is required.
After Alice leaves the office, Alice goes to a hospital to check her
health status. When she arrives at the hospital and meets a doctor,
if the doctor wants to change the configuration in a device or get
her health data, only the member devices of health care group should
be authenticated by using a group authentication mechanism.
Yang, et al. Expires April 19, 2016 [Page 5]
Internet-Draft draft-yang-ace-groupauth-01 October 2015
2.1.2. Requirements for wearable devices
Authentication mechanism is required for every device to verify its
communication entity in advance of data exchange. The authentication
mechanism would be changed according to device capability.
Group key should be shared to verify identities between devices and
group agent.
The discovery procedure between group agent and corresponding nodes
is out of scope.
2.1.3. Mobile sink for isolated sensor environment
In Wireless Sensor Network, Mobile sink, which has a function
allowing nodes to move anywhere, is to be a solution for aggregating
data. Especially, mobile sink is used for gathering sensor data from
deployed sensors, where they are located in isolated environment such
as the heart of a mountain or the deep sea. Based on sensor
characteristics, user can make a group such as a humidity group or a
temperature group and others. In some scenarios, authentication is
required for secure communication between mobile sink and sensor node.
For that, a mobile sink can authenticate its corresponding group
cluster header based on the group authentication mechanism.
2.1.4. Requirements for mobile sink
Group key should be shared to verify identities between sensor and
mobile sink.
Based on group information, mobile sink can request message to group
cluster header.
The discovery procedure between group agent and corresponding nodes
is not necessary.
2.1.5. Smart car
Alice and Bob have a smart car which may have lots of sensors for
managing tire air pressure, engine oil, break oil, headlight, battery,
etc. When they sit on the car seat, the car detects its user and
sends status information of car to them; thereby they can check
condition of car easily. Based on the car's information, they can
examine the car and prevent accident occurred by car's problem.
Moreover, there might be several actuators in the car for
Yang, et al. Expires April 19, 2016 [Page 6]
Internet-Draft draft-yang-ace-groupauth-01 October 2015
automatically adjusting car seats, room mirror, side view mirror, etc.
So, after checking the car's status, actuators send request message
to driver to get driver's identity. Based on the drivers identity,
every actuators set adjustment value which are modified by driver's
characteristic.
2.1.6. Requirements for smart car
Authentication mechanism is required for every sensors or actuators
to verify its communication entity in advance of data exchange. The
authentication mechanism would be changed according to device
capability.
Group key should be shared to verify identities between sensor and
group agent (e.g. driver's smart phone).
When a device (i.e. sensor or actuator) is replaced, new device
should be securely registered to its corresponding group agent.
When group member are changed, group key should be securely changed
and distributed to all group members.
If the group cluster header will leave, group cluster header will be
re-selected from the group members.
Group agent has information about group mapping table between device
and CN.
3. Group authentication architecture and procedures
3.1. Architecture
As shown in figure 1, the proposed group authentication architecture
is hierarchically constructed. Users (application user or service
provider) make one or more groups based on application policy or
service goal. For example, there might be a group of devices for
healthcare service and a group of devices for working, etc. The group
agent manages the groups. Also, in a group, one device can be
selected as a group cluster header which delegates authentication for
other devices in his group. We note here that a device can belong to
one or multiple groups (see the device 2 in figure 1). Group agent
Yang, et al. Expires April 19, 2016 [Page 7]
Internet-Draft draft-yang-ace-groupauth-01 October 2015
has a management function and it communicates with its corresponding
nodes. In the figure 1, CN indicates a corresponding node.
************************************************
* +-------+ *
* +device1+ +----------------------+ *
* +-------+ + device 2 + *
* +(group cluster header)+--*-----+
* +----------------------+ * |
* ############## * |
* # # * |
* # +-------+ # ****************************+-----------+ +--+
* # +device2+ * +group agent+<-->|CN|
* # +-------+ * ########################## +-----------+ +--+
* # * # |
***************** # |
# +--------------------+ # |
# +-------+ +group cluster header+--#-------+
# +device3+ +--------------------+ #
# +-------+ #
###########################################
Figure 1 Group Authentication Architecture
3.2. Group authentication procedure
In this document, we just consider on the inbound case as an initial
version of this draft. That is, we define a procedure when a
corresponding node (CN) sends a request to a group of devices. Our
procedure is divided into two phases. The first phase is the device
registration with group agent; the second phase is the group
authentication.
3.2.1. Device registration
As discussed in the former section, we assume that groups are made by
users, and each group has a header that is the representative device
of the group. The header device can be pre-configured by users or can
be selected in a dynamic fashion. The way to dynamically decide a
header device is out of scope of the current document. When a group
header is decided, the header device and its corresponding group
Yang, et al. Expires April 19, 2016 [Page 8]
Internet-Draft draft-yang-ace-groupauth-01 October 2015
agent share a secret key each other. Also, each group header forwards
the secret key to its group devices through a secure channel.
Alternatively, a group agent performs authentication procedures with
a representative header of a group of devices. The authentication
between the group agent and the header device can be done by a
general asymmetric key based method (i.e. RawPublic Key or
Certificate based mode of CoAP over DTLS binding).
3.2.2. Resource discovery
Corresponding nodes should know their group information to send group
based request message to the group agent. Therefore, we should define
procedure of gathering group information based on CoAP[RFC7252]. When
a corresponding node sends group information request messages to the
group agent like a resource discovery message in CoAP, the group
agent replies to the corresponding node with group information.
3.3. Group authentication procedure (inbound)
The general procedure of message flows from corresponding nodes to
devices is described below. A corresponding node sends the
authentication request message to its group agents. After receiving
the authentication request message, the group agent verifies the
corresponding node identity. After authentication, the corresponding
node sends the group discovery message to the group agent.
Corresponding nodes that need group information from the group agent
sends a request message (information, configuration) to the group
agent with the group ID. When a group agent receives the request
message, it looks up group ID information and forwards it to the
group cluster header that corresponds to the received group ID. The
group cluster header verifies the group agent identity and sends a
request message to devices in its group.
Yang, et al. Expires April 19, 2016 [Page 9]
Internet-Draft draft-yang-ace-groupauth-01 October 2015
Device1(A) Device2(A) Group Cluster Group Agent CN
(GCH) (A group)
| | | | |
| | | |<-Auth Req--|
| | | | |
| | | Authentication of |
| | | CN |
| | | | |
| | | |<-Group Info|
| | | | Reg |
| | | | |
| | | |Group Info->|
| | | | |
| | | |<--Req Msg--|
| | | | (group A) |
| | | | |
| | | Mapping |
| | | group |
| | | | |
| | |<----Req Msg----| |
| | | | |
| | Authentication of | |
| | GA | |
| | | | |
| |<----Req Msg-----| | |
| | | | |
| | | | |
|<---------Req Msg-------------| | |
| | | | |
Figure 2 Group Authentication Procedure
4. Consideration
In this document, we define necessary functions and procedures when
corresponding nodes send a request message to group devices. In
future work, we will refine and list more use cases requiring the
group authentication and define a function, entity, procedure and so
on. Moreover, we consider key management and dynamic key registration
within the group.
5. Security Considerations
TBD
Yang, et al. Expires April 19, 2016 [Page 10]
Internet-Draft draft-yang-ace-groupauth-01 October 2015
6. IANA Considerations
This document has no IANA actions.
7. Conclusion
In this document, we described use cases and an efficient way to
authenticate an entity for a group communication. Based on the use
cases, we will add more functions and procedures.
8. References
8.1. Normative References
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014.
[I.D.ietf-ace-usecases-04]
L. Seitz, Ed., S. Gerdes, Ed., G. Selander, M. Mani, S.
Kumar, "ACE use cases", draft-ietf-ace-usecases-04, June 04,
2015.
[I.D.ietf-dice-profile-13]
H. Tschofenig, Ed., T. Fossati," A TLS/DTLS Profile for the
Internet of Things", draft-ietf-dice-profile-13, June 11,
2015.
[RFC7228] C. Bormann, M. Ersue, A. Keranen, "Terminology for
Constrained-Node Networks", RFC7228, May, 2014.
8.2. Informative References
9. Acknowledgments
Yang, et al. Expires April 19, 2016 [Page 11]
Internet-Draft draft-yang-ace-groupauth-01 October 2015
Authors' Addresses
Hyunsik Yang
Soongsil University
369, Sangdo-ro, Dongjak-gu,
Seoul 156-743, Korea
Email: yangun@dcn.ssu.ac.kr
Youngki Park
Soongsil University
369, Sangdo-ro, Dongjak-gu,
Seoul 156-743, Korea
Email: ykpark@dcn.ssu.ac.kr
Namhi Kang
HERIT Corporation
613, Seolleung-ro, Gangnam-gu,
Seoul 135-833, Korea
Email: kang@herit.net
URI: http://www.herit.net
Younghan Kim
Soongsil University
369, Sangdo-ro, Dongjak-gu,
Seoul 156-743, Korea
Email: younghak@ssu.ac.kr
Yang, et al. Expires April 19, 2016 [Page 12]
