Assurance

[Emily Eisbruch <>]

Greetings,

Please mark your calendar for the next Monthly Assurance Call,
Wed., April 1, 2015 at noon ET.

Connection Info:
+1-734-615-7474
+1-866-411-0013 (toll free US/Canada Only)
Access code: 0129048#

This call will feature a discussion on Password Reset, led by Eric Goodman, Identity and Access Management Architect, University of California Office of the President.

We will start with a short introduction laying out the  issues, followed by open discussion.  During the discussion, we will consider questions such as:

• What is your policy and what is working / not working about it ?
• Is it worth codifying password reset procedures?
• Any recommendations to modify the language in the IAP for InCommon to  consider?

For reference, below Eric's January 2015 summary of an email thread on the password reset topic.

Thank you and we look forward to your participation on the call.
Emily


=====================
FOR REFERENCE:
EMAIL THREAD SUMMARIZED BY ERIC GOODMAN AS OF JAN. 2015

Hello and Happy New Year!

At the end of last year I started a thread on the InCommon Participants mailing last year discussing account recovery/password reset and the Bronze IAP. It was pointed out (offline) that the InCommon Assurance mailing list is probably a more appropriate place for the discussion, so I’m posting a follow-up summary of that thread here instead of on the Participants list.

My original message was asking about section 4.2.4.3 of the Bronze/Silver IAP. That section provides a list of approved password change methods, followed by the statement “if none of these methods is 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.” Because the section 4.2.2 applies only to Silver IAQ accounts, there’s ambiguity about what is acceptable for recovery of a Bronze IAQ account when the explicitly allowed mechanisms fail.

In that thread, I asked for examples of processes campuses actually use to recovery Bronze IAQ accounts when the allowed methods in 4.2.4.3 fail, and specifically how campuses that have certified/self-asserted compliance with Bronze determined/justified that such processes met the IAP requirements in this section.

There was a good theoretical discussion of the requirements -- and I did even get one response (off-list) with an actual Bronze process example :). Reading between the lines of the theoretical discussion, I want to make some concrete statements and see if they capture what people are thinking and doing:

How people interpret the IAP requirements:

·         For Silver: The list of allowed methods in 4.2.4.3 combined with the identity proofing processes defined in 4.2.2 comprise a complete list of allowed password change methods.

·         For Bronze: The list of allowed methods in 4.2.4.3 provide an incomplete list of allowed password change methods. Other methods would be considered to be acceptable/compatible if they meet the general Bronze IAP criteria outlined in section 3.1 that:

o   “Assertions under this [Bronze] profile are likely to represent the same Subject each time a Subject identifier is provided” and

o   “it is expected that IdPOs use reasonable care when [re-]issuing Credentials to confirm that a single individual applies for and receives a given Credential and its Authentication Secret.”

How people apply this requirement (for recovery of Bronze accounts):

a)      Users provide information that loosely (i.e., not Silver verified) binds their account to known, valid identity data. E.g., A user provides information that matches them to an employee or student record as part of creating/updating their account profile.

b)      Account operators presume that (unverified), completely self-asserted information registered by a user in their profile accurately describes the real world owner of the account.

If either are true, then we can use whatever mechanisms we see as meeting the “reasonable care” guideline to verify a real life person’s identity against the (a) referred to source system record or (b) the (unverified) profile data registered on the account, to perform account recovery operations.

Implications:

·         Account operators presume that people provide accurate information as part of their account profiles, even if there’s no mechanism whatsoever to positively validate that presumption.

o   E.g., if I registered an account using a fake name and other data, I wouldn’t be able to recover that account (if 4.2.4.3 methods fail), but some real person who happens to match the false information I provided could potentially take possession of the account. In this case, we fail the “it’s the same person each time” test, but arguably not in a way that violates the “reasonable care” metric.

·         For truly anonymous accounts (no name or other data that can be verified against externally), there is no recourse; if the 4.2.4.3 methods fail the account is forever unrecoverable.

·         It’s arguable that the additional processes (beyond 4.2.4.3) account operators use for of recovery Bronze accounts should (must?) be registered as Alternative Means with InCommon.

o   This contradicts the interpretation (above) that section 4.2.4.3 is an incomplete list of allowed methods for both Bronze.

o   Alternative Methods processes are likely similar enough across campuses that relatively few would need to be created to cover most use cases .

Is this a reasonable summary of how people look at account recovery for Bronze accounts?

Thanks for your time, especially if you’ve read this far!

--- Eric


 

Emily Eisbruch, Technology Transfer Analyst
Internet2

office: +1-734-352-4996 | mobile +1-734-730-5749