WO2008089699A1 - A method and a system for authenticating a user terminal in ims network - Google Patents

Abstract

A method and a system for authenticating a user terminal in an IMS network, the method comprises: receiving a REGISTER message of user terminal UE; determining an authentication mode according to the Authentication head domain and/or private access network information P-Access-Network-Info head domain in the REGISTER message, performing an authentication processing according to the determined authentication mode.

Description

 Method and system for authenticating user terminal in IMS network The application claims to be submitted to the Chinese Patent Office on January 23, 2007, the application number is 200710073023.5, and the invention name is "an authentication method for distinguishing user terminals in an IMS network. The priority of the method and the Chinese patent application of the I-CSCF, the entire contents of which are incorporated herein by reference.

Technical field

 The invention belongs to the technical field of IMS (IP Multimedia Service Subsystem), and particularly relates to a technology for access terminal authentication in an IMS network.

Background technique

 IP (Internet Protocol) The multimedia subsystem, as the core session control layer of fixed and mobile networks, has become a direction of technological development, the third generation mobile communication system (3G) and TISPAN (Telecommunications and Internet Converged Services and Protocols for Advanced Networking, Advanced Networking Telecommunications and Internet Convergence Services and Protocols) defines many IMS-related specifications, including network architecture, interfaces, protocols, etc. Security is an important aspect of 3G and TISPAN considerations. In the existing specification, the IMS network is divided into an access domain and a core domain from a security perspective, and security specifications of the access domain and the core domain are respectively defined.

 The part of the IMS network about the transport network (Transport) is related to the specific access network. It may be a TISPAN/NGN (Next Generation Network) access network, a Packet Cable access network, and a Wireless Local Area Network (WLAN). Access to the network, etc.

 Currently, the authentication methods supported by 3GPP (The Third Generation Partnership Project) are AKA (Authentication and Key Agreement) and Early IMS (early IMS authentication).

 Currently, the authentication methods supported by TISPAN (Telecommunications and Internet Converged Services and Protocols for Advanced Networking) are: AKA, NASS-Bundled-Authentication (IMS service layer authentication and access) Layer authentication binding NBA) and HTTP DIGEST.

In the process of implementing the present invention, the inventors have found that there is currently no solution for different access networks to simultaneously access the same IMS core network. Summary of the invention

 An embodiment of the present invention provides a method for authenticating a user terminal in an IMS network and a CSCF, so that when different access networks access the same IMS network, the CSCF can distinguish the authentication mode of the user terminal, and thus can be used for the user terminal. Perform the correct authentication process.

 An embodiment of the present invention provides a method for authenticating a user terminal in an IMS network, and receiving a registration REGISTER message of the user terminal UE; an authentication Authorization header field and/or a private access network information P-Access in the REGISTER message The -Network-Info header field determines an authentication mode of the UE; and performs an authentication process according to the determined authentication mode.

 The embodiment of the present invention further provides a system, further comprising an authentication mode determining unit, configured to determine, according to an Authorization header field and/or a P-Access-Network-Info header field in a REGISTER message of the UE, an authentication mode of the UE .

DRAWINGS

 1 is a schematic block diagram of an I-CSCF in an embodiment of the present invention;

 2 is a flow chart of a method for authenticating a user terminal in an IMS network according to the present invention; FIG. 3 is a flowchart of a specific implementation manner of the embodiment of the present invention shown in FIG.

 4 is a flowchart of specific judgment of an I-CSCF according to an embodiment of the present invention;

 Figure 5 is a flow chart of the AKA authentication mode;

 6 is a flowchart of an Early IMS authentication mode;

 Figure 7 is a flow chart of the NBA authentication mode;

 Figure 8 is a flow chart of the HTTP DIGEST authentication method.

detailed description

 In the embodiment of the present invention, after receiving the REGISTER message sent by the P-CSCF, the I-CSCF distinguishes the authentication mode according to the Authorization header field and/or the P-Access-Network-Info header field in the REGISTER message, and then Subsequent authentication processing is performed. It should be noted that the corresponding functions performed by the I-CSCF in the embodiment of the present invention may also be completed by other CSCF entities.

 In order to make the objects, technical solutions and advantages of the embodiments of the present invention more comprehensible, the present invention will be further described in detail with reference to the accompanying drawings. It is understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

