PANATIKI: A Network Access Control Implementation Based on PANA for IoT Devices

3.1. Extensible Authentication Protocol (EAP)

The Extensible Authentication Protocol (EAP) [4] is a lock-step request/response protocol, which supports only a single packet (request or response) in flight. Therefore, each request message (EAP Request) is answered with a response (EAP Response). EAP allows different types of authentication mechanisms, the so-called EAP methods (e.g., based on symmetric keys, digital certificates, etc.). EAP-PSK [22] is an example of the EAP method. It assumes pre-shared symmetric key (PSK) between the EAP peer and EAP server and provides a lightweight authentication mechanism consisting of only four messages. No other secure EAP method uses fewer messages for authentication purposes. This means it is a potential candidate in constrained environments, such as IoT networks. In fact, this is the EAP method we have used for our experiments.

Every EAP method is run between an EAP peer and an EAP server through an EAP authenticator. From a security standpoint, the EAP authenticator does not take part in the mutual authentication process, but acts as a mere EAP packet forwarder.

To carry out an EAP authentication, the EAP authenticator usually starts the process by requesting the EAP peer's identity through an EAP Request/Identity message. The EAP peer answers with an EAP Response/Identity with its identity. With this information, the EAP server will select the EAP method to be performed. The EAP method execution involves several EAP Request and Response exchanges between the EAP server and the EAP peer.

Figure 2 represents the pass-through authentication model, which is the most deployed configuration. In this model, the EAP server and the EAP authenticator are implemented in separate nodes. Specifically, the EAP server is placed on an AAA server deployed by the network operator somewhere on the Internet. Here, communication between the EAP server and the pass-through EAP authenticator is performed using an AAA protocol, such as RADIUS [23] or Diameter [24]. In both cases, a protocol referred to as the EAP lower-layer protocol is used to transport the EAP packets between the EAP peer and EAP authenticator.

Certain EAP methods [25] are able to generate keying material. In particular, according to the EAP Key Management Framework [26], two keys are exported after a successful EAP authentication: the Master Session Key (MSK) and the Extended Master Session Key (EMSK). The former is traditionally sent to the authenticator to establish a security association with the EAP peer, while the latter must not be provided to any other entity outside the EAP server and peer. Thus, both entities may use the key material for further key derivation and, therefore, for bootstrapping purposes.

3.2. PANA

PANA [5] is an application protocol using the User Datagram Protocol (UDP) as the transport, which has been specially conceived of by the Internet Engineering Task Force (IETF) to carry EAP to support different authentication mechanisms for network access. Thus, it is an EAP lower-layer protocol, which is independent of the underlying network access technology. Consequently, the PANA architecture described in [27] defines several logical entities that have a correspondence with the EAP entities shown in Figure 2. This relationship is depicted in Figure 3.

The PANA network access control model considers a PANA Client (PaC), which requests access to the network service offered by an Enforcement Point (EP), such as an access point or a router. The EP is controlled by a PANA Authentication Agent (PAA), which is responsible for authenticating and authorizing the PaCs for the network service. The PAA communicates with the AAA Server, to verify the credentials provided by a PaC. If the AAA server correctly verifies the credentials, it sends authorization parameters (cryptographic material, network access lifetime, quality of service (QoS) filters, etc.) to the PAA. Then, the PAA transfers some configuration information to the EP by using either an Application Program Interface (API) or a Configuration Network Protocol (CNP), like Simple Network Management Protocol (SNMP) [28]. According to this operation, as depicted in Figure 3, the PaC, PAA and AAA implement the EAP peer, EAP authenticator and EAP server functionalities, respectively.

It is worth noting that a new, but optional, entity, named PANA Relay (PRE), has been defined in [29]. This entity is located between a PaC and a PAA and is responsible for relaying the PANA messages. From the PaC's perspective, the PRE appears as the PAA. The deployment of this entity may not be required in general scenarios, but it is essential in scenarios where the PaC cannot make contact directly with the PAA. This situation is typical in IoT environments, like that shown in Figure 1, where the unauthenticated node can only interact with the nearest authenticated node, but not with an entity several hops away (i.e., PAA).

