United States Patent {19]
`Feigen et al.
`
`l|ll|llllllllIll|l||lll||||||||l|||||l||l[Illllllllllllllllllllllllllllll
`5,699,513
`Dec. 16, 1997
`
`USOO5699513A
`Patent Number:
`[11]
`[45] Date of Patent:
`
`[54]
`
`METHOD FOR SECURE NETWORK ACCESS
`VIA MESSAGE INTERCEPT
`
`[75]
`
`[73]
`
`[21]
`I221
`['51]
`[52]
`
`[5 8]
`
`[5 6]
`
`Inventors: Ronald Glen Feigen, Mesa; Paul
`Aerick Lambert, Scottsdale, both of
`Ariz.
`
`Assignee: Motorola, Inc., Schaumburg, lll.
`
`Appl. No.: 414,823
`Fil d:
`Ma . 31 1995
`e
`r
`’
`Int. Cl.6 .................................................... .. G06F 11/00
`US. Cl. ............... .. SETS/187.01; 395/ 186; 364/2225;
`364/2864
`Field of Search ............................. .. 395113701, 186,
`395118801; 380/4, 21, 23, 25; 364/2354,
`2365, 2225
`
`References Cited
`
`US PATENT DOCUMENTS
`2/1988 Savar .................................... .. 235/377
`4,727,243
`1/1989 Hann et al.
`364/200
`4,799,153
`5,434,920 7/1995 Cox et al. ....................... .. 380/49
`
`5,455,861 10/1995 Faucher et a1. ........................... .. 380/9
`5,499,297
`311996 Boekeit .... ..
`‘
`.... .. 380/21
`5,537,099
`7/1996 Liang ............ ..
`340182507
`5,560,008
`9/1996 Johnson et al. .
`..... .. 395/650
`5,577,209 11/1996 Boyle et a1. ..................... .. 395/20006
`
`Primary Examiner-Robert W. Beausoliel, Jr.
`Assistant Examiner-Dieu-Minh Le
`Attorney, Agent, or Finn-Jeffrey D. Nehr; Bradley J.
`Botsch, S1".
`[57]
`
`ABSTRACT
`
`Security is provided for an inside network (14) by a security
`host (26). Connection request messages sent from source
`hosts (22) in an outside network (12) are intercepted (94) in
`the security host (26) and prevented from being transmitted
`on the inside network (14)- The user of the source host (22)
`then establishes a connection (78) to the security host (26)
`where a dialog session (80, 98, 100) occurs to confirm the
`user’s authenticity and authorization. After the user is
`con?nned, the intercepted connection request message is
`released (116) for transmission on the inside network (14)
`where the intended application service will respond and a
`commu?ica?on s?ssioll Will 0011111161166
`
`16 Claims, 4 Drawing Sheets
`
`12
`1
`
`\
`
`V
`
`(
`
`{
`
`SOURCE HOST
`(CLIENT) “"
`\
`2?
`
`22
`\
`SOURCE HOST ‘a
`(CLIENT)
`
`g
`I
`
`REMOTE m REMOTE
`NETWORK
`NETWORK
`
`SOURCE HOST
`“' (CLIENT)
`k
`22
`
`; _
`¢
`
`22
`\
`SOURCE HOST
`(CLIENT)
`
`<—>
`
`\
`2o
`
`‘
`
`I
`20
`
`TRANSMISSION MEDIA
`n
`
`\18
`
`OUTSIDE NETWORK
`
`I4
`\
`INSIDE NETWORK
`24
`\
`
`n
`
`15
`
`32
`
`/n
`30
`
`25
`1 ,
`'
`SECURITY
`Hols-r
`
`l
`
`l
`
`TRANSMISSION MEDIA
`
`I
`
`i
`
`I28
`28‘
`DESTINATION HOST ". DESTINATION HOST
`(SERVER)
`(SERVER)
`
`(
`
`(
`
`6-D
`
`Google Ex. 1524, pg. 1
`
`

`
`US. Patent
`
`Dec. 16, 1997
`
`Sheet 1 of4
`
`5,699,513
`
`12
`I
`
`:
`
`REMOTE
`NETWORK
`
`REMOTE
`NETWORK
`
`\
`20
`
`“
`
`j
`20
`
`“
`
`=
`
`TRANSMISSION MEDIA
`M
`
`\
`
`SOuRcE HOST
`(CLIENT)
`\
`;
`22
`°
`
`22
`\
`sOuRcE HOST
`(CLIENT)
`
`\
`1'8
`
`4
`
`(
`
`‘
`
`SOURCE HOST :
`(CLIENT)
`\
`g
`22
`'
`
`22
`
`SOURCE HOST :
`(CLIENT)
`
`f
`
`I
`
`OUTSIDENETWORK
`
`14
`
`f
`
`INSIDE NETWORK
`24‘
`
`{
`
`L
`
`15
`\ FILTER
`/N
`30
`
`32
`'
`
`26
`‘
`SECURITY
`
`HOKST
`
`1
`
`TRANSMISSION MEDIA
`
`M
`
`H
`
`2s
`28
`I
`\
`1
`\
`DESTINATION HOST m DESTINATION HOST
`(SERVER)
`(SERVER)
`
`FIG. 1
`
`Google Ex. 1524, pg. 2
`
`

`
`US. Patent
`
`Dec. 16, 1997
`
`Sheet 2 of 4
`
`5,699,513
`
`34
`r
`
`36‘,
`SOURCE
`ADDRESS
`
`48
`~ (olglggDE
`50
`\ (IRESTBDE
`52
`\ s?ggéggl)
`
`54
`
`\
`
`:
`a
`
`ACCESS CONTROL LIST
`4g
`38‘ RF
`I
`/ DESTINATIDN
`PORT /
`ADDRESS
`
`44
`42 {
`FLAGS/ /
`PORT / PRDTD. / ACTION
`
`46
`I,
`
`*
`
`*
`
`*
`
`*
`
`:
`0
`
`/
`; (ouTSIDE NET)
`/
`j (OUTSIDE NET)
`/
`5 (INSIDE NET)
`
`'
`
`j (INSIDE NET)
`/
`/
`/
`/
`
`:
`0
`
`*
`
`*
`
`*
`
`*
`
`:
`0
`
`/
`j
`
`*
`
`‘A
`
`/
`; BLOCK
`/
`j
`;’
`/
`/
`5 SYNC ; FORWARD
`
`PASS
`
`/
`
`j “8%; j PASS
`/
`/
`/
`/
`/
`/
`/
`/
`
`:
`0
`
`:
`0
`
`FIG- 2
`
`CLIENT
`APPLICATION
`7'
`
`SECURITY
`SERvER
`7'
`
`APPLICATION
`SERVER
`7'
`
`FIG. 3
`
`5
`;
`/
`/
`i
`;
`j
`,
`3
`;
`;
`/
`§_
`
`_
`
`/
`';
`j
`,
`’
`;
`,
`,
`5
`;
`é
`/
`3
`
`_
`
`Z INTERCEPT FIRST
`; CONNECTION REQUEST
`; SECOND CONNECTION
`, REQUEST
`Z ACKNOWLEDGE SECOND
`; REQUEST
`; SECOND CONNECTION
`/ SESSION
`? RELEASE FIRST CONNECTION
`; REDuEsT TD INSIDE NETWORK
`’ ACKNOWLEDGE FIRST
`/ REQUEST
`1 FIRST coNNEcTIoN
`
`: SESSION
`
`Google Ex. 1524, pg. 3
`
`

`
`US. Patent
`
`Dec. 16, 1997
`
`Sheet 3 0f 4
`
`5,699,513
`
`56
`( CLIENT )
`
`58 OPEN WINDOW TO ESTABLISH
`CONNECTION WITH INSIDE
`APPLICATION SERVICE
`
`60 INITIATE CONNECTION
`‘1 REQUEST TO INSIDE
`APPLICATION SERVICE
`
`62
`
`SELECT SOURCE PORT NUMBER
`AND FORM CONNECTION
`REQUEST MESSAGE
`
`T
`SEND MESSAGE TOWARD
`INSIDE NETWORK
`
`~\
`
`76
`I
`OPEN WINDOW TO
`ESTABLISH CONNECTION
`WITH SECURITY SERVICE
`
`T
`
`78
`
`INITIATE CONNECTION
`REQUEST TO SECURITY
`SERVICE
`
`62
`
`ESTABLISH CONNECTION
`IF POSSIBLE
`
`CONDUCT SESSION
`WITH SECURITY SERVICE
`
`TIMEOUT
`
`TERMINATE
`CONNECTION
`
`‘96
`
`CONNECTION
`REQUEST
`ACKNOWLEDGED
`
`-
`
`Y
`
`80
`— CONDUCT SESSION
`
`a0
`
`MAXIMUM
`NUMBER OF REQUESTS
`MADE
`
`KILL
`PENDING REQUEST
`
`FIG. 4
`
`Google Ex. 1524, pg. 4
`
`

`
`US. Patent
`
`Dec. 16, 1997
`
`Sheet 4 of 4
`
`5,699,513
`
`DROP STALE
`CONNECTION
`REQUEST
`MESSAGES
`
`92
`
`SECURITY SERVICE
`
`88
`
`MESSAGE
`DIRECTED TO
`SECURITY s-ERvIcE
`
`N
`
`FIG. 5
`
`94
`’
`SAVE RECEIVED
`CONNECTION
`REouEsT AND
`Tl?msglfrp
`DUPLICMION
`
`SEND ACKNOWLEDGE
`98’ MESSAGE To souRcE
`
`‘
`OBTAIN USER
`, IDENTIFICATION
`IRON CLIENT
`100
`
`USER
`AUTHENTICATED
`
`FIND PENDING REQUESTS
`FOR THE SOURCE ADDRESS
`
`108
`
`110
`
`I
`SEND PENDING REQUEST
`LIST TO CLIENT
`
`OBTAIN USER SELECTION
`DATA FROM CLIENT
`
`104
`\
`SEND FAILED
`ACCESS
`MESSAGE To
`CLIENT
`
`TERMINATE ’ 106
`Y
`CONNECTION
`RELEASE SELECTED REQUEST
`To INSIDE NETWORK
`
`116
`
`Y
`
`Google Ex. 1524, pg. 5
`
`

`
`5,699,513
`
`1
`METHOD FOR SECURE NETWORK ACCESS
`VIA MESSAGE INTERCEPT
`TECHNICAL FIELD OF THE INVENTION
`The present invention relates generally to secure com
`puter networks, to computer network ?rewalls, and to tech
`niques for providing computer network security.
`BACKGROUND OF THE INVENTION
`Security for a computer network refers to preventing
`network users, and particularly undesirable users hereinafter
`referred to as hackers, from engaging in unwanted activities
`with respect to computers or peripheral devices on the
`network However, computer networks are in place to pro
`vide various services for certain authorized users who may
`need the services. Thus, network security involves an often
`complicated structure and/or technique for allowing certain
`users to use certain services while denying services to
`hackers.
`Network security provisions often incorporate a ?rewall.
`A ?rewall is a network node or collection of nodes con?g
`ured so that all data tra?ic passing into or out from a
`protected local network passes through the ?rewall. Fire
`walls may be used between a protected local network and an
`outside network, such as the Internet or the like. Desirably,
`only authorized data tra?ic passes through the ?rewall, and
`the ?rewall itself has a low likelihood of being compro
`mised. Firewalls often incorporate one or more ?lters. Filters
`selectively block certain classes of data tra?ic while allow
`ing other classes of data tra?ic to pass. Filtering decisions
`are usually based, at least in part, upon packet source and/or
`destination addresses.
`While conventional ?rewalls provide some degree of
`security, they often utilize ?ltering that is much too coarse
`to distinguish acceptable tra?ic from hacln'ng. For example,
`a ?lter may be programmed to allow tra?ic between the
`protected network and a particular remote address.
`However, this type of programming forms a serious security
`loophole because any port at the remote address may then be
`granted access to the protected network.
`If the ?lter is more precisely programmed to permit traffic
`with only a speci?c port at the remote address, then other
`wise acceptable tra?ic can be excluded. Acceptable tra?ic
`can be excluded because, as is a conventional process in the
`Intemet’s TCP/IP protocol, source port numbers are often
`arbitrarily chosen at the remote address. Even if a single
`remote host could be identi?ed for favorable treatment by a
`?lter, nothing prevents a hacker from accessing the protected
`network by gaining physical or logical access to this single
`favored remote host.
`A conventional improved security technique substitutes a
`proxy between a remote user and one or more local appli
`cation servers. This improvement may be used either alone
`or in connection with a ?rewall. In order to gain access to a
`local application server, the remote client must ?rst gain
`authentication and authorization through the proxy. Authen
`tication refers to a process by which a user proves his or her
`identity. Authorization refers to a process which decides
`which privileges are given to a presumably authentic user.
`Improvement results because a speci?c remote user and not
`a mere remote host is con?rmed. In other words, access is
`granted based upon authenticating a user and not upon
`recognizing an identity for certain approved remote equip
`ment. Additional security improvements may accrue from
`the use of encryption between applications running on the
`protected network and remote applications. Encryption may
`be used with or without proxies.
`
`2
`Unfortunately, these conventional security improvements
`suffer from a limited applicability. An existing infrastructure
`of server and client applications currently exist. These server
`and client applications for the most part do not accommo
`date communication through a proxy or encrypted commu
`nications. Consequently, the conventional security improve
`ment techniques cannot be used with the existing
`infrastructure without signi?cant infrastructure modi?ca
`tions. Such modi?cations to an entire infrastructure of server
`and client applications would be such an expensive and time
`consuming undertaking that such modi?cations are not
`practical.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`A more complete understanding of the present invention
`may be derived by referring to the detailed description and
`claims when considered in connection with the Figures,
`wherein like reference numbers refer to similar items
`throughout the Figures, and:
`FIG. 1 shows a block diagram of a computer network
`environment within which the present invention may be
`practiced;
`FIG. 2 shows an exemplary access control list which
`controls the operation of a ?lter;
`FIG. 3 shows a sequence of events which take place in a
`successful remote access session to an application server
`located on an internal network;
`FIG. 4 shows a ?ow chart of a client process performed
`in cooperation with a security host process; and
`FIG. 5 shows a flow chart of the security host process.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`
`FIG. 1 shows a block diagram of a computer network
`environment 10 within which the present invention may be
`practiced. Environment 10 includes an outside network 12
`and an inside network 14. Data tra?ic may pass between
`outside and inside networks 12 and 14 if it is allowed
`through a ?lter 16.
`Outside network 12 represents any system of software and
`hardware connected in a manner to support data transmis
`sion. In the preferred embodiments, outside network 12 is
`the Internet, and more speci?cally the TCP/IP connection
`oriented protocol suite utilized therewith, but this speci?c
`network and protocol is not a requirement of the present
`invention. Outside network 12 includes various transmission
`media 18 which couple to any number of remote networks
`20. Filter 16 also couples to transmission media 18. Within
`each remote network 20, any number of source hosts 22 may
`run any number of client applications that might possibly be
`used to remotely access services provided elsewhere in
`environment 10. (Note, the converse function of restricting
`access from a secure network to unsecured networks can
`also be controlled with the present method.)
`Inside network 14 is also a system of software and
`hardware connected in a manner to support data transmis
`sion. However, inside network 14 is the network for which
`the preferred embodiments of the present invention provides
`security. Transmission media 24 of inside network 14 couple
`to ?lter 16, a security host 26, and any number of destination
`hosts 28. A security service runs on security host 26, and any
`number of application services run on destination hosts 28.
`Users are persons who operate source hosts 22 in outside
`network 12 and the client applications running thereon. In
`accordance with the preferred embodiments of the present
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`65
`
`Google Ex. 1524, pg. 6
`
`

`
`5,699,513
`
`10
`
`15
`
`25
`
`30
`
`35
`
`3
`invention, only users whose identi?es are deemed authentic
`and who are authorized to do so may access application
`services residing on inside network 14. Filter 16 is desirably
`provided by a conventional ?ltering device, such as a router,
`bridge, gateway, or the like. However, nothing requires the
`?ltering device to function only as a ?lter. In the preferred
`embodiment, a main inside port 30 of ?lter 16 couples to
`transmission media 24 while a separate logging port 32
`directly couples ?lter 16 to security host 26. In alternative
`embodiments, security host 26 may be implemented within
`the same device that implements ?lter 16 (not shown) or as
`a separate device placed in series (not shown) between ?lter
`16 and transmission media 24. Thus, for at least certain types
`of packets, security host 26 resides intermediate to a source
`host 22 and a destination host 28 within environment 10.
`Moreover, security host 26 is desirably located physically
`and logically with inside network 14 where it is beyond the
`control of source hosts 22. As discussed below, security host
`26 and the security service which runs thereon provide
`transparent session control for inside network 14 at the IP
`layer of the TCP/IP protocol suite. Due to operation at the IP
`layer, the existing TCP/IP protocol suite, existing client
`applications, and existing server applications are all accom
`modated without modi?cation.
`FIG. 2 shows an exemplary access control list (ACL) 34
`which controls the operation of ?lter 16. ACL 34 represents
`a table stored in memory (not shown) of the node that
`implements ?lter 16. Generally, ACL 34 associates various
`items which are typically included with message control
`data in IP and other packet headers. These message or packet
`control data items are associated with actions that ?lter 16
`may take.
`For example, a TCP/IP packet typically speci?es a source
`address 36, a source port 38, a destination address 40, a
`destination port 42, and various ?ags/protocols 44 which,
`among other things, serve to identify a packet type. Action
`46 de?nes the operation of ?lter 16 when data items 36, 38,
`40, 42, and 44 from a packet header de?ne the speci?ed
`conditions.
`As shown at an entry 48, when a packer’s source and
`destination addresses indicate an entities in outside network
`12, ?lter 16 may be programmed to block the packet so that
`it cannot enter inside network 14. An entry 50 indicates that
`packets having a source address associated with inside
`network 14 and a destination address associated with outside
`network 12 may pass through ?lter 16. An entry 52 indicates
`that connection request packets with a speci?ed outside
`source address and an inside network 14 address are for
`warded to logging port 32 (see FIG. 1). In accordance with
`TCP/IP terminology, a connection request message or packet
`is called a sync packet. An entry 54 indicates that other types
`of packets with a speci?ed outside source address and an
`inside network 14 address are passed through ?lter 16.
`Those skilled in the art will understand that the speci?c
`lxogramming of ACL 34 will differ from one inside network
`14 to another inside network 14. Moreover, in alternate
`embodiments, the security service can be involved in
`dynamically programming ACL 34 to further restrict the
`passage of unwanted packets into inside network 14. For the
`purposes of the preferred embodiment, it is the forwarding
`of potentially permissible connection request messages to
`logging port 32 (see FIG. 1) and security host 26 (see FIG.
`1) that allows a security service to transparently provide
`security for inside network 14, as discussed below.
`FIG. 3 shows an overview of a sequence of events which
`take place in a successful remote access session to an
`
`4-5
`
`50
`
`55
`
`65
`
`4
`application server running on a destination host 28 located
`on internal network 14. FIGS. 4 and 5 discuss these events
`in greater detail. Referring to FIGS. 1 and 3, a client
`application running on a source host 22 sends a ?rst con
`nection request message toward an application service
`which resides on inside network 14. However, ?lter 16
`routes this ?rst connection request to security host 26, where
`a security service prevents it from being transmitted within
`inside network 14. The security service saves this ?rst
`connection request but does not return an acknowledgment
`to the client application.
`Next, the source host 22 sends a second connection
`request message toward inside network 14, but this second
`message requests connection to the security service. Filter
`16 may be programmed either to forward this second
`connection request message through logging port 32 or to let
`this particular connection request message pass through to
`inside network 14.
`The security service acknowledges the second connection
`request, and a communication session dialog between the
`source host 22 and the secm-ity service occurs through this
`second connection. During this session, the ?rst connection
`request is con?rmed by authenticating and authorizing the
`user who is operating the source host 22. After con?rmation,
`this second connection may be terminated. The security
`service then releases the ?rst connection request to inside
`network 14. The intended target application service located
`at a destination host 28 will then acknowledge the connec
`tion request, and a communication session based upon the
`?rst connection will commence.
`FIG. 4 shows a ?ow chart of a client process 56 performed
`in cooperation with a security host process, discussed below
`in connection with FIG. 5. Client process 56 is performed at
`a source host 22 in outside network 12 (see FIG. 1). As
`shown by dotted-line boxes, process 56 includes various
`tasks which are intended, but not required, to be performed
`in response to actions taken by a user.
`A user task 58 is performed to open a window within
`which a connection may be established with an application
`service on inside network 14. After the user opens this
`window, a task 60 is performed to initiate a connection
`request to the inside application service. Desirably, conven
`tional techniques and processes are used in tasks 58 and 60.
`Thus, security provisions provided through the operation of
`security host 26 are transparent to existing client applica
`tions. In other words, the user may use any client application
`to perform tasks 58 and 60 which would be compatible with
`the intended application server if the security provisions
`provided by security host 26 were not present.
`After task 60, and while additional user actions occur
`(discussed below), the source host 22 performs a process 62
`to establish a connection, if possible, with the target appli
`cation server located on inside network 14. Process 62
`includes a task 64 to select a source port number which is
`compatible with the TCP protocol. Task 64 may arbitrarily
`select the source port number. In addition, task 64 forms a
`connection request message, which is a legitimate sync
`packet in the TCP/IP protocol suite. This message speci?es
`a source address for the remote network 20 (see FIG. 1) upon
`which source host 22 is located, a destination address which
`corresponds to inside network 14, a port number associated
`with the application service to which connection is being
`requested, and control data which de?ne the message as a
`connection request message.
`Next, a task 66 sends the connection request message
`through transmission media 18 (see FIG. 1) toward inside
`
`Google Ex. 1524, pg. 7
`
`

`
`5
`network 14. After task 66, a query task 68 determines
`whether a time-out period following task 66 has expired. So
`long as the time-out period has not yet expired, a query task
`70 determines whether the connection request has been
`acknowledged. As discussed above in connection with FIG.
`3, this ?rst connection request message is intercepted at
`security host 26 (see FIG. 1) and does not immediately reach
`its intended destination. Thus, the connection request for the
`?rst message will not be immediately aclmowledged. When
`no acknowledgment is detected at task 70, program control
`loops back to task 68 to again test for a time-out.
`Due to the interception of the ?rst connection request
`message at security host 26, the time-out period is expected
`to, but need not, expire at least once. When this happens, a
`query task 72 determines whether a maximum predeter
`mined number of connection request retransmissions has
`been made. So long as this maximum number has not been
`reached, program control loops back to task 66 to again send
`the ?rst connection request message toward inside network
`14. If no acknowledgment of the ?rst connection request
`message is received by the time mat the maximum number
`of retransmissions occurs, a process 74 will be performed to
`kill the pending connection request. User actions will be
`required to attempt the connection again.
`While source host 22 is performing process 62, user
`actions are simultaneously causing source host 22 to per
`fonn a user task 76 and subsequent tasks. During task 76, the
`user opens a window within which a connection may be
`established with the security service running on security host
`26. After the user opens this window, a task 78 is performed
`to initiate a second connection request to the security
`service. Desirably, conventional techniques and processes,
`such as Telnet, are used in tasks 76 and 78.
`After task 78, process 62 is again performed to establish
`a connection if possible, but this time process 62 is per
`formed in connection with the second connection request
`rather than the ?rst. As discussed above in connection with
`FIG. 3, the second connection request is acknowledged
`immediately by the security service. Thus, program control
`quickly proceeds through this iteration of process 62 to a
`conduct session process 80 while the source host 22 con
`tinues to perform process 62 in connection with the ?rst
`connection request.
`During process 80, a task 82 is performed to conduct a
`portion of the communication session with the security
`service. In particular, this second connection session
`engages in a dialog with the user, which is discussed below
`in connection with FIG. 5. After task 82, a query task 84
`determines whether the session has ended. So long as the
`session has not ended, program control loops back to task 82
`to continue this second connection session.
`When the session is over, a process 86 is performed to
`terminate ?'re connection. Assuming that the user is authen
`ticated and authorized, the security service will release the
`?rst connection request it has intercepted within inside
`network 14, and the ?rst connection request will be
`acknowledged by the intended destination of the ?rst con
`nection request.
`When this acknowledgment is received at source host 22,
`task 70 routes program control out from process 62 relative
`to the ?rst connection request to conduct session process 80.
`During this iteration of process 80, the user and client
`application will have access to the application service pro
`vided on inside network 14. If the user is not authenticated
`or authorized or if too much time is consumed in the dialog
`session with the security service, no access to the application
`
`10
`
`15
`
`20
`
`25
`
`35
`
`45
`
`50
`
`55
`
`65
`
`5,699,513
`
`6
`service will be granted, and process 62 relative to the ?rst
`connection request will eventually kill the pending ?rst
`connection request at process 74.
`FIG. 5 shows a ?ow chart of a security service process 88
`which runs on security host 26. When a connection request
`message is received at security host 26, process 88 leaves an
`idle state and performs a query task 90. From time to time,
`process 88 also leaves the idle state and performs a task 92,
`which is discussed below. Task 92 may be performed
`simultaneously with and independent from other tasks in
`process 88.
`Query task 90 determines whether the received connec
`tion request message is directed to the security service or to
`some other application service on inside network 14. When
`the received connection request message is directed to
`another application service and not to the security service, a
`task 94 saves the received connection request with a current
`time stamp.
`In addition, task 94 saves the received connection request
`so that duplicate connection requests are eliminated. Dupli
`cates may, for example, be eliminated by saving connection
`request messages in an ordered list so that subsequent
`requests for the same connection over write their predeces
`sors. The elimination of duplicate connection request mes
`sages prevents retransmissions of connection requests dis
`cussed above in connection with FIG. 4 from being
`recognized as separate connection requests.
`After task 96, program control returns to the idle state.
`Over a period of time, any number of connection requests
`may be intercepted through tasks 94 and 96. However, some
`of the connection requests may be dropped, erased, or
`otherwise removed from consideration through the action of
`task 92.
`Process 88 performs task 92 from time to time to identify
`and drop stale connection request messages. Stale connec
`tion request messages are associated with time stamps
`indicating that a predetermined period of time has elapsed
`since they were intercepted. Thus, if a connection request is
`not acted upon within the predetermined period of time, it
`will be dropped so that it cannot later serve as the basis of
`a connection to an inside application service. After each
`iteration of task 92, program control returns to the idle state.
`When task 90 identi?es a connection request message
`directed to the security service, a task 98 sends the appro
`priate acknowledgment message to the source address and
`port number indicated in the connection request message.
`This causes the second connection communication session,
`discussed above in connection with FIGS. 3 and 4, to
`commence. During this second connection session, at a task
`100 process 88 sends an appropriate prompting message to
`the source to elicit user identi?cation data from the client
`application, and waits until such data are obtained. Of
`course, conventional time-out techniques (not shown) may
`be used to address the lack of a response.
`After task 100, a query task 102 authenticates the user. In
`other words, task 102 determines whether the user identi?
`cation obtained above in task 100 indicates that the user is
`an authentic user or a hacker. Together tasks 100 and 102
`form an authentication process the strength of which may
`vary in accordance with the needs of network 14. In the
`preferred embodiment, a one-time password process is rec
`ommended. A one-time password process requires a user to
`have an authenticator device which provides the one-time
`passwords that a user may enter and may be con?rmed in
`task 102. However, different systems may use dilferent
`authentication processes.
`
`Google Ex. 1524, pg. 8
`
`

`
`7
`When task 102 fails to con?rm the user’s authenticity, a
`task 104 is performed to send an appropriate failed access
`message to the client. Next, a task 106 takes any actions
`needed to continue to prevent requests associated with the
`user’s source host 22 from being released onto inside
`network 14. Thus, no connection will be made with the
`intended destination. Eventually, the user’s ?rst connection
`request will be dropped through the action of task 92. After
`task 106, program control returns to the idle state.
`When task 102 con?rms the user’s authenticity, a task 108
`investigates the currently pending intercepted connection
`request messages to identify those messages having the
`same source address as the source address used in the current
`session with the security service. Typically, only one con
`nection request will be pending because connection requests
`are intercepted for only a short period of time before being
`dropped by task 92. However, multiple connection requests
`may be pending for several di?’erent reasons. For example,
`the source address may identify a large institution, such as
`a university, from which multiple legitimate simultaneous
`connection requests might possibly originate. In addition, a
`hacker may be attempting to hijack the connection or the
`user’s own previous connection request may still be inter
`cepted and not dropped via the action of task 92.
`Next, a task 110 sends data describing these identi?ed
`pending requests to the client application, where they are
`displayed for the user, preferably in the form of a menu. In
`addition, task 110 sends an appropriate prompting message
`to the user to elicit a selection of one of the pending
`connection requests from the user. By reviewing the pending
`connection requests the user may determine whether suspi
`cious activities are taking place.
`After task 110, a task 112 obtains the selection data from
`the client. These selection data identify one of potentially
`several connection requests. After task 112, a query task 114
`determines whether the presumably authentic user is autho
`rized to access the application service identi?ed by the
`selection data obtained above in task 112. Task 114 may, for
`example, consider user privileges with respect to speci?c
`application services and/or the time of day. When task 114
`fails to oon?rrn the user’s authorization for the requested
`connection, program control proceeds to task 104 to return
`a failed access message. The requested connection will not
`occur.
`When task 114 con?rms that the user is authorized to
`access the requested application service, a task 116 releases
`the selected connection request message to inside network
`14. As discussed above, the selected application service will
`then acknowledge the mes sage and a communication session
`will commence. After task 116, program control returns to
`the idle state. Eventually, the connection request message for
`the just-completed connection will be erased from the
`memory of security host 26 via task 92.
`In summary, the present invention provides an improved
`method and apparatus for providing security for a commu
`nication network. The present invention provides network
`security which can achieve user authentication while
`remaining compatible with an existing infrastructure of
`server and client applications. Uncon?rmed connections are
`prevented from being established. In the preferred
`embodiment, communication session control is provided at
`the 1P level of the TCP/IP protocol suite used by the Internet,
`and the session control is transparent at TCP and application
`levels. The present invention may be implemented in a
`relatively simple con?guration of hardware and software at
`relatively low cost.
`
`50
`
`55
`
`65
`
`5,699,513
`
`10
`
`15
`
`25
`
`35
`
`8
`The present invention has been described above with
`reference to preferred embodiments. However, those skilled
`in the art will recognize that changes and modi?cations may
`be made in these preferred embodiments without departing
`from the scope of the present invention. For example, those
`skilled in the art will appreciate that the precise processes,
`task descriptions, and sequences described herein may be
`greatly modi?ed from implementation to implementation.
`These and other changes and modi?cations which are obvi
`ous to those skilled in the art are intended to be included
`within the scope of the present invention.
`What is claimed is:
`1. A method of providing security for a network having
`one or more application services to which connections may
`be made from outside said network, said method comprising
`the steps of:
`intercepting a plurality of connection request messages
`each of which establishes a ?rst connection request for
`an application service provided on said network;
`establishing a second connecti