The embodiment of the invention discloses a system, which may be a CSCF (such as I-CSCF) or capable of Other entities that perform the same function. The system is described in detail below by taking the I-CSCF as an example. The block diagram of the I-CSCF is as shown in FIG. 1 , and includes an authentication mode determining unit 11 . After the I-CSCF receives the REGISTER message, the I-CSCF according to the Authorization header field in the message and/or Or the P-Access-Network-Info header field determines the authentication mode adopted by the UE. Specifically, the authentication mode determining unit 11 analyzes the REGISTER message received by the I-CSCF:

 If the Authorization header field in the REGISTER message has an integrity-protected parameter and its value corresponds to the AKA mode, the I-CSCF determines that the AKA authentication mode should be used;

 If the value of the integrity-protected parameter in the Authorization header field in the REGISTER message corresponds to a value other than AKA, or if there is no integrity-protected parameter in the Authorization header field in the REGISTER message, and there is no P-Access-Network-Info The access-type parameter in the header field or the P-Access-Network-Info header field indicates that the access network type is a cable cable access network, and the authentication mode of the UE is determined to be an HTTP summary mode.

 If there is no Authorization header field in the REGISTER message, and there is no P-Access-Network-Info header field or the access-type parameter in the P-Access-Network-Info header field indicates 3GPP mobile access network, then I -CSCF determines that 3GPP early IMS authentication mode should be adopted;

 If there is no integrity-protected parameter in the Authorization header field of the REGISTER message or there is no Authorization header field, and the access-type parameter in the P-Access-Network-Info header field indicates the TISPAN fixed access network, the I-CSCF determines that it should be used. TISPAN's NBA or HTTP DIGEST authentication method.

 After the authentication mode determining unit 11 determines the authentication mode of the UE, the I-CSCF performs subsequent authentication processing according to the determined authentication mode.

 It should be noted that, the foregoing I-CSCF may further include a unit for receiving a REGISTER message of the UE, where the unit provides the REGISTER message of the UE for the authentication mode determining unit 11; and may further include a determining unit according to the authentication mode. 11 The authentication method determined by the authentication method.

Please refer to FIG. 2 , which is a flowchart of an embodiment of a method for authenticating a user terminal in an IMS network according to the present invention. Step 21: Receive a registration REGISTER message of the user terminal UE.

 Step 22: Determine an authentication mode of the UE according to the authentication Authorization header field and/or the private access network information P-Access-Network-Info header field in the REGISTER message.

 Specifically, if the REGISTER message has an Authorization header field, and the integrity-protected parameter value corresponds to the AKA mode, the authentication mode of the UE is determined to be an authentication and key agreement AKA mode.

 If there is no Authorization header field in the REGISTER message, and there is no P-Access-Network-Info header field, it is determined that the authentication mode of the UE is the early IMS authentication Early IMS mode.

 If there is no Authorization header field in the REGISTER message, and

The access-type parameter in the P-Access-Network-Info header field indicates that the access network type is the 3GPP mobile access network, and the authentication mode of the UE is determined to be the early IMS authentication Early IMS mode.

 If there is no integrity-protected parameter in the Authorization header field in the REGISTER message, and the access-type parameter in the P-Access-Network-Info header field indicates the access network type is advanced network telecommunications and Internet convergence service and protocol TISPAN The fixed access network determines that the authentication mode of the UE is the IMS service layer authentication of the TISPAN and the NSA mode or the HTTP summary mode of the NASS access layer authentication binding authentication.

 If the value of the integrity-protected parameter in the Authorization header field in the REGISTER message corresponds to a value other than the AKA, determining that the authentication mode of the UE is an HTTP digest mode;

 If there is no integrity-protected parameter in the Authorization header field in the REGISTER message, and there is no P-Access-Network-Info header field, it is determined that the authentication mode of the UE is an HTTP digest mode;

 If there is no integrity-protected parameter in the Authorization header field in the REGISTER message, the access-type parameter in the P-Access-Network-Info header field indicates that the access network type is a cable cable access network, and then determining the UE The authentication method is HTTP summary mode.

