Progressive Authentication

From MgmtWiki
Revision as of 16:51, 17 June 2018 by Tom (talk | contribs) (Solutions)

Jump to: navigation, search

Full Title or Meme

When the exact nature of the user request is unknown, 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

Then general use case[1] is where trust elevation must occur at some time during the a long term engagement, as when as user first goes to a site to get information, investigates the options and then decides to commit to the 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 the Bell-LaPadula model with 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 talk 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 device 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]

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 in now in the third update to their Digital Identity Guidelines [5] where they still insist, against all evidence to the contrary that "digital identity is the unique representation of a subject engaged in an online transaction." It is a fact, acknowledged in that publication that user will have different personas for email versus banking. 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 should not be considered as any reason to abandon 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 to move on with the next generation of solution.

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 on such use case:

  1. The user contacts the web site to determine if that is the service that will meet their needs.
    1. The user may be given the option to provide some means of payment or authorization and remain otherwise anonymous with no continuity from on interchange to the next.
  2. 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.
    1. 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.

References

  1. Tom Jones Trust Elevation Use Case https://wiki.idesg.org/wiki/index.php?title=Trust_Elevation_Use_Case
  2. Donald MacKenzie, Mechanizing Proof: Computing, Risk and Trust, MIT Press ISBN 0-262-13393-8
  3. Oriana Riva +3 Progressive authentication: deciding when to authenticate on mobile phones Published in: Proceedings Security'12 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
  4. Jeffrey Warren, +3, Progressive Authentication on Android https://css.csail.mit.edu/6.858/2013/projects/jtwarren-vkgdaddy-vedha-vvelaga.pdf
  5. NIST Digital Identity Guidelines https://doi.org/10.6028/NIST.SP.800-63-3