111111
`
`1111111111111111111111111111111111111111111111111111111111111
`US006976177B2
`
`(12) United States Patent
`Ahonen
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 6,976,177 B2
`Dec. 13, 2005
`
`(54) VIRTUAL PRIVATE NETWORKS
`
`OTHER PUBLICATIONS
`
`(75)
`
`Inventor: Pasi Matti Kalevi Ahonen, Oulu (FI)
`
`(73) Assignee: Telefonaktiebolaget LM Ericsson
`(publ), Stockholm (SE)
`
`( *) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 865 days.
`
`(21) Appl. No.: 09/764,661
`
`(22) Filed:
`
`Jan. 18,2001
`
`(65)
`
`Prior Publication Data
`
`US 2001!0009025 Al
`
`Jul. 19, 2001
`
`(30)
`
`Foreign Application Priority Data
`
`Jan. 18, 2000
`
`(GB)
`
`.................................. 00009613
`
`(51)
`
`Int. Cl? ............................................... G06F 17/00
`
`(52) U.S. Cl. ...................... 713/201; 713/168; 713/175;
`713/153
`
`(58) Field of Search ................................ 713/201, 168,
`713/175, 153
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`5,940,591 A * 8/1999 Boyle et a!. ................ 713/201
`6,330,562 B1 * 12/2001 Boden eta!. ................. 707/10
`
`Zao et al., "A public-key based secure Mobile IP", J.C.
`Baltzer AG, Sceince Publishers, pp. 373-390.*
`Reavis, Jim, "Is VPN the killer application for PKI?", Sep.
`22, 1999, Network World Fusion.*
`Zao et al., A public-key based secure mobile IP, Wireless
`Networks, vol. 5, Issue 5 (Oct. 1999) pp.: 373-390 Year of
`Publication: 1999. *
`
`(Continued)
`
`Primary Examiner-David Jung
`(74) Attorney, Agent, or Firm-Roger Burleigh
`
`(57)
`
`ABSTRACT
`
`A secure communication method for allowing a mobile host
`to communicate with a correspondent host over a Virtual
`Private Network. The method comprises negotiating one or
`more Security Associations between the mobile host and a
`correspondent host of a Virtual Private Network. Subse(cid:173)
`quently, a communication is initiated between the mobile
`host and a Security Gateway and an authentication certifi(cid:173)
`cate sent to the Security Gateway, the certificate containing
`at least the identity of a Security Association which will be
`used for subsequent communication between the mobile
`host and the correspondent host. Data packets can then be
`sent from the mobile host to the correspondent host using the
`identified Security Association, via the Security Gateway.
`However, the data packets are forwarded by the Security
`Gateway to the correspondent host only if they are authen(cid:173)
`ticated by the Security Gateway.
`
`15 Claims, 3 Drawing Sheets
`
`y~
`
`Delete SA trom SAD and select new SA
`
`Ex. 1006
`Apple v. MPH Techs. Oy
`IPR2019-00820
`
`0001
`
`

`

`US 6,976,177 B2
`Page 2
`
`01HER PUBLICATIONS
`
`Dynamic network-based secure VPN deployment in GPRS
`Xenakis, C.; Merakos, L.; Personal, Indoor and Mobile
`Radio Communications, 2002. The 13th IEEE International
`Symposium on vol. 3, Sep. 15-18,2002, Page(s).:1260-1265
`vol.3.*
`An agent-based shopping system Benedicenti, L.; Xuguang
`Chen; Xiaoran Cao; Paranjape, R.; Electrical and Computer
`Engineering, 2004. Canadian Conference on vol. 2, May
`2-5, 2004 Page(s):703-705, vol. 2.*
`Simple mobility support for IPsec tunnel mode Byoung-Jo,
`K.; Srinivasan, S.; Vehicular Technology Conference, 2003.
`VTC 2003-Fall. 2003 IEEE 58th vol. 3, Oct. 6-9, 2003
`Page(s):1999-2003 vol. 3 Digital Object Identifier 10.1109/
`VETECF.2003.1285375.*
`
`Jacobs, S., et al., "Security of Current Mobile IP Solutions",
`Proceedings of the Military Communications Conference,
`Nov. 3, 1997, pp. 1122-1128, XP 000792591.
`
`Inoue, A, et al., "IP Layer Security and Mobility Support
`Design Policy and an Implementation", Proceedings of the
`ISS'97
`International Switching Symposium, Toronto,
`Canada, Sep. 21-23, 1997, pp. 571-577, XP000720565.
`
`Zao, J., et al., "A Public-Key Based Secure Mobile IP",
`Proceedings of the Mobicom'97 Third Annual ACM!IEEE
`International Conference on Mobile Computing and
`Networking, Budapest, Hungary, pp. 26-30, Sep. 1997, XP
`000764777.
`
`* cited by examiner
`
`0002
`
`

