Progressive Authentication - Revision history

Tom: /* Context */

2025-07-01T16:50:10Z

‎Context

Tom: /* Context */

2021-04-14T00:07:00Z

‎Context

Tom: /* Problems */

2018-09-07T23:27:54Z

‎Problems

Tom: /* Problems */

2018-09-07T23:15:12Z

‎Problems

Tom: /* Problems */

2018-09-07T23:13:39Z

‎Problems

Tom: /* Problems */

2018-09-07T23:11:12Z

‎Problems

Tom: /* Context */

2018-09-07T23:04:29Z

‎Context

Tom: /* References */

2018-09-07T22:58:52Z

‎References

Tom: /* References */

2018-09-07T22:57:53Z

‎References

Tom: /* Solutions */

2018-07-31T16:25:47Z

‎Solutions

@@ Line 6: / Line 6: @@
 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 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.
+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 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]]''

@@ Line 8: / Line 8: @@
 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 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''
+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.

@@ Line 17: / Line 17: @@
 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. If an attacker has been able to compromise the initial connection, they will be able to see the upgrade and "follow" the user to the next higher security level.
+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==

@@ Line 19: / Line 19: @@
 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. If an attacker has been able to compromise the initial connection, they will be able to see the upgrade and "follow" the user to the next higher security level.
-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.
+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.
 ==Solutions==

@@ Line 19: / Line 19: @@
 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. If an attacker has been able to compromise the initial connection, they will be able to see the upgrade and "follow" the user to the next higher security level.
-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 progressive more capable of accessing highly secured [[Resource]]s.
+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.
 ==Solutions==

← Older revision		Revision as of 23:11, 7 September 2018
Line 18:		Line 18:

	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. If an attacker has been able to compromise the initial connection, they will be able to see the upgrade and "follow" the user to the next higher security level.		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. If an attacker has been able to compromise the initial connection, they will be able to see the upgrade and "follow" the user to the next higher security level.
		+
		+	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 progressive more capable of accessing highly secured [[Resource]]s.

	==Solutions==		==Solutions==

@@ Line 4: / Line 4: @@
 ==Context==
-The general use case<ref>Tom Jones ''Trust Elevation Use Case'' 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.
+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 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.

@@ Line 47: / Line 47: @@
 <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.
+* 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]]

← Older revision		Revision as of 16:25, 31 July 2018
Line 42:		Line 42:


−	Another class 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.	+	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==