< draft-schmitt-ace-twowayauth-for-iot-01.txt   draft-schmitt-ace-twowayauth-for-iot-02.txt >
ACE Working Group C. Schmitt ACE Working Group C. Schmitt
Internet-Draft B. Stiller Internet-Draft B. Stiller
Intended status: Standards Track University of Zurich Intended status: Standards Track University of Zurich
Expires: June 30, 2015 December 27, 2014 Expires: January 1, 2016 M. Noack
June 30, 2015
Two-way Authentication for IoT Two-way Authentication for IoT
<draft-schmitt-ace-twowayauth-for-iot-01> <draft-schmitt-ace-twowayauth-for-iot-02>
Abstract Abstract
In this draft the first key idea for a full two-way authentication In this draft a full two-way authentication security scheme for the
security scheme for the Internet of Things (IoT) based on existing Internet of Things (IoT) based on existing Internet standards and
Internet standards is introduced. The solution is twofold providing protocols is introduced. The solution is twofold providing a two-way
a two-way authentication for resource-rich hardware (e.g., class 2 authentication for resource-rich hardware (e.g., class 2 devices with
devices with ~50 KiB RAM and ~250 KiB ROM [RFC7228]) and for devices ~50 KiB RAM and ~250 KiB ROM [RFC7228]) and for devices with less
with less resources (e.g., class 1 devices with ~10 KiB RAM and ~100 resources (e.g., class 1 devices with ~10 KiB RAM and ~100 KiB ROM
KiB ROM [RFC7228]). By relying on an established standard, existing [RFC7228]). By relying on an established standard, existing
implementations, engineering techniques, and security infrastructure implementations, engineering techniques, and security infrastructure
can be reused, which enables an easy security uptake. The proposed can be reused, which enables an easy security uptake. The proposed
security scheme for resource-rich devices is, therefore, based on security scheme for resource-rich devices is, therefore, based on
RSA, the most widely used public key cryptography algorithm. It is RSA, the most widely used public key cryptography algorithm. It is
designed to work over standard communication stacks that offer UDP/ designed to work over standard communication stacks that offer UDP/
IPv6 networking for Low power Wireless Personal Area Networks IPv6 networking for Low power Wireless Personal Area Networks
(6LoWPANs). RSA is a bulky solution at the moment but shows that it (6LoWPANs). RSA is a bulky solution at the moment but shows that it
is possible using it on constraint devices for security purposes. An is possible using it on constraint devices for security purposes. An
optimization is the usage of elliptic curve cryptography (ECC) as optimization is the usage of elliptic curve cryptography (ECC) as
assumed for devices with less resources. assumed for devices with less resources.
skipping to change at page 1, line 46 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 30, 2015. This Internet-Draft will expire on January 1, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 34 skipping to change at page 2, line 34
3. High Level Design Requirements . . . . . . . . . . . . . . . . 5 3. High Level Design Requirements . . . . . . . . . . . . . . . . 5
3.1. Implementation of A Standards Based Design . . . . . . . . 5 3.1. Implementation of A Standards Based Design . . . . . . . . 5
3.2. Focus on Application Layer and End-to-End Security . . . . 6 3.2. Focus on Application Layer and End-to-End Security . . . . 6
3.3. Support for UDP . . . . . . . . . . . . . . . . . . . . . 6 3.3. Support for UDP . . . . . . . . . . . . . . . . . . . . . 6
4. End-to-End Security Using Two-way authentication . . . . . . . 7 4. End-to-End Security Using Two-way authentication . . . . . . . 7
4.1. Class 2 Devices or Higher . . . . . . . . . . . . . . . . 7 4.1. Class 2 Devices or Higher . . . . . . . . . . . . . . . . 7
4.1.1. Handshake Description . . . . . . . . . . . . . . . . 8 4.1.1. Handshake Description . . . . . . . . . . . . . . . . 8
4.1.2. Certificate Creation . . . . . . . . . . . . . . . . . 9 4.1.2. Certificate Creation . . . . . . . . . . . . . . . . . 9
4.2. Class 1 Devices . . . . . . . . . . . . . . . . . . . . . 10 4.2. Class 1 Devices . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Handshake . . . . . . . . . . . . . . . . . . . . . . 10
5. Architecture Description . . . . . . . . . . . . . . . . . . . 10 5. Architecture Description . . . . . . . . . . . . . . . . . . . 11
5.1. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Data Access Procedure . . . . . . . . . . . . . . . . . . 12 5.3. Data Access Procedure . . . . . . . . . . . . . . . . . . 13
6. Hardware Requirements . . . . . . . . . . . . . . . . . . . . 15 6. Hardware Requirements . . . . . . . . . . . . . . . . . . . . 15
6.1. Class 2 Hardware Requirements . . . . . . . . . . . . . . 15 6.1. Class 2 Hardware Requirements . . . . . . . . . . . . . . 15
6.2. Class 1 Hardware Requirements . . . . . . . . . . . . . . 15 6.2. Class 1 Hardware Requirements . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Class 2 Security Considerations . . . . . . . . . . . . . 15 7.1. Class 2 Security Considerations . . . . . . . . . . . . . 16
7.2. Class 1 Security Considerations . . . . . . . . . . . . . 16 7.2. Class 1 Security Considerations . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 10. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 17
10. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Norminative References . . . . . . . . . . . . . . . . . . 17 11.1. Norminative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Today, there is a multitude of envisioned and implemented use cases Today, there is a multitude of envisioned and implemented use cases
for the Internet of Things (IoT) and wireless sensor networks for the Internet of Things (IoT) and wireless sensor networks
(WSNs).In many of these scenarios it is intended to make the (WSNs).In many of these scenarios it is intended to make the
collected data globally accessible to authorized users and data collected data globally accessible to authorized users and data
processing units through the Internet. Most of these data collected processing units through the Internet. Most of these data collected
in such scenarios is of sensitive nature due to the relation to in such scenarios is of sensitive nature due to the relation to
location and personal information or IDs. Even seemingly location and personal information or IDs. Even seemingly
skipping to change at page 4, line 50 skipping to change at page 4, line 50
a HTTPS connection with the server is comparable to the approach a HTTPS connection with the server is comparable to the approach
described in this draft: The use of the DTLS protocol in an end-to- described in this draft: The use of the DTLS protocol in an end-to-
end security architecture for IoT is investigated, where a two-way end security architecture for IoT is investigated, where a two-way
authentication handshake is processed in order to establish a secured authentication handshake is processed in order to establish a secured
communication channel requiring authentication of both communication communication channel requiring authentication of both communication
parties. Due to high resource requirements, especially memory and parties. Due to high resource requirements, especially memory and
computational capacities, devices with additional hardware like TPM computational capacities, devices with additional hardware like TPM
can perform this solution (e.g., class 2 devices with ~50 KiB RAM and can perform this solution (e.g., class 2 devices with ~50 KiB RAM and
~250 KiB ROM [RFC7228]). More constraint devices (e.g., class 1 ~250 KiB ROM [RFC7228]). More constraint devices (e.g., class 1
devices with ~10 KiB RAM and ~100 KiB ROM [RFC7228]) can perform two- devices with ~10 KiB RAM and ~100 KiB ROM [RFC7228]) can perform two-
way authentication using ECC instead. way authentication using ECC [2] instead.
1.1. Document Structure 1.1. Document Structure
Section 2 mentions conventions used in this draft. Afterwards the Section 2 mentions conventions used in this draft. Afterwards the
assumed high level design requirements are briefly mentioned in assumed high level design requirements are briefly mentioned in
Section 3. Section 4 describes a two-way authentication handshake Section 3. Section 4 describes a two-way authentication handshake
for constraint devices in order to establish an end-to-end security for constraint devices in order to establish an end-to-end security
in constraint networks (e.g., wireless sensor networks). This in constraint networks (e.g., wireless sensor networks). This
section consists of two parts specifying the solution for resource- section consists of two parts specifying the solution for resource-
rich devices (class 2 devices, for example, supporting Trusted rich devices (class 2 devices, for example, supporting Trusted
skipping to change at page 5, line 47 skipping to change at page 5, line 47
Due to the usage of DTLS for establishing an end-to-end security Due to the usage of DTLS for establishing an end-to-end security
architecture for IoT three high-level design decisions have to be architecture for IoT three high-level design decisions have to be
made. made.
3.1. Implementation of A Standards Based Design 3.1. Implementation of A Standards Based Design
Standardization has helped the widespread uptake of technologies. Standardization has helped the widespread uptake of technologies.
Radio chips can rely on IEEE 802.15.4 for the physical and the MAC Radio chips can rely on IEEE 802.15.4 for the physical and the MAC
layer. Routing functionality is provided by the so-called 'IPv6 layer. Routing functionality is provided by the so-called 'IPv6
Routing Protocol for Low power and Lossy Networks' (RPL) [RFC6550] or Routing Protocol for Low power and Lossy Networks' (RPL) [RFC6550] or
6LoWPAN [RFC4944]. COAP [2] defines the application layer. So far, 6LoWPAN [RFC4944]. COAP [RFC7252] defines the application layer. So
no such efforts have addressed security in a wider context of IoT. far, no such efforts have addressed security in a wider context of
IoT.
3.2. Focus on Application Layer and End-to-End Security 3.2. Focus on Application Layer and End-to-End Security
An end-to-end protocol provides security even if the underlying An end-to-end protocol provides security even if the underlying
network infrastructure is only partially under the user's control. network infrastructure is only partially under the user's control.
As the infrastructure for Machine-to-Machine (M2M) communication is As the infrastructure for Machine-to-Machine (M2M) communication is
getting increasingly commoditized, this scenario becomes more likely: getting increasingly commoditized, this scenario becomes more likely:
The European Telecommunications Standard Institute (ETSI) plans to The European Telecommunications Standard Institute (ETSI) plans to
standardize the transport of local device data to a remote data standardize the transport of local device data to a remote data
center. For stationary installations security functionality could be center. For stationary installations security functionality could be
skipping to change at page 6, line 40 skipping to change at page 6, line 40
to a lower degree, because network stacks of both devices have to to a lower degree, because network stacks of both devices have to
support the same security protocols. support the same security protocols.
3.3. Support for UDP 3.3. Support for UDP
Reliable transport protocols like TCP incur an overhead over simpler Reliable transport protocols like TCP incur an overhead over simpler
protocols such as UDP. Especially for energy starved, battery protocols such as UDP. Especially for energy starved, battery
powered devices this overhead is often too costly and TCP has been powered devices this overhead is often too costly and TCP has been
shown to perform poorly in low-bandwidth scenarios [3]. This is shown to perform poorly in low-bandwidth scenarios [3]. This is
reflected in the design of the emerging standard COAP, which uses UDP reflected in the design of the emerging standard COAP, which uses UDP
transport and defines a binding to DTLS for security [2]. By using transport and defines a binding to DTLS for security [RFC7252]. By
DTLS in conjunction with UDP this draft does not force the using DTLS in conjunction with UDP this draft does not force the
application developer to use reliable transport - as it would be the application developer to use reliable transport - as it would be the
case if TLS would be used. It is still possible to use DTLS over case if TLS would be used. It is still possible to use DTLS over
transport protocols like TCP, since DTLS only assumes unreliable transport protocols like TCP, since DTLS only assumes unreliable
transport. transport.
This is a weaker property than the reliability provided by TCP. This is a weaker property than the reliability provided by TCP.
However, adaptations of DTLS for unreliable transport introduce However, adaptations of DTLS for unreliable transport introduce
additional overhead when compared to TLS. There MAY be a benefit in additional overhead when compared to TLS. There MAY be a benefit in
using TCP during the handshake phase but the DTLS reliability using TCP during the handshake phase but the DTLS reliability
mechanism SHOULD be adapted to the special requirements of constraint mechanism SHOULD be adapted to the special requirements of constraint
skipping to change at page 9, line 5 skipping to change at page 9, line 5
Based on the hardware equipment (cf. Section 6) the proposed two-way Based on the hardware equipment (cf. Section 6) the proposed two-way
authentication handshake has to support a solution for class 2 authentication handshake has to support a solution for class 2
devices or higher. devices or higher.
Figure 2 summarizes the message flow during the two-way Figure 2 summarizes the message flow during the two-way
authentication handshake. Here client and server represent the two authentication handshake. Here client and server represent the two
communication parties that want to exchange data. Client communication parties that want to exchange data. Client
(Subscriber) is each entity that requests data from another entity (Subscriber) is each entity that requests data from another entity
and a server (Publisher) can be each entity that has the data. and a server (Publisher) can be each entity that has the data.
Client Server Client (A) Server (B)
| | | |
|---ClientHello---------------------->| |---ClientHello------------------------------------------>|
| | | |
|<----------------ClientHelloVerify---| |<------------------------------------ClientHelloVerify---|
| | | |
|---ClientHello---------------------->| |---ClientHello------------------------------------------>|
| | | |
|<----------------------ServerHello---| | ServerHello, Certificate, |
|<----------------------Certificate---| |<-----------------[CertificateRequest],ServerHelloDone---|
|<-------------[CertificateRequest]---| | |
|<------------------ServerHelloDone---| | [Certificate], ClentKeyExchange, |
| | |---[CertificateVerify], ChangeCipherSpec, Finished------>|
|---[Certificate]-------------------->| | |
|---ClentKeyExchange----------------->| |<---------------------------ChangeCipherSpec, Finished---|
|---[CertificateVerify]-------------->| | |
|---ChangeCipherSpec----------------->| | |
|---Finished------------------------->|
| |
|<-----------------ChangeCipherSpec---|
|<-------------------------Finished---|
| |
| |
Figure 2: Message Flow of Two-way Authentication Handshake for Class Figure 2: Message Flow of Two-way Authentication Handshake for Class
2 Devices 2 Devices
4.1.2. Certificate Creation 4.1.2. Certificate Creation
When the network consists of class 2 devices or higher it is When the network consists of class 2 devices or higher it is
processed like shown in Figure 2. Before deploying the devices processed like shown in Figure 2. Before deploying the devices
certificates and individual 2048 bit RSA keys should be created and certificates and individual 2048 bit RSA keys should be created and
stored. Therefore, it is recommended to use an OpenSSL stored. Therefore, it is recommended to use an OpenSSL
skipping to change at page 10, line 10 skipping to change at page 10, line 4
* commonName = localhost * commonName = localhost
4. X509v3 extensions: 4. X509v3 extensions:
* X509v3 Basic Constraints: CA:FALSE * X509v3 Basic Constraints: CA:FALSE
* Netscape Comment: OpenSSL Generated Certificate * Netscape Comment: OpenSSL Generated Certificate
* X509v3 Subject Key Identifier * X509v3 Subject Key Identifier
* X509v3 Authority Key Identifier * X509v3 Authority Key Identifier
Depending on the implementation additional information should be Depending on the implementation additional information should be
requested that will be incorporated into the certificate request. requested that will be incorporated into the certificate request.
This informatiion may include the following: This informatiion may include the following:
1. Country Name (2 letter code) [CH] 1. Country Name (2 letter code) [CH]
2. State or Providence Name (full name) [Zurich] 2. State or Providence Name (full name) [Zurich]
3. Locality Name (e.g., city) [Zurich-Oerlikon] 3. Locality Name (e.g., city) [Zurich-Oerlikon]
4. Organization Name (e.g., company) [UZH] 4. Organization Name (e.g., company) [UZH]
5. Organisation Unit Name (e.g., section) [IFI] 5. Organisation Unit Name (e.g., section) [IFI]
6. Common Name (e.g., YOUR name) [opal-device10] 6. Common Name (e.g., YOUR name) [opal-device10]
7. Email Address [] 7. Email Address []
8. optional 8. optional
* A challenge password [] * A challenge password []
* An optional company name [] * An optional company name []
4.2. Class 1 Devices 4.2. Class 1 Devices
t.b.a. due to current investigation and implementation at department. The prosposed solution for class 1 devices requests the same network
stack as for higher devices shown in Figure 2. Instead of working
with X.509 certificates each device is deployed with an unique pre-
shared key (PSK) of 16 Byte length [2]. This key is the initial key
material that is used for resource saving ECC for performed PKC. ECC
[RFC6090] itself offers efficient algorithms (ECDSA [RFC5280], ECIES
[16], ECDH [RFC5280]) for key generation, key exchange, encryption,
decryption, and signatures. For message encryption an integrated
encryption scheme (IES) is recommendated to harness the speed-
advantage of symmetric encryption for large amount of data without
drawback of a repeated key exchange for every transmission to avoid
reusage of secrets.
4.2.1. Handshake
In order to achieve two-way authentication for class 1 devices the
Bellare-Canetti-Krawczyk (BCK) protocol [15] with pre-shared key is
recommendated [2]. Those pre-shared keys are master keys for initial
authentication between two devices (e.g., client and server).
Figure 3 shows the recommendated handshake between two devices.
ECC is used for key generation, key exchange, encryption, decryption,
and signatures during the data exchange. The public ECC keys are
decomposed into x and y-coordinates for easy handling on the mote
side. Elliptic Curve Digital Signature Algorithm (ECDSA) signatures
are integer keypairs, written as (r, s), and therefore difficult to
include in a fixed-length packet, because the bit-length of the
hexadecimal representation of large integers may vary. [2]
Client (A) Server (B)
| |
|---------- X_A, H(K, X_A) -------------->|
| |
|<-- X_B, Sig_B (X_B,X_A, A), H(K, X_B) --|
| |
|-------- Sig_A (X_A, X_B, B) ----------->|
| |
Figure 3: Message Flow of Two-way Authentication Handshake for Class
1 Devices
X_A is the public key of client (A), respectivly X_B of server (B).
Sig_A is the signature of client (A), respectively Sig_B of server
(B). K represents the PSK. H is a hash function created from the
PSK and the corresponding public key, resulting in H(K, X_A) or H(K,
X_B).
5. Architecture Description 5. Architecture Description
As briefly mentioned in Section 1 data is connected to sensitive As briefly mentioned in Section 1 data is connected to sensitive
information and can lead to potential infringements in the users' information and can lead to potential infringements in the users'
privacy. This fact becomes a security risk if the data is privacy. This fact becomes a security risk if the data is
transmitted over long distances, perhaps several hops, to a specified transmitted over long distances, perhaps several hops, to a specified
global sink [10]. Depending on the setting it might happen that the global sink [10]. Depending on the setting it might happen that the
data is also transmitted via the Internet and might be cached in data is also transmitted via the Internet and might be cached in
between. The latter case is inspired by the project FLAMINGO, which between. The latter case is inspired by the project FLAMINGO, which
skipping to change at page 11, line 47 skipping to change at page 12, line 46
5.2. Requirements 5.2. Requirements
In order to show the applicability of the proposed solution In order to show the applicability of the proposed solution
throughout the above sections a common network structure consisting throughout the above sections a common network structure consisting
of a global sink and several sensor nodes is assumed. Additionally, of a global sink and several sensor nodes is assumed. Additionally,
an Access Control Server (ACS) is integrated into the network. The an Access Control Server (ACS) is integrated into the network. The
ACS is a trusted entity and a more resource-rich server, on which the ACS is a trusted entity and a more resource-rich server, on which the
access rights for the publishers (= sensor nodes) of the secured access rights for the publishers (= sensor nodes) of the secured
network are stored. Therefore, every publisher in the network MUST network are stored. Therefore, every publisher in the network MUST
have an unique identity. Figure 3 illustrates the assumed have an unique identity. Figure 4 illustrates the assumed
architecture, where it is assumed that also the subscriber, architecture, where it is assumed that also the subscriber,
publisher, and sensors have individual certificates received from the publisher, and sensors have individual certificates received from the
Certificate Authority. Depending on individual architectural setups Certificate Authority. Depending on individual architectural setups
it can be possible to integrate the ACS functionality direct into the it can be possible to integrate the ACS functionality direct into the
gateway. gateway.
+-----------------------+ +----------------------------+
| Certificate Authority | | Certificate Authority (CA) |
+-----------------------+ +----------------------------+
| |
| | | |
+------------+ +----------------------------+ +---------+ +----------------+ +----------------------------+ +---------+
| Subscriber |-----| Access Control Server (ACS)|----| Gateway | | Subscriber (S) |-----| Access Control Server (ACS)|----| Gateway |
+------------+ +----------------------------+ +---------+ +----------------+ +----------------------------+ +---------+
|
| |
+-----------+ +---------------+
| Publisher | | Publisher (P) |
+-----------+ +---------------+
| |
+------------+----------------+ +------------+----------------+
| | | | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| Sensor 1 | | Sensor 2 | ... | Sensor n | | Sensor 1 | | Sensor 2 | ... | Sensor n |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Figure 3: Architecture Figure 4: Architecture
As mentioned the concept of Internet of Things forms the basis for As mentioned the concept of Internet of Things forms the basis for
this draft, which include also the basic understanding of the this draft, which include also the basic understanding of the
Internet. Thus, it is assumed that identities are usually Internet. Thus, it is assumed that identities are usually
established via public key cryptography and the identifiers provided established via public key cryptography and the identifiers provided
through X.509 certificates [RFC5280]. In general, X.509 certificate through X.509 certificates [RFC5280]. In general, X.509 certificate
contains the public key of an entity and its common name. A trusted contains the public key of an entity and its common name. A trusted
third party - Certificate Authority (CA) - signs that certificate. third party - Certificate Authority (CA) - signs that certificate.
This signing allows the receiver to detect modifications to the This signing allows the receiver to detect modifications to the
certificate and that the identity of the entity, who requested the certificate and that the identity of the entity, who requested the
skipping to change at page 13, line 4 skipping to change at page 13, line 46
administrator of the network or an established Internet certificate administrator of the network or an established Internet certificate
authority can be used. authority can be used.
Furthermore, it is assumed that the identity of a default subscriber Furthermore, it is assumed that the identity of a default subscriber
is usually preconfigured on a publisher before it is deployed. is usually preconfigured on a publisher before it is deployed.
5.3. Data Access Procedure 5.3. Data Access Procedure
Based on the FLAMINGO project the following use-case is assumed [9]: Based on the FLAMINGO project the following use-case is assumed [9]:
A sensor node has published its data, which is transmitted in A sensor node has published its data, which is transmitted in
direction to the global sink (cf. Figure 3 where global sink is direction to the global sink (cf. Figure 4 where global sink is
located in the gateway component). Therefore, it is assumed that a located in the gateway component). Therefore, it is assumed that a
two-way authentication handshake between those two communication two-way authentication handshake between those two communication
parties was successful performed before. In between the data can be parties was successful performed before. In between the data can be
cashed in order to make it accessible more quicker to subscribers. cashed in order to make it accessible more quicker to subscribers.
In this case the cached entity functions as a publisher. In this case the cached entity functions as a publisher.
Assuming the new subscriber wants to access the data, it must Assuming the new subscriber wants to access the data, it must
initialize a connection with the publisher. Therefore, the initialize a connection with the publisher. Therefore, the
subscriber MUST obtain an access ticket from the ACS before. The subscriber MUST obtain an access ticket from the ACS before. The
functionality of the ACS is to verify that the subscriber has the functionality of the ACS is to verify that the subscriber has the
skipping to change at page 13, line 26 skipping to change at page 14, line 23
are influenced by legal and regulative implications (e.g., rights are influenced by legal and regulative implications (e.g., rights
connected to an ISP region, where the subscriber belongs to). If the connected to an ISP region, where the subscriber belongs to). If the
subscriber received a valid access ticket, it is presented to the subscriber received a valid access ticket, it is presented to the
publisher. The publisher must evaluate the identity of the publisher. The publisher must evaluate the identity of the
subscriber and verify the ticket it has received from the ACS. subscriber and verify the ticket it has received from the ACS.
If the validation was successful the subscriber can access the data. If the validation was successful the subscriber can access the data.
Before every kind of data exchange, where sensitive information is Before every kind of data exchange, where sensitive information is
involved, takes place the proposed two-way authentication handshake involved, takes place the proposed two-way authentication handshake
is performed in order to establish a highly secured communication is performed in order to establish a highly secured communication
channel between the entities. Figure 4 summarizes the aforementioned channel between the entities. Figure 5 summarizes the aforementioned
work flow and will be defined in detail in the upcoming subsections work flow and will be defined in detail in the upcoming subsections
assuming that the ACS functionality is included in the Gateway assuming that the ACS functionality is included in the Gateway
component. component.
Gateway Subscriber (S) Gateway (incl. ACS) Publisher (P)
Subscriber (incl. ACS) Publisher | | |
| | | | | Two-way |
| | | | |<-------Authentication Handshake---->|
| | Two-way | | | |
| |<-------authentication---->| | |<------Measured Data-----------------|
| | Handshake | | | |
| | | | Two-way | |
| | | |<--authentication Handshake -->| |
| |<------Measured Data-------| | | |
| | | |---Connection request for P--->| |
| Two-way | | | | |
|<--authentication -->| | | Check of Request |
| Handshake | | | | |
| | | |<---Copy of Access Ticket------+-----Subscriber's Access ticket----->|
| | | | | |
| Connection | | | | Validation of
|------- request ---->| | | | Access Ticket
| for Publisher | | | | |
| | | | Two-way authentication handshake between |
| | | |<------------------------------------------------------------------->|
| Check of | | Subscriber and Publisher |
| Request | | | |
| | | |<-------------Data exchange using DTLS secured channel-------------->|
| | | | | |
| Copy of | Subscriber`s | | | |
|<------ Access ------+-------Access ticket------>|
| Ticket | |
| | |
| | Validation of
| | Access Ticket
| | |
| | |
| Two-way authentication handshake between |
|<----------------------------------------------->|
| Subscriber and Publisher |
| | |
| | |
|<---Data exchange using DTLS secured channel---->|
| | |
| | |
Figure 4: Flow Diagram for Data Access Procedure Figure 5: Flow Diagram for Data Access Procedure
6. Hardware Requirements 6. Hardware Requirements
6.1. Class 2 Hardware Requirements 6.1. Class 2 Hardware Requirements
Hu et al. showed that RSA, the most commonly used public key Hu et al. showed that RSA, the most commonly used public key
algorithm in the Internet, can be used in sensor networks with the algorithm in the Internet, can be used in sensor networks with the
assistance of a class 2 devices that MAY include a TPM, which costs assistance of a class 2 devices that MAY include a TPM, which costs
less than 5% of a common sensor node [4]. A TPM is an embedded chip less than 5% of a common sensor node [4]. A TPM is an embedded chip
that provides tamper proof generation and storage of RSA keys as well that provides tamper proof generation and storage of RSA keys as well
skipping to change at page 15, line 27 skipping to change at page 16, line 9
For publishers that are not equipped with TPM chips the For publishers that are not equipped with TPM chips the
authentication can be proposed via the DTLS pre-shared key cipher- authentication can be proposed via the DTLS pre-shared key cipher-
suite, which requires a small number of random bytes, from which the suite, which requires a small number of random bytes, from which the
actual key is derived, to be preloaded to the publisher before actual key is derived, to be preloaded to the publisher before
deployment. This secret MUST also be made available to the ACS, deployment. This secret MUST also be made available to the ACS,
which will disclose the key to devices with sufficient authorization. which will disclose the key to devices with sufficient authorization.
6.2. Class 1 Hardware Requirements 6.2. Class 1 Hardware Requirements
t.b.a. No hardware requirements.
7. Security Considerations 7. Security Considerations
7.1. Class 2 Security Considerations 7.1. Class 2 Security Considerations
The following security goals are addressed by the key idea presented The following security goals are addressed by the key idea presented
in this draft: in this draft:
Authenticity Authenticity
skipping to change at page 16, line 49 skipping to change at page 17, line 34
BLIP - Berkeley Low-power IP stack BLIP - Berkeley Low-power IP stack
CA - Certificate Authority CA - Certificate Authority
COAP - Constrained Application Protocol COAP - Constrained Application Protocol
DTLS - Datagram Transport Layer Security protocol (RFC 6347) DTLS - Datagram Transport Layer Security protocol (RFC 6347)
ECC - Elliptic Curve Cryptography ECC - Elliptic Curve Cryptography
ECDH - Elliptic Curve Diffie-Hellman
ECDSA -Elliptic Curve Digital Signature Algorithm
ECIES - Elliptic Curve Integrated Encryption System
ETSI - European Telecommunications Standard Institute ETSI - European Telecommunications Standard Institute
HVAC - Heating, Ventilation, and Air Conditioning HVAC - Heating, Ventilation, and Air Conditioning
IEC - Integrated Encryption Scheme
IoT - Internet of Things IoT - Internet of Things
KiB - Kibi-Byte (1 KiB = 1024 Bytes) [14] KiB - Kibi-Byte (1 KiB = 1024 Bytes) [14]
PKC - Public Key Cryptography PKC - Public Key Cryptography
PSK - Pre-shared Key
RPL - Routing Protocol for Low power and Lossy Networks (RFC 6550) RPL - Routing Protocol for Low power and Lossy Networks (RFC 6550)
TCP - Transmission Control Protocol (RFC 793) TCP - Transmission Control Protocol (RFC 793)
TLS - The Transport Layer Security (TLS) Protocol Version 1.2 (RFC TLS - The Transport Layer Security (TLS) Protocol Version 1.2 (RFC
5246) 5246)
TPM - Trusted Platform Module TPM - Trusted Platform Module
skipping to change at page 17, line 47 skipping to change at page 18, line 41
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012. Lossy Networks", RFC 6550, March 2012.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, September 2007.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[2] Shelby et al., Z., "Constrained Application Protocol [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
(CoAP), the Elliptic Curve Digital Signature Algorithm (ECDSA)",
http://tools.ietf.org/html/draft-ietf-core-coap-14", RFC 4754, January 2007.
March 2013.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014.
[3] Balakrishnan, H., Padmanabhan, V., Seshan, S., and R. [3] Balakrishnan, H., Padmanabhan, V., Seshan, S., and R.
Katz, "A Comparison Of Mechanisms For Improving TCP Katz, "A Comparison Of Mechanisms For Improving TCP
Performance Over Wireless Links", IEEE/ACM Transaction on Performance Over Wireless Links", IEEE/ACM Transaction on
Networking, Vol. 5, No. 6, pp. 756-769 , 1997. Networking, Vol. 5, No. 6, pp. 756-769 , 1997.
[5] Modadugu et al., N., "The Design and Implementation of [5] Modadugu et al., N., "The Design and Implementation of
Datagram TLS", In Proceedings of the Network and Datagram TLS", In Proceedings of the Network and
Distributed System Security Symposium (NDSS), San Diego, Distributed System Security Symposium (NDSS), San Diego,
California, U.S.A. , 2004. California, U.S.A. , 2004.
skipping to change at page 18, line 44 skipping to change at page 19, line 43
Journal Ad Hoc Networks , 2013. Journal Ad Hoc Networks , 2013.
[7] Dawson-Haggerty, S. and D. Culler, "Berkeley IP [7] Dawson-Haggerty, S. and D. Culler, "Berkeley IP
Information, Berkeley WEBS Wireless Embedded Systems, Information, Berkeley WEBS Wireless Embedded Systems,
http://smote.cs.berkeley.edu:8000/tracenv/wiki/blip", http://smote.cs.berkeley.edu:8000/tracenv/wiki/blip",
2010. 2010.
[8] SmartenIT Consortium, "Socially-aware Management of New [8] SmartenIT Consortium, "Socially-aware Management of New
Overlay Application Traffic combined with Energy Overlay Application Traffic combined with Energy
Efficiency in the Internet (SmartenIT), Efficiency in the Internet (SmartenIT),
http://www.smartenit.eu/", 20103. http://www.smartenit.eu/", 2013.
[9] Flamingo Consortium, "FLAMINGO - Management of the Future [9] Flamingo Consortium, "FLAMINGO - Management of the Future
Internet, http://www.fp7-flamingo.eu/", 2013. Internet, http://www.fp7-flamingo.eu/", 2013.
[10] Schmitt, C., "Secure Data Transmission in Wireless Sensor [10] Schmitt, C., "Secure Data Transmission in Wireless Sensor
Networks, Dissertation", Network Architectures and Networks, Dissertation", Network Architectures and
Services (NET), ISBN: 3-937201-36-X, ISSN: 1868-2634 Services (NET), ISBN: 3-937201-36-X, ISSN: 1868-2634
(print), DOI: 10.2313/NET-2013-07-2 , 2013. (print), DOI: 10.2313/NET-2013-07-2 , 2013.
[11] Boyd, C. and A. Mathuria, "Protocols for Authentication [11] Boyd, C. and A. Mathuria, "Protocols for Authentication
and Key Establishment (Information Security and and Key Establishment (Information Security and
Cryptography)", Springer, ISBN 3540431071 , 2003. Cryptography)", Springer, ISBN 3540431071 , 2003.
[13] "OpenSSL - Cryptography and SSL/TLS Toolkit, [13] "OpenSSL - Cryptography and SSL/TLS Toolkit,
https://www.openssl.org/", 2014. https://www.openssl.org/", 2014.
[14] "International Standard - Quantities and units - Part 13: [14] "International Standard - Quantities and units - Part 13:
Information science and technology", IEC 80000-13 , 2008. Information science and technology", IEC 80000-13 , 2008.
[15] Bellare, M., Canetti, R., and H. Krawczyk, "A Modular
Approach to the Design and Analysis of Authentication and
Key Exchange Protocols (Extended Abstract)", In
Proceedings of the 13th Annual ACM Symposium on Theory of
Computing, ser. STOC , 2008.
[16] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook
of Applied Cryptography", ICRC Press, ISBN:
0-8493-8523-7 , 1996.
[2] Noack, M., "Optimization of Two-way Authentication
Protocol in Internet of Things", Master Thesis, University
of Zurich, Communication Systems Group, Department of
Informatics, Zurich, Switzerland , 2014.
Authors' Addresses Authors' Addresses
Corinna Schmitt Corinna Schmitt
Univerity of Zurich University of Zurich
Department for Informatics Department for Informatics
Communication Systems Group Communication Systems Group
Binzmuehlestrasse 14 Binzmuehlestrasse 14
Zurich 8050 Zurich 8050
Switzerland Switzerland
Email: schmitt@ifi.uzh.ch Email: schmitt@ifi.uzh.ch
Burkhard Stiller Burkhard Stiller
Univerity of Zurich University of Zurich
Department for Informatics Department for Informatics
Communication Systems Group Communication Systems Group
Binzmuehlestrasse 14 Binzmuehlestrasse 14
Zurich 8050 Zurich 8050
Switzerland Switzerland
Email: stiller@ifi.uzh.ch Email: stiller@ifi.uzh.ch
Martin Noack
Email: martin.noack@acm.org
 End of changes. 41 change blocks. 
119 lines changed or deleted 173 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/