Method and apparatus for authentication of session packets for resource and admission control functions (RACF)

CROSS-REFERENCE TO RELATED APPLICATION

0001This application claims priority of Provisional Application Ser. No. 60/852,865 which was filed Oct. 19, 2006.

TECHNICAL FIELD

0002This invention relates generally to the authentication of a transport packet stream (which constitutes a flow within a session), which has been admitted into a managed packet network.

BACKGROUND OF THE INVENTION

0003In the past years, the telecommunications industry has been solving several inter-related problems in the converged (both mobile and fixed) networks:

00041. Establishment of a user session in a managed IP network;

00052. Policy-based admission control; and

00063. Policy enforcement.

0007The first item above, user session establishment, addresses signaling between an end point (i.e., user equipment terminal) and the network in order to establish an end-to-end session (such as a Voice-over-IP telephone call or a conference call, or an IP TV session). Policy-based admission control refers to the process triggered during session establishment, in which the network itself is determining whether there are sufficient resources (i.e., bandwidth) in the network to admit the relevant IP flows (defined by the quintuple that contains the originating and terminating IP addresses and originating and terminating port numbers along with the protocol identifier); if such resources are found and the request is authorized as legitimate, the network instructs the appropriate devices at its edges to admit the authorized flows (and, in the most general case, ensure that they conform to specific policies). Policy enforcement deals with actual admission of the traffic from end points. The IP Multimedia Subsystem (IMS), ETSI TS 123 002 V7.1.0 (2006-03), Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Network Architecture and ETSI TS 123 228 V7.3.0, (2006-03), Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); IP Multimedia Subsystem (IMS); Stage 2, has defined an architecture and a set of standards that support the implementation of the above functions. Subsequently, this has been further elaborated within the framework of a more general architecture presently developed by ITU-T within the framework of Resource Admission and Control Functions known as ITU-T New Draft Recommendation Y.2111 (formerly Y.RACF), Resource and Admission Control Functions in Next Generation Networks.

SUMMARY OF THE INVENTION

0008An advance is made over the prior art in accordance with the principles of the present invention that addresses the problem of authentication of the transport packet stream (which constitutes a flow within a session), which has been admitted into a managed packet network. Authentication and the subsequent enforcement of the flows supporting an identified client's authorized service prevent a large class of denial of service attacks described below. Specifically, the invention addresses two different matters: 1) key distribution and management 2) various forms of using a shared key for the authentication of transport packets on the user-to-network-interface (UNI).

0009In one embodiment of the invention, a method of authenticating a transport packet stream in a managed packet network is shown comprising the steps of receiving at a RACF (Resource and Admission Control Function) a request for service from a client application transmitted through a service control function and authenticating the transport packet stream, using a session key, based on session flow parameters associated with said transport packet stream without regard to identity of a client. Another embodiment includes a method of authenticating a transport packet stream in a managed packet network comprising the steps of receiving at a RACF a request for service from a client application transmitted through a service control function; authorizing the request from the service control function; creating a key, K_F, for a session flow to be established, K_Fbeing shared between said client application and a gateway; and passing a quantity (X or Y) to the service control function from which X can be determined, wherein X is included in a token to be passed to a client application, wherein a client can determine a session flow key K_F. Additional steps may include creating a ticket, t, for a border gateway to be contacted, where t=K_BGW(F, K_F), wherein the quantity X which is passed to the client utilizes the ticket as part of an encrypted value.

BRIEF DESCRIPTION OF THE DRAWING

0010The teachings of the present invention can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which:

0011<figref idref="DRAWINGS">FIG. 1</figref> shows a flow diagram for message flows according to a PULL model and the present invention;

0012<figref idref="DRAWINGS">FIG. 2</figref> shows a flow diagram for message flows according to a PUSH model and the present invention; and

0013<figref idref="DRAWINGS">FIG. 3</figref> shows an exemplary message flow in accordance with the present invention that addresses NAT.

DETAILED DESCRIPTION