If there is no Authorization header field in the REGISTER message, and the access-type parameter in the P-Access-Network-Info header field indicates that the access network type is a TISPAN fixed access network, it is determined that the authentication mode of the UE is NBA. the way. Step 23: Perform authentication processing according to the determined authentication manner.

 In order to more clearly disclose the method embodiment for authenticating the user terminal in the above IMS network, a specific implementation manner of this embodiment is given below. The basic flow chart of this embodiment is shown in FIG. 3, and specifically includes the following steps:

 1. The UE sends a REGISTER message to the P-CSCF to request registration.

 2. The P-CSCF forwards the REGISTER message to the I-CSCF;

 3. After receiving the REGISTER message, the I-CSCF determines the user according to the parameters in the Authorization header field or the P-Access-Network-Info header field, or the parameters in the Authorization header field and the P-Access-Network-Info header field. Terminal authentication method;

 Specifically, the basis for the judgment is as follows:

 If the Authorization header field in the REGISTER message has an integrity-protected parameter and its value corresponds to the AKA mode, the I-CSCF determines that the AKA authentication mode should be used;

 If the value of the integrity-protected parameter in the Authorization header field in the REGISTER message corresponds to a value other than AKA, or if there is no integrity-protected parameter in the Authorization header field in the REGISTER message, and there is no P-Access-Network The access-type parameter in the -Info header field or the P-Access-Network-Info header field indicates that the access network type is a cable cable access network, and the authentication mode of the UE is determined to be an HTTP summary mode;

 If there is no Authorization header field in the REGISTER message, and there is no

The access-type parameter in the P-Access-Network-Info header field or the P-Access-Network-Info header field indicates the 3GPP mobile access network, and the I-CSCF determines that 3GPP early IMS authentication should be used. the way;

 If there is no integrity-protected parameter in the Authorization header field in the REGISTER message or there is no Authorization header field, and the access-type parameter in the P-Access-Network-Info header field indicates the TISPAN fixed access network, the I-CSCF determines that it should Use TISPAN's NBA or HTTP DIGEST authentication method.

4. After the I-CSCF determines the authentication mode, the I-CSCF performs subsequent authentication processing according to the corresponding authentication mode. In the specific embodiment of the present invention shown in FIG. 3, after the I-CSCF receives the REGISTER message, the root According to the authorization flow and the parameters in the P-Access-Network-Info header field, the specific process of the authentication method is as shown in FIG. 4, and includes the following steps:

 1. The UE sends a REGISTER message to the P-CSCF to request registration.

 2. The P-CSCF forwards the REGISTER message to the I-CSCF, and the I-CSCF receives the REGISTER message;

 3. After receiving the REGISTER message, the I-CSCF determines whether the Authorization header field exists in the message. If not, go to step 4. If yes, go to step 7;

 4, I-CSCF further determines whether there is a P-Access-Network-Info header field in the REGISTER message, if yes, go to step 5, otherwise go directly to step 6;

 5. The I-CSCF further determines whether the access network type indicated by the access-type in the P-Access-Network-Info header field is a 3GPP mobile access network or a TISPAN fixed access network, if it is a 3GPP mobile access network, such as 3GPP-GERAN (Global Mobile Telecommunications System GSM Edge Radio Access Network GERAN), 3GPP-UTRAN-FDD (Universal Terrestrial Radio Access Network Frequency Division Duplex) or 3GPP-UTRAN-TDD (Universal Terrestrial Radio Access Network Time Division Duplex) ), go to step 6, if it is TISPAN fixed access network, such as NASS (network attached subsystem) or DSL (digital subscriber line), go to step 9;

 6. The I-CSCF determines that the authentication mode is 3GPP Early IMS; if not, go to step 8, otherwise go to step 10;

 8. The I-CSCF determines whether the access-type in the P-Access-Network-Info header field indicates that the access network type is a TISPAN fixed access network, and if yes, go to step 9, otherwise go to step 11;

 9. The I-CSCF determines the NBA or HTTP DIGEST authentication mode using TISPAN. The I-CSCF can further distinguish the two authentication methods as follows: If the TISPAN fixed access network type is indicated as

NASS, the NBA authentication method is adopted, otherwise the HTTP DIGEST authentication method is adopted;

 10. The I-CSCF determines whether the value of the integrity-protected parameter corresponds to AKA (for example, its value is "YES" or "NO"), if yes, go to step 12, otherwise go to step 11;

