MACE Call 1-August-2011

**MACE Call 1-August-2011**

**Attending**
RL "Bob" Morgan, U. Washington (chair)
Ken Klingenstein, Internet2
Scott Cantor, The Ohio State U.
Keith Hazelton, U. Wisconsin - Madison
Leif Johansson, SUNET/NORDUnet
Von Welch, Indiana U.
Michael Gettes, CMU
Tom Barton, U. Chicago
Jim Jokl, U. Virginia
Steven Carmody, Brown U.
Renee Shuey, Penn State U.
Ann West, Internet2
David Wasley, independent
Nate Klingenstein, Internet2
Steve Olshansky, Internet2 (scribe)

NEXT CALL: 15-August-2011

**New Action Items**
[AI] (Von) will invite REN-ISAC management to a future MACE call (TBD, could be a subset one-off call) for further discussion of potentially applying more intelligence to IdM systems to thwart attacks, or other overlapping areas of interest.

**Carryover Action Items**
[AI] (All) discuss further ideas on IAM suite collaboration on the mailing list.
[AI] (All) send seedcorn suggestions to Ken.
[AI] (Ken) will distribute the CRU taxonomy of SPs
[AI] (Ken) will send out a link to relevant GENI IdM information.
[AI] (Keith) will write up the current state of the identifier discussion and apparent consensus, and associated explanatory material, for use by REFEDs.
[AI] (Ken) will coordinate a small working group with Heather to look into access control and IdM layer requirements for shared file services, calendaring, and web-conferencing in a federation-centric context.
[AI] (All) with suggestions for other foundations that the Shib Consortium could eventually be embedded in are encouraged to discuss them on the list.
[AI] (Ken) will convene a small subgroup of MACE to consider the seed corn issues in more depth and report back on a forthcoming call, soon.
[AI] (Ken) will invite Mike Conlin (U. Florida), the VIVO PI, to a forthcoming MACE call.
[AI] (Keith) will maintain an issues list to inform a potential new charter for MACE-DirNG, syncing it with the FedApps charter.
[AI] (RLBob, Scott, and SteveO) will proceed with the process of formalizing the FedApps working group, including setting up a list/wiki/website, and advertise it in the appropriate venues.
[AI] (Ken) will draft a one-pager about what MACE does and what questions it has, for review by MACE, as a discussion guide with Internet2 leadership.
[AI] (Ken) will distribute a draft requirements framework for VO support engagement
[AI] (David) will contact GSA for an update on the approval process for InCommon Silver.
[AI] (ReneeS) will revisit the list of potential new MACE members on the list.
[AI] (Ken) will send out info on DHS secure online transactions
[AI] (Ken) will follow up on a MACE/AMSAC call.
[AI] (Ken) will follow up with Kuali/Rice about I2MI collaboration.
[AI] (Ken) will draft a catalyst doc, covering the key items to be addressed in advising VOs how to use our infrastructure.
[AI] (Leif) will contact Ken/Steven/Tom about potential overlaps between the SDCI proposal and projects in the EU.
[AI] (Jens) will speak to an Eduroam rep about communicating with Educause.
[AI] (Ken) will draft and circulate a letter to Rice leadership, requesting input to roadmaps and use cases, and to ensure our projects with Kuali projects are aligned with their high-level strategic direction.
[AI] (Nate) will distribute information to the list about upcoming tactical issues facing MACE
[AI] (All) send Bamboo IAM comments to Tom ASAP for coordination.
[AI] (All) interested in participating in the international collaboration activity contact RL "Bob."
[AI] (RL "Bob") will contact a representative of Kuali Rice about coordinating a call.
[AI] (Ken and Mark) will distribute some information on trust anchors in the context of dynamic network configuration in GENI testbed, as well as for general access control.
[AI] (Ken) will circulate some meeting notes from the last TERENA/REFEDS meetings.

**Theme Call**

(1) "Risk-based authentication":

Searching on the above term reveals many links promoting the concept of using a variety of environmental factors as input to the authentication process: various kinds of user-related factors such IP address, cookie presence, prior behavior, etc; and transaction-related factors. US financial companies have done a lot of this, because they have been forced to. Google says that the big IdPs do it too, to reduce hacking costs.

We might discuss:
* are campuses doing any of this today?
* are there practices to recommend?
* how does this relate to traditional assurance guidance?

This was formerly referred to as "layered authn" -- an IdP in high risk or larger scale environments would be motivated to apply heuristics to authn acts to manage risk. It was noted that password resets often consume a great deal of time and energy on the part of the organization, and thus there is motivation to reduce this as much as possible. E.g. flagging login attempts from unusual geographic locations is one low hanging fruit, if managed correctly.

Limiting exposure to password attacks is a major motivator, and utilizing CAPTCHAs is one approach commonly used although they are only usable for web-based authn. To the extent that other protocols are able to carry additional information, users can be redirected to a webpage to resolve an account lockout...

Some campuses have serious anti-phishing measures in place, e.g. looking for diverse login sources, and monitoring black-hat sites for published hacked accounts.

Sharing observed attack/threat information between sites is one obvious example, and REN-ISAC is doing this currently (and may be pursuing federated access in the near future). SES (Security Event System) will be expanding, based upon institutional (v. personal) trust. Meaningful individual identifiers that are useful across domains is a challenge that they are looking at, e.g. to identify compromised user accounts.
http://www.ren-isac.net/
http://www.ren-isac.net/ses/

Note also fordrop.org, which is currently funded by .SE and is being picked up by CERTs and IRT teams all over the world. Both cert.org and Team Cymru are already in this loop.

Ken will be drafting a one-pager aimed at CIOs, on the value of bringing IdM groups and security operations groups to cultivate cross-pollination opportunities. It was noted that these are often different parts of the IT organization however.

Event correlation and analysis is being used more commonly these days, at least on some campuses, to monitor attacks. However campuses are often running many diverse services, and thus this can be challenging given the complex environments.

[AI] (Von) will invite REN-ISAC management to a future MACE call (TBD, could be a subset one-off call) for further discussion of potentially applying more intelligence to IdM systems to thwart attacks, or other overlapping areas of interest.

Since accounts can be compromised by means other than phishing, it is important to not focus on this to the exclusion of other threat vectors.

For the higher-ed community, is there software to be written, or guidance to be provided, or other contributions that MACE/I2MI ought to undertake? Requirements gathering around big-scope IdM systems is underway in various fora, should this topic --- attack resilience -- be included?

See also for reference: Phishing Technical Controls: Beyond Proofpoint
http://www.educause.edu/SEC11/Program/SESS05

(2) "LMNOP", aka "StreetID":
http://www.slideshare.net/sachseric/identity-as-easy-as-lmnop
https://sites.google.com/site/oauthgoog/

This is Google's pitch from a recent IIW event about an ambitious plan to make a brave new higher-assurance web authentication world by connecting the big IdPs to mobile-phone authentication and subscriber databases. This, I believe, is among the initiatives being pursued in the OIX.

We might discuss whether this is realistic, whether there are opportunities for HE in that picture, whether this means we're all doomed, etc.

The question of whether this might aid remote proofing arose, and the answer is not yet clear.

The issue arose: what does Google expect phone-based identification to be authoritative for? Pseudonymous identifier? The actual user of the phone -- who is often not the account "owner"? The "responsible party"? Privacy issues may be difficult, at least for some in the community (i.e. not Google?).

See also for reference various efforts around "Mobile PKI."

The assumption that mobile operators actually validate identities beyond e-mail address and credit card (account responsibility) is likely not realistic, and certainly they have no control over who actually uses any particular mobile device.

OIX is also working on related topics, more to come on this...