0014As stated in the Summary, the invention addresses the problem of authentication of a transport packet stream (which constitutes a flow within a session), which has been admitted into a managed packet network (such as AT&amp;T or Verizon packet networks). Authentication and the subsequent enforcement of the flows supporting an identified client's authorized service prevent a large class of denial of service attacks described below. Specifically, the invention addresses two different matters: 1) key distribution and management 2) various forms of using a shared key for the authentication of transport packets on the user-to-network-interface (UNI). Although the invention is described with respect to the Resource and Admission Control Function (RACF) and Service Control Function apparatus, it would be understood that other apparatus that include like functionality may also be utilized in connection with the present invention.

0015Referring to <figref idref="DRAWINGS">FIGS. 1 and 2</figref>, the entities involved in the process of authenticating a session, for example, are <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0016"> User Equipment terminal <b>10</b> (such as a computer, an IP wireline [fixed] or mobile telephone, or a set top box) which originates and receives the flows related to a service. As far as the terms of this invention are concerned, the invention considers a specific client service application running on a terminal and the flows that such client application generates toward the network; </li><li id="ul0002-0002" num="0017"> Service Control Function <b>20</b> (such as P-CSCF or S-CSCF functions defined in IMS or a specialized service control equipment for delivery of IPTV); </li><li id="ul0002-0003" num="0018"> RACF <b>30</b>; and </li><li id="ul0002-0004" num="0019"> Border Gateway (such as an IP router), which is responsible for policy enforcement and which is broadly designated as Transport Functions <b>40</b>. </li></ul></li></ul>

0020The standards outline two respective models of typical information exchange among these entities, which are augmented by the present invention. There are two modes of operation known as a pull model and a push model. They are depicted in <figref idref="DRAWINGS">FIGS. 1 and 2</figref>, respectively.

0021Referring to <figref idref="DRAWINGS">FIG. 1</figref>, with a pull model, certain exemplary message flows for an information exchange between the entities described are set forth using flow designations <b>1</b> through <b>8</b> as below: <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0022"><b>1</b>) The client application initiates a request for service to the service control function; </li><li id="ul0004-0002" num="0023"><b>2</b>) The service control function translates this request into specific traffic parameters and passes those to the RACF; </li><li id="ul0004-0003" num="0024"><b>3</b>) The RACF authorizes the request and makes the necessary reservations, returning to the service control function a standard token with additional information for the client application; </li><li id="ul0004-0004" num="0025"><b>4</b>) The service control function passes the authorization and the token to the client application; </li><li id="ul0004-0005" num="0026"><b>5</b>) The client application initiates signaling (such as the Resource reservation Setup Protocol [RSVP] reservation request), in which it passes the appropriate flow parameters and the token (which may contain the information necessary to locate the RACF) to the border gateway; </li><li id="ul0004-0006" num="0027"><b>6</b>) The border gateway requests the respective policy (based on the flow parameters) from the RACF; </li><li id="ul0004-0007" num="0028"><b>7</b>) The RACF supplies the requested policy; and </li><li id="ul0004-0008" num="0029"><b>8</b>) The client application receives confirmation, at which point the respective application client can start sending the packets within the flow. </li></ul></li></ul>

0030Referring to <figref idref="DRAWINGS">FIG. 2</figref>, with a push model, an information exchange between the entities described are set forth using flow designations <b>1</b> through <b>5</b> as below <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0031"><b>1</b>) The client application initiates a request for service to the service control function; </li><li id="ul0006-0002" num="0032"><b>2</b>) The service control function translates this request into specific traffic parameters and passes it to the RACF; </li><li id="ul0006-0003" num="0033"><b>3</b>) The RACF authorizes the request and installs the respective policy in the border gateway; </li><li id="ul0006-0004" num="0034"><b>4</b>) The RACF replies to the service control function; </li><li id="ul0006-0005" num="0035"><b>5</b>) The service control function passes the authorization to the client application, upon receiving which the respective client application can start sending the packets within the flow. </li></ul></li></ul>

