Scope and Structure of Authentication Assurance Levels

The trust requirements in electronic communication involving multiple independent parties need to be standardized to allow secure many-to-many trust relationships. In fact, to allow for good scalability, policies and capabilities must be negotiated automatically. The different contributors to this field have overlapping, but different scope definitions for their various policies and frameworks. To give a quick introduction, see following incomplete 

  •  NIST 800-63:
    Remote authentication of individual people to establish trust in user identities
  • STORK:
    Make different electronic authentication schemas across Europe interoperable
  •  EUGridPMA:
    Define policies for authorities issuing identity assertions for Grid Authentication
  • ISO 29115 provides a framework for entity authentication assurance. Authentication is defined as the process of corroborating an identity or attribute with a specified or understood level of assurance.

To get a better understanding of the different requirements I started to create a common model of these frameworks. The model’s scope includes multi-level security frameworks and single-level policies such as certificate policies, legal regulation for certain classes of signatures and domain-specific policies for remote user identity and access management.

The model shall help to answer following questions:

  • How can authentication profiles from different frameworks be mapped into each other?
  • How complete is the specification of a particular authentication profile in comparison to the whole?
  • Given a range of security controls from very loose to very strict, what are positions of the lowest and highest level? How can this be justified with a risk/value-based method?
  • How can existing authentication policies be updated to improve consistency and comprehensibility?
  • How can I use a standardized risk management model to evaluate if the selected controls within a assertion level are appropriate and balanced?

Preliminary findings

Separation of requirements and solutions

Although the authentication policies seem to be very practical, the lack of throughout separation between requirements and solutions (objectives and controls) makes it difficult to map policies to each other. A more formalized modeling can improve that to a good extent, but finally it would be desirable if the policy writers would adopt a common model of the type that is described here.

Scope considerations

  • NIST and STORK are limited to prove the identity of the user. This seems too narrow, because to protect the data properly, it must be guaranteed that only the authenticated user has access to the resource to which access was granted. This is a minor extension to pure authentication, nonetheless an important one. E.g. it is not enough to have a robust session binding to the user, but the payload data in the session must be protected as well.
  • Most frameworks are silent on privilege management. In the context of federations however, a relying party will frequently have to trust an attribute provider, a CSP-class role, or the user home organization to provide attributes that are user for access decisions. Proper policies in this area are important to make federations scalable.
  • NIST is excluding non-human agents and systems, which is not practical I today's SOA.

Inconsistent or missing Controls

  •   STORK: There is an issue with some registration options on  assurance levels 2 and 3, that seem so weak that they would downgrade the respective level. It needs to be clarified if this is intentional, given to misunderstanding or an error.
  •  There are numerous protection requirements that are not addressed in all frameworks. This will need further investigation.
  •  In general ISMS (information security management systems) like ISO 27000 are nowhere required, with only loose or partial controls.

 The scope of the model encompasses session-based, message-based and document-centric electronic exchanges, like interactions with web browsers, web services and digital signatures on static documents.