# Compact Extensible Authentication Protocol for the Internet of Things: Enabling Scalable and Efficient Security Commissioning

Authors: Marcin Piotr Pawlowski; Antonio J. Jara; Maciej J. Ogorzalek
Journal: Mobile Information Systems
 (2015)

---

## Abstract

Internet of Things security is one of the most challenging parts of the domain. Combining strong cryptography and lifelong security with highly constrained devices under conditions of limited energy consumption and no maintenance time is extremely difficult task. This paper presents an approach that combines authentication and bootstrapping protocol (TEPANOM) with Extensible Authentication Protocol (EAP) framework optimized for the IEEE 802.15.4 networks. The solution achieves significant reduction of network resource usage. Additionally, by application of EAP header compacting approach, further network usage savings have been reached. The EAP-TEPANOM solution has achieved substantial reduction of 42% in the number of transferred packets and 35% reduction of the transferred data. By application of EAP header compaction, it has been possible to achieve up to 80% smaller EAP header. That comprises further reduction of transferred data for 3.84% for the EAP-TEPANOM method and 10% for the EAP-TLS-ECDSA based methods. The results have placed the EAP-TEPANOM method as one of the most lightweight EAP methods from ones that have been tested throughout this research, making it feasible for large scale deployments scenarios of IoT.


---

## Body

## 1. Introduction

One of disrupting technologies that has a big impact on our lives has been the Internet of Things (IoT) [1, 2]. It has been expected that, by the year 2020, billions of new IoT devices will be connected and deployed around the world [3]. Homes, hospitals, offices, cars, and even cities will be filled with myriads of new devices that will be responsible for wellbeing and safety of its users [4–7]. Consequently, IoT needs to be reliable and easy to use and secure and provide mechanisms for scalable seamless commissioning.One of the major challenges in the IoT has been the security [8, 9]. High constraints of IoT devices communications and memory and computation capabilities and limited entropy sources [10] in conjunction with the fact that most of devices have been battery operated and have limited remote maintenance capabilities [11] have made security a very challenging goal. Therefore, IoT requires security solutions to be as lightweight as possible and as secure as possible—combination hard to achieve. Furthermore, designed solutions should be easy to use and should not require any human intervention during their lifetime. Additionally, IoT presents new challenges for the bootstrapping and commissioning of billions of deployed devices. Such processes need to be executed without any maintenance time or human intervention.Many efforts have been carried out by research community addressing security issues of the IoT. The most notable attempts have been coming from the Internet Engineering Task Force (IETF) Datagram Transport Layer Security In Constrained Environments (DICE) [12] working group that has focused on adaptation of theTransport Layer Security (TLS) protocol for protection of the end-to-end communication of constrained IoT devices [13]. Additionally, the IETF working group Authentication and Authorization for Constrained Environments (ACE) has been addressing problems of secure and privacy oriented authorization and authentication in the IoT networks [14].The main motivation behind this research has been the need to address issues of very lightweight, flexible, scalable, and secure solution for authentication and bootstrapping of constrained devices in the IoT networks. In the environment with overwhelming number of deployed IoT devices new solutions are required to enable secure and scalable management. First step in managing of such enormous number of devices has to be provided already during the deployment phase. The installation and initial set-up of the device need to be seamless and should be done in a place-and-move-along manner. Person responsible for the deployment should only put the device in desired place and walk away: the device should do the rest in a secure way. This is the ideal approach towards which presented solution has been pursuing.First contribution of this paper has been the combination ofTrust Extension Protocol for Authentication of New deployed Objects and sensors through the Manufacturer (TEPANOM) bootstrapping and authentication solution withExtensible Authentication Protocol (EAP) authentication framework that has been enabled to work over IEEE 802.15.4 networks throughSlim Extensible Authentication Protocol Over Low-Rate Wireless Personal Area Networks (SEAPOL) adaptation layer [15]. The EAP-TEPANOM solution has achieved substantial reduction of 42% in the number of transferred packets and 35% reduction of the transferred data.Second contribution of this paper has been the compacted version of the EAP which achieved further minimization of the transmitted data. Application of the EAP header compaction constituted reduction of up to 80% of the EAP header size. That comprises further reduction of up to 10% of transferred data.The rest of the paper is organized as follows. Section2 introduces briefly the secure commissioning and current state-of-the-art solutions alongside with the descriptions of the EAP, SEAPOL adaptation layer, and TEPANOM solution. In Section 3 the EAP-TEPANOM solution has been presented. Section 4 presents header compaction solution for the EAP. Section 5 briefly analyzes security of the proposed solutions. The network usage evaluation results have been presented in Section 6. In Section 7 the energy analysis of proposed solutions has been presented. Section 8 concludes the paper and addresses the next research steps.


## 2. Secure Commissioning

Throughout this paper, thecommissioning term has been defined as the process of verification and configuration of the deployed equipment. The commissioning consists of two stages, first, the authentication during which deployed devices present their credentials to the network security management mechanism and, second, the bootstrapping stage that is responsible for providing necessary information to deployed devices to enable their functionality, like shared keys negotiation for secure communication.From the perspective of the security of the commissioning process the description of the state of the art has been limited to the authentication and key establishments mechanisms for the constrained networks.In [16] the authors present an authentication and key establishment scheme for WSNs in distributed IoT applications. It has been based on a simplifiedDatagram Transport Layer Security (DTLS) [12] exchange and the use of elliptic curve cryptography through TinyECC implementation [17].One of the most promising bootstrapping security protocols has been theHost Identity Protocol-Diet EXchange (HIP-DEX) [18]. Its use for the network access stage has been analyzed in [19]. Although presented results have been promising, compared to the DTLS protocol, the HIP-DEX has not been widely adopted. This has been mainly related to the fact that HIP-DEX does not use certificate-based public key agreement. Additionally, high complexity of the puzzle mechanism responsible for mitigation of the DoS attacks also limits its usability.Another noteworthy bootstrapping security protocol has been based on theProtocol for Carrying Authentication for Network Access (PANA) [20]. In [21] the usage of PANA in networking environment of constrained IoT devices has been presented. The authors showedPANATIKI solution which has been a lightweight implementation of PANA that has been suitable for constrained IoT devices. TheExtensible Authentication Protocol-Pre-Shared Key (EAP-PSK) [22] has been used as the authentication mechanism. Usage of symmetric key cryptography (EAP-PSK) has been motivated by reduction of high computational costs in comparison to the public key cryptography operations. Unfortunately, the EAP-PSK provides lower degree of scalability and security than public key based authentication mechanisms.All of the above solutions share common issue: they require IP connectivity before the authentication phase. In some cases this might introduce potential security threats. The approach presented in this paper has been based on the link layer and does not require involving higher layer connectivity before authenticating the device.In the following subsections related works have been briefly described on which the solution presented in this paper has been based.