0036Presently, the policy enforcement encompasses admission of an authorized flow based solely on the information in the network- and transport-layer headers of each packet: source and destination IP addresses and ports and the protocol number. Based on this information, the network may police the traffic by dropping (not admitting) the packets when the flow does not conform to agreed traffic specifications (e.g., traffic exceeds the data rate).

0037One problem with this approach is that, in the absence of the mechanism for authenticating every packet, it is possible (and deemed fairly easy) to stage a denial-of-service (DOS) attack, in which an attacker emits a flow with the same header information as a legitimate one and thus hinders or even fully denies the intended service. The same attack, especially if it involves multicast addresses (i.e., in case of an IPTV broadcast service) may deny service to a large group of recipients and ultimately to the service provider itself.

0038These types of attacks can be prevented if each packet is admitted only if it is positively authenticated. To enable that, the network and the end point must share a secret (i.e., a high-quality cryptographic key) for the session. If this goal is achieved, yet another problem is solved, namely the problem of providing the confidentiality and integrity on the UNI interface.

0039The present invention teaches how to achieve that goal within the RACF framework so that the session key distribution via a RACF-issued ticket is combined with standard authorization and resource admission control functions performed by the RACF.

0040The invention first augments the RACF with a key distribution function, so that the RACF shares the respective keys with each service control function and each border gateway with which it needs to interact. With that, the RACF can help interoperate a service control function in one network with a border gateway in another network.

0041The following are the cryptographic keys (such as the keys used in the Data Encryption Standard (DES)-, or triple-DES key) involved in the transactions below: <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0000"><ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0042"> K_BGWis a key shared between the RACF and border gateway; </li><li id="ul0008-0002" num="0043"> K_SCFis a key shared between the RACF and service control function; </li><li id="ul0008-0003" num="0044"> K_Fis a key for the session flow to be established, which RACF creates so that it is shared between the subscriber client application and the gateway; </li><li id="ul0008-0004" num="0045"> K_Sis a key shared between the subscriber and service control function; (In the case of the IMS, P-CSCF possesses this key.) If the service control function trusts the RACF (which should always be the case when both belong to the same network), it can supply the RACF with K_Sin step <b>2</b> (common to both the pull and push models) </li><li id="ul0008-0005" num="0046"> K(L) always denotes a string that is the result of the encryption of string L using a certain encryption algorithm and the key, K. </li></ul></li></ul>

0047With the present invention, upon authorizing the request from the service control function, the RACF creates K_Fand computes a “ticket” to the BGW: <br /><i>t=K</i>_BGW(<i>F,K</i>_F), <br /> where F is the flow identifier. In one exemplary embodiment of the invention, the session flow parameters are derived from the quintuple that contains the originating and terminating IP addresses and originating and terminating port numbers along with the protocol identifier.

0048Then, in step <b>3</b> of the pull model or step <b>4</b> of the push model, there are two alternatives that depend on the trust model chosen between the entities in the network: <ul id="ul0009" list-style="none"><li id="ul0009-0001" num="0000"><ul id="ul0010" list-style="none"><li id="ul0010-0001" num="0049"><b>1</b>) If the RACF has K_S, it will pass to the service control function the quantity X=K_S(K_F, F, t); or, </li><li id="ul0010-0002" num="0050"><b>2</b>) Otherwise, the RACF will pass to the service control function the quantity Y=K_SCF(K_F, t). On receiving this quantity, the service control function will decrypt it and compute X=K_S(K_F, F, t). In this case, RACF does not need to know the key shared between the subscriber and service control function. The quantity Xis then included in the token T and passed to the client application in step <b>4</b> of the pull model. The step <b>5</b> of the push model may be augmented to include X. </li></ul></li></ul>

0051In addition, the invention envisions the case where K_Sis shared only by the RACF and the client (but not the service control function). Then case 1) can actually protect the session key from the service control function. This option may be considered in certain deployment scenarios.

