Re: [Id-event] Subject Principals and Subject Principal Administrative Groupings

[Tim Cappalli <[e-mail]>]

I agree that SPAGs should be defined in the spec.

tim

From: Id-event <[e-mail]>
Date: Tuesday, July 14, 2020 at 10:55
To: Mike Jones <[e-mail]>
Cc: SecEvent <[e-mail]>rg>, Dick Hardt <[e-mail]>
Subject: Re: [Id-event] Subject Principals and Subject Principal Administrative Groupings
A few points / responses:

  1.  Agree with Mike that spag_id should not be a required claim unless it's actually required for every subject. So keeping it optional (if we decide to have it at all) is the right thing to do.
  2.  IMO it will be far simpler for multi-tenanted hosts to use SPAGs rather than manage multiple event streams (i.e. one per tenant)
  3.  A multi-tenanted architecture is increasingly very common, so this will apply to a large number of organizations.
  4.  For single tenanted transmitters, the SPAG id may be inferred by receivers. Single tenanted receivers may ignore the SPAG ids in the subjects. So processing SPAGs in hybrid situations does not appear to be cumbersome.
  5.  The use of SPAGs is not limited to tenant-level information, since it may be applied to OUs or groups
  6.  If we agree that SPAG is a "meta concept" that applies in most situations, then capturing it in the spec is probably important. What Dick is proposing is a way to implement SPAGs without specifying them in a standard, so each entity is free to define it the way they want. This approach can cause incompatibilities.
  7.  Without SPAGs in the spec, if peers need to send events about SPAGs, then they need to use the "iss-sub" catch all to send events about enabling or disabling events about SPAGs. Since this is not standardized, it could also cause proprietary and incompatible implementations.
Atul

On Mon, Jul 13, 2020 at 5:23 PM Mike Jones <[e-mail]<mailto:[e-mail]>> wrote:
As I see it, the use cases that require a spag_id can use them when necessary (unless the working group decides on another way to do this) but I certainly would oppose requiring it when it’s unnecessary.

                                                       -- Mike

From: Id-event <[e-mail]<mailto:[e-mail]>> On Behalf Of Dick Hardt
Sent: Monday, July 13, 2020 5:13 PM
To: Atul Tulshibagwale <[e-mail]<mailto:[e-mail]>>
Cc: SecEvent <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Id-event] Subject Principals and Subject Principal Administrative Groupings

Would different URLs for each relationship not solve your issue of maintaining secrets for each SPAG? For example:

https:/example.com/secevent/SPAG_ID_1<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fsecevent%2FSPAG_ID_1&data=02%7C01%7Ctim.cappalli%40microsoft.com%7C9ccd8d2be2814ab880e208d82805fa11%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637303353431075063&sdata=DJL1CFQXxAlH%2FECuofX26jHlMl%2F3ZZkzsx8CpaWqXdI%3D&reserved=0>

https:/example.com/secevent/SPAG_ID_2<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fsecevent%2FSPAG_ID_2&data=02%7C01%7Ctim.cappalli%40microsoft.com%7C9ccd8d2be2814ab880e208d82805fa11%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637303353431075063&sdata=tvfSRx1awudo6z%2B3wHdQbhsskKTp9gHxp%2Bt01PVKAxc%3D&reserved=0>

https:/example.com/secevent/SPAG_ID_3<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fexample.com%2Fsecevent%2FSPAG_ID_3&data=02%7C01%7Ctim.cappalli%40microsoft.com%7C9ccd8d2be2814ab880e208d82805fa11%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637303353431085057&sdata=AlxSKnSv%2BUyOmZ03PgZF%2BHLfpRnadcdLMJCyrTkyaX0%3D&reserved=0>

Then the credential is independent of the SPAG, but we are not injecting an identifier (spag_id) that is only relevant to orgs that want to use the same credentials across SPAG relationships.



On Mon, Jul 13, 2020 at 5:08 PM Atul Tulshibagwale <[e-mail]<mailto:[e-mail]>> wrote:
I am OK with making the spag_id a required claim in every subject identifier. For single tenanted transmitters, it would be a constant value for all events they generate.