### 2.1. EAP over SEAPOL Adaptation Layer

In this subsection basic information aboutExtensible Authentication Protocol (EAP) and its adaptation layer for the IEEE 802.15.4 networks has been provided.The EAP has been selected as a mechanism for securing the commissioning in IoT networks, based on three observations. First, the EAP has been one of the most commonly used authentication protocols in the Wireless Local Area Networks and it supports many different authentication mechanisms. Second, it works on the link layer; thus it introduces lower communication overhead in comparison to different authentication mechanisms—energy consumption is important for constrained IoT devices. Third, the protocol is flexible and does not require globally centralized infrastructure. Therefore, it provides good scaling capabilities. All of these make the EAP the best choice for secure commissioning solution that combines strong security (like ECC certificates and EAP-TLS authentication method) with lightweight link-layer transmission and scalable, globally decentralized infrastructure.The EAP has been a part of the infrastructure specified in the IEEE 802.1X standard [23]. The standard describes comprehensive authentication solution that consists of three services (Authentication Server,Authenticator, andSupplicant), with additional definition of protocol to transfer the EAP frames over the Local Area Networks (EAPOL). Subsequent standard IEEE 802.11i extends the usage of EAPOL protocol over Wireless Local Area Networks [24]. The communication between the Authenticator and the Authentication Server has been realized by the RADIUS protocol and has been defined in [25]; additional protocols such as Diameter also can be used for transporting the EAP Packets [26].The simple schema showing IEEE 802.1X communication has been presented in Figure1.Figure 1
Schema of IEEE 802.1X secured networks architecture.TheExtensible Authentication Protocol has been defined in the RFC 3748 standard as an authentication framework that provides common functions for the authentication mechanisms [27]. The standard has not defined any authentication mechanism, except MD5 based one, that has been exemplary and totally insecure. The authentication mechanisms have been defined in many subsequent documents like Pre-Shared Key [22] or Transport Layer Security (TLS) [28] based mechanisms. In the EAP nomenclature the authentication mechanisms have been called EAP methods.The EAP communication consists mostly of the Request-Response datagram exchange between the Authenticator and the Supplicant. During this, at first the authentication method is negotiated. Then, the Request-Response datagram exchange carries the negotiated authentication method data. And, finally, the authentication procedure one final Success or Failure datagram is sent to the Supplicant.


### 2.2. SEAPOL-IEEE 802.15.4 Adaptation Layer

The EAP has its link layer transmission mechanisms defined for IEEE 802.1 wired [23] and IEEE 802.11 wireless [24] networks. Officially, such mechanism has not been defined for the IEEE 802.15.4 standard [29], although recently in [30] the EAPOL protocol has been adopted for the needs of the IEEE 802.15.4 link layer [29] and subsequently optimized asSlim Extensible Authentication Protocol Over Low-Rate Wireless Personal Area Networks (SEAPOL).The improved version of the EAPOL protocol has been designed after careful analysis of the regular EAPOL protocol. It has been noticed that only 5 different frame types can represent the full functionality of the regular EAPOL protocol. Additionally the EAPOL Start and EAP Packet frames can be easily differentiated by the frame payload size, and therefore they can use the same frame type. That led to the definition of theSlim EAPOL (SEAPOL) that represents full EAPOL functionality in just 3 bits (93.75% less overhead in comparison to the regular EAPOL) and, additionally, it has been fully integrated with the Frame Control field of the IEEE 802.15.4 protocol reducing the frame overhead to zero. The IEEE 802.15.4 Frame Control field modifications of SEAPOL protocol have been presented in Figure 2.Figure 2
IEEE 802.15.4 Frame Control field modifications to support Slim Extensive Authentication Protocol Over Low-Rate Wireless Personal Area Networks (SEAPOL).


### 2.3. TEPANOM Protocol

Trust Extension Protocol for Authentication of New deployed Objects and sensors through the Manufacturer (TEPANOM) has been defined as a solution for authentication, identity verification, bootstrapping, configuration, and trust extension of the deployment and management domains to the new device [31]. The TEPANOM protocol consists of two phases, theAuthentication and theTrust Extension.


#### 2.3.1. Trust Extension

TheTrust Extension phase of the TEPANOM protocol has been designed to register methods and resources of the new device and to establish new shared key between the protocol actors. In this paper theTrust Extension phase of the TEPANOM protocol will be not addressed any further, and therefore for more details please refer to [31].


#### 2.3.2. Authentication