The PANA operation is performed along four phases. First, the authentication and authorization phase is initiated by the PaC through a PANA-Client-Initiation (PCI) sent to the PAA. In this phase, the PaC and the PAA exchange several PANA-Auth-Request/Answer (PAR/PAN) messages, which are used to negotiate some parameters, such as the integrity algorithms used to protect PANA messages. They also exchange PANA messages transporting EAP to perform the authentication and to establish a so-called PANA session. At the end of this phase, two security associations are established. On the one hand, the PANA Security Association (SA) is established between the PaC and the PAA in order to protect the integrity of the PANA messages. To build this security association, both PaC and PAA derive the PANA_AUTH_KEY from the MSK obtained once the PaC has been successfully authenticated with EAP. This PANA_AUTH_KEY is the one used for integrity protecting the PANA messages. On the other hand, after the PANA SA has been set, a PaC-EP SA may be established to protect data traffic between the PaC and the EP

Once the PaC is successfully authenticated, the protocol enters the access phase in which the PaC can use the network service just by sending/receiving data traffic through the EP. If the session is about to expire, typically a re-authentication phase occurs to renew this session lifetime, as well as the associated security associations. The PaC or PAA can terminate the session (e.g., the PaC wishes to log out the network access session) during termination phase, where resources allocated by the EP for the PaC are also removed.

If the PANA authentication involves a PRE between the PaC and PAA, the PRE encapsulates each message sent by the PaC in a new message, named PANA-Relay (PRY), and sends it to the PAA. The PAA encapsulates its answer in another PRY message and sends it to the PRE. Finally, the PRE decapsulates the message sent by the PAA and forwards it without modification to the PaC.

4.1. Preliminary Considerations

To perform an authentication, an unauthenticated node will have to implement the PaC with the EAP peer functionality and the client part of the EAP methods. Once this node is authenticated, it becomes an authenticated node and may act as a PANA relay to forward PANA messages between a new unauthenticated PaC and the PAA deployed. Therefore, a node joining the multi-hop network and trying to send traffic to the Internet will have to implement both PaC and PRE functionality. Thus, these implementations must be optimized to preserve resources in the constrained device. In contrast, the PAA will be typically co-located with the border router, which is assumed to have enough resources to run a general PANA implementation. This mapping is represented in Figure 4.

Our first attempt to deploy PANA in constrained devices was to adapt OpenPANA to the requirements imposed by these constrained devices. However, the source code of OpenPANA is not well adapted for constrained environments. For example, it makes use of heavy libraries for constrained devices, like open secure sockets layer (OpenSSL) [31] or implements multiple EAP methods to provide flexibility. However, this variety increases the source code size. This has led us to implement, from scratch, a PaC and a PRE specially adapted for constrained devices. This implementation is based on the Contiki OS, which is the operating system used by the devices we have used for our real experience.

For these implementations, we have followed documents Request For Comments (RFC) 5609 [32], RFC 4137 [33] and RFC 6345 [29], which describe the PANA state machine, the EAP state machine and the PRE behavior, respectively. Nevertheless, it is convenient to analyze how these state machines can be simplified without removing any mandatory behavior of the standard protocols.

Additionally, it is important to make use of the hardware resources that these devices already offer. This means adapting the variables' length to the word length of the microprocessor or using available hardware cryptographic modules. For example, several constrained devices already integrate certain hardware implementations of basic cryptographic functions. PANA and EAP typically require a certain cryptographic suite to perform authentication and key management. In PANA authentication, the establishment of the PANA Security Association (SA) requires cryptographic operations apart from those required by the chosen EAP method. Thus, an important design decision is not only to keep the same cryptographic suite in both PANA and the EAP method so that it can be reused, but also to try to select this cryptographic suite in such a manner that most of the required cryptographic functions are already implemented by the device's hardware.

In addition, we need to reduce the number of messages, variables, features, etc., as much as possible. Each non-mandatory feature and byte we can save will be key in achieving a reduction in other parts. As a design principle, this must be done following the standard's rules in order to achieve interoperability with other implementations.

