Table Of ContentLecture Notes in Computer Science 1550
Editedby G.Goos,J. Hartmanisand J.van Leeuwen
3
Berlin
Heidelberg
NewYork
Barcelona
HongKong
London
Milan
Paris
Singapore
Tokyo
Bruce Christianson Bruno Crispo
William S. Harbison Michael Roe (Eds.)
Security Protocols
6th International Workshop
Cambridge, UK, April 15-17, 1998
Proceedings
1 3
SeriesEditors
GerhardGoos,KarlsruheUniversity,Germany
JurisHartmanis,CornellUniversity,NY,USA
JanvanLeeuwen,UtrechtUniversity,TheNetherlands
VolumeEditors
BruceChristianson
ComputerScienceDepartment,UniversityofHertfordshire
HatfieldAL109AB,UK
E-mail:[email protected]
BrunoCrispo
UniversityofCambridge,ComputerLaboratory
NewMuseumsSite,PembrokeStreet,CambridgeCB23QG,UK
andUniversityofTurin,DepartmentofComputerScience
CorsoSvizzera185,I-10149Turin,Italy
E-mail:[email protected]
WilliamS.Harbison
NortelNetworks,HarlowLaboratories,LondonRoad
Harlow,EssexCM179NA,UK
E-mail:[email protected]
MichaelRoe
UniversityofCambridge,CentreforCommunicationsSystemsResearch
10DowningStreet,CambridgeCB23DS,UK
E-mail:[email protected]
Cataloging-in-Publicationdataappliedfor
DieDeutscheBibliothek-CIP-Einheitsaufnahme
Securityprotocols:6thinternationalworkshop,Cambridge,UK,
April15-17,1998;proceedings/BruceChristianson...(ed.).-
Berlin;Heidelberg;NewYork;Barcelona;HongKong;London;
Milan;Paris;Singapore;Tokyo:Springer,1999
(Lecturenotesincomputerscience;Vol.1550)
ISBN3-540-65663-4
CRSubjectClassification(1998):E.3,F.2.1-2,C.2,K.6.5,J.1
ISSN0302-9743
ISBN3-540-65663-4Springer-VerlagBerlinHeidelbergNewYork
Thisworkissubjecttocopyright.Allrightsarereserved,whetherthewholeorpartofthematerialis
concerned,specificallytherightsoftranslation,reprinting,re-useofillustrations,recitation,broadcasting,
reproductiononmicrofilmsorinanyotherway,andstorageindatabanks.Duplicationofthispublication
orpartsthereofispermittedonlyundertheprovisionsoftheGermanCopyrightLawofSeptember9,1965,
initscurrentversion,andpermissionforusemustalwaysbeobtainedfromSpringer-Verlag.Violationsare
liableforprosecutionundertheGermanCopyrightLaw.
(cid:1)c Springer-VerlagBerlinHeidelberg1999
PrintedinGermany
Typesetting:Camera-readybyauthor
SPIN10693156 06/3142–543210 Printedonacid-freepaper
Preface
You hold in your hands the proceedings of the sixth Cambridge Interna-
tionalWorkshopon Security Protocols. This annualevent is an opportunity for
researchers in acadaemia and industry to discuss new developments in the area
ofdistributed system security,usingvariousinsightsintothe generalnotionofa
protocolasapointofdeparture. Althoughyouwillalso(cid:12)ndplentyofinteresting
new results in this volume, our primary concern is to create a forum in which
researchers are free to discuss the limitations of current work: things we can’t
yet do, or don’t yet fully understand.
This year the theme ofthe workshop was the interactions between trust and
delegation, exploring the implications and e(cid:11)ects of these upon such issues as
authorization,securitypolicyandsystemandcomponentdesign.Asyouwillsee,
thisturnedouttobeafruitfulavenue.Thisvolumemarksareturntoouroriginal
intention for the format of the proceedings: we bring you a short position pa-
per fromeach contributor,deliberatelywritten toprovokereasoned controversy,
together with not-quite-verbatimtranscripts of the discussions which ensued.
Many thanks to Stewart Lee and the University of Cambridge Centre for
Communications Systems Research, for acting as hosts of the workshop, and
to Roger Needham and Microsoft Research Limited(Cambridge),for providing
us with an excellent venue and large amounts of co(cid:11)ee. This year’s workshop
marks twenty years since the publication of Needham and Schroeder’s \Using
Encryption for Authentication in Large Networks of Computers" and ten years
since the (cid:12)rst appearance of the BAN logic,so we were delighted to have Roger
in the chair for the (cid:12)nal panel discussion, a transcript of which concludes the
volume.
It is a pleasure to express our gratitude to Hitachi and Nortel for providing
(cid:12)nancialsupport.WearealsoindebtedtoRobinMilneroftheUniversityofCam-
bridge Computer Laboratory for his support and assistance. Finally,we would
like to thank Dorian Addison of CCSR for undertaking a Sisyphean burden of
administration,andLoriKlimaszewskaoftheUniversityofCambridgeComput-
ing Service for an excellent job of transcribing audio tapes full of \techie-talk
and coughing".
We use this workshop to guide our own research agendas, and we hope that
engaging with the discussions in these proceedings will also provide you with
some useful re(cid:13)ections upon your research, and maybe help inspire it in some
unexpected new direction. If this happens please write and tell us, we’d love to
hear fromyou.
Bruce Christianson
Bruno Crispo
WilliamHarbison
Michael Roe
Contents
Inductive Analysis of the Internet Protocol TLS
Lawrence C. Paulson ................................................... 1
Discussion ............................................................. 13
External Consistency and the Veri(cid:12)cation of Security Protocols
Simon N. Foley ........................................................ 24
Discussion ............................................................. 28
The Trust Shell Game
Carl Ellison ........................................................... 36
Discussion ............................................................. 41
Overview of the AT&T Labs Trust-Management Project
Joan Feigenbaum .......................................................45
Discussion ............................................................. 51
KeyNote: Trust Management for Public-Key Infrastructures
(cid:3)
Matt Blaze, Joan Feigenbaum, Angelos D. Keromytis .................59
Discussion - Trust Management............................................ 64
Application-Oriented Security Policies and Their Composition
(cid:3)
Virgil D. Gligor and Serban I. Gavrila ............................... 67
Discussion ............................................................. 75
Secure Fingerprinting Using Public-Key Cryptography
(cid:3)
Hiroshi Yoshiura, Ryoichi Sasaki and Kazuo Takaragi ............... 83
Discussion ............................................................. 90
Third Party Certi(cid:12)cation of HTTP Service Access Statistics
(cid:3)
Francesco Bergadano and Pancrazio De Mauro ....................... 95
Discussion ............................................................ 100
DelegatingTrust
William S. Harbison (Discussion) .....................................108
Delegationof Responsibility
Bruno Crispo ........................................................ 118
Discussion ............................................................ 125
Abuse of Process
Mark Lomas (Discussion) .............................................131
A New Concept in Protocols: Veri(cid:12)able ComputationalDelegation
Peter Landrock ........................................................137
Discussion ............................................................ 146
Delegationand Not-So SmartCards
(cid:3)
Bruce Christianson and James A. Malcolm ......................... 154
Discussion ............................................................ 158
Certi(cid:12)cation and Delegation
Michael Roe (Discussion) ..............................................168
Discussion - Di(cid:11)erences Between Academic and CommercialSecurity
Virgil Gligor, Peter Landrock, Mark Lomas, Raphael Yahalom
and John Warne ..................................................... 177
OptimisticTrust with Realistic eNvestigators
Raphael Yahalom ......................................................193
Discussion ............................................................ 203
Insider Fraud
Dieter Gollmann ......................................................213
Discussion ............................................................ 220
Panel Session - Future Directions
Stewart Lee, Joan Feigenbaum, Virgil Gligor and Bruce Christianson
Chair: Roger Needham ................................................227
Contributor Index ............................................. 241
Inductive Analysis of the Internet Protocol TLS?
(Position Paper)
Lawrence C. Paulson
Computer Laboratory, University ofCambridge, Cambridge CB23QG, England
[email protected]
1 Introduction
Internet commerce requires secure communications.To order goods, acustomer
typically sends credit card details. To order life insurance, the customer might
havetosupplycon(cid:12)dentialpersonaldata.Internetusers wouldliketoknowthat
such informationis safe from eavesdropping or tampering.
Many Web browsers protect transmissions using the protocol SSL (Secure
Sockets Layer). The client and server machines exchange nonces and compute
session keys from them. Version 3.0 of SSL has been designed to correct a flaw
of previous versions, where an attacker could induce the parties into choosing
an unnecessarily weak cryptosystem. The latest version ofthe protocol is called
TLS (Transport Layer Security) [1]; it closely resembles SSL 3.0.
Is TLS really secure? My proofs suggest that it is, but one should draw
no conclusions without reading the rest of this report, which describes how the
protocolwasmodelledandwhatproperties were proved.Ihaveanalyzedamuch
simpli(cid:12)ed form of TLS; I assume hashing and encryption to be secure.
My abstract version of TLS is simpler than the concrete protocol, but it is
still more complex than the protocols typically veri(cid:12)ed. We have not reached
the limit of what can be analyzed formally. The proofs were conducted using
Isabelle/HOL [4], an interactive theorem prover for higher-order logic. They
followthe inductive method [6], which has a clear semantics and treats in(cid:12)nite-
state systems. Model-checking is not used, so there are no restrictions on the
agent population, numbers of concurrent runs, etc.
The paper gives an overview of TLS (x2) and of the inductive method for
verifyingprotocols (x3). It continues by presenting the Isabelle formalizationof
TLS (x4) and outlining some of the properties proved (x5). Finally, the paper
discusses related work (x6) and concludes (x7).
2 Overview of TLS
A TLS handshake involves a client, such as a World Wide Web browser, and
a Web server. Below, I refer to the client as A (‘Alice’) and the server as B
? M. Abadi encouraged me to understand TLS and referred me to related work. J.
Margetson pointed out simpli(cid:12)cations to the model. C. Ballarin commented on a
draft. Research funded by the epsrc, grants GR/K77051 ‘Authentication Logics’
and GR/K57381 ‘Mechanizing Temporal Reasoning.’
B.Christiansonetal.(Eds.):Security Protocols,LNCS1550,pp. 1{12,1998.
(cid:13)c Springer-VerlagBerlinHeidelberg1998
2 Lawrence C. Paulson
(‘Bob’), as is customary for authentication protocols, especially since C and S
often have dedicated meanings in the literature.
At the start of a handshake, A contacts B, supplying a session identi(cid:12)er
and nonce. In response, B sends another nonce and his public-key certi(cid:12)cate
(my model omits other possibilities). Then A generates a pre-master-secret, a
48-byte random string, and sends it to B encrypted with his public key. A
optionally sends a signed message to authenticate herself. Now, both parties
calculatethemaster-secret M fromthenoncesandthepre-master-secret, usinga
secure pseudo-random-number function(PRF).Theycalculatesession keysfrom
the nonces and M. Each session involves a pair of symmetric keys; A encrypts
usingoneandB encrypts usingthe other.Before sendingapplicationdata,both
parties exchange (cid:12)nishedmessages to con(cid:12)rm all details of the handshake and
to check that cleartext parts of messages have not been altered.
A full handshake is not always necessary. At some later time, A can resume
a session by quoting an old session identi(cid:12)er along with a fresh nonce. If B
is willing to resume the designated session, then he replies with a fresh nonce
and both parties compute fresh session keys from these nonces and the stored
master-secret, M. Both sides con(cid:12)rm this shorter run using (cid:12)nishedmessages.
My version of TLS leaves out details of record formats, cryptographic algo-
rithms, etc.: they are irrelevant in an abstract analysis. Alert and failure mes-
sages are omitted: bad sessions are simply abandoned. I also omit the server
key exchange message, which allows anonymous sessions.
Here are the handshake messages in detail, as I model them, along with
comments about their relation to full TLS. Section numbers, such as tlsx7.3,
refer to the TLS speci(cid:12)cation [1].
client hello A!B :A;Na;Sid;Pa
The items in this message include the nonce Na, called client random, and
the session identi(cid:12)er Sid. Item Pa is A’s set of preferences for encryption and
compression. For our purposes, all that matters is that both parties can detect
if this valuehas been altered during transmission (tlsx7.4.1.2).
server hello B !A:Nb;Sid;Pb
B,in histurn, replies with nonceNb (server random)andhis preferences Pb.
server certi(cid:12)cate B !A:certi(cid:12)cate(B;Kb)
The server’s public key, Kb, is delivered in a certi(cid:12)cate signed by a trusted
third party. (The TLS proposal (tlsx7.4.2) speci(cid:12)es a chain of X.509v3 certi(cid:12)-
cates,butIassumeasinglecerti(cid:12)cationauthorityandomitlifetimesandsimilar
details.) Makingthe certi(cid:12)cate mandatoryand eliminatingthe server key ex-
changemessage(tlsx7.4.5)simpli(cid:12)esserver hello.Ileavecerti(cid:12)caterequest
(tlsx7.4.4) implicit: A herself decides whether or not to send the optional mes-
