Difference between revisions of "Progressive Authentication"
(→Problems) |
(→Problems) |
||
| (40 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
| − | When the exact nature of the user request is | + | When the exact nature of the user request is not well-known, it is best to try [[Authentication]] in the least obtrusive manner, which is typically not at the highest level they might need later in the interchange. |
==Context== | ==Context== | ||
| − | + | The general use case<ref>Tom Jones ''Trust Elevation Use Case'' (2014-11-01) IDESG Wiki https://wiki.idesg.org/wiki/index.php?title=Trust_Elevation_Use_Case</ref> is where trust elevation will occur at some time during a long term engagement, as when a user first goes to a site to get information, investigates the options and then decides to commit to a service offering that requires stronger identity in order to qualify for access to some resource, such as a state sponsored benefit. | |
| − | An anti-use case was discovered when the NSA funded the Blacker System<ref>Donald MacKenzie, Mechanizing Proof: Computing, Risk and Trust, MIT Press ISBN 0-262-13393-8</ref> which attempted to use the Bell-LaPadula model | + | An anti-use case was discovered when the NSA funded the Blacker System<ref>Donald MacKenzie, Mechanizing Proof: Computing, Risk and Trust, MIT Press ISBN 0-262-13393-8</ref> which attempted to use Mandatory Access Control with the Bell-LaPadula model for computer networking. Development started in 1984, it was certified in 1991. It became clear that security was given such precedence over usability that soldiers in the field would be forced to authenticate to their devices before they could answer a call on them. It was obvious when tested that no one had bothered to ask if this user experience was acceptable to a soldier in the field. The cautionary tale here is that following a set of rules created without thought of user experience is unlikely to ever be deployable. |
| − | When mobile | + | When mobile devices became common it was early realized that any solution forcing a single mode of authentication was not feasible and progressive authentication was proposed<ref>Oriana Riva +3 ''Progressive authentication: deciding when to authenticate on mobile phones'' Published in: Proceedings of the 21st USENIX conference on Security symposium Pages 15-15 Bellevue, WA August 08 - 10, 2012, http://feihu.eng.ua.edu/NSF_CPS/year1/SP_paper1.pdf</ref> for mobile devices and later specifically for Android devices.<ref>Jeffrey Warren, +3, ''Progressive Authentication on Android'' https://css.csail.mit.edu/6.858/2013/projects/jtwarren-vkgdaddy-vedha-vvelaga.pdf</ref> NIST SP 1800-13 is now in draft form<ref>NIST SPECIAL PUBLICATION 1800-13B ''Mobile Application Single Sign-On'' |
| + | https://www.nccoe.nist.gov/publication/1800-13/VolB/index.html</ref> with guidelines on high-security rules for Improving Authentication for Public Safety First Responders, a group with similar UX requirements to warfighters. | ||
An alternative definition of progressive authentication is a suite of authentication tests which can be selected to be run at a single time with a [[Trust Vector]] that can be tested by the authorization service. While this does provide some flexibility, it still presumes that required level of authentication be known at initial connection. This might work for systems that are wholly risk based with a captive audience, but will not work for users who have any choice in the selection of their providers. | An alternative definition of progressive authentication is a suite of authentication tests which can be selected to be run at a single time with a [[Trust Vector]] that can be tested by the authorization service. While this does provide some flexibility, it still presumes that required level of authentication be known at initial connection. This might work for systems that are wholly risk based with a captive audience, but will not work for users who have any choice in the selection of their providers. | ||
| Line 14: | Line 15: | ||
==Problems== | ==Problems== | ||
NIST is now in the third update to their ''Digital Identity Guidelines'' <ref>NIST ''Digital Identity Guidelines'' https://doi.org/10.6028/NIST.SP.800-63-3</ref> where they still insist, at least for government | NIST is now in the third update to their ''Digital Identity Guidelines'' <ref>NIST ''Digital Identity Guidelines'' https://doi.org/10.6028/NIST.SP.800-63-3</ref> where they still insist, at least for government | ||
| − | purposes, that "digital identity is the unique representation of a subject engaged in an online transaction." But it is a fact, acknowledged in that publication that | + | purposes, that "digital identity is the unique representation of a subject engaged in an online transaction." But it is a fact, acknowledged in that publication, that users will have different personas, for example, for email versus banking, if not for various interaction with the government. Imposition of privacy obligations makes it clear that users must not be expected to offer detailed attributes of their life which are not needed for the transaction at hand, so there can be no expectation that any online representation of a user is anything other that what they are willing to release. While any [[Relying Party]] may insist on a high level of assurance as to the validity of the attributes provided by the user, in most cases those parties are willing to accept whatever assurances the user may offer, or the user will just go elsewhere. This need for multiple personas should not be considered as any reason to ignore the current NIST publications. As of May 2018 these publications are still the best available benchmark for authenticating users on the internet. Still it is time for industry to acknowledge their needs, and the privacy regulations, require more flexibility. A quick summary of the levels is at this [https://wiki.idesg.org/wiki/index.php?title=Design_Pattern%3A_Selecting_an_Identity#Relationship_to_NIST_800-63_Digital_Authentication_Guideline_.28Levels_of_Assurance.29 site]. |
| + | |||
| + | Security versus usability seems to always create the most intractable difficulties. Consider the issue of creating a connection between two system with minimal security, and then upgrading the level of security by adding additional authentication factors. There is a risk in the use of [[Progressive Authentication]] for if an attacker is able to gain access when a low level of [[Assurance]] is used, they might be able to "piggy-back" on an existing connection as it gets progressively more capable of accessing highly secured [[Resource]]s. This threat can be reduced by always using HTTPS from the source to the destination of the connection from the very first web page displayed to the [[User]]. | ||
==Solutions== | ==Solutions== | ||
| Line 20: | Line 23: | ||
| − | The following is | + | The following is a class of use cases with a time line about how that user interaction might progress and the problems that could ensue: |
# The user contacts the web site to determine if that is the service that will meet their needs. | # The user contacts the web site to determine if that is the service that will meet their needs. | ||
## The user may be given the option to provide some means of payment or authorization and remain otherwise anonymous with no continuity from one interchange to the next. | ## The user may be given the option to provide some means of payment or authorization and remain otherwise anonymous with no continuity from one interchange to the next. | ||
| Line 29: | Line 32: | ||
## At a protocol level the user has two or three claims in the authorization request:an anonymized user-name and some means to contact the user when required by future events, such as a breach. | ## At a protocol level the user has two or three claims in the authorization request:an anonymized user-name and some means to contact the user when required by future events, such as a breach. | ||
# Access to more privileged parts of the site may require the user to enter additional authentication in the form of either: (1) a payment card, (2) an additional authentication factor, either of which provide more assurance. | # Access to more privileged parts of the site may require the user to enter additional authentication in the form of either: (1) a payment card, (2) an additional authentication factor, either of which provide more assurance. | ||
| − | ## | + | ## At a protocol level the user just as more claims that can be collected for use in an authorization request, most of which will be consider to be personal information. |
| + | ## But any progression to higher levels of security cannot continue any network connection that might be compromised. But user experience would insist that continuity of connections is the best UX. Solutions might be: | ||
| + | ### Network security must be established at the beginning of a session and maintained throughout the entire interchange, or | ||
| + | ### The network connection must be re-established every time the user moves to a higher security level without the user being unduly challenged. | ||
| + | # The user may try to perform some action which requires specific [[Authorization]] based on some [[Attribute]] of the [[User]] that is contingent of a variety of factors which must also be true. Example use cases are: | ||
| + | ## The user is an EMT that is only permitted to ask for user health data during their shift, or when that are using a communications device inside of an ambulance. | ||
| + | ## The user is required to provide [[Proof of Possession]] of some [[Trusted Execution Environment]] that could be a smart card, a FIDO U2F security key, or a personal computer/phone that has been properly secured. | ||
| + | ## The physician can only prescribe drugs if there is a current DEA certificate on file with the prescribing pharmacy (this may even be further split by the specific class of the drug). | ||
| + | |||
| + | |||
| + | Another class of use cases is provided by a [[Distributed Identity]] which is designed for a [[Relying Party]] to query a [[User Agent]] to get the specific type of identity provided. This is a different paradigm than having the [[Relying Party]] drive the selection of [[Identifier or Attribute Provider]]s by offering the [[User]] a list to chose from, as is the dominate current paradigm. | ||
==References== | ==References== | ||
| + | <references /> | ||
| + | |||
| + | * Verizon uses the name [https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/white-papers/en/3139-securing-your-enterprise.pdf contextual MFA] for a very similar concept in their 2016 Data Breach Ivestigations Report. | ||
| + | [[Category:Glossary]] | ||
| + | [[Category:Authentication]] | ||
Revision as of 16:27, 7 September 2018
Full Title or Meme
When the exact nature of the user request is not well-known, it is best to try Authentication in the least obtrusive manner, which is typically not at the highest level they might need later in the interchange.
Context
The general use case[1] is where trust elevation will occur at some time during a long term engagement, as when a user first goes to a site to get information, investigates the options and then decides to commit to a service offering that requires stronger identity in order to qualify for access to some resource, such as a state sponsored benefit.
An anti-use case was discovered when the NSA funded the Blacker System[2] which attempted to use Mandatory Access Control with the Bell-LaPadula model for computer networking. Development started in 1984, it was certified in 1991. It became clear that security was given such precedence over usability that soldiers in the field would be forced to authenticate to their devices before they could answer a call on them. It was obvious when tested that no one had bothered to ask if this user experience was acceptable to a soldier in the field. The cautionary tale here is that following a set of rules created without thought of user experience is unlikely to ever be deployable.
When mobile devices became common it was early realized that any solution forcing a single mode of authentication was not feasible and progressive authentication was proposed[3] for mobile devices and later specifically for Android devices.[4] NIST SP 1800-13 is now in draft form[5] with guidelines on high-security rules for Improving Authentication for Public Safety First Responders, a group with similar UX requirements to warfighters.
An alternative definition of progressive authentication is a suite of authentication tests which can be selected to be run at a single time with a Trust Vector that can be tested by the authorization service. While this does provide some flexibility, it still presumes that required level of authentication be known at initial connection. This might work for systems that are wholly risk based with a captive audience, but will not work for users who have any choice in the selection of their providers.
Problems
NIST is now in the third update to their Digital Identity Guidelines [6] where they still insist, at least for government purposes, that "digital identity is the unique representation of a subject engaged in an online transaction." But it is a fact, acknowledged in that publication, that users will have different personas, for example, for email versus banking, if not for various interaction with the government. Imposition of privacy obligations makes it clear that users must not be expected to offer detailed attributes of their life which are not needed for the transaction at hand, so there can be no expectation that any online representation of a user is anything other that what they are willing to release. While any Relying Party may insist on a high level of assurance as to the validity of the attributes provided by the user, in most cases those parties are willing to accept whatever assurances the user may offer, or the user will just go elsewhere. This need for multiple personas should not be considered as any reason to ignore the current NIST publications. As of May 2018 these publications are still the best available benchmark for authenticating users on the internet. Still it is time for industry to acknowledge their needs, and the privacy regulations, require more flexibility. A quick summary of the levels is at this site.
Security versus usability seems to always create the most intractable difficulties. Consider the issue of creating a connection between two system with minimal security, and then upgrading the level of security by adding additional authentication factors. There is a risk in the use of Progressive Authentication for if an attacker is able to gain access when a low level of Assurance is used, they might be able to "piggy-back" on an existing connection as it gets progressively more capable of accessing highly secured Resources. This threat can be reduced by always using HTTPS from the source to the destination of the connection from the very first web page displayed to the User.
Solutions
The best solution is one that asks the user only for sufficient attributes to complete the simplest tasks on the relying party web site. As more verification of the user's trustworthiness are required because of the user's request to access protected information, the authentication of the user can progress as those desire of the user are made known.
The following is a class of use cases with a time line about how that user interaction might progress and the problems that could ensue:
- The user contacts the web site to determine if that is the service that will meet their needs.
- The user may be given the option to provide some means of payment or authorization and remain otherwise anonymous with no continuity from one interchange to the next.
- When the user determines that the site is appropriate and that a connection that survives from one interchange to the next, some registration process is required.
- The most basic form of registration requires that the user select a user-name, a means of authentication and a means to recover access if lost for any reason. The only personal information required is in the contact data.
- An alternate if for the user to have the option to select one of the various social networks (Google, Microsoft, Facebook, etc.) to provide authentication as well as a anonymized user name, possibly non-trackable.
- At this point the user can sign into the web site whenever it is wished and the potential for tracking is limited to the
- At a protocol level the user has two or three claims in the authorization request:an anonymized user-name and some means to contact the user when required by future events, such as a breach.
- Access to more privileged parts of the site may require the user to enter additional authentication in the form of either: (1) a payment card, (2) an additional authentication factor, either of which provide more assurance.
- At a protocol level the user just as more claims that can be collected for use in an authorization request, most of which will be consider to be personal information.
- But any progression to higher levels of security cannot continue any network connection that might be compromised. But user experience would insist that continuity of connections is the best UX. Solutions might be:
- Network security must be established at the beginning of a session and maintained throughout the entire interchange, or
- The network connection must be re-established every time the user moves to a higher security level without the user being unduly challenged.
- The user may try to perform some action which requires specific Authorization based on some Attribute of the User that is contingent of a variety of factors which must also be true. Example use cases are:
- The user is an EMT that is only permitted to ask for user health data during their shift, or when that are using a communications device inside of an ambulance.
- The user is required to provide Proof of Possession of some Trusted Execution Environment that could be a smart card, a FIDO U2F security key, or a personal computer/phone that has been properly secured.
- The physician can only prescribe drugs if there is a current DEA certificate on file with the prescribing pharmacy (this may even be further split by the specific class of the drug).
Another class of use cases is provided by a Distributed Identity which is designed for a Relying Party to query a User Agent to get the specific type of identity provided. This is a different paradigm than having the Relying Party drive the selection of Identifier or Attribute Providers by offering the User a list to chose from, as is the dominate current paradigm.
References
- ↑ Tom Jones Trust Elevation Use Case (2014-11-01) IDESG Wiki https://wiki.idesg.org/wiki/index.php?title=Trust_Elevation_Use_Case
- ↑ Donald MacKenzie, Mechanizing Proof: Computing, Risk and Trust, MIT Press ISBN 0-262-13393-8
- ↑ Oriana Riva +3 Progressive authentication: deciding when to authenticate on mobile phones Published in: Proceedings of the 21st USENIX conference on Security symposium Pages 15-15 Bellevue, WA August 08 - 10, 2012, http://feihu.eng.ua.edu/NSF_CPS/year1/SP_paper1.pdf
- ↑ Jeffrey Warren, +3, Progressive Authentication on Android https://css.csail.mit.edu/6.858/2013/projects/jtwarren-vkgdaddy-vedha-vvelaga.pdf
- ↑ NIST SPECIAL PUBLICATION 1800-13B Mobile Application Single Sign-On https://www.nccoe.nist.gov/publication/1800-13/VolB/index.html
- ↑ NIST Digital Identity Guidelines https://doi.org/10.6028/NIST.SP.800-63-3
- Verizon uses the name contextual MFA for a very similar concept in their 2016 Data Breach Ivestigations Report.