Below, we focus on specific viable simplifications in the state machines of the PaC, EAP peer and the EAP method layer of the EAP peer. It is worth noting that the EAP method layer is implemented by the EAP method, so it will depend on the EAP method selected. For the purpose of our study, we have chosen the lightweight EAP-PSK (pre-shared key) [22]. This election is not random. Apart from being based on symmetric cryptography (lighter than asymmetric one), the cryptographic suite used by EAP-PSK uses the advance encryption standard (AES) as the main algorithm for its operation. This algorithm is implemented in the hardware in many constrained devices.

Given that the PANA Relay entity is also implemented in this work, we also provide some insights into its implementation. Finally, although PAA is not installed in constrained devices (we use the PAA distributed in OpenPANA), some specific behavior of the PAA is expected to handle PANA authentications coming from a constrained device. We discuss the details of this behavior.

4.2. EAP Peer State Machine

In general, the EAP peer state machine definition is simple (see Appendix); however, some simplifications are still possible. In particular, we can safely obviate the portEnabled variable and the Disabled state, because they were inherited from legacy technology (e.g., 802.1X technology), and we can assume that portEnabled is always TRUE and Disabled is FALSE.

We have also deleted the timeout management in the EAP peer. This timeout is established by the peer, so that it avoids waiting for a EAP Request indefinitely. Nevertheless, this situation can also be discovered if the EAP lower layer notifies the EAP peer that the authenticator has not sent any message after a certain period of time. Since PANA provides this functionality, it is not worth duplicating functionality in both layers. This simplifies some transitions and avoids extra verification and management of this timeout (see Figure B1).

Finally, we have deleted the Notification transition. A Notification message is optionally used to transport a displayable message from the authenticator to the peer. However, it is not widely used, and certain EAP methods prohibit or do not recommend its usage, because this message is not securely protected. EAP-PSK is an example. Thus, our EAP peer state machine removes this state and its management, since it is not essential.

4.3. PANA Client State Machine

In general, the complete PaC state machine can be simplified to fit better in constrained devices. Therefore, we need to make some decisions to get a lighter version without affecting the mandatory parts of the standard.

Some hints of this simplification process can be found in [7], where we have some useful guidance and recommendations about how the PANA client can be tailored to meet the requirements for constrained environments. From this contribution and our own experience, we can establish a set of simplifications of the PaC state machine. Figure 5 shows a simplified PaC state machine after the following simplifications.

4.4. PANA Security Association

Another key part that can be optimized is the PANA Security Association (PANA SA) and the message integrity protection once the authentication has successfully been completed. In particular, a PANA SA is established thanks to the derivation of a key named PANA_AUTH_KEY. This key is obtained from the MSK exported by the EAP method by applying a key derivation function named PRF+ (pseudo random function) defined in [6]. The pseudo random function (PRF) used to implement PRF+ is based on the use of hash-based message authentication code - secure hash algorithm 1 (HMAC-SHA1). This is a keyed-hash function that provided us with the integrity protection of the messages. Once the authentication has successfully been performed and the PANA_AUTH_KEY has been generated using the mechanism shown above, the integrity protection of the messages (PANA_PDU) is achieved by including an authentication tag contained in the AUTH AVP.

However, HMAC_SHA1 is not implemented in the hardware we use for our experimental testbed. Instead, the device implements an AES module, which is a common algorithm included in cryptographic processors of constrained devices. Taking into account the principle of taking as much advantage as possible of the hardware resources, we have replaced HMAC_SHA1 for the advanced encryption standard - cipher-based message authentication code (AES-CMAC) algorithm [34] to derive the PANA_AUTH_KEY and to provide integrity to PANA messages. It is worth noting that, although PANA defines HMAC_SHA1 as the mandatory cryptographic suite to be supported, other cryptographic suites may be used optionally (e.g., AES). In order to get our proposal working, we demand that the PaC supports only AES-CMAC, while the PAA facing a constrained network must support both HMAC_SHA1 and AES-CMAC. In this way, the solution is scalable. The PAA can handle the authentication of different devices (The PAA will use HMAC_SHA1 as the cryptographic suite for authenticating a general purpose device, while AES-CMAC will be used for authenticating a constrained device), while still following the PANA specification. We affirm that the inclusion of both AES-CMAC and HMAC_SHA1 in the PAA is feasible, as we have already done it in our project, OpenPANA [21].

