A security scheme for resource sharing over a network

Computers & Security, 9 (1990) 67-75

A Security Scheme for Resource Sharing over a Network

The purpose oi hi.\ paper is to describe a sccuriry sclmnc for a

special purpose rewurcc-sharing systctn for ncrworkcd corn-- putcr,. The scl~cmc makes USC of cryptographic constructs

called coupon\, issued by a central authority, and rcprcscnting

th right to mc a ccrtaitl amount of rcsourccs on a spccificd

machc. The sccuriry schcmc tb dcscribcd in detail. and an

attalvsis ot tt\ wcuriry t5 also givctt.

~qwor~L: Sccuriq, Cryprograph). Computer network, Proto-

col. Authentication.

1. Introduction

T hc purpose of the schcmc dcscribcd hcrc is to provide security for a special purpose rcsourcc

allocation schcmc. WC suppose that, in a network ofcomputcrs, two conditions mist.

l Spare rcsourccs arc available, i.e. thcrc mist computers on the network which do not USC all their available CPU time.

l Jobs mist which rcquirc more computational effort than can bc provided by a single machine in a rcasonablc amount of time.

Wc then suppose that the owners of the undcr- used machines arc willing for their unused

rcsourccs to bc utilized by other users with rcsourcc shortages, as long as thcsc other users arc appropriately authorized.

111 this paper WC dcscribc a schcmc for providing such authorization information. This systcni uses the notion of a broker, who keeps details of all machines with spare rcsourccs, and allocates thcsc rcsourccs to other users who need them. This broker must bc trusted by all the cntitics within the network which is scrvcd. WC suppose that the computers on the network may bc cithcr users or suppliers of rcsourccs (or both). A supplier makes the offer of unused capacity to the broker. The broker then allocates thcsc rcsourccs to users who rcqucst them from the broker.