`

`U.S. Patent
`
`Dec. 13, 2005
`
`Sheet 1 of 3
`
`US 6,976,177 B2
`
`6
`
`7
`
`Figure 1
`
`ISAKMP SA
`
`Peer 1
`
`Peer2
`
`IKE Phase 1
`
`IKE Phase 2
`IPSec SA #2 ~--_J
`
`Figure 2
`
`0003
`
`

`

`U.S. Patent
`
`Dec. 13, 2005
`
`Sheet 2 of 3
`
`US 6,976,177 B2
`
`IKE :MESSAGES IN Phase 1
`Pr
`
`Initiator
`
`Algorithm
`Negotiation
`
`}
`
`}
`
`Diffie-Hellman
`Key Generation
`
`A uthenticate/2
`
`} Peer authentication
`
`Figure 3
`
`QUICK MODE MESSAGES (Phase 2)
`
`(IPsec) SA Proposal(~
`II""" Responde~
`
`Initiator
`
`Selected (IPsec) SA
`
`...,
`
`......
`
`Liveliness hash
`(conclusion)
`
`...
`....
`
`Figure 4
`
`0004
`
`

`

`U.S. Patent
`
`Dec. 13, 2005
`
`Sheet 3 of 3
`
`US 6,976,177 B2
`
`Ne otiate ISAKMP hase 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 firewall (over pre-exiting SA)
`
`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 ~---r---,
`correspondent host if authenticated
`
`No
`
`Yes
`
`Delete SA from SAD and select new SA 1 - - - - - - '
`
`Figure 5
`
`0005
`
`

`

`US 6,976,177 B2
`
`1
`VIRTUAL PRIVATE NETWORKS
`
`BACKGROUND
`
`2
`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.
`Preferably, said SAs are IPsec phase 2 SAs and are used
`on top of an ISAKMP SA More preferably, said authenti(cid:173)
`cation certificate contains the Internet Security Association
`Key Management Protocol (ISAKMP) cookies of the mobile
`host and said correspondent host, with which the phase 2
`10 negotiation was done.
`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 commu(cid:173)
`nication between the mobile host and the correspondent host
`15 pre-exist. When it is required to initiate a new communica(cid:173)
`tion, it is only necessary for the mobile host to authorize the
`SG to forward packets belonging to a certain SA between the
`mobile host and said correspondent host.
`Preferably, the VPN comprises an intranet, with the SG
`20 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).
`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.
`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.
`In certain embodiments of the present invention, a nego(cid:173)
`tiated SA expires after a predefined volume of data has been
`40 sent using the SA The SG maintains a record of the sent data
`volume and suspends the SA when the predefined volume is
`reached.
`In certain embodiments of the invention, a negotiated SA
`is time limited by the SG. At the end of a predefined time
`limit the SA identity is suspend by the SG.
`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 contain hashes of
`50 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 Associations
`55 (SA) negotiated between the mobile host and the SG.
`According to a second aspect of the present invention
`there is provided a Security Gateway (SG) of a Virtual
`Private Network, the SG enabling secure communication
`between a mobile host and a correspondent host, the SG
`comprising:
`(1) means for negotiating one or more Security Associa(cid:173)
`tions (SAs) between the mobile host and the Security
`Gateway (SG);
`(2) means for subsequently initiating a communication
`between the mobile host and the SG using a negotiated
`SA and for receiving an authentication certificate sent
`
`The present invention relates to Virtual Private Networks 5
`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.
`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(cid:173)
`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.
`An Internet Engineering Task Force (IETF) standard
`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. While this 25
`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 30
`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(cid:173)
`nario the communicating parties need to make a re-authen- 35
`tication of one another and establish new security associa(cid:173)
`tions on the basis of the new IP address( es ). This will result
`in increased signalling traffic and will degrade the perfor(cid:173)
`mance of the VPN and of the applications being run.
`
`SUMMARY
`
`According to a first aspect of the present invention there
`is provided a secure communication method for allowing a
`mobile host to communicate with a correspondent host over 45
`a Virtual Private Network via a Security Gateway (SG), the
`method comprising the steps of:
`(1) negotiating one or more Security Associations (SAs)
`between the mobile host and a correspondent host of a
`Virtual Private Network (VPN);
`(2) subsequently initiating a communication between the
`mobile host and the SG and sending an authentication
`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 cor(cid:173)
`respondent host;
`(3) sending data packets from the mobile host to the
`correspondent host using the identified SA, via the SG;
`and
`(4) wherein said data packets are forwarded by the SG to
`the correspondent host only if they are authenticated by
`the SG.
`Preferably, prior to step (2) of the above method, one or
`more Security Associations (SAs) are negotiated between 65
`the mobile host and the SG and said authentication certifi(cid:173)
`cate is sent to the SG using one of these SAs.
`
`60
`
`0006
`
`

`

