[Openid-specs-mobile-profile] ACR values

John Bradley jbradley at mac.com
Wed Dec 2 02:01:04 UTC 2015


I pushed a series of updates to bitbucket to make it easier to back out the ones you do’t like.

I looked at PAPE again and tried basing the three acr values on that for for the sake of argument.   We can refine the names and descriptions.

I wanted to try and tie the amr in some meaningful way to risks mitigated.

Let me know.

I have an appointment first thing in the morning so probably won’t be able to make changes before the call.

John B.

> On Dec 1, 2015, at 1:42 PM, Lodderstedt, Torsten <t.lodderstedt at telekom.de> wrote:
> 
> Hi John,
>  
> your proposal sounds very good to me. Would you propose text for the authentication spec?
>  
> best regards,
> Torsten.
>  
> Von: John Bradley [mailto:jbradley at mac.com] 
> Gesendet: Sonntag, 29. November 2015 21:06
> An: Torsten Lodderstedt
> Cc: Lodderstedt, Torsten; openid-specs-mobile-profile at lists.openid.net
> Betreff: Re: [Openid-specs-mobile-profile] ACR values
>  
> Yes the document currently calls it singe factor, but that is probably to general.
>  
> This is one reason I prefer abstract names like silver and gold, that way as technology changes you don’t need to change the protocol.
>  
> So lets describe them and pick names after we agree on the description.
>  
> Silver:
> The user is authenticated via possession of a device (phone) containing a secret key. 
> The user is required to provide no additional authentication information to use the key.
> The user is interactively prompted to confirm the authentication. 
> The storage mechanism for the secret key and other relevant authentication information is returned via the ”amr” value.
> The user is not re-prompted if prompt is not login and max_age is more than the elapsed time since the user last authenticated at this acr
>  
> Gold:
> The user is authenticated via possession of a device (phone) containing a secret key. 
> The user is required to provide additional authentication information via a biometric, pin code or other appropriate factors such as bluetooth paring with a watch.
> Given suitable Mobile device management unlocking the device is also sufficient along with user confirmation of desire to authenticate.
> The storage mechanism for the secret key and other relevant authentication information is returned via the ”amr” value.
> The user is not re-prompted if prompt is not login and max_age is more than the elapsed time since the user last authenticated at this acr
>  
> Platinum:
> The user is authenticated via possession of a device (phone) containing a secret key.
> The user is required to provide additional authentication information via a local biometric, or a remote paring with a biometric capable device. 
> A pin or second biometric as a third factor may also be required.
> Biometric device unlock may be used, but only in conjunction with a pin code or second biometric.
> The user is always prompted to authenticate irrespective of the values of prompt and max_age.
>  
> So all 3 require possession of the phone.  Gold and Platinum require a second factor to unlock the phone.   
> Platinum forces the use of a pin or second biometric.
>  
> I put in Platinum for argument to show that it is additional risk mitigations that we are interested in,  
> as a single biometric like facial on a phone can be spoofed quite easily. (talking to Knock Knock they didn’t find any that they had confidence in as part of UAF if the attacker had a photo of the subject’s face)
>  
> So in the ACR
> [ “Platinum”, “Gold”, “Silver”]  would cause the device to do the highest one posable but if it is incapable fall back to a lower one.
>  
> If we leave the ACR query parameter as is rather than changing it to essential then 
>  
> [ “Platinum” ] would do exactly the same thing.
>  
> If we add the essential semantic to the ACR values then
> [ “Platinum” ]  would return an error if the device can’t support a biometric.  You would need to always list them all unless you are willing to get an error.
>  
> That is my best attempt at trying to describe the scale of risk mitigation represented by the ACR that we are talking about.
>  
> John B.
>  
>  
>  
> On Nov 29, 2015, at 3:30 PM, Torsten Lodderstedt <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>> wrote:
>  
> 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 <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 <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 authentication attempt.
>  
> 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 <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 <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 <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 <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/20151201/58d7b484/attachment-0001.html>


More information about the Openid-specs-mobile-profile mailing list