The protocol dcscribcd below bears sonic rcscm- blanccs to the Kcrbcros authentication protocol dcscribcd by Stcincr ct (I/., [ 1 11. Howcvcr, thcrc arc a number of significant diffcrcnccs. From a cryptographic point of view the most significant is that, unlike Kcrbcros, the protocol dcscribcd hcrc is indcpcndcnt of timestamps, and hcncc dots not rely on synchronized clocks. In addition, within its dcsigncd application it introduces no additional messages, and hcncc its ovcrhcads on the undcrly- ing communications systcni arc very low.

0167-4048/90/$3.50 0 1990, Elsevier Science Publishers Ltd. 67

J. Burns et aLlResource Sharing over a Network

2. The Protocol

2.1 Notation and Assumptions

The solution described in this paper relics on the use of conventional (symmetric) cryptography, as typified by the DES block cipher algorithm [ 1, 61. We assume that each user and supplier in the network shares a sccrct key with the broker, and that this sccrct key corresponds to an algorithm capable of being used both for data encryption (for confidentiality) and for corn utation authentication codes (MACS) or data integrity and P

of message

authentication. We denote the key shared by network entity E and the broker by K(E). Note that different versions of this key should be used for encryption and MAC computation; for cxamplc,

the key could be bit-wise cxclusivc or-cd with a fixed “mask” (not all zeros or all ones) when used for MAC computation.

We dcnotc by

EK [II

the encryption of the data I using key K, and we write

MK PI

for the MAC computed on the data I using the key K. The diffcrcncc bctwccn thcsc two concepts is that knowlcdgc of E, [I] and K cnablcs the rccovcry of I after the application of the appropriate dccryp- tion function, whereas MKII] is a short, fixed length checksum enabling dclibcratc or accidental modifications to data to be dctcctcd.

An cxamplc of a suitable algorithm is provided by the DES (or, for that matter, any other block cipher algorithm). Data encryption could bc achicvcd by using DES in the standardized cipher block chain- ing (CBC) mode [ 2, 7, 81, and the h4AC computation could again bc based on DES in CBC mode; see, for cxamplc. rcfs. 13, 4,9].

2.2 Resource Tickets and their Management

Fundamental to the operation of the proposed sys- tcm is the list of information on available rcsourccs kept by the broker. This list consists of a scrics of tickets, issued by rcsourcc suppliers 011 the ncrwork. Each ticket contains the following three items of information: the name of the supplier, a supplier serial number and a value paramctcr (qiv- ing an indication of the amount of rcsourccs biing offcrcd). This value paramctcr may, for csamplc, indicate an upper limit on CPU time, the type of processor involved and/or an u able RAM; the prccisc USC o F

per limit on avail- this paramctcr is

beyond the scope of this paper and will, in any cast, be very dcpcndcnt on the particular implc-

mcntation of this schcmc.

Each supplier will gcncratc one or more of thcsc tickets (possible of varying values) and send them to the broker in protcctcd form. As and when the tickets arc eventually used (as WC dcscribc below), and as further unused rcsourccs bccomc available, so the supplier gencratcs more tickets and supplies them to the broker. Serial numbers arc allocated by the supplier, and it is important that the supplier cnsurcs (a) that no rwo tickets with the same serial number arc issued and (b) that a record is kept of the serial numbers of outstanding (i.c. unused) tick- cts. This is ncccssary in order to prcvcnt rc-use of old tickets.

Marc formally, a ticket issued by supplier S has the form:

(S, N, V,)

whcrc N is the serial number, V, is the value and the USC of commas dcnotcs concatenation of data. The three items of information within the ticket arc prcciscly the items of information stored within the broker. When the ticket is shipped from the supplier to the broker it has the form

i.e. a MAC on all the data within the ticket is appended to the end of the ticket. This MAC is

68

Computers and Security, Vol. 9, No. 1

computed using the key shared by S and the broker. The use of this MAC enables the broker to check the validity of the ticket.

Before proceeding WC consider the deletion of stored tickets. As we described above, lists of tickets will need to be stored both by ticket suppliers and the broker. The broker deletes a ticket once it has been allocated to a particular user (as described in Section 2.3 below). The ticket supplier deletes a ticket when a user wishes to USC the resources spec- ified in it (see Section 2.4 below). However, in certain circumstances, neither of these types of event will occur. For example, the broker may never issue a ticket because of a shortage of users, and a user may not need to USC a resource requested from a broker, and hence the supplier will never get a request for resources corresponding to one of its stored tickets.

For this reason both the broker and the supplier will automatically delete tickets from their stores after a spccificd time interval (depending on the type of network involved). At worst this will have the effect of meaning that, occasionally, messages from users to suppliers will be rejected bccausc the corresponding tickets have expired and been dis- carded. To minimize the probability of this occur- ring it is probably wise for the broker to keep tickets for a shorter time than the supplier.

In many applications it may bc dcsirablc for suppliers of tickets to specify the lifctimc of their tickets. Details of how this may be achicvcd with only a small modification to the basic protocol are given in Section 4.3 below.

2.3 Resource Requests and Coupons

WC now consider how users rcqucst resources from the broker. Suppose user U wishes to make USC of spare rcsourccs on the ncrwork. U issues a request to the broker, which contains the following

two items of information: the name of the user and a value parameter V, giving an indication of the amount of resources required. As with the value parameter in supplier tickets, the precise nature of

the request value parameter is beyond the scope of this paper. These requests arc sent in protected form as follows:

i.e. a MAC on all the data within the request is appended to the end of the request. This MAC is computed using the key shared by U and the broker. The use of this MAC enables the broker to check the validity of the request.

On receipt of a request (given that the MAC check proves it to be valid) the broker will compare it with the outstanding tickets, and decide which of the tickets arc to be allocated to the requesting

user. This will be done using a process which might take into account the following: the privi- leges of the requesting user, the size of the value in the request and the number and values of the outstanding tickets.

For each ticket allocated to the requesting user, a coupon message is generated and sent (in protected form) to the requesting user. If the ticket being allocated to user U has the form:

(S, N, V,)

then the corresponding coupon message has the form

(S N, V,, U, M&S, N, V,, U, SK],

M,&, N, V,, U, SK])

(EK(U,[W

(hw) [SKI)

The coupon itself is the first part of the message, namely

(S, N, Vc. U, M&S, N, V,, U, SK],

M,& N, V,, U SK])

69


where SK is a session key randomly generated by the broker and unique to each coupon. Also sent with the coupon arc: a copy of the session key, SK, encrypted under the secret key shared by the user

and the broker

(EK(“)Wl)

and a copy of the session key, SK, encrypted under the secret key shared by the ticket supplier and the broker

(Elqs, PI)

When the broker sends such a coupon, the corrc- sponding ticket is dclctcd from its list. For each coupon (and accompanying keys) received by the user, the following proccdurc is followed.

l The copy of the session key SK cncryptcd under K(U) is dccryptcd and SK is recovered.

l The appropriate MAC on the coupon is then checked using K(U) and the rccovcrcd value of SK.

l If the MAC authcnticatcs the coupon, then the coupon is stored ready for USC, together with two other pieces of information: the session key for the coupon (SK), and the session key cncryptcd under the supplier’s secret key (as provided by the broker)

(EK(S)[SKl)

2.4 Resource Supply When the user rcccivcs the co~~po~~s from the broker, it is then up to the user to divide the task to bc pcrformcd mto smtablc picccs corresponding to the values in the coupons. WC now consider the process followed when a user wishes to USC a coupon.

The user, U, sends the coupon to the named supplier, S, (omitting the MAC computed using K(U) as this is of no USC to S), togcthcr with two other picccs of information.

l First, U also sends S a copy of the session key for the coupon cncryptcd under S’s sccrct key (as provided by the broker)

(EK(S, [SKI)

l Secondly, U sends all the ncccssary information about the task U wishes S to perform (probably including all the ncccssary cxccutablc code) authenticated using SK, i.e. if the task information

is T then U sends S

(TV MS, [TI)

U also stores information about the particular task T, togcthcr with the values S and N, so that, when the results of performing T arc rcturncd to U by S, they can bc matched to T.

When S rcccivcs the coupon and the associated task information, S follows the proccdurc below.

l The copy of the session key SK cncryptcd under K(S) is decrypted and SK is rccovcrcd.

l The MAC on the coupon is chcckcd using K(S)

and the rccovcrcd value of SK.

l The MAC on the task T is chcckcd using SK.

l If the MACs authcnticatc the coupon and the task to bc pcrformcd, and the serial number N corresponds to an m1rcdccmcd serial number stored within S. then the task T is cxccutcd.

l The ticket serial number, N, in this rcqucst is

dclctcd from the list of outstanding tickets.

When the given task has tcrminatcd, the results of performing the task arc rcturncd to U in a protcctcd form. Marc specifically, if l< rcprcscnts the results of performing the task T, then S returns to U the following:

70


whcrc the name of S and the serial number N identify uniquely to U which task T these results correspond to. This completes the description of the system’s operation.

3. Analysis of the Protocol

A system such as the one dcscribcd in the above section may bc subject to a variety of attacks by unauthorized third parties wishing to misappro- priatc rcsourccs. WC consider some of thcsc attacks, and cxaminc how the system resists them.

Bcforc proceeding note that the system dcscribcd dots not attempt to provide any confidentiality scrviccs for the tasks distributed around the network. Rather, the scheme is designed to protect

suppliers against misappropriation of their

rcsourccs. However, if they were ever rcquircd, confidentiality mechanisms could probably bc added to the above protocol without too much difficulty.

3.1 Replay Attacks Every mcssagc in the protocol dcscribcd above involves the USC of authentication cheeks (MACs) computed using sccrct keys. Thcreforc, given the MAC algorithm is sound, construction by unauthorized users of complctcly spurious mcssagcs is impossible unless keys bccomc compromised (we discuss this latter possibility in Section 3.2 below). Thus, apart from key compromise, the only possible attacks involve some form of replay.

WC now cxaminc in turn the cffccts of replaying each tvpc of mcssagc in the system. Thcrc arc csscntially five types of mcssagc in the above system: tickets sent from S to the broker, requests sent from U to the broker, coupons sent from the broker to U, coupons sent from U to S and results sent from S to U.

When transmitted from S to the broker, a ticket has the form

and all the data in the ticket is protcctcd by a single MAC. Thcrcforc in this cast the only possibility is to replay the mcssagc unchanged. If such a replay occurs, all that will happen is that the broker will store a duplicate ticket, and possibly issue a duplicate coupon to an unsuspecting user. If this dots occur the only harmful end result is that one of the two recipients of the duplicated coupon will have their request refused by the supplier bccausc the ticket has already been used. This is a minor problem and does not breach the security of the system.

When transmitted from U to the broker, a rcqucst has the form

and all the data in the request arc protected by a single MAC. Thcrcforc, as before, the only possibility is to replay the message unchanged. The end result will bc that U will be given coupons for which U has no real USC, and perhaps some of thcsc coupons will be wasted. A pcrsistcnt attacker of the system could rcpcatcdly do this, with the aim of diverting all the coupons to one user and thcrcby prcvcnting their allocation to gcnuinc users. The obvious way to allcviatc the cffccts of such an attack is to restrict the pcrccntagc of coupons which may bc allocated to any one user. Howcvcr, the main thing to note is that this attack would not comprise the basic integrity of the system, since no rcsourccs would bc allocated to unauthorized users. It has to bc rccognizcd that “denial of scrvicc” attacks can always bc launched against such

systems, in the cstrcmc simply by disrupting the communications bctwccn end users of the

network.

When transmitted from the broker to U, a coupon mcssagc has the form

(S, N. V,, U, M,,,,[S N, V,, U, SK],

(S N, If,, M,(,)(S, N, Y]) MKj,$, N, I/,, U, SK])

71


(EK(“) [SKI)

(EK(S,FI)

This message has three distinct parts; however, all three parts arc “bound together” by the value of SK, which is unique to this particular coupon. Thcrcfore the only possibility is to replay the message unchanged. The end result of such a replay will be that U ends up with two copies of the same coupon; if U tries to use both of them then the second will be rejected by the supplier S. This again does not represent a major hazard to the security of the system, since such events are bound

to occur occasionally because of the automatic deletion of tickets by suppliers.

When transmitted from U to S, a coupon message has the form

(S N V,, U, M,& N, V,, U, SK])

(T MS, [T])

(ElqS) WI)

This messa K

e has three distinct parts; howcvcr, just as before al three parts are “bound together” by the value of SK, which is unique to this particular coupon. Therefore the only possibility is to replay the message unchanged. The end result of such a replay will be for S to rcccivc two topics of the same coupon from U. The second will bc rejected by the supplier S, and so this attack again does not rcprescnt a major hazard to the security of the sysrcm.

When transmitted from S to U, a- results message

has the form

(R, S, N, M,,[K S, N])

and all the dara in the mcssagc arc protcctcd by a single MAC. Thcrcforc in this case the only possibility is to replay the mcssagc unchanged. This will mean that U gets two topics of the results of

performing the rcqucstcd task. The second will bc ignored since the two topics will bc idcntificd

as such by the rcpctition of N (the serial nunlbcr).

3.2 Deletion of Messages

The only obvious cffcct of dclcting any of the messages in transit is to prcvcnt the USC of a ticket issued by a supplier S. S will then bc left with an unused ticket in its list. This could happen anyway if a user U ncvcr cashes in a coupon issued by the broker. The simplest solution to the problem of accumulating unclaimed rcsourcc tickets is for all suppliers to discard unused tickets within a certain time interval of their issue, as described in Section 2.2.

3.3. Use of Cryptanalyzed Session Keys

It will be apparent that the protocol dcscribcd above bears many similarities co the protocol described in Nccdham and Schrocdcr [lo]. Unfor- tunately, this latter protocol is vulnerable to a certain special kind of replay attack if the confi-

dentiality of a session key is ever compromised; XC, for example, ref. [5].

The main difference bctwccn the protocol dcscribcd hcrc and the NcedhamAchrocdcr protocol is the use of serial numbers, which prcvcnt rc- USC‘ of coupons. This is a great advantage since it also prcvcnts the kind of attack possible on the Needham/Schrocdcr protocol. WC now describe

the potential attack in a little more detail.

Suppose that an intcrccptor, C say, of a coupon has, by some means, been able to discover the session key, SK, contained in the coupon. If the intcrccptor wishes to USC this information to steal

rcsourccs from the supplier of the corresponding ticket, then a mcssagc of the form

(S, N, v,, U, My,& N, V,, U, SK])

CT’, &$'I)

(EK(S) [SKI)

72


must constructed

knowlcdgc of the key K(S) which we must assume remains sccurc; of course, if this key was

then the entire system would bc

rcndcrcd Hcncc the only option for C is to copy these two parts from an obscrvcd message and forge the middle part (containing T’). This would work (with C impersonating

rcccived.

In summary, compromise belonging to a ticket will only compromise

resources to that ticket, and will not allow any other to be stolen. This is as much as one could cxpcct from a system of this type.

3.4 User Attacks

In our discussion above WC have considcrcd the cast whcrc an unauthorized third party wishes to steal rcsourccs from a supplier. WC conclude this analysis by considering the cast whcrc a valid user wishes to try and obtain more rcsourccs than arc allocated by the broker.

As in Section 3.3 above, such a user U must send a mcssagc of the following form to a supplier S:

6 N, vv U, M,(,)[S, N, V,, U, SK])

(T’, M\K [T’])

(%(s) [SK])

Howcvcr, user U is in no bcttcr a position than the third party C, dcscribcd in Section 3.3, to forge the first or third parts of such a mcssagc. It is thcrcforc not possible for a user to obtain rcsourccs not allo- catcd to it (unless the cryptographic fmlctions used arc insccurc or sccrct keys arc compromised).

4. Possible Extensions

Thcrc arc many ways in which the above protocol

could bc cxtendcd to provide additional facilities. We consider three such extensions hcrc.

4.1 Multiple Results Messages

The protocol dcscribcd above allows for the

resource supplier, S, to return a single results

message to the user, U. In some circumstances (par- ticularly if the task being undertaken by S is a long one) it would be desirable to allow S to return intermediate results mcssagcs.

Currently the defined protocol will only allow the

transmission of one such results message-all subscqucnt messages will bc rcjccted as replays. To modify the protocol to allow multiple results mcs- sage requires S and U to store and use an additional

serial number, P, say. The form of the results mcssagc will then be

(R S, N, P,, Ms,[JL 5 Nt J’iv])

In the first results message P, is set to 1. and is then incrcmentcd for each subscqucnt results mcssagc. U will only accept thcsc mcssagcs if the new value of P, is strictly larger than the previously rcccivcd value for this particular value of N. The USC of this serial number will prcvcnt replay attacks.

4.2 Splitting Tickets

When the broker rcccivcs a ticket from a supplier S, the value in the ticket may bc large compared with the values of coupon the broker is being rcqucstcd to issue. In such circumstances it would bc dcsirablc if the broker could divide the ticket into two or more parts and issue coupons whose values sum to the value of the ticket. One way in which this might bc achicvcd securely is as follows.

When the broker issues a coupon, (rcprcscnting part of the value of the ticket issued by supplier S with serial number N and value V,), an additional serial number C, is included. The number C, is initially set to 1, and subscqucntly incrcmcntcd cvcry time a new coupon is issued reprcscnting

73


part of the same ticket. The issued coupon will then have the form

(S, N, C,, V,, U, M&, N, C,, V,. U, SK].

M,&. N, G,, v,, U, SK])

whcrc V, rcprcscnts the value of the coupon and is not more than the value given to the issued ticket (VJ. The broker must cnsurc that the sum of the coupon values V, issued against a ticket ncvcr cxcceds the value of the ticket (i.e. Vc).

When U receives a coupon and USC’S it to issue a request, U not only stores information about the task T and the values S and N, but also stores the value C,. This value is used to help .match rcccivcd

results messages against stored requests. When U rcqucsts S to perform a task. the communication is just as dcscribcd in Section Z.-C, cxccpt that the coupon shipped from U to S now contains the value V,.

The ticket supplier, S, is also required to store additional state information, namely: the initial value of the ticket V,, the value so far consumed (;.c. the sum of the values V, of the coupons so far rcccivcd bearing the serial number of the ticket), and the values for the serial mmlbcrs C, so far rcccivcd. When a coupon is reccivcd rwo additional cheeks are pcrformcd: the coupon number C, is chcckcd against the stored value for this ,V to dctcct replays, and the value on the coupon. V,. is added to the value so far consumed, and a check is made to see that the total value dots not cxcccd the value originally assigned to this serial number h:.

Finally note that the only other chan~c to trans- mittcd messages is in the form of& the results mcssagc, which also includes the new serial num- bcr C,, and has the form

(K, S, N, C,, M,,$t. S, N, C,])

4.3 Limiting the Life of Tickets

The automatic cxpiry of tickets w;15 discussed in Section 2.2. Howcvcr, as mentioned in Section 2.2,

in some circumstances diffcrcnt suppliers mn~ Lvish to assign d’ff i crcnt (shorter) lifctimcs to their tickets. For csamplc a supplier may have rcsourccs available for a strictly limited period of rime. and may wish to specify that, after the cspir) of this time period. the ticket should not bc issued.

Of course. one simple strategy would bc for sup-

pliers to delete the tickets thcmsclvcs once the rcsourccs have ccascd to bc available. rcgardlcss of

the fact that the broker might still issue 3 corrcs- ponding coupon to a user. All that would happen is that the user’s rcqucst for rcsourccs would bc dcnicd. Howcvcr, a more cfficicnt solution might bc to include a lifctimc interval inside each ticket. The gcncral form of a rickct would then bc

(5 N, V,, T)

whcrc ?‘indicatcs the length of time that the ticket

should bc kept by the broker. If the ticket remains unused after time ‘I’ has c>lapscd, it is automaticall) dclctcd by the broker. Suppl icrs would nonnall)