TheAuthentication phase of the TEPANOM protocol has been designed to authenticate the device and its features to the manufacturer through theTEPANOM-Authentication-Point. From the perspective of the network communication, three different actors have been defined, theTEPANOM-Client,TEPANOM-Gateway, and already mentionedTEPANOM-Authentication-Point. TheTEPANOM-Client is a constrained IoT device that is authenticating to theTEPANOM-Authentication-Point. The authentication process is done through theTEPANOM-Guard that is the gateway between the unauthenticated devices and the privileged parts of the network. TheTEPANOM-Guard has been responsible for protecting theTEPANOM-Authentication-Point against Denial-of-Service attacks, which could have been executed by maliciousTEPANOM-Clients. TheTEPANOM-Authentication-Point has been responsible for authenticating theTEPANOM-Client and providing theDataSheet which is extended description of device resources, capabilities, and methods.


## 2.1. EAP over SEAPOL Adaptation Layer

In this subsection basic information aboutExtensible Authentication Protocol (EAP) and its adaptation layer for the IEEE 802.15.4 networks has been provided.The EAP has been selected as a mechanism for securing the commissioning in IoT networks, based on three observations. First, the EAP has been one of the most commonly used authentication protocols in the Wireless Local Area Networks and it supports many different authentication mechanisms. Second, it works on the link layer; thus it introduces lower communication overhead in comparison to different authentication mechanisms—energy consumption is important for constrained IoT devices. Third, the protocol is flexible and does not require globally centralized infrastructure. Therefore, it provides good scaling capabilities. All of these make the EAP the best choice for secure commissioning solution that combines strong security (like ECC certificates and EAP-TLS authentication method) with lightweight link-layer transmission and scalable, globally decentralized infrastructure.The EAP has been a part of the infrastructure specified in the IEEE 802.1X standard [23]. The standard describes comprehensive authentication solution that consists of three services (Authentication Server,Authenticator, andSupplicant), with additional definition of protocol to transfer the EAP frames over the Local Area Networks (EAPOL). Subsequent standard IEEE 802.11i extends the usage of EAPOL protocol over Wireless Local Area Networks [24]. The communication between the Authenticator and the Authentication Server has been realized by the RADIUS protocol and has been defined in [25]; additional protocols such as Diameter also can be used for transporting the EAP Packets [26].The simple schema showing IEEE 802.1X communication has been presented in Figure1.Figure 1
Schema of IEEE 802.1X secured networks architecture.TheExtensible Authentication Protocol has been defined in the RFC 3748 standard as an authentication framework that provides common functions for the authentication mechanisms [27]. The standard has not defined any authentication mechanism, except MD5 based one, that has been exemplary and totally insecure. The authentication mechanisms have been defined in many subsequent documents like Pre-Shared Key [22] or Transport Layer Security (TLS) [28] based mechanisms. In the EAP nomenclature the authentication mechanisms have been called EAP methods.The EAP communication consists mostly of the Request-Response datagram exchange between the Authenticator and the Supplicant. During this, at first the authentication method is negotiated. Then, the Request-Response datagram exchange carries the negotiated authentication method data. And, finally, the authentication procedure one final Success or Failure datagram is sent to the Supplicant.


## 2.2. SEAPOL-IEEE 802.15.4 Adaptation Layer

The EAP has its link layer transmission mechanisms defined for IEEE 802.1 wired [23] and IEEE 802.11 wireless [24] networks. Officially, such mechanism has not been defined for the IEEE 802.15.4 standard [29], although recently in [30] the EAPOL protocol has been adopted for the needs of the IEEE 802.15.4 link layer [29] and subsequently optimized asSlim Extensible Authentication Protocol Over Low-Rate Wireless Personal Area Networks (SEAPOL).The improved version of the EAPOL protocol has been designed after careful analysis of the regular EAPOL protocol. It has been noticed that only 5 different frame types can represent the full functionality of the regular EAPOL protocol. Additionally the EAPOL Start and EAP Packet frames can be easily differentiated by the frame payload size, and therefore they can use the same frame type. That led to the definition of theSlim EAPOL (SEAPOL) that represents full EAPOL functionality in just 3 bits (93.75% less overhead in comparison to the regular EAPOL) and, additionally, it has been fully integrated with the Frame Control field of the IEEE 802.15.4 protocol reducing the frame overhead to zero. The IEEE 802.15.4 Frame Control field modifications of SEAPOL protocol have been presented in Figure 2.Figure 2
IEEE 802.15.4 Frame Control field modifications to support Slim Extensive Authentication Protocol Over Low-Rate Wireless Personal Area Networks (SEAPOL).


## 2.3. TEPANOM Protocol

Trust Extension Protocol for Authentication of New deployed Objects and sensors through the Manufacturer (TEPANOM) has been defined as a solution for authentication, identity verification, bootstrapping, configuration, and trust extension of the deployment and management domains to the new device [31]. The TEPANOM protocol consists of two phases, theAuthentication and theTrust Extension.


### 2.3.1. Trust Extension

TheTrust Extension phase of the TEPANOM protocol has been designed to register methods and resources of the new device and to establish new shared key between the protocol actors. In this paper theTrust Extension phase of the TEPANOM protocol will be not addressed any further, and therefore for more details please refer to [31].


### 2.3.2. Authentication

TheAuthentication phase of the TEPANOM protocol has been designed to authenticate the device and its features to the manufacturer through theTEPANOM-Authentication-Point. From the perspective of the network communication, three different actors have been defined, theTEPANOM-Client,TEPANOM-Gateway, and already mentionedTEPANOM-Authentication-Point. TheTEPANOM-Client is a constrained IoT device that is authenticating to theTEPANOM-Authentication-Point. The authentication process is done through theTEPANOM-Guard that is the gateway between the unauthenticated devices and the privileged parts of the network. TheTEPANOM-Guard has been responsible for protecting theTEPANOM-Authentication-Point against Denial-of-Service attacks, which could have been executed by maliciousTEPANOM-Clients. TheTEPANOM-Authentication-Point has been responsible for authenticating theTEPANOM-Client and providing theDataSheet which is extended description of device resources, capabilities, and methods.