11. The I-CSCF processes this as another case; for example, if the value of the integrity-protected parameter in the Authorization header field in the REGISTER message corresponds to other values of the AKA, or if the Authorization in the REGISTER message No in the header field The integrity-protected parameter, and the access-type parameter in the P-Access-Network-Info header field or the P-Access-Network-Info header field indicates that the access network type is a cable cable access network, and then the UE is determined. The authentication method is HTTP summary mode.

 12. The I-CSCF determines that the authentication method is AKA.

 After the I-CSCF determines the authentication mode according to the above process, the subsequent authentication process is performed. Different authentication methods correspond to different authentication processes. The specific authentication process can refer to the application process corresponding to various authentication modes. The application flow corresponding to each of several authentication methods is given below.

 Referring to FIG. 5, the application process of the UE is the application flow corresponding to the AKA mode, and the main steps are as follows:

 1. The initial key K is shared between the UE (User Terminal) and the HSS (Home Subscribe Server).

 2. (SM1-CM2) The user initiates a registration request SMI (SM indicates that the protocol between the two entities is a SIP message SIP Message), and the S-CSCF passes the CM1 (CM indicates a Cx interface message between the I/S-CSCF and the HSS) Cx interface Message, not the SIP protocol, but the DIAMETER protocol) requests data from the HSS. The HSS generates an authentication quintuple based on the initial key K and the sequence number (SQN, Sequence Number) and delivers an S-CSCF (Serving Call Session Control Function) through the CM2, wherein the quintuple includes (random data RAND - Random Data, authentication number AUTN - Authentication Token, expected result XRES - Expected Response, integrity protection key IK - Integrity Key, encryption key CK - Ciphering Key).

 3. (SM4-SM5) The S-CSCF returns a 401 response (authentication challenge) to the user, carrying the quaternion information except XRES.

 4. (SM6) P-CSCF (Proxy Call Session Control Function) saves IK, CK information, and transmits (RAND, AUTN) information to the UE in the 401 response.

5. (SM7-SM9) The UE authenticates whether the network device is trusted according to the information such as the initial key K and the SQN, and the AUTN sent by the received network device. If the authentication is successful, the network device is trusted, and the RAND is combined. And K, produce the result RES information, the RES will be used as the key "password" for the terminal to calculate the response response process, and the result of the calculation is sent to the network in SM7 (authentication response) On the network side, the UE calculates IK and CK by itself.

 6. The S-CSCF receives the response information generated by the RES in the SM9, and compares it with the result calculated by the X ES. If the two are the same, the authentication to the user is considered successful.

 It can be seen from the above process that the UE initiates registration with the IMS (IP Multimedia Core Network Subsystem) network, implements mutual authentication between the UE and the IMS network through AKA, and also completes the UE and the P-CSCF (proxy-call). The session control function entity) establishes an inter-security association. The UE and the P-CSCF share an encryption key CK and an integrity protection key IK. These two keys will be used for secure communication channels between the UE and the P-CSCF. The establishment of.

 Please refer to FIG. 6 , which is an application flow corresponding to the Early IMS authentication mode. The user terminal accesses a GPRS (General Packet Radio Service) network, a GGSN authentication user identifier (IMS International Mobile Subscriber Identity), and an MSISDN (Mobile Station International ISDN Number) through a GGSN (Gateway GPRS Support Node) to allocate a network transport layer to the user terminal. Identification (IP address).

 Step 1: The GGSN transmits the correspondence between the user identifier and the terminal IP address to the HSS through the "Accounting Request Start", and the HSS saves the corresponding relationship;

 Step 2. The HSS responds by "Accounting Request Answer"; Step 3. The user terminal initiates registration of the REGISTER request to the P-CSCF. The P-CSCF compares the IP address of the sent-by header field in the via header field in the REGISTER message with the source IP address in the IP header of the REGISTER message. If it is inconsistent, add a received header field. Go to the via header field and fill it with the source IP address in the IP header; the P-CSCF forwards the above REGISTER request to the S-CSCF. The S-CSCF queries whether the registration has been made based on the public user ID in the REGISTER request.

 Step 4: If not registered, request the HSS to correspond to the terminal IP address corresponding to the public user ID (the correspondence between the HSS static configuration public user ID and the MSISDN, and obtain the corresponding terminal IP address through the public user identifier);

 Step 5: The HSS returns the terminal IP address corresponding to the public user identifier.

