1. Comments on Procedures for RBAC (doc#0056) Group Name: WG4(SEC), WG2(ARC) and WG5(MAS) Source: Suresh Nair, Alcatel-Lucent, suresh.p.nair@alcatel-lucent.com Meeting Date: 2013-11-26 Agenda Item: RBAC

2. ALU Comments- Scheme Frame work using OAuth looks OK. It releases the burden of Application Server owners having to maintain subscription accounts with different roles/service eligibility. ‘Principals’ wanting to access the resources gets the credentials (Tokens) by offline means. Access Request is made using these Tokens to the Application Server. Application Server, looks at the Token+Access rights and makes a permission based on the Token. Application Server keeps the token for their assigned validity, if for one time use, Token becomes invalid after the one time usage. Roles/Access Rights are based on the token. © 2013 oneM2M Partners 2

3. ALU Comments- Security issues 1 App Server allocates the Tokens to the App User (based on App User ID – AUID) according to a subscription to an Application. The Tokens are distributed in bulk over an alternate distribution media, e.g. OMA DM. The User Device M2M ID is opaque to the App Server. The Token is mapped to the AUID.

4. ALU Comments- Security issues 2 Once the Tokens are distributed, the User App picks an available Token from the unused pool, and sends it via M2M Server to the App Server. – The M2M Server authenticates the User Device using M2M ID and credentials. – The AUID and Token are Opaque to the M2M Server.

5. ALU Comments- Security issues 3 – Once the M2M credentials are authenticated, the AUID and Token are sent to the App Server for Authorization. – The App Server checks if the Token is not yet used, and is associated with the AUID. If so, it authorized the use of Resource.

6. ALU Comments- Security threats 1.Security Threat: An Attacker may block or disturb the communications between OneM2M and App Server when victim requests the Resource, and then masquerade as a victim AUID and present an intercepted Token. The resource will be authorized for an Attacker instead of Victim. 2.Security Threat: An Attacker may masquerade as a Victim and present Tokens that has been intercepted, trying to get authorization for Resource.

7. ALU Comments- Security threats 3. Security Threat: An Attacker may present used-up or invalid Tokens for a Victim’s AUID, overloading the App Server, causing distribution of new Tokens to the Victim, loading the Token Distribution system i.e. OMA DM, making current Victim’s Tokens invalid, and thus keeping the Victim unable to use the Resource.

8. Security Requirements The App Server needs to maintain mapping of the AUID of the User with the M2M ID of the User’s Device, so when AUID with Token is presented to the App Server, it has to be presented with the AUTHENTICATED OneM2M ID of the Device that made an Access. The Token Distribution must be secure, protected from eavesdropping and manipulation, i.e. Confidentiality and Integrity protected. If IP/TCP/HTTP is used, the HTTPS is the right security tool for this distribution. If IP/UDP is used, DTLS is the right security tool.