Secure token passingat application level

Augusto Ciuffoletti

University of Pisa

Pisa – ITALYaugusto@di.unipi.it

http://dx.doi.org/10.1016/j.future.2009.12.003

What this paper is not about

● Many algorithms rely on a reliable token exchange (mutual exclusion, network overlay, etc)

● Few of them describe a protocol that effectively implements such operation

● None of them discusses an application level protocol

● Here we will not discuss an algorithm based on token exchange, but the token exchange itself

● Being implemented at the application level, it can be embedded in any sort of application

Basics of a token

● Token presence reflects in the state of the application

● Persistence of several tokens is to be avoided● Long periods of absence of token are to be

avoided● The token circulates fairly in the system● A token is never forged, or spoofed (by

unauthorized entities)

A token passing protocol

● The presence of a token on a host must induce, after some time– the release of the token inside the host holding it, and

– the presence of the token inside another host

● We consider that this operation (the token passing operation) is implemented with a protocol based on UDP datagrams

● In order to effectively implement the token passing operation, the protocol must fulfill some requirements...

Protocol requirements● Token passing latency is concentrated around a

value: this ensures fairness● Token passing failure with token loss is an

infrequent event: this event deteriorates the performance of the system

● Token duplication is deterministically excluded: it would be extremely difficult to detect and recover from this event

● The presence of several (distinct) tokens in the system is an infrequent event: it deteriorates the performance of the system

Protocol requirements

● The source of the token must be authenticated: this ensures that only trusted peers participate in token sharing

The above requirement entails the maintenance of a trust relationship among participants.It is the kind of problem that may be solved using a token based scheme, and is related with the topology used to circulate the token.Here we propose a “vanilla” solution...

Token circulation topology● We introduce a full mesh topology (all-to-all) and

a randomized circulation of the token● As a consequence, the membership consists of all

hosts sharing the token● Such membership relies on the existence of a

Certification Authority● All datagrams in the protocol are signed, and

exceptionally contain the certificate● Hosts maintain a cache of certificates, and public

keys of the peers

Host architecture

ReceiverProcess

SenderprocessUnix pipePort 9000

Tokenentershere

Tokenexitshere

LocalCacheread/update read

4-way token exchange protocol● Types of packets:

– Move pkt: submits token exchange

– Acknowledge pkt: accepts packet exchange

– Commit pkt: confirms token exchange

– EarlyStop pkt: stops resending Commit pkts

● All types except EarlyStop can be resent● Non conformant packets are silently

dropped● All packets are signed● Resent packets carry sender certificate

Sender process state diagramTransition notation:● event (rcv or timeout)● -------● action (send etc.)

Transition arrow:● blue: high probability● yellow: low probability● red: failure

Transition label:● green: send event

Receiver process state diagramTransition notation:● event (rcv or timeout)● -------● action (send etc.)

Transition arrow:● blue: high probability● yellow: low probability● red: failure

Transition label:● green: send event

Is it real?

● In order to assess the consistency of our specification, we implemented the specification using the Perl language

● It is about 700 lines of Perl code● Exchanged packets are about 50 bytes long, 4 per

token passing operation● The security issues are partially implemented in

the prototype: we use public keys instead of certificates issued by a cert. authority.

Does it work?

● In order to assess the conformace of the prototype with respect to the requirements we run two experiments

● The first experiment was run in the real Internet, using a testbed of three hosts located in Italy and Greece

● The purpose was to establish the robustness against Internet failures

● The token kept bouncing among the hosts for as long as 20 days (one bounce every 5 secs) before being lost

● More details reported in paper...

Does it work?

● Another experiment was run in a virtual network composed of 10 virtual hosts (using Netkit support)

● In that case, we injected token loss events and induced randomized delays

● Also in this case the results were satisfactory. They are not published in this issue.

Conclusions

● A communication protocol that ensures a reliable token passing operation is a basic building block

● An authentication mechanism is required in order to protect from disruptive intrusions

These results have been published in the Future Generation Computer Systems journal.

The Perl implementation of the protocol is available at the Wandering Token home page.

Useful links

● Augusto Ciuffoletti. Secure token passing at application level. Future Generation Computer Systems, 2010. doi:10.1016/j.future.2009.12.003.

● Wandering token home page: http://www.di.unipi.it/~augusto/WanderingToken/index.html