(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2001/0009025A1
`Ahonen
`(43) Pub. Date:
`Jul.19, 2001
`
`US 2001 OOO9025A1
`
`(54) VIRTUAL PRIVATE NETWORKS
`
`(76) Inventor: Pasi Matti Kalevi Ahonen, Oulu (FI)
`
`Correspondence Address:
`Ronald L. Grudziecki
`BURNS boANE, SWECKER & MATHIS
`L.L.P. 9
`9
`9
`Po. Box 1404
`Alexandria WA 22313-1404 (US)
`
`9
`
`(21) Appl. No.:
`
`09/764,661
`
`(22) Filed:
`(30)
`
`Jan. 18, 2001
`Foreign Application Priority Data
`
`Jan. 18, 2000 (GB)......................................... OOOO961.3
`
`Publication Classification
`(51) Int. Cl." ............................. H04L 12/22; H04L 9/00
`(52) U.S. Cl. ........................... 713/161; 713/151; 713/201
`(57)
`ABSTRACT
`A Secure communication method for allowing a mobile host
`1 to communicate with a correspondent host 4 over a Virtual
`Private Network. The method comprises negotiating one or
`more Security Associations (SAS) between the mobile host
`1 and a correspondent host 4 of a Virtual Private Network
`(VPN). Subsequently, a communication is initiated between
`the mobile host 1 and a SG 3 and an authentication certifi
`cate Sent to the SG 3, the certificate containing at least the
`identity of a SA which will be used for Subsequent commu
`nication between the mobile host and the correspondent
`host. Data packets can then be sent from the mobile host 1
`to the correspondent host 4 using the identified SA, Via the
`SG 3. However, the data packets are forwarded by the SG 3
`to the correspondent host 4 only if they are authenticated by
`the SG 3.
`
`Negotiate ISAKMP phase 1 SA between mobile host and firewal
`
`Negotiate multiple IPsec phase 2 SAs
`between mobile host and firewall
`
`Negotiate ISAKMP phase 1 SA between
`mobile host and correspondent host
`
`Negotiate multiple LPsec phase 2 SAs between
`mobile host and correspondent host
`
`Send certificate from roaming mobile
`host to firewa (over pre-exitingSA)
`
`Firewal
`authorises mobile
`lost
`
`Identify SA to be used to correspondent host
`
`Send encrypted user data packets and associated authentication
`packets from mobile host to firewall using respective SAs
`
`For each packet, pass from firewall to
`correspondent host if authenticated
`
`
`
`Does traffic
`counter exceed
`pre-defined
`imit for SA
`
`Delete SA from SA and select new SA
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 1
`IPR2019-00821, Apple Inc. v. MPH Technologies Oy
`
`

`

`Patent Application Publication
`
`Jul. 19, 2001
`
`Sheet 1 of 3 US 2001/0009025 A1
`
`Figure 1
`
`
`
`IKE Phase 1
`
`IKE Phase 2
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 2
`IPR2019-00821, Apple Inc. v. MPH Technologies Oy
`
`

`

`Patent Application Publication
`
`Jul. 19, 2001
`
`Sheet 2 of 3 US 2001/0009025 A1
`
`
`
`
`
`
`
`
`
`
`
`IKE MESSAGES IN Phase 1
`
`Generate key/1
`Generate key/2
`
`Authenticate/1
`
`Authenticate/2
`
`Algorithm
`Negotiation
`
`Diffie-Hellman
`Key Generation
`
`Peer authentication
`
`QUICKMODE MESSAGES (Phase 2)
`(IPsec) SA Proposal(s)
`
`
`
`Initiator
`
`Selected (IPsec) SA
`
`Liveliness hash
`(conclusion)
`
`Figure 4
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 3
`IPR2019-00821, Apple Inc. v. MPH Technologies Oy
`
`

`

`Patent Application Publication
`
`Jul. 19, 2001
`
`Sheet 3 of 3 US 2001/0009025 A1
`
`Negotiate ISAKMP phase 1 SA between mobile host and firewall
`
`Negotiate multiple IPsec phase 2 SAs
`between mobile host and firewall
`
`Negotiate ISAKMP phase 1 SA between
`mobile host and correspondent host
`
`Negotiate multiple IPsec phase 2 SAs between
`mobile host and correspondent host
`
`Send certificate from roaming mobile
`host to firewal (over pre-exiting SA)
`
`Firewa
`authorises Inobile
`host?
`
`
`
`No.
`
`End
`
`Yes
`
`Identify SA to be used to correspondent host
`
`Send encrypted user data packets and associated authentication
`packets from mobile host to firewall using respective SAs
`
`For each packet, pass from firewall to
`correspondent host if authenticated
`
`
`
`Does traffic
`counter exceed
`pre-defined
`imit for SAR
`
`
`
`Delete SA from SAD and select new SA
`
`Figure 5
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 4
`IPR2019-00821, Apple Inc. v. MPH Technologies Oy
`
`

`

`US 2001/0009025 A1
`
`Jul. 19, 2001
`
`VIRTUAL PRIVATE NETWORKS
`
`FIELD OF THE INVENTION
`0001) The present invention relates to Virtual Private
`Networks and in particular to Virtual Private Networks in
`which a mobile terminal establishes a Secure connection
`with a correspondent host located in an intranet, via a
`Security Gateway.
`
`BACKGROUND OF THE INVENTION
`0002 There is an ever increasing demand for mobility in
`communications Systems. However, this demand must be
`met in a manner which provides for the Secure transfer of
`data between communicating parties. A concept known as
`the Virtual Private Network (VPN) has recently been intro
`duced, with the aim of Satisfying, by a combination of
`encryption and Secure access, this demand. A VPN may
`involve one or more corporate Local Area Networks (LANs)
`or intranets, as well as users coupled to “foreign' LANs, the
`Internet, wireleSS mobile networks, etc.
`0003) An Internet Engineering Task Force (IETF) stan
`dard known as IPsec has been defined and provides for the
`creation of a secure connection between parties in a VPN
`over IPv6. In the IPsec model the end points of the secure
`connection are identified by their IP addresses. Whilst this
`may be Satisfactory for users having a fixed connection, it
`does present problems for the mobile user (Such as a user
`who connects to the VPN via a wireless terminal) who
`wishes to roam between different access networks. The main
`problem is that the IP address allocated to the roaming
`mobile user is likely to change dynamically as the user
`moves between access networks. In the event of an IP
`address change, it is difficult to reuse the pre-existing
`Security associations (of IPSec) and in the worst case Sce
`nario the communicating parties need to make a re-authen
`tication of one another and establish new Security associa
`tions on the basis of the new IP address(es). This will result
`in increased signalling traffic and will degrade the perfor
`mance of the VPN and of the applications being run.
`
`SUMMARY OF THE INVENTION
`0004. According to a first aspect of the present invention
`there is provided a Secure communication method for allow
`ing a mobile host to communicate with a correspondent host
`over a Virtual Private Network via a Security Gateway (SG),
`the method comprising the Steps of
`0005 (1) negotiating one or more Security Associations
`(SAS) between the mobile host and a correspondent host of
`a Virtual Private Network (VPN);
`0006 (2) subsequently initiating a communication
`between the mobile host and the SG and sending an authen
`tication certificate to the SG, the certificate containing at
`least the identity of a SA which will be used for subsequent
`communication between the mobile host and the correspon
`dent host;
`0007 (3) sending data packets from the mobile host to
`the correspondent host using the identified SA, via the SG;
`and
`0008 (4) wherein said data packets are forwarded by the
`SG to the correspondent host only if they are authenticated
`by the SG.
`
`0009 Preferably, prior to step (2) of the above method,
`one or more Security ASSociations (SAS) are negotiated
`between the mobile host and the SG and said authentication
`certificate is Sent to the SG using one of these SAS.
`0010 Preferably, the authentication certificate sent to the
`SG contains an IP address of the mobile host. This may be
`required, for example, when the mobile host has been
`allocated a new IP address.
`0011 Preferably, said SAS are IPsec phase 2 SAS and are
`used on top of an ISAKMP SA. More preferably, said
`authentication certificate contains the ISAKMP cookies of
`the mobile host and said correspondent host, with which the
`phase 2 negotiation was done.
`0012 Embodiments of the present invention reduce the
`amount of Security related messaging during on-the-fly IP
`address changes, as the SAS needed to provide for Secure
`communication between the mobile host and the correspon
`dent host pre-exist. When it is required to initiate a new
`communication, it is only necessary for the mobile host to
`authorise the SG to forward packets belonging to a certain
`SA between the mobile host and said correspondent host.
`0013 Preferably, the VPN comprises an intranet, with the
`SG being coupled between the intranet and the Internet. The
`SG may also be coupled between the intranet and another
`network Such as a core network of a mobile wireleSS
`telecommunications system (such as UMTS).
`0014. The mobile host may be a wireless host coupled to
`the SG Via an access network, which may be an access
`network of a mobile wireleSS telecommunications System
`(for example the UTRAN access network of UMTS) or a
`wireless LAN or WAN. Said correspondent host may also be
`a mobile host, or it may be a fixed host.
`0015. In the case where the VPN comprises an intranet,
`Said correspondent host may reside within the intranet, or
`may reside outside of the intranet. In the later case, Said data
`packets are forwarded to the correspondent host from the SG
`over a Secure connection. This may be established in the
`Same way as the Secure connection between Said mobile host
`and the SG.
`0016. In certain embodiments of the present invention, a
`negotiated SA expires after a predefined Volume of data has
`been sent using the SA. The SG maintains a record of the
`Sent data Volume and Suspends the SA when the predefined
`Volume is reached.
`0017. In certain embodiments of the invention, a nego
`tiated SA is time limited by the SG. At the end of a
`predefined time limit the SA identity is suspend by the SG.
`0018. In the case of cellular access, the data packets sent
`to the SG in step (3) and which contain user data are
`authenticated using authentication data Sent in Separate data
`packets. For example these Separate data packets may con
`tain hashes of the user data. More preferably, the data
`packets containing user data are sent (possibly encrypted)
`using a Security ASSociation (SA) negotiated between the
`mobile host and Said correspondent host and the data packets
`containing authentication data are Sent using Security ASSo
`ciations (SA) negotiated between the mobile host and the
`SG.
`0019. According to a second aspect of the present inven
`tion there is provided a Security Gateway (SG) of a Virtual
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 5
`IPR2019-00821, Apple Inc. v. MPH Technologies Oy
`
`

`

`US 2001/0009025 A1
`
`Jul. 19, 2001
`
`Private Network, the SG enabling secure communication
`between a mobile host and a correspondent host, the SG
`comprising:
`0020 (1) means for negotiating one or more Security
`Associations (SAS) between the mobile host and the Secu
`rity Gateway (SG);
`0021 (2) means for Subsequently initiating a communi
`cation between the mobile host and the SG using a negoti
`ated SA and for receiving an authentication certificate Sent
`from the mobile host, the certificate containing at least the
`identity of the mobile host and an IP address of the mobile
`host;
`0022 (3) means for receiving data packets sent from the
`mobile host and for authenticating the data packets, and
`0023 (4) means for forwarding the data packets from the
`SG to Said correspondent host providing that the received
`data packets are authenticated.
`0024. According to a third aspect of the present invention
`there is provided a Secure communication method for allow
`ing a mobile host to communicate with a correspondent host
`over a Virtual Private Network, the method comprising the
`Steps of:
`0025 (1) negotiating one or more Security Associations
`(SAS) between the mobile host and a Security Gateway (SG)
`of a Virtual Private Network (VPN);
`0026 (2) subsequently initiating a communication
`between the mobile host and the SG using a negotiated SA
`and Sending an authentication certificate to the SG, the
`certificate containing at least the identity of the mobile host
`and an IP address of the mobile host;
`0027 (3) sending data packets from the mobile host to
`the SG and authenticating the data packets at the SG, and
`0028 (4) providing that the received data packets are
`authenticated, forwarding the data packets from the SG to
`Said correspondent host.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0029 FIG. 1 illustrates schematically a Virtual Private
`Network (VPN) comprising an intranet;
`0030 FIG. 2 illustrates at a general level the signalling
`between two nodes of the VPN of FIG. 1 during a secure
`data connection establishment process,
`0031 FIG. 3 illustrates at a more detailed level the
`signalling involved in an IKE phase 1 of the process of FIG.
`2,
`FIG. 4 illustrates a Quick Mode message exchange
`0.032
`of an IKE phase 2 of the process of FIG. 2; and
`0.033
`FIG. 5 is a flow diagram illustrating a secure
`communication method according to an embodiment of the
`present invention.
`
`DETAILED DESCRIPTION OF A PREFERRED
`EMBODIMENT
`0034. The method which will now be described makes
`use of features described in the following documents: IP
`sec RFC 2401, Security Architecture for the Internet Pro
`tocol, November 1998; REKEY Internet Draft, IPsec Re
`keying Issues; IKERFC 2409, The Internet Key Exchange
`(IKE), November 1998; ISAKMP) RFC 2408, Internet
`
`Security ASSociation and Key Management Protocol,
`November 1998; INTDOI) RFC 2407, The Internet Secu
`rity Domain of Interpretation for ISAKMP, November 1998.
`Reference should be made to these documents for a fuller
`understanding of the method.
`0035 FIG. 1 illustrates a situation where a remote
`mobile host 1 uses the Internet 2 to connect to an organi
`sation's firewall or Security Gateway (SG) 3, and then to
`gain access to Some correspondent host (e.g. a server or
`other machine) 4 connected to the organisation's intranet
`(i.e. corporate LAN) 5. An access network 6 couples the
`mobile host 1 to the Internet 2. FIG. 1 also illustrates an
`alternative path for coupling the mobile terminal 1 to the
`intranet 5 and which involves a core network 7. A secure
`connection between the mobile host 1 and the correspondent
`host 4 is facilitated using “daemons” which work inside the
`mobile host 1, the firewall 3, and the correspondent host 4.
`The Specific Solution presented here, and which is further
`described below, utilises:
`0036) traffic counters;
`0037 a continuous channel method (REKEY) to
`always maintain at least one valid phase 1 Security
`Association (SA) between the mobile host 1 and the
`firewall 3 and also between the mobile host 1 and the
`correspondent host 4,
`0038 the “pre-creation” of multiple similar (phase
`2) SAS,
`0039) control certificates which are sent between the
`mobile host 1 and the firewall 3 to block or pass
`traffic associated with certain pre-created phase 2
`SAS,
`0040 a mechanism in the firewall 3 to block or pass
`traffic through the firewall 3, according to received
`control certificates and Overall corporate policy;
`0041 a potential for (partially) separating authenti
`cation from the encrypted traffic (the user layer data
`traffic can be sent immediately as encrypted, but the
`authentication data fields (e.g. hashes) for that data
`traffic can be delayed and Sent a short time later, e.g.
`in grouped into bursts). This applies in particular to
`access over cellular linkS.
`0042. The method, which may be referred to as a “cer
`tificate based firewall method’, can be divided into three
`main functions:
`0043 a preparations function which, in its simplest
`form, is carried out at a preliminary Stage when the
`mobile host 1 is “physically located within the
`intranet 5:
`0044) a remote control function which is carried out
`during the mobile host's remote access to the intranet
`5; and
`0045 a traffic enforcement function which is also
`carried out during the remote access Stage.
`0046 Each of these functions will now be considered in
`turn.
`0047 The preparations function (Phase 1)
`0048 Whilst the mobile host 1 is located within the
`intranet 5, the preparations for future lightweight and Secure
`remote access are made in one example using Standard
`techniques. Firstly, a single ISAKMP Security Association
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 6
`IPR2019-00821, Apple Inc. v. MPH Technologies Oy
`
`

`