## 2.3.1. Trust Extension

TheTrust Extension phase of the TEPANOM protocol has been designed to register methods and resources of the new device and to establish new shared key between the protocol actors. In this paper theTrust Extension phase of the TEPANOM protocol will be not addressed any further, and therefore for more details please refer to [31].


## 2.3.2. Authentication

TheAuthentication phase of the TEPANOM protocol has been designed to authenticate the device and its features to the manufacturer through theTEPANOM-Authentication-Point. From the perspective of the network communication, three different actors have been defined, theTEPANOM-Client,TEPANOM-Gateway, and already mentionedTEPANOM-Authentication-Point. TheTEPANOM-Client is a constrained IoT device that is authenticating to theTEPANOM-Authentication-Point. The authentication process is done through theTEPANOM-Guard that is the gateway between the unauthenticated devices and the privileged parts of the network. TheTEPANOM-Guard has been responsible for protecting theTEPANOM-Authentication-Point against Denial-of-Service attacks, which could have been executed by maliciousTEPANOM-Clients. TheTEPANOM-Authentication-Point has been responsible for authenticating theTEPANOM-Client and providing theDataSheet which is extended description of device resources, capabilities, and methods.


## 3. EAP-TEPANOM

It has been widely known fact that the most energy consumption in the constrained device comes from the radio communication. Therefore, it has been imperative to minimize the usage of wireless interfaces by limiting the number of transmitted bytes and packets. This approach has been seen in the application layer as CoAP protocol for HTTP [32], for device management like COMAN for SNMP [33, 34] or OMA LWM2 M [35], and for network layer transmission protocol like 6LoWPAN for IPv6 [36], MIPv6 [37, 38], and many others.TheEAP-TEPANOM protocol is a combination ofTEPANOM withEAP. The EAP has been used as a transport layer for the TEPANOM authentication mechanism. This formed new method that has been examined and compared in terms of the IEEE 802.15.4 network resource usage. The main motivation for this approach has been the need to minimize the communication overhead by eliminating the usage of IPv6/UDP transport protocols and exchanging it with more lightweight EAP communication stack.


### 3.1. Protocol Selection

The EAP-TEPANOM approach maximizes the size of the available payload space in the IEEE 802.15.4 frame by removing the UDP and IPv6 encapsulations that have been used by the regular TEPANOM protocol and using EAP encapsulation instead. The UDP and IPv6 together require 48 bytes of the 127-byte IEEE 802.15.4 frame which constitutes 37.8% of the whole frame. Using the EAP encapsulation with SEAPOL adaptation layer the same task can be achieved by only 5 bytes, which has been only 3.9% of the IEEE 802.15.4 frame. By applying this approach, it has been possible to save additional 43 bytes for the payload. This constitutes the reduction of the number of transmitted and received bytes and packets. Therefore, it has been the main contributing factor to the minimization of the network usage. The visual representation of TEPANOM frame with UDP/IPv6 has been presented in Figure3(a) and EAP encapsulation of the TEPANOM protocol has been presented in Figure 3(b).Figure 3
Comparison of IEEE 802.15.4 frames with different encapsulations of TEPANOM protocol.
(a)
IEEE 802.15.4 frame with standard TEPANOM protocol encapsulation example
(b)
IEEE 802.15.4 frame with regular EAP header and TEPANOM payload using SEAPOL adaptation layer
(c)
IEEE 802.15.4 frame with compact EAP header and TEPANOM payload using SEAPOL adaptation layer


### 3.2. Communication Exchange

EAP based solution that has been implemented in previous researches [39, 40] has been relying on the usage of the RADIUS protocol as the communication mechanism between theAuthenticator and theAuthentication Server. The solution has been extended to enable support for the TEPANOM protocol. This has been achieved by making modifications to theAuthenticator EAP Packet processing mechanism. Additional functionalities have been introduced that have been responsible for recognizing the EAP-TEPANOM protocol datagrams, extracting the TEPANOM payload, sending the TEPANOM payload to theTEPANOM-Guard through UDP/IPv6, and receiving the answers from theTEPANOM-Guard and forwarding them to theSupplicant (TEPANOM-Client) encapsulated in the EAP datagram. In other words, introduced modifications enabled theAuthenticator to work as a relay between EAP (Supplicant) and UDP/IPv6 (TEPANOM-Guard) protocols. The whole communication scheme with mentioned changes has been presented in Figure 4.Figure 4
EAP-TEPANOM method message exchange scheme.


## 3.1. Protocol Selection

The EAP-TEPANOM approach maximizes the size of the available payload space in the IEEE 802.15.4 frame by removing the UDP and IPv6 encapsulations that have been used by the regular TEPANOM protocol and using EAP encapsulation instead. The UDP and IPv6 together require 48 bytes of the 127-byte IEEE 802.15.4 frame which constitutes 37.8% of the whole frame. Using the EAP encapsulation with SEAPOL adaptation layer the same task can be achieved by only 5 bytes, which has been only 3.9% of the IEEE 802.15.4 frame. By applying this approach, it has been possible to save additional 43 bytes for the payload. This constitutes the reduction of the number of transmitted and received bytes and packets. Therefore, it has been the main contributing factor to the minimization of the network usage. The visual representation of TEPANOM frame with UDP/IPv6 has been presented in Figure3(a) and EAP encapsulation of the TEPANOM protocol has been presented in Figure 3(b).Figure 3
Comparison of IEEE 802.15.4 frames with different encapsulations of TEPANOM protocol.
(a)
IEEE 802.15.4 frame with standard TEPANOM protocol encapsulation example
(b)
IEEE 802.15.4 frame with regular EAP header and TEPANOM payload using SEAPOL adaptation layer
(c)
IEEE 802.15.4 frame with compact EAP header and TEPANOM payload using SEAPOL adaptation layer


