Internet DRAFT - draft-oualha-group-auth
draft-oualha-group-auth
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]