Step 6. The S-CSCF checks the received source IP address of the REGISTER (if there is a received header field in the via header field, the received header field is preferentially compared, otherwise the sent-by header field in the via header field is compared), if If the IP address obtained from the HSS is the same, the authentication success message is sent to the GGSN. The Early IMS access domain security mechanism is only for a specific wireless access environment, and has special requirements for the access network, and cannot guarantee user access security in other access environments.

 Referring to FIG. 7, which is an application flow corresponding to the NBA authentication mode, the method includes the following steps: Step 101: Network Attachment Subsystem (NASS) access layer attachment authentication, and a connection location function entity (Connection Location) The location information of the user terminal (UE) is recorded on the Function, CLF).

 Step 102: The UE sends a registration message REGISTER message to the P-CSCF, where the message carries the access operator identifier and the access user identifier.

 Step 103: The P-CSCF determines whether a security association with the UE needs to be established by checking whether the REGISTER message includes a security negotiation parameter (for example, Security-Client). If you have this parameter, you need to create it. If you don't have this parameter, you don't need to create it. In general, Key Accounting (AKA) must have this parameter, and NASS-Bundled and Hypertext Transfer Protocol Summary (HTTP DIGEST) certainly do not have this parameter.

 Step 104: The P-CSCF determines the CLF according to the access operator identifier in the registration message and the correspondence between the preset access carrier identifier and the CLF. Then, the P-CSCF queries the location information of the user in the CLF determined above according to the source IP address of the registration message.

 Step 105: Since the location information corresponding to the source IP address is pre-stored in the CLF, the CLF returns corresponding location information and other information to the P-CSCF in this step.

 Step 106: The P-CSCF sends the registration message REGISTER carrying the location information and other information obtained in the previous step to the Interrogating-Call Session Control Function (I-CSCF).

 Step 107: The I-CSCF sends a User Authorization Request (UAR) message to the User Profile (UPSF).

 In step 108, the UPSF returns a User Authorization Answer (UAA) message.

 Step 109: The I-CSCF selects a corresponding S-CSCF according to the message returned from the UPSF, that is, selects which S-CSCF processes the registration.

Step 110: The I-CSCF forwards the registration message REGISTER including the location information to the S-CSCF determined above. Step 111: The S-CSCF determines which authentication mode is determined by whether the Integrity-Protected parameter is included in the REGISTER message. If there is this parameter, it is definitely the AKA mode. The authentication request sent by the S-CSCF to the UPSF is only for requesting the authentication parameter. If there is no such parameter, the configured authentication mode needs to be queried to the UPSF, and the S-CSCF sends it to the UPSF. The request is for requesting the authentication method and the corresponding authentication parameters. Since the NASS-Bundled authentication method is used here, the Integrity-Protected parameter is not included in the REGISTER message. The S-CSCF sends a MAR (Multimedia Authentication Request) message to the UPSF, requesting the user's authentication vector and corresponding authentication parameters.

 Step 112: The UPSF checks the authentication subscription data of the user, and finds that the authentication mode of the user is the NASS-Bundled authentication mode.

 Step 113: The UPSF sends a Multimedia Authentication Answer (MAA) message to the S-CSCF, and returns the user's authentication mode and the authentication parameter, that is, the location information.

 Step 114: The S-CSCF compares the location information sent from the P-CSCF with the location information obtained from the UPSF query. If the information is consistent, the authentication succeeds. Step 115 and subsequent processes are performed, that is, the authentication succeeds is sent to the UE. If the message is inconsistent, the authentication fails, and step 115 and subsequent steps are performed, that is, the message that the authentication fails is sent to the UE.

 Step 115: The S-CSCF sends a 2xx Auth_OK message to the I-CSCF, indicating that the authentication succeeds. Step 116: The I-CSCF sends the foregoing 2xx Auth_OK message to the P-CSCF.

 Step 117: The P-CSCF sends the foregoing 2xx Auth_OK message to the UE.

 Please refer to FIG. 8 , which is an application flow corresponding to the HTTP DIGEST authentication method, which includes the following steps:

 Step 201: The UE sends a registration message to the P-CSCF. REGISTER^

 Step 202: The P-CSCF determines whether a security association with the UE needs to be established by checking whether the REGISTER message includes a security negotiation parameter (for example, Security-Client). If you have this parameter, you need to create it. If you don't have this parameter, you don't need to create it. In general, Key Accounting (AKA) must have this parameter, and NASS-Bundled and Hypertext Transfer Protocol Summary (HTTP DIGEST) certainly do not have this parameter.

