Linköping University | Department of Computer and Information Science
Bachelor thesis, 16 ECTS | Computer Science
2018 | LIU-IDA/LITH-EX-G--18/047--SE
Evaluation of Key
Manage-ment Protocols and Their
Im-plementations
Utvärdering av Key Management Protokoll och dess
implemen-tationer
Erik Andersson
David Combler
Supervisor : Andrei Gurtov Examiner : Marcus Bendtsen
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c
Erik Andersson David Combler
Students in the 5 year Information Technology program complete a semester-long software development project during their sixth semester (third year). The project is completed in mid-sized groups, and the students implement a mobile application intended to be used in a multi-actor setting, currently a search and rescue scenario. In parallel they study several topics relevant to the technical and ethical considerations in the project. The project culminates by demonstrating a working product and a written report documenting the results of the practical development process including requirements elicitation. During the final stage of the semester, students create small groups and specialise in one topic, resulting in a bachelor thesis. The current report represents the results obtained during this specialisation work. Hence, the thesis should be viewed as part of a larger body of work required to pass the semester, including the conditions and requirements for a bachelor thesis.
Abstract
When constructing a network system it is important to consider the attributes which define said system and how to best build around those attributes. In this report we’ve studied Key Management Protocols as well as 802.15.4 WPAN networks and how key managment is conducted in such networks. This was done to better understand how Key Management Protocols themselves work and if, or how, they differ when used in 802.15.4 networks.
In this report we studied 4 different Key Management Protocols: IKEv2, HIPv2, PANA and 802.1X as well as their various implementations. Based on the information gathered we analyzed how an implementation would work according to IEEE 802.15.9.
Firstly we found was that IKEv2 offers a lot of functionality at the cost of system com-plexity and required a lot of memory. It also required major modifications to work in 802.15.4 networks.
Secondly we found that HIPv2 offers the ability to separate the locator and identifier tags of TCP/IP and is lightweight. It doesn’t use IP or TCP/UDP and as such required minor changes to work in 802.15.4 networks.
Finally, PANA and 802.1X both offer client-to-network authentication using EAP and use a moderate to high amount of space. 802.1X required a moderate amount of changes to work in 802.15.4 networks. PANA on the other hand required few changes, though it should not be used as a general purpose Key Management Protocol in 802.15.4 networks.
Acknowledgments
Contents
Abstract iv
Acknowledgments v
Contents vi
List of Figures vii
List of Tables viii
1 Introduction 1
1.1 Motivation . . . 1
1.2 Aim . . . 1
1.3 Definitions and abbreviations . . . 2
1.4 Research questions . . . 2
1.5 Delimitations . . . 3
2 Theory, Related Work 4 2.1 Related works . . . 4
3 Method 5 3.1 Evaluating Key Management Protocols . . . 5
3.2 Evaluating KMP implementations . . . 6
3.3 Method for KMP comparison . . . 6
4 Results 7 4.1 802.15.9 . . . 7
4.2 Internet Key Exchange Protocol Version 2 . . . 9
4.3 Host Identity Protocol Version 2 . . . 12
4.4 PANA . . . 15
4.5 802.1X . . . 19
5 Discussion 23 5.1 Results . . . 23
5.2 Method . . . 26
5.3 The work in a wider context . . . 26
6 Conclusion 27 6.1 Future work . . . 28
List of Figures
4.1 Example OSI model with MPX fragmentation/reassembly and MAC-link commu-nication. As can be seen, the MPX fragmentation is part of the Network Layer. . . 8 4.2 A typical request/response pair IKEv2 handshake. . . 9 4.3 A typical HIPv2 handshake. . . 13 4.4 A typical PANA authentication and authorization phase. . . 16 4.5 IEEE 802.1X/EAP and IEEE 802.1X/MKA used together as a PAN KMP. Firstly
EAP is used to autheticate the device and then MKA is used to create a key. . . 20 4.6 IEEE 802.1X/EAP, IEEE 802.11/4WH and IEEE 802.11/GKH used together as a
PAN KMP. Similarly to Figure 4.5, EAP is used for authentication and then a key can be created with either 4WH or GKH. . . 21
List of Tables
1.1 The protocols and implementations covered in this report. . . 3
4.1 The IKE Header . . . 10
4.2 The fixed HIPv2 Header. . . 13
4.3 The PANA Header. . . 16
4.4 The AVP Header. . . 17
4.5 The KMPs used in 802.1X and their Protocol Data Unit formats. . . 19
5.1 Comparison of the various protocol attributes. Note the 4 byte generic header for IKEv2. . . 24
1
Introduction
1.1
Motivation
Key management is critical to the security of a cryptographic system. However in today’s world there are a myriad of different Key Management Protocols (KMPs) to choose from and they all differ somewhat in terms of generating, exchanging, storing, using and replacing keys. For instance, some KMPs might take up more memory than others while instead of-fering some type of functionality that the others don’t. So how do you know which one best suits your system?
In this report we hope to answer this question by studying the inner workings of Key Management Protocols, their open source implementations as well as the 802.15.9 standard which defines the use of KMPs in 802.15.4 networks. We’ll also look at what changes may apply when operating these protocols in 802.15.4 networks. We’ll be looking at attributes such as the number of messages in a typical exchange, the size of the overhead, what functionality they offer and more. We will also look at the specifics of the KMP implementations, for example how many lines of code each implementation consists of and when they were last updated.
Finally the findings gained from each Key Management Protocol will be compared to find how the implementations of these protocols differ. We will also try to find the underlying factors behind the difference in performance.
With this research we hope to provide a basis for others when selecting which Key Man-agement Protocol to use in their 802.15.4 system. However it should be noted that due to the time constraints of this research we will only have sufficient time to investigate a few different KMPs. As such there might be other Key Management Protocols that we have not covered which better suit a specific need.
1.2
Aim
In this report we want to give an estimation of which KMP is, in our view, best suited for a system based on certain parameters. We will do this by using the data collected in our research on 802.15.9, KMPs and their implementations and then comparing them.
1.3. Definitions and abbreviations
1.3
Definitions and abbreviations
Due to the technical nature of this report, there are several loosely defined words as well as several acronyms used. Therefore they will first be explained here.
Key Management Protocol (KMP): According to the IEEE the Key Management Protocol is deifined as the following: "A collection of data transactions that provide the mechanism to manage cryptographic keys. This includes dealing with the generation, exchange, storage, use, and replacement of keys." [16]
Internet Protocol Security: Internet Protocol Security, IPsec, is a collection of protocols that operates at the IP layer. Its purpose is to provide security for communication over the Internet, and it is capable of doing so for gateway-gateway, host-gateway and host-host connections. The Internet Key Exchange Protocol, a KMP that will be covered in section 4.2, is the most commonly used protocol for negotiating and managing keys in IPsec [5].
4WH 4-Way-Handshake
AVP Attribute-Value Pairs
EAP Extensible Authentication Protocol HIP Host Identity Protocol
IKEv2 Internet Key Exchange Protocol Version 2
IP Internet Protocol
IPsec IP Security
IRAS IPsec Remote Access Server
KMP Key Management Protocol
LoC Lines of Code
NAT Network Address Translation
PANA Protocol for Carrying Authentication for Network Access
SA Security Association
SPI Security Parameter Index UDP User Datagram Protocol
1.4
Research questions
To better understand the performance impact of various KMPs we have decided to discuss the following questions:
• How does the 802.15.9 standard, and the underlying 802.15.4 standard, work and what changes are neccessary for KMPs in 802.15.9?
• To what extent does each KMP impact attributes such as overhead size, functionality and number of messages per exchange?
• How do the attributes of the different KMPs compare to each other? • Which relevant factors cause the difference in KMP performance?
1.5. Delimitations
1.5
Delimitations
Many companies are not keen on revealing how keys are managed in their system and as such there might be protocol implementations that we are unaware of. We also have a short amount of time to conduct this study. Due to these constraints we have decided to limit our study to 4 different Key Management Protocols and their open source implementations, namely:
Protocol Implementation
IKEv2 strongSwan
HIP OpenHIP
PANA OpenPANA
802.1X Open1X & FreeRADIUS
2
Theory, Related Work
This section will cover some prior reports written on KMPs and use these to illustrate and motivate the informational gap our report aims to fill. Since this project is a theoretical com-parison of KMPs, our research into the specifics of the KMPs is the main body of our results and will therfore be presented in section 4. The main sources of information used in this project will be technical specifications of the different KMPs, e.g. RFC documents, as well as different open source implementations of the KMPs, e.g. the strongSwan implementation of IKEv2. We will also draw some information to aid our comparisons from other reports.
2.1
Related works
One of the primary goals of this project is to examine how the theoretical performance differs between different KMPs. In the area of KMP performance, several different studies have been made. Faigl et al. compares IKEv2 performance between different authentication methods, while Lawas et al. compares IKEv2 to the Secure Socket Tunneling Protocol from a Virtual Private Network perspective [4][9]. Cremers does perform a theoretical analysis of IKEv2, but no comparisons to other KMPs [3]. Arraez et al. provides an evaluation of HIP through experiments with the infraHIP inplementation, and Nikander et al. perform an analysis of HIP in general, but makes no comparisons to other KMPs [1][12]. For PANA and 802.1X, we found very few performance evaluations, and no comparisons to other KMPs. As shown above, while two of our relevant protocols have had some performance evaluations done for them, the other two have had a very limited amount. This illustrates the value in our report providing that. As we have also shown, a narrow amount of reports meant to compare and contrast these KMPs have been written, which motivates our report taking a focus on that.
Another goal of the report is to understand what changes need to be made to the specified KMPs to work according to IEEE 802.15.9, and how that affects their performance. For this end, a limited amount research seems to have been made, other than what is specified in the IEEE 802.15.9 standard itself.
3
Method
To reach the goals of this report we performed the following tasks:
1. Studied relevant documents regarding the Key Management Protocols we chose to fo-cus on.
2. Found open source implementations of the Key Management Protocols in 1).
3. Gathered information regarding the performance of the Key Management Protocols outlined in 1) and their implementations outlined in 2).
4. Studied and visualized the data gathered in 3).
3.1
Evaluating Key Management Protocols
To understand how each KMP works and to better be able to compare them we first had to outline what attributes we looked at in each. We decided to narrow down our research to 3 attributes after talking to our supervisor and discussing what key features would give a good overview of the KMPs in question. The attributes we looked at were the following:
• Functionality - Some protocols might offer functionality that others don’t. In this case it is important to outline how the functionality differs and what, if any, tradeoffs are necessary to achieve this functionality.
• Number of messages to establish connection and keys - By looking at the number of mes-sages the protocols use for the intial connection and key establishment we can better understand the space and time complexity of the various protocols.
• Overhead size - When choosing a protocol to use one might have to make the tradeoff between functionality and execution time. In such occasions it is important to consider the overhead of each message sent.
3.2. Evaluating KMP implementations
3.2
Evaluating KMP implementations
When planning the project we decided to use available open source implementations of var-ious Key Management Protocols. We did this since we estimated that the time to create our own implementation for several KMPs was too great and that we would not be able to do so in a reasonable amount of time.
We have considered several of these protocol implementations and have decided on using one for each Key Management Protocol due to the time limitations, as stated in section 1.5. When choosing which implementation to use, we tried to choose general purpose implemen-tations, as opposed to highly optimized implementation for specific purposes. We made this choice because the general purpose implementation would give us a general representation of the protocols, whereas the size and complexity of the specialized implementations could vary depending on the specific task they were designed to do.
When looking at the open source implementation we decided to look at 2 attributes in par-ticular. As in section 3.1, these attributes were chosen after a discussion with our supervisor. The attributes are the following:
• Protocol file size - By looking at how much memory each implementation uses we were able to determine if an implementation is better suited for low-memory systems, such as sensors in a WPAN network.
• Lines of code - Studying the lines of code (LOC) in an implementation gave us a picture of how complex the implementation is. For instance, an implementation with a low LoC-value might reflect on code that is better refactored, less complex and easier to maintain.
To count the LoC in each implementation we used an open source program called cloc which counts the lines of code, separating blank spaces, comments and actual code, for several different programming languages [2].
3.3
Method for KMP comparison
Once all the relevant data had been gathered and processed each attribute was individually compared between the different protocol implementations. Afterwards there was a compari-son of all the attributes at once.
Evidently it might be difficult to quantifiably compare some attributes, such as function-ality, however we still considered such information to be valuable from a comparative per-spective since it offered insight into the uses of each protocol implementation.
4
Results
We found four Key Management Protocols and corresponding implementations that we de-cided to analyze further. This section will be dedicated to the results we found regarding 802.15.9 as well as the various KMPs and the implementation we chose for each one.
4.1
802.15.9
IEEE 802.15.9 is a standard for the trasportation of KMP datagrams over 802.15.4 networks. The main difference between KMP datagrams in regular networks compared to 802.15.4 net-works is that 802.15.4 operates on the physical and MAC layers, meaning that there is no use of higher layer protocols such as IP or TCP/UDP. This presents the following problems regarding how one sends KMP datagrams over the network:
1. The MAC frame size is much more limited, meaning that for some KMPs the message size might exceed the frame size limit. Therefore fragmentation and reassembly is nec-essary.
2. KMPs that rely on higher-level protocols might need to be altered to work with 802.15.4 networks. This might mean that some functionality is lost.
To solve these issues, 802.15.9 defines a fragementation/reassembly service as well as several special versions of KMPs which are slightly altered in order for them to work with 802.15.4. These special versions and the changes they entail will be discussed later on along with their corresponding KMP in sections 4.2.3, 4.2.4, 4.4.3 and 4.5.3.
Fragmentation/Reassembly
In order to fragment and reassemble datagrams 802.15.9 defines a method called MPX. This way two nodes can send packets between each other over a MAC link. The payloads, which as previously mentioned might be larger than a single MAC frame, are fragmented into sev-eral MAC frames and then sent in a sequential order from the originator to the recipient. The recipient then reassembles the frames into the original payload.
4.1. 802.15.9
The fragmentation in MPX is done by a fragmentation method that uses MAC acknowl-edgment. This way unacknowledged frames are retransmitted and the originator can there-fore be assured that the recipient gets all of the frames necessary for reassembling the pay-load. In some cases the frame might get lost when it is passed to a higher layer, e.g. if a higher layer is overloaded at the time, and as such the MAC acknowlegment should only be taken as proof that the frame arrived at the recipient, not that it made it to the reassembly service.
If the originator fails to send a frame altogether then the transaction will fail and the MPX service will return an error status to the nearest high-level layer. In this case it is important that the receiver uses a timeout function since the MAC layer often does not posses a means of communicating that a transfer has failed. It should be noted that while there’s no method to signal that a frame wasn’t sent, there is a method to signal that allows either the originator or the recipient to end the transaction early. This might be done when one node doesn’t have the resources necessary to finish the transaction. The node can then abort the transaction and also send a message informing the other node as to the maxiumum size transaction which it can currently handle.
Figure 4.1: Example OSI model with MPX fragmentation/reassembly and MAC-link com-munication. As can be seen, the MPX fragmentation is part of the Network Layer.
4.2. Internet Key Exchange Protocol Version 2
4.2
Internet Key Exchange Protocol Version 2
The Internet Key Exchange Protocol Version 2, IKEv2, is a protocol that serves to establish SAs and perform authentication for IPsec.
IKEv2 operates in two phases: First, it performs a handshake to establish the connection between the two parties. In this handshake, the two parties do several things, which include deciding on cryptographic algorithms, performing authentication, establishing a session key and finally creating the IKE-SA. This IKE-SA is then used for the second phase, in which the two parties can now send authenticated messages, perform reliable liveness checks and establish Child SAs at a low cost. These Child SAs are essentially another SA between the two parties, with its own keys and encryption. This allows for data to be sent between the two parties through different SAs, and is useful if e.g. the two parties are routers sending and receiving data on behalf of multiple users. In such a case, the users might be more comfortable knowing that their data is encrypted separately from the other users’ data.
Key establishment
In IKEv2, all communication consists of a request/response pair. For example, the intial handshake is made up of two request/response pairs, as can be seen in Figure 4.2. The first one is called the IKE_SA_INIT, and it is where the cryptographic algorithms are ne-gotiated, as well as the Diffie-Hellman exchange is performed. The second exchange is called the IKE_SA_AUTH. By now the connection between the two parties is encrypted, as well as integrity protected, using the keys established in the previous Diffie-Hellman exchange. In this exchange the parties now identify themselves, authenticate those identities using some public or shared key in conjunction with the previously established keys, and create the IKE-SA.
In the second phase, the exchanges are called CREATE_CHILD_SA exchanges and con-sist of one request/response pair each. Theses exchanges are used to, as the name suggests, create new child SAs, but is also used to rekey the IKE SA or existing Child SAs. There is also a fourth type of exchange, called the INFORMATIONAL exchange. These INFORMA-TIONAL exchanges are only allowed after the intial exchanges are completed, and are used to communicate control messages regarding events or errors [8].
4.2. Internet Key Exchange Protocol Version 2
Packet information
Each IKEv2 message has an IKE header as shown in Table 4.1. An explanation of the fields will now follow:
• IKE SA Initiator’s/Responder’s SPI, 8 bytes each
These two fields contain an ID identifying a unique IKE SA established between the two parties.
• Next Payload, 1 byte
This field contains a value that identifies which type of payload that will follow the header.
• Major Version, 4 bits
This field states which major version of IKE that is used. For IKEv2, this value is set to 2.
• Minor Version, 4 bits
This field states which minor version of IKE is used. For IKEv2, this field is set to 0 and ignored in all messages.
• Exchange Type, 1 byte
The value in this field indicates which type of exchange this header is for, i.e. if it is an IKE_SA_INIT, IKE_SA_AUTH, CREATE_CHILD_SA or INFORMATIONAL exchange. • Flags, 1 byte
This field contains 3 flags, indicating whether this message is a response or not, if the sender can use a higher version of IKE or not and if the sender was the intiator of the SA or not, respectively.
• Message ID, 4 bytes
This field is an identifier that serves the purpose of controlling retransmission of pack-ets, as well as matching requests and responses. This field is vital to prevent message replay attacks.
• Length, 4 bytes
This field states the length, in bytes, of the message including header and payloads. Each IKE message fits inside a single UDP payload. This means that each packet that contains an IKE message will contain exactly one IKE header. Summing the sizes of all the header fields provides us with a total overhead of 28 bytes per packet. In addition to this, each IKE payload has a generic header of 4 bytes. Since the number of IKE payloads vary be-tween different IKE messages, it is difficult to give a general answer to how much additional overhead this adds per UDP payload.
IKE SA Initiator’s SPI IKE SA Responder’s SPI
Next Payload Major Version Minor Version Exchange Type Flags Message ID
Length
4.2. Internet Key Exchange Protocol Version 2
IEEE 802.15.9 specifics
In 802.15.9, IKEv2 does not use IP and UDP, but instead operates just above the MAC layer. This would normally limit the size of the payloads to some tens of bytes, but the MPX data layer specified in 802.15.9 allows for a payload to be split up into a maxiumum of 256 frag-ments. This allows for transportation of payloads which are several thousand bytes in size.
There is also some functionality of IKEv2 that is not supported in IEEE 802.15.9. These are:
• Negotiation of multiple protocols within same proposal • Capability to handle multiple outstanding requests • Cookies
• Configuration Payload • NAT-Traversal
The first two limitations makes it so that IKEv2 needs to use more exchanges to set up SAs, and needs to handle one request at a time. The third limitation makes it so that a responder can not have an initiator retry the intitation when there are several half-open IKE SAs. This should not be a severe limitation however, since IEEE 802.15.9 recommends only one SA between two nodes. The fourth and fifth limitations limit IKEv2s ability to operate across gateways, specifically IRAS and NAT, respectively. Since IEEE 802.15.4 focuses specifically on WPANs, this should not be a severe limitation.
IEEE 802.15.4 also only supports a single cryptographic algorithm, the AES-CCM* cipher. This means that although IKEv2 supports several different algorithms for algorithm negotia-tion, AES-CCM* must be used.
There is also functionality that could be needed in IEEE 802.15.9 that is not present in IKEv2, specifically broadcast and multicast. If such functionality is needed, it would need to be added to any IKEv2 implementation used [16].
Implementation
The implementation of IKEv2 that we chose to evaluate was the strongSwan project version 5.6.2, released in February of 2018. We chose this project mainly since it was actively being maintained and developed, and was recommended to us by our supervisor. Strongswan contains a total 413,531 LoC, 378,988 of which are in C, Java or C header files, which is the main body of the code [19]. These files, along with various support configuration and testing files, amount to 100 MB of data.
4.3. Host Identity Protocol Version 2
4.3
Host Identity Protocol Version 2
The Host Identity Protocol Version 2 (HIPv2), as defined in RFC 7401, is a protocol which allows two consenting parties to establish and maintain a secure shared IP-layer state [11]. This allows the two parties to separate the identifier and locator roles of IP addresses, which allows the parties to keep communicating even if their IP-addresses change. This is beneficial for systems where two parties wish to continuously communicate whilst their IP-addresses change on a regular basis since they won’t have to go through the process of indentifying the other party more than once.
When speaking of HIP there are two versions to consider, firstly the standard HIPv2 Base Exchange (HIP BEX) and secondly HIPv2 Diet Exchange (HIP DEX). HIP BEX uses public keys, created by an ephemeral Diffie-Hellman key exchange, to ensure safe communication between the communicating paries. It is designed to be resistant to both denial-of-service (DoS) and man-in-the-middle attacks. It is worth noting that HIP BEX does not provide integrity protection, however can do so when used in conjunction with another relevant pro-tocol such as Encapsulated Security Payload (ESP).
HIP DEX
HIP DEX is designed to be a lightweight version of HIP BEX [7]. To become more lightweight, HIP DEX has made several trade-offs between functionality and overhead. Some of the more notable examples include:
• Instead of using public keys and ephemeral Diffie-Hellman key-pairs, HIP DEX in-stead uses static Elliptic Curve Diffie-Hellman key pairs for peer authentication and key agreement.
• HIP DEX swaps the AES-CBC encryption method for AES-CTR, and also swaps the HMAC-SHA-1, HMAC-SHA-256 and HMAC-SHA-384 MACing methods for AES-CMAC.
• HIP DEX uses a more efficient and simpler fold function in order to generate Host Iden-tity Tags, while HIP BEX HIT-generation uses SHA-1, SHA-256 or SHA-386.
These trade-offs means that the HIP-DEX overhead is reduced and that the protocol is more lightweight overall, making it better suited for computation or memory-constrained devices. However it also means that HIP DEX loses functionality such as HIPv2s Perfect For-ward Secrecy and digital signatures. HIP DEX also only protects HIP packets, and separate session key(s) need to be generated in order to protect the protocol data transmitted at upper layers.
Key establishment
For key establishment, HIP uses a Sigma-compliant four-packet exchange. The two parties in question are called the Initiator and the Responder. The Initiator starts the exchange by sending the first message, I1, which includes the Host Identity Tag (HIT)-values of the com-municating nodes. After receiving I1, the Responder replies with R1, which includes a pre-computed puzzle which the Initiator has to solve. The puzzle’s difficulty can be adjusted based on several factors, such as the current load of the Responder. By using a puzzle and re-maining stateless until after I2, HIP creates a layer of protection against DoS attacks. R1 also starts the Diffie-Hellman exchange and contains the Responder’s key and signature value.
4.3. Host Identity Protocol Version 2
After R1 the Initiator solves the Responder’s puzzle and sends the answer, along with the Initiator’s public key, in I2. Finally the Responder verifies the answer given in I2, authenti-cates the Initiator and creates an IPSec-session. This way the Responder stores no information until after I2 is received and verified. The final R2 package contains the SPI-parameters for the Responder and it is not until after this message that data-packets begin to flow.
Key establisment is similar between both HIP BEX and HIP DEX. However it should be noted that some slight differences may apply. For instance, in the 2nd and 3rd packages the Initiator and Responder will exchange their public keys in HIP BEX, whereas in HIP DEX they will instead exchange their static Elliptic Curve Diffie-Hellman key pairs. It is also important to keep in mind that HIP DEX cannot encrypt the Host Identity of the Initiator and Responder in the 2nd and 3rd packets, which means that HIP DEX does not allow end-point anonymity.
Figure 4.3: A typical HIPv2 handshake.
Packet information
HIP packets all start with the same fixed header. The header is an extension of the IPv6 header and as such has a maximum size of 40 bytes. The biggest difference between the IPv6 header and the HIPv2 header are the HIT-fields. The HIT-fields replace the standard Source and Destination Address fields in IPv6 packets and are always 16 bytes long.
Seeing as how the HIT-values make up the large majority of the HIP header, carrying HIs and HIT-fields in every packet would lead to a large packet overhead. As such HIPv2 is designed so that the HIT-fields are not expected in every packet and other methods are instead used to map the packets to a corresponding HI.
Next Header Header Length 0 Packet Type Version Res. 1
Checksum Controls
Sender’s Host Identity Tag (HIT) Receiver’s Host Identity Tag (HIT)
HIP Parameters
4.3. Host Identity Protocol Version 2
IEEE 802.15.9 specifics
Since HIP has no IP or TCP/UDP content in either the DEX or BEX versions, it doesn’t need many changes to work with the 802.15.9 standard [17]. The IEEE recommends the following changes and practices when using HIP in 802.15.4 networks:
• Using a fixed AES-CCM algorithm and a related AES-CMAC authentication method, since those are the only ones supported in 802.15.4. Therefore no algorithm negotiation is necessary.
• Preinstalling Host Identities and Host Identity Tags in devices to avoid the high cost of generating them. They can also be printed on QR codes and scanned for loading into authentication services.
• Using either ACL-based, RADIUS-based, certificate-based or coordinator authentica-tion methods to authenticate HITs.
Implementation
For HIP, we’ve chosen to focus on the OpenHIP implementation. OpenHIP is a small imple-mentation by comparison to some of the others in this report. However we chose to research it for the following reasons:
1. OpenHIP was updated as recently as December 2017, which means that the implemen-tation is more likely to be up to date.
2. OpenHIP is developed as part of a course at Linköping University, where this study was conducted. The course is also taught by the supervisor of this report. As such we felt assured that if we had any questions we could easily get answers to these since we have easy access to developers behind the implementation.
OpenHIP contains a total of 34,890 LoC, 33,627 of which are in C, C++ or C/C++ header files, which is the main body of the code [14]. The project amounts to 3.5 MB of data in total.
4.4. PANA
4.4
PANA
The Protocol for Carrying Authentication for Network Access, PANA, is a protocol operat-ing at the network layer designed to provide transportation of authentication methods for network access [rfc5191]. It is also designed to work with the Extensible Authentication Pro-tocol (EAP), which provides these methods of authentication. This means that the actual authentication algorithms, methods, keys etc. are handled by the EAP, and PANA serves to transport EAP payloads and help the communicating parties establish an EAP session. These two parties consist of a client, called PANA Client (PaC), and a server, called PANA Authen-tication Agent (PAA). To send PANA messages between themselves, a PaC and a PAA needs to establish a PANA session, which consists of four distinct phases:
• Authentication and Authorization Phase
During this phase the PANA session is established and the two parties authenticate themselves using the EAP.
• Access Phase
During this phase the parties can receive and send IP traffic as well as check liveness of the PANA session.
• Re-authentication Phase
This phase is a sub-phase of the access phase, and is entered when either party wants to extend the lifetime of the PANA session. To do this, PANA carries EAP payloads to perform re-authentication. Upon completion, the session returns to the access phase. • Termination Phase
This phase is entered when either party chooses to end the session. This can either be done through explicit termination messages, or by simply disconnecting. If the second option is chosen, session expiration or failure of a liveness test will eventually end the session for the other party
4.4. PANA
Key establishment
In PANA, key establishment is optional. However, since the goal of this report is to com-pare different Key Management Protocols, we will only consider the use case where keys are established. Key establishment in PANA occurs during the authentication and authorization phase. To establish keys, the PaC and the PAA need to agree on certain algorithms to be used. To do this, the PAA sends a list of PRF- and integrity algorithms to the PaC, which then se-lects one of each and responds with it. Following this intial exchange, the next PANA request must include a nonce, which the other party then responds to. In the case that a key has suc-cessfully been established, the PAA also needs to send another request with the Key-Id and AUTH for the first keys in the session.
Figure 4.4 shows a typical PANA authentication and authorization phase for key estab-lishment, in this case where the PaC is the initiator of the PANA session.
Figure 4.4: A typical PANA authentication and authorization phase.
Packet information
Each PANA message has a header as shown in Table 4.3. Reserved Message Length
Flags Message Type Session Identifier Sequence Number Table 4.3: The PANA Header. A description of the different fields follows below: • Reserved 2 bytes
4.4. PANA
• Flags 2 bytes
This field includes several flags indicating certain special message types, such as re-quests and liveness tests.
• Message Type 2 bytes
This field indicates which type of message this PANA message is. • Session Identifier 4 bytes
This field contains the session identifier, indicating which session this PANA message belongs to.
• Sequence Number 4 bytes
This field contains the sequence number, indicating which message in the sequence this PANA message is.
Summing the fields of the PANA header tells us that the header adds an additional 16 bytes overhead to each PANA message. In addition to this, most PANA message include 0-1 AVP messages. These carry their own headers, which are shown in Table 4.4.
AVP Code AVP Flags AVP Length Reserved
Vendor-ID (Optional) Table 4.4: The AVP Header.
A description of the different fields in the AVP header follows below: • AVP Code 2 bytes
This field identifies, optionally with the Vendor-Id field, an attribute. If the Vendor-Id field is included the attribute is a PANA attribute, otherwise it is an IETF attribute. • AVP Flags 2 bytes
This field includes a single flag to indicate wether the Vendor-Id field is in use or not. • Avp Length 2 bytes
This field indicates the length of the AVP message excluding the header length. • Reserved 2 bytes
Like in the PANA header, this field is reserved for future use. In use it is set to zero and ignored by the receiver.
• Vendor-Id 4 bytes
This optional field is included if the flag is set for it in the AVP Flags field. It is used if the implementor wants to use their own specific PANA AVP.
The AVP header adds an additional 12 bytes of overhead to the AVP message. However, as stated previously, an AVP message is not included in every PANA message. Most often there is either one or no AVP message included, meaning that usually, this header adds at most 12 bytes of overhead to the entire payload.
IEEE 802.15.9 specifics
In IEEE 802.15.9, PANA’s main use is providing link-layer credentials, also known as boot-strapping. Indeed, when a KMP.CREATE request is issued with any KMP other than PANA, that KMP will first, internally, use PANA to obtain the LLCs. PANA itself should not be used to invoke a KMP.CREATE request. This special use of PANA in 802.15.9 makes it not so much an alternative as a complement to other KMPs operating in IEEE 802.15.9. Every other KMP
4.4. PANA
Implementation
It was difficult to find an actively maintained open source implementation of PANA. We did however find two older open source iplementations, CPANA, a lightweight implementation from 2010 and OpenPANA, a more versatile and feature-heavy implementation from 2014. From these we chose openPANA because it was the most recent implementation, as well as the most general one. CPANA, on the other hand, implements far fewer features, e.g. only one EAP method, and according to Moreno-Sanchez et al. its main weakness is its lack of implemented features and its strength is the optimization of the features it does implement [10]. As such, we deemed the more general OpenPANA implementation to be a better repre-sentation of the protocol. The fact that OpenPANA also was more recently updated solidified it as the implementation of our choice.
OpenPANA contains a total 181,789 LoC, 171,035 of which are in C, C++, or C/C++ header files and is the main body of the code [15]. In total the project is 14 MB of data.
4.5. 802.1X
4.5
802.1X
IEEE 802.1X defines a port-based network access method for IEEE 802 networks. The prot-col allows for the restriction of network access to authenticated and authorized systems by authenticating a device before it is granted network access. 802.1X achieves this by using Extensive Authentication Protocol packets which are transported between the client which awaits authentication, called the Supplicant, and an Authenticator Port Access Entity. The Authenticator then sends the information to an Authentication Server to check whether or not the Supplicant device is valid.
The authentication provided in 802.1X does not provide any protection of the actual frames and messages sent in WPAN devices. However when a device is succesfully authenti-cated the authentication packets can be accompanied by a secret key which can then be used by both the Supplicant and Authenticator for mutual authentication or to be used for future secret keys. There are several key agreement protocols that are used that can use the EAP secret to agree upon a secret key in 802.1X. In this report we’ve focused on some of the more common examples.
The first is IEEE Standard 802.1X-2010 which specifices a MACsec Key Agreement (MKA) protocol. The secret key that is used in MKA is derived from EAP and is called the Con-nectivity Association Key (CAK). In some instances the CAK can also be shared between communicating stations beforehand. After the CAK has been established the key can then be used to discover other Port Access Entities connected to the same Local Area Network (LAN). By doing this the Supplicant can confirm mutual possesion of a CAK and by doing so also prove a previous mutual authentication. It can also agree to the secret keys to be used by datagram security services.
The second protocol for key agreement is IEEE Standard 802.11-2012 which, similarly to the previously mentioned 802.1X-2010, derives a Master Session Key (MSK) from EAP. It then uses the MSK to protect 4-Way Handshake and Group Key Handshake protocols.
KMP PDU Format
IEEE 802.1X MKA EAPOL-MKA IEEE 802.11/4WH EAPOL-KEY IEEE 802.11/GHK EAPOL-KEY
Table 4.5: The KMPs used in 802.1X and their Protocol Data Unit formats.
Key establishment
As previously mentioned, 802.1X does not provide any frame protection in and of itself and instead relies on the KMPs listed in Table 4.5 for agreeing upon a shared key derived from EAP. After establishing a secure shared key it is then possible for the communicating devices to agree upon keys and policies for secrurity services.
4.5. 802.1X
For IEEE 802.1x/MKA, the key agreement first starts with a KMP-CREATE request. This results in an IEEE 802.1X/EAP protocol followed by an IEEE 802.1X/MKA protocol. This is meant to authenticate the device and allows for the MKA to agree upon a Security Asso-ciation. In some instances, higher layer protocols can create additional keys by sending the additional KMP-CREATE.requests using the same instance of IEEE 802.1X/MKA. Once the exchange is done and an SA has been created, a KMP-FINISHED.indication message is sent.
Figure 4.5: IEEE 802.1X/EAP and IEEE 802.1X/MKA used together as a PAN KMP. Firstly EAP is used to autheticate the device and then MKA is used to create a key.
In the case that the Connectivity Association Keys have been shared beforehand, by for instance pre-installing a CAK on devices in the network, it is possible to disregard the IEEE 802.1X/EAP protocol shown in Figure 4.5.
IEEE 802.11/4WH and IEEE 802.11/GKH can also be used as KMPs. The 4WH results in a pairwise key used for point to point communication, while GKH results in a group key which can be shared across multiple WPAN devices. Key agreement functions similarly to IEEE 802.1X/MKA, however there are some minor differences.
It is important to note that each invocation of both IEEE 802.11/4WH and IEEE 802.11/GKH are independent and can happen in any order.
Packet information
IEEE 802.1X uses 802.3 ethernet frames for communication. If we exclude the data payload and focus on the overhead we get the following values for the frame:
• Preamble (PRE) 7 bytes
Start of the frame and consists of a pattern of alternating ones and zeros. It informs the receiver that the frame is starting.
• Start of Frame delimiter (SOF) 1 byte
4.5. 802.1X
Figure 4.6: IEEE 802.1X/EAP, IEEE 802.11/4WH and IEEE 802.11/GKH used together as a PAN KMP. Similarly to Figure 4.5, EAP is used for authentication and then a key can be created with either 4WH or GKH.
if the address is a group or individual address and if the address is globally or locally administrated.
• Source Address (SA) 6 bytes Identifies the sender of the frame. • Length / Type 2 bytes
Provides MAC information as well as indicated how many client data types that are contained in the payload.
• Frame Check Sequence (FCS) 4 bytes
Contains a Cyclic Redundancy Check which has been generated over the Destination Address, Source Address, Length/Type and Data payload fields.
IEEE 802.15.9 specifics
The previously mentioned 802.1X KMPs send messages which are carried in either EAPOL-MKA or EAPOL-KEY formated EAPOL-PDUs.
EAPOL-MKA requires several modifications to both the parameters and semantics of messages to make them compatible with 802.15.9 [18]. Firstly an integrity check value (ICV) has to be calculated by using AES-CMAC. The ICV protected bytes are denoted as M and are defined as:
M=DA+SA+ (EAPOL ´ ICV) (4.1)
where
• DA and SA are the destination and source addresses. • EAPOL is the EAPOL-PDU.
4.5. 802.1X
The following EAPOL-MKA fields require some modifications:
• Latest Key AN and Distributed AN are instead referred to as the KeyIndex, which is also reduced in size to 0x00-0x11.
• MACsec Cipher Suite instead means the "WPAN CCM* Cipher Suite". The following EAPOL-MKA fields are unused:
• Old Key AN, Old Key tx, Old Key rx • Delay Protect
• Latest Key Lowest Acceptable PN, Old Key Lowest Acceptable PN • Offset Confidentiality
MKA also requires each node to transmit an MKA message every 2 seconds, which might be too much of a power drain on 802.15.4 systems, especially battery powered ones. Therefore it might be useful to set an MKA suspension time, as defined in IEEE Std 802.1Xbx-2014, which tells the MKA key server not to expect MKA messages from the node for the duration of the suspension.
Finally, EAPOL-KEY messages require the following minor modifications to work with 802.15.9:
• KEY ID now maps to the Key Index field.
• The Cipher Suite Selector will be set to 00-0F-AC-12.
Implementation
While searching for 802.1X implementations we encountered the problem that many projects only focused on one aspect of the protocol. For this reason we’ve chosen a combination of two projects for our 802.1x implementation.
The first is Open1X, which provides support for the Supplicant, which would be operated on the client. It should be noted that support for the Supplicant is built into most operating systems today, such as Windows 10, and is therefore redundant in many cases. However the source code for these implementations is proprietary and as such we would not be able to analyze it. Open1X was last updated in 2010 and contains 207,136 LoC, 130,413 of which are in C, C++ or C/C++ header files [13]. This project amounts to 18.3 MB of data.
Secondly we’ve chosen to use FreeRADIUS which provides support for the Authentica-tion Server. FreeRADIUS supports mutiple authenticaAuthentica-tion types, is used daily by 100 million people and is updated on a regular basis. Based on this we decided that is was a good choice for our Authentication Server. FreeRADIUS contains a total of 325,288 LoC of which 155,698 are in C and C/C++ header files, and its files amount to 106 MB of data [6].
5
Discussion
5.1
Results
The protocols that we have brought up in this report all share similar functionality on a basic level, however they all have their own nuances and distinct uses. To provide a better under-standing of the differences between these protocols and how best to use them, this section will be devoted to comparing them with each other and illustrating their use cases.
Protocol comparison
In comparing the different protocols we found that IKEv2 has a lot of functionality that the others don’t. While it might not seem too different when comparing the messages sent or the overhead size, IKE’s array of features means that it is much more complex and memory dependant. While some functionality is optional, much of it, such as NAT detection and DoS protection, are built in to the protocol. For use cases where such functionality is unwanted or unneeded, IKEv2 might be superfluous.
HIPv2’s main feature is its separation of the locator and identifier roles which are com-monly held by the IP address. As such HIP turns out to be a good option for certain networks where the nodes are mobile and changing IP addresses on the regular. HIP’s features also means that it has the ability to work in an ad-hoc network where there is no centralized in-frastructure. Due to minimal amount of features in HIP compared to the other protocols, it lends itself to being rather lightweight.
When researching the Key Management Protocols we found that PANA and 802.1X share very similar functionality, however PANA has the ability to send its packets over other nodes while 802.1X only has the ability to send its messages to the Authenticator directly.
A key difference between PANA and 802.1X compared to IKEv2 and HIPv2 is that they are built to authenticate to a network rather than to another entity and as such they need a central Authenticaton Server. Conversly, IKEv2 and HIPv2 can operate without the need for a central infrastructure.
5.1. Results
IKEv2 HIPv2 PANA 802.1X
Functionality Many options, Identifier Client-to network Authentication authentication and locator authentication, with EAP methods included separation Authentication
with EAP
Number of messages 4 4 6 6
Overhead size (bytes) 28 + 4n 40 16 (+12) 26
Table 5.1: Comparison of the various protocol attributes. Note the 4 byte generic header for IKEv2.
Implementation comparison
When researching and comparing the different implementations we found that strongSwan was by far the largest of the KMPs we analyzed. This came as no suprise seeing as how IKEv2 hosts an impressive amount of features. However this means that strongSwan’s 107 Megabytes is less suited for devices with constrained memory. strongSwan also contained the most lines of code, indicating that the implementation might be more complex than the others and difficult to configure.
OpenHIP proved to be the smallest implementation, coming in at 33,627 lines of code and only 3,5 Megabytes of data. To an extent this can be explained by the fact that OpenHIP is not updated as regularly or as feature heavy as the other implementations. This would indicate that the implementation might be better suited for smaller networks or ones where the developer might want to be able to better configure the implementation.
While PANA and 802.1X may look very similar, their implementations don’t. OpenPANA features significantly fewer lines of code and a much smaller file size. This is mostly because of OpenPANA being a lightweight solution which requires the use of another compatible client.
Open1X combined with FreeRADIUS is the largest implementation in terms of file size. In large part this is because of FreeRADIUS since the server side application features many graphical elements as well as several modules for other authentication methods. While the lines of code means that it might be complex to work with the code itself, the developers have made efforts to create an easy to use client for the user which proves beneficial when creating an 802.1X system.
strongSwan OpenHIP OpenPANA Open1X & FreeRADIUS
Lines of Code 378,988 33,627 171,035 286,111
File size (MB) 107 3.5 14 124.3
5.1. Results
KMP usage according to 802.15.9
In our research we found that the amount of modifications necessary to operate the various KMPs in 802.15.4 networks varies greatly from KMP to KMP. In this section we wish to dis-cuss how the KMPs might differ in 802.15.4 networks and what ramifications those changes have.
HIP
HIP requires the least amount of changes in order to operate in 802.15.9 and as such might be a good choice if one doesn’t want to spend time converting the KMP for 802.15.4 use. The OpenHIP implementation is also not too complex which means that it would most likely be easier to implement according to 802.15.9. Finally, the low amount of changes required has the added benefit of ensuring that the developer would be familiar with the way the KMP works in 802.15.4 networks if they have used HIP previously.
We suggest using this protocol in a system when one wishes to use node to node commu-nication while also keeping the development complexity as well as memory usage low.
802.1X
802.1X requires a moderate amount of changes in order to operate in 802.15.4 networks. While it is mostly semantics based, swapping names of fields with the MPX IE counterpart, there are also some features that get changed or in some cases even dropped. As such, implementation of 802.1X according to 802.15.9 would take a significant amount of time and would be slightly different from the regular version.
We suggest using this protocol when one has the time to create a moderatly complex system and also desires a group of nodes to communicate between each other using uni-cast/multicast/broadcast frames.
IKEv2
As can be seen in Table 5.2, IKEv2 uses a lot of memory due to its wide array of features. This poses a problem since 802.15.4 network nodes often operate with little memory and processing power. For this reason many of the features of IKEv2 have to either be dropped or modified in order for the protocol to become more light-weight. As a result of this, creating an IKEv2 implementation that works in accordance with 802.15.9 is a substantialy more complex task compared to other protocols, such as HIP.
In our view IKEv2 would be best suited for 802.15.4 networks where there is a central, more powerful node along with other less powerful nodes. An example of this is a sensor network with a central node that collects the data from the sensors in the network. It should be noted that creating such an implementation would most likely require a longer develop-ment time compared to the other protocols in this report since there are a high amount of changes needed to create an IKEv2 implementation according to 802.15.9.
PANA
As stated in section 4.4, PANA is not to be used as a general purpose KMP in IEEE 802.15.4 networks. It is specifically to be used to acquire LLCs that other KMPs will then use. For this use case, a PANA implementation should require very few changes. It is to be noted that a PANA payload could exceed the MTU for a IEEE 802.15.4 network. This would be an issue if not for the fragmentation functionality specified in IEEE 802.15.9.
5.2. Method
5.2
Method
The most important limitation of our method is the fact that it is a purely a study of litterature. This causes our results to be highly theoretical, and they might not accurately reflect the practical performance of the investigated KMPs.
The number of implementations investigated per KMP can also be a source of error, or at least a misrepresentation of the KMP. Since we only investigated one implementation per KMP, there is a risk that we did not select an implementation that is representative of the KMP and would thus introduce errors into our discussion and conculsion. This risk is mitigated by us trying to select general purpose, popular and frequently updated implementations, but the risk still exists nonetheless.
There are also some attributes of the KMPs that we chose not to investigate, either for lack of time or the means to investigate them. The exclusion of these attributes is not neccessarily a source of error in regards to our results, but including them might have given us a different view of each KMP and thus affected our discussion and consequently our conclusion.
The sources used for our results are mostly RFCs and IEEE standards. RFCs can vary in reliability and should therefore generally be approached cautiously. However, we made an effort to only include RFCs that were directly connected to the KMPs investigated, usually only the actual defining RFC, which should mitigate the impact of potentially unreliable in-formation from RFCs. IEEE standards on the other hand are large collaborations between several people and approved by a board and should therefore include few errors. This makes these standards excellent sources of information.
5.3
The work in a wider context
Small scale WPAN-networks are becoming more and more frequent as the Internet of Things grows. Therefore it is important to know how one best should build such a network while also maintaining a level of privacy and encryption by using Key Management Protocols. By researching KMPs and their implementations we can enable future engineers and researchers to build these networks while maintining proper security for the end-users.
6
Conclusion
The aim of this report was to answer these three research questions:
• How does the 802.15.9 standard, and the underlying 802.15.4 standard, work and what changes are neccessary for KMPs in 802.15.9?
• To what extent does each KMP impact attributes such as overhead size, functionality and number of messages per exchange?
• How do the attributes of the different KMPs compare to each other? • Which relevant factors cause the difference in KMP performance?
We have gone over the inner working of 802.15.9 and how it for instance fragments and reassembles payloads from higher layers. We then analyzed and discussed how each KMP differed from its original form when used in accordance to 802.15.9. In general we found that the difference in KMPs between the regular and 802.15.9 compatible versions varies greatly from protocol to protocol. Some require minimal changes while others require massive over-hauls to be compatible with 802.15.4 networks.
In this report we have also managed to identify factors for each KMP such as overhead size, funtionality and number of messages per exchange. Ontop of that we have also man-aged to find other information regarding the KMP implementations, such as the number of lines of code and how much memory each impelementation takes up.
As for impact, by studying these KMPs and their attributes we can safely conclude that functionality reflects on the complexity and size of a KMP implementation. Larger and more complex KMPs, such as IKEv2, lead to bigger implementations whereas a more minimal KMP like HIPv2 features less complex implementations.
However more functionality does not always mean that every attribute becomes more complex. If we compare IKEv2 and HIPv2 again we can see that IKEv2, while being much more complex in terms of the features it offers, uses the same amount of messages to establish a secret key as HIPv2.
6.1. Future work
In large part we consider the functionality to be the main cause in difference in KMP per-formance. However, while we’ve tried our best to find the factors behind KMP performance we do recognize that not all factors might have been found. Due to both the limited time for this project and the limited prior knowledge on the subject, we understand that there might be other factors which we have not explored.
To conclude, we have answered the questions we laid out in the report and done an inves-tigation of various Key Management Protocols and their impelementations. We hope that in the future this report can be used as a point of reference when network administrators, engi-neers and researchers need to find the Key Management Protocol that best suits their general or 802.15.4 system.
6.1
Future work
We admit that the limited time of this study meant that we could not go as in depth for each KMP as we would have wanted. As such we would find it interesting for future works without the same time limitations to look at several different implementations for the same KMP and then compare the attributes of these. One could also look at more, or completely different attributes than those we chose.
Another interesting future research topic would be to implement these KMPs in actual hardware. Then these implementations could be tested to find other interesting attributes, such as differences in energy consumption or response time.
Finally we think an in-depth comparison of KMPs not listed in this research would also be interesting. There are many more KMPs out there than those we have brought up here and comparing them to each other, or even the results gathered here, could lead to interesting results.
Bibliography
[1] L. Arraez, H. Chaouchi, and Z. Gurkas Aydin. “Performance Evaluation and Exper-iments for Host Identity Protocol”. In: IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 2. Mar. 2011, 74
bibrangedash 83.
[2] CLOC. https://github.com/AlDanial/cloc, accessed 2018-05-10.
[3] Cas Cremers. Key Exchange in IPsec revisited: Formal Analysis of IKEv1 and IKEv2. 2013. [4] Z. Faigl, S. Lindskog, and A. Brunstrom. A Measurement Study on IKEv2 Authentication
Performance in Wireless Networks. 2013.
[5] S. Frankel and S. Krishnan. IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap. RFC 6071. IETF, Feb. 2011.
[6] FreeRADIUS. https://github.com/FreeRADIUS/freeradius-server, accessed 2018-05-10.
[7] Moskowitz Hummen. HIP Diet EXchange (DEX). Internet-Draft draft-ietf-hip-dex-06. IETF, Dec. 2017.
[8] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, and T. Kivinen. Internet Key Exchange Protocol Version 2 (IKEv2). RFC 7296. IETF, Oct. 2014.
[9] J. B. R. Lawas, A. C. Vivero, and A. Sharma. “Network performance evaluation of VPN protocols (SSTP and IKEv2)”. In: 2016 Thirteenth International Conference on Wireless and Optical Communications Networks (WOCN). July 2016, 1
bibrangedash 5.
[10] P. Moreno-Sanchez, R. Marin-Lopez, and F. Vidal-Meca. An open source implementation of the protocol for carrying authentication for network access: OpenPANA. University of Mur-cia, Apr. 2014.
[11] Moskowitz, et al. Host Identity Protocol Version 2 (HIPv2). RFC 7401. IETF, Apr. 2015. [12] P. Nikander, A. Gurtov, and T. R. Henderson. “Host Identity Protocol (HIP):
Connectiv-ity, MobilConnectiv-ity, Multi-Homing, SecurConnectiv-ity, and Privacy over IPv4 and IPv6 Networks”. In: IEEE Communications Surveys Tutorials 12.2 (2010), pp. 186–204.
Bibliography
[15] OpenPANA. https://github.com/OpenPANA/openpana, accessed 2018-05-10.
[16] IEEE Computer Society. IEEE Recommended Practice for Transport of Key Management Pro-tocol (KMP) Datagrams. IEEE, Aug. 2016, p. 13.
[17] IEEE Computer Society. IEEE Recommended Practice for Transport of Key Management Pro-tocol (KMP) Datagrams. IEEE, Aug. 2016, pp. 58–59.
[18] IEEE Computer Society. IEEE Recommended Practice for Transport of Key Management Pro-tocol (KMP) Datagrams. IEEE, Aug. 2016, pp. 51–53.
