IEEE C802.16ppc-10/0052
Project
Title
Date
Submitted
IEEE 802.16 Broadband Wireless Access Working Group < http://ieee802.org/16 >
Device Authentication for 802.16p Machine to Machine (M2M) Devices
2010-08-25
Source(s) Eldad Zeira
InterDigital Communications LLC
Re: CfC for M2M SRD
Abstract
Purpose
Notice
Release
Patent
Policy
E-mail: eldad.zeira@interdigital.com
This contribution discusses and proposes device authentication requirements for M2M
To be discussed and accepted by 802.16
This document does not represent the agreed views of the IEEE 802.16 Working Group or any of its subgroups . It represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for discussion. It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material contained herein.
The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.16.
The contributor is familiar with the IEEE-SA Patent Policy and Procedures:
< http://standards.ieee.org/guides/bylaws/sect6-7.html#6 > and
< http://standards.ieee.org/guides/opman/sect6.html#6.3
>.
Further information is located at < http://standards.ieee.org/board/pat/pat-material.html
> and
< http://standards.ieee.org/board/pat >.
1

IEEE C802.16ppc-10/0052
Eldad Zeira
InterDigital Communications LLC
The approved 802.16p (a.k.a. M2M) PAR includes a requirement to support “… improved device authentication”.
Improved device authentication could, depending on how it is implemented, protect the network against rogue devices (e.g. with tampered software). The level of protection could vary and can include the disablement of network entry for those rogue devices and the prevention of denial of service attacks by repeated entry attempts.
Many, but not all, M2M applications require a high level of security. It is important therefore to develop improved authentication in such a way that the burden of complexity falls only on those applications that require it.
Some security related requirements must however be mandatory. Not doing so will allow rogue devices to escape their security requirements by signaling the lack of capability to support M2M requirements.
Therefore we propose a tiered approach to device authentication. The decision of which elements to support is left to implementation and deployment.
We define therefore a category of devices that support the enhanced authentication. Devices in this category are
M2M-secure. The issue whether all M2M devices are M2M-secure devices is out of scope for the standard.
M2M-secure devices shall be able to report this capability to the network. By default, devices that do not report this capability are not M2M-secure.
To keep deployment flexible, we assume that the standard does not prohibit M2M-secure and non M2M-secure from being deployed in the same cell and carrier frequency (although there may be security or other benefits in doing so).
We assume that M2M-secure devices have some internal mechanism that can check the validity of the device.
We assume that there is some information contents (e.g. a token) that is required for authentication and that is only released if the device is deemed valid. The nature of this mechanism is out of scope for the standard and there is no formal requirement regarding it.
M2M-secure devices shall not attempt to perform network entry if the information for authentication is not available (as it means that device validation has failed). This can eliminate DOS attacks on the network (by repeated entry attempts). The implementation of this requirement is not specified. At its simplest it is a decision at the MAC. In other applications, dedicated HW could prevent physical transmission.
2

IEEE C802.16ppc-10/0052
Once the authentication information has been sent, the authentication process is handled as per 802.16m.
6.4.1
The 802.16p amendment should support the M2M device authentication . Support of M2M device authentication
802.16p shall recognize a category of M2M-Secure devices and the MS and BS shall be able to exchange this capability.
M2M-secure devices shall not attempt to perform network entry or reentry if the access to the required content for the authentication request message is not available.
M2M-secure devices shall attest to a successful device authentication by transmission of a device authentication certificate with the authentication request and response.
Comment: it is assumed that the rest of the authentication process is handled as per 802.16m
6.4.2
The 802.16p amendment should support verification and validation of the exchanged data for
M2M services.
6.4.3
The protocol should support efficient security for small burst transmissions.
3