Step 203: The P-CSCF forwards the registration message REGISTER of the UE to the I-CSCF. The message also carries the location information of the UE obtained by the P-CSCF from the CLF query. Step 204: The I-CSCF and the UPSF select the corresponding S-CSCF through the Cx-Selection-Info message, that is, the I-CSCF sends a request to the UPSF to find the user attribute in the UPSF to determine which S-CSCF processes the registration file. .

 Step 205: The I-CSCF forwards the UE registration REGISTER to the S-CSCF determined in step 204.

 Step 206: The S-CSCF determines which authentication method is adopted by whether the Integrity-Protected parameter is included in the REGISTER message. If there is this parameter, it is definitely the AKA mode. The authentication request sent by the S-CSCF to the UPSF is only for requesting the authentication parameter. If there is no such parameter, the configured authentication mode needs to be queried to the UPSF, and the S-CSCF sends it to the UPSF. The request is for requesting the authentication method and the corresponding authentication parameters. Since the HTTP DIGEST authentication method is used here, the Integrity-Protected parameter is not included in the REGISTER message. The S-CSCF and the UPSF update the S-CSCF indication information on the UPSF through the Cx-Put message, and inform the UPSF that the subsequent processing by the user is performed in the S-CSCF.

 Step 207: The S-CSCF sends an MAR message to the UPSF, requesting the user's authentication mode and authentication data.

 Step 208: The UPSF checks the authentication subscription data of the user, and obtains the authentication mode of the user according to the authentication subscription data as an HTTP DIGEST authentication mode, and generates an authentication vector such as nonce and an expected result (XRES) and the like.

 Step 209: The UPSF sends a MAR message to the S-CSCF, and sends the user authentication mode information HTTP DIGEST, the authentication parameter nonce, the expected result (X ES ), and the like to the S-CSCF.

 In step 210, the S-CSCF calculates the expected result X ES .

 Step 211: The S-CSCF obtains the authentication mode information and saves the XRES, and then sends the information to the I-CSCF.

The "4xx Auth-Challenge" message, the Algorithm parameter in the WWW-Authenticate header of the message indicates that the HTTP DIGEST authentication method is used.

 Step 212, the I-CSCF sends a "4xx Auth_Challenge" message to the P-CSCF, the message

The Algorithm parameter in the WWW-Authenticate header indicates that the HTTP DIGEST authentication method is used.

 Step 213: The P-CSCF sends a "4xx Auth_Challenge" message to the UE.

Step 214, after receiving the "4xx Auth-Challenge" message, the UE finds that the Algorithm parameter indicates the HTTP DIGEST authentication mode, and re-sends the registration message REGISTER to the P-CSCF, and Carry the response (RES) for authentication.

 Step 215: The P-CSCF sends a registration message REGISTER carrying the RES to the I-CSCF. Step 216: The I-CSCF and the UPSF determine, by the Cx-Query, which S-CSCF the UE registration message is sent to, that is, the I-CSCF queries the UPSF for the S-CSCF to process the registration message, and the SSF saves the S. The -CSCF indication message informs the I-CSCF to process the S-CSCF of the registration. In the following steps, the S-CSCF sends a message of successful authentication or authentication failure to the UE.

 Step 217, the I-CSCF forwards the registration REGISTER to the S-CSCF determined in step 216. Step 218: The S-CSCF compares the X ES obtained from the UPSF with the RES sent by the UE. When the two are consistent, the authentication succeeds. When the two are inconsistent, the authentication fails.

 Step 219: The S-CSCF and the UPSF update the S-CSCF indication information on the UPSF by using a Cx-Put message, and notify the UPSF that the subsequent processing by the user is performed in the S-CSCF.

 Step 220: The S-CSCF and the UPSF obtain the subscription data information of the user by using a Cx-Pull message. Step 221: The S-CSCF sends a 200 message indicating that the authentication succeeds to the I-CSCF, or a 403 Forbidden message indicating that the authentication fails. In the figure, only the 200 message when the authentication succeeds is indicated.

 Step 222: The I-CSCF sends the foregoing message to the P-CSCF.

 Step 223: The P-CSCF sends the foregoing message to the UE.

 It can be seen from the application flow of the above various authentication methods: For the Early IMS mode, the I-CSCF needs to derive the IMPI (IMS Private User Identity) according to the IMPU (IMS Public User Identity) as follows: The URI (Uniform Resource Identifier), port number, etc. are removed as IMPI, and this is not required for other authentication methods. For the AKA method, the I-CSCF needs to perform the following S-CSCF reselection procedure: if the previous selected S-CSCF does not respond to the REGISTER message sent by the I-CSCF or sends a response message such as 3XX or 480, and the REGISTER message Without the "integrity-protected" header field, the I-CSCF performs the S-CSCF reselection process to select a new S-CSCF, which is not required for other authentication methods. For NBA/HTTP DIGEST, since the registration message may contain the Authorization header field (with IMPI), it may not include the Authorization header field, which may or may not include IMPI, so that when IMPF interacts with CFX, IMPI The acquisition method may be different from Early IMS.