## 3.2. Communication Exchange

EAP based solution that has been implemented in previous researches [39, 40] has been relying on the usage of the RADIUS protocol as the communication mechanism between theAuthenticator and theAuthentication Server. The solution has been extended to enable support for the TEPANOM protocol. This has been achieved by making modifications to theAuthenticator EAP Packet processing mechanism. Additional functionalities have been introduced that have been responsible for recognizing the EAP-TEPANOM protocol datagrams, extracting the TEPANOM payload, sending the TEPANOM payload to theTEPANOM-Guard through UDP/IPv6, and receiving the answers from theTEPANOM-Guard and forwarding them to theSupplicant (TEPANOM-Client) encapsulated in the EAP datagram. In other words, introduced modifications enabled theAuthenticator to work as a relay between EAP (Supplicant) and UDP/IPv6 (TEPANOM-Guard) protocols. The whole communication scheme with mentioned changes has been presented in Figure 4.Figure 4
EAP-TEPANOM method message exchange scheme.


## 4. Compact EAP

The minimization of transferred data for constrained IoT devices has been very important research objective. If a constrained device sends or receives data through the wireless interface it consumes a significant amount of energy. Due to the fact that constrained devices are mostly battery operated it has been imperative to save this limited resource. Throughout this and previous researches and various experiments with the EAP it has been noticed that it is possible to introduce modifications to the EAP header to achieve reduction of its length by up to 80%. Such modification should have significant impact on reduction of the energy consumption of constrained IoT devices.The compact EAP (cEAP) solution has been presented and discussed in this section. Every field of the EAP header has been discussed separately to show the motivation and reasoning behind the compaction approach.


### 4.1. Code

First field of the EAP header has been theCode whose length is one byte. Possible values that can be put in theCode field have been limited to just four different states:Request (1),Response (2), andSuccess (3) orFailure (4). This shows the obvious fact that theCode field can be used more efficiently. By application of simple compaction, (1)CompactCode=Code-1, theCode can freely fit into just 2 bits of the cEAP header instead of occupying whole byte of the EAP header. The process is easily reversible by applying (2)DecompactCode=Code+1 after which theCode will go back to the original EAPCode value.Application of this code compaction approach makes it possible to save 6 bits out of one byte of the header without compromising any functionality.


### 4.2. Identifier

Second field of the EAP header as well as second byte has been devoted to theIdentifier. This field has been introduced as a method to differentiate between Request and retransmission during the EAP session. The new Request needs differentIdentifier than the previous Request. TheIdentifier has been also responsible for the minimization of the possibility of successful reply attack. In addition in the RFC 3748 [27] it has been stated thatIdentifier space is unique to each session. Authenticators are not restricted to only 256 simultaneous authentication conversations, and conversation is not limited to only 256 roundtrips.Therefore, there has been no significant requirement to have theIdentifier field length of one byte by applying simple compaction: (3)CompactIdentifier=Identifiermod⁡16. It has been possible to shorten theIdentifier in half and use just 4 bits out of one byte.TheIdentifier compaction function loses information of the original value. Thus, the decompaction in cases whereIdentifier is not fitting in four least significant bits of the original field would require having savedIdentifier. This may not be common situation and might only occur if there would be communication between EAP and cEAP.


### 4.3. Length

Third field of the EAP header and third and fourth bytes have been devoted to theLength indicator. This has been the longest field in the whole EAP header. One important thing, which has been noticed during the research on EAP for IoT, has been that theLength field has not been used in any significant manner. Additionally, due to the fact that in the IEEE 802.15.4 networks the length of the frame has been limited to 127 bytes and that throughout the research the EAP frame has been limited to 100 bytes there has been no need for theLength field. The length of the IEEE 802.15.4 frame has always been sent to the MAC layer which independently indicates the EAP frame size.Therefore it has been possible to completely remove theLength field, saving two bytes of the header.


### 4.4. Type

Fourth and last field of the EAP header of the length of one byte has been theType. The presence of theType field has been conditional. It is part of the header only if theCode field has been set as theRequest orResponse. Observations of the EAP communication have led to the conclusion that theType field could be used in a more conditional manner. In addition to setting properCode, theType field could be only present if the type of the frame needs to be changed during current EAP session. This means that, for example, during the EAP-TEPANOM conversation theType will be set and present in the header only once for the first EAP-TEPANOM packet.That approach has saved one additional byte per every packet sent during the conversation of the same EAP method, except the first packet of the conversation.


### 4.5. Complete Solution

The modifications of the EAP fields presented above have been integrated and formed complete solution. After applying theCode compaction, the first byte of the header there will have 6 bits free that can be utilized more efficiently.Firstly, the most-left bit of the first byte of the frame indicates if the EAP header has been compacted. If the most-left bit of the first byte of the frame is turned on then the header has been compacted. This approach will not break any EAP implementation because the RFC 3748 [27] clearly states that any packet withCode above the value of 4 should be discarded.Secondly, the second most-left bit of the first byte of the frame indicates if theType field has been present. If the second most-left bit has been turned on then theType field has been present. If it has been turned off then theType field has been absent.Next, third and fourth most-left bits have been reserved for the compactedCode values. The last field of the cEAP header has been devoted to the compactedIdentifier.The presented complete solution has reduced the 5 bytes of regular EAP header down to just 1 byte, achieving 80% of header space savings. The examples of the compacted EAP headers have been presented in Figure5.Figure 5
Compact EAP header examples.


## 4.1. Code

First field of the EAP header has been theCode whose length is one byte. Possible values that can be put in theCode field have been limited to just four different states:Request (1),Response (2), andSuccess (3) orFailure (4). This shows the obvious fact that theCode field can be used more efficiently. By application of simple compaction, (1)CompactCode=Code-1, theCode can freely fit into just 2 bits of the cEAP header instead of occupying whole byte of the EAP header. The process is easily reversible by applying (2)DecompactCode=Code+1 after which theCode will go back to the original EAPCode value.Application of this code compaction approach makes it possible to save 6 bits out of one byte of the header without compromising any functionality.


