...
NOTE WELL: All Internet2 Activities are governed by the Internet2 Intellectual Property Framework.
Index to Meeting Notes
Table of Contents
Work Group Call - August 25, 2016
...
Welcome
Agenda bash
Status of the possibility of a REFEDS consultation (Scott)
There doesn’t seem to be a light-weight process that would get us a URI to use for the profiles. We’ll have to go with the full Consultation process.
Draft Charter for a Strong Identity Proofing Profile Working Group
Please look it over for discussion next week.
Eric will accept all of Scott’s comments and call it done.
Proposed changes for the next revision of Final Report of the MFA Interoperability Profile Working Group and the profiles
What should we do about the profiles’ URIs?
We’ll pursue REFEDS consultation and consider an InCommon-only interim if it looks like that will take too long.
Karen and David will talk with Ann about bringing this to REFEDS.
Scott: This is an Entity Attribute, not an Entity Category.
David will correct this. [Added to notes after the call. - DHW]
Scott: Should we just define a metadata element that lists the authnContexts that the IdP supports?
This satisfies purposes 1 and 3 in the draft spec. It’s questionable whether 2 needs anything, anyway, since SAML says you can’t lie in your assertions.
“Support” would mean something like “would reply successfully for at least one person”
Consensus on the call was that this is a good idea that’s extensible to future profiles without inventing new entity attributes, however...
The benefit of any flagging is marginal. Should we do anything?
Consensus on the call was no.
Leave the decision up to the AAC by providing the draft entity attribute definition, but recommend it not be used.
Discussion will continue next week. Karen and David will discuss, too, and recommend a resolution.
Work Group Call - May 12, 2016
...
Welcome
Agenda bash
Complete language for our profiles, based on comments received during the week
We’re editing and resolving comments.
After review of the usage guide, we’ll consider if some of its issues should move into the profile
In particular, the issue Walter raised about whether Duo’s “trusted devices” are allowed.
David mentioned that Duo will be asked to review what we’ve done, probably recommend configurations that comply. (Nick Lewis, who has Duo in his Net+ portfolio, knows about this and participates in our group.)
We got through the document and resolved all comments (for now, at least).
We resolved all comments, except for whether we should have any criteria for this profile. What’s there doesn’t require anything other than InCommon membership, but maybe we should have nothing at all.
We’ll continue this discussion next week.
This document is complete.
Everyone is asked to read and comment on Eric’s draft for discussion next week.
If there's time, brainstorm an outline for our report
There was not enough time.
Work Group Call - March 17, 2016
...
Welcome
Agenda bash
Review of our Use Cases
Is our authentication-only profile good enough for anyone’s use cases?
Good enough for Brett Bieber (U Nebraska) for the student information system, shared with state colleges.
Same for Eric Goodman (U California), except that it’s a new HR system. And may be context specific (i.e., what the user is doing, rather than who the user is).
Very similar to one of our main use cases in SWAMID, although we have one upcoming student documentation system and about 35+ members that need to implement MFA for the staff
Discussion of issues related to whether services need MFA all the time, or if they may need it later, depending on what the user does. In the first case, the SP just requests MFA. In the latter the SP may request only non-MFA initially, and MFA later, or it may request either MFA or non-MFA initially (and then require it later).
[I’m still unclear on difference between static and dynamic Phishing - matters most for Duo push]
Are we trying to require mitigation of the user bypassing authentication processes (e.g., configuring your voicemail to respond to Duo requests)?
It needs to be included in security awareness training.
What phones are allowed? Not VOIP that authenticates with a password. Phone number should be tied to a specific outlet or device (cell phone).
The IdP/institution will have to have a process to figure this out
Complete language in the profiles
Is it OK for one of the two factors to be verified at two different times?
Security training requirements (only if voice allowed?)
What is allowed technology-wise (table 1 of threats page)
No Enterprise [phones/devices/factors] if accessible (solely) via same password/credential as IdP authN
Work Group Call - March 10, 2016
...
There was consensus that we don’t want any certification.
We discussed an entity category that indicates that an IdP supports the MFA base-level profile. Also, perhaps, that an SP will respond appropriately to errors in the MFA authentication process.
Defer for future work (when we have more understanding of what’s needed.)
For now, multiple authentication requests can probably handle use cases, but may not be optimal.
It may be useful for reporting, e.g., how many IdPs support MFA.
=> We’ll put this in our report for InCommon to do.
Work Group Call - March 3, 2016
...
Welcome
Agenda bash
Review of our MFA Use Case Descriptions (see assignments below).
We’ll generalize the WorkDay description to cover other enterprise applications with varying riskiness of transactions.
Eric has offered to add some Univeristy of California cases.
Brett (Nebraska) will add to the Intra-campus use cases
Review of our Example Base-Level MFA Technologies (see below).
Duo has many options. We may want to provide some guidance of which are compliant this our spec.
Jim offered to expand on the material here.
Review of our DRAFT Base-Level MFA Profile.
Eric: We should define the authentication context, then talk about the compliance issues.
Scott: The formal definition should include the schema. He can do this.
Jim: Should we say something about identity proofing (even if it’s the “base” “we use this for ourselves”)
We could add that to higher-layered profiles
We should consider a base-level (not MFA) profile that this layers on top of.
Can address at least some of this in the usage notes.
General agreement that this is out of scope for this profile (but not future profiles)
Scott: Advocates not having ANY proofing requirement. Brett, Mary, Karen concur. Brett: This profile is entirely about enhancing the authentication mechanism.
Scott’s experience is that “proofing” typically happens at the application, and that the application typically only wants the authncontext to manage identifier repeatability.
Later discussed whether “registration” needs to be have criteria as well.
At the least we need to clearly define “proofing” vs. “registration” so we can distinguish what we’re trying to constrain.
Move definition of the authentication context to a new definition section, then reference the definition in the compliance section.
Reference the 800-63 language of multi-factor.
Certification
Institutions (via their executive contact?) will self-certify that their IdP asserts the profile correctly.
Process for community review.
We’ll plan to solicit community review of the draft profile, use cases, and target technologies after next week’s call.
Work Group Call - February 25, 2016
...
Welcome
KH: Want to refocus on our charge. Have short timeline, so need to stay focused.
Agenda bash
Review of our charge
(We don’t have a lot of time…)
“The mission of the working group is to develop and document requirements for creating and implementing an interoperability profile to allow the community to leverage MFA provided by an InCommon Identity Provider by allowing SPs to rely on a standard syntax and semantics regarding MFA.”
Deliverables
Assemble use cases that will motivate the deliverables of this working group
Develop short list of widely deployed MFA technologies in higher education that will be in scope for the profile
Define requirements for and draft MFA Interoperability Profile
Develop and recommend scope and plan for adoption
Present draft to InCommon community for review
Publish final profile
Principles
Profile should be constrained to address the articulated need for distributed MFA.
Ability to implement with current MFA and Federation technology should be a core design constraint.
Support for this capability should be exposed in the Federation Metadata.
Proposal: Limit ourselves to federated use cases and SAML. Don’t worry (too much) about incomplete SAML implementations.
One of the interesting use cases is WorkDay. It’s not clear they’re interested in federating.
We’ll include SaaS in our scope, independent of whether WorkDay is specifically interested
What we do will be useful outside of SAML, but we’ll focus on SAML.
Assign people to write a few sentences for our MFA Use Cases. Here’s the list from our last call:
InCommon Certificate Manager (Paul/Nick Roy/Comodo)
Federation Manager (Paul/Nick Roy)
WorkDay
LIGO (Scott Koranda)
Federal services (FICAM, Paul)
Intra-campus use cases (Dave Langenberg)
Federated AuthN to a single Grouper instance (Keith)
The few sentences should just describe the use cases. You don’t need to discuss implications of the use cases at this point (although it’s OK if you want to).
Create the “short list of widely deployed MFA technologies”
Can we get a few volunteers to do this for next week?
E.g., smart phone app, key fob, …
http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-817.pdf as background? (Their “categories”)
We’ll post a place where people can contribute ideas, and Karen and I will summarize and/or augment on Wednesday for next Thursday’s call.
Define what we mean by MFA
We may not decide this is strong enough, but it will serve as a baseline.
Some possibilities
From Paul: "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. Such second factor will be resistant to phishing attempts and will be used regardless of the user’s device or location. Normal SSO session options (duration, etc) are allowed.”
Inspired by How Much Security Is Enough? (replacing the bolded sentence above): “The combination of first and second factors must mitigate first-factor-only risks of phishing, offline cracking, and online guessing.”
This doesn’t eliminate, e.g., offline cracking, but it means that a cracked password isn’t enough to authenticate.
Do we care if both factors are validated in the same process (a hardware PKI token that requires a PIN), or at different times (username/password + Duo or U2F)? - No, but we may care for profiles that are stronger than the baseline.
This is probably true for man-in-the-middle, too (even in the context of websso??).
What resistance should the websso have? man in the middle, session hijack (perhaps more from the 800-63 list)
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf
We’ll go with this sentence.
We need a normative statement that expresses the requirement, then we can talk about examples, etc., of what would comply. If in two documents, they should reference each other.
We also need information on the registration process; +1
Must mitigate the risk that the two factors were assigned to two different people.
Eskil: I believe it is important that the second factor should be resistant to phishing, offline etc in itself. The first sentence was in my opinion a stronger wording regarding this.
Addition to Use Case homework: Is the base-level definition of MFA sufficient, or do we need some more of these other things in the base level?
Does this address our use cases? What else do we need to add to address more use cases? Should those things be added in additional profiles?
Karen and David will draft a strawman base-level profile for discussion next week.
Work Group Call - February 18, 2016
...
Eric: We should define what needs to be in the base level v1.0 (first column). Other things are for the future.
For next week, please add your comments to the table, including your initials so we know who’s saying what.
Work Group Call - February 11, 2016
...
Welcome
Agenda bash
Use cases
Who is going to use our profile? Some possibilities include the InCommon/Comodo Certificate Manager, the InCommon Federation Manager (metadata management for Site Admins), and WorkDay. Last week, we also thought there are probably research-related possibilities like CILogon. Will people use the profile for use cases that are internal to their campuses?
A recent note from Scott Koranda: "I want to reiterate that if the MFA profile evolves in a way that crosses national federation boundaries then it is likely to be quite useful to research VOs like LIGO."
Paul Caskey: Interest from feds in something stronger than “basic” identity, and Silver hasn’t caught on. MFA can make that differentiation.
Paul can brief FICAM about what we’re doing and get feedback.
Dave Langenberg: Chicago is using this in a campus-centric use case.
Nick Lewis: WorkDay and Duo are having discussions.
Max Miller: Is on the WorkDay group. It’s not active now, but WorkDay has said that they’ll be forming a higher-ed-related group.
Scott Cantor: WorkDay does have this on their issue list. Our work may provide an incentive to do something.
Eric Goodman: Discussion of whether our profile is useful if the SP doesn’t really “care” about authentication strength. E.g., if SP just replaces “PasswordProtectedTransport” with “MFAAuthnContext”, but doesn’t operate in any other way that makes the MFA context meaningful, then the profile doesn’t provide much value, as the SP will still rely on the IdP to address any “special” access rules.
Scott C: Even if the SPs don’t do anything differently, there’s still value to the IdP operator if they don’t need to manually configure MFA support via per-SP configurations.
Agreed(?) that if an SP asserts the profile and requests MFA, the SP operators are taking on the responsibility for dealing with “failed MFA” situations. This point should probably be spelled out as guidance.
“Handling failed MFA” may by simply mean refusing users access until MFA is asserted by the IdPs
Could also be dealt with by SPs accepting multiple authncontexts (“prefer MFA, accept PPT”).
Dave L: We may want to consider other forms of signalling of “failed MFA”. E.g., an IdP could post a notice of “Failed MFA during $TIME_PEROID” to a well known location for which SPs would monitor and could scrutinize activities more closely. This would enable campuses to fail-open when MFA providers fail and still assert MFA Success to enable business continuity.
We'll want to talk to these people to answers questions about what needs to be in or out of our base-level MFA profile.
Continued discussion of Paul Caskey's language for the base-level MFA profile.
"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. Such second factor will be resistant to phishing attempts and will be used regardless of the user’s device or location. Normal SSO session options (duration, etc) are allowed.”
Things we discussed last week:
We may not want to call phishing out specifically. There are, of course, other risks, such as man-in-the-middle.
Do we allow "trusted" devices?
How long can the SSO session be?
What questions about this language should we ask of the people responsible for our use cases?
Should the profile allow “fail open?”
Eric: “Phishing” issue; the (at some point) proposed wording of “not likely to be phished at the same time the password is phished fails the “man-in-the-middle” attack. We talked broadly about “reusable phishable information” last week.
This led to discussion of whether “recovery code” type solutions (written down one-use passcodes, HOTPs, etc) would fail the “reusable” test, if the stored code is reusable multiple times.
Scott C. raised the question of whether we are intending to signal literally “MFA” vs. “strong authentication”. “MFA” by itself seems to rule out certificate authentication
Mary: Certificate can itself be protected by password/pin. Scott was comfortable that this would bridge his concern.
Some (quick) discussion of whether password/pin protection of the external “strong” token should be considered MFA. (Eric’s inserted interpretation:) The question being whether both factors need to be authenticated directly by the IdP, vs. processes that require MFA by policy/practice.
I.e., with Duo, the IdP typically authenticates both the PPT and the Duo authentication success. With pwd-protected cert, the IdP presumes presentation of the cert-based authentication implies both factors were used.
Should we consider registration process in whether this is MFA? What if second factors can be registered knowing only the first factor?
David W: Suggestion that this trustmark/authncontext/profile strictly indicate that MFA (or otherwise acceptable “strong” encryption”) technology/process was done. While registration processes are important and relevant, those can be defined separately and combined with this profile once they are finalized.
Signalling for non-authentication “trustmarks” can be done through channels other than authnContext.
Other trustmarks will be needed. We can suggest some of those as part of our work.
(Didn’t get the name) Discussion of whether telephony based MFA is really strong encryption. Argument that strong encryption would require strong registration practices, and protections beyond what would be available on a typical (non-keycode protected) phone.
Nick: campuses aren’t going to be able to meet that high a level of “assurance”; could run into the same adoption issues as Silver. And even then, OMB 05-05/NIST 800-63 define levels above 2 that those examples may fit.
Paul: probably need to distinguish initial registration from “re-registration” in any such profiles (and possibly disallow methods that permit ‘at-any-time’ re-registration).
Though these registration profiles may still be different profiles than the MFA profile this group builds first.
Eric’s VOIP example: What if the phone is the second factor, but the first factor is used to authenticate to the phone?
Is this really a second factor? Everyone pretty much agrees “no”. However, it may be a challenge to distinguish what makes this authentication process insecure, yet still NOT address registration security.
Quick FYI: Duo Security Outage - Responses and Planning for Future was created to collect mitigations for Duo’s recent outage at various campuses.
==================================
...