Over at Gartner, Mark Diodati had a recent blog post regarding issues that are surfacing as part of Gartner's research into Mobility. Two particular items in the blog post caught my eye:
"Many organizations make the classic distribution mistake; they couple a weak identity proofing mechanism with the deployment of stronger authentication systems"
"I have seen many organizations try to fix the identity proofing problem after deployment because they have little confidence that the OTP secrets are in the hands of authorized users."
This brought to mind some discussions that I've been part of regarding the use of tokens at varying levels of assurance and assurance level escalation mechanisms.
Whenever you start down this path, it is often worthwhile to step back and look at the Registration, Credential Issuance and Maintenance sections of the Electronic Authentication Model (from NIST SP-800-63-1 PDF):
As you can see above, you have an Applicant that registers with a Registration Authority (RA), which identity proofs the Applicant and confirms the results of that event with a Credential Service Provider (CSP). The CSP in turn interacts with the Applicant to issue a Credential that binds the identity of the person to a Token (a secret, or something that holds a secret used in a remote authentication protocol). At this point in time the Applicant becomes a Subscriber of the CSP. The rest of the model focuses on the use of the credential and token.
While the RA and CSP functions, especially in the commercial world, are often done by the same entity, the key point to keep in mind is that Registration, Identity Proofing, Token Creation/Issuance and Credential Issuance are all distinct and logically separate processes that can be broken up into separate physical encounters or online/electronic transactions. Point of fact, they could be broken up and fulfilled by entirely separate entities. The challenge in this, as noted in Mark's blog entry, is to make sure that the same party is acting as the Applicant through the process.
A model to look at and potentially implement [1] that may help in this area is what we use within the US Government for credential issuance at Level of Assurance (LOA 1 - 4). We have increasingly stringent requirements (as we move from Level 1 to 4) that we need to follow in order to make sure that the same Applicant is moving through the process (More details in NIST 800-63-1):
- At Level 1: There is no specific requirement, however some effort should be made to uniquely identify and track applications.
- At Level 2: For electronic transactions, the Applicant shall identify himself/herself in any new transaction (beyond the first transaction or encounter) by presenting a temporary secret which was established during a prior transaction or encounter, or sent to the Applicant’s phone number, email address, or physical address of record.
- At Level 3: For electronic transactions, the Applicant shall identify himself/herself in each new electronic transaction by presenting a temporary secret which was established during a prior transaction or encounter, or sent to the Applicant’s physical address of record. Permanent secrets shall only be issued to the applicant within a protected session.
- At Level 4: Only physical transactions apply.
Ultimately, whatever types of credentials you are issuing, and in whatever modalities that credential is being used, if you cannot have confidence in the processes used to assure that the person using the credential is indeed the person that went through the above steps to get the credential, then you have gained little to no value by choosing to issue a technically "stronger" credential type.
[1] For those reading this from USG Agencies: The choice to implement or not does not exist for us :-). OMB Policy on Annual FISMA Guidance M-11-33 (PDF) makes implementation of NIST Guidance a requirement.
:- by Anil John
