idnits 2.17.1 draft-scurtescu-secevent-risc-use-cases-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2017) is 2492 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 secevent M. Scurtescu 3 Internet-Draft Google 4 Intended status: Informational June 29, 2017 5 Expires: December 31, 2017 7 Security Events RISC Use Cases 8 draft-scurtescu-secevent-risc-use-cases-00 10 Abstract 12 This document describes the RISC use cases for security events and 13 helps with defining the requirements for token format and event 14 distribution. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 31, 2017. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3.1. Explicit IdP to RP . . . . . . . . . . . . . . . . . . . 2 54 3.2. Explicit RP to IdP . . . . . . . . . . . . . . . . . . . 3 55 3.3. Implicit IdP to RP . . . . . . . . . . . . . . . . . . . 3 56 3.4. Implicit RP to IdP . . . . . . . . . . . . . . . . . . . 4 57 3.5. Pseudo-implicit . . . . . . . . . . . . . . . . . . . . . 4 58 3.6. Identity as a Service . . . . . . . . . . . . . . . . . . 4 59 3.7. Security as a Service . . . . . . . . . . . . . . . . . . 4 60 3.8. On-Premise RP . . . . . . . . . . . . . . . . . . . . . . 4 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 2. Definitions 67 o Transmitter - the entity that sends security events 69 o Receiver - the entity that receives security events 71 o IdP - Identity Provider, in most cases but not always this is the 72 transmitter 74 o RP - Relying Party, in most cases but not always this is the 75 receiver 77 o RISC - Risk and Incident Sharing and Coordination, see 78 http://openid.net/wg/risc/ 80 o SCIM - System for Cross-domain Identity Management, see 81 http://www.simplecloud.info/ 83 3. Use Cases 85 3.1. Explicit IdP to RP 87 o Transmitter: IdP 89 o Receiver: RP 91 Simplest use case, IdPs send security events to relevant RPs. 93 RP can make control plane calls to the IdP and can authenticate with 94 access tokens issued by IdP. 96 3.2. Explicit RP to IdP 98 o Transmitter: RP 100 o Receiver: IdP 102 The RP can also send RISC events back to IdP. We want to make it 103 very easy for the RP to do that, no complicated registration steps 104 and crypto of possible. 106 IdP can document well-known endpoint for data plane (where it 107 receives events). RP can use access token when sending events on 108 data plane and maybe does not need to sign SETs. 110 If RP is sophisticated and is exposing its own control plane then 111 during RP stream registration with IdP (either manual or 112 programmatic) it can advertise its own issuer and that issuer through 113 .well-known can specify full transmitter functionality of RP. 115 3.3. Implicit IdP to RP 117 o Transmitter: implicit IdP 119 o Receiver: implicit RP 121 Example: Google and Amazon, Amazon account can be backed by gmail 122 address. Amazon acts as implicit RP to Google in this case. 124 Google and Amazon need legal agreement, When Amazon account is 125 created or updated with gmail address Amazon makes REST call to 126 Google to enroll this new email address for RISC events. If 127 enrollment succeeds then RISC events will flow bidirectionally (see 128 next section, for simplicity only unidirectional is considered in 129 this section). 131 Assumption: Amazon/RP is registered with Google/IdP as an OAuth 2 132 client and can use access tokens for control plane. 134 Open question: what are the implications of unverified email 135 addresses? 137 Open question: discovery of hosted domains, how does Google know that 138 example.com is managed by Oracle and that subject enrollment should 139 be sent to them? 141 3.4. Implicit RP to IdP 143 o Transmitter: implicit RP 145 o Receiver: implicit IdP 147 No enrollent call is strictly necessary. The RP can start sending 148 events to IdP as new identifiers show up. 150 3.5. Pseudo-implicit 152 Common email address or phone number used by two different RPs. 154 Example: Amazon and PayPal, both Amazon and PayPal each have an 155 account with the same gmail address. 157 Mutual discovery by exchanging email address hashes. 159 Open question: legal and privacy implications 161 3.6. Identity as a Service 163 Example: Google Firebear, IdaaS manages large number of RPs and 164 implements RP functionality on their behalf. 166 IdaaS should be able to manage SET distribution configuration for its 167 RPs with a given IdP using the credentials already established 168 between the RP and the IdP. Control plane operation to create/update 169 stream allows that. 171 Assumption: IdaaS can impersonate RP at IdP (can obtain access token 172 on behalf of RP) 174 3.7. Security as a Service 176 Similar to IdaaS described in previous estion, but the service 177 provider has its own set of credentials different from the 178 credentials and RP is using. The SP cannot impersonate the RP at 179 IdP. The IdP must define delegation rules and allow the SP to make 180 requests on behalf of the RP. 182 3.8. On-Premise RP 184 The RP (receiver) is behind a firewall and cannot be reached through 185 HTTP. The only way to deliver events is if the RP periodically polls 186 an endpoint provided by the transmitter. 188 Author's Address 190 Marius Scurtescu 191 Google 193 Email: mscurtescu@google.com