1. M2M Service Layer – DM Server Security Group Name: OMA-BBF-oneM2M Adhoc Source: Timothy Carey, timothy.carey@alcatel-lucent.com Meeting Date: 2014-01-27 Agenda Item: Adhoc

2. Collaboration Sessions oneM2M Deployment Scenarios - Completed Translation Approach for Requests and Notifications – Wed, Jan 8 th 13:00 UTC Session Management between the Service Layer and DM Servers – Wed Jan 15 th 13:00 UTC Security establishment between the Service Layer and DM Servers – Mon Jan 27 th 13:00 UTC Extra: Mon, Mar 24 th 13:00 UTC 2

3. Agenda 1.M2M Service Session/Link Security 2.Request Access Management 3

4. oneM2M Functional Architecture 4

5. Management Architecture 5

6. Disclaimer Warning: The oneM2M Security Functions are still a work in progress and are volatile at this stage of development. Member organizations should not use these requirements in this contribution until they have been aligned with a completed draft of the TS-0003. 6

7. What has to be Secured? The “ms interface” – M2M Service Session/Link Security The command and notification (request) where identification and authorization is based on the oneM2M originator of the request. 7

8. M2M Service Session/Link Security When we look at the session, link security requirements of the “ms interface” we can refer to the BBF TR-131 for this: – The NBI MUST provide support for standards-based security. This includes authentication of both Server and Client, authorization, link security so that it can be verified that the content has been sent from the appropriate sender and was not modified while in transit. Information should also be confidential (encryption). 8

9. M2M Service Session/Link Security In oneM2M, requirements exist that are applicable to link/session security: – SER-001: The M2M System shall incorporate protection against threats to its availability such as Denial of Service attacks. – SER-002: The M2M System shall be able to ensure the confidentiality of data. – SER-003: The M2M System shall be able to ensure the integrity of data. – SER-009: The M2M System shall be able to support mutual authentication for interaction with Underlying Networks, M2M Services and M2M Application Services. – SER-012: The M2M System shall be able to support countermeasures against Impersonation attacks and Replay attacks. – SER-016: The M2M System shall be able to support non repudiation within the M2M service layer and in its authorized interactions with the network and application layers. – SER-024: The M2M System shall enable M2M Applications to use different and segregated security environments. 9

10. M2M Service Session/Link Security Requirements The DM Server shall be able to ensure the confidentiality of data. The DM Server shall be able to ensure the integrity of data. The DM Server shall be able to support mutual authentication for interaction with the M2M Service Layer. The DM Server shall be able to support countermeasures against Impersonation attacks and Replay attacks. The DM Server shall be able to support non repudiation with authorized interactions with the M2M Service Layer. This last requirement requires additional discussion and clarification: The DM Server shall be capable of using different and segregated security environments. 10

11. Request Access Management Requests between Application Entities and CSEs are authenticated and authorized by Security CSF within the CSE using 3 components – Access Control – Authorization – Authentication (not shown; TBD) While these components currently only consider Application and CSE interactions – the Security Functions are expected to be extended across the Underlying Network Service Entity (DM Server). 11

12. Extending Access Management to the DM Server Once a request has performed an Access Decision by the M2M Service Layer to allow the request, the M2M Service Layer must select the appropriate DM Server along with elements the DM Server would need to implement access management within the DM Server: – Identity of the subject (oneM2M Originator) of the request: This is needed in scenarios where the original issuer of the request is needed to be known – this could be done by correlating principals (e.g., Roles, Accounts) used by the M2M Service Layer and DM Server. 12

13. Access Management Requirements The DM Server shall be capable of providing a mechanism for the M2M Service Layer to discover the Access Management elements used to authorize and authenticate access to resources controlled by the DM Server. The M2M Service Layer shall be capable of correlating Access Management elements provided by the DM Server to Access Management elements used by the M2M Service Layer. The M2M Service Layer shall be capable of providing secured storage of Access Management elements within the M2M Service Layer. 13

14. Terms Access Decision: Authorization reached when an entity’s Privileges, as well as other Access Control Attributes, are evaluated. Privilege: Qualification given to an entity that allows a specific operation (e.g. Read/Update) on a specific resource (e.g.: an entry in ACL specifies a privilege, not an Access Decision). – Note: In addition to being granted a Privilege, the entity must also satisfy any conditions of the Access Control Attributes. Access Control Attributes: Set of parameters of the originator, target resource, and environment against which there could be rules evaluated to control access. – Note: An example of Access Control Attributes of Originator is a role. Examples of Access Control Attributes of Environment are time, day and IP address. An example of Access Control Attributes of targeted resource is creation time. Alignment of the RBAC model Terminology with the existing oneM2M Terminology – (RBAC) User => (oneM2M) Originator – (RBAC) operations, objects => oneM2M (Hosting CSE resources) – Support for ACL and ABAC (Role as an attribute of ABAC) 14