9.2
The Problem of ‘Authentication’
The Authenticator pattern [BF99] presents a technical solution to the problem of authentication with a remote service. This section details how a Sif problem spe- cification for this problem can be constructed. Problems in Sif are modelled as sets of requirements that are indexed by the domain of operations in which the problem occurs. The full specification is presented at the end of this section in Listing 9.3, and Chapter 5 §5.4.2 details the Sif DSL used.
9.2.1
Problem Declaration
The problem of authentication can be summarised as:
Given two entities Alice and Bob, how can Bob authenticate with Alice such that Alice knows that Bob is who he says he is.
Authentication mechanisms are used to provide assurances over the identity of an entity; or provenance of an object. When modelling problems with Sif we must first declare the existence of the problem and then provide the problem’s requirements. Listing 9.1 provides the initial declaration of the authentication problem. Sif only allows for a single problem to be specified per file. The declaration on Line 1 informs the Sif evaluator that a problem specification is being declared. When declaring problems within a specification, the type of specification needs to be specified before the problem instance itself can be given. Line 5 provides the declaration of the problem itself. The left arrow (<-) declares and initialises the symbolic representation of the problem. Right of the arrow is the type declarationProblem, and right of the type declaration is
the title associated with the symbol. This notation is used throughout the problem declaration to assign values to symbols.
1 sif p r o b l e m 2 3 > How to a u t h e n t i c a t e e n t i t i e s such t h a t a s s u r a n c e s 4 > can be made o f t h e i r i d e n t i t y . 5 authentication <- P r o b l e m " Authentication "
Listing 9.1: Initial problem declaration for modelling the problem ofAuthentication
9. Engineering Patterns for Authentication
Preceding the problem declaration is the corresponding textual description for the problem presented as Sif documentation. Model documentation is indicated using ‘Bird’ notation i.e. the ‘>’ operator.
9.2.2
Contexts of Operation
With the problem itself declared, the domains of operation can now be defined. Existing literature has already provided a corpus of patterns that illustrate the various contexts in which authentication can occur [ESP07; FS03; FW03; Fer07; AF10; MF06; Wei06]. These identified patterns illustrate that the problem of authentication exists in a myriad of contexts. For this tutorial five different contexts were identified:
• Local Technical: How to perform authentication locally between entities without human assistance. For example,Firmware Signingis a means for devices
to authenticate software locally on a machine.
• Remote Technical: How to perform authentication remotely between entit- ies without human intervention. For example,Certificate-Based SSH Loginis
an automatic authentication mechanism to allow two devices to communicate. • Local Socio-Technical: How to perform authentication locally between
entities that require human involvement. For example, password based device authentication.
• Remote Socio-Technical: How to perform remote authentication between entities that require human involvement. For example, device pairing requires human involvement to enter a ‘pairing code’ to allow two devices to pair with one another.
• Societal: How to perform authentication between entities that does not re- quire technology. For example, shibboleth’s and code phrases are challenge- response mechanisms used to allow agents to authenticate with each other without the need for technology.
Listing 9.2 shows how these contexts are declared in the specification file. The syntax required for context declaration follows that for problem declarations. However, the type differs and specifies that the resulting object is of typeContext. For each context
9.2. The Problem of ‘Authentication’
1 socio <- C o n t e x t "Non - Technical "
2 sociotechLocal <- C o n t e x t " Local Socio - Technical "
3 sociotechRemote <- C o n t e x t " Remote Socio - Technical "
4 techLocal <- C o n t e x t " Local Technical "
5 techRemote <- C o n t e x t " Remote Technical "
Listing 9.2: Modelling of contexts in which authentication can take place in Sif. defined, an identifier is required and an explanatory title. Each context can be docu- mented, if the modeller wishes to provide more information. During model evaluation, contexts are automatically assigned to the presented problem when presented with a solution for a specified context.
9.2.3
Requirements
Next comes specification of requirements detailing aspects of the problem that the solu- tion must address. For the problem of authentication, one possible set of requirements can be:
• Proof of Authenticity: A proof is required that will attest to the authenticity of an entity.
• EnrolmentSolutions must have a means to enrol entities into the authentica- tion procedure and provide them with proof of identity.
• Authentication Step: Solutions must have an authentication step in which the proof of an entity’s identity will be tested.
• Changeable: The means of authentication must be changeable and re-enrolment possible.
• Consistent: The act of authentication must be consistent and each authentica- tion act, if repeated, must have the same outcome.
• Timely: Processing authentication requests must be timely. Further, the dura- tion of the complete authentication process must be timely in its duration. • Lockout: Entities that repeatedly authenticate incorrectly should be denied the
right to authenticate for some predefined period of time.
9. Engineering Patterns for Authentication 1 sif p r o b l e m 2 3 > How to a u t h e n t i c a t e e n t i t i e s such t h a t a s s u r a n c e s 4 > can be made o f t h e i r i d e n t i t y . 5 authentication <- P r o b l e m " Authentication " 6
7 socio <- C o n t e x t "Non - Technical "
8 sociotechLocal <- C o n t e x t " Local Socio - Technical "
9 sociotechRemote <- C o n t e x t " Remote Socio - Technical "
10 techLocal <- C o n t e x t " Local Technical "
11 techRemote <- C o n t e x t " Remote Technical "
12
13 enrollment <- F u n c t i o n a l " Enrollment "
14 proof <- F u n c t i o n a l " Proof of Authenticity "
15 authStep <- F u n c t i o n a l " Authentication Mechanism ."
16 changeable <- F u n c t i o n a l " Changeable ."
17 consistent <- R e l i a b i l i t y " Authentication happens ."
18 timely <- P e r f o r m a n c e " Timely Authentication ."
19 lockout <- F u n c t i o n a l " Limited access attempts ."
20 effortless <- U s a b i l i t y " Effortless Authentication "
Listing 9.3: Sif Problem specification for the problem ofAuthentication.
Within Sif, types for requirements come from the Furps requirements model [Gra92]. This model categorises requirements as being related to one of the following concepts: Functional, Usability, Reliability, Performance, or Supportability. Allowing each re- quirement to be given a type that better describes the requirement being detailed. For example, the ‘consistent’ requirement is a reliability requirement rather than a purely functional one. Listing 9.3 lists the complete problem specification and also details the requirements for the problem together with their requirement types. For brevity, documentation for each requirement has not be given. With the problem specification given, the twopotentialsolutions can now be investigated.