MFA Interop Working Group

[Nick Roy <>]

+1

Nick

From: David Langenberg <>
Date: Friday, April 29, 2016 at 8:13 AM
To: Nicholas Roy <>, Fredrik Åslund <>, Eric Goodman <>
Cc: "" <>
Subject: Re: [MFA-Interop] Changes based on conversation on today's call

Yes, it's a good point, however, we're not here in this profile to achieve a perfectly secure solution (or even anywhere near one).  We're here to achieve a profile that minimizes impact of a specific attack -- phished credentials.  User's phone with stored first factor and also serving as second factor is not in scope.  Later work, sure, let's tackle that scenario.

Dave

-- 
David Langenberg
Identity & Access Management Architect

University of Chicago

On April 29, 2016 at 8:09:27 AM, Nick Roy () wrote:

I think this highlights the futililty of trying to achieve a perfectly secure solution with this or any other authentication profile, but it's a very valid point nonetheless.

Nick



On 4/29/16, 12:17 AM, " on behalf of Fredrik Åslund" < on behalf of > wrote:

>On Thu, 28 Apr 2016, Eric Goodman wrote:
>
>> Hi all,
>>
>> I put some proposed changes in the Usage Guidance document based on our conversation today. They are all entered as suggestions, so they are clearly marked (and undoable):
>>
>>
>> * Added a section called "Types of Factors" that calls out that two different passwords is not compliant with the profile.
>>
>> * Modified the language about factors that are accessible using only the first factor per suggestions on the call.
>>
>> o Focus was on inserting the text: "is no more secure than the single factor by itself" as an explanation of why it is not considered sufficient.
>>
>Do not underestimate the other way around, for example a "second factor"
>mobile phone, with "first factor" password stored in login forms in the
>web browser in the phone.
>
>/Fredrik
>
>> * Same change made to the "reregistration" example.
>>
>> * Added text about SPs needing to validate returned <AuthnContextClassRef> values in the "Considerations" section.
>>
>> o Scott, I did already take a stab to make it more strongly focus on validating the values in responses, rather than focusing on "not trusting" the request by itself, but of course feel free to further edit.
>>
>> In the Base Level profile, I also suggested changes to remove the language that the profile will "establish a base over which other profiles can be defined".
>>
>> --- Eric
>>
>
>Fredrik Åslund
>----------------------------------
>System Administrator
>IT-stöd och systemutveckling (ITS)
>Umeå University
>901 87 Umeå
>Sweden
>----------------------------------
>Telefon: +46 (0)90 786 65 43
>Mobil: +46 (0)70 303 78 36
>----------------------------------
>
>www.its.umu.se