keep tickets for a slightly longer time interval (as previously discussed).

One advantage of this schcmc is that it does not rcquirc synchronized clocks in order to opcratc correctly. All it rcquircs is that the brokcr’$ and supplier’s clocks run at roughly the same r:ltc (a very rcasonablc rcquircmcnt).

74


PI

181

PI

I ’ (‘1

rrtrrmriorr. International OrSanizarion for Standardizarion.

I Y88. It. M. Nccdbam and M. D. Schroeder, Using cncvption

for autbcntication in large networks of computers. Cow

,,,I,?,. .-lCIu 21 (1978) 003-WY.

J. G. Steiner, C. Ncutnan and J. 1. Scbillcr, Kcrbcros: An

.-

John Burns rcccived his H.Sc. dcgrcc in

n~arhcmatics and applicarions from the

University of 13inningham. U.K., in

lY77. Hc subsequently wwrkcd on

various real-tinx control and cone

Inunications producrs both in tbc U.K.

and the U.S. before joining Hewlert-

Packard’s European I&car& Labora-

tories in 13risto1, U.K.. in 1 Y80. Hc is

currently tbc Manager of tbc Network

Protocols Department. whose special intcrcsts include tbc &Ids

of sccuriry and fwnal specification of nctworkcd and sccurc

systcma.

Chris J. Mitchell is a Projecr Manager

within tbc Network Protocols Dcpart-

nlcnt at the Information Systems Ccntrc

of Hcwlctt-Packard Laboratories in

13ristol. U.K.. wbcre bc has worked s~ncc

198.5. Hc was prcviouslv Chief Mathc-

marician at I&al-C&cc Ltd. (Salis-

b UT. U.K.), whcrc hc bad been

I

employed since 1~70. Hc rcccived his

I%%. (I 075) and Pb.1). (IWO) dcgrcch in

Inatbctnatic\ from Wcstficld Collqc. London University. Hi\

rocarch intercst~ arc ill c ryptoloyy. data sccuriry and cwnbma-

torIa matbctnatic~. and IIC has publislwd over 30 pnpcrs and

patent\ III tbcsc &Ids. Hc 1s a fellow of tbc 13ritish Conlputcr

So+. a mcmbcr oi tllc Imtirution of Elcctncal En$uccrs. a

fellow of the Institute of Marhcmatics and its Applications and a n~cn~bcr of the Loudon Mathcmatica1 So&v.

75

Documents

A security scheme for resource sharing over a network