## 4.2. Identifier

Second field of the EAP header as well as second byte has been devoted to theIdentifier. This field has been introduced as a method to differentiate between Request and retransmission during the EAP session. The new Request needs differentIdentifier than the previous Request. TheIdentifier has been also responsible for the minimization of the possibility of successful reply attack. In addition in the RFC 3748 [27] it has been stated thatIdentifier space is unique to each session. Authenticators are not restricted to only 256 simultaneous authentication conversations, and conversation is not limited to only 256 roundtrips.Therefore, there has been no significant requirement to have theIdentifier field length of one byte by applying simple compaction: (3)CompactIdentifier=Identifiermod⁡16. It has been possible to shorten theIdentifier in half and use just 4 bits out of one byte.TheIdentifier compaction function loses information of the original value. Thus, the decompaction in cases whereIdentifier is not fitting in four least significant bits of the original field would require having savedIdentifier. This may not be common situation and might only occur if there would be communication between EAP and cEAP.


## 4.3. Length

Third field of the EAP header and third and fourth bytes have been devoted to theLength indicator. This has been the longest field in the whole EAP header. One important thing, which has been noticed during the research on EAP for IoT, has been that theLength field has not been used in any significant manner. Additionally, due to the fact that in the IEEE 802.15.4 networks the length of the frame has been limited to 127 bytes and that throughout the research the EAP frame has been limited to 100 bytes there has been no need for theLength field. The length of the IEEE 802.15.4 frame has always been sent to the MAC layer which independently indicates the EAP frame size.Therefore it has been possible to completely remove theLength field, saving two bytes of the header.


## 4.4. Type

Fourth and last field of the EAP header of the length of one byte has been theType. The presence of theType field has been conditional. It is part of the header only if theCode field has been set as theRequest orResponse. Observations of the EAP communication have led to the conclusion that theType field could be used in a more conditional manner. In addition to setting properCode, theType field could be only present if the type of the frame needs to be changed during current EAP session. This means that, for example, during the EAP-TEPANOM conversation theType will be set and present in the header only once for the first EAP-TEPANOM packet.That approach has saved one additional byte per every packet sent during the conversation of the same EAP method, except the first packet of the conversation.


## 4.5. Complete Solution

The modifications of the EAP fields presented above have been integrated and formed complete solution. After applying theCode compaction, the first byte of the header there will have 6 bits free that can be utilized more efficiently.Firstly, the most-left bit of the first byte of the frame indicates if the EAP header has been compacted. If the most-left bit of the first byte of the frame is turned on then the header has been compacted. This approach will not break any EAP implementation because the RFC 3748 [27] clearly states that any packet withCode above the value of 4 should be discarded.Secondly, the second most-left bit of the first byte of the frame indicates if theType field has been present. If the second most-left bit has been turned on then theType field has been present. If it has been turned off then theType field has been absent.Next, third and fourth most-left bits have been reserved for the compactedCode values. The last field of the cEAP header has been devoted to the compactedIdentifier.The presented complete solution has reduced the 5 bytes of regular EAP header down to just 1 byte, achieving 80% of header space savings. The examples of the compacted EAP headers have been presented in Figure5.Figure 5
Compact EAP header examples.


## 5. Security Analysis

In this work two contributions have been introduced and in this section their brief security analysis has been presented.The EAP-TEPANOM method has been based on the TEPANOM protocol which has been designed as the lightweight protocol for bootstrapping of constrained devices. Firstly, the TEPANOM protocol itself has been well designed and it has based its security on the AES encryption, which stands its security on the same level as the EAP-PSK method. Secondly, it implements Denial-of-Service mitigation technique through puzzle solving request, which is unique feature among other EAP methods. Lastly, the TEPANOM message transmission has been based on the UDP/IPv6 protocols that have been transparent for internal workings of the TEPANOM protocol and by exchanging UDP/IPv6 with EAP the communication scheme has not been altered. Therefore, EAP-TEPANOM protocol provides security on the level of EAP-PSK, with Denial-of-Service mitigation technique and without UDP/IPv6 overhead.The security of the compacted EAP has been on the same level as the regular EAP. Although the length of the identifier field has been reduced and its purpose has been to reduce the replay attacks, it should not pose any significant threat due to the fact that in constrained networks number of transmissions is limited. Caution should be taken while using compact EAP in regular networks where number of transmissions is virtually unlimited; probability of a replay attack might be higher. No other changes have been introduced to the functionality of the compacted EAP that could hamper its security.


## 6. Results

