Skip to content

Workshop Feb2020

Jump to bottom
Tim Cappalli edited this page Feb 5, 2022 · 2 revisions

Tuesday February 11, 2020

Agenda

  • Introductions
  • Summary of current status
  • Background on RISC
  • Topics of Interest
  • Topology
  • Discovery and Registration (Bootstrapping)
  • Authorization
  • Event Types
  • Subject Types / Identifiers
  • Plan for future meetings

Introductions

  • Atul Tulshibagwale - Google (G Suite Security)
  • Reda Zerrad - Lookout (Post-perimeter security alliance)
  • Jordan Wright - Cisco Duo
  • Nick Wooler - Cisco WebEx Identity team
  • Asad Ali - Thales (CTO office, IAM and data protection)
  • Mike Jones - Microsoft (Identity Standards)
  • Pam Dingle - Microsoft (Identity Standards)
  • Morteza Ansari - Cisco (Security group CTO office)
  • Phil Hunt - IndependentId, worked on security event tokens
  • Adam Hampton - Sailpoint (R&D labs, standards and new ventures)
  • Sergey Petrenko - OneLogin (Security Architect)
  • Gokul Baskaran - Target (Identity and Authentication team)
  • Rich Smith - Cisco (Duo Labs CTO)
  • David Waite - Ping Identity
  • Oren Melzer - Microsoft

Notes

RISC vs CAEP

  • [Jordan] Events versus Updates discussion
  • [Phil] CAEP events are normal, in contrast to RISC, which are exceptional
  • [Sergey] RISC is defined by policy, whereas CAEP is broader, and a different set of policies or no policies may apply
  • [Morteza] Events are always related to policy, but signals may not always be associated with policy. Various network components may make policy decisions based on signals
  • [Jordan] CAEP should not prescribe policies, only specify the mechanisms
  • [Pam] Is there an assumption in RISC about cardinality. Is there a difference wrt this in CAEP (i.e. a large number of small pipes versus a very few big pipes in RISC)
  • [Jordan] Establishing streams may need to change in terms of how hard it is in RISC
  • [Jordan] We had considered extracting management api part of RISC to make it common between RISC and CAEP
  • [Morteza] Due to the larger numbers one may require new ways of filtering streams
  • [Mike] Who are the parties communicating may need to be defined
  • [Mike] We should drill into this aspect in this workshop
  • [Asad, Gokul, Mike, Atul, Morteza] Discussion on mTLS. It could be too low-level at this time.
  • [Mike] First need to understand the problems we are trying to solve, then we can focus on the mechanisms required.
  • [Pam] Is the event stream required or is it optional.
  • [Sergey] Who are the participants in CAEP

Event Types

Review G-Suite Scenario: https://docs.google.com/document/d/1w8x5bYqBm2vD2u0VSWtbmThCcO7aOSUvCs-6Yw23mqw/edit?usp=sharing

Discussion

  • [Pam] What are the event types and how do we identify the scope
  • Session scoped subject type (referred to in the scenario as the SAML request id / assertion id)
  • [Asad]
  • [Morteza] Some events may demand full re-auth, some others may not (as described in the scenario)

Review CAEP Federation Scenarios

Wednesday February 12, 2020

Attendees

  • Atul Tulshibagwale
  • Jordan Wright
  • Mike Jones
  • Ali Asad (Thales)
  • Morteza Ansari
  • Rich Smith
  • Adam Hampton
  • Gokul Baskaran
  • Matt Domsch
  • Phil Hunt

Agenda

  • Cover more use cases to try and identify event types, subject types, topology and authorization requirements

Event Types

CAEP Event Types doc: https://docs.google.com/spreadsheets/d/1GUrWQOyp3hz6KJ7rRDnuB0PrsgAqkKNeX85wQSkrzPA/edit#gid=0

Authentication Events Flow Use cases: https://docs.google.com/document/d/1TPc_O8IiyyR9A-VA-xK-fVB3ZTssJmhz/edit

Multi-Identity + Telco Use cases: https://docs.google.com/document/d/1Ip2D9cr5yi3r-XA9x3qZT8xdCaQlJR43_wTxBiwpCzY/edit

Topology

Messages could have no target. That is, they could go to a “CAEP endpoint” where they would then be reprocessed, then propagated via CAEP to downstream recipients as needed.

Event vs. Signal Possible distinctions:

  • Event indicates that some action was taken. Signals are observations
  • AI: Get together and come up with a definition between the two:
    • Rich
    • Asad
    • Jordan
    • Sergey

How we want to transmit signals

We anticipate using SET’s to transmit signals, though we may need to make a profile on top of them

For the transport, we should try and work with the DELIVERYPUSH and DELIVERYPOLL SET transmitting specifications to see if they’ll work, or we need to make adjustments.

For authorization, we should read the FastFed specification to see how they think about discovery and establishing a cross-org trust relationship.

Action Items

  • AI: Jordan and Asad volunteer to be editors for the consolidated use cases documents
    • AI: Rich and Jordan to provide security use-cases
    • Jordan and Asad to start by creating a common format for each use case
    • Deadline: 3 weeks for initial draft of use case document
  • Next F2F meeting to correspond with IIW April 28, 2020 – April 30, 2020
    • OpenID workshop the day before
    • Atul signed up as a presenter
    • F2F to be after IIW (Thursday afternoon and Friday morning)
  • AI: Jordan to send email to caep-discuss / risc mailing lists
  • AI Determine who can host
  • AI: Atul to post to caep-discuss to deprecate the list in favor of risc
  • AI: Atul to create initial draft of solution
    • Deadline: One week before IIW
  • Move our discussions to the bi-weekly RISC call

Artifact: "Subject Identifiers for CAEP.docx"

The following subject types are required to implement the scenarios detailed in CAEP.

  1. Browser Session
  2. Federation Session
  4. Device
  5. Device assignment (i.e. a unique identifier representing a specific user on a specific device)
  6. App

All RISC subject identifiers

Home

Meetings

Clone this wiki locally