The 1996
`Symposium on Network and Distributed Systems
`Security
`(SNDSS'96)
`Hypermedia Proceedings, Slides, and Summary
`Report
`
`Table of Contents
`Copyright © 1996 Institute of Electrical and Electronics Engineers. Reprinted from The
`Proceedings of the 1996 Symposium on Network and Distributed Systems Security.
`
`This material is posted here with permission of the IEEE. Internal or personal use of this material
`is permitted. However, permission to reprint/republish this material for advertising or promotional
`purposes or for creating new collective works for resale or redistribution must be obtained from
`the IEEE by sending a blank email message to info.pub.permission@ieee.org
`
`By choosing to view this document, you agree to all provisions of the copyright laws protecting it.
`
`General Chair's Message
`Program Chairs' Message
`Organizing Committee
`Program Committee
`Privacy and Security Research Group
`Author Index
`
`Session 1: Electronic Mail Security
`Chair: Stephen T. Kent -BBN Corporation
`
`1. Mixing E-mail with BABEL
`C. Gulcü and G. Tsudik (abstract)
`2. An Integration of PGP and MIME
`K. Yamamoto (abstract)
`
`Session 2: Distributed Object Systems
`Chair: Danny M. Nessett -Sun Microsystems
`
`1. A Security Framework Supporting Domain-Based Access Control in Distributed Systems
`N. Yialelis and M. Sloman (abstract, slides)
`2. Panel - Scalability of Security in Distributed Object Systems
`Moderator: Danny M. Nessett -Sun Microsystems ( abstract)
`(cid:127) Bret Hartman -BlackWatch Technology ( slides)
`(cid:127) Danny M. Nessett -Sun Microsystems ( slides)
`(cid:127) Nicholas Yialelis - Imperial College, London
`
`New Bay Capital, LLC
`Ex. 1002-Page 57
`
`

`
`Session 3: Distributed System Security
`Chair: Michael Roe -University of Cambridge
`
`1. A Flexible Distributed Authorization Protocol
`J.T. Trostle and B.C. Neuman (abstract)
`2. Preserving Integrity in Remote File Location and Retrieval
`T. Jaeger and A.D. Rubin (abstract)
`3. C-HTTP - The Development of a Secure, Closed HTTP-Based Network on the Internet
`T. Kiuchi and S. Kaihara (abstract, slides)
`
`Session 4: Panel - Intellectual Property Protection
`Moderator: Peter Neumann -SRI International ( abstract)
`
`· Olin Sibert -Electronic Publishing Resources
`· Russell D. Housley -Spyrus ( slides)
`· Dan Boneh -Princeton University ( slides)
`
`Session 5: Network Security
`Chair: Matt Bishop -University of California at Davis
`
`1. Designing an Academic Firewall: Policy, Practice, and Experience with SURF
`M. Greenwald, S.K. Singhal, J.R. Stone, and D.R. Cheriton (abstract, slides)
`2. Digital Signature Protection of the OSPF Routing Protocol
`S.L. Murphy and M.R. Badger (abstract, slides)
`3. A Case Study of Secure ATM Switch Booting
`S-C. Chuang and M. Roe (abstract)
`
`Session 6: Key Management
`Chair: Burton S. Kaliski, Jr. -RSA Laboratories
`
`1. SKEME: A Versatile Secure Key Exchange Mechanism for Internet
`H. Krawczyk (abstract, slides)
`IDUP and SPKM: Developing Public-Key-Based APIs and Mechanisms for Communication Security
`Services
`C. Adams (abstract, slides)
`
`2.
`
`Session 7: Encryption
`Chair: Aviel D. Rubin -Bellcore
`
`1. An Empirical Study of Secure MPEG Video Transmissions
`I. Agi and L. Gong (abstract, slides)
`2. Parallelized Network Security Protocols
`E. Nahum, D.J. Yates, S. O'Malley, H. Orman, and R. Schroeppel (abstract, slides)
`3. A "Bump in the Stack" Encryptor for MS-DOS Systems
`D.A. Wagner and S.M. Bellovin (abstract, slides)
`
`Session 8: Panel - Public-Key Infrastructure
`Moderator: Warwick Ford -Bell-Northern Research ( abstract)
`
`· John Wankmueller -MasterCard International
`· Taher ElGamal -Netscape Communications ( slides)
`· Michael Baum -Verisign
`
`New Bay Capital, LLC
`Ex. 1002-Page 58
`
`

`
`General Chair's Message
`Welcome to the third annual ISOC Symposium on Network and Distributed System Security! Each year we
`seek to bring together researchers, implementors, and users of network and distributed system security facilities.
`This year our Program Committee has again done an outstanding job of selecting a mix of technical
`presentations and panel sessions to discuss and debate the issues we face today.
`
`As we are all aware, the need for usable distributed system security mechanisms is growing rapidly, tracking the
`growth and utilization of the world-wide Internet. For a welcome change, the general awareness of and interest
`in security is growing significantly as well _ by commercial organizations, the media, and private citizens. More
`than ever before, organizations will be looking to you, the participants of this symposium, for both technical
`solutions to specific problems and advice for the emerging public policy debates.
`
`I encourage you to take advantage of this Symposium to not only listen to the presentations but also share your
`own experiences and ideas with other attendees during the breaks and evening activities.
`
`Many thanks are in order for the behind-the-scenes effort that has culminated in this symposium: Tom Hutton
`"secured" our new location at the Princess Resort; Donna Leggett has done a superb job in handling the
`increased registration activities; and Stephen Welke has brought our Proceedings into the electronic age! I also
`want to commend the Program Co-Chairs, David Balenson and Clifford Neuman, for their excellent work with
`the Program Committee for pulling together the excellent program in which you are about to participate.
`Without the hard work by all these folks, this symposium would not have been possible.
`
`As always, I want to thank all the authors who submitted papers and the panelists who are participating by
`sharing their knowledge and experiences with us.
`
`Enjoy!
`
`James T. Ellis
`Carnegie Mellon University
`jte@cert.org
`
`Program Chairs' Message
`In the past year, the public has increasingly been urged to enter cyberspace and to use the Internet to obtain
`information from vendors, order products, and even bank from home. At the same time, businesses are being
`compelled to have a presence on the Internet, making information available to customers and other businesses.
`As a result, the need for network and distributed system security has grown dramatically.
`
`Today we find that the individuals trying to breach the security of computer systems are using more
`sophisticated attacks, and because such attacks now can yield business data or result in financial transactions,
`these attacks have become more lucrative. While the computer security discipline once addressed mostly
`hypothetical threats, the press has recently taken notice when attacks known by practitioners for years were
`suddenly perpetrated against widely-used and heavily marketed products including web servers and browsers
`and network file systems.
`
`There is good news and bad news regarding the state of Internet security. The good news is that most of the
`threats we are seeing have been known for some time, and we know how to protect against them. The bad news
`is that the solutions must still be integrated with applications, many of the solutions require a computer security
`infrastructure that is not widely available, and we have yet to see widespread deployment of computer security
`technologies.
`
`New Bay Capital, LLC
`Ex. 1002-Page 59
`
`