In this section experimental results of the analysis of the EAP methods and compact EAP have been presented. The tests have been performed using TelosB [41] compatible devices working under control of the ContikiOS [42] operating systems. The results have been obtained from the perspective of network resource consumption of the Supplicant (TEPANOM-Client) device. Whole comparison has been presented in Table 1 and visual comparison between regular and compact EAP has been presented in Figure 6.Table 1
Comparison of network usage statistics calculated on the Supplicant/Client node. The statistics have been generated for compact (cEAP) and standard header versions of various EAP methods and regular TEPANOM protocol encapsulation. All statistics have been generated using SEAPOL adaptation layer for the IEEE 802.15.4 network.
TX packets
TX data
RX packets
RX data
Total packets
Total data
TEPANOM
2
210 B
17
1533 B
19
1743 B
EAP-TEPANOM
2
98 B
9
1020 B
11
1118 B
cEAP-TEPANOM
2
90 B
9
985 B
11
1075 B
EAP-MD5
3
66 B
3
59 B
6
125 B
cEAP-MD5
3
54 B
3
49 B
6
103 B
EAP-PSK
5
181 B
4
160 B
9
341 B
cEAP-PSK
5
161 B
4
145 B
9
306 B
EAP-TLS-ECDSA-160
12
271 B
17
812 B
29
1083 B
cEAP-TLS-ECDSA-160
12
223 B
17
745 B
29
960 B
EAP-TLS-ECDSA-256
13
286 B
18
931 B
31
1217 B
cEAP-TLS-ECDSA-256
13
234 B
18
860 B
31
1094 B
EAP-TLS-RSA-480
19
376 B
24
1566 B
43
1942 B
cEAP-TLS-RSA-480
19
300 B
24
1471 B
43
1771 B
EAP-TLS-RSA-512
20
397 B
25
1627 B
45
2024 B
cEAP-TLS-RSA-512
20
317 B
25
1528 B
45
1845 B
EAP-TLS-RSA-1024
27
496 B
32
2370 B
59
2866 B
cEAP-TLS-RSA-1024
27
388 B
32
2243 B
59
2631 B
EAP-TLS-RSA-2048
43
712 B
48
4200 B
91
4912 B
cEAP-TLS-RSA-2048
43
540 B
48
4009 B
91
4549 BFigure 6
Comparison of network usage calculated on the Supplicant/Client node of regular and compacted EAP using various EAP methods with SEAPOL adaptation for the IEEE 802.15.4 network.


### 6.1. Transmission

Both of the TEPANOM and EAP-TEPANOM solutions require only 2 packets to be sent by the Supplicant. This has been the most minimal requirement from all of the previously evaluated EAP methods; even the most simple of the regular EAP methods the EAP-MD5 requires one additional packet to be transmitted by the authenticating device.There has been no difference in terms of transmitted number of packets between the EAP and compact EAP solutions.Data required to be sent by the Supplicant have been different for the TEPANOM and EAP-TEPANOM solutions. The EAP-TEPANOM transmits only 98 bytes which has been 53% less than the 210 bytes required by the TEPANOM. The EAP-TEPANOM result has been 33% bigger than the EAP-MD5 method and 46% smaller than the EAP-PSK method. The TEPANOM result has been placed between the results of EAP-PSK and EAP-TLS-ECDSA-160 methods.The differences between EAP and compact EAP in terms of transmitted bytes by the Supplicant device have been very significant. The number of transmitted bytes for the cEAP-TEPANOM method has been lower by 8.16%. This result has been the smallest from all of the analyzed methods. The biggest reduction has been obtained for the cEAP-TLS-RSA-2048 method and has been 24.15% smaller than the EAP counterpart.


### 6.2. Reception

The number of received packets has been significantly higher than the number of transmitted packets for both of the TEPANOM and EAP-TEPANOM solutions. The TEPANOM requires receiving 17 packets, which has been the same number of received packets as for the EAP-TLS-ECDSA-160 method. The EAP-TEPANOM requires only 9 packets to be received, which has been 47% less than the TEPANOM. The EAP-TEPANOM results have been placed between the results of the EAP-PSK and EAP-TLS-ECDSA-160 methods.There has been no difference in terms of received number of packets between the EAP and compact EAP solutions.Received data has risen up significantly in comparison to the transmitted data for both of the TEPANOM and EAP-TEPANOM solutions. The TEPANOM protocol needs to receive 1533 bytes of data, which makes it almost the same result as for the EAP-TLS-RSA-480 method. The EAP-TEPANOM needs to receive 33% less data than the TEPANOM, which has been 1020 bytes. These results make the EAP-TEPANOM just slightly more data hungry than the EAP-TLS-ECDSA-256 solution.The differences between EAP and compact EAP in terms of received bytes by the Supplicant device have been less significant than those of the transmitted bytes. For the cEAP-TEPANOM the reduction has been at the level of 3.43%, which also has been the smallest improvement from all of the measured methods. The biggest reduction has been measured for the cEAP-MD5 method and has been at the level of 16.94% in comparison to the regular EAP.


### 6.3. Total

The total number of packets for the TEPANOM protocol has been 19 and for the EAP-TEPANOM 11 that has a 42% reduction. This places both solutions between the EAP-PSK and EAP-TLS-ECDSA-160 methods results.There has been no difference in terms of total number of packets between the EAP and compact EAP solutions.The total number of received data for the TEPANOM protocol has been 1743 bytes and for EAP-TEPANOM has been 35% less, which has been 1118 bytes. These results have placed the TEPANOM between EAP-TLS-ECDSA-256 and EAP-TLS-RSA-480 methods and the EAP-TEPANOM has been placed betweeen EAP-TLS-ECDSA-160 and EAP-TLS-ECDSA-256 results.The total reduction of exchanged data during the compact EAP communication has been significant. For the cEAP-TEPANOM method savings have been at the level of 3.84% and this has been the smallest saving from all of the analyzed methods. The biggest savings have been measured for the cEAP-MD5 method and have been at the level of 17.6%. Noteworthy savings have been achieved for the cEAP-TLS-ECDSA-160 and for the cEAP-TLS-ECDSA-256 at the level of 10.61% and 10.10%, respectively.


## 6.1. Transmission

Both of the TEPANOM and EAP-TEPANOM solutions require only 2 packets to be sent by the Supplicant. This has been the most minimal requirement from all of the previously evaluated EAP methods; even the most simple of the regular EAP methods the EAP-MD5 requires one additional packet to be transmitted by the authenticating device.There has been no difference in terms of transmitted number of packets between the EAP and compact EAP solutions.Data required to be sent by the Supplicant have been different for the TEPANOM and EAP-TEPANOM solutions. The EAP-TEPANOM transmits only 98 bytes which has been 53% less than the 210 bytes required by the TEPANOM. The EAP-TEPANOM result has been 33% bigger than the EAP-MD5 method and 46% smaller than the EAP-PSK method. The TEPANOM result has been placed between the results of EAP-PSK and EAP-TLS-ECDSA-160 methods.The differences between EAP and compact EAP in terms of transmitted bytes by the Supplicant device have been very significant. The number of transmitted bytes for the cEAP-TEPANOM method has been lower by 8.16%. This result has been the smallest from all of the analyzed methods. The biggest reduction has been obtained for the cEAP-TLS-RSA-2048 method and has been 24.15% smaller than the EAP counterpart.