On Mon, Jul 13, 2020 at 4:01 PM Dick Hardt <[e-mail]<mailto:[e-mail]>> wrote:
So the receiver is using authentication sometimes to determine SPAG, and not at other times?

I'm digging into this as I had always thought of the event being between two parties, where they are identified by the endpoint and/or the credentials.

Adding a relationship identifier seems to be solving the problem at the wrong layer, unless it is in all events.


On Mon, Jul 13, 2020 at 3:54 PM Atul Tulshibagwale <[e-mail]<mailto:[e-mail]>> wrote:
Sorry for the terse message.

If a single tenant transmitter is trusted by a multi-tenanted receiver for a specific tenant, then the SPAG-id need not be included if the subject is unique at the tenant level, because the receiver will automatically identify SPAG that the subject belongs to on its end (based on the authentication).



On Mon, Jul 13, 2020 at 3:37 PM Dick Hardt <[e-mail]<mailto:[e-mail]>> wrote:
Which part is not required?

On Mon, Jul 13, 2020 at 3:33 PM Atul Tulshibagwale <[e-mail]<mailto:[e-mail]>> wrote:
Not required, since the claim is optional.

On Mon, Jul 13, 2020 at 3:25 PM Dick Hardt <[e-mail]<mailto:[e-mail]>> wrote:
Would a transmitter that is only in one SPAG (a single tenant system) have to include its SPAG id in events sent to a receiver that accepts events from multiple SPAGs? But it would not include it in sending events to other receivers that have separate credentials for each relationship?



ᐧ

On Mon, Jul 13, 2020 at 3:05 PM Atul Tulshibagwale <[e-mail]<mailto:[e-mail]>> wrote:
That could be true but there are a few ways in which it can be avoided:

  1.  The peers leverage some higher-level trust to accept / decline events relating to lower level SPAGs. For example, if trust is established at a tenant level, then an OU level SPAG need not have its own authorization.
  2.  The secret required for establishing the authorization of a SPAG may be temporary. For example:

     *   An administrator signs in to their tenant in the transmitter's administrator console
     *   The admin obtains a temporary authorization (one-time code)
     *   The admin signs in to their tenant in the receiver's administration console and pastes in the one-time code
     *   The receiver sends a request to enable the stream for the specified SPAG with that one-time authorization.
In the first case, there are no additional secrets required. In the second case, the secret is temporary.



On Mon, Jul 13, 2020 at 2:34 PM Dick Hardt <[e-mail]<mailto:[e-mail]>> wrote:
I see the SPAG lets the transmitter and receiver provide context, as the subject identifier may be the same across SPAGs.

Now I'm trying to understand how the transmitter authenticates to the receiver if it does not have it's own secret (assuming that authentication model) -- IE, how does the receiver know the transmitter is authorized for that SPAG?


On Mon, Jul 13, 2020 at 2:08 PM Atul Tulshibagwale <[e-mail]<mailto:[e-mail]>> wrote:
Dick, your understanding is correct.

To clarify the proposal here, Here's the text I'm proposing to be added:

3.  Subject Principals

   Subject Principals are the management entities associated with
   Subjects.  These may be human or robotic principals or devices or
   other entities that are managed by transmitters and receivers.  For
   example, the same Subject Principal may be referred to by an email
   address or a phone number.  A transmitter or receiver will typically
   manage subject principals and organize them into sub-groupings such
   as tenants, groups, organizational units, etc.

   Subjects are identified by Subject Identifiers defined below.

3.1.  SPAGs

   Subject Principals MAY be grouped for administrative purposes into
   "Subject Principal Administrative Groupings" or SPAGs.  For example,
   all users belonging to one customer of a "multi-tenanted" Transmitter
   may be in one SPAG.  Alternatively, an Organizational Unit or a group
   of Subjects within a customer of a Transmitter (whether multi-
   tenanted or not) may be one SPAG.  SPAGs may have overlapping sets of
   Subjects.

   A SPAG MAY be the Subject of certain stream update events defined
   later in this spec, hence is defined as a Subject Type of its own
   below..  A SPAG identifier MAY be included in other subject types to
   disambiguate the subject.

   A SPAG subject identifier is agreed to offline between a transmitter
   and a receiver.