`
`The organizers of this symposium hope that the symposium will encourage the Internet community to deploy
`the available security technology and develop new technology in areas where it is lacking. In selecting papers
`and panels for the symposium, the program committee sought to bring together the papers that will have the
`greatest impact on the field by introducing new computer security technologies whether research prototypes or
`actual products, demonstrating the application of computer security technologies to Internet applications, and
`describing components of the computer security infrastructure.
`
`By bringing together researchers and practitioners in the field we are confident that the symposium will have a
`positive impact on the state of Internet security. We encourage you, as a participant in this symposium, to use
`this opportunity to actively participate in the dialog. Ask questions of the speakers, raise your important issues
`during relevant panel sessions, and let others know of your requirements, observations, and experience in this
`important area.
`
`B. Clifford Neuman
`Marina del Rey, California
`bcn@isi.edu
`
`David M. Balenson
`Glenwood, Maryland
`balenson@tis.com
`
`Organizing Committee
`General Chair
`James T. Ellis
`CERT Coordination Center
`Carnegie Mellon University
`jte@cert.org
`
`David M. Balenson
`Trusted Information Systems
`balenson@tis.com
`
`Program Chairs
`B. Clifford Neuman
`USC Information Sciences Institute
`bcn@isi.edu
`
`Publications Chair
`Stephen R. Welke
`Institute for Defense Analyses
`welke@ida.org
`
`Registrations Chair
`Donna Leggett
`The Internet Society
`leggett@linus.isoc.org
`
`Local Arrangements Chair
`Thomas Hutton
`San Diego Supercomputer Center
`hutton@sdslug.org
`
`Steering Group
`Internet Research Task Force, Privacy and Security Research Group
`
`Program Committee
`
`New Bay Capital, LLC
`Ex. 1002-Page 60
`
`