`US 6,976,177 B2
`
`5
`
`3
`from the mobile host, the certificate containing at least
`the identity of the mobile host and an IP address of the
`mobile host;
`(3) means for receiving data packets sent from the mobile
`host and for authenticating the data packets; and
`(4) means for forwarding the data packets from the SG to
`said correspondent host providing that the received data
`packets are authenticated.
`According to a third aspect of the present invention there
`is provided a secure communication method for allowing a 10
`mobile host to communicate with a correspondent host over
`a Virtual Private Network, the method comprising the steps
`of:
`(1) negotiating one or more Security Associations (SAs)
`between the mobile host and a Security Gateway (SG) 15
`of a Virtual Private Network (VPN);
`(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 20
`host and an IP address of the mobile host;
`(3) sending data packets from the mobile host to the SG
`and authenticating the data packets at the SG; and
`(4) providing that the received data packets are authenti(cid:173)
`cated, forwarding the data packets from the SG to said
`correspondent host.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`4
`firewall 3, and the correspondent host 4. The specific solu(cid:173)
`tion presented here, and which is further described below,
`utilizes:
`traffic counters;
`a continuous channel method (REKEY) to always main(cid:173)
`tain 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;
`the "pre-creation" of multiple similar (phase 2) SAs;
`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;
`a mechanism in the firewall 3 to block or pass traffic
`through the firewall 3, according to received control
`certificates and overall corporate policy;
`a potential for (partially) separating authentication 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.
`The method, which may be referred to as a "certificate
`25 based firewall method", can be divided into three main
`functions:
`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;
`a remote control function which is carried out during the
`mobile host's remote access to the intranet 5; and
`a traffic enforcement function which is also carried out
`during the remote access stage.
`Each of these functions will now be considered in turn.
`
`FIG. 1 illustrates schematically a Virtual Private Network 30
`(VPN) comprising an intranet;
`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;
`FIG. 3 illustrates at a more detailed level the signalling 35
`involved in an IKE phase 1 of the process of FIG. 2;
`FIG. 4 illustrates a Quick Mode message exchange of an
`IKE phase 2 of the process of FIG. 2; and
`FIG. 5 is a flow diagram illustrating a secure communi(cid:173)
`cation method according to an embodiment of the present 40
`invention.
`
`DETAILED DESCRIPTION
`
`The method which will now be described makes use of 45
`features described in the following documents, the contents
`of which are incorporated by reference herein: [IPsec] RFC
`2401, Security Architecture for
`the Internet Protocol,
`November 1998; [REKEY] Internet Draft, IPsec Re-keying
`Issues; [IKE] RFC 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 Security Domain
`of Interpretation for ISAKMP, November 1998. Reference
`should be made to these documents for a fuller understand- 55
`ing of the method.
`FIG. 1 illustrates a situation where a remote mobile host
`1 uses the Internet 2 to connect to an organization's firewall
`or Security Gateway (SG) 3, and then to gain access to some
`correspondent host (e.g. a server or other machine) 4 con(cid:173)
`nected to the organization'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
`
`The Preparations Function (Phase 1)
`While 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.
`First, a single ISAKMP Security Association (SA) is nego(cid:173)
`tiated between the mobile host 1 and the firewall 3. The
`ISAKMP SA provides protection for the IKE messaging
`itself. Second, 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 pro(cid:173)
`tecting actual user data traffic. The phase 2 message
`exchange is carried out under the protection of the estab(cid:173)
`lished ISAKMP SA The overall process is illustrated gen(cid:173)
`erally in FIG. 2. This process is then repeated in order to
`50 negotiate a separate ISAKMP SA between the mobile host
`1 and the correspondent host 4 as well as separate pairs of
`IPsec SAs.
`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 circumstances). These
`message types provide for, in order, algorithm negotiation,
`secret key generation, and peer authentication. The algo-
`60 rithm negotiation phase will be considered first.
`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(cid:173)
`ticated keying material for use with the ISAKMP and IPsec
`65 security associations. The following attributes are used by
`IKE and are negotiated as part of the ISAKMP Security
`Association (mandatory supported values in parenthesis):
`
`0007
`
`