0052Upon receiving X, the client application extracts from it K_Fand t, and then—in step <b>5</b> of the pull model—it includes in the token T the quantity Y=[t, K_F(timestamp)] and sends it to the border gateway as part of the session initiation process.

0053When the border gateway receives it and determines that the timestamp is fresh, it replies—in step <b>8</b> of the pull model—with the authenticator A=K_F(timestamp+1).

0054The push model can be augmented with the above exchange. Alternatively, the RACF can simply deliver the key to the border gateway in step <b>3</b>. In this case, the ticket is not used and the quantity X is computed as follows: <br /><i>X=K</i>_S(<i>F,K</i>_F).

0055From now on, each packet in the flow can be authenticated using any existing mechanism (such as hashed message authentication code [HMAC]) that uses the shared key. The use of HMAC in the message authentication code is a standard practice. It is accomplished as follows: When a principal A sends a message M to a principal B, A computes a quantity H(M, K), which is the hash of a certain function ƒ(M, K) of M and the shared key, K, and then attaches this quantity to the message. Thus what is really sent is [M, H(M, K)]. When B receives a message (M′, Q), B computes H(M′, K) and checks whether it is equal to Q. If it is, then B knows that only A could send this message because only A knows K.

0056To further protect against the replay, the present invention contemplates that such mechanisms must include time stamping. One way of achieving this is for both principals—the user equipment and border gateway—to remember the initial value of timestamp so that each subsequent packet i in the flow computes HMAC on the string that includes the quantity timestamp+i.)

0057Envisioning particularly long sessions, this invention employs a mechanism to regenerate K_F. For this, a special timer, T_F, is associated with a key, K_F, at the time it is generated. When this timer expires, the key generation and distribution procedure is repeated. To ensure that both principals transition flawlessly to using the new key, this invention defines the transition timer, Δ_F. The latter defines the time period when both the old and the new keys are valid. To employ these timers, the clocks of the principals must be synchronized. This can be achieved by using the Network Time Protocol (NTP) or the global position system.

0058The invention also envisions a related problem, which is that the K_Scan be changed, too. If this key is used, the service control function is responsible for provisioning RACF with it when it has changed. Such a change, however, does not have an effect on the existing session.

0059The session key, K_F, once established, can be also used for integrity protection or confidentiality on the segment between the end-user's terminal and the border gateway.

0060This invention has also provided a solution to a problem when a certain class of the Network Address Translation (NAT) devices that are application aware (such as a SIP-aware NAT or another application-level gateway) is employed at the home or enterprise network where the subscriber is located. The problem description is accompanied by <figref idref="DRAWINGS">FIG. 3</figref>. Here, as before, the service control function <b>20</b> identifies—and passes to the RACF <b>30</b> and the client <b>10</b>—the flow F. But the NAT device <b>50</b> modifies F; the new value, F′, which is passed to the client is constructed so that NAT translates it to F. In this case, the client may not use F′ for authentication; however, since it had received F in the ticket (which is not changed by NAT), it can use the correct quantity in the HMAC calculation.

0061The foregoing description merely illustrates the principles of the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements, which, although not explicitly described or shown herein, embody the principles of the invention, and are included within its spirit and scope. Furthermore, all examples and conditional language recited are principally intended expressly to be only for instructive purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure.

0062In the claims hereof any element expressed as a means for performing a specified function is intended to encompass any way of performing that function including, for example, a) a combination of circuit elements which performs that function or b) software in any form, including, therefore, firmware, microcode or the like, combined with appropriate circuitry for executing that software to perform the function. The invention as defined by such claims resides in the fact that the functionalities provided by the various recited means are combined and brought together in the manner which the claims call for. Applicant thus regards any means which can provide those functionalities as equivalent as those shown herein. Many other modifications and applications of the principles of the invention will be apparent to those skilled in the art and are contemplated by the teachings herein. Accordingly, the scope of the invention is limited only by the claims.