## 6.2. Reception

The number of received packets has been significantly higher than the number of transmitted packets for both of the TEPANOM and EAP-TEPANOM solutions. The TEPANOM requires receiving 17 packets, which has been the same number of received packets as for the EAP-TLS-ECDSA-160 method. The EAP-TEPANOM requires only 9 packets to be received, which has been 47% less than the TEPANOM. The EAP-TEPANOM results have been placed between the results of the EAP-PSK and EAP-TLS-ECDSA-160 methods.There has been no difference in terms of received number of packets between the EAP and compact EAP solutions.Received data has risen up significantly in comparison to the transmitted data for both of the TEPANOM and EAP-TEPANOM solutions. The TEPANOM protocol needs to receive 1533 bytes of data, which makes it almost the same result as for the EAP-TLS-RSA-480 method. The EAP-TEPANOM needs to receive 33% less data than the TEPANOM, which has been 1020 bytes. These results make the EAP-TEPANOM just slightly more data hungry than the EAP-TLS-ECDSA-256 solution.The differences between EAP and compact EAP in terms of received bytes by the Supplicant device have been less significant than those of the transmitted bytes. For the cEAP-TEPANOM the reduction has been at the level of 3.43%, which also has been the smallest improvement from all of the measured methods. The biggest reduction has been measured for the cEAP-MD5 method and has been at the level of 16.94% in comparison to the regular EAP.


## 6.3. Total

The total number of packets for the TEPANOM protocol has been 19 and for the EAP-TEPANOM 11 that has a 42% reduction. This places both solutions between the EAP-PSK and EAP-TLS-ECDSA-160 methods results.There has been no difference in terms of total number of packets between the EAP and compact EAP solutions.The total number of received data for the TEPANOM protocol has been 1743 bytes and for EAP-TEPANOM has been 35% less, which has been 1118 bytes. These results have placed the TEPANOM between EAP-TLS-ECDSA-256 and EAP-TLS-RSA-480 methods and the EAP-TEPANOM has been placed betweeen EAP-TLS-ECDSA-160 and EAP-TLS-ECDSA-256 results.The total reduction of exchanged data during the compact EAP communication has been significant. For the cEAP-TEPANOM method savings have been at the level of 3.84% and this has been the smallest saving from all of the analyzed methods. The biggest savings have been measured for the cEAP-MD5 method and have been at the level of 17.6%. Noteworthy savings have been achieved for the cEAP-TLS-ECDSA-160 and for the cEAP-TLS-ECDSA-256 at the level of 10.61% and 10.10%, respectively.


## 7. Energy Analysis

In this section the energy analyses of introduced solutions have been presented. During the analysis the TelosB compatible mote has been used equipped withTI MSP430F1611 Microcontroller andCC2420 Radio Chip. For the purpose of the analysis the energy consumption models from [43] have been used.The CC2420 radio chip requires on average 17.4 mA for transmission and 18.8 mA for reception of packet [44]. Using these numbers the energy analysis of our solution has been prepared and presented in Figure 7.Figure 7
Comparison of estimated energy consumption calculated on the Supplicant/Client node of regular and compacted EAP using various EAP methods with SEAPOL adaptation for the IEEE 802.15.4 network.Application of compacted EAP solution saves up to 24.1% while transmitting EAP-TLS-RSA-2048 authentication data and 4.55% while receiving for the same method. This gives total saving of 7.2%. The biggest total saving of energy of 17.11% has been observed for EAP-MD5 method. The EAP-PSK and EAP-TLS-ECDSA have achieved energy savings of around 10%, while smallest reduction of the energy consumption of 3.81% has been noted for EAP-TEPANOM method.Overall, application of compacted EAP brings on average 8.96% savings of energy consumption.


## 8. Conclusion and Future Work

First contribution in this work has been a solution that combines theExtensive Authentication Protocol (EAP) withSlim Extensive Authentication Protocol Over Low-Rate Wireless Personal Area Networks (SEAPOL) IEEE 802.15.4 adaptation layer withTrust Extension Protocol for Authentication of New deployed Objects and sensors through the Manufacturer (TEPANOM). This solution has been evaluated and achieved significant network usage savings. The EAP-TEPANOM method has achieved 42% reduction in number of transferred packets and 35% reduction of the data that needs to be transferred. The EAP-TEPANOM has been requiring fewer network resources than the most of the EAP-TLS methods.Second contribution is that the compaction of the EAP header has been proposed that achieved significant savings in transmitted and received data. The best overall savings have been obtained for the cEAP-MD5 method at the level of 17.6% and for the cEAP-TLS-ECDSA based ones at the level of 10%. The cEAP-TEPANOM method has achieved saving at the level of 3.84%.The EAP-TEPANOM solution showed that it has been possible to use the EAP infrastructure to reduce the usage of the network resources of the constrained devices and extend it to communicate with new authentication protocols and its separate infrastructure.Future work will be devoted to integrating more closely the TEPANOM solution and its architecture with the EAP infrastructure. More work will be done in the context of the TEPANOM Trust Extension phase integration with EAP infrastructure and its optimization. Additionally the EAP will be analyzed more thoroughly and new approach would be designed to find better way to transmit data more efficiently by reducing the number of transmitted packets.



---

*Source: 506284-2015-11-24.xml*