- Email: [email protected]
Use of a formal description technique in the specification of authentication protocols
203
Use of a Formal Description Technique in the Specification of Authentication Protocols Vijay V A R A D H A R A J A N Hewlett-Packard Labs., Filton Road, Stoke Gifford, Bristol BS12 6QZ, UK
Formal specification techniques have been employed o v e r the past decade or so by various workers in data communication and computer network systems in order to provide both definitional specifications of protocols and models of protocols for analytic purposes. This paper considers the use of the specification language LOTOS (Language of Temporal Ordering Specification) for specifying some authentication protocols developed in the security field. The language LOTOS recently became an International ISO Standard and the protocols specified form part of the ISO and CCITT Standards. In fact, the CCITT protocol which is considered in this paper, has been used in the LOCATOR (X.400 Secure Mail) project within HPLabs. We first give a brief introduction to LOTOS and then specify two security protocols from ISO/DP 9798 and CCITT x.509 Standards. We feel that a formal specification of protocols is a useful and a necessary step towards understandability, analysis and implementation of the protocols. Further, we feel that LOTOS possesses the necessary features required for specifying such protocols, Keywords: Authentication, CCITT X. 509, Computer network
systems, Data communication, Formal specification, ISO/DP 9798, LOTOS, Modeling, Protocols, x.400~
k
Vijay Varadharajan is a Project
Manager at the Bristol Information Systems Centre of Hewlett-Packard Labs., U.K., doing research in security in distributed systems. He obtained his Ph.D. in the area of security in 1984. Since then he has been a member of Staff at the Dept. of Computer ~ Science, Reading University and has worked as a Research Manager at the British Telecom Research Laboratories in Ipswich, U.K. His research interests include security, formal specification and modelling techniques, object models and networks,
I
North-Holland Computer Standards & Interfaces 9 (1989/90) 203-215
1. Introduction Several formal specification languages have b e e n developed in recent years. These languages essentially differ in the emphasis they place o n concepts such as abstractness (how i m p l e m e n t a tion d e p e n d e n t they can be), c o n c u r r e n c y (how suitable they are for specifying parallel systems) a n d analysability (how readily specifications can be verified). It is the application area which p r i m arily determines the appropriateness of the language. O n e i m p o r t a n t area is that of c o m m u n i c a tion systems which present technical challenges due to the i n h e r e n t c o n c u r r e n c y and distributedness. Protocols play an i m p o r t a n t role in c o m p u t e r networks a n d distributed systems. The complexity of such protocols is c o n t i n u o u s l y increasing which in t u r n implies that more a n d more powerful techniques to develop them are necessary. Description of the protocol forms a n i m p o r t a n t part of the d e v e l o p m e n t process. Initial descriptions provide a c o m m o n frame of reference allowing cooperation a m o n g designers of different parts of a protocol. Descriptions also play a vital role in the verification process. T h e protocol design must be verified for logical correctness before implementation. Here we consider a formal specification language L O T O S developed by the I n t e r n a t i o n a l S t a n d a r d s O r g a n i z a t i o n (ISO) [1] for specifying some a u t h e n t i c a t i o n protocols. In Section 2, a brief overview of the language L O T O S is given. Section 3 describes the specification of a peer entity a u t h e n t i c a t i o n protocol using a symmetric e n c r y p t i o n technique. This protocol forms part of the I S O / D P 9798 S t a n d a r d [2]. In Section 4, an a u t h e n t i c a t i o n p r o t o c o l using a p u b l i c key cryptosystem is specified. This m e c h a n i s m forms part of the s t a n d a r d C C I T T X.509: The Direct o r y - A u t h e n t i c a t i o n F r a m e w o r k [3].
0920-5489/90/$3.50 © 1990, Elsevier Science Publishers B.V. (North-Holland)
204
V. Varadharajan / Formal Description Technique
2. L O T O S Formal Description Techniques (FDTs) are methods of defining the behaviour of a system in a language with a formal syntax and semantics, Some of the objectives to be satisfied by a F D T are as follows [1]: a. expressive power: ability to express a wide range of properties required for the description of services and protocols b. well-defined syntax and semantics: enabling mechanical manipulation, and validation c. well-structured: increasing understandability and maintainability of specifications d. abstraction: allowing representation of architectural aspects at a sufficiently high level of abstraction, where implementation details are not specified, LOTOS is a Formal Description Technique (FDT) that has been developed for the formal specification of open distributed systems, in particular those related to Open Systems Interconnection (OSI). LOTOS is based on process algebraic methods and does not use a (temporal) logical language, in contrast to what the name might appear to suggest. More specifically, LOTOS can be viewed to consist of two components, one dealing with the description of process behaviours and interactions and the other dealing with the description of data structures and value expressions. The former is based on CCS [4] and CSP [5] whereas the latter was inspired by the abstract data type technique ACT O N E [6]. We now give a very brief description of each of these two components of LOTOS. We will be only presenting some of the features of LOTOS that are necessary for our specification of authentication protocols in Sections 4 and 6. The reader is referred to [1] and [7] for detailed treatment. 2.1. L O T O S Process Model
In LOTOS, a system is modelled as a collection of processes interacting with each other. However, a process may contain several sub-processes, where a sub-process is a process in itself. Hence a system is essentially specified as a hierarchy of process definitions. A process in LOTOS is described in terms of its observable (communication) behaviour. This is done using language expressions that have primitive interactions called events.
An event consists of interaction points and a list of variables and values and events occur at points of interaction shared by processes, event gates. Events are assumed to be atomic, in the sense that they occur instantaneously, without consuming time. The processes that interact in an event must synchronize. That is, the processes that interact in an event must participate in its execution at the same moment in time, so that all variables in the event are simultaneously assigned values. Hence essentially, the LOTOS specification describes the potential order between the events, that can be observed at the interaction points. This description is a conjunction of atomic events and subprocesses, joined using the LOTOS operators. The basic operators in LOTOS which we mention here are the action prefix operator, the choice operator, the parallel operator and the guarding operator. Other operators include hiding, enabling, and disabling. For a detailed description of all these operators refer to [1] and [7]. The action prefix construct (;) enables the production of a new behaviour expression out of an existing one by prefixing it with an event name. Hence a ; B describes a process which first offers participation in event " a " and if it takes place then the behaviour of the process is given by the expression B. The choice operator ([ ]) allows to describe a process that behaves either like B1 or like B2, where B1 and B2 are behaviour expressions. The choice is resolved in the interaction of the process with the environment. To describe parallelism, LOTOS uses three operators which help to model three different types of concurrent processes, namely, asynchronous, synchronous and partially synchronous. The operator III denotes independent composition. It defines the behaviour of the composition as the arbitrary interleaving of the events of the subprocesses. B1 IIIB2 can participate in an event if B1 can participate in it, or B2 can participate in it. Any event that is refused by both B1 and B2 will not occur. The operator II defines the parallel composition of dependent subprocesses. B1 lIB2 can participate in an event if both B1 and B2 can participate in it. Hence it refuses any event that is refused by B1 or B2. The third parallel operator, called the general
1I.. Varadharajan / Formal Description Technique
parallel operator, is used to describe a composition between two subprocesses which must synchronize with respect to a set of events. For instance, B1 I[al, a2 . . . . , an] I B2 describes a composition in which b o t h processes B1 and B2 must synchronize with respect to the events al, a2, . . . , an. The guarding operator is a construct which allows to express conditional choice. If e is a boolean expression, then [e] ---, p means that the execution of p is only offered if the " g u a r d " e is true, else it is equivalent to stop - inactive process. We conclude this very brief section on process specification by mentioning a special event called the internal event. As the name implies, an internal event is "internal" to the process and is not observable. It is denoted by "i".
2.2. LOTOS Data Types Again, in this section, we very briefly mention some of the concepts involved in the data type specification. The interested reader should refer to [1] and [7] for more detailed treatment, In LOTOS, the representation of values, value expressions and data structures are derived from the algebraic specification method, A C T O N E . The algebraic specification technique derives its n a m e from its relationship to a form of abstract algebra called a heterogeneous or many-sorted algebra. A n abstract algebra consists of a none m p t y set (called carrier) and a set of n a m e d functions, each of which takes a finite n u m b e r of arguments from the carrier and maps them onto an element of the carrier. A heterogeneous algebra is one that has a set of n a m e d carriers, To define an abstract data type, one needs to define the names of data carriers and the operations. In L O T O S , the names of the data carriers are referred to as "sorts". The sorts and operations (opns) of a data type are referred to as the signature of that data type. The equations (eqns) define the axioms and axiom schema on the roodels of the operations, In order to facilitate the specification of systems with a large n u m b e r of operations and equations and complex data types features such as " r e n a m i n g " of data types, " p a r a m e t e r i z a t i o n " and " c o m b i n a t i o n " of specifications are provided in LOTOS.
205
2.3. Other Relevant Operations In this section, we briefly mention communication events. Recall that an event offer consists of event gate name, identifying the point of interaction and a finite list of attributes. There are two types of attributes: a value declaration and a variable declaration. A value declaration is a L O T O S expression describing a data value, preceded by an exclamation mark (e.g, !3). A variable declaration has the form ?x : t where x is the name of the variable and t is its sort identifier (e.g., ?x : integer). Let us now consider some typical interactions between processes. a. a!sl and a!s2 - T w o processes sharing an event gate may attach values to events and the corresponding event takes place if these values coincide (sl = s2). b. a?x : t and a!e - If two processes make complementary offers, i.e. one is prepared to accept any value of type t at a certain gate and the other is prepared to provide a value of e of the same type at the same gate, then the event m a y take place. c. a?x : tl and a?y : t2 (and tl = t2) - In this case, the actual value of the event that will occur is not determined by this model and hence this can be used to represent some sort of " v a l u e negotiation" between processes, where the actual mechanism determining the choice is not relevant or is unknown. The resulting value is referred to as " x " in one process and as " y " in the other.
3. Authentication Protocol Using Symmetric Encryption Technique In this section, we consider the use of L O T O S in the specification of a peer entity authentication protocol employing a symmetric encryption technique described in the ISO d o c u m e n t I S O / D P 9798 [2]. The Standard d o c u m e n t presents four a u t h e n t i c a t i o n e x c h a n g e m e c h a n i s m s . These mechanisms are defined by authentication exchanges employed for interactions between entities and the Authentication Server. They provide scope for key exchange prior to establishing a connection for data confidentiality service, and for the identification of entities' rights as part of an access control service. The mechanisms employ
206
V. Varadharajan / Formal Description Technique
any suitable n-bit symmetry key encryption algorithm rather than a specific one. In this section, we will be considering the specification of one such mechanism, namely the Authentication Exchange Mechanism IV, in LOTOS. We will be only describing the ideal behaviour. The objective of entity authentication is to assure an entity that the entity with which it communicates is the one claimed. Authentication may be unilateral or mutual. Here we are concerned only with the mutual authentication mechanism. The mechanism is defined via interactions between entities and the Authentication Server. It is assumed that the secret keys of the entities are known to the Authentication Server. We assume that the reader is familiar with the concept of authentication Server and its use in key distribution protocols.
~ ~
~
v
e r
~41)) (
2
)
~
Rec (7)
(1) KID (2) [IniI[RecIINRIIKID]A-r~c (3) [AI([[NR]I~r~
(4) "collect", [K I DIIR]A K
3.1. Authentication Exchange Mechanism
Suppose that an entity Initiator (Ini) wishes to have a conversation with an entity Receiver (Rec). The secret keys of Ini and Rec are known to the Authentication Server (AS). The steps involved in the authentication mechanism are as follows (see Fig. 1 ): Phase 1: Entity Ini establishes the conditions
to enable it to prove its identity and the timeliness of its communication to entity Rec. 1. Ini sends to Rec a number called the key reference number (KID) to initiate the authentication. 2. Rec sends an encrypted requests to the Authentication Server (AS)to generate authentication key. The request includes the identities Ini and Rec together with the received KID and a sequence number (NR) generated by Rec. The request is encrypted under Rec's secret key. 3. AS generates the authentication key (AK) and returns both AK and NR to Rec, encrypted under Rec's key. Rec knows that the message comes from AS since the secret key of Rec is only known to Rec and AS. Further, Rec can check that the message is not replayed by testing whether the sequence number in the message corresponds to its own. Phase 2: Entity Ini identifies itself to entity Rec and challenges Rec to prove its identity. 4. Rec sends a message to Ini containing the
(5) [Ini[[Rec[[NI[[l(ID]t~-ini (6) [aI(I[NI]h'ini (7) R
[X]k - denotes encryptionof X under key k. x I I Y - denotes concatenationof X and Y. Fig. 1. Exchange mechanism.
verifier which includes an encrypted version of a random number R generated by Rec and the key reference number KID. 5. Ini requests AS the authentication key, stored under the reference number KID, The request includes the identities Ini and Rec together with KID and a sequence number NI generated by Ini. The request is encrypted under the secret key of Ini. 6. AS uses KID to locate the authentication key and returns both AK and NI to Ini encrypted under the Ini's secret key. Ini decrypts the message to reveal the authentication key and also verifies the sequence number, to protect against replay. Phase 3: Entity Rec proves its identity to entity Ini. 7. Ini uses AK to decrypt the verifier of Rec and confirms that Rec knows the authentication key. Then Ini returns the random number R to Rec which confirms to Rec that Ini knows the authentication key.
V. Varadharajan / Formal Description Technique
4. L O T O S Specification of Authentication Exchange Mechanism
4.1. Notation ini : rec : K : Ki : Kr : AK : gir : gis : grs : KID: NI : NR :
Initiator Receiver Key shared by the initiator and the receiver Initiator key Receiver key Authentication key Initiator-Receiver gate Initiator-Server gate Receiver-Server gate Key reference numl~er Number generated by the initiator Number generated by the receiver,
4.2. Specification We model the authentication protocol by specifying three processes Initiator, Receiver and
207
Authentication Server. The processes interact with other processes via appropriate gates. That is, the process Initiator interacts with the process Receiver via gate gir and with the process Server via gate gis; the process Receiver interacts with the process Server via the gate grs. We only specify the ideal behaviour of the protocol. Further we let the authentication key (AK) equal to the field F in ISO DP9798. This can be easily modified by including another operation is in so that we can specify A K is_in F. We will first consider the specification of each of the processes: Initiator, Receiver and Authentication Server. Most of the data types used in this protocol are also common to the ones required for the specification of the second protocol employing public key encryption, described in Section 6. Accordingly the data types are described in Section 6.2.2. The numbers in brackets refer to the numbers used in the description of the protocol in Section 3.1.
4.2.1. Process Specification
(.
.)
Specification Auth_ Exchange_ IV : exit behaviour hide gis grs in Auth Server I[gis,grs]l (hide gir in Initiator I[gir]l Receiver) (* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
process Initiator[gis,gir] (id_ ini: Ident, id_ rec: Ident, Ki: Element, K I D : R e f No,) :exit := gir !KID; gir !collect ?cip_ mes_ 4 :String; choice NI :Nat [ ] i; gis !encrypt(Ki, concat(iden elem conv(id ini), concat(iden_ elem conv(id_ rec), concat(num_ elem_ conv(NI), rnum_ str_ cony(KID))))); gis ?cip_ rues_ 6 :String; (let plain mes 6 :String = decrypt(Ki,cip mes 6), ini_ no : Element = tail(1,plain_ rues_ 6) in [ini no eq num_elem conv(NI)] --* (let auth_ key :Element = tail(0,plain_ rues_ 6) plain mes__4 :String = decrypt(auth key, cip rues 4) in gir !elem num conv(tail(1,plain mes_ 4); exit)
.)
(1) (4)
(5) (6)
(7)
)
endproc (* .........................................................................
.)
208
V. Varadharajan / FormalDescription Technique
(* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
process Receiver[gir,grs] (id ini:Ident, id rec:Ident, Kr:Element) :exit -'= gir ?n :Ref No; choice N R :Nat [ ] i; grs !encrypt(Kr, concat(iden_elem_conv(id ini), concat(iden_elem conv(id rec), concat(num_ elem_ conv(NR), rnum _ str_ conv(KID))))); grs ?cip_ rues_ 3 :String; choice R :Nat [ ] i; (let rec_no : Element = tail(1,decrypt(Kr,cip mes 3)) auth_ key : Element = tail(0,decrypt(Kr,cip mes_ 3)) in ([rec_ no eq num_ elem_ conv(NR)] -~ gir !collect !encrypt(auth key, concat(num elem conv(n), num str conv(R))); gir !R; exit) ) endproc (* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . process Auth_ Server[gis,grs] (id_ ini:Ident, id rec: Ident) :exit := grs ?cip mes_ 2 :String; (let Ki : Element = keymap(id_ ini), Kr :Element = keymap(id_ reo) in) choice AK :Nat [ ] i; (let rec_ no :Element = tail(2,decrypt(Kr,cip _ mes_ 2)) in grs !encrypt(Kr, concat(rec no, n s conv(AK))); gis ?cip mes 5 :String; (let ini_ no :Element = tail(2,decrypt(Ki,cip_ mes_ 5)) in gis !encrypt(Ki, concat(num elem conv(AK),concat(ini_no, ~ )))); exit)) ) endproc (* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (NOTE : See Section 6.2.2 for specification of Data Types) endspec (. *) 5. Authentication Protocol - Using Public Key
Eneryption Technique In this section, we specify an authentication protocol using a public key encryption technique in LOTOS. The protocol forms part of the C c I T r Standard X.509, The Directory-Authentication Framework. In X.509, the protocol is referred to as the "Three-way Strong Authentication Procedure". The strong authentication procedures in X.509 employ public key cryptosystems. The reader is assumed to be familiar with the concept of public
*)
(1)
(2) (3)
(4) (7)
.) .)
(2)
(3) (5) (6)
.)
key systems. Two users wishing to authenticate must support the SAME cryptographic algorithm for authentication to be performed correctly. However, as in the previous case, the protocol itself is independent of any specific algorithm. Similarly, two users wishing to authenticate must support the same hash function, which is used in forming credentials and authentication tokens. Again, ANY suitable hash function can be used. For a user to trust the authentication procedure, he or she must obtain the other user's public key from a source that it trusts. This source is the Certification Authority (CA) and it uses the public
V. Varadharajan / FormalDescription Technique
key algorithm to certify the public key, producing a certificate. The certificates are unforgeable, that is, no party other than the certification authority can modify the certificate without this being detected. Any user who has the knowledge of the public key of the certification authority can obtain a certified public key. To generate the certificate, the CA uses the identity (name) of the user, the public key of the user and the first and last dates during which period the certificate is valid. The credentials of users are held as attributes within an information database called the Directory. For instance, the directory entry of each user involved in strong authentication includes the certificate of that user. In general, there may be more than one Certification Authority. That is, two users may "belong" to two different Certification Authorities. These Certification Authorities are arranged in a tree-like hierarchy. So if a user A wishes to obtain the public key of a user B, he needs to know the public key of the Certification Authority to which B "belongs". If A does not know the public key of the Certification Authority of B, then he goes through his certification Authority to find out the public keys of all the superior Certification Authorities, by "ascending the tree". In this way, eventually the user A will obtain the public key of the Certification Authority of B. The list of certificates required to allow a particular user to discover the public key of another user is called the Certification Path. Each item in the list is a certificate of the next Certification Authority. The certification path between two users A and B is denoted as A ~ B whereas the return certification path between A and B is denoted as B ~ A. In our specification, we assume that the users are served by the same Certification Authority so that the users can unwrap each others' certificates directly.
5.1. Three-way Strong Authentication Procedure
209
(2) ~ (6)(/ (7)k,. ~
~ "~ ini ,p, ~
(5)
(3) (4) (9)
(8) Fig. 2. Steps involved in Three-way Authentication Protocol.
i n i s is the secret key of the signer ini and h is the hash function. ini p[data] denotes encryption of data using public key of ini.
5.1.2. Steps 1. User Ini generates a random number ri, which is used in the detection of replay attacks and to prevent forgery. 2. User Ini sends the following message to B: B ~ A, rec p[ini(ti,ri,rec}] where the latter component is the authentication token and ti is a timestamp. 3. User rec carries out the following actions: a. obtains the public key of ini, i n i p , from B ~ A and checks that the user ini's certificate has not expired; b. deciphers the authentication token, and then verifies the signature and thus the integrity of the signed information; c. checks that the random number ri has not been replayed. This is specified by keeping a record of numbers received and checking that current number does not belong to this set. 4. User rec generates a random number rr to be used in a similar manner as ri. 5. User rec sends the following authentication token to user ini: ini_p[rec{ tr,rr,ini,rr) ]
Let us now briefly describe the steps involved in the three-way authentication procedure, when a user ini initiates the conversation with another user rec. The steps are depicted in Fig. 2. Our description closely follows the one given in [3] and we also employ the same notation as in [3].
5.1.1. Notation ini{data} denotes
(data,ini_s[h(data)])
where
where tr is a timestamp. 6. User ini carries out the following actions: a. deciphers the authentication token and then verifies the signature and thus the integrity of the signed information; b. checks that rr has not been replayed. 7. User ini checks that the received ri is identical to the ri which was sent.
II.. Varadharajan / Formal Description Technique
210
8. User ini sends the following authentication token to user rec:
sk rec pk ca
rec_p[ini(rr)] 9. User rec carries out the following actions: a. deciphers the authentication token and then checks the signature and thus the integrity of the signed information; b. checks that the received rr is identical to the rr which was sent. NOTE: Although timestamps form part of the token, in three-way authentication protocol, there is no checking of timestamps. However, timestamps are checked in one-way and two-way strong authentication procedures in X.509 [3].
gir gtime gdate certificate
6. L O T O S Specification ot Three-way Authentication Procedure
6.1. Notation ini rec r_i_path pk_ini p k rec sk_ini
: : : : : :
Initiator Receiver Receiver-Initiator Path Public key of the initiator Public key of the receiver Secret key of the initiator
: Secret key of the receiver : Public key of the common Certification Authority : Initiator-Receiver gate : Timer gate : Date gate : ( u s e r identity, user_public_ key, st_date, fin_date) where st_ date and fin_ date refer to the first and last dates on which the certificate is valid.
6.2. Specification As before, we model this protocol by specifying two processes Initiator, and Receiver and describing communications between them. We do not model interactions between the users and the Certification Authorities and we assume that the return certification path and the appropriate keys are provided to the processes by the external environment. Further selecting " a random number such that it is a strong key whatever cryptosystem to be used" [3] is not considered, as it is dependent upon the specific cryptosystem used. The numbers in brackets refer to the numbers used in the description of the protocol in Section 5.1.
6.2.1. Process Specification
(.
*)
specification Three_ Way_ Auth [gtime, gdate] : exit behaviour hide gir in Initiator[gir,gtime] ][gir]l Receiver[gir,gtime,gdate] (* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Process Initiator [gir, gtime] (r_ i_ path : String, pk_ ini, pk_ rec, sk_ini : Element, id_ini, id_rec : Ident, tab_ini : Rn_set) : exit .'= choice ri : Nat [ ] i; gtime ?ti : Time; (let ini_ token : String = concat(time_ elem_ conv(ti), concat(num_ elem_ conv(ri), iden _ str_ conv(id_ rec))) ini_signl : String = decrypt(sk_ini, hash(ini_token)) in gir !r_ i_ path !encrypt(pk_ rec, list(ini_ token, ini_ signl)); gir ? cip_mes_5 :String; (let plain_ mes_ 5 : String = decrypt(sk_ ini, cip_ mes_ 5), rand _ no : Element = tail(1,plain _ mes _ 5),
*)
(1)
(2) (5)
II. Varadharajan / Formal Description Technique
rec token
:String
rec_ hash
: String
211
= concat(tail(3,plain_ mes_ 5), concat( tail(2,plain mes_ 5), concat(tail(1,plain_ mes_ 5), concat (tail(0,plain_ mes_ 5), ( ) ) ) ) ) , = encrypt(pk_ rec, r e m o v e ( r e m o v e ( r e m o v e ( r e m o v e (plain_ mes _ 5,tail(0,plain _ mes_ 5)), tail(1,plain_ mes_ 5)),tail(2,plain mes _ 5)), tail(3,plainmes_ 5)))
in [hash(rec_token) eqs r e c _ h a s h and tail(3,plain mes 5) eq n u m elem conv(ri) and not_ in(elem _ n u m _ conv(rand _ no),tab _ ini)] --* (let ini_ sign2 : String = decrypt(sk_ ini, hash(elem_ str c o n v ( r a n d _ no))) in gir !encrypt(pk_ rec, concat(rand_ no,ini_ sign2)); exit)
) ) endproc (* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . process Receiver [gir,gtime,gdate] (r_i p a t h : String, p k _ r e c , sk_rec, p k _ c a : Element, id_ini, id_ rec : Ident, tab rec : R n _ s e t ) :exit-'= gir ? c i p _ m e s _ 2 a :String ?cip m e s _ 2 b :String; gdate ?date : Element; (let certificate : String = u n w r a p (pk_ ca, cip_ mes_ 2a), pk : Element = tail(1,certificate), st_ date : Element = tail(2,certificate), f i n _ d a t e : Element=tail(3,certificate), plain _ mes _ 2b : String = decrypt(sk _ rec, cip _ mes_ 2b), ini_ token : String = concat(tail(2,plain mes_ 2b), concat(tail(1,plain_mes_ 2b), concat(tail(0,plain_ mes_ 2b), ( ) ) ) ) , ini _ hash : String = encrypt(pk_ ini, r e m o v e ( r e m o v e ( r e m o v e (plain_ mes_ 2b, tail(0,plain_ mes_ 2b)), tail(1,plain_ mes_ 2b)),tail(2,plain_ mes_ 2b))) in [st_date leeq date and date leeq fin_ date and hash(ini_ token) eqs ini_ hash and not_ in (elem_ n u m _ conv(tail(1,plain_ mes_ 2b),tab_ rec)] choice rr : N a t [ ] i; gtime ?tr: Time; (let rec token: String = concat(time_ elem_ conv(tr),concat(num_ elem_ conv(rr), concat(tail(0,certificate),concat(tail(1,plain _ mes _ 2b), ())))) rec_ sign : String --- decrypt(sk_ rec, hash(rec_ token)) in gir ! encrypt(pk_ ini, list(rec_ t o k e n , r e c sign)); gir ?cip mes_ 8 : String; (let plain_ mes_ 8 : String = decrypt(sk_ rec, cip _ rues_ 8) in [hash(elem_str conv(tail(0,plain_mes 8))) eqs encrypt(pk_ini,
(6) (7)
(8)
*)
(2)
(3)
(4)
(5) (8)
212
V.. Varadharajan / Formal Description Technique
r e m o v e ( p l a i n _ m e s _ 8 , t a i l ( 0 , p l a i n _ m e s _ 8)) a n d t a i l ( 0 , p l a i n _ m e s _ 8) eq n u m _ e l e m _ conv(rr)]
(9)
exit) )
) endproc (* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.)
6.2.2. Data Types (* .........................................................................
type N a m e s is sorts I d e n t o p n s ini : ~ I d e n t rec : ---, I d e n t endtype (. ......................................................................... t y p e A u t h P a r a m s is N a t u r a l N u m b e r , B o o l e a n , N a m e s sorts String, E l e m e n t opns ( ) : ~ String collect : ~ Element nil : ---, E l e m e n t concat : Element, String ---, S t r i n g list : String, S t r i n g ~ String remove : String, E l e m e n t ---, S t r i n g encrypt : Element, String ---, S t r i n g decrypt : Element, String ~ String tail : Nat, String ~ Element _eqe_ : E l e m e n t , E l e m e n t --, Bool _neqe_ : E l e m e n t , E l e m e n t ~ Bool _eqs_ : String, String ---, Bool _neqs_ : String, S t r i n g ---, Bool _leeq_ : E l e m e n t , E l e m e n t ---, Bool keymap : Ident ~ Element str_ n u m _ c o n v : S t r i n g ~ Nat num_str_conv : Nat ~ String i d e n str c o n v : Ident ~ String str i d e n _ c o n v : String ---, I d e n t num_ elem_conv : Nat ~ Element elem_ num_ conv: Element ~ Nat iden_elem_conv : Ident --, E l e m e n t elem_ iden_ conv: Element ~ Ident eqns forall k,x,y,z: E l e m e n t , s,t: String, n :Nat, i d , i d _ a , i d b: I d e n t of sort S t r i n g e n c r y p t ( k , d e c r y p t ( k , s ) ) = y; d e c r y p t ( k , e n c r y p t ( k , s ) ) = y; encrypt(k,()) = ( ); decrypt(k,()) = ( ); t a i l ( n , ( ) ) = nil ; tail(O,concat(k,s)) = k;
.)
.)
V. Varadharajan / FormalDescription Technique
213
tail(succ(n), concat(k,s)) = tail(n,s); d e c r y p t ( k , e n c r y p t ( k , c o n c a t ( x , s ) ) ) = concat(x,s); e n c r y p t ( k , d e c r y p t ( k , c o n c a t ( x , s ) ) ) = concat(x,s); l i s t ( ( ) , s ) = s; list(eoncat(k,s),t) = concat(k,list(s,t)); r e m o v e ( ( ) , k ) = ( ); r e m o v e ( c o n c a t ( k , s ) , k ) = s; k neqe x ~ remove(concat(k,s),x) = concat(k,remove(s,x)); ofsort Bool x eqe x = true; x = y ~ x eqe y = true; x eqe y ~ x = y; x n e q e y = n o t ( x eqe y); ( )eqs( )=true; c o n c a t ( k , s ) eqs ( ) = false; ( ) eqs c o n c a t ( k , s ) = false; concat(k,s) eqs c o n c a t ( x , t ) = k eqe x a n d s eqs t; s n e q s t = n o t ( s eqs t); k e y m a p ( i d a) eqe k e y m a p ( i d b) --* i d a = i d b; id a=id b ~ k e y m a p ( i d a) eqe k e y m a p ( i d b); (x n e q e y), (x leeq y) ~ n o t ( y leeq x) = true; (x leeq y), (y leeq x) ~ (x eqe y) -- true; (x leeq y), (y leeq z) ~ (x leeq z) = true; x leeq x = true; ofsort E l e m e n t n u m _ e l e m _ c o n v ( e l e m _ n u m _ c o n v ( k ) ) = k; i d e n _ e l e m _ c o n v ( e l e m _ i d e n _ c o n v ( k ) ) = k; ofsort N a t str_ n u m c o n v ( n u m _ str_ c o n y ( n ) ) = n; e l e m _ h u m _ c o n v ( n u m _ e l e m _ c o n v ( n ) ) = n; ofsort I d e n t str_ i d e n _ c o n v ( i d e n _ str c o n v ( i d ) ) = id; elem _ i d e n _ c o n v ( i d e n _ e l e m _ c o n v ( i d ) ) = id; endtype (* .........................................................................
*)
t y p e R e f e r e n c e N o is A u t h _ P a r a m s sorts R e f _ n o o p n s m u m str c o n v : R e f _ n o ~ String str_ mum_ conv : String ~ Ref_ no mum_ elem_ conv: Ref_ no ---, E l e m e n t elem rnum conv: Element ~ Ref_no e q n s forall n: R e f _ n o , s: String, k: E l e m e n t ofsort R e f _ n o str_ m u m _ c o n v ( r n u m _ str_ c o n v ( n ) ) = n; e l e m _ m u m _ c o n y ( m u m _ e l e m _ c o n y ( n ) ) = n; ofsort String str_ m u m _ c o n v ( s t r _ m u m _ c o n v ( s ) = s; of sort E l e m e n t m u m _ e l e m _ c o n v ( e l e m _ r n u m _ c o n y ( k ) ) = k; endtype (* .........................................................................
*)
214
V. Varadharajan /Formal Description Technique
t y p e R a n d o m _ N o Set is N a t u r a l N u m b e r , Boolean sorts R n _ s e t o p n s a d d n o : N a t , R n set ---, R n set n o t _ i n : N a t , R n _ set ~ Bool i s _ i n : N a t , R n _ set ---, Bool eqns forall n,m: N a t , s: R n set ofsort R n _ set a d d _ no(n,add(n,s)) = a d d _ no(n,s); a d d _ n o ( n , a d d _ no(m,s)) = a d d _ n o ( m , a d d _ no(n,s)); ofsort Bool i s _ i n ( n , a d d _ n o ( n , s ) ) = true; n ne m ~ i s _ i n ( n , a d d _ n o ( m , s ) ) = is in(n,s); n o t _ in(n,s) = not(is_ in(n,s)); endtype (* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . t y p e Clock is A u t h _ Params, Boolean sorts T i m e opns time_elem_conv " Time ~ Element e l e m _ time_ conv : E l e m e n t ~ T i m e eqns forall t: T i m e K: E l e m e n t of sort T i m e elem_ time_ conv (time_ elem_ conv(t)) = t; ofsort E l e m e n t time_ elem _ c o n v (elem_ time _ c o n v (k)) = k; endtyp (* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . endspec (*
7. Extension of Specification T h e specifications d e s c r i b e d a b o v e d e s c r i b e two a u t h e n t i c a t i o n p r o t o c o l s as given in the S t a n d a r d s I S O / D P 9798 a n d in C C I T T X.509. This section briefly considers s o m e further extensions to the specifications that can be carried out. i. W h e n i n t e r p r e t i n g a specification as some sort o f d e s c r i p t i o n of w h a t can h a p p e n we need to include deviations f r o m the " c o r r e c t " beh a v i o u r that occur in n o r m a l situations. The specifications d e s c r i b e d a b o v e only c o n s i d e r the ideal b e h a v i o u r of the protocol. W e can extend this b y considering the b e h a v i o u r of the p r o t o c o l when various error situations that can arise such as c o r r u p t i o n of messages, loss of messages a n d b r e a k d o w n in connections. However, note that the S t a n d a r d s I S O / D P 9798 a n d C C I T T X.509 d o n o t consider such a b n o r m a l situations,
*)
*) .)
ii. T h e a b o v e d e s c r i p t i o n o f the t h r e e - w a y a u t h e n t i c a t i o n p r o t o c o l of X.509 can b e extended to include specification of i n t e r a c t i o n s between the users, the Certification A u t h o r i t y a n d the Directory. iii. T h e specification d e s c r i b e d a b o v e considers the case where there are two users ini a n d rec who assume the role of the i n i t i a t o r a n d receiver a n d have a c o m m u n i c a t i o n . This can be generalized to a m o r e real situation where we have a finite n u m b e r of users, each of w h o m can a s s u m e the role of the i n i t i a t o r c o m m u n i cating with a n y of the o t h e r users.
8. Discussion In this p a p e r , we have d e s c r i b e d two authentic a t i o n p r o t o c o l s in L O T O S that have been p r o p o s e d in the security field. These two p r o t o c o l s
V. Varadharajan / Formal Description Technique
have been s t a n d a r d i z e d b y the I n t e r n a t i o n a l bodies ISO a n d C C I T T respectively. W e feel that L O T O S is a powerful language, useful for p r o d u c ing concise a n d structured specifications. F u r t h e r L O T O S does also have analytical power to verify the desired properties of the specified systems. I n particular, as future work, it will be interesting to carry out s i m u l a t i o n a n d analysis of the specified protocols. T o be able to do this, adequate L O T O S tools are necessary. These are currently being developed within the Protocol E n g i n e e r i n g Project, at H P L a b s . [8].
References [1] ISO 8807: Information Processing Systems - Open Systems Interconnection LOTOS - A Formal Description
215
Technique based on the temporal ordering of observational behaviour(1988). [2] ISO/DP 9798: Data Cryptographic Techniques - Peer Entity Authentication Mechanisms using an n-bit secret key algorithm (1987). [3] CCITT X.509: The Directory - Authentication Framework (1987). [41 R. Milner, A caluculus of communicating systems, LNCS 92 (Springer-Verlag, Berlin 1980). [5] C.A.R. Hoare, Communicating Sequential Processes (Prentice-Hall, 1985). [6] H. Ehrig and B. Mahr, Fundamentals of algebraic specification 1: Equations and initial semantics, EATCS (Springer-Verlag, 1985). [7] Stewart Black, Introduction to LOTOS for protocol specification and verification, Internal Paper, HP-ISC, July 1988. [81 Stuart Johnston, SPIDER - Service and protocol interactive development environment, Technical Memo, HPLISC-TM-88-050.
Use of a Formal Description Technique in the Specification of Authentication Protocols Vijay V A R A D H A R A J A N Hewlett-Packard Labs., Filton Road, Stoke Gifford, Bristol BS12 6QZ, UK
Formal specification techniques have been employed o v e r the past decade or so by various workers in data communication and computer network systems in order to provide both definitional specifications of protocols and models of protocols for analytic purposes. This paper considers the use of the specification language LOTOS (Language of Temporal Ordering Specification) for specifying some authentication protocols developed in the security field. The language LOTOS recently became an International ISO Standard and the protocols specified form part of the ISO and CCITT Standards. In fact, the CCITT protocol which is considered in this paper, has been used in the LOCATOR (X.400 Secure Mail) project within HPLabs. We first give a brief introduction to LOTOS and then specify two security protocols from ISO/DP 9798 and CCITT x.509 Standards. We feel that a formal specification of protocols is a useful and a necessary step towards understandability, analysis and implementation of the protocols. Further, we feel that LOTOS possesses the necessary features required for specifying such protocols, Keywords: Authentication, CCITT X. 509, Computer network
systems, Data communication, Formal specification, ISO/DP 9798, LOTOS, Modeling, Protocols, x.400~
k
Vijay Varadharajan is a Project
Manager at the Bristol Information Systems Centre of Hewlett-Packard Labs., U.K., doing research in security in distributed systems. He obtained his Ph.D. in the area of security in 1984. Since then he has been a member of Staff at the Dept. of Computer ~ Science, Reading University and has worked as a Research Manager at the British Telecom Research Laboratories in Ipswich, U.K. His research interests include security, formal specification and modelling techniques, object models and networks,
I
North-Holland Computer Standards & Interfaces 9 (1989/90) 203-215
1. Introduction Several formal specification languages have b e e n developed in recent years. These languages essentially differ in the emphasis they place o n concepts such as abstractness (how i m p l e m e n t a tion d e p e n d e n t they can be), c o n c u r r e n c y (how suitable they are for specifying parallel systems) a n d analysability (how readily specifications can be verified). It is the application area which p r i m arily determines the appropriateness of the language. O n e i m p o r t a n t area is that of c o m m u n i c a tion systems which present technical challenges due to the i n h e r e n t c o n c u r r e n c y and distributedness. Protocols play an i m p o r t a n t role in c o m p u t e r networks a n d distributed systems. The complexity of such protocols is c o n t i n u o u s l y increasing which in t u r n implies that more a n d more powerful techniques to develop them are necessary. Description of the protocol forms a n i m p o r t a n t part of the d e v e l o p m e n t process. Initial descriptions provide a c o m m o n frame of reference allowing cooperation a m o n g designers of different parts of a protocol. Descriptions also play a vital role in the verification process. T h e protocol design must be verified for logical correctness before implementation. Here we consider a formal specification language L O T O S developed by the I n t e r n a t i o n a l S t a n d a r d s O r g a n i z a t i o n (ISO) [1] for specifying some a u t h e n t i c a t i o n protocols. In Section 2, a brief overview of the language L O T O S is given. Section 3 describes the specification of a peer entity a u t h e n t i c a t i o n protocol using a symmetric e n c r y p t i o n technique. This protocol forms part of the I S O / D P 9798 S t a n d a r d [2]. In Section 4, an a u t h e n t i c a t i o n p r o t o c o l using a p u b l i c key cryptosystem is specified. This m e c h a n i s m forms part of the s t a n d a r d C C I T T X.509: The Direct o r y - A u t h e n t i c a t i o n F r a m e w o r k [3].
0920-5489/90/$3.50 © 1990, Elsevier Science Publishers B.V. (North-Holland)
204
V. Varadharajan / Formal Description Technique
2. L O T O S Formal Description Techniques (FDTs) are methods of defining the behaviour of a system in a language with a formal syntax and semantics, Some of the objectives to be satisfied by a F D T are as follows [1]: a. expressive power: ability to express a wide range of properties required for the description of services and protocols b. well-defined syntax and semantics: enabling mechanical manipulation, and validation c. well-structured: increasing understandability and maintainability of specifications d. abstraction: allowing representation of architectural aspects at a sufficiently high level of abstraction, where implementation details are not specified, LOTOS is a Formal Description Technique (FDT) that has been developed for the formal specification of open distributed systems, in particular those related to Open Systems Interconnection (OSI). LOTOS is based on process algebraic methods and does not use a (temporal) logical language, in contrast to what the name might appear to suggest. More specifically, LOTOS can be viewed to consist of two components, one dealing with the description of process behaviours and interactions and the other dealing with the description of data structures and value expressions. The former is based on CCS [4] and CSP [5] whereas the latter was inspired by the abstract data type technique ACT O N E [6]. We now give a very brief description of each of these two components of LOTOS. We will be only presenting some of the features of LOTOS that are necessary for our specification of authentication protocols in Sections 4 and 6. The reader is referred to [1] and [7] for detailed treatment. 2.1. L O T O S Process Model
In LOTOS, a system is modelled as a collection of processes interacting with each other. However, a process may contain several sub-processes, where a sub-process is a process in itself. Hence a system is essentially specified as a hierarchy of process definitions. A process in LOTOS is described in terms of its observable (communication) behaviour. This is done using language expressions that have primitive interactions called events.
An event consists of interaction points and a list of variables and values and events occur at points of interaction shared by processes, event gates. Events are assumed to be atomic, in the sense that they occur instantaneously, without consuming time. The processes that interact in an event must synchronize. That is, the processes that interact in an event must participate in its execution at the same moment in time, so that all variables in the event are simultaneously assigned values. Hence essentially, the LOTOS specification describes the potential order between the events, that can be observed at the interaction points. This description is a conjunction of atomic events and subprocesses, joined using the LOTOS operators. The basic operators in LOTOS which we mention here are the action prefix operator, the choice operator, the parallel operator and the guarding operator. Other operators include hiding, enabling, and disabling. For a detailed description of all these operators refer to [1] and [7]. The action prefix construct (;) enables the production of a new behaviour expression out of an existing one by prefixing it with an event name. Hence a ; B describes a process which first offers participation in event " a " and if it takes place then the behaviour of the process is given by the expression B. The choice operator ([ ]) allows to describe a process that behaves either like B1 or like B2, where B1 and B2 are behaviour expressions. The choice is resolved in the interaction of the process with the environment. To describe parallelism, LOTOS uses three operators which help to model three different types of concurrent processes, namely, asynchronous, synchronous and partially synchronous. The operator III denotes independent composition. It defines the behaviour of the composition as the arbitrary interleaving of the events of the subprocesses. B1 IIIB2 can participate in an event if B1 can participate in it, or B2 can participate in it. Any event that is refused by both B1 and B2 will not occur. The operator II defines the parallel composition of dependent subprocesses. B1 lIB2 can participate in an event if both B1 and B2 can participate in it. Hence it refuses any event that is refused by B1 or B2. The third parallel operator, called the general
1I.. Varadharajan / Formal Description Technique
parallel operator, is used to describe a composition between two subprocesses which must synchronize with respect to a set of events. For instance, B1 I[al, a2 . . . . , an] I B2 describes a composition in which b o t h processes B1 and B2 must synchronize with respect to the events al, a2, . . . , an. The guarding operator is a construct which allows to express conditional choice. If e is a boolean expression, then [e] ---, p means that the execution of p is only offered if the " g u a r d " e is true, else it is equivalent to stop - inactive process. We conclude this very brief section on process specification by mentioning a special event called the internal event. As the name implies, an internal event is "internal" to the process and is not observable. It is denoted by "i".
2.2. LOTOS Data Types Again, in this section, we very briefly mention some of the concepts involved in the data type specification. The interested reader should refer to [1] and [7] for more detailed treatment, In LOTOS, the representation of values, value expressions and data structures are derived from the algebraic specification method, A C T O N E . The algebraic specification technique derives its n a m e from its relationship to a form of abstract algebra called a heterogeneous or many-sorted algebra. A n abstract algebra consists of a none m p t y set (called carrier) and a set of n a m e d functions, each of which takes a finite n u m b e r of arguments from the carrier and maps them onto an element of the carrier. A heterogeneous algebra is one that has a set of n a m e d carriers, To define an abstract data type, one needs to define the names of data carriers and the operations. In L O T O S , the names of the data carriers are referred to as "sorts". The sorts and operations (opns) of a data type are referred to as the signature of that data type. The equations (eqns) define the axioms and axiom schema on the roodels of the operations, In order to facilitate the specification of systems with a large n u m b e r of operations and equations and complex data types features such as " r e n a m i n g " of data types, " p a r a m e t e r i z a t i o n " and " c o m b i n a t i o n " of specifications are provided in LOTOS.
205
2.3. Other Relevant Operations In this section, we briefly mention communication events. Recall that an event offer consists of event gate name, identifying the point of interaction and a finite list of attributes. There are two types of attributes: a value declaration and a variable declaration. A value declaration is a L O T O S expression describing a data value, preceded by an exclamation mark (e.g, !3). A variable declaration has the form ?x : t where x is the name of the variable and t is its sort identifier (e.g., ?x : integer). Let us now consider some typical interactions between processes. a. a!sl and a!s2 - T w o processes sharing an event gate may attach values to events and the corresponding event takes place if these values coincide (sl = s2). b. a?x : t and a!e - If two processes make complementary offers, i.e. one is prepared to accept any value of type t at a certain gate and the other is prepared to provide a value of e of the same type at the same gate, then the event m a y take place. c. a?x : tl and a?y : t2 (and tl = t2) - In this case, the actual value of the event that will occur is not determined by this model and hence this can be used to represent some sort of " v a l u e negotiation" between processes, where the actual mechanism determining the choice is not relevant or is unknown. The resulting value is referred to as " x " in one process and as " y " in the other.
3. Authentication Protocol Using Symmetric Encryption Technique In this section, we consider the use of L O T O S in the specification of a peer entity authentication protocol employing a symmetric encryption technique described in the ISO d o c u m e n t I S O / D P 9798 [2]. The Standard d o c u m e n t presents four a u t h e n t i c a t i o n e x c h a n g e m e c h a n i s m s . These mechanisms are defined by authentication exchanges employed for interactions between entities and the Authentication Server. They provide scope for key exchange prior to establishing a connection for data confidentiality service, and for the identification of entities' rights as part of an access control service. The mechanisms employ
206
V. Varadharajan / Formal Description Technique
any suitable n-bit symmetry key encryption algorithm rather than a specific one. In this section, we will be considering the specification of one such mechanism, namely the Authentication Exchange Mechanism IV, in LOTOS. We will be only describing the ideal behaviour. The objective of entity authentication is to assure an entity that the entity with which it communicates is the one claimed. Authentication may be unilateral or mutual. Here we are concerned only with the mutual authentication mechanism. The mechanism is defined via interactions between entities and the Authentication Server. It is assumed that the secret keys of the entities are known to the Authentication Server. We assume that the reader is familiar with the concept of authentication Server and its use in key distribution protocols.
~ ~
~
v
e r
~41)) (
2
)
~
Rec (7)
(1) KID (2) [IniI[RecIINRIIKID]A-r~c (3) [AI([[NR]I~r~
(4) "collect", [K I DIIR]A K
3.1. Authentication Exchange Mechanism
Suppose that an entity Initiator (Ini) wishes to have a conversation with an entity Receiver (Rec). The secret keys of Ini and Rec are known to the Authentication Server (AS). The steps involved in the authentication mechanism are as follows (see Fig. 1 ): Phase 1: Entity Ini establishes the conditions
to enable it to prove its identity and the timeliness of its communication to entity Rec. 1. Ini sends to Rec a number called the key reference number (KID) to initiate the authentication. 2. Rec sends an encrypted requests to the Authentication Server (AS)to generate authentication key. The request includes the identities Ini and Rec together with the received KID and a sequence number (NR) generated by Rec. The request is encrypted under Rec's secret key. 3. AS generates the authentication key (AK) and returns both AK and NR to Rec, encrypted under Rec's key. Rec knows that the message comes from AS since the secret key of Rec is only known to Rec and AS. Further, Rec can check that the message is not replayed by testing whether the sequence number in the message corresponds to its own. Phase 2: Entity Ini identifies itself to entity Rec and challenges Rec to prove its identity. 4. Rec sends a message to Ini containing the
(5) [Ini[[Rec[[NI[[l(ID]t~-ini (6) [aI(I[NI]h'ini (7) R
[X]k - denotes encryptionof X under key k. x I I Y - denotes concatenationof X and Y. Fig. 1. Exchange mechanism.
verifier which includes an encrypted version of a random number R generated by Rec and the key reference number KID. 5. Ini requests AS the authentication key, stored under the reference number KID, The request includes the identities Ini and Rec together with KID and a sequence number NI generated by Ini. The request is encrypted under the secret key of Ini. 6. AS uses KID to locate the authentication key and returns both AK and NI to Ini encrypted under the Ini's secret key. Ini decrypts the message to reveal the authentication key and also verifies the sequence number, to protect against replay. Phase 3: Entity Rec proves its identity to entity Ini. 7. Ini uses AK to decrypt the verifier of Rec and confirms that Rec knows the authentication key. Then Ini returns the random number R to Rec which confirms to Rec that Ini knows the authentication key.
V. Varadharajan / Formal Description Technique
4. L O T O S Specification of Authentication Exchange Mechanism
4.1. Notation ini : rec : K : Ki : Kr : AK : gir : gis : grs : KID: NI : NR :
Initiator Receiver Key shared by the initiator and the receiver Initiator key Receiver key Authentication key Initiator-Receiver gate Initiator-Server gate Receiver-Server gate Key reference numl~er Number generated by the initiator Number generated by the receiver,
4.2. Specification We model the authentication protocol by specifying three processes Initiator, Receiver and
207
Authentication Server. The processes interact with other processes via appropriate gates. That is, the process Initiator interacts with the process Receiver via gate gir and with the process Server via gate gis; the process Receiver interacts with the process Server via the gate grs. We only specify the ideal behaviour of the protocol. Further we let the authentication key (AK) equal to the field F in ISO DP9798. This can be easily modified by including another operation is in so that we can specify A K is_in F. We will first consider the specification of each of the processes: Initiator, Receiver and Authentication Server. Most of the data types used in this protocol are also common to the ones required for the specification of the second protocol employing public key encryption, described in Section 6. Accordingly the data types are described in Section 6.2.2. The numbers in brackets refer to the numbers used in the description of the protocol in Section 3.1.
4.2.1. Process Specification
(.
.)
Specification Auth_ Exchange_ IV : exit behaviour hide gis grs in Auth Server I[gis,grs]l (hide gir in Initiator I[gir]l Receiver) (* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
process Initiator[gis,gir] (id_ ini: Ident, id_ rec: Ident, Ki: Element, K I D : R e f No,) :exit := gir !KID; gir !collect ?cip_ mes_ 4 :String; choice NI :Nat [ ] i; gis !encrypt(Ki, concat(iden elem conv(id ini), concat(iden_ elem conv(id_ rec), concat(num_ elem_ conv(NI), rnum_ str_ cony(KID))))); gis ?cip_ rues_ 6 :String; (let plain mes 6 :String = decrypt(Ki,cip mes 6), ini_ no : Element = tail(1,plain_ rues_ 6) in [ini no eq num_elem conv(NI)] --* (let auth_ key :Element = tail(0,plain_ rues_ 6) plain mes__4 :String = decrypt(auth key, cip rues 4) in gir !elem num conv(tail(1,plain mes_ 4); exit)
.)
(1) (4)
(5) (6)
(7)
)
endproc (* .........................................................................
.)
208
V. Varadharajan / FormalDescription Technique
(* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
process Receiver[gir,grs] (id ini:Ident, id rec:Ident, Kr:Element) :exit -'= gir ?n :Ref No; choice N R :Nat [ ] i; grs !encrypt(Kr, concat(iden_elem_conv(id ini), concat(iden_elem conv(id rec), concat(num_ elem_ conv(NR), rnum _ str_ conv(KID))))); grs ?cip_ rues_ 3 :String; choice R :Nat [ ] i; (let rec_no : Element = tail(1,decrypt(Kr,cip mes 3)) auth_ key : Element = tail(0,decrypt(Kr,cip mes_ 3)) in ([rec_ no eq num_ elem_ conv(NR)] -~ gir !collect !encrypt(auth key, concat(num elem conv(n), num str conv(R))); gir !R; exit) ) endproc (* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . process Auth_ Server[gis,grs] (id_ ini:Ident, id rec: Ident) :exit := grs ?cip mes_ 2 :String; (let Ki : Element = keymap(id_ ini), Kr :Element = keymap(id_ reo) in) choice AK :Nat [ ] i; (let rec_ no :Element = tail(2,decrypt(Kr,cip _ mes_ 2)) in grs !encrypt(Kr, concat(rec no, n s conv(AK))); gis ?cip mes 5 :String; (let ini_ no :Element = tail(2,decrypt(Ki,cip_ mes_ 5)) in gis !encrypt(Ki, concat(num elem conv(AK),concat(ini_no, ~ )))); exit)) ) endproc (* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (NOTE : See Section 6.2.2 for specification of Data Types) endspec (. *) 5. Authentication Protocol - Using Public Key
Eneryption Technique In this section, we specify an authentication protocol using a public key encryption technique in LOTOS. The protocol forms part of the C c I T r Standard X.509, The Directory-Authentication Framework. In X.509, the protocol is referred to as the "Three-way Strong Authentication Procedure". The strong authentication procedures in X.509 employ public key cryptosystems. The reader is assumed to be familiar with the concept of public
*)
(1)
(2) (3)
(4) (7)
.) .)
(2)
(3) (5) (6)
.)
key systems. Two users wishing to authenticate must support the SAME cryptographic algorithm for authentication to be performed correctly. However, as in the previous case, the protocol itself is independent of any specific algorithm. Similarly, two users wishing to authenticate must support the same hash function, which is used in forming credentials and authentication tokens. Again, ANY suitable hash function can be used. For a user to trust the authentication procedure, he or she must obtain the other user's public key from a source that it trusts. This source is the Certification Authority (CA) and it uses the public
V. Varadharajan / FormalDescription Technique
key algorithm to certify the public key, producing a certificate. The certificates are unforgeable, that is, no party other than the certification authority can modify the certificate without this being detected. Any user who has the knowledge of the public key of the certification authority can obtain a certified public key. To generate the certificate, the CA uses the identity (name) of the user, the public key of the user and the first and last dates during which period the certificate is valid. The credentials of users are held as attributes within an information database called the Directory. For instance, the directory entry of each user involved in strong authentication includes the certificate of that user. In general, there may be more than one Certification Authority. That is, two users may "belong" to two different Certification Authorities. These Certification Authorities are arranged in a tree-like hierarchy. So if a user A wishes to obtain the public key of a user B, he needs to know the public key of the Certification Authority to which B "belongs". If A does not know the public key of the Certification Authority of B, then he goes through his certification Authority to find out the public keys of all the superior Certification Authorities, by "ascending the tree". In this way, eventually the user A will obtain the public key of the Certification Authority of B. The list of certificates required to allow a particular user to discover the public key of another user is called the Certification Path. Each item in the list is a certificate of the next Certification Authority. The certification path between two users A and B is denoted as A ~ B whereas the return certification path between A and B is denoted as B ~ A. In our specification, we assume that the users are served by the same Certification Authority so that the users can unwrap each others' certificates directly.
5.1. Three-way Strong Authentication Procedure
209
(2) ~ (6)(/ (7)k,. ~
~ "~ ini ,p, ~
(5)
(3) (4) (9)
(8) Fig. 2. Steps involved in Three-way Authentication Protocol.
i n i s is the secret key of the signer ini and h is the hash function. ini p[data] denotes encryption of data using public key of ini.
5.1.2. Steps 1. User Ini generates a random number ri, which is used in the detection of replay attacks and to prevent forgery. 2. User Ini sends the following message to B: B ~ A, rec p[ini(ti,ri,rec}] where the latter component is the authentication token and ti is a timestamp. 3. User rec carries out the following actions: a. obtains the public key of ini, i n i p , from B ~ A and checks that the user ini's certificate has not expired; b. deciphers the authentication token, and then verifies the signature and thus the integrity of the signed information; c. checks that the random number ri has not been replayed. This is specified by keeping a record of numbers received and checking that current number does not belong to this set. 4. User rec generates a random number rr to be used in a similar manner as ri. 5. User rec sends the following authentication token to user ini: ini_p[rec{ tr,rr,ini,rr) ]
Let us now briefly describe the steps involved in the three-way authentication procedure, when a user ini initiates the conversation with another user rec. The steps are depicted in Fig. 2. Our description closely follows the one given in [3] and we also employ the same notation as in [3].
5.1.1. Notation ini{data} denotes
(data,ini_s[h(data)])
where
where tr is a timestamp. 6. User ini carries out the following actions: a. deciphers the authentication token and then verifies the signature and thus the integrity of the signed information; b. checks that rr has not been replayed. 7. User ini checks that the received ri is identical to the ri which was sent.
II.. Varadharajan / Formal Description Technique
210
8. User ini sends the following authentication token to user rec:
sk rec pk ca
rec_p[ini(rr)] 9. User rec carries out the following actions: a. deciphers the authentication token and then checks the signature and thus the integrity of the signed information; b. checks that the received rr is identical to the rr which was sent. NOTE: Although timestamps form part of the token, in three-way authentication protocol, there is no checking of timestamps. However, timestamps are checked in one-way and two-way strong authentication procedures in X.509 [3].
gir gtime gdate certificate
6. L O T O S Specification ot Three-way Authentication Procedure
6.1. Notation ini rec r_i_path pk_ini p k rec sk_ini
: : : : : :
Initiator Receiver Receiver-Initiator Path Public key of the initiator Public key of the receiver Secret key of the initiator
: Secret key of the receiver : Public key of the common Certification Authority : Initiator-Receiver gate : Timer gate : Date gate : ( u s e r identity, user_public_ key, st_date, fin_date) where st_ date and fin_ date refer to the first and last dates on which the certificate is valid.
6.2. Specification As before, we model this protocol by specifying two processes Initiator, and Receiver and describing communications between them. We do not model interactions between the users and the Certification Authorities and we assume that the return certification path and the appropriate keys are provided to the processes by the external environment. Further selecting " a random number such that it is a strong key whatever cryptosystem to be used" [3] is not considered, as it is dependent upon the specific cryptosystem used. The numbers in brackets refer to the numbers used in the description of the protocol in Section 5.1.
6.2.1. Process Specification
(.
*)
specification Three_ Way_ Auth [gtime, gdate] : exit behaviour hide gir in Initiator[gir,gtime] ][gir]l Receiver[gir,gtime,gdate] (* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Process Initiator [gir, gtime] (r_ i_ path : String, pk_ ini, pk_ rec, sk_ini : Element, id_ini, id_rec : Ident, tab_ini : Rn_set) : exit .'= choice ri : Nat [ ] i; gtime ?ti : Time; (let ini_ token : String = concat(time_ elem_ conv(ti), concat(num_ elem_ conv(ri), iden _ str_ conv(id_ rec))) ini_signl : String = decrypt(sk_ini, hash(ini_token)) in gir !r_ i_ path !encrypt(pk_ rec, list(ini_ token, ini_ signl)); gir ? cip_mes_5 :String; (let plain_ mes_ 5 : String = decrypt(sk_ ini, cip_ mes_ 5), rand _ no : Element = tail(1,plain _ mes _ 5),
*)
(1)
(2) (5)
II. Varadharajan / Formal Description Technique
rec token
:String
rec_ hash
: String
211
= concat(tail(3,plain_ mes_ 5), concat( tail(2,plain mes_ 5), concat(tail(1,plain_ mes_ 5), concat (tail(0,plain_ mes_ 5), ( ) ) ) ) ) , = encrypt(pk_ rec, r e m o v e ( r e m o v e ( r e m o v e ( r e m o v e (plain_ mes _ 5,tail(0,plain _ mes_ 5)), tail(1,plain_ mes_ 5)),tail(2,plain mes _ 5)), tail(3,plainmes_ 5)))
in [hash(rec_token) eqs r e c _ h a s h and tail(3,plain mes 5) eq n u m elem conv(ri) and not_ in(elem _ n u m _ conv(rand _ no),tab _ ini)] --* (let ini_ sign2 : String = decrypt(sk_ ini, hash(elem_ str c o n v ( r a n d _ no))) in gir !encrypt(pk_ rec, concat(rand_ no,ini_ sign2)); exit)
) ) endproc (* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . process Receiver [gir,gtime,gdate] (r_i p a t h : String, p k _ r e c , sk_rec, p k _ c a : Element, id_ini, id_ rec : Ident, tab rec : R n _ s e t ) :exit-'= gir ? c i p _ m e s _ 2 a :String ?cip m e s _ 2 b :String; gdate ?date : Element; (let certificate : String = u n w r a p (pk_ ca, cip_ mes_ 2a), pk : Element = tail(1,certificate), st_ date : Element = tail(2,certificate), f i n _ d a t e : Element=tail(3,certificate), plain _ mes _ 2b : String = decrypt(sk _ rec, cip _ mes_ 2b), ini_ token : String = concat(tail(2,plain mes_ 2b), concat(tail(1,plain_mes_ 2b), concat(tail(0,plain_ mes_ 2b), ( ) ) ) ) , ini _ hash : String = encrypt(pk_ ini, r e m o v e ( r e m o v e ( r e m o v e (plain_ mes_ 2b, tail(0,plain_ mes_ 2b)), tail(1,plain_ mes_ 2b)),tail(2,plain_ mes_ 2b))) in [st_date leeq date and date leeq fin_ date and hash(ini_ token) eqs ini_ hash and not_ in (elem_ n u m _ conv(tail(1,plain_ mes_ 2b),tab_ rec)] choice rr : N a t [ ] i; gtime ?tr: Time; (let rec token: String = concat(time_ elem_ conv(tr),concat(num_ elem_ conv(rr), concat(tail(0,certificate),concat(tail(1,plain _ mes _ 2b), ())))) rec_ sign : String --- decrypt(sk_ rec, hash(rec_ token)) in gir ! encrypt(pk_ ini, list(rec_ t o k e n , r e c sign)); gir ?cip mes_ 8 : String; (let plain_ mes_ 8 : String = decrypt(sk_ rec, cip _ rues_ 8) in [hash(elem_str conv(tail(0,plain_mes 8))) eqs encrypt(pk_ini,
(6) (7)
(8)
*)
(2)
(3)
(4)
(5) (8)
212
V.. Varadharajan / Formal Description Technique
r e m o v e ( p l a i n _ m e s _ 8 , t a i l ( 0 , p l a i n _ m e s _ 8)) a n d t a i l ( 0 , p l a i n _ m e s _ 8) eq n u m _ e l e m _ conv(rr)]
(9)
exit) )
) endproc (* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.)
6.2.2. Data Types (* .........................................................................
type N a m e s is sorts I d e n t o p n s ini : ~ I d e n t rec : ---, I d e n t endtype (. ......................................................................... t y p e A u t h P a r a m s is N a t u r a l N u m b e r , B o o l e a n , N a m e s sorts String, E l e m e n t opns ( ) : ~ String collect : ~ Element nil : ---, E l e m e n t concat : Element, String ---, S t r i n g list : String, S t r i n g ~ String remove : String, E l e m e n t ---, S t r i n g encrypt : Element, String ---, S t r i n g decrypt : Element, String ~ String tail : Nat, String ~ Element _eqe_ : E l e m e n t , E l e m e n t --, Bool _neqe_ : E l e m e n t , E l e m e n t ~ Bool _eqs_ : String, String ---, Bool _neqs_ : String, S t r i n g ---, Bool _leeq_ : E l e m e n t , E l e m e n t ---, Bool keymap : Ident ~ Element str_ n u m _ c o n v : S t r i n g ~ Nat num_str_conv : Nat ~ String i d e n str c o n v : Ident ~ String str i d e n _ c o n v : String ---, I d e n t num_ elem_conv : Nat ~ Element elem_ num_ conv: Element ~ Nat iden_elem_conv : Ident --, E l e m e n t elem_ iden_ conv: Element ~ Ident eqns forall k,x,y,z: E l e m e n t , s,t: String, n :Nat, i d , i d _ a , i d b: I d e n t of sort S t r i n g e n c r y p t ( k , d e c r y p t ( k , s ) ) = y; d e c r y p t ( k , e n c r y p t ( k , s ) ) = y; encrypt(k,()) = ( ); decrypt(k,()) = ( ); t a i l ( n , ( ) ) = nil ; tail(O,concat(k,s)) = k;
.)
.)
V. Varadharajan / FormalDescription Technique
213
tail(succ(n), concat(k,s)) = tail(n,s); d e c r y p t ( k , e n c r y p t ( k , c o n c a t ( x , s ) ) ) = concat(x,s); e n c r y p t ( k , d e c r y p t ( k , c o n c a t ( x , s ) ) ) = concat(x,s); l i s t ( ( ) , s ) = s; list(eoncat(k,s),t) = concat(k,list(s,t)); r e m o v e ( ( ) , k ) = ( ); r e m o v e ( c o n c a t ( k , s ) , k ) = s; k neqe x ~ remove(concat(k,s),x) = concat(k,remove(s,x)); ofsort Bool x eqe x = true; x = y ~ x eqe y = true; x eqe y ~ x = y; x n e q e y = n o t ( x eqe y); ( )eqs( )=true; c o n c a t ( k , s ) eqs ( ) = false; ( ) eqs c o n c a t ( k , s ) = false; concat(k,s) eqs c o n c a t ( x , t ) = k eqe x a n d s eqs t; s n e q s t = n o t ( s eqs t); k e y m a p ( i d a) eqe k e y m a p ( i d b) --* i d a = i d b; id a=id b ~ k e y m a p ( i d a) eqe k e y m a p ( i d b); (x n e q e y), (x leeq y) ~ n o t ( y leeq x) = true; (x leeq y), (y leeq x) ~ (x eqe y) -- true; (x leeq y), (y leeq z) ~ (x leeq z) = true; x leeq x = true; ofsort E l e m e n t n u m _ e l e m _ c o n v ( e l e m _ n u m _ c o n v ( k ) ) = k; i d e n _ e l e m _ c o n v ( e l e m _ i d e n _ c o n v ( k ) ) = k; ofsort N a t str_ n u m c o n v ( n u m _ str_ c o n y ( n ) ) = n; e l e m _ h u m _ c o n v ( n u m _ e l e m _ c o n v ( n ) ) = n; ofsort I d e n t str_ i d e n _ c o n v ( i d e n _ str c o n v ( i d ) ) = id; elem _ i d e n _ c o n v ( i d e n _ e l e m _ c o n v ( i d ) ) = id; endtype (* .........................................................................
*)
t y p e R e f e r e n c e N o is A u t h _ P a r a m s sorts R e f _ n o o p n s m u m str c o n v : R e f _ n o ~ String str_ mum_ conv : String ~ Ref_ no mum_ elem_ conv: Ref_ no ---, E l e m e n t elem rnum conv: Element ~ Ref_no e q n s forall n: R e f _ n o , s: String, k: E l e m e n t ofsort R e f _ n o str_ m u m _ c o n v ( r n u m _ str_ c o n v ( n ) ) = n; e l e m _ m u m _ c o n y ( m u m _ e l e m _ c o n y ( n ) ) = n; ofsort String str_ m u m _ c o n v ( s t r _ m u m _ c o n v ( s ) = s; of sort E l e m e n t m u m _ e l e m _ c o n v ( e l e m _ r n u m _ c o n y ( k ) ) = k; endtype (* .........................................................................
*)
214
V. Varadharajan /Formal Description Technique
t y p e R a n d o m _ N o Set is N a t u r a l N u m b e r , Boolean sorts R n _ s e t o p n s a d d n o : N a t , R n set ---, R n set n o t _ i n : N a t , R n _ set ~ Bool i s _ i n : N a t , R n _ set ---, Bool eqns forall n,m: N a t , s: R n set ofsort R n _ set a d d _ no(n,add(n,s)) = a d d _ no(n,s); a d d _ n o ( n , a d d _ no(m,s)) = a d d _ n o ( m , a d d _ no(n,s)); ofsort Bool i s _ i n ( n , a d d _ n o ( n , s ) ) = true; n ne m ~ i s _ i n ( n , a d d _ n o ( m , s ) ) = is in(n,s); n o t _ in(n,s) = not(is_ in(n,s)); endtype (* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . t y p e Clock is A u t h _ Params, Boolean sorts T i m e opns time_elem_conv " Time ~ Element e l e m _ time_ conv : E l e m e n t ~ T i m e eqns forall t: T i m e K: E l e m e n t of sort T i m e elem_ time_ conv (time_ elem_ conv(t)) = t; ofsort E l e m e n t time_ elem _ c o n v (elem_ time _ c o n v (k)) = k; endtyp (* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . endspec (*
7. Extension of Specification T h e specifications d e s c r i b e d a b o v e d e s c r i b e two a u t h e n t i c a t i o n p r o t o c o l s as given in the S t a n d a r d s I S O / D P 9798 a n d in C C I T T X.509. This section briefly considers s o m e further extensions to the specifications that can be carried out. i. W h e n i n t e r p r e t i n g a specification as some sort o f d e s c r i p t i o n of w h a t can h a p p e n we need to include deviations f r o m the " c o r r e c t " beh a v i o u r that occur in n o r m a l situations. The specifications d e s c r i b e d a b o v e only c o n s i d e r the ideal b e h a v i o u r of the protocol. W e can extend this b y considering the b e h a v i o u r of the p r o t o c o l when various error situations that can arise such as c o r r u p t i o n of messages, loss of messages a n d b r e a k d o w n in connections. However, note that the S t a n d a r d s I S O / D P 9798 a n d C C I T T X.509 d o n o t consider such a b n o r m a l situations,
*)
*) .)
ii. T h e a b o v e d e s c r i p t i o n o f the t h r e e - w a y a u t h e n t i c a t i o n p r o t o c o l of X.509 can b e extended to include specification of i n t e r a c t i o n s between the users, the Certification A u t h o r i t y a n d the Directory. iii. T h e specification d e s c r i b e d a b o v e considers the case where there are two users ini a n d rec who assume the role of the i n i t i a t o r a n d receiver a n d have a c o m m u n i c a t i o n . This can be generalized to a m o r e real situation where we have a finite n u m b e r of users, each of w h o m can a s s u m e the role of the i n i t i a t o r c o m m u n i cating with a n y of the o t h e r users.
8. Discussion In this p a p e r , we have d e s c r i b e d two authentic a t i o n p r o t o c o l s in L O T O S that have been p r o p o s e d in the security field. These two p r o t o c o l s
V. Varadharajan / Formal Description Technique
have been s t a n d a r d i z e d b y the I n t e r n a t i o n a l bodies ISO a n d C C I T T respectively. W e feel that L O T O S is a powerful language, useful for p r o d u c ing concise a n d structured specifications. F u r t h e r L O T O S does also have analytical power to verify the desired properties of the specified systems. I n particular, as future work, it will be interesting to carry out s i m u l a t i o n a n d analysis of the specified protocols. T o be able to do this, adequate L O T O S tools are necessary. These are currently being developed within the Protocol E n g i n e e r i n g Project, at H P L a b s . [8].
References [1] ISO 8807: Information Processing Systems - Open Systems Interconnection LOTOS - A Formal Description
215
Technique based on the temporal ordering of observational behaviour(1988). [2] ISO/DP 9798: Data Cryptographic Techniques - Peer Entity Authentication Mechanisms using an n-bit secret key algorithm (1987). [3] CCITT X.509: The Directory - Authentication Framework (1987). [41 R. Milner, A caluculus of communicating systems, LNCS 92 (Springer-Verlag, Berlin 1980). [5] C.A.R. Hoare, Communicating Sequential Processes (Prentice-Hall, 1985). [6] H. Ehrig and B. Mahr, Fundamentals of algebraic specification 1: Equations and initial semantics, EATCS (Springer-Verlag, 1985). [7] Stewart Black, Introduction to LOTOS for protocol specification and verification, Internal Paper, HP-ISC, July 1988. [81 Stuart Johnston, SPIDER - Service and protocol interactive development environment, Technical Memo, HPLISC-TM-88-050.