Patent Application
20120036567
The technical field relates generally to secure session establishment or, more particularly, to methods for authenticated time synchronization and for network access control for communication devices using dynamically assigned Internet Protocol (IP) addresses.
In many instances today, when a source device sends information to a destination device, the information may travel through a network such as the Internet. Depending on the nature of the information, it may need to be secured in one or more ways. For example, the devices may implement one or more core security services, such as confidentiality, authentication, etc., wherein confidentiality (e.g., the use of encryption/decryption algorithms) provides information privacy and is applied to the information so that it is understandable only by the intended recipient, and authentication is a process that evaluates the genuineness of the originator and recipient of the information. A number of existing security protocols can be used to provide the core security services. One such suite of protocols is Internet Protocol Security (IPsec) defined in a number of standards documents (i.e., in a series of Requests for Comments (RFCs)) specified by the Internet Engineering Task Force (IETF). In systems making use of IPsec or other similar data security protocols, security session establishment protocols such as the Internet Key Exchange (IKE) defined in RFCs 2409 (IKEv1) and 4306 (IKEv2) are used to provide security session access control and exchange of data relevant to the security session, such as a basis for replay protection. For example, the IKE protocol first performs mutual authentication of both peers in the exchange before allowing IPsec security session establishment to continue. Furthermore, as an implicit part of creating an IPsec security session, sequence numbers used for replay protection are also synchronized.
IKE is widely used in peer-to-peer networks, often when the network connecting the two peers is a high bandwidth network. In this case, the overhead associated with the several messages transferred as part of an IKE session establishment is relatively small. However, in a low bandwidth network such as an APCO (Association of Public Safety Communications Officials International) Project 25 (P25) radio network or other wireless data network, the added overhead can add an unacceptable delay to security session establishment time. Solutions to this problem typically involve avoidance of IKE altogether and performing IPsec with fixed keys only. However, this solution is often not desirable because it does not allow the additional authentication step that is part of security session establishment and makes synchronizing sequence numbers for relay protection difficult or impossible. IKE is also not suitable for use in cases where messages are targeted to a large group of receivers, such as in sending multicast data.
Thus, there exists a need for a novel method for establishing a security session between devices, which at least supports authentication and replay protection.
The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views, which together with the detailed description below are incorporated in and form part of the specification and serve to further illustrate various embodiments of concepts that include the claimed invention, and to explain various principles and advantages of those embodiments.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help improve understanding of various embodiments. In addition, the description and drawings do not necessarily require the order illustrated. It will be further appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. Apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the various embodiments so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein. Thus, it will be appreciated that for simplicity and clarity of illustration, common and well-understood elements that are useful or necessary in a commercially feasible embodiment may not be depicted in order to facilitate a less obstructed view of these various embodiments.
Generally speaking, pursuant to the various embodiments, a security gateway and an initiating device perform methods for establishing a security session. The methods includes the security gateway: receiving a first message from an initiating device, the first message including a first message authentication code; validating the first message using the message authentication code; and responsive to the validating, sending a second message to the initiating device, the second message including a timestamp and further including a second message authentication code for authenticating of the timestamp by the initiating device, wherein the first and second messages are used to establish the security session, and the authenticated timestamp is used for subsequent replay protection of messages between the security gateway and the initiating device. The method further includes the security gateway validating a dynamically assigned IP address for the initiating device to use in authorizing access of the initiating device to the security gateway.
Using the methods for security session establishment in accordance with the teachings herein (which is an alternative security session establishment procedure to that provided for by the IKE protocol) enables a number of illustrative advantages. For example, the security session establishment procedure in accordance with the present teachings, at a minimum, mutually authenticates both endpoint devices, provides an authorization mechanism for an initiating device to access a security gateway, and synchronizes an authenticated basis for replay protection, while using fewer and much smaller bandwidth messages than when using the IKE protocol. In addition, the prior art for access control to a security gateway by initiating devices provides a filter based only on static Internet Protocol (IP) addresses of the initiating devices; whereas, embodiments of the present disclosure provide a filter, for access control based on dynamically assigned IP addresses of the initiating devices. Those skilled in the art will realize that the above recognized advantages and other advantages described herein are merely illustrative and are not meant to be a complete rendering of all of the advantages of the various embodiments.
Referring now to the drawings, and in particular
To facilitate these secure communications, system 100 further includes a data encryption gateway (DEG) 104 and a DEG function (not shown) physically integrated within the radio 106 that communicate using a network 108, which in this case is an IP network (wherein IPv4 or IPv6 is implemented to enable endpoints to be reachable anywhere within system 100 using IP addresses). Accordingly, security processing by the DEGs is implemented in system 100 using IPsec. However, network 108 can be any type of suitable network, wherein security processing is performed using a correspondingly suitable security processing protocol.
Additionally, system 100 includes an infrastructure device 110 (such as a base site, base station, or the like) through which the radio 106 attaches to and communicates with wirelessly to operate over the network 108. Moreover, system 100 is shown as having two Host devices 102 and 106 and only two DEGs (only DEG 104 shown) for ease of illustration. However, in an actual system implementation, there may be hundreds and even thousands of host devices that use system 100 to facilitate communications with other host and infrastructure devices in system 100. Moreover, there may be additional DEGs in an actual system implementation, including DEGs that serve a number of host devices such as DEG 104.
DEG 104, in this illustrative implementation, provides data application services for multiple communication devices such as radio 106. In order for the radio 106 to access the data application services within host 102, radio 106 needs to authenticate to the DEG 104, which serves as a security gateway to a Virtual Private Network (VPN) that includes the host 102, wherein the DEG further serves to authorize VPN traffic, which is defined as traffic or messages communicated between the security gateway (e.g., DEG) and authenticated communication devices. The authorized VPN traffic also undergoes security processing by the DEGs, using a data security protocol (which in this case is IPsec), as it travels through the network 108 to provide secure communications between the hosts 102 and 106.
Messages that have undergone security processing using a data security protocol are termed, herein, as “security processed messages.” Accordingly, messages that have undergone IPsec processing are deemed security processed IPsec messages. As the term is used herein, a message is defined as a unit of communication sent between the devices, such as a packet, wherein the size and format of the communication unit depends on the particular protocol used to create the communication unit.
Prior to using IPsec for data encryption, a security session is established between the DEG 104 and the DEG in the radio 106. A “security session establishment procedure” is defined as an exchange of a sequence messages between the DEGs to provide, at a minimum, authentication of an initiating device (e.g., radio 106) and in many instances mutual authentication between the initiating device and the security gateway; an authorization mechanism for an initiating device to access the security gateway; and synchronization of an authenticated basis for replay protection. Accordingly, a security session is defined as the result of applying a security session establishment procedure; the security session and security processing of messages provide a secure “tunnel” 112 for messages traveling through the network 108. In the prior art, IKE served as the security session establishment procedure. However, IKE is not suitable for low bandwidth systems. Therefore, the present disclosure provides an alternative security session establishment procedure used to establish a security session using fewer and smaller messages than IKE. Examples of the security session establishment procedure in accordance with the present teachings are described by reference to
As illustrated by reference to
In general, the Hosts 102 and 106 and the DEGs (104 shown) are each implemented using (although not shown) a memory, one or more network interfaces, and a processing device that are operatively coupled, and which when programmed form the means for these system elements to implement their desired functionality, for example as illustrated by reference to the MSCs shown in
For example, where the network supports wired communications, the interfaces may comprise a serial port interface (e.g., compliant to the RS-232 standard), a parallel port interface, an Ethernet interface, a USB interface, and/or a FireWire interface, and the like. Where the network supports wireless communications, the interfaces comprise elements including processing, modulating, and transceiver elements that are operable in accordance with any one or more standard or proprietary wireless interfaces, wherein some of the functionality of the processing, modulating, and transceiver elements may be performed by means of the processing device through programmed logic such as software applications or firmware stored on the memory device of the system element or through hardware.
The processing device utilized by these elements may be partially implemented in hardware and thereby programmed with software or firmware logic or code for performing functionality described by reference to
Turning now to
In this illustrative implementation, AUTH is a Message Authentication Code (MAC), e.g., an 8-byte MAC. As used herein, a MAC is defined as a short piece of information used to authenticate a message. A MAC algorithm, sometimes called a keyed (cryptographic) hash function, accepts as input a secret key and an arbitrary-length message to be authenticated, and outputs a MAC (sometimes known as a tag). The MAC value protects both a message's data integrity as well as its authenticity, by allowing verifiers (who also possess the secret key) to detect any changes to the message content. In one example implementation, AUTH=function {HDR, TIME, Nr, Ni, auth_key}. For instance, the secret key (auth_key) can be provisioned in both the radio 202 and DEG 204 using over the air rekeying (OTAR) or Key Fill. The same or a different secret key may also be provisioned in both devices using OTAR and used for encrypting the messages 206 and 208. HDR, TIME, Nr, and Ni are next described.
In this illustrative implementation, all headers (HDR) shown in
Nonce (N) is a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks. As used herein random or pseudo-random means non-order or non-coherence in a sequence of symbols or steps, such that there is no intelligible pattern or combination, and such numbers can be generated using any suitable random (or pseudo-random) number generator function. Ni signifies the nonce sent by the initiating device, and Nr signifies the nonce sent by the responder, e.g., the security gateway. Moreover, a replay attack is defined as a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. A technique that protects against or guards against a replay attack is deemed to provide “replay protection”. For IPsec, for instance, replay protection is provided for in the prior art using sequence numbers that are initiated using IKE. However, the present disclosure provides for a novel replay protection technique for use with IPsec, as further described below.
TIME is a timestamp, which is defined as a sequence of characters denoting the date and/or time at which a certain event occurred, such as a recorded time at which a message was sent. In one illustrative implementation, TIME is a 32-bit value. An illustrative timestamp format with 32 bits is contained in a table shown in
Turning again to MSC 200, in the normal case for session establishment shown in
As explained above, the AUTH function for generating the MAC uses both Ni and Nr. Nr is sent in message 208 and Ni is “implied” in that the radio 202 should know its nonce. The radio 202 uses the implied Ni, as well as the explicit Nr, to calculate the AUTH value, and then compares the calculated AUTH value to the AUTH value that it received in message 208; although, in an alternative implementation, Ni could also be sent in message 208 (and 308 of
It should be noted that all of the messages shown in
Also,
As mentioned earlier, the authenticated timestamp is used in providing replay protection. More particularly, the authenticated timestamp is used for replay protection of security processed messages sent between the radio and DEG after the security session is established. The session establishment synchronizes authentic time between the radio and the security gateway. The time is used to construct a number that can only be used once. The purpose of this number is to provide uniqueness to a message that is being authenticated through the MAC, and thus prevent replay of the message. Both security endpoints need to have the synchronized timestamp in order to implement the time-based authentication validation.
In this illustrative embodiment, the authenticated timestamp is used for replay protection of IPsec security processed messages sent between the radio and DEG after the security session is established. More particularly, with regards to replay protection, the radio needs to keep its time synchronized with the time of the security gateway. This can be done initially through the session-establishment exchange, where the timestamp is authenticated by the MAC. The radio can also readjust its authenticated time to account for drift by checking the unauthenticated time using any suitable means such as on a trunking control channel or by checking time broadcasts on a conventional traffic channel.
If the radio sees the broadcasted control channel time change abruptly, and determines that the unauthenticated control channel time differs significantly (e.g., is outside of a defined threshold) with the authenticated timestamp that was initialized by the security gateway, then the radio does not resynchronize its authenticated time to the new control channel time. The radio instead requests to receive an authenticated time stamp from the security gateway by initiating a new session-establishment exchange. In order to prevent flooding of the system, in one example implementation, the radio only reinitiates the session-establishment exchange when it either receives or needs to transmit a new security processed message that includes or needs to have included therein an authenticated time stamp.
To facilitate the replay protection using the authenticated timestamp, the radio or security gateway inserts, into a security processed message (such as an IPsec message), a current timestamp that is derived from the authenticated timestamp; or in other words, the current timestamp uses the authenticated timestamp as a synchronized time basis. In one example implementation, the current timestamp is inserted into a sequence number field of an Encapsulating Security Payload (ESP) header or into a sequence number field of an Authentication Header (AH) protocol header within the IPsec message. Furthermore, the current timestamp may be inserted into an unencrypted portion of a payload in the IPsec message. Correspondingly, the radio or the security gateway receives an IPsec having a timestamp included in a sequence number field of an ESP or AH header of the IPsec message; and verifies the timestamp in the sequence number field against the authenticated timestamp to evaluate the IPsec message for replay attack.
Insertion of the timestamp into the ESP header is described herein, but the description is equally applicable to insertion of the timestamp into the AH header. The ESP header's Sequence Number field is 32 bits in length, and is populated with the ESP transmitter's current time stamp. The subfields that are inserted into the Sequence Number field include: Month, Day, Hour, Minute, and Microslot (12 bits), as shown in
An ESP device should also be capable of handling conditions where packets are received out of chronological order. For example, the ESP device has a configurable Anti-Replay Window (ARW) parameter. The ARW defines the interval of time where the ESP device will accept a packet whose time stamp is older than the previously received packet from the same source. Otherwise, received packets whose time stamps are older than the previously received packet from the same source are discarded. A smaller ARW value provides tighter protection against replay attack. A larger value loosens the security, but will allow for more flexible network operation. A typical default value of the ARW parameter is on the order of a couple of seconds.
In some networks, instead of having static IP addresses (meaning IP addresses that do not change over time), the radios have dynamically assigned IP addresses (meaning IP addresses that change over time), which are usually assigned through context activation. However, access control methods for a radio to access the gateway device, and hence the application service of the enterprise network) do not address access control when IP addresses are dynamically assigned. However, an embodiment of the present disclosure provides access control for radios having dynamically assigned IP addresses.
The radio is authorized to use a VPN based upon the settings of the security gateway's access control list. The security gateway's access control list contains the radio IDs of all authorized radios and may also contains a unique MAC key for each radio through OTAR provisioning or Key Fill. Accordingly, the security gateway verifies the received radio ID (e.g., from message 206 or 306) to the stored radio IDs. If there's a match and upon successful security session completion, the radio is authorized to use the VPN via the security gateway, and the dynamically assigned IP address (which is now an authorized IP address) is stored for that radio and associated with (or mapped to) the radio's stored ID. Since a radio ID is not present in later IPsec messages, the security gateway allows or authorizes VPN traffic to and from radios that have authorized IP addresses. The filtering can be performed based on IP addresses since each message contains the radio's IP address.
In the foregoing specification, specific embodiments have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present teachings. The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims as issued.
Moreover in this document, relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises,” “comprising,” “has”, “having,” “includes”, “including,” “contains”, “containing” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by “comprises . . . a”, “has . . . a”, “includes . . . a”, “contains . . . a” does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, contains the element. The terms “a” and “an” are defined as one or more unless explicitly stated otherwise herein. The terms “substantially”, “essentially”, “approximately”, “about” or any other version thereof, are defined as being close to as understood by one of ordinary skill in the art, and in one non-limiting embodiment the term is defined to be within 10%, in another embodiment within 5%, in another embodiment within 1% and in another embodiment within 0.5%. The term “coupled” as used herein is defined as connected, although not necessarily directly and not necessarily mechanically. A device or structure that is “configured” in a certain way is configured in at least that way, but may also be configured in ways that are not listed.
It will be appreciated that some embodiments may be comprised of one or more generic or specialized processors (or “processing devices”) such as microprocessors, digital signal processors, customized processors and field programmable gate arrays (FPGAs) and unique stored program instructions (including both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the method and apparatus for secure packet transmission described herein. The non-processor circuits may include, but are not limited to, a radio receiver, a radio transmitter, signal drivers, clock circuits, power source circuits, and user input devices. As such, these functions may be interpreted as steps of a method to perform the secure packet transmission described herein. Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches could be used. Both the state machine and ASIC are considered herein as a “processing device” for purposes of the foregoing discussion and claim language.
Moreover, an embodiment can be implemented as a computer-readable storage element or medium having computer readable code stored thereon for programming a computer (e.g., comprising a processing device) to perform a method as described and claimed herein. Examples of such computer-readable storage elements include, but are not limited to, a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory) and a Flash memory. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation.
The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.
The present application is related to the following U.S. applications commonly owned together with this application by Motorola, Inc.: Ser. No. 12/731,220, filed Mar. 25, 2010, titled “Method and Apparatus for Secure Packet Transmission” by Larry Murrill (attorney docket no. CM12774), which claims the benefit of provisional application Ser. No. 61/173,182 filed Apr. 27, 2009; Ser. No. 61/370,943, filed Aug. 5, 2010 titled “Method for Key Identification Using an Internet Security Association and Key Management Based Protocol” by Langham, et al. (attorney docket no. CM13837); and Ser. No. 61/371,735 filed Aug. 8, 2010 titled “Methods for Establishing a Security Session in a Communication System” by Senese, et al. (attorney docket no. CM13662), which is a provisional filing from which the present application claims the benefit of its priority date.
| Number | Date | Country | |
|---|---|---|---|
| 61371735 | Aug 2010 | US | |
| 61370943 | Aug 2010 | US |
