MFA Interop Working Group

[Steven Carmody <>]

we could actually use the

        


email list to collect real use cases.  ;-)

There are already quite a few IC campus members that are in production 
with WD, but want to add/implement MFA as a requirement when accessing WD.

On 2/17/16 5:30 PM, Nick Roy wrote:
> Michael Gettes from Penn State might be good to contact about Workday.
>   They are in the middle of an implementation.  I think UW is, too,
> maybe Jim Phelps and / or Nathan Dors?  I think we need Workday use
> cases from the customers, not the vendor.
>
> Nick
>
> From: 
> <
> <mailto:>>
>  on behalf of David Walker
> <
>  
> <mailto:>>
> Date: Wednesday, February 17, 2016 at 3:05 PM
> To: MFA Interoperability Profile Working Group 
> <
> <mailto:>>
> Subject: [MFA-Interop] Agenda for the 2/18/2016 MFA Interoperability
> Profile Working Group call
>
> Everyone,
>
> Here's a reminder of this Thursday's MFA Interoperability Profile
> Working Group call (2/18/2016, 4:00-5:00 ET).  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
>
>
> A proposed agenda from Karen and me follows; it's also in our "live
> scribe" document.  I look forward to talking with all of you on Thursday.
>
> David
>
> ------------------------------------------------------------------------
>
> Agenda
>
>  1.
>
>     Welcome
>
>  2.
>
>     Agenda bash
>
>  3.
>
>     FYI: GTRI Trustmark Pilot <https://trustmark.gtri.gatech.edu/>.
>       Specific trustmark definitions are at
>     
> <https://trustmark.gtri.gatech.edu/operational-pilot/trustmark-definitions/>https://trustmark.gtri.gatech.edu/operational-pilot/trustmark-definitions/
>
>       *
>
>         Trustmark Definition (TD):  Implementation of Multi-Factor
>         Hardware Cryptographic Tokens
>         
> <https://trustmark.gtri.gatech.edu/operational-pilot/trustmark-definitions/implementation-of-multi-factor-hardware-cryptographic-tokens/1.0/index.html>is
>         a good example.
>
>  4.
>
>     FYI:  The use cases we’ve identified so far:
>
>       *
>
>         InCommon Certificate Manager (Paul/Nick/Comodo)
>
>       *
>
>         Federation Manager (Paul/Nick)
>
>       *
>
>         WorkDay (we'll need to find someone to contact)
>
>           o
>
>             Other cloud services?
>
>       *
>
>         LIGO (Scott Koranda)
>
>           o
>
>             Other VOs?
>
>       *
>
>         Federal services (FICAM)
>
>       *
>
>         Intra-campus use cases (Dave Langenberg)
>
>           o
>
>             Probably others.
>
>  5.
>
>     Answering our current questions
>
>       *
>
>         See table below.
>
>       *
>
>         Which should we answer in our base-level MFA profile?
>
>       *
>
>         Which should we leave for future work?
>
>       *
>
>         How many can we answer today?
>
>
> Current Questions
>
>
>         
>
> Question
>
>         
>
> Base-Level MFA
>
>         
>
> Future Required Trustmark
>
>         
>
> Future Optional Trustmark
>
> 1
>
>         
>
> Do we want to call phishing out specifically? There are, of course,
> other risks, such as man-in-the-middle.
>
>         
>         
>         
>
> 2
>
>         
>
> Do we allow "trusted" access devices (PCs, phones, etc.)?
>
>         
>         
>         
>
> 3
>
>         
>
> How long can the SSO session be?
>
>         
>         
>         
>
> 4
>
>         
>
> Do we allow "fail open?"
>
>         
>         
>         
>
> 5
>
>         
>
> Is a second factor that is unlocked with the first factor (e.g., VOIP
> phone) really a second factor?
>
>         
>         
>         
>
> 6
>
>         
>
> Can a second factor be registered solely on the basis of the first factor?
>
>         
>         
>         
>
> 7
>
>         
>
> In general, is the registration process "strong enough?"
>
>         
>         
>         
>
> 8
>
>         
>         
>         
>         
>
> 9
>
>         
>         
>         
>         
>
> 10
>
>         
>         
>         
>         
>
> 11
>
>         
>         
>         
>         
>
> 12
>
>         
>         
>         
>