SEC-2015-0558R01-use-case-requirements-end-to-end-authentication-using-delegation
Change Request
CHANGE REQUEST
Meeting:*
SEC 18
Source:*
Vinod Choyi, Interdigital, vinod.choyi@interdigital.com
Date:*
2015-07-12
Contact:*
Same as above
Reason for Change/s:*
Use case and requirements for providing End-to-End Message
Authentication using Delegation
R01 addresses comments during SEC session
CR against: Release*
oneM2M R2
CR against: WI*
X Active WI-0016
MNT Maintenace / < Work Item number(optional)>
STE Small Technical Enhancements / < Work Item number
(optional)>
Only ONE of the above shall be ticked
CR against: TS/TR*
TR-0012 oneM2M End-to-End Security and Group Authentication
Clauses/Sub Clauses*
Type of change: *
Editorial change
Bug Fix or Correction
Change to existing feature or functionality
X New feature or functionality
Only ONE of the above shall be ticked
Post Freeze checking:*
This CR contains only essential changes and corrections? YES
NO X
NO X if YES, please indicate the
document number of the original CR:
<Document Number)<CR Number of the original CR to the current
Release>
This CR is a mirror CR? YES
Template Version:23 February 2015 (Dot not modify)
2
3
oneM2M Notice
4
5
6
7
8
The document to which this cover statement is attached is submitted to oneM2M. Participation in, or attendance at, any
activity of oneM2M, constitutes acceptance of and agreement to be bound by terms of the Working Procedures and the
Partnership Agreement, including the Intellectual Property Rights (IPR) Principles Governing oneM2M Work found in
Annex 1 of the Partnership Agreement.
© 2016 oneM2M Partners
Page 1 (of 5)
SEC-2015-0558R01-use-case-requirements-end-to-end-authentication-using-delegation
Change Request
9
GUIDELINES for Change Requests:
10
Provide an informative introduction containing the problem(s) being solved, and a summary list of proposals.
11
Each CR should contain changes related to only one particular issue/problem.
12
13
In case of a correction, and the change apply to previous releases, a separated “mirror CR” should be posted at the same
time of this CR
14
15
16
Follow the principle of completeness, where all changes related to the issue or problem within a deliverable are
simultaneously proposed to be made E.g. A change impacting 5 tables should not only include a proposal to change
only 3 tables. Includes any changes to references, definitions, and acronyms in the same deliverable.
17
Follow the drafting rules.
18
All pictures must be editable.
19
Check spelling and grammar to the extent practicable.
20
Use Change bars for modifications.
21
22
23
The change should include the current and surrounding clauses to clearly show where a change is located and to provide
technical context of the proposed change. Additions of complete sections need not show surrounding clauses as long as
the proposed section number clearly shows where the new section is proposed to be located.
24
25
Multiple changes in a single CR shall be clearly separated by horizontal lines with embedded text such as, start of
change 1, end of change 1, start of new clause, end of new clause.
26
27
When subsequent changes are made to content of a CR, then the accepted version should not show changes over
changes. The accepted version of the CR should only show changes relative to the baseline approved text.
28
Introduction
29
30
31
32
33
In an oneM2M system, entities may require service layer messaging in order to communicate with another entity that
may be multiple hops away. Messages may traverse multiple intermediate entities before the message reaches the final
destination (receiver). An entity may require a high-level of assurance that a message originated from a particular end
entity. A constrained M2M entity would like to delegate certain security functions (e.g. End-to-End Message
Authentication) to another trusted entity that may have much more computing power/memory/battery resources.
34
35
-----------------------Start of change 1-------------------------------------------
36
38
5.6 Use case of End-to-End Message Authentication using
Delegated Means
39
5.6.1 Description
40
41
42
43
44
In an oneM2M system, entities may require service layer messaging in order to communicate with another entity that
may be multiple hops away. Messages may traverse multiple intermediate entities before the message reaches the final
destination (receiver). An entity may require a high-level of assurance that a message originated from a particular end
entity. A constrained M2M entity would like to delegate certain security functions (e.g. End-to-End Message
Authentication) to another trusted entity that may have much more computing power/memory/battery resources.
37
© 2016 oneM2M Partners
Page 2 (of 5)
SEC-2015-0558R01-use-case-requirements-end-to-end-authentication-using-delegation
Change Request
45
5.6.2 Actors
46
47
The entities involved in the use case are shown in Figure 5.6.2-1 and described as follows:
48
49
50
M2M Application: It represents an application that uses sensor data to perform certain application-specific operations.
The M2M Application is multiple hops away from a sensor and may be connected to the sensor by entities that may
belong to different administrative domains.
51
52
M2M Server: It represents an infrastructure entity that is responsible for enabling an M2M application to obtain
services provided by the M2M service provider.
53
54
55
M2M Gateway: It represents a gateway that is responsible for processing and / or forwarding messages that are sent
from an M2M Application and from M2M Devices. The M2M Gateway may function as a Delegated End-to-End
Message Authentication Agent on behalf of the M2M Device.
56
57
M2M Device: It represents a sensor application or a sensor device that is responsible for measuring sensor data and
communicating the data to an application. The M2M Device is assumed to be a very constrained device.
58
59
60
Trusted Third-Party (TTP): It represents an entity that can broker trust relationships between entities that may belong
within the same administrative domain or outside. The TTP may also facilitate in providing credential registration as
well as credential requisition services.
61
Trusted
Third-Party
(TTP)
M2M
Device
M2M
Gateway
M2M
Server
M2M
Application
Delegated E2E
Message
Authentication Agent
62
63
Figure 5.6.2-1: Entities involved in oneM2M messaging
64
5.6.3 Pre-Conditions
65
66
M2M Device registers with the M2M Gateway in order that an M2M Application may be able to access the sensor data
provided by M2M Device.
67
68
69
Either by policies determined by M2M service provider or by explicit signalling, the M2M Gateway is assigned as the
delegated end-to-end message authentication agent on behalf of the M2M Device
70
M2M Gateway requests and or registers end-to-end message authentication credentials with a TTP.
71
72
Any message originating from the M2M Gateway is integrity protected by the M2M Gateway using end-to-end
message authentication credentials on behalf of the M2M Device.
73
74
Any message destined to the M2M Gateway or M2M Device is verified to check for authenticity / integrity by the M2M
Gateway on behalf of the M2M Device
75
© 2016 oneM2M Partners
Page 3 (of 5)
SEC-2015-0558R01-use-case-requirements-end-to-end-authentication-using-delegation
Change Request
76
5.6.4 Normal Flow
77
Procedure for oneM2M messaging:
78
1. An M2M Device registers its sensor resource with an M2M Gateway
79
80
81
82
83
2. The M2M Gateway based on policies and security requirements determines that the messages originating from it
may have to be integrity protected using End-to-End Message Authentication mechanisms using cryptographic
mechanisms and therefore may generate appropriate end-to-end credentials, identifiable by a credential identifier
and registers the credentials with a TTP. Alternatively, the M2M Gateway may request for appropriate credentials
from the TTP, which is then used for protecting the integrity / authenticity of messages originating from it.
84
85
3. An M2M Application would like to subscribe to sensor resource that is provided by an M2M Device. In order to
obtain the data, the M2M Application sends a request message to the M2M Gateway via the M2M Server.
86
4. The M2M Server receives the message and forwards the message to the appropriate M2M Gateway.
87
88
5. The M2M Gateway on receiving the message from the M2M Server verifies if the M2M Application is authorized to
send the request message.
89
90
6. Upon verification, the M2M Gateway sends an integrity protected response message to the M2M Application using
the end-to-end message authentication credentials that was registered with a TTP via the M2M Server.
91
7. The M2M Server forwards the integrity protected response message to the M2M Application.
92
93
94
95
8. Based on the type of credentials (symmetric or assymetric) that has been used for integrity protection of the
messagte the M2M Application may or may not be able to verify the integrity / authenticity of the message. If the
M2M Application does not have the appropriate credentials, identified by the credential identifier, it requests for
the credentials with the TTP.
96
97
9. The TTP checks for the authorization of the M2M Application, if authorized, the TTP provisions the M2M
Applciation with the appropriate credentials using the credential identifier.
98
10. The M2M Application is able to verify the integrity / authenticity of the message and processes it.
99
100
101
It must be noted that the mechanisms described above may be used by the M2M Gateway to verify the integrity /
authenticity of the request message at Step 5, originating from a M2M Application using similar mechanisms
102
103
104
Message authentication may be performed by verifying a message authentication code / authentication tag that is
appended to the original message if using symmetric credentials or by verifying the Digital Signature associated with
the message if using asymmetric credentials.
105
106
5.6.5 Potential Requirements
107
108
1 M2M system shall support an entity to delegate security functions (e.g. message authentication / integrity
protection) to a trust-worthy entity on behalf of the originator entity.
109
2
110
-----------------------End of change 1 ---------------------------------------------
111
112
113
CHECK LIST
114
115
 Does this change request include an informative introduction containing the problem(s) being solved, and a
summary list of proposals.?
116
 Does this CR contain changes related to only one particular issue/problem?
117
 Have any mirror crs been posted?
© 2016 oneM2M Partners
Page 4 (of 5)
SEC-2015-0558R01-use-case-requirements-end-to-end-authentication-using-delegation
Change Request
118
119
120
 Does this change request make all the changes necessary to address the issue or problem? E.g. A change
impacting 5 tables should not only include a proposal to change only 3 tables. Includes any changes to
references, definitions, and acronyms in the same deliverable?
121
 Does this change request follow the drafting rules?
122
 Are all pictures editable?
123
 Have you checked the spelling and grammar?
124
 Have you used change bars for all modifications?
125
126
127
 Does the change include the current and surrounding clauses to clearly show where a change is located and to
provide technical context of the proposed change? (Additions of complete sections need not show surrounding
clauses as long as the proposed section number clearly shows where the new section is proposed to be located.)
128
129
 Are multiple changes in this CR clearly separated by horizontal lines with embedded text such as, start of change
1, end of change 1, start of new clause, end of new clause.?
130
© 2016 oneM2M Partners
Page 5 (of 5)