Skip to Content.
Sympa Menu

mfa-interop - [MFA-Interop] Agenda for the 3/3/2016 MFA Interoperability Working Group call

Subject: MFA Interop Working Group

List archive

[MFA-Interop] Agenda for the 3/3/2016 MFA Interoperability Working Group call


Chronological Thread 
  • From: David Walker <>
  • To: MFA Interoperability Profile Working Group <>
  • Subject: [MFA-Interop] Agenda for the 3/3/2016 MFA Interoperability Working Group call
  • Date: Wed, 2 Mar 2016 14:23:58 -0800
  • Authentication-results: incommon.org; dkim=none (message not signed) header.d=none;incommon.org; dmarc=none action=none header.from=internet2.edu;
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:23

Everyone,

Here's a proposed agenda for tomorrow's call:

  1. Welcome
  2. Agenda bash
  3. Review of our MFA Use Case Descriptions (see assignments below).
  4. Review of our Example Base-Level MFA Technologies (see below).
  5. Review of our DRAFT Base-Level MFA Profile.

The live-scribed notes for last week's call are, of course, available, but here are some highlights.  Note that everyone has homework.
  • We decided to limit our scope to addressing federated use cases with SAML.  If any of our use cases cannot be addressed that way, we'll say so and suggest further work, as appropriate.
  • We settled, at least tentatively, on the following specification for MFA:
"When SAML Authentication Context ‘xyz’ is used in a SAML Authentication Request or subsequent SAML Authentication Response, the meaning of that value is that a discrete second factor will always be (or was) used in the initial authentication event for the current web SSO session.  The combination of first and second factors must mitigate first-factor-only risks of phishing, offline cracking, and online guessing.  Normal SSO session options (duration, etc) are allowed.”
    • We also discussed other requirements that we will consider for higher-level profiles.
      • Registration process(es) must mitigate the risk that the two factors are assigned to different people.
      • The webSSO session must mitigate man in the middle and session hijack risks.  [I said I would check the 800-63 list of authentication risks, and it looks to me that these are the applicable risks. - DHW]
      • The authentication of all factors must occur as part of a single process, not as two separate authentication events.
  • We've made the following assignments for few-sentence use case descriptions.  Please add the descriptions to MFA Use Case Descriptions on the wiki.  We also ask that the people writing these descriptions indicate whether the MFA spec above would be sufficient for their needs.  Don't worry about other implications of your use case in this writeup unless you've got extra time and interest; just a brief description is what's needed.
    • InCommon Certificate Manager (Paul Caskey / Comodo)
    • InCommon Federation Manager (Tom Scavo, Nick Roy)
    • WorkDay  (We'll use SAML MFA for WorkDay)
    • LIGO (Scott Koranda)
    • Federal services (Paul Caskey, FICAM)
    • Intra-campus use cases (Dave Langenberg)
    • Federated AuthN to a single Grouper instance (Keith)
  • Everyone is asked to add their suggestions to Example Base-Level MFA Technologies.
  • Karen and I agreed to draft a strawman base-level MFA profile spec on the wiki for next week's call.  [We have done that:  https://docs.google.com/document/d/1vsvnyVmNglBpdX-Aw8lg268LIWwPGfowJYpcSDux3QY/edit?usp=sharing.  You'll note that we took some liberties that will need discussion.]


As always:

Dial-in numbers:

+1-734-615-7474 (Please use if you do not pay for Long Distance)

+1-866-411-0013 (English I2, toll free US/Canada Only)

PIN: 0148636#

Wiki space: https://spaces.internet2.edu/x/CY5HBQ

"Live scribe" meeting notes: https://docs.google.com/document/d/1adxlMCIqBIFEdrQ4J8sytV5zPqYIer7znaNp_Evqg0U/edit#heading=h.4zjjv9vxdyxi


Looking forward to tomorrow's discussion.

David

Attachment: signature.asc
Description: OpenPGP digital signature




Archive powered by MHonArc 2.6.16.

Top of Page