Date: Fri, 29 Mar 2024 07:11:42 +0000 (UTC) Message-ID: <1552282243.7593.1711696302586@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_7592_146276387.1711696302585" ------=_Part_7592_146276387.1711696302585 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Attending
Ann West, InCommon/Internet2
Mary Dunker, Virginia Tech
Jim Green, Michigan State University
Susan Neitsch, Texas A&M
David Walker, Independent
David Bantz, University of Alaska
Benn Oshrin, Internet2
Lee Trant, University of Nebraska Medical Center
Brian Arkills, University of Washington
Michael Brogan, University of Washington
Arlene Allen, UCSB
Michael Hodges, University of Hawaii
James Oulman, University of Florida
Joe St Sauver, University of Oregon, Internet2
Shreya Kumar, Michigan Tech University
David Langenberg, University of Chicago
Ron Thielen, University of Chicago
Eric Goodman, University of California
Bry-Ann Yates, University at Albany, SUNY
Colorado State University
DISCUSSION
Assurance Requirements for the IDP
David Walker reported that a small group has met several times to discus= s assurance requirements for the Shib IdP. The objective is for the IdP to = recognize and facilitate communication with the SPs based on the InCommon a= ssurance profiles. Shreya Kumar at Michigan Tech is documenting the specifi= cations for the group. Completion target is March. When completed, the spec= . will be distributed as an RFP for a short term development project to enh= ance Shibboleth 2 to better support assurance. The specs will also be given= to the Shib Consortium for long term incorporation in their roadmap.
Q: In the SP metadata, is there an indication of what assurance level th=
e SP requires?
A: No. The metadata contains an entity tag for the IdP if certified, but n=
ot the SP. The SP specifies its required assurance at the start of each ses=
sion.
Approval of 1.2
Version 1.2 was approved by Incommon Steering on Feb. 11, 2013, and it i= s now the production spec. The Assurance website will be updated soon= with the new information. Simplifed bronze is now in effect; an audit is n= o longer needed for bronze and certification is free. Longer term, it's pos= sible that bronze assurance will replace the InCommon IdP Participant Opera= tional Practices (POP).
FICAM has a list of IdPs that have been approved by a trust framework pr= ovider. Virginia Tech is on that list, and it would be good to get ad= ditional institutions listed to make it clear that higher ed is ready= to play with the Agencies:http://www.idmanagem= ent.gov/pages.cfm/page/ICAM-TrustFramework-IDP
Alternative Means
There is now an approved process for submitting alternative means. =
http://www.incommon.org/assurance/alternativemeans.html=
a>
This was added to the spec in 1.1, but was not approved by FICAM until the=
FICAM review of 1.2. The process allows submission of alternative me=
ans:
-along with an application for assurance
-prior to an application for certification
-by a community group (such as the AD Silver group)
Approved alternative means will be added to the website and will be cons= idered normative.
The AD Silver Issue and 1.2
The issue with 1.2 and Active Directory is around the technologies (MD5 = hash) that AD uses for storage of password secrets. There are doubts = that AD could pass the "approved algorithm" bar set in version 1.2, althoug= h the alternative means option must be explored to determine this. Wh= ile AD makes it possible to enable two-factor authentication, it is not pos= sible to turn off authentication via password. Microsoft has not indicated = that they plan to change the way passwords are stored in AD.
The AAC has determined that a first step is to convene a group to look a= t AD under alternative means and develop a risk assessment and mitigation s= trategies using the AD Cookbook as a basis. Brian, Michael, Eri= c and Ron expressed interest in participating in the group.
Password Entropy Tool
Shreya presented her work on a new UI-driven password entropy tool. This= is being built on many of the capabilities in the existing Entropenator to= ol developed by University of Wisconsin-Madison. The user will enter inform= ation on their password security policies (password length, lockout duratio= n, allowed guesses, etc.), and the tool will calculate the password level, = based on the NIST specification. The tool will calculate the current = LOA eligibility and will specify what more is needed to increase LOA. = There will be a "View Report" feature and it will be possible to generate = a PDF report. There will be an "About Us" tab that will present FAQs,= explain the the tool is based on the NIST specifications and will present = information on the InCommon Assurance program.
Re-Registration for Bronze
Benn Oshrin notes that version 1.2 could lead to some confusion around w= hat is needed for password reset under bronze assurance. The issue is that = v1.2 makes section =C2=A74.2.4.3 part of bronze, and this section says:
"After expiration of the current Credential, if none of these methods ar=
e successful then the Subject must re-establish her or his identity
with the IdPO per Section 4.2.2 before the Credential may be renewed or re=
-issued."
However, almost none of =C2=A74.2.2 applies to Bronze, since Bronze has = no registration record requirements. So what does this imply for a Subject&= nbsp; with an expired credential, a no longer valid Address of Record, and = no (or forgotten) pre-registered questions?
Ann explained that the AAC felt this was a logic bug in the spec when th= e issue was raised a few weeks ago. The spec is not incorrect. The AAC did = not want to go back to FICAM to address this and risk delaying release.&nbs= p; This issue will be corrected in the next iteration of the spec. The inte= nded solution is for the institution to protect PII gathered in the registr= ation and re-registration process. It was agreed that it would make sense t= o clarify this in an FAQ.
Next Call: TBA