It should be noted that, in the foregoing specific embodiment of the present invention, the I-CSCF receives the REGISTER. After the message, it is first determined whether the Authorization header field exists in the message, and then the next step is judged according to whether or not the Authorization is present, but in the actual application, it is also possible to first determine whether the P-Access-Network-Info exists in the REGISTER message. The header field, and then according to the presence or absence of the P-Access-Network-Info header field, the next step is judged, that is, the I-CSCF judges the Authorization header field and the P-Access-Network-Info header field and its parameters. It is not limited to a specific order, and one authentication method can be uniquely determined according to one or both of the two header fields. In addition, the HTTP DIGEST authentication method in the foregoing specific embodiment of the present invention is a general term, which includes not only the HTTP DIGEST authentication method in the traditional sense, but also the SIP DIGEST authentication method developed based on the traditional HTTP DIGEST.

 As mentioned above, the I-CSCF is based on the Authorization header field of the REGISTER message and/or

The parameter in the P-Access-Network-Info header field determines the authentication mode of the user terminal, and can solve the problem of how the I-CSCF distinguishes various authentication modes when multiple access networks access the same IMS core network. The technical solution provided by the embodiment of the present invention is also scalable, and can easily solve the problem that the I-CSCF distinguishes the new authentication when other access networks access the same IMS core network to introduce a new authentication mode. The problem with the way.

 A person skilled in the art may understand that all or part of the steps in implementing the above method embodiments may be completed by a program instructing related hardware, and the program may be stored in a computer readable storage medium, the storage medium Such as: ROM / RAM, disk, CD, etc.

 The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the protection of the present invention. Within the scope.

Claims

