[Openid-specs-mobile-profile] ACR values
Torsten Lodderstedt
torsten at lodderstedt.net
Sun Nov 29 18:30:39 UTC 2015
Hi John,
I understand your argument. It's always a trade off between being
specific (and risking failed authentication attempts) and being to
generic (and loose control). I think there is no difference between
having two LOAs + 2 AMRs on one side or having 3 LOAs, if the AMR is
required from a RP's perspective to assess the authentication. But let's
assume we go with two LOAs for single and 2 factor authn.
I think just single factor won't be enough, as Mobile Connect (according
to my understanding/interpretation) is about password-less single factor
authentication. So I assume we need to have a certain special single
factor authentication ACR value.
best regards,
Torsten.
Am 28.11.2015 um 22:19 schrieb John Bradley:
> Operators will certainly have some users with devices that store keys
> in hardware (SIM) and others that are using software, and probably
> some that are using the HW keychain unlocked by a biometric or a pin.
>
> The point I am trying to make is that a user has one device. It will
> or will not have HW protection for the key. If the RP is too specific
> about what it asks for all it will do is cause failed authentications.
>
> I was counting click OK to the SIM applet as single factor (Because it
> is). In the single factor case the AMR would differentiate between
> a SIM with click OK and a password or something else.
>
> We can send more specific information back in the amr about what happened.
>
> The acr in the request shouldn’t be too specific because that just
> forces the IdP to return an error vs something useful.
>
> I am bading these observations on the three levels in the current
> document.
> Two are effectively the same from a request point of view. Give me a
> authentication where the user needs to locally authenticate to the
> device. The only diffrence will be how the key is protected in the
> hardware and that depends on the device. The RP can’t influence that
> in a meaningful way during authentication.
>
> So far I don’t see having more than two LoA in the request as being
> useful from the description.
>
> What behaviour at the IdP would the third one cause different from the
> second?
>
> It may be that there is something, but it is not captured in the
> description. That is what I am looking for.
>
> John B.
>
>
>
>> On Nov 28, 2015, at 2:51 PM, Lodderstedt, Torsten
>> <t.lodderstedt at telekom.de <mailto:t.lodderstedt at telekom.de>> wrote:
>>
>> Hi John,
>> why doesn’t it make sense for a RP to specifically ask for HW
>> protected keys? I could imagine some operators use software-based
>> keys (which should be ok in some cases) whereas the majority will
>> store them on the SIM card.
>> And by the way: It’s not just about asking the OP to perform 2nd
>> factor authentication or accept single factor. In the case of Mobile
>> Connect, it is also desirable to ask for certain factors (or better
>> said prohibit knowledge alone) in the single factor case. The
>> predominant example is inherence in the case of SIM applet (click ok).
>> best regards,
>> Torsten.
>> *Von:*John Bradley [mailto:jbradley at mac.com]
>> *Gesendet:*Freitag, 27. November 2015 20:02
>> *An:*Lodderstedt, Torsten
>> *Cc:*openid-specs-mobile-profile at lists.openid.net
>> <mailto:openid-specs-mobile-profile at lists.openid.net>
>> *Betreff:*Re: [Openid-specs-mobile-profile] ACR values
>> That is true but normally the levels are not defined in a protocol
>> document. They would be in a trust framework document that details
>> how to conform to them including all the legal and business practice
>> agreements.
>> All we can say is that all of that is dealt with someplace else and
>> the URI indicate the means by which the subject was most recently
>> authenticated.
>> One of the hard things with LoA is that better might be subjective.
>> There is no guarantee in general that one is better than another as
>> they might theoretically mitigate different risks.
>> For MODRNA LoA it looks like we are going to have three dimensions
>> for what would normally all be bound up in a single loa number in
>> 29115/SP800-63
>> a) Identtiy proofed [ “True” , “False”] (can the IdP
>> legally identify the subject)
>> b) Proof of Possession [ “True” , “False”] (in 800-63 PoP is
>> required for LoA 4, but we can deal with it separately in the protocol)
>> c) Strength of Primary credential [ “single factor”, “multi-factor
>> soft-key”, “ multi-factor hard key” ]
>> In the first stage we are only asserting non proofed subjects.
>> That gives us three levels now and eventually six to plan for.
>> In reality the user will have a token with a HW or software key, so
>> as a RP asking specifically for one or the other doesn’t make much sense.
>> As a RP I think that you want to be able to say force the user to 2nd
>> factor if there current login is single factor, or I will take what
>> the user is logged in as.
>> Lets assume for the moment that amr in the response can differentiate
>> between hard and soft keys.
>> That would leave us with two acr values to ask for. Lets call them
>> 1F and 2F for the moment.
>> That would give us:
>> [ “1F” ] == Give me what the user has logged in at, don’t force
>> step up.
>> [ “2F” , "1F" ] == Force the user to do two factor if there device
>> supports it, but I will take single if that is all there device supports.
>> [ “2F” ] == Force the user to do two factor if there
>> device supports it, return an error if 2F is not available.
>> In the response the “amr” will indicate if the authentication was
>> with HW or SW based keys.
>> It strikes me that trying to add another LoA complicates things for
>> the RP.
>> I suspect that for initial login most sites will want [ “1F” ] and do
>> [ “2F” , "1F" ] for step up around specific transactions.
>> Banks will want [ “2F” , "1F" ] all the time.
>> Asking for [ “2F” ] on its own is not as useful as asking for [ “2F”
>> , "1F" ] at-least if you get back a LoA with “1F” then you know it
>> is probably the correct person as opposed to any random person who
>> could generate an error, at that point you can guide them through
>> some other step up or tell them to use a different device etc.
>> However some people may have limited RP logic and be happier with an
>> error.
>> So as an example if the user has authenticated with “2F” but the RP
>> asks for [ “1F” ] then we would expect the IdP not to prompt
>> (assuming max-age is ok) and return “2F” as the acr in the response
>> along with a amr indicating if the key was HW or SW protected.
>> It might make sense in non modrna cases to have a RP specifically ask
>> for a HW backed multi-factor. The IdP could force the user to use a
>> smart card with match on card biometrics on a different computer,
>> rather than using the soft token on the phone. How ever I don’t
>> think that is our use-case, and having an extra thing the RP can ask
>> for just adds to the complexity.
>> If we need to have three for some political reason I would have the
>> IdP treat the two multi-factor as equivalent in the request, and only
>> differentiated in the response.
>> Thoughts on paring it down to two?
>> John B.
>>
>> On Nov 27, 2015, at 2:19 PM, Lodderstedt, Torsten
>> <t.lodderstedt at telekom.de <mailto:t.lodderstedt at telekom.de>> wrote:
>> As a RP, I would prefer to send the minimal level I would like
>> the OP to fulfill, e.g. mc2, and I would accept if the OP did
>> better, i.e. authenticated using mc3.
>> I think it is evenly important to be clear on the meaning of the
>> levels. Otherwise, the RP does not know what to expect and the OP
>> does not know exactly know what to implement.
>> Best regards,
>> Torsten.
>> *Von:*John Bradley [mailto:jbradley at mac.com]
>> *Gesendet:*Freitag, 27. November 2015 15:14
>> *An:*Lodderstedt, Torsten
>> *Cc:*philippe.clement at orange.com
>> <mailto:philippe.clement at orange.com>;openid-specs-mobile-profile at lists.openid.net
>> <mailto:openid-specs-mobile-profile at lists.openid.net>
>> *Betreff:*Re: [Openid-specs-mobile-profile] ACR values
>> That is not the normal behaviour for Connect when using the query
>> parameter.
>> We had much debate at the time.
>> We can achieve that with server side policy however.
>> What I think people want is to send a list in preference order
>> eg [ “mc-2”, “mc-3” ]
>> The IdP must try to do the highest one in the list that the users
>> device supports, if that fails then the IDP will return an error.
>> That is the semantic if you use make it an essential claim in the
>> request object.
>> Normally if the device only supported “mc-1” or “mc-4" the IdP
>> could try that and return it if successful.
>> I suppose that we could say that if the user can be authenticated
>> at a higher level by the IdP it can do that and return a lower
>> level from the requested list.
>> This is probably more important to be clear on than the levels
>> themselves in some ways.
>> Is that the behaviour we want to require of the IdP?
>> John B.
>>
>> On Nov 27, 2015, at 8:51 AM, Lodderstedt, Torsten
>> <t.lodderstedt at telekom.de <mailto:t.lodderstedt at telekom.de>>
>> wrote:
>> >If the IdP cant supply one of the acr values by getting the
>> user to step up then it must return a failed
>> authenticationattempt.
>> I think this is the desired behavior for MODRNA
>> _______________________________________________
>> Openid-specs-mobile-profile mailing list
>> Openid-specs-mobile-profile at lists.openid.net
>> <mailto:Openid-specs-mobile-profile at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
>>
>> _______________________________________________
>> Openid-specs-mobile-profile mailing list
>> Openid-specs-mobile-profile at lists.openid.net
>> <mailto:Openid-specs-mobile-profile at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
>>
>
>
>
> _______________________________________________
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20151129/d2c66964/attachment-0001.html>
More information about the Openid-specs-mobile-profile
mailing list