`
`Members
`Thomas A. Berson -Anagram Laboratories
`Matt Bishop -University of California at Davis
`Doug Engert -Argonne National Laboratory
`Warwick Ford -Bell-Northern Research
`Burton S. Kaliski, Jr. -RSA Laboratories
`Stephen T. Kent -BBN Corporation
`Paul A. Lambert -Oracle
`John Linn -OpenVision Technologies
`Teresa Lunt -Advanced Research Projects Agency
`Danny M. Nessett -Sun Microsystems
`Hilarie Orman -University of Arizona
`Michael Roe -University of Cambridge
`Robert Rosenthal -National Institute of Standards and Technology
`Aviel D. Rubin -Bellcore
`Jeffrey I. Schiller -Massachusetts Institute of Technology
`Robert W. Shirey -BBN Corporation
`Doug Tygar -Carnegie Mellon University
`Roberto Zamparo -Telia Research
`
`External Reviewers
`Carlisle Adams -Bell-Northern Research
`William Burr -National Institute of Standards and Technology
`Jan Carlsson -Telia Research
`Trent Jaeger -University of Michigan
`Stewart Kowalski -Telia Research
`Tim Moses -Bell-Northern Research
`Paul Van Oorschot -Bell-Northern Research
`Rich Schroeppel -University of Arizona
`Ola Sjögren -Telia Research
`Richard Thomas -Bell-Northern Research
`Jyri J. Virkki -Bellcore
`Michael Wiener -Bell-Northern Research
`Andrey Yeatts -University of Arizona
`
`Privacy and Security Research Group of the Internet Research Task
`Force
`Chair
`Stephen T. Kent
`BBN Corporation
`kent@bbn.com
`
`PSRG Committee Members
`
`David M. Balenson
`Trusted Information Systems
`balenson@tis.com
`
`Matt Bishop
`University of California, Davis
`bishop@cs.ucdavis.edu
`
`Warwick Ford
`Bell-Northern Research
`wford@bnr.ca
`
`Russell D. Housley
`Spyrus
`housley@spyrus.com
`
`New Bay Capital, LLC
`Ex. 1002-Page 61
`
`

`
`Burton S. Kaliski, Jr.
`RSA Laboratories
`burt@rsa.com
`
`B. Clifford Neuman
`USC Information Sciences Institute
`bcn@isi.edu
`
`Michael Roe
`University of Cambridge
`michael.roe@cl.cam.ac.uk
`
`Danny M. Nessett
`Sun Microsystems
`nessett@eng.sun.com
`
`Richard L. Parker, II
`SHAPE Technical Centre
`parker@stc.nato.int
`
`Robert Rosenthal
`NIST
`rosenthal@ecf.ncsl.nist.gov
`
`Jeffrey I. Schiller
`Massachusetts Institute of Technology
`jis@mit.edu
`
`Roberto Zamparo
`Telia Research
`Roberto.Zamparo@haninge.trab.se
`
`Author Index
`Adams, C. (IDUP and SPKM: Developing ...)
`Agi, I. (An Empirical Study of Secure MPEG ...)
`Badger, M.R. (Digital Signature Protection ...)
`Bellovin, S.M. (A "Bump in the Stack" ...)
`Cheriton, D.R. (Designing an Academic Firewall: ...)
`Chuang, S-C. (A Case Study of Secure ATM ...)
`Gong, L. (An Empirical Study of Secure MPEG ...)
`Greenwald, M. (Designing an Academic Firewall: ...)
`Gulcü, C. (Mixing E-mail ...)
`Jaeger, T. (Preserving Integrity in ...)
`Kaihara, S. (C-HTTP - The Development ...)
`Kiuchi, T. (C-HTTP - The Development ...)
`Krawczyk, H. (SKEME: A Versatile ...)
`Murphy, S.L. (Digital Signature Protection ...)
`Nahum, E. (Parallelized Network Security ...)
`Neuman, B.C. (A Flexible Distributed ...)
`O'Malley, S. (Parallelized Network Security ...)
`Orman, H. (Parallelized Network Security ...)
`Roe, M. (A Case Study of Secure ATM ...)
`Rubin, A.D. (Preserving Integrity in ...)
`Schroeppel, R. (Parallelized Network Security ...)
`Singhal, S.K. (Designing an Academic Firewall: ...)
`Sloman, M. (A Security Framework ...)
`Stone, J.R. (Designing an Academic Firewall: ...)
`Trostle, J.T. (A Flexible Distributed ...)
`Tsudik, G. (Mixing E-mail ...)
`Wagner, D.A. (A "Bump in the Stack" ...)
`Yamamoto, K. (An Integration of ...)
`Yates, D.J. (Parallelized Network Security ...)
`Yialelis, N. (A Security Framework ...)
`
`Return to the ISOC home page.
`
`New Bay Capital, LLC
`Ex. 1002-Page 62
`
`

