forked from mscurtescu/secevent
-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathdraft-scurtescu-secevent-risc-use-cases.xml
239 lines (172 loc) · 8.2 KB
/
draft-scurtescu-secevent-risc-use-cases.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.3 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc docName="draft-scurtescu-secevent-risc-use-cases-00" category="info">
<front>
<title>Security Events RISC Use Cases</title>
<author initials="M." surname="Scurtescu" fullname="Marius Scurtescu">
<organization>Google</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date year="2017" month="June" day="29"/>
<area>Security</area>
<workgroup>secevent</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document describes the RISC use cases for security events and helps with
defining the requirements for token format and event distribution.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
</section>
<section anchor="defs" title="Definitions">
<t><list style="symbols">
<t>Transmitter - the entity that sends security events</t>
<t>Receiver - the entity that receives security events</t>
<t>IdP - Identity Provider, in most cases but not always this is the transmitter</t>
<t>RP - Relying Party, in most cases but not always this is the receiver</t>
<t>RISC - Risk and Incident Sharing and Coordination, see
http://openid.net/wg/risc/</t>
<t>SCIM - System for Cross-domain Identity Management, see
http://www.simplecloud.info/</t>
</list></t>
</section>
<section anchor="use-cases" title="Use Cases">
<section anchor="explicit-idp-to-rp" title="Explicit IdP to RP">
<t><list style="symbols">
<t>Transmitter: IdP</t>
<t>Receiver: RP</t>
</list></t>
<t>Simplest use case, IdPs send security events to relevant RPs.</t>
<t>RP can make control plane calls to the IdP and can authenticate with access
tokens issued by IdP.</t>
</section>
<section anchor="explicit-rp-to-idp" title="Explicit RP to IdP">
<t><list style="symbols">
<t>Transmitter: RP</t>
<t>Receiver: IdP</t>
</list></t>
<t>The RP can also send RISC events back to IdP. We want to make it very easy for
the RP to do that, no complicated registration steps and crypto of possible.</t>
<t>IdP can document well-known endpoint for data plane (where it receives events).
RP can use access token when sending events on data plane and maybe does not
need to sign SETs.</t>
<t>If RP is sophisticated and is exposing its own control plane then during RP
stream registration with IdP (either manual or programmatic) it can advertise
its own issuer and that issuer through .well-known can specify full transmitter
functionality of RP.</t>
</section>
<section anchor="implicit-idp-to-rp" title="Implicit IdP to RP">
<t><list style="symbols">
<t>Transmitter: implicit IdP</t>
<t>Receiver: implicit RP</t>
</list></t>
<t>Example: Google and Amazon, Amazon account can be backed by gmail address.
Amazon acts as implicit RP to Google in this case.</t>
<t>Google and Amazon need legal agreement, When Amazon account is created or
updated with gmail address Amazon makes REST call to Google to enroll this new
email address for RISC events. If enrollment succeeds then RISC events will flow
bidirectionally (see next section, for simplicity only unidirectional is
considered in this section).</t>
<t>Assumption: Amazon/RP is registered with Google/IdP as an OAuth 2 client and can
use access tokens for control plane.</t>
<t>Open question: what are the implications of unverified email addresses?</t>
<t>Open question: discovery of hosted domains, how does Google know that
example.com is managed by Oracle and that subject enrollment should be sent to
them?</t>
</section>
<section anchor="implicit-rp-to-idp" title="Implicit RP to IdP">
<t><list style="symbols">
<t>Transmitter: implicit RP</t>
<t>Receiver: implicit IdP</t>
</list></t>
<t>No enrollent call is strictly necessary. The RP can start sending events to IdP
as new identifiers show up.</t>
</section>
<section anchor="pseudo-implicit" title="Pseudo-implicit">
<t>Common email address or phone number used by two different RPs.</t>
<t>Example: Amazon and PayPal, both Amazon and PayPal each have an account with the
same gmail address.</t>
<t>Mutual discovery by exchanging email address hashes.</t>
<t>Open question: legal and privacy implications</t>
</section>
<section anchor="idaas" title="Identity as a Service">
<t>Example: Google Firebear, IdaaS manages large number of RPs and implements RP
functionality on their behalf.</t>
<t>IdaaS should be able to manage SET distribution configuration for its RPs with a
given IdP using the credentials already established between the RP and the IdP.
Control plane operation to create/update stream allows that.</t>
<t>Assumption: IdaaS can impersonate RP at IdP (can obtain access token on behalf
of RP)</t>
</section>
<section anchor="secaas" title="Security as a Service">
<t>Similar to IdaaS described in previous estion, but the service provider has its
own set of credentials different from the credentials and RP is using. The SP
cannot impersonate the RP at IdP. The IdP must define delegation rules and allow
the SP to make requests on behalf of the RP.</t>
</section>
<section anchor="on-premise-rp" title="On-Premise RP">
<t>The RP (receiver) is behind a firewall and cannot be reached through HTTP. The
only way to deliver events is if the RP periodically polls an endpoint provided
by the transmitter.</t>
</section>
</section>
</middle>
<back>
</back>
<!-- ##markdown-source:
H4sIACl+VVkAA51XwW7kuBG98ysIzMUOrO7JHBKkgWAz8DqJD8403A72sFgE
bIktMaZILUlZox3sv+dVUWpLbSPIxocZtUQWq169elUsikIkk6zeyYMu+2DS
KO9etEtRPt4fbuU/o5a3KuooKl861WJdFdQpFRGLk8a/RdSlph1FMLEs+qiL
kjYUHz+KSiVs+PTx938sPv6h+PQnUeJF7cO4k8advBAqaPV6shh8eK6D77ud
nK2KZz3idbWT9y7p4HQqvicHhIhJuepfynqHM0Z42Jmd/DH58kZGH1LQp4in
saWHn3BUnxofdkIWQuLPuLiTDxt5mOPgtznCBxVMHy8++VArZ35RyXi3k3/z
vraaP+hWGbuT7RmRv9T8cVP6lheIoiikOsYUVAm/nxoTJdDsW4QnK+wI5qij
TI3OmANCyRDKkw8ERE6LzmlB0LLRtotyMKkRlT4ZZ1zN24P+uTdBt7yQNif/
rB09tSrxTjYiKwNnzLGnWDZCsIOtqSpEJABz8FVf0jf57YOhn7+KPy/+hPie
D6UVEUvgQlytEOJ38ikoF1uTkDNZsHM4mMJIDVyJ2lXxMjTsekTWzcu7W0L+
9N6u+2qPDffVtHwf/IupdLhBkmXrY5rQRLzSeeBgBzUS3siDybinV2/JCzL3
qO1IuO5VSONvMDX5yXYom7Bk4jODf+9KQ07KQwOGwTa9vPVgt3HMK/BVa9Gk
1O22W99pZ6oNGL8d6i0V1xY2D7f3D7B5GGPSLef4NvgYi8qDhu4VhAflVM1M
WBkdhmETTdtZXVrfVxsqwy0YcK5z5PNcwoukCnH3tbOmNInRTp5A+vZBTy8L
U3VF8kXofiUyXfxd8GFHJhbJ3sGWEAf2CgjP9L+hZZGp8qYIcH7QVr8ogPm4
j+Aw3CkVcqSesdsTaa3srHJky1reQdkh5wl1WkuKQGiRKHExSVWWOkbBVUMJ
jb2u5HGkXVQmZwgeGQGytYAgMAIA4n+C4HGNACECZdByikPZ6HPoTKIp7KMq
n6eTN/IHOE3x4zdHDb9gChCpOBIxRMrm8L3yXEM34CzAaclhxFwBw5qUgLkn
Qaguy0sZxg67/El2oJY5QsuEFBQuuXaWrkFbWzw7PzgUatV5SAUTEqqvJuyv
hkYHdu1cvjmU682cMUp3xn1SK2xxHDpVyBQ43FtYJR9bNR41fIFFFKJwGuHA
52hqJw93T5E9PlH8qMvoO1RomqKm7XiJxPlIZxg6AEGsaUPckFXPdYpkASat
2jVizBmC5UrjCarVKtcri1Yhu+DroFrIrimvKX5OaoUEJRO1mI9kigX2iEVu
+p0aNMG6kZsFxGQgdro0J2S3t3alWafesWArS0XiKW4i7H37Ts2a9v+qWbOw
taLu+QNV8d1XRWU8N0iO7HOrfiFty/9Tsn3vMiJIIXE6V1lNjRQgVQFk2Ijz
cmp6cXkMhTLZh+Sx+JJgUMrfHCuZGVbXyIuqg54k8QfK7oVDZAZJJoqgevqu
4kdO8sq1eR9VHcaku8MTa8zCKzxpByrZ7JzTg9ArC1Qmi8LeSFA17+DKij0K
Qlcxk3CpAIOB0ZP1gziaCq1+yrod5RVUHid9peZa5mbC48OMG2jhsKx3y32I
WYD2kdolYp3RnCxcE6KfQcm2y1NPDnybiyqXAu9jjHLsW1ZY0hH55TMEVn6S
pTUU1CS74rLgMxqr4qNzv6D9yZ97dAQ+eqDywLjIKm4mCeMBBGzvHZhoTgau
rHDW8bu3ljD8lJ6VEjsb9HTsyt0T82LjhywqUyap9rg0hc7MpqmOom+5vzJv
v2CumziXh5v++G8AuEpo43tbEd2jZskmcW6/W5bosqecS/S39ZRlJb5bodxl
/jGTU3MRWssKiXmwTOCH05QZFcaNXLQjzNohXYpydlcoJrjkyYZyECKFO8i+
IwnaR91XCGF24duHbv3mTWRC3Pq2RX2tS4ZEtcGsL13fHqGRoBGjnwb0N3M6
gYjnYeCsQnOFIzV7Ne6VvZFHD1K+eY+uWTayUS+Ux7MiMK+RKRFxL7jUJyke
+kRy/0oouKO/lo1yNcO08r9RsdHxHWZP2gRXumBeVDmu6E0UmWc6KitclsKL
KTWxpFIqvkcMBvFSif+Kqj9qFWisUuowEThKq0J9BpU7Rx4CeBzLNwnQ6aLB
kE5oE0DoRtlTng7I6CvP1THrYD6GWvLq1kH1fjJ1P3VSUgDDJ8VpEhM1uOu4
Hvo4328gz4wFpiNMSNDqCoCDm0drAC6dmwatnZwmn1yROo9vt6vujuF6Oho+
ZtXfZsWXU6dHYfghckVfymCOleoCIIHvgCXlA3OnvaJP/phoIF+NNt5NiAkG
+hrJPd+6L5ILCf5v2cW0bJC5XIPkzXyPZBHvgn4xHlfYzLEbvq8QEnGy301X
JGIlAS9owog6EQGWIL8W1ilA997kgOZTbgacoywZhz2u+Y5uR0t05pSkPLw+
TbN420e6A+M6iWFOUylwUkKPqwCb5zTwKHvYn0dduucitPgKKDmejyDR+eKK
Pa7BmLTyyONd0eXfb6ed89h9Nd/crikgmDV0vDyhbgZSyal/UWBHcgGCQTPn
NKr9/ekphyW4zeJayIO3tnydnRSTbomznxLYGF+Zkrt35y3j+TpJTymqBGnc
+oq6kfnKTqOTEP8BrEZsu8MRAAA=
-->
</rfc>