EAP Method Update Working Group N. Oualha Internet Draft A. Olivereau CEA LIST Intended status: Informational October 21, 2013 Expires: April 2014 EAP-based simultaneous re-authentication of a group of nodes draft-oualha-group-auth-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 21, 2014. oualha Expires April 21, 2014 [Page 1] Internet-Draft group-auth October 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This Internet-Draft presents a new scheme that enables the simultaneous re-authentication of a group of nodes in an efficient manner. The Internet-Draft proposes to aggregate the re- authentications of multiple network nodes members of the same group. The scheme is based on the Extensible Authentication Protocol (EAP) framework, defined in RFC 3748. As an example of operation, a method inspired from EAP-GPSK RFC 5433, is provided. Table of Contents 1. Introduction ................................................ 1 2. Terminology ................................................. 2 3. Approach overview ........................................... 4 3.1. Assumptions ............................................ 4 3.1.1. Network topology .................................. 4 3.1.2. Secure group communications ....................... 4 3.1.3. Aggregatable messages ............................. 5 3.2. Message exchanges ...................................... 5 4. Extensions to EAP-GPSK ...................................... 6 5. Security Considerations ..................................... 8 6. IANA Considerations ......................................... 8 7. Acknowledgements ............................................ 8 8. References .................................................. 8 8.1. Normative References ................................... 8 8.2. Informative References ................................. 9 1. Introduction The initial authentication of a node, sometimes referred to as bootstrapping, is generally followed by subsequent re- authentications either in a periodic-basis or because of node mobility. In some situations, a group of nodes are required to perform re-authentication at the same time. For example, nodes may oualha Expires April 21, 2014 [Page 2] Internet-Draft group-auth October 2013 have the same mobility pattern, so they arrive at the same time to a new network and need to re-authenticate. In another example, nodes may be part of the same network that is subject to some administrative changes (e.g., gateway replacement) that require nodes to re-authenticate. Besides temporal or spatial proximity of nodes, nodes with the same interest to access a given resource or service, all may also need to authenticate to the service provider to gain access. By forming a group of nodes, re-authentications can be aggregated within the group of nodes. The advantages of message aggregation are multiple: o In-network message aggregation allows to reduce the number of authentication messages exchanged between the group of nodes and the authentication server (typically, the number of messages goes from n to log(n) with aggregation). The communication medium, in which access is the most expensive element for sensors/actuators for example, is less solicited. o Thanks to aggregation, the network is less congested. In particular, the load at intermediary nodes in the network (e.g., routers) is reduced, making the risk of having a bottleneck diminished. o The proposed scheme aims to collectively authenticate multiple nodes, but the result of authentication concerns each individual node. In contrast with the group-based solution proposed in [10], the scheme allows to authenticate nodes individually, while authentication messages are aggregated. The present Internet-Draft defines the new scheme based on aggregated authentications. It also extends the EAP authentication framework [3] with the ability to aggregate multiple re- authentications. 2. Terminology This document uses frequently the terms described in [3] and [4]. The following is a remainder of the used terms: Variables: ID_Server: Server identity as an opaque blob. ID_Group: The identity of the group of nodes. The format of the group ID (e.g., application-based identity, IP multicast address) depends on how the group is formed. oualha Expires April 21, 2014 [Page 3] Internet-Draft group-auth October 2013 PD_Payload: Data carried within the protected data payload. PD_Payload_Block: Block of possibly multiple PD_Payloads carried by a packet. RAND_Server: Random integer generated by the server (32 octets). Operations: ENC_(Y): Encryption of message Y with a symmetric key X, using a defined block cipher. SIGN X(Y): Signature of message Y with a key X, using a defined digital signature scheme. For the server, the signature is provided using an asymmetric key e.g., based on RSA, or using a symmetric group key e.g., based on TESLA [11]. For the node, the signature is a keyed message authentication code computed over Y with symmetric key X. SEC_X(Y): SEC is a function that provides integrity protection based on a chosen ciphersuite. The function SEC uses the algorithm defined by the selected ciphersuite and applies it to the message content Y with key X. In short, SEC_X(Y) = Y || SIGN_X(Y). xor{M}: Aggregation of messages M with an XOR operation. For example, xor{M, M', M"} = M xor M'xor M". Keys: PSK: Long-term key shared between the peer and the server. MK: A session-specific Master Key between a node and authentication server. MK is derived from PSK as defined in [4]. PK_p: Session key generated from the MK as defined in [4] and used during protocol exchange to encrypt protected data. PK_s: Session key generated from a group key (e.g., TESLA [11]) or securely shared using an asymmetric key (e.g., server RSA key). SK_p: Session key generated from the MK as defined in [4] and used during protocol exchange to demonstrate knowledge of the PSK. SK_s: Symmetric key derived from a group key (e.g., TESLA [11]) or asymmetric key (e.g., server RSA key). oualha Expires April 21, 2014 [Page 4] Internet-Draft group-auth October 2013 3. Approach overview In the proposed scheme, a group of nodes (sensors/actuators) are re- authenticating simultaneously to an authentication server. The nodes are authenticating to gain access to the network or to a remote resource or service. In the first case, they may connect through a gateway; while in the second case, their authentication messages may go through a service provider (as defined in [6]). The authentication server and the gateway/service provider can be co- located (see Figure 1 for a network example). N0 -+ +- GW1 --+- Auth. Server | | | N1 -+- IN0 ----+ IN1 | | | N2 --- IN2 ----+ | | N3 ------ GW2 --+ Figure 1 Example of a group of nodes composed of 4 leaf nodes (N0, ... N3)and 3 intermediate nodes (IN0, ..., IN2). Nodes connect to the authentication server through two gateways (GW1, GW2). 3.1. Assumptions The scheme relies on the following assumptions. 3.1.1. Network topology The scheme considers a network with a topology established according to a destination oriented directed acyclic graph. This type of topology allows to multicast a common message from a destination to a group of nodes of the network. It allows also to aggregate messages originated from a group of nodes toward a destination, called reverse multicast. The network topology can be implemented using an application-based multicast scheme or an IP-multicast routing scheme (e.g., RPL [5]). 3.1.2. Secure group communications Integrity-protected communications between the group of nodes is preferable, in order to minimize pollution attacks, in which oualha Expires April 21, 2014 [Page 5] Internet-Draft group-auth October 2013 attackers insert bogus information into aggregated messages to distort the aggregated result. The group of nodes is identified by a group ID (e.g., IP multicast address). 3.1.3. Aggregatable messages The response messages provided by nodes to a given challenge should be aggregatable, i.e. messages are aggregated into one message smaller than the sum of response messages. Only the aggregated result is sent to the authentication server, hence the original messages are not available for veri.cation. Still, the authentication server should be able to validate the aggregated result based on security credentials shared individually with each node. 3.2. Message exchanges The authentication approach relies on challenge-response messages, in which a common challenge is sent to all nodes in the group, and nodes' responses are aggregated back to the authentication server. The first two exchanged messages in a typical EAP authentication protocol, generally concern identity request and response. In the proposed approach, these messages can be omitted. The identity of the group is implicitly acknowledged by the server. Alternatively, the root node of the group may send the group ID to the authentication server, if requested by the server. The server initiates the message flow by sending a challenge message to the group of nodes identified by a group ID. The challenge may contain information authenticating the server, if mutual authentication is provided. In this case, the server uses either an asymmetric key (i.e., digital signature) or a symmetric group key (e.g., TESLA [11]). Intermediary nodes (e.g., routers) in the group does not immediately answer the challenge, instead they wait for their child nodes to answer the challenge. As the server challenge is received by the leaf nodes in the group, these latter send their responses to their parent nodes. The nodes use security credentials (e.g., pairwise secret keys) shared with the authentication server to generate the response to the challenge. They may also authenticate the origin of the received message, if mutual authentication is provided. oualha Expires April 21, 2014 [Page 6] Internet-Draft group-auth October 2013 Upon receiving the responses of all child nodes (or after a timeout), the intermediary nodes aggregate the received responses with their own response, and send the result to their parent nodes. Optionally, in case, some of the child nodes do not answer the challenge after a timeout because of unavailability (in sleeping mode) or failure, their IDs are added to a list that is sent along with the aggregated result. The aggregated result is finally sent to the authentication server. The server checks the received aggregated response. If validation succeeds/fails, a common success/failure message is sent to all nodes of the group. The list of nodes of the group that did not answer the challenge sent along with the aggregated result, is used by the server to correctly validate the aggregated result, and to send a success/failure message only to nodes that participate in the authentication process. The messages exchanges are summarized in Figure 2. End Node Interm. Node Server | | Challenge | | |<-------------------------------------| | Challenge | | |<------------------| | | Response | | |------------------>| | | | Aggregated Responses | | |------------------------------------->| | | Success/Failure | | |<-------------------------------------| | Success/Failure | | |<------------------| | Figure 2 Message exchanges overview 4. Extensions to EAP-GPSK As an example of realization, the EAP-GPSK [4] method is extended to support the proposed approach. Extensions concern mainly the EAP server part at the validation phase i.e., the server checks an aggregated result instead of one oualha Expires April 21, 2014 [Page 7] Internet-Draft group-auth October 2013 individual response. At the nodes' side, to be able to authenticate server messages, an asymmetric key (i.e., digital signature) or a group key (e.g., TESLA [11] group key) are used instead of pairwise keys, like it is defined in the original EAP-GPSK. Additionally, the first identity request/response messages in the protocol are not used. The cipher suite used in the exchange is already selected by the server. Nodes that join the group commit to the selected cipher suite. An extension independent of EAP is also needed at intermediary nodes to aggregate responses based on an XOR operation. We consider three entities involved in the exchange of EAP messages: the end node, the intermediary node (it belongs to the group), and the authentication server. A successful extended protocol exchange is presented in F .igure 3. End Node Interm. Node Server | M-1 | M-1 | |<---------------------------------------------------------| | | | | M-2 | M-3 | |--------------------------------------------------------->| | | | | M-4 | M-4 | |<---------------------------------------------------------| | | | | M-5 | M-6 | |--------------------------------------------------------->| | Success | Success | |<---------------------------------------------------------| Figure 3 Extended EAP-GPSK protocol The protocol consists of the following messages: M-1: ID_Server, ID_Group, RAND_Server M-2: SEC_SK_p(ID_i, ID_Server, RAND_Server, [ENC_PK_p(PD_Payload_Block)]) M-3: xor{M-2} oualha Expires April 21, 2014 [Page 8] Internet-Draft group-auth October 2013 M-4: SEC_SK_s(RAND_Server, ID_Server, ID_Group, [ENC_PK_s(PD_Payload_Block)]) M-5: SEC_SK_p([ENC_PK_p(PD_Payload_Block)]) M-6: xor{M-5} 5. Security Considerations The proposed scheme does not incur substantial changes to the original EAP authentication scheme. Authentication is provided by demonstrating the knowledge of a secret key: the server uses an asymmetric key or a group key to authenticate, while nodes rely on their PSK shared with the server. As demonstrated in [9], the aggregated result cannot be produced without the knowledge of the secret keys. So message aggregation does not reduce the security of the protocol. The protocol can be still subject to disruption attacks (i.e., denial of service attacks) where, in particular, attackers inject false information into the aggregated result. The obtained result that is sent to the server is not validated. This type of attacks can be limited by securing communications inside the group, such that outsider attackers cannot inject bogus information. Insider pollution attacks are possible, though. 6. IANA Considerations This memo includes no request to IANA. 7. Acknowledgements This work is part of the European project TWISNet (Trustworthy Wireless Industrial Sensor Network, FP7-ICT-STREP, contract No. 258280) and is totally funded by the European Union. 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. oualha Expires April 21, 2014 [Page 9] Internet-Draft group-auth October 2013 [3] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [4] T. Clancy and H. Tschofenig, "Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", RFC 5433, February 2009. [5] T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. [6] S. Winter and J. Salowey, "Update to the EAP Applicability Statement for ABFAB", Internet-Draft draft-ietf-abfab- eapapplicability-06, August 19, 2013. 8.2. Informative References [7] Jonathan Katz and Andrew Y. Lindell. Aggregate message authentication codes. In Proceedings of the 2008 The Cryptopgraphers' Track at the RSA conference on Topics in cryptology (CT-RSA'08), Tal Malkin (Ed.). Springer-Verlag, Berlin, Heidelberg, 155-169. [8] Yaping Li, Hongyi Yao, Minghua Chen, Sidharth Jaggi, and Alon Rosen. 2010. RIPPLE authentication for network coding. In Proceedings of the 29th conference on Information communications (INFOCOM'10). IEEE Press, Piscataway, NJ, USA, 2258-2266. [9] Jonathan Katz and Andrew Y. Lindell. Aggregate message authentication codes. In Proceedings of the 2008 The Cryptopgraphers' Track at the RSA conference on Topics in cryptology (CT-RSA'08), Tal Malkin (Ed.). Springer-Verlag, Berlin, Heidelberg, 155-169. [10] Group-based authentication method of machine type communication (MTC) nodes. CN 102088668 A (UNIV XIDIAN), 08- Jun-2011. [11] A. Perrig, R. Canetti, J. D. Tygar, and D. Song, "The tesla broadcast authentication protocol," RSA CryptoBytes, Volume 5, No. 2 Summer/Fall 2002. oualha Expires April 21, 2014 [Page 10] Internet-Draft group-auth October 2013 Authors' Addresses Nouha Oualha CEA LIST CEA Saclay, 91191 Gif sur Yvette, France Phone: +33 169084625 Email: Nouha.oualha@cea.fr Alexis Olivereau CEA LIST CEA Saclay, 91191 Gif sur Yvette, France Phone: +33 169089233 Email: alexis.olivereau@cea.fr oualha Expires April 21, 2014 [Page 11]