Rights request  A method for authenticating a user terminal in an IMS network, the method comprising: receiving a registration REGISTER message of a user terminal UE;  Determining an authentication mode of the UE according to the authentication Authorization header field and/or the private access network information P-Access-Network-Info header field in the REGISTER message;  The authentication process is performed according to the determined authentication mode.  The method according to claim 1, wherein the determining the authentication mode of the UE according to the Authorization header field and/or the P-Access-Network-Info header field in the REGISTER message includes:  If there is an Authorization header field in the REGISTER message, and the integrity-protected parameter value corresponds to the AKA mode, the authentication mode of the UE is determined to be an authentication and key agreement AKA mode.  The method according to claim 1, wherein the determining the authentication mode of the UE according to the Authorization header field and/or the P-Access-Network-Info header field in the REGISTER message includes:  If there is no Authorization header field in the REGISTER message, and there is no P-Access-Network-Info header field, it is determined that the authentication mode of the UE is an early IMS authentication Early IMS mode;  If there is no Authorization header field in the REGISTER message, and the access-type parameter in the P-Access-Network-Info header field indicates that the access network type is a 3GPP mobile access network, then the UE is determined to be authenticated. The method is Early IMS authentication Early IMS mode.  The method according to claim 1, wherein the determining the authentication mode of the UE according to the Authorization header field and/or the P-Access-Network-Info header field in the REGISTER message includes: If there is no integrity-protected parameter in the Authorization header field in the REGISTER message, and the access-type parameter in the P-Access-Network-Info header field indicates the access network type is advanced network telecommunications and Internet convergence service and protocol TISPAN The fixed access network determines that the authentication mode of the UE is the IMS service layer authentication of the TISPAN and the NSA mode or the HTTP summary mode of the NASS access layer authentication binding authentication. The method according to claim 1, wherein the determining the authentication mode of the UE according to the Authorization header field and/or the P-Access-Network-Info header field in the REGISTER message includes:  If the value of the integrity-protected parameter in the Authorization header field in the REGISTER message corresponds to a value other than AKA, determining that the authentication mode of the UE is an HTTP digest mode;  If there is no integrity-protected parameter in the Authorization header field in the REGISTER message, and there is no P-Access-Network-Info header field, it is determined that the authentication mode of the UE is an HTTP digest mode;  If there is no integrity-protected parameter in the Authorization header field in the REGISTER message, the access-type parameter in the P-Access-Network-Info header field indicates that the access network type is a cable cable access network, and then determining the UE The authentication method is HTTP summary mode.  The method according to claim 1, wherein the determining the authentication mode of the UE according to the Authorization header field and/or the P-Access-Network-Info header field in the REGISTER message includes:  If there is no Authorization header field in the REGISTER message, and the access-type parameter in the P-Access-Network-Info header field indicates that the access network type is a TISPAN fixed access network, it is determined that the authentication mode of the UE is NBA. the way.  The method according to claim 1, wherein the execution subject of each step in claim 1 is specifically: a query-call session control function entity I-CSCF.  A system, further comprising: an authentication mode determining unit, configured to determine, according to an Authorization header field and/or a P-Access-Network-Info header field in a REGISTER message of the UE, an authentication mode of the UE .  The system according to claim 8, wherein the authentication mode determining unit comprises:  When the Authorization header field is included in the REGISTER message, and the integrity-protected parameter value corresponds to the AKA mode, the authentication mode of the UE is determined to be a unit of the authentication and key agreement AKA mode. The system according to claim 8, wherein the authentication mode determination unit package Includes:  And when there is no Authorization header field in the REGISTER message, and there is no P-Access-Network-Info header field, determining that the authentication mode of the UE is an early IMS authentication Early IMS mode; or not in the REGISTER message Authorization header field, the access-type parameter in the P-Access-Network-Info header field indicates that when the access network type is 3GPP mobile access network, the authentication mode of the UE is determined to be an early IMS authentication Early IMS mode unit. .  The system according to claim 8, wherein the authentication mode determining unit comprises:  Determining the authentication of the UE when there is no integrity-protected parameter in the Authorization header field in the REGISTER message, and the access-type parameter in the P-Access-Network-Info header field indicates the TISPAN fixed access network The mode is the NBA mode of TISPAN or the unit of HTTP summary mode.  The system according to claim 8, wherein the authentication mode determining unit comprises:  Used to have no Authorization header field in the REGISTER message, and The access-type parameter in the P-Access-Network-Info header field indicates that the TISPAN fixed access network determines the NBA mode of the UE's authentication mode as TISPAN.  The system according to claim 8, wherein the authentication mode determining unit comprises:  When the value of the integrity-protected parameter in the Authorization header field in the REGISTER message corresponds to a value other than the AKA, determining that the authentication mode of the UE is an HTTP digest mode; or an Authorization header in the REGISTER message If there is no integrity-protected parameter in the domain, and there is no P-Access-Network-Info header field, it is determined that the authentication mode of the UE is HTTP summary mode; or there is no integrity-protected in the Authorization header field in the REGISTER message. The parameter and the access-type parameter in the P-Access-Network-Info header field indicate that the access network type is a cable cable access network, and the authentication mode of the UE is determined to be a unit of the HTTP digest mode. The system according to any one of claims 8 to 13, characterized in that the system is specifically a call session control function entity CSCF. The system according to claim 14, wherein the CSCF is specifically a query-call session control function entity I-CSCF.  The system according to any one of claims 8 to 13, further comprising: means for receiving a REGISTER message of the user terminal UE, the unit providing the REGISTER of the UE for the authentication mode determining unit Message; and  A unit for performing an authentication process according to the authentication mode determined by the authentication mode determining unit.