`

`US 6,976,177 B2
`
`5
`
`5
`
`encryption algorithm,
`hash algorithm (MDS and SHA),
`authentication method (via pre-shared keys),
`information about a group over which to do Diffie(cid:173)
`Hellman (MODP over group no:1).
`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(cid:173)
`dent, but must satisfy the following basic requirements
`[ISAKMP]:
`The cookie must depend on the specific parties. 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 15
`randomly chosen IP addresses or ports.
`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 generation and subse(cid:173)
`quent verification of a cookie. It must not be possible
`to deduce this secret information from any particular
`cookie.
`The cookie generation function must be fast enough to
`protect against attacks intended to wear down CPU 25
`resources. (The suggested method for creating the
`cookie is to perform a fast hash (e.g. MDS) 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 30
`each SA established,
`to help prevent
`replay
`attacks-therefore, the date and time must be added to
`the information hashed.
`It is further noted that the Domain of Interpretation (DOl)
`field in the phase 1 negotiation can be used to expand the 35
`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 DOl, choose security protocol and cryptographic trans(cid:173)
`forms from a common namespace and share key exchange 40
`protocol identifiers. They also share a common interpreta(cid:173)
`tion of DOl-specific payload data content, including the
`Security Association
`and
`Identification
`payloads.
`[INTDOI])
`Two particularly interesting "Identification Payload" 45
`types (used to identify the initiator and the responder of the
`SA) currently defined for Internet Domain [INTDOI],
`include:
`ID_DER_ASN1_DN type specifies the binary DER
`encoding of an ASN.1 X.SOO Distinguished Name of 50
`the principal whose certificates are being exchanged to
`establish the SA,
`ID_DER_ASN1_GN type specifies the binary DER
`encoding of an ASN.1 X.SOO GeneralName of the
`principal whose certificates are being exchanged to 55
`establish the SA,
`Other alternatives include:
`ID_IPV4_ADDR type specifies a single four (4) octet
`1Pv4 address,
`ID_FQDN type specifies a fully-qualified domain name 60
`string,
`ID_USER_FQDN type specifies a fully-qualified user(cid:173)
`name string,
`ID_IPV6_ADDR type specifies a single sixteen (16)
`octet 1Pv6 address
`ID_IPV6_ADDR_SUBNET type specifies a range of
`1Pv6 addresses,
`
`6
`ID _KEY _ID type specifies an opaque byte stream which
`may be used to pass vendor-specific information nec(cid:173)
`essary to identify which pre-shared key should be used,
`for example, to authenticate Aggressive mode negotia(cid:173)
`tions.
`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 pre(cid:173)
`ferred during the ISAKMP SA negotiations. However, the
`10 selected ID type will strongly affect the mobility properties
`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.
`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 pro(cid:173)
`cess will create a shared secret between the communicating
`20 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 par(cid:173)
`ties.
`The DH exchange messages will carry Diffie-Hellman
`(DH) public values and ancillary data (e.g. nonces) neces(cid:173)
`sary for the exchange. Normally (in main mode), one
`message needs to be transferred in both directions, and the
`result is a common shared secret at both ends. (On the other
`hand, also the "Quick Mode", must be implemented in the
`stack to generate fresh keying material and negotiate NON(cid:173)
`ISAKMP security services.)
`The third stage of phase 1 involves the authentication of
`the peers. As has been discussed above, the authentication
`method for the exchange has already been negotiated (dur(cid:173)
`ing IKE negotiation) from four different types of candidates:
`digital signature,
`authentication with public key encryption (two different),
`pre-shared key.
`Now, the selected authentication method will be applied
`in this authentication exchange, and the result will be three
`groups of authenticated keying material (keymat):
`the keymat used by the ISAKMP SA to protect the
`confidentiality of its messages,
`the keymat used by the ISAKMP SA to authenticate its
`messages,
`the keymat used to derive keys for non-ISAKMP security
`associations.
`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 authenti(cid:173)
`cation message) will authenticate the exchange.
`If the signature authentication method has been negoti(cid:173)
`ated, 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.
`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
`65 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
`
`0008
`
`

`

`US 6,976,177 B2
`
`7
`authentication message.) Note that authentication with pub(cid:173)
`lic key encryption allows for identity protection with
`Aggressive Mode.
`In a third alternative, authentication is achieved using a
`revised mode of public key encryption. This authentication 5
`mode retains the advantages of public key encryption 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 10
`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.
`For extra protection of the Diffie-Hellman, the DH "public
`information" is also encrypted using the same symmetric 15
`key, instead of clear text. Note that these symmetric keys are
`ephemeral and must be discarded after use.
`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, 20
`the key can only be identified by the IP address of the peers.
`Fortunately, the Aggressive Mode allows for different iden(cid:173)
`tifiers 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.
`
`8
`As mentioned above, a single phase 2 negotiation can
`simultaneously request multiple Security Associations, but
`the repeated re-keying using Quick Mode could consume the
`entropy of the Diffie-Hellman shared secret. Therefore, in
`order to preserve good privacy, an upper threshold value
`should be configured in the stack for the Quick Mode
`Exchanges.
`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
`Secrecy. Using the optional Diffie-Hellman payload (e.g.
`every now and then), an additional exponentiation is per(cid:173)
`formed and Perfect Forward Secrecy is provided for the
`keying material.
`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 correspondent host
`4. It will be appreciated that the mobile host may addition(cid:173)
`ally establish SAs with a second (or subsequent) correspon-
`dent 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
`25 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.
`To conclude the preparations function, the mobile host 1
`30 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 certificate trans(cid:173)
`fer). This certificate includes at least a formatted list of
`identities of the phase 2 SAs that were pre-created during the
`35 Quick Mode between the mobile host 1 and the correspon(cid:173)
`dent host 4. The information about each SA in the list could
`consist of:
`the Source and Destination IP addresses,
`the ISAKMP Cookies of the mobile host 1 and the
`correspondent host 4 (under which the phase 2 nego(cid:173)
`tiation was done),
`the IPsec protocol ID (AH, ESP)
`the SPI number of the particular phase 2 SA (incoming
`and outgoing separated),
`the Initial sequence number [and Initialization vector] of
`the particular phase 2 SA,
`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"),
`the Traversal Threshold is the remote controlled limit for
`this phase 2 SA to be "activated" (initially set to 0),
`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 Informational certificate,
`this flag is set to "Off'' which means that the corre(cid:173)
`sponding phase 2 SA has not been activated by the
`Remote Control function.
`The contents of the received authorisation certificates 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 fire(cid:173)
`wall 3. For example, expired phase 2 SA IDs are deleted
`65 automatically from the Remote Control Database.
`The firewall3 is now ready to serve the mobile host 1 and
`the correspondent host 4 traffic via the Remote Control
`
`The Preparations Function (Phase 2)
`Phase 2 is where Security Associations are negotiated
`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 nego(cid:173)
`tiation. As with phase 1, this is carried out while the mobile
`terminal! is located within the intranet 5. A single ISAKMP
`SA 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 optimizations can lead to less
`than one messaging round trip, and less than one DH
`exponentiation, per IPsec SA [IKE].
`Each ISAKMP SA (Phase 1) is bi-directional, which
`means that after it has been established, either party may 40
`initiate "Quick 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(cid:173)
`vices. Quick Mode is basically a SA negotiation and an 45
`exchange of Nonces that provides replay protection. (The
`New Group Mode is a mechanism to define private groups
`for Diffie-Hellman exchanges.)
`All offers made during a Quick Mode are logically
`related. For example, if a Diffie-Hellman payload is sent 50
`(optional), the DH group must be included in every trans(cid:173)
`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(cid:173)
`trated in FIG. 4, where:
`"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,
`"Selected IPsec SA" message includes the IPsec SA 60
`negotiation payload
`(only one SA selected), a
`responder Nonce, and a