# Lightweight CoAP-Based Bootstrapping Service for the Internet of Things
## 2 State of the Art
### The Extensible Authentication Protocol (EAP)  
The _Extensible Authentication Protocol_ (EAP) [12] allows different types of authentication mechanisms (e.g., based on symmetric keys, digital certificates, _etc._) named _EAP methods_. For example, EAP-PSK [31] is an EAP method based on the use of a pre-shared key (PSK) to provide a lightweight authentication mechanism. Another examples of EAP methods can be found in [32].  
EAP is a lock-step protocol, which supports only a single packet, request or response, in flight. Each request message (_EAP Request_) is answered with a response (_EAP Response_). The number of exchanges will depend on the EAP method selected. Every EAP method runs between the _EAP peer_, and the _EAP server_ through an _EAP authenticator_. From a security standpoint, the EAP authenticator acts as a mere EAP packet forwarder.  
To perform 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. The identity follows the _Network Access Identifier_ (NAI) format [33] (e.g., _smartobject@domain_). It contains a smart object's identity information (_i.e._, _smartobject_) separated with an @ and the domain (_i.e._, _domain_) it belongs to. With this information, the EAP server will select the EAP method to be performed. The EAP method execution involves several EAP Request/Response exchanges between the EAP server and the EAP peer.  
There are two deployment models of deployment for EAP. On the one hand, the _standalone EAP authenticator model_, where the EAP server is co-located in the same device as the EAP authenticator. This may be appropriate in deployments with a small number of objects. In this case, there is no AAA infrastructure in the backend. On the other hand, there is the _pass-through EAP authenticator_ model, which is the most scalable configuration. In this model, the EAP server and the EAP authenticator are implemented in separate nodes. Specifically, the EAP server is centralized on an AAA server deployed somewhere on the Internet and gives service to several EAP authenticators. Here, the communication between the EAP server and the pass-through EAP authenticator is performed using an AAA protocol. In both cases, a protocol referred to as the _EAP lower-layer_ is used to transport the EAP packets between the EAP peer and the EAP authenticator. As we will see in Section 3, CoAP-EAP defines a new EAP lower-layer by using CoAP messages. Figure 1 shows a mapping between the entities defined in the AAA model and EAP pass-through model. Each layer in the EAP processes a part of the EAP message in each entity, as described in [12]. As observed, the EAP method is processed in the EAP peer and the EAP server in the IdP's AAA server.  
Certain EAP methods [32] are able to generate keying material. Specifically, according to the _EAP Key Management Framework_ (EAP KMF) [14], two keys are exported after a successful EAP authentication: the _Master Session Key_ (MSK) and the _Extended Master Session Key_ (EMSK). The first is traditionally sent to the authenticator to establish a security association with the EAP peer, while the second must not be provided to any other entity outside the EAP server and peer. Thus, both entities may use the key material for further purposes.  
Recently, the applicability statement defined in [12], which limited EAP for network access authentication, has been enriched to allow the use of EAP in application access authentication [34].