In addition, as we will see in Section 4.5, the EAP method we have selected in our experimental testbed is EAP-PSK, which also uses AES as the main cryptographic algorithm. In this manner, we still keep the same cryptographic suite in every part of the protocol stack. Therefore, AES is not only used in PANA_AUTH_KEY generation and AUTH AVP generation, but also in the EAP method. As is evident, we recommend that other developers change this function and use another cryptographic algorithm, if the device employed supports other types of functions, in order to follow the same principle.

Nevertheless, the choice of AES-CMAC as the cryptographic algorithm for integrity has some implications. Specifically, it implies that the PANA_AUTH_KEY must be 16 bytes in length (the HMAC_SHA1 result is a 20-byte length). This is not a problem, because applying AES-CMAC to derive PANA_AUTH_KEY already generates a 16-byte output with a single iteration. However, the MSK used as a parameter of AES-CMAC is 64 bytes in length. AES-CMAC only accepts 16-byte length keys as the parameter. The solution that we have adopted is the use of the 16 most significant bytes of this MSK.

4.5. EAP Method: EAP-PSK

The possibility of choosing between several EAP methods is one of the advantages of using EAP. However, several choices imply adding more source code to the constrained device. Thus, it is convenient to select only one EAP method and implement it. In particular, as pointed out in [7], an EAP method that minimizes the number of messages is preferable. This is the case of Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) [35] or EAP-PSK [22], which have the minimum number of messages for an EAP method. Moreover, they are based on symmetric cryptography, which is better in terms of resource consumption than other methods based on asymmetric cryptography, such as EAP-TLS [36].

Between EAP-GPSK and EAP-PSK, we have used the latter, because, apart from being very similar to EAP-GPSK, it relies on a single cryptographic primitive AES-128, which lets us keep the same cryptographic suite in all our protocol stacks. Besides, EAP-PSK is supposed to be lightweight and well suited for any type of device, especially those of small processing power and memory. Finally, for simplicity, EAP-PSK has also chosen a fixed message format, which eases the processing.

EAP-PSK defines two modes of authentication: EAP-PSK Standard Authentication and EAP-PSK Extended Authentication. We have used the Standard Authentication mode, which builds a protected channel with less source code and complexity. It is worth noting that this protected channel contains a value in the last message named P_CHANNEL_1, which is cryptographically verified by the EAP peer part of EAP-PSK. However, the same message contains a Message Authentication Code (MAC). We argue that the MAC verification is enough for the EAP peer to authenticate the EAP server, so verifying P_CHANNEL_1 is redundant. Thus, we have removed the source code to verify P_CHANNEL_1 in the constrained device.

Finally, the use of EAP-PSK implies that a PSK key must be distributed in advance to the device to be authenticated. Given the resource constraints in sensor devices, our proposal is based on the assumption that a device has been manually pre-configured with a PSK that is known a priori to the authentication server. This assumption is reasonable since a PSK can be included in the manufacturing process of a device and stored in the authentication server in charge of authenticating the corresponding sensor.

4.6. PANA Relay

The PANA Relay entity (PRE) is located between the PaC and the PAA, and its main function is to forward PANA messages from the PaC to the PAA and vice versa, without keeping any session state. Thus, the complexity associated with this entity is relatively small.

According to RFC 6345 [29], the functionalities to be implemented are mainly: reception of messages from different sources (i.e., PaC and PAA); encapsulation of PANA messages sent by PaC to the PAA in PANA-Relay (PRY) messages; and the corresponding decapsulation of the answer sent by the PAA to the PaC, also contained in a PRY message.

4.7. PANA Agent

While the PANA Agent (PAA) does not require any particular simplification (we assume that it would be placed in the border router or any other device with suitable resources), it is important that PAA establish a set of policies that control its behavior when it is controlling a network with constrained PaCs. These policies are related to the PaC's behavior that we have described in previous sections, namely:

• PAA should not initiate (re-)authentication, even if the session lifetime is about to expire. Instead, it must wait for a notification message from the PaC indicating the initiation of a (re-)authentication process.