`
`This page was last modified 17-January-1996.
`
`mailto:welke@ida.org
`
`New Bay Capital, LLC
`Ex. 1002-Page 63
`
`

`
`C-HTTP -- The Development of a Secure, Closed HTTP-based Network
`on the Internet
`
`Takahiro Kiuchi
`
`Shigekoto Kaihara
`
`Department of Epidemiology and Biostatistics
`Faculty of Medicine, University of Tokyo
`7-3-1 Hongo, Bunkyo-ku, Tokyo 113, Japan
`
`Hospital Computer Center
`University of Tokyo Hospital
`7-3-1 Hongo, Bunkyo-ku, Tokyo 113, Japan
`
`Abstract
`We have designed ”C—HTTP” which provides secure
`HTTP communication mechanisms within a closed group
`of institutions on the Internet, where each member is
`protected
`by
`its
`own
`firewall.
`C-HTTP-based
`communications are made possible by the following three
`components: a client-side proxy, a server-side proxy and
`a C-HTTP name server. A client-side proxy and server-
`side proxy communicate with each other using a secure,
`encryptedprotocol while communications between a user
`agent and client-side proxy or an origin server and
`server-side proxy are performed using current HTTP,/1. 0.
`In a C—HTTP—based network, instead ofDNS, a C-HTTP-
`based secure, encrypted name and certi ication service is
`used. The aim of C-HTTP is to assure institutional level
`security and is different in scope from other secure HTTP
`protocols currently proposed which are oriented toward
`secure end-to~end HTTP communications
`in which
`
`security protection is dependent on each end-user.
`
`1. Introduction
`In the medical community, there is a strong need for
`closed networks among hospitals and related institutions,
`such as coordinating centers for clinical trials or clinical
`laboratories. Secure transfer of patient information for
`clinical use is obviously essential.
`In addition,
`some
`medical
`information has to be shared among some
`hospitals, but it should not be made available to other
`sites. This includes, for example, infomiation concerning
`inulti-institutional clinical trials and documents for case
`conferences although patients’ names are usually not
`specified in such information. In this paper, we discuss
`the design and implementation of a closed HTTP
`(Hypertext Transfer Protocol)-based network (C-HTTP)
`which can be built on the Internet.
`
`2. Design and specification of C-HTTP
`2.1 Overview
`C-HTTP is assumed to be used in a closed group of
`institutions on the Internet,
`in which each member is
`protected
`by
`its
`own
`firewall.
`C-HTTP-based
`communication is made possible with the following three
`components: 1) a client-side proxy on the firewall of one
`institution, 2) a server-side proxy on the firewall of
`another institution and 3) a C-HTTP name server, which
`manages
`a given C-HTTP-based network and the
`information for its all proxies. A client-side proxy and
`server-side proxy communicate with each other using a
`secure, encrypted protocol (C-HTTP). Communications
`between two kinds of proxies and HTTP/1.0 compatible
`servers/user agents within the firewalls are performed
`based on HTTP/1.0 with current C-HTTP implementation
`undcr way[l]. The DNS name service is not used for
`hostname resolution as the original secure name service,
`including certification,
`is used for the C-HTTP-based
`network. A summary of the protocol specification is
`described in the Appendices.
`
`2.2 Security technology and key information
`In C-HTTP, five kinds of security technologies are used.
`They are: 1) asymmetric key encryption for the secure
`exchange of data encryption keys between two types of
`proxies and host information between a proxy and C-
`HTTP name server, 2) symmetric key encryption for the
`encryption of C-HTTP encrypted headers and HTTP/ 1.0
`requests, 3) electronic signature for the request/response
`authentication, 4) a one-way hash function for checking
`data tampering and 5) random key generation technology.
`In the C-H'1"TP name service, symmetric encryption is not
`used because the amount of information transferred is
`small.
`
`server—side proxy has its own
`Each client-side or
`private and public asymmetric keys and the C-HTTP
`name server's public key. Proxies do not exchange their
`
`0-8186-7222-6/96 $5.00 © 1996 IEEE
`Proceedings of SNDSS ’96'
`
`New Bay Capital, LLC
`
`New Bay Capital, LLC
`Ex. 1002-Page 64
`
`

`
`public keys with each other directly. Instead, the C—HTTP
`name server provides both client-side and server-side
`proxies with each peer's public key. In addition, Nonce
`values for both request and response are also generated
`and provided by the C-HTTP name server, which will be
`specified as
`initial
`values
`in Request-Nonce
`and
`Response—Nonce headers contained in the first C-HTTP
`request dispatched by a client-side proxy and in the first
`C-HTTP response dispatched by a server—side proxy,
`respectively. The C-HTTP name server manages its own
`private and public asymmetric keys and the public keys of
`all proxies which participate in the closed network. Two
`data encryption keys (syinrnetric keys) for requests and
`responses respectively are generated randomly during
`each C-HTTP session.
`
`An origin server which is compatible with HTTP/1.0 is
`responsible for user authentication if necessary. It uses
`the
`built-in HTTP/1.0
`authentication mechanism.
`
`ID, password and
`Information concerning a user's
`security realrn (HTTP/1.0) are encrypted by proxies and
`are transferred only in encrypted form through the
`Internet. Replay attacks are blocked by checking values of
`the Request-Nonce header field of each request.
`When a given institution wants to participate in a
`closed network,
`it must 1)
`install a client—side and/or
`server-side proxy on its firewall, 2) register an IP address
`( for a server—side proxy, a port number should also be
`registered) and hostname (Which does not have to be the
`same as its DNS name) for a firewall gateway, 3) give the
`proxy's public key to the C-HTTP name server, and 4)
`obtain the C-HTTP name server's public key.
`In the
`present C-HTTP specification,
`there is only one name
`server in a given C—HTTP network, although one can
`define any possible combination of closed subnetworks
`within the network.
`
`2.3 C-HTTP-based communication
`C—HTTP—based
`communication
`is
`follows:
`
`summarized
`
`as
`
`1) Connection of a client to a client-side proxy
`A client-side proxy behaves as an HTTP/1.0 compatible
`proxy, and it should be specified as a proxy server for
`external (outside the firewall) access in each user agent
`within the firewall.
`In C-HTTP,
`as different
`from
`ordinary HTTP, a session (virtual C-HTTP connection) is
`established between a client-side proxy and server—side
`proxy and, thus, it is not stateless. The session is finished
`when the client accesses another C-HTTP server or an
`ordinary WWW server or when the client-side or server-
`side proxy times out. The following ad-hoc mechanism is
`employed to define a session in stateless HTTP/1.0-based
`communication between a client-side proxy and user
`
`agent. Suppose that the HTML specified in Figure (21) is
`retrieved and sent to a client-side proxy after a C—HTTP
`session is established. In the client-side-proxy, the HTML
`document
`is rewritten as specified in Figure (b) and
`forwarded to a user agent. When one of these resource
`names with a connection ID, for example,
`"httpt//server.in. current. connectiori/sarnple. html=@,=6zd
`DfldfcZLj8V!i" in Figure (b), is selected and requested by
`an end—user, the client-side proxy takes off the connection
`ID and forwards the stripped, the original rcsource name
`to the server in its request as described in Figure (c).
`When the connection ID is not found
`in the current
`connection table in the client-sidc-proxy,
`the current
`connection is disconnected. Thus a new connection is
`established if the host is in the closed network and an
`
`ordinary HTTP/1.0 request is dispatched otherwise.
`
`2) Lookup of server-side proxy information (Appendix 3.
`a,b)
`A client-side proxy asks the C-HTTP name server
`whether it can communicate with the host specified in a
`given URL. If the name server confirms that the query is
`legitimate, it examines whether the requested server-side
`proxy is registered in the closed network and is permitted
`to accept the connection from the client-side proxy. If the
`connection is permitted, the C—HTTP name server sends
`the IP address and public key of the server—side proxy and
`both request and response Nonce values.
`If it
`is not
`permitted, it sends a status code which indicates an error.
`If a client-side proxy receives an error status,
`then it
`performs DNS lookup, behaving like an ordinary
`HTTP/ 1.0 proxy.
`Both the request to and response from the C—HTTP
`name
`server
`are
`encrypted
`and
`certified,
`using
`asymmetric
`key
`encryption
`and
`digital
`signature
`technology.
`
`for connection to the server-side proxy
`3) Request
`(Appendix 3. c)
`When the C-HTTP name server confirms that
`
`the
`
`specified server—side proxy is an appropriate closed
`network member, a client-side proxy sends a request for
`connection to the server-side proxy, which is encryptcd
`using the server-side proxy‘s public key and contains the
`client-sidc proxys IP address, hostname, request Nonce
`value and syniinetiic data exchange key for
`request
`encryption.
`
`4) Lookup of client-side proxy information (Appendix 3.
`de)
`for
`server-side proxy accepts a rcquest
`When a
`connection from a client-side proxy, it asks the C-HTTP
`
`New Bay Capital, LLC
`
`New Bay Capital, LLC
`Ex. 1002-Page 65
`
`

`
`Figure. Conversion of
`stateful C—HTTP
`
`stateless HTTP to
`
`a. The HTML document sent from a origin server to a
`c|ient—side proxy
`
`‘<T|TLE>SAMPLE< /TlTLE>
`<BODY>
`<A HREF =
`
`"http://server.in.current.connection/samp|e.htmI">
`Please click here.</A>
`<A HREF =
`E’
`"http://another.server.in.c|osed.network/">
`Another server.</A>
`</soov
`
`b. The HTML document rewritten and forwarded to a
`use agent by the c|ient—sIde proxy. The string,
`"6zdDfldfcZLj8V!i", attached to the end of the URLs
`is a connection ID
`
`<TlTLE>SAMPLE< /T|TLE>
`<BODY>
`<A HREF =
`
`"http://server.in.current.connection/samp|e.htm|=@
`=6zdDf|dfcZLj8V!i">
`Please click here.</A>
`<A HREF =
`
`"http://another.server.in.c|osed.network/=@=6zdDfi
`dfcZLj8V!i">
`Another server.</A>
`</BODY>
`
`c. HTTP/1.0 request from the user agent (1) and
`HTTP/1.0 request encrypted and wrapped in C—HT|'P
`request dispatched by the c|ient—side proxy (2)
`
`(1)
`GET "http://server.In.current.connection/
`samp|e.htm|=@= 6zd Df|dfcZLj8V!i"
`HTTP/I .0<CR><LF>
`
`(2)
`GET "http://server.in.current.connection/
`sample.htm|'
`H'I‘I’P/I .0<CR><LF>
`
`client-side proxy is an
`the
`server whether
`name
`appropriate member of the closed network. If the name
`server confirms that
`the query is legitimate,
`it
`then
`examines whether the client-side proxy is permitted to
`access to the server-side proxy. If access is permitted, the
`C—HTTP name server sends the IP address and public key
`of the client-side proxy and both request and response
`Nonce values, which are the same as those sent to the
`client—side proxy. The C-HTTP name server keeps both of
`the Nonce values for thiny seconds. If not,
`it sends a
`status code which indicates an error a11d the server-side
`
`proxy refuses the connection from the client-side proxy.
`
`5) Connection establishment (Fig. 2t)
`the client-side
`When the sever-side proxy obtains
`proxy's
`IP address,
`hostname
`and public key,
`it
`authenticates the client-side proxy, checks the integrity of
`the request and the request Nonce value and generates
`both a connection ID derived from the server-side proxy’s
`name, date and random numbers (32 bits) using MD5,
`and also a second symmetric data exchange key for
`response encryption, which are sent
`to the c1ient—side
`proxy. When the client-side proxy accepts and checks
`them, the connection is established.
`
`6) Sending C-HTTP requests to the server-side proxy (Fig.
`2g)
`Once the connection is established, a client-side proxy
`forwards HTTP/1.0 requests from the user agent
`in
`encrypted form using C-HTTP format.
`
`7) Forwarding requests to an origin server
`Using HTTP/1.0, a server-side proxy communicates
`with an origin server inside the firewall. From the view of
`the user agent or client-side proxy, all resources appear to
`be located in a server-side proxy on the firewall. In reality,
`however,
`the server-side proxy forwards requests to the
`origin server.
`It is possible to map any of the Virtual
`directories on the server-side proxy to any of the
`directories in one or more origin servers inside the
`firewall.
`
`8) Origin server responses to the user agent through the
`server-side and c1ient—side proxies (Fig. 2h)
`An HTTP/1.0 response sent from the origin server to
`the server-side proxy is encrypted in C-HTTP format by
`the server-side proxy, and is forwarded to the client-side
`proxy. Then,
`in the client-side proxy,
`the C-HTTP
`response
`is decrypted a11d
`the HTTP/ 1.0
`response
`extracted. Ifthe transferred object is in HTML format, the
`connection ID is attached to the anchor URLs contained
`
`in the document. The resulting HTTP/1.0 response is sent
`to the user agent.
`
`New Bay Capital, LLC
`
`New Bay Capital, LLC
`Ex. 1002-Page 66
`
`

`
`9) Request for closing the conriectiou (Appendix 3. i.j)
`A client-side proxy can send a request for closing the
`connection. The server-side proxy returns a status which
`indicates the connection is closed. On the other hand, if
`the server-side proxy detects that a given connection
`times out,
`it deletes
`the connection ID from the
`connection list, informing the client-side proxy that the
`connection is closed when an error status is returned in
`response to the request.
`
`3. Trial implementation
`Trial implementation is under way using 1) RSA as the
`asymmetric key encryption method (OSISEC RSA
`library)[2], 2) DES as the syiniuetric key encryption
`method (GNU DES library)[3], 3) RSA as the electronic
`signature method (OSISEC RSA library) and 4) a one-
`way hash function based on MD5[4]). As for random key
`generation, programs included in the OSISEC RSA
`library and GNU DES library are used for RSA
`asymmetric keys and DES symmetric keys, respectively.
`In the implementation, we employed the following
`methods to enhance security.
`
`1) Key protection
`In C-HTTP, keys are stored only on the firewall of a
`given institution. C-HTTP proxy software is provided as
`source code, and the keys are designed not to be stored in
`a separate "key file," A key generation program generates
`a C program file, which contains key information for
`proxies.
`It
`is more difficult
`to steal keys using this
`method than if they were stored in a separate file.
`
`2) No simultaneous data transfer to both sides
`Only after receiving all the data transferred from one
`side, does a proxy sewer begin to forward it to the other
`side, except for image and sound data. In this method, the
`performance of data transfer is not good, however,
`the
`data transfer
`is separated between the internal and
`external sides. For the secure implementation of this
`feature, the size of HTML documents and object bodies
`should be limited and checked by each proxy. We plan to
`implement routines which check the contents of object
`bodies (especially concerning form data used in POST
`method) in the future.
`
`3) Closure of TCP connection after each transaction
`C-HTTP itself is stateful, but the TCP connection is
`closed after each transaction (request and response pair)
`in order to reduce the possibility of it being intercepted by
`attackers.
`
`4. Discussion
`
`4.1 Why HTTP‘?
`It
`is possible to develop a secure application level
`protocol available only to a closed group in the Internet,
`making use of cipher technology. The reasons we chose
`HTTP as
`the communication protocol
`for a closed
`network are as follows:
`
`I) Flexibility of HTTP
`have been
`protocols
`level
`Different
`application
`developed for individual network services, such as FTP,
`SMTP, NNTP or GOPHER[5],[6],[7],[8]. HTTP has the
`flexibility to be able to provide services similar to those
`which have been provided by these protocols . For
`example, file transfer by FTP is accomplished by the
`object
`transfer
`iuechanism of HTTP and,
`from a
`functional viewpoint,
`the Gopher protocol can be
`considered a
`subset of HTTP.
`Internet news
`and
`electronic mail services are available with an HTTP-
`based graphical user interface via gateways for protocol
`co11versions[9]. Electronic mail services within a given
`group of institutions can be also developed using HTTP
`and CGI (Common Gateway Interfaee)[10].
`
`2) Hypertext-based user-friendly graphical interface
`Using HTTP and the Hypertext Markup Language
`(HTML), distributed multimedia information systems
`with user-friendly graphical interfaces based on hypertext
`can be easily developed[l 1].
`
`3) User agents and servers available on almost all
`platforms
`HTTP has now gained widespread popularity and
`various kinds of user agents and servers are available on
`almost all platforms. Even if new protocols for closed
`networks are developed which are superior in function or
`flexibility, new clients and servers have to be developed
`for compatibility, which is costly and an obstacle to their
`universal acceptance.
`
`4.2 Proxy—proxy vs. end—to-end secure HTTP-
`based information exchange
`As for hospitals, from which the Internet is available,
`in-hospital networks are usually protected using a dual
`home gateway and packet filter (firewall) and the Internet
`can only be accessed through proxies on the firewalls.
`The role of proxies in HTTP communication has been
`considered as important in communicating over firewalls
`and transferring information efficiently by caching. Other
`secure HTTP protocols are designed to be implemented in
`origin servers and user agents in order to assure "end-to-
`end" security protection[l2-15]. Our approach is aimed at
`
`New Bay Capital, LLC
`
`New Bay Capital, LLC
`Ex. 1002-Page 67
`
`