The benefits of doing this are:

  1.  Multi-tenanted hosts do not need to maintain secrets per tenant and per transmitter tenant if each tenant has to be an event transmitter and an event receiver of its own.
  2.  An event stream may be established between two multi-tenanted hosts, and so does not need to be managed at a per-tenant level
  3.  The same subject or subject principal may be a part of multiple SPAGs, and identifying the SPAG that an event relates to can be achieved if the standard allows for the SPAGs to be identified.


On Mon, Jul 13, 2020 at 11:32 AM Dick Hardt <[e-mail]<mailto:[e-mail]>> wrote:
To clarify, your proposal is driven by the implementation burden of maintaining separate secrets / streams between a transmitter and receiver?
ᐧ

On Mon, Jul 13, 2020 at 9:01 AM Atul Tulshibagwale <atultulshi=[e-mail]<mailto:40google.com@dmarc..ietf.org>> wrote:
Hi all,
Here's a quick background for the proposal<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frichanna%2Fsecevent%2Fpull%2F1&data=02%7C01%7Ctim.cappalli%40microsoft.com%7C9ccd8d2be2814ab880e208d82805fa11%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637303353431085057&sdata=8kZ%2FE667mzW9NoHuWC0UjIciV%2BEFDjXXPQccVoofSSk%3D&reserved=0> for including Subject Principals and Subject Principal Administrative Groupings or SPAGs in the Subject Identifiers spec.

Use of Subject Identifiers in Shared Signals and Events:
The Shared Signals and Events (SSE) profile of SETs specifies that transmitters and receivers send and receive SETs that contain Subject Identifiers. These subject identifiers have the format that is now being discussed as a separate specification here.

Transmitters and Receivers in SSE
The SSE profile defines transmitters and receivers as hosts that manage streams between peers. The receiver authenticates to the transmitter using OAuth, requiring the use of a secret per receiver. In a multi-tenanted host that handles hundreds of thousands or millions of independent tenants, maintaining such a secret per instance of a receiver is cumbersome. Furthermore, since a transmitter and a receiver has to maintain a stream per pair, creating such per-tenant streams can add significant implementation overhead.

SPAGs
Therefore, we need a notion of a grouping of subjects within the same transmitter and receiver to distinguish between various administrative groupings that exist within a host. These groupings could include tenants, organizational units or user groups.. This grouping is captured in the notion of a SPAG. The uniqueness of a user identifier (subject identifier) may also be limited to a SPAG. For example, if a random unique ID represents a user, then that ID may be unique within a SPAG and not universally across a transmitter or receiver. This is because each transmitter and receiver may have multiple connections to other transmitters and receivers, and ensuring uniqueness across all such peers is probably an intractable problem.

Subject Principals
While what is represented within a subject identifier may be only an aspect of the management entity, the administrative grouping is about the management entity itself. This could be the user, device or other principal that the subject identifier represents. Therefore, an abstract notion of a Subject Principal is also required in order specify what the grouping within a SPAG is about.

The above is captured in the "Subject Principal" and "SPAG" sections within the proposed PR<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frichanna%2Fsecevent%2Fpull%2F1&data=02%7C01%7Ctim.cappalli%40microsoft.com%7C9ccd8d2be2814ab880e208d82805fa11%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637303353431095051&sdata=pj4WBHmM8VqizQydVnmsGZths6AJ9IgJTgnOpnMDe3U%3D&reserved=0>amp;reserved=0>.

Thanks,
Atul

_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/id-event<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fid-event&data=02%7C01%7Ctim.cappalli%40microsoft.com%7C9ccd8d2be2814ab880e208d82805fa11%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637303353431095051&sdata=4lnyQUcGLfoMktuNhXDCn%2B43Kg%2FjhyIaNiH6OlO7r2Q%3D&reserved=0>