• The EAP piggyback option will be used. Given that lightweight PaC assumes its usage, this option is activated in the PAA, as well.

• The PAA will only answer PNR messages and will not send PNR to the PaC. (i.e., such as PANA Ping or to start a (re-)authentication process). Similarly, PAA should avoid sending a PTR message to terminate a session.

• The PANA SA must be only removed when the associated lifetime expires. We assume that the PaC is in charge of sending a PANA notification message before lifetime expiration to perform the re-authentication.

• The AES-CMAC function must be available as a PRF+ and integrity function, since the PaC deployed in an IoT device will support only this cryptographic suite. Thus, the same function must be supported in the PAA.

5.1. Deployed Testbed

First of all, it is necessary to describe the testbed used in this evaluation process. We have used the JN5139 hardware [37] as an example of a constrained device. The JN5139 module has only 96 kB of RAM and 128 kB of ROM. These limitations have been taken into account, since we must adjust our implementation to fit in this space. It has a wireless communication module based on IEEE 802.15.4 [2] and implements a 128-bit AES encryption module, which allows faster encryption operations. As the operating system, it uses Contiki OS [11], which is specially adapted to this type of constrained device. Programming in Contiki OS is based on the american national standards institute (ANSI) C language.

The entities that take part in the testbed are described in Figure 6. In particular, two scenarios have been deployed. On the one hand, the non-PRE scenario, in which the PaC is deployed in a JN5139 module [37] that connects directly with a bridge 6LoWPAN-Ethernet.

Conversely, the PAA is placed on a regular PC, which is connected to the Ethernet network. Thus, once a PANA message reaches the bridge, this hardware sends the message to the computer where the PAA is running. The same process is done on the way back. On the other hand, we have the with-PRE scenario, where, unlike the non-PRE one, the PaC is not directly connected with the PAA through the bridge, but by means of a node acting as the PRE. Thus, the messages created by the PaC are sent to the PRE, and this entity will forward the message to the PAA using the bridge over the 6LoWPAN network. Once a message reaches the PAA, this entity will send the answer to the PRE, which will forward it to the PaC.

Finally, the server part of EAP-PSK is already implemented by the RADIUS server. The RADIUS messages are sent over the localhost interface, since the RADIUS server is located in the same computer as the PAA. While the PAA has been deployed by using OpenPANA [21] (version 0.2.3), the RADIUS server implementation is based on FreeRADIUS [38] (version 2.0.2). Both the PAA and RADIUS server have been deployed over an Ubuntu 12.04 32-bit operating system. Elsewhere, PANATIKI [10] (version 0.1) has been used for PaC and PRE implementations.

The non-PRE and with-PRE scenarios have been also simulated on Cooja [39] to experiment with more nodes. Cooja is a simulator of constrained networks available in the Contiki OS software. It allows the simulation of constrained nodes running a Contiki OS-based user application suitable for the inherent constraints to such nodes. In particular, PaC, PRE and 6LoWPAN Ethernet bridge functionalities have been loaded into simulated z1 nodes [40], which are more constrained than JN5139 devices. In fact, they have 92 kB of ROM and only 8 KB of RAM. The rest of the elements of our testbed (i.e., PAA and the EAP server) have been deployed in a real computer, as explained for the real hardware-based deployments. Given that simulated nodes (i.e., Z1 nodes) have different capabilities than real hardware nodes (i.e., Jennic nodes), a small set of changes has been needed in both the OpenPANA and PANATIKI software. In particular, OpenPANA (version 0.2.4) has been used to run PAA, while PANATIKI (version 0.2) has been used for PaC and PRE simulated entities. RADIUS server software remains as the same version as in the hardware-based deployment. Finally, the software needed for the simulated Ethernet bridge has been adopted by the examples available in Contiki release 2.6.

These Cooja-based simulations allow us to test our deployment according to variables that we could not check with the real hardware-based testbed. In particular, we have tested our implementation depending on a variable number of PaCs and a variable packet loss ratio.

5.2. Results

We have carried out two deployments of our testbed. The first deployment has been based on real hardware, while the second deployment has been simulated on Cooja with additional nodes. In this section, we present two sets of results corresponding to each deployment.