`US 2001/0009025 A1
`
`Jul. 19, 2001
`
`(SA) is negotiated between the mobile host 1 and the firewall
`3. The ISAKMPSA provides protection for the IKE mes
`Saging itself. Secondly, Several pairs (or in the case of a
`highly memory limited device only a single pair) of IPsec
`Security ASSociations (SA) are established for the purpose of
`protecting actual user data traffic. The phase 2 message
`eXchange is carried out under the protection of the estab
`lished ISAKMPSA. The overall process is illustrated gen
`erally in FIG. 2. This process is then repeated in order to
`negotiate a separate ISAKMPSA between the mobile host
`1 and the correspondent host 4 as well as Separate pairs of
`IPSec SAS.
`0049 FIG. 3 illustrates in more detail the messages
`exchanged during each of the ISAKMP SA negotiation
`phases, and which consist of 3 different types of message in
`a certain order (this example relates to “main” mode
`“aggressive” mode may be preferred in certain circum
`stances). These message types provide for, in order, algo
`rithm negotiation, Secret key generation, and peer
`authentication. The algorithm negotiation phase will be
`considered first.
`0050. In the present scenario, the size of the intranet 5 is
`considered to be large (hundreds or thousands of nodes).
`Therefore, it is assumed that IKE is used to obtain authen
`ticated keying material for use with the ISAKMP and IPsec
`Security associations. The following attributes are used by
`IKE and are negotiated as part of the ISAKMP Security
`ASSociation (mandatory Supported values in parenthesis):
`encryption algorithm,
`0051)
`0.052 hash algorithm (MD5 and SHA),
`authentication method (via pre-shared keys),
`0053)
`0054 information about a group over which to do
`Diffie-Hellman (MODP over group no.1).
`0055. It is noted that the ISAKMP uses the Initiator and
`Responder cookie fields in the ISAKMP header to identify
`the particular ISAKMP SAS for itself. The creation of an
`Anti-Clogging Token (“Cookie') is implementation depen
`dent, but must Satisfy the following basic requirements
`ISAKMP):
`0056. The cookie must depend on the specific par
`ties. This prevents an attacker from obtaining a
`cookie using a real IP address and UDP port, and
`then using it to Swamp the victim with Diffie
`Hellman requests from randomly chosen IP
`addresses or ports.
`0057. It must not be possible for anyone other than
`the issuing entity to generate cookies that will be
`accepted by that entity. This implies that the issuing
`entity must use local Secret information in the gen
`eration and Subsequent verification of a cookie. It
`must not be possible to deduce this Secret informa
`tion from any particular cookie.
`0058. The cookie generation function must be fast
`enough to protect against attacks intended to wear
`down CPU resources. (The suggested method for
`creating the cookie is to perform a fast hash (e.g.
`MD5) over the IP Source and Destination Address,
`the UDP Source and Destination Ports and a locally
`generated secret random value. ISAKMP requires
`that the cookie be unique for each SA established, to
`help prevent replay attacks-therefore, the date and
`time must be added to the information hashed.
`
`0059. It is further noted that the Domain of Interpretation
`(DOI) field in the phase 1 negotiation can be used to expand
`the Syntax and Semantics of Identities. Therefore, the present
`implementation is not bound to the Identities currently
`defined for the Internet domain. Security protocols sharing
`a DOI, choose Security protocol and cryptographic trans
`forms from a common nameSpace and share key exchange
`protocol identifiers. They also share a common interpreta
`tion of DOI-specific payload data content, including the
`Security
`ASSociation and Identification
`payloads.
`INTDOI))
`0060 Two particularly interesting “Identification Pay
`load' types (used to identify the initiator and the responder
`of the SA) currently defined for Internet Domain INTDOI),
`include:
`0061 IDDER ASN1 DN type specifies the
`binary DER encoding of an ASN.1 X.500 Distin
`guished Name of the principal whose certificates are
`being eXchanged to establish the SA,
`0062) ID DER ASN1 GN type specifies the
`binary DER encoding of an ASN.1 X.500 Gener
`alName of the principal whose certificates are being
`eXchanged to establish the SA,
`0063). Other alternatives include:
`0064.) ID IPV4 ADDR type specifies a single four
`(4) octet IPv4 address,
`0065) ID FODN type specifies a fully-qualified
`domain name String,
`0.066 ID USER FODN type specifies a fully-quali
`fied username String,
`0067 ID IPV6 ADDR type specifies a single six
`teen (16) octet IPv6 address
`0068 ID IPV6 ADDR SUBNET type specifies a
`range of IPv6 addresses,
`0069 ID KEY ID type specifies an opaque byte
`Stream which may be used to pass vendor-specific
`information necessary to identify which pre-shared
`key should be used, for example, to authenticate
`Aggressive mode negotiations.
`0070 AS will be apparent from the list above, different
`versions of IP addresses, domain and user names, principal
`name encoding, and Vendor Specific ID information can be
`preferred during the ISAKMP SA negotiations. However,
`the selected ID type will strongly affect the mobility prop
`erties of later secure connections. Note that when an IKE
`eXchange is authenticated using certificates, any ID's used
`for input to local policy decisions should be contained in the
`certificate used in the authentication of the exchange.
`0071 Considering now the second stage of the phase 1
`message exchange (illustrated in FIG. 3), this involves
`establishing an authenticated key exchange, which generates
`authenticated keying material from a Diffie-Hellman
`eXchange. This proceSS will create a shared Secret between
`the communicating parties (i.e. the mobile host 1 and the
`firewall 3 and the mobile host 1 and the correspondent host
`4), which is hence only available for communication
`between those two parties.
`0072 The DH exchange messages will carry Diffie
`Hellman (DH) public values and ancillary data (e.g. nonces)
`necessary for the exchange. Normally (in main mode), one
`message needs to be transferred in both directions, and the
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 7
`IPR2019-00821, Apple Inc. v. MPH Technologies Oy
`
`

`