`
`assuring proxy-proxy security and is
`different from theirs.
`
`fundamentally
`
`All proposals for secure HTTP communications are
`designed to be secure against the following attacks: 1)
`network tampering, 2) replay attacks and 3) middle of the
`man attack[l 2-15]. C-HTTP is also designed to be secure
`against these attacks and, in addition, it has the following
`enhancements for security protection.
`
`No end-user has any chance to obtain keys for
`1)
`encryption or decryption.
`Much cost and time are necessary to decode ciphers
`which have been used for a long time and are considered
`confidential, such as DES or RSA, so an easier and more
`practical way to obtain original
`information is not
`to
`decode them, but to "steal a key" instead. It is not realistic
`for hospital
`information managers to expect
`that all
`individual end-users,
`including those who connect their
`PCs to in—hospital LANs, manage their keys in a secure
`manner.
`
`As currently proposed secure HTTP protocols aim at
`providing end-to-end security mechanisms, responsibility
`for sccurity is attributed to each individual user. Secure
`transfer of data
`exchange keys
`is
`performed by
`exchanging public keys (in most Cases with certificates)
`between both parties In this situation, once a private key
`is stolen it is possible to obtain information from WWW
`servers outside the hospital.
`Undoubtedly,
`the purpose of security protection is
`secure
`commercial
`information services
`or on-line
`
`shopping services which are provided by profit-making
`companies for the masses. For commercial services, it is
`reasonable that individual users (payers) are responsible
`for "their own risks," but, as for patient information, it is
`each hospital
`that
`should be responsible for
`"their
`patients‘ risks.“ Each hospital should take measures to
`assure security at the institutional level.
`
`2) Name service
`As C-HTTP includes its own secure name service,
`which contains a certification mechanism, it is impossible
`to know the IP address of a server-side proxy even if its
`C-HTTP hostname (not necessarily the same as its DNS
`name )
`is known and vice versa. The C-HTT? name
`service is eflicient because it can do name resolution and
`host certification simultaneously.
`
`3) Difficulty in accessing from outside the closed network
`lt is difficult to access any servers in a closed network
`from outside. A cracker has to take the following steps:
`
`a) To find the IP address and port number of a server-side
`proxy
`
`b) To get the public key of the server-side prmy in order
`to send a valid C-HTTP request for C-HTTP con