Internet Engineering Task Force P. Porambage
Internet-Draft P. Kumar
Intended status: Experimental A. Gurtov
Expires: June 13, 2014 M. Ylianttila
E. Harjula
CWC, University of Oulu
December 10, 2013
Certificate based keying scheme for DTLS secured IoT
draft-pporamba-dtls-certkey-01
Abstract
The IP-based Internet of Things (IoT) stands for the universal
interconnection of smart objects and back end users with the help of
IP protocols. Secure key management among the smart objects is an
important aspect of IoT security. Due to the high levels of resource
constraints of the devices in terms of memory, battery capacity and
CPU power, and other network characteristics such as mobility,
scalability, heterogeneity and limited bandwidth, the conventional
security protocols cannot be directly deployed in IoT networks in
their raw formats. We propose a lightweight DTLS-based keying
mechanism for CoAP IoT smart objects which supports the scalability
of the network and node mobility. In addition to the key
establishment part the protocol also provides node authentication.
The protocol consumes less device resources and minimum network
bandwidth by incurring low message overhead. The smart objects can
securely access the network and obtain certificates after an initial
configuration irrespective of the manufacturer standards.
Requirements Language
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].
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/.
Porambage, et al. Expires June 13, 2014 [Page 1]
Internet-Draft DTLS CERTREQ December 2013
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 June 13, 2014.
Copyright Notice
Copyright (c) 2013 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.
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.
1. Introduction
The IP-based Internet of Things (IoT) will enable smart objects to
communicate among each other and with backend users of the Internet
during different activities such as sensing, controlling, smart
metering and etc. When the IoT networks are formed with massive
number of resource constrained nodes, they are inherently vulnerable
to security attacks. Therefore, in order to acheive trustworthy data
communication, it is important to maintain a secure object
authorization mechanism and a common session key between two parties
in every application scenarios.
IoT networks and the network devices have several specific
characteristics. Mostly the devices are tightly resource constrained
in terms of memory, battery capacity, CPU power and bandwidth.
Therefore, the standard expensive IP-based protocols cannot be
deployed in such networks and inexpensive communication protocols are
required. Currently IETF is contributing to the development of
lightweight protocols for Low-power Lossy IoT networks. E.g. IPV6
over Wireless Personal Area Networks (6LoWPAN) and Constrained
Application Protocol (CoAP). Likewise security protocols have been
introduced such as DTLS, HIP-DEX and light versions of EAP. However
they are still being undergoing profiling and standardization to
Porambage, et al. Expires June 13, 2014 [Page 2]
Internet-Draft DTLS CERTREQ December 2013
incorrperate with IoT enabled smart devices. The network can be
comprised of heterogeneous devices which are manufactured by
different vendors with different specifications. Therefore, it is
quite challenging to define a common security protocol that is
compatible with all the device specifications. The devices can also
be mobile and application specific. The size of the network might be
varying from hundreds to billions of nodes.
In this draft we propose a secure network access and a key management
scheme for resource restricted IoT networks. Furthermore, we analyze
how the new protocol supports mobility of the devices and scalability
of the network. Secure network access enables the nodes to obtain
authorized identity from a trusted root. The two-phase solution is
formulated with Datagram Transport Layer Security (DTLS) handshaking
protocol. The certificate generation and key establishment are based
on Elliptic Curve Cryptography (ECC) arithmetic. The rest of the
document is organized as follows. Section 2 gives some related work
and background about DTLS secured IoT networks. Section 3 describes
the use cases and the problem statement. Section 4 presents the
proposed security scheme. Finally, Section 5 concludes the proposed
IoT security solution with future improvements.
2. Related Work and Background
DTLS protocol is an adaptation of Transport Layer Security (TLS)
protocol which runs on unreliable User Datagram Protocol (UDP)
connections [RFC6347]. Though DTLS uses similar messages as TLS
handshaking it has some internal mechanisms to withstand against DoS
attacks, replay attacks, packet losses and packet reordering.
Therefore, DTLS is proposed as the main security binding for
Constrained Application Protocol (CoAP) [I-D.ietf-core-coap].
Basically the DTLS secured CoAP has three modes of security.
PreSharedKey: A list of pre-shared keys is deployed in the network
nodes. When a connection is formed with a new node, the system
selects the appropriate key based on the new node and establishes a
DTLS session using DTLS PSK mode. This implementation is mandatory
to consider cipher suite TLS_PSK_WITH_AES_128_CCM_8 as specified in
[RFC6655] and security considerations of [RFC4279].
RawPublicKey: The DTLS enabled devices have asymmetric key pair
without an X.509 certificate. The raw public keys are pre-configured
in the devices in accordance to the cipher suite
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in
[I-D.mcgrew-tls-aes-ccm-ecc], [RFC5246], [RFC4492]. Each smart
object calculates an identifier based on its public key. The
identifiers are used to associate the endpoints with further device
information and to perform access control.
Porambage, et al. Expires June 13, 2014 [Page 3]
Internet-Draft DTLS CERTREQ December 2013
Certificate: The DTLS enabled devices have asymmetric key pair with
an X.509 certificate. The certificates are issued and signed by a
common trust root. Sometimes a device might have one or several
certificates issued by more than one certificate authority. When a
device is forming a new connection with a remote device, the
certificates should be verified.
The last two phases of DTLS based security modes are more dynamic and
scalable. Since the nodes might be manufactured by different vendors
with different specifications, it is yet an open issue to bring the
security solution to a common platform. However the use of X.509
certificates is still quite expensive for resource constrained
network devices such as tiny sensors, actuators and smart home
appliances. Instead of using a costly explicit certificate scheme,
it will be highly appropriate to replace with an implicit certificate
scheme which consumes fewer resources and induces low network
overhead. The same certificates are to be utilized in pairwise key
establishment between CoAP nodes. Though, DTLS is considered a
lighter and robust security solution, the number of message transfers
to establish the secure connection (i.e. 12 messages) still
introduces a large communication overhead. In
[I-D.garcia-core-security-05], the authors have presented the most
significant security considerations in the IP-based Internet of
Things. The internet-draft [I-D.keoh-lwig-dtls-iot] proposes
pervasive security architecture for the IoT in order to provide
network access control to smart devices, the management of keys and
securing unicast/multicast communication.
3. Use Cases and Problem Statement
Our work aims an IoT network running on 6LoWPAN/CoAP enabled smart
network devices. The network devices can be stationary or mobile,
battery powered and highly resource constrained in terms of memory
and CPU power. The communication links might have bandwidth
limitations too. In applications such as smart power metering,
health monitoring and smart home, the IoT network is connected to the
public internet through a number of 6LoWPAN border routers (6LBR).
In defining this key establishment protocol, we consider the 6LBR is
performing as the coordinator entity of the IoT network. For
instance take into account a particular scenario of a smart building
where the lighting devices, window panes and air condition machines
are controlled, monitored and billed by a central authority. The
functionality of each device is controlled by the central node, based
on the sensed data related to the network.
3.1. Problem Statement and Requirements
Porambage, et al. Expires June 13, 2014 [Page 4]
Internet-Draft DTLS CERTREQ December 2013
As explained in the previous section, DTLS plays a prominent role in
CoAP-based IoT security, even thought, it produces a reasonable
message overhead to low-power lossy networks. The demand for a
secure lightweight keying mechanism is significant for both DTLS and
non-DTLS secured IoT networks. The utilization of implicit
certificates as a replacement for X.509 certificates will also be a
low-cost solution. Therefore we identify two main problems with
security in CoAP-based IoT networks.
o A new joining device must have secure and authorized identity to
perform as legitimate nodes in the network. The nodes can claim
their legitimacy by having implicit certificates granted by a
common trust root (e.g. 6LBR).
o Lightweight pairwise key establishment is mandatory for mutual
communication between nodes or nodes and back end internet users.
The two entities should be able to use the certificates as an
implicit assurance for being legitimate users of the particular
network.
Additionally the solution requires being scalable and supporting
mobility and heterogeneity of the network devices. Since the network
might contain thousand to billions of nodes, the solution should be
easily extensible. Furthermore, since the devices have to be
accessed and controlled via standard IP protocols, the authorized
identification should be IP supportive.
3.2. Security Requirements
We consider the Internet Threat Model in [RFC3552] where a malicious
attacker can read and modify the network traffic while transmitting
between devices. However, it is assumed that the devices themselves
are protected and not exposed to node capture or compromising
attacks.
The security scheme should be lightweight as well as strongly
secured. PKC based schemes are inherently secured comparing to
symmetric key algorithms. Elliptic Curve Cryptography (ECC) which is
an inexpensive alternative for PKC is to be used for protocol design.
Random numbers are supposed to be generated as given in
[NIST-800-108].
4. Design
This section provides a brief overview of the design of the protocol
which consists of two phases as (i) secure network access and
certificate receipt (ii) secure pairwise key establishment between
communicating nodes.
Porambage, et al. Expires June 13, 2014 [Page 5]
Internet-Draft DTLS CERTREQ December 2013
4.1. Overview
The first phase associates with a new node accesses to a secure
network and obtains its authorized certificate and private key
construction data for deriving its own private-public key pair. When
a new node is added to the network with an initial configuration of
cryptographic primitives it has to generate a certificate request to
the certificate authority (CA) (i.e. 6LBR). Since the smart devices
have limited transmission they might not be able to access the trust
root or 6LBR in single hop. Therefore the certificate requests can
be sent as multiple hops by means of relaying devices. Since 6LBR is
a resource rich device, we assume that the 6LBR can directly transmit
the certificates to all the smart devices within the network as a
broadcast message. By including the identity of the recepient of the
broadcasting certificate message we can allow the nodes to keep or
discard the certificate.
The second phase of the protocol supports to establish secure traffic
encryption keys between any two legitimate nodes which can prove
their authenticity using the certificates and other cryptographic
primitives. Even a back end user of the traditional internet can
establish pairwise keys with smart devices in the IoT network after
communicating with the corresponding 6LBR. However, the users should
obviously possess the security parameters (i.e. certificate issued by
the same trust root) similar to the other nodes it the particular IoT
network. In such scenarios, the back end users also have to access
the corresponding border router initially. Afterwards the secure
communication can be established according to DTLS Certificate mode
as explained in section 4.3.
4.2. Hash Function Selection
During both phases, a cryptographic hash function has to be used. As
specified in [SEC4], hash function selection should be carefully done
for low-power devices and their security algorithms. The use of
SHA-1 is not recommended anymore due its security collapse shown by
Wang, [Collisions-SHA1]. SHA-2 and SHA-3 functions induce a high
processing overhead and memory footprint on devices which are not
affordable by resource constrained network devices. In
[I-D.ietf-suiteee], the author has proposed a suitable block cipher
based hash function for resource constrained devices. The motivation
is to use a hash function with reduced codes size, suitable for
hardware implementation, reduced computational cost and less energy
consumption, however with strong security. As explained in
[I-D.ietf-suiteee], AES-MMO (Matyas-Meyer-Oseas) hash function
provides a reasonable level of security with less resource
consumption. Specifically it supports the hardware specifications of
IEEE 802.15.4 standard including AES encryption. AES-MMO provides
Porambage, et al. Expires June 13, 2014 [Page 6]
Internet-Draft DTLS CERTREQ December 2013
128-bit security level and MD-strengthening padding scheme is used
for existing deployments in ZigBee Smart Energy applications which
reduces padding on small messages. However, the use of AES-MMO hash
function for real-time implementation requires careful
considerations.
4.3. Certificate Generation
DTLS message exchange for secure network access has to be performed
when a new node is joining to an existing IoT network. The
certificate generation is inspired by the ECQV implicit certificate
scheme presented in [SEC4]. First the node should be pre-installed
with several security parameters namely, Elliptic Curve (EC) domain
parameters (q, a, b, G - base point generator with n order, q - a
prime), authentication key K, CAs public key (Q_CA) and a valid IPV6
address. K is common to all the smart objects and trust root of the
network. Then the node can be located in the network and start
exchanging messages with the corresponding trust root (i.e. CA). The
simple timeout and retransmission scheme with the standard DTLS state
machine is also applicable to this handshaking too.
Initially the client (i.e. smart device) sends the Client Hello
message and upon receiving the message, the server (i.e. CA) verifies
the message and responds with a HelloVerifyRequest. After the client
verifies the server Hello message successfully, it generates a random
integer r_U and true nonce N_U, creates a certificate request (EC
point) R_U and sends to the server the certificate request along with
its IPV6 address and MAC value.
Upon receiving the certificate request, the server checks the
legitimacy of IPV6 address and verifies the MAC value. If both are
successful, the server computes public key reconstruction data P_U
for the client, using the request point R_U. Then the certificate is
generated as an encoded version of P_U, client IPV6 address and time
stamp T. The server computes an integer (r_U) value for calculating
client private key construction value s. Hash value of the
certificate is computed during this stage. The selection of hash
function is described in section 4.1.1. CA private key (d_CA) is
utilized while calculating s.
On receiving the certificate and private key construction integer,
the client first verifies the integrity of the message using the MAC
and analyses the certificate for further verifications.
The client calculates private key (d_U) and public key (Q_U) as
depicted in Figure 1. During this stage, the client computes its
public key by two mechanisms for authenticating whether the
certificate is granted by the given trusted root. If the
Porambage, et al. Expires June 13, 2014 [Page 7]
Internet-Draft DTLS CERTREQ December 2013
verification is successful, the client sends Finish message to the
server. Finally, the server concludes the handshaking with the
Server Finished message.
Client Server
(Node U) (CA)
-------- --------
Client Hello ---------->
<---------- HelloVerifyRequest
Certificate Request
Generation
generate r_U
R_U = r_U * G
Generate N_U
Calculate
MAC[R_U, U, N_U]
Certificate Request
R_U, N_U, U, MAC ---------->
Check validity of U
Verify MAC
Generate r_CA
P_U = R_U + r_CA * G
Cert_U = {U, P_U, T}
e = H(Cert_U)
s = e*r_CA + d_CA (mod n)
Generate N_CA
Calculate
MAC [Cert_U, s, N_CA]
Message
<---------- U,Cert_U, s, N_CA, MAC
Verify MAC
Analyze Cert_U
e = H(Cert_U)
d_U = e*r_U + s (mod n)
Method 1: Q_U = d_U*G
Method 2: Q1_U = eP_U + Q_CA
Verify Q_U == Q1_U
ClientFinished ---------->
<---------- ServerFinished
Figure 1
Porambage, et al. Expires June 13, 2014 [Page 8]
Internet-Draft DTLS CERTREQ December 2013
4.4. Secure Pairwise Key Establishment
When the IoT network nodes possess valid certificates and public-
private key pairs, they are in a position to communicate equivalently
in the Certificate mode of DTLS secured CoAP. Two smart devices can
setup a secure communication channel along with a pairwise key
establishment for traffic encryption as illustrated in Figure 2.
Here we consider the initiator node as the client and the responder
node as the server.
Client Server
(Node U) (Node V)
-------- --------
Client Hello ---------->
<---------- HelloVerifyRequest
Generate N_U
Calculate MAC [Cert_U, U, N_U]
Key Establishment Request
Cert_U, N_U, U, MAC ---------->
Check validity of U
Verify MAC
e = H(Cert_U)
Q_U = eCert_U + Q_CA
Generate N_V
Calculate MAC[Cert_V, V, N_V]
Response
<---------- Cert_V, N_V, V, MAC
Verify MAC K_UV = d_V*Q_U = d_V*d_U*G
e = H(Cert_V)
Q_V = eCert_V + Q_CA
K_UV = d_U*Q_V = d_U*d_V*G
ClientFinished ---------->
<---------- ServerFinished
Figure 2
The initial handshake is performed between the client and the server
by exchanging Hello messages according to the standard DTLS protocol.
The client node (U) chooses a true random nonce NU and broadcasts it
along with Cert_U, IPV6 address U and MAC[Cert_U, N_U, U]. Similarly
in Phase I, MAC is appended for the initial authentication. Once the
server node (V) receives the message, it verifies the MAC. If the
verification succeeds, it can ensure that U is an authenticated user.
Porambage, et al. Expires June 13, 2014 [Page 9]
Internet-Draft DTLS CERTREQ December 2013
Furthermore, V can have an implicit assurance that U is a legitimate
user of the given cluster by computing sender public key QU using
Q_CA; e = H(Cert_U) and Q_U = eCert_U + Q_CA. According to the
following derivation in Figure 3, the calculation also gives exactly
the same Q_U as computed by node U.
Q_U = d_U * G
= (er_U + s (mod n)) * G
= (er_U + er_CA + d_CA (mod n)) *G
= e (r_U + r_CA (mod n)) * G + d_CA * G
= e(r_U * G + r_CA * G) + Q_CA
= e(R_U + r_CA * G) + Q_CA
= eCert_U + Q_CA
Figure 3
Then the node V generates a random nonce NV and sends it along with
Cert_V , identity V and MAC[Cert_V , N_V , V]. In the meantime V
computes the pairwise key K_UV from its private key d_V and Q_U, K_UV
= d_V Q_U. Similar to V, upon receiving the message, node U verifies
the MAC and if the verification is successful it computes QV and K_UV
= d_UQ_V . Therefore, at the end of two way message transferring,
both parties can derive a common pairwise key for actual secure
communication.
Comparing to the standard ECDH key exchange, our scheme is more
secure since it validates the legitimacy of both parties before
deriving the final key. Instead of transmitting the public keys in
the air, the nodes send their Cert values to derive the public keys
(at the other node). This will also implicitly assure the
authenticity and legitimacy of smart objects.
Finally the handshaking is concluded by exchanging Finished messages.
We assume that DTLS handshaking messages are delivered reliably as
explained in [RFC6347].
Likewise, the same handshaking can be performed between a smart
device in the IoT network and a backend user in the Internet.
However the Internet users should also possess valid certificates
from the same trust root.
5. Conclusion
In this Internet draft we have proposed a DTLS-based certificate
scheme and a secure key establishment for IoT networks. The protocol
is lightweight and strongly secured due to the exploitation of ECC
arithmetic throughout the entire design.
Porambage, et al. Expires June 13, 2014 [Page 10]
Internet-Draft DTLS CERTREQ December 2013
Our protocol supports the scalability of the network and the topology
changes (i.e, location changes or mobility) of the smart objects with
in the same IoT network. When a new node is added to the network, a
valid node identity, keying information (i.e, K and QCA) and EC
domain parameters should be stored. Then, at the bootstrapping
phase, the node can send the certificate request and obtain a
certificate from the CA for computing its own keys. Therefore, the
size of the network is not necessary to be pre-defined during the
initial deployment phase. The CA only needs to verify the validity
of the sensor node IPV6 identities to issue the certificate.
Similarly, the nodes do not need a prior knowledge about their
neighbors. Whenever a new node is added to the network or it changes
the neighboring set, it can establish the pairwise link keys, with
the corresponding neighbors using the certificate.
The certificates always provide an implicit assurance for the nodes,
that they are authenticated nodes in the given domain. Irrespective
of the location of the devices (within the given IoT network) they
can derive the pairwise keys securely without previous awareness of
the new communicating nodes. If the pairwise keys between
communicating nodes (i.e. node to node or node to Internet user) are
pre-installed, there should be a large number of stored keys per
node, which may not be desirable for large scale networks. However,
in our protocol such a large scale key pre-installation is not
needed. Bandwidth utilization is also preserved by restricting two
message transactions for both certificate generation and key
establishment scenarios.
6. IANA Considerations
7. Security Considerations
This document discusses different design aspects of DTLS based secure
key establishment scenarios. This document is entirely focused on
security.
8. Acknowledgements
The authors would like to thank Zach Shelby for his valuable comments
and suggestions.
9. References
Porambage, et al. Expires June 13, 2014 [Page 11]
Internet-Draft DTLS CERTREQ December 2013
9.1. Normative References
[Collisions-SHA1]
Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
Full SHA-1", in Proceedings of Crypto, 2005.
[I-D.garcia-core-security-05]
Garcia-Morchon, O., Keoh, S., Kumar, S., Hummen, R., and
R. Struik, "Security Considerations in the IP-based
Internet of Things", draft-gracia-core-security-05 (work
in progress), March 2013.
[I-D.keoh-lwig-dtls-iot]
Keoh, S., Kumar, S., and O. Garcia-Morchon, "Securing the
IP-based Internet of Things with DTLS", dtraft-keoh-lwig-
dtls-iot-01 (work in progress), February 2013.
[I-D.mcgrew-tls-aes-ccm-ecc]
McGrew, D., Bailey, D., Campagna, M., and R. Dugal,
"AESCCM ECC Cipher Suites for TLS", draft-mcgrew-tls-aes-
ccm-ecc-06 (work in progress) (work in progress), February
2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
2003.
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279, December
2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
9.2. Informative References
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)", draft-ietfcore-
coap-12(work in progress) (work in progress), October
2012.
[I-D.ietf-suiteee]
Porambage, et al. Expires June 13, 2014 [Page 12]
Internet-Draft DTLS CERTREQ December 2013
Campagna, M., "A Cryptographic Suite for Embedded Systems
(SuiteE)", draft-campagna-suitee-04 (work in progress),
October 2012.
[NIST-800-108]
National Institute of Standards and Technology, "NIST SP
800-108, Recommendation for Key Derivation Using
Pseudorandom Functions", NIST Special Publication 800-108,
<http://csrc.nist.gov/publications/nistpubs/ 800-108/
sp800-108.pdf>.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, Janurary 2012.
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
Transport Layer Security (TLS)", RFC 6655, July 2012.
[SEC4] Standards for Efficient Cryptography Group, "Elliptic
Curve Qu-Vanstone Implicit Certificate Scheme (ECQV),
v0.97", SEC 4, March 2011,
<http://www.secg.org/download/aid-785/sec4-0.97.pdf>.
Authors' Addresses
Pawani Porambage
CWC, University of Oulu
P.O. Box 4500, FI-90014
Oulu
Finland
Phone: +358 8 553 2965
Email: pporamba@ee.oulu.fi
URI: http://www.cwc.oulu.fi
Pradeep Kumar
CWC, University of Oulu
P.O. Box 4500, FI-90014
Oulu
Finland
Phone: +358 8 553 2965
Email: pkumar@ee.oulu.fi
URI: http://www.cwc.oulu.fi
Porambage, et al. Expires June 13, 2014 [Page 13]
Internet-Draft DTLS CERTREQ December 2013
Andrei Gurtov
CWC, University of Oulu
P.O. Box 4500, FI-90014
Oulu
Finland
Phone: +358 40 596 3729
Email: gurtov@ee.oulu.fi
URI: http://www.cwc.oulu.fi
Mika Ylianttila
CWC, University of Oulu
P.O. Box 4500, FI-90014
Oulu
Finland
Phone: +358 40 535 0505
Email: mika.ylianttila@ee.oulu.fi
URI: http://www.cwc.oulu.fi
Erkki Harjula
CWC, University of Oulu
P.O. Box 4500, FI-90014
Oulu
Finland
Phone: +358 40 535 0505
Email: erkkih@ee.oulu.fi
URI: http://www.cwc.oulu.fi
Porambage, et al. Expires June 13, 2014 [Page 14]