`US 2001/0009025 A1
`
`Jul. 19, 2001
`
`result is a common shared Secret at both ends. (On the other
`nand, also the “Quick Mode”, must be implemented in the
`Stack to generate fresh keying material and negotiate NON
`ISAKMP security services.)
`0073. The third stage of phase 1 involves the authenti
`cation of the peers. AS has been discussed above, the
`authentication method for the eXchange has already been
`negotiated (during IKE negotiation) from four different
`types of candidates:
`0074 digital signature,
`0075 authentication with public key encryption
`(two different),
`0.076 pre-shared key.
`0077. Now, the selected authentication method will be
`applied in this authentication eXchange, and the result will
`be three groups of authenticated keying material (keymat):
`0078 the keymat used by the ISAKMPSA to protect
`the confidentiality of its messages,
`0079 the keymat used by the ISAKMP SA to
`authenticate its messages,
`0080 the keymat used to derive keys for non
`ISAKMP security associations.
`0081. This keying material is proven to be authentic,
`because both the initiator and the responder generate a hash
`value from a specific Set of the exchanged information
`(including the corresponding ID of the ISAKMP party).
`Each party's ability to reconstruct the hash (from the
`received authentication message) will authenticate the
`eXchange.
`0082 If the signature authentication method has been
`negotiated, the authentication “seed” (nonce) will be
`eXchanged during the DH exchange. Then, the authenticity
`of the eXchange is assured by Signing a mutually obtainable
`hash.
`0.083. When using public key encryption to authenticate
`the exchange, the nonce and the identities of the parties will
`be exchanged during the DH exchange, but now being
`encrypted with the public key of the receiver. Each party's
`ability to reconstruct a hash authenticates the exchange.
`However, in order to perform the public key encryption the
`initiator must already have the responder's public key. (A
`hash of the certificate the initiator used to encrypt the
`ancillary information could also be passed as part of the
`authentication message.) Note that authentication with pub
`lic key encryption allows for identity protection with
`Aggressive Mode.
`0084.
`In a third alternative, authentication is achieved
`using a revised mode of public key encryption. This authen
`tication mode retains the advantages of public key encryp
`tion but works with only two public key operations. In the
`eXchanged message, only the nonce is encrypted with the
`public key, but the identity related information is encoded
`using the negotiated Symmetric encryption (with a key
`derived from the nonce). Optionally, a certificate payload
`may be attached to the DH key exchange message to provide
`the responder with a public key with which to respond.
`0085 For extra protection of the Diffie-Hellman, the DH
`"public information' is also encrypted using the same Sym
`metric key, instead of clear text. Note that these Symmetric
`keys are ephemeral and must be discarded after use.
`
`0086. In the fourth alternative, a key retrieved by some
`off-line mechanism may be used to authenticate the IKE
`eXchange. When using pre-shared key authentication with
`Main Mode, the key can only be identified by the IP address
`of the peers. Fortunately, the Aggressive Mode allows for
`different identifiers to be used. In addition, it allows parties
`to maintain multiple pre-shared keys and the means to
`identify the corresponding key for a particular exchange.
`0087. The preparations function (Phase 2)
`0088 Phase 2 is where Security Associations are nego
`tiated between the mobile host 1 and the firewall 3, and
`between the mobile host 1 and the correspondent host 4, for
`Services Such as IPSec, which need key material or parameter
`negotiation. AS with phase 1, this is carried out whilst the
`mobile terminal 1 is located within the intranet 5. A single
`ISAKMPSA may be used as a basis for several IPsec SAS
`which, if desired, can be negotiated in a Single phase 2
`Sequence. The positive consequence of these optimisations
`can lead to less than one messaging round trip, and less than
`one DH exponentiation, per IPsec SAIKE).
`0089. Each ISAKMPSA (Phase 1) is bidirectional, which
`means that after it has been established, either party may
`initiate “Ouick Mode”, “Informational”, and “New Group
`Mode” exchanges. The Quick Mode provides a phase 2
`eXchange and is a mandatory mechanism to generate fresh
`keying material and negotiate non-ISAKMP Security Ser
`vices. Quick Mode is basically a SA negotiation and an
`exchange of Nonces that provides replay protection. (The
`New Group Mode is a mechanism to define private groups
`for Diffie-Hellman exchanges.)
`0090 All offers made during a Quick Mode are logically
`related. For example, if a Diffie-Hellman payload is sent
`(optional), the DH group must be included in every trans
`form of every SA being negotiated. Similarly, if the Client
`Identities are used, they must apply to every SA in the
`negotiation. The message exchange in Quick Mode is illus
`trated in FIG. 4, where:
`0091) “IPsec SA Proposal(s)' message includes an
`IPsec SA negotiation payload (with one or more
`proposals), an initiator Nonce, a hash of the message,
`and optionally a Diffie-Hellman payload and Client
`Identities,
`0092) “Selected IPsec SA” message includes the
`IPsec SA negotiation payload (only one SA
`Selected), a responder Nonce, and a hash of the
`message, and optionally a Diffie-Hellman payload
`and Client Identities,
`0093 “Liveliness hash” message includes a hash
`over, e.g. a concatenation of the message ID and the
`Initiators and responder's Nonce minus the payload
`header.
`0094. As mentioned above, a single phase 2 negotiation
`can Simultaneously request multiple Security ASSociations,
`but the repeated re-keying using Quick Mode could con
`Sume the entropy of the Diffie-Hellman shared secret. There
`fore, in order to preserve good privacy, an upper threshold
`value should be configured in the stack for the Quick Mode
`Exchanges.
`0.095 The Nonces are used to GENERATE fresh key
`material and prevent replay attackS. However, the Quick
`Mode (without the optional Diffie-Hellman payload) only
`refreshes the old keying material derived from the exponen
`tiation in phase 1. This does not provide Perfect Forward
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 8
`IPR2019-00821, Apple Inc. v. MPH Technologies Oy
`
`

`

`US 2001/0009025 A1
`
`Jul. 19, 2001
`
`Secrecy. Using the optional Diffie-Hellman payload (e.g.
`every now and then), an additional exponentiation is per
`formed and Perfect Forward Secrecy is provided for the
`keying material.
`0096. The result of this process is that SAS (phase 1 and
`phase 2) are established between the mobile host 1 and the
`firewall 3, and between the mobile host 1 and the corre
`spondent host 4. It will be appreciated that the mobile host
`may additionally establish SAS with a second (or Subse
`quent) correspondent host. Details of the negotiated SAS are
`held at the firewall in a Security Association Database
`(SAD) and at the end of the negotiation process the firewall
`3 transfers the SAD from the intranet side interface to the
`external side interface of the IPsec protocol stack. This
`makes it possible for the mobile host 3 to make use of the
`pre-created IKE phase 1 and phase 2 SAS from outside of the
`intranet 5.
`0097. To conclude the preparations function, the mobile
`host 1 will Send a specific formatted authorisation certificate
`to the firewall 3 (if outside the intranet 5, a temporary
`Secured IPsec channel could be established for this certifi
`cate transfer). This certificate includes at least a formatted
`list of identities of the phase 2 SAS that were pre-created
`during the Quick Mode between the mobile host 1 and the
`correspondent host 4. The information about each SA in the
`list could consist of
`0.098
`the Source and Destination IP addresses,
`0099 the ISAKMP Cookies of the mobile host 1 and
`the correspondent host 4 (under which the phase 2
`negotiation was done),
`01.00
`the IPsec protocol ID (AH, ESP)
`0101 the SPI number of the particular phase 2 SA
`(incoming and outgoing Separated),
`0102 the Initial sequence number and Initialisation
`vector of the particular phase 2 SA,
`0.103
`the Expiration clause of the phase 2 SA
`(which was negotiated using the Quick Mode in the
`beginning of the Preparations function. In the present
`proposal, this should be expressed (at least) in the
`form of “maximum number of bytes processed”),
`0104 the Traversal Threshold is the remote con
`trolled limit for this phase 2 SA to be “activated”
`(initially set to 0),
`0105 a Remote Control flag indicating whether this
`SA has been “activated” by the mobile host 1 from
`outside of the intranet 5. Initially, in the Informa
`tional certificate, this flag is set to “Off” which means
`that the corresponding phase 2 SA has not been
`activated by the Remote Control function.
`0106 The contents of the received authorisation certifi
`cates are Stored in a nominal (Secure) database, referred to
`here as a Remote Control DataBase (RCDB), within the
`firewall 3. This database is then subsequently maintained by
`the firewall 3. For example, expired phase 2 SA IDs are
`deleted automatically from the Remote Control Database.
`0107 The firewall3 is now ready to serve the mobile host
`1 and the correspondent host 4 traffic via the Remote Control
`function. Note that it is also possible to carry out the
`“preparations function” while the mobile host 1 is outside
`the intranet 5 (the mobile host 1 can order the firewall 3 to
`
`pass also ISAKMP Signalling messages between the mobile
`host 1 and the correspondent host 4).
`0108). The Remote Control Function
`0109 The remote control function is used by the mobile
`host 1 to remotely “activate' preexisting Secure connections
`to the correspondent host 4. If the mobile host user travels
`away from the intranet 5, the SAS which were created during
`the preparatio