WO2008006309A1

WO2008006309A1 - Method and apparatus for determining service type of key request

Info

Publication number: WO2008006309A1
Application number: PCT/CN2007/070185
Authority: WO
Inventors: Yanmei Yang; Chengdong He
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2006-07-04
Filing date: 2007-06-26
Publication date: 2008-01-17
Also published as: CN101102191A; CN101102191B

Abstract

A method for determining a service type of a key request comprises the steps of: carrying an information of the requested service type in the key message of the requested push service; determining the service type of the requested key applying according to the requested type information carried in the key message of the requested push service. An apparatus for determining a service type of a key request includes: a message generating unit for carrying an information of the requested service type in the key message of the requested push service; and a judging unit for determining the service type of the key applying requested by a network application function entity according to the requested type information carried in the key message of the requested push service.

Description

Method and device for determining key request service type

This application claims priority to Chinese Patent Application No. 200610101049.1, entitled "Method for Determining Key Request Service Type in General Authentication Framework", filed on July 4, 2006, the entire contents of which are hereby incorporated by reference. Combined in this application. Technical field

The present invention relates to the field of network communication technologies, and in particular, to a method and apparatus for determining a key request service type. Background technique

In the third generation of wireless communication standards, multiple application service entities use a common structure for performing user identity verification, namely the Generic Authentication Architecture (GAA). The application of the universal authentication framework enables the user of the application service to check and verify the identity, and provides a key for secure communication for the user to access the application service. The plurality of application services may be a multicast or broadcast service, a user certificate service, an information immediate service, or a proxy service.

Figure 1 shows the structure of GAA:

The universal authentication framework is usually located by the UE (user;), the Bootstrapping Server Function (BSF), the Home Subscriber Server (HSS), and the location of the HSS. The user location function entity (SLF, Subscriber Locator Function) and the network application function entity (NAF, Network Application Function). The BSF is used for mutual authentication with the UE, and generates a shared key Ks of the BSF and the user. The HSS stores a description file for describing user information, and the HSS also has the function of generating authentication information. Dz, Zh, Zn, Ub, and Ua are interfaces between entities.

Generally, when the UE needs to use a certain service, it needs to contact the network application function entity NAF corresponding to the service, that is, the UE initiates a connection request to the NAF. If the NAF uses the GAA universal authentication framework, the UE first needs to authenticate with the BSF to verify the identity. After the authentication succeeds, the UE calculates the derived key Ks_NAF that communicates with the NAF based on the shared key Ks with the BSF, and sends the session transaction identifier (B-TID) containing the Ks information to the NAF, according to the received B. -TID obtains the derived key Ks_NAF of the shared key Ks from the BSF. In this way, the UE will It is possible to communicate securely with the NAF using the derived key Ks-NAF at the Ua port.

In some application scenarios, the network side needs to initiate a communication request to the UE, that is, push the service. Before the NAF sends a push message to the user, it needs to go to the BSF to request the Ks-NAF derived key of the Ua port communication. When the BSF receives the key request from the NAF, first of all, it needs to know the NAF request type, that is, the Ua interface service communication type is a service initiated by the general UE or a push service initiated by the NAF; The BSF also needs to distinguish between a general NAF-related key request and a Ks key renegotiation request. Then, according to the type of business, the corresponding processing is done. For example, if the general UE initiates a service, after receiving the request, the BSF needs to find whether there is a Ks key corresponding to the B-TID locally, and if not, an error message will be returned to the NAF; however, if it is a push service, and If the key corresponding to the user is not found, then the BSF needs to obtain a set of authentication vectors from the user home server HSS, and then calculate a new Ks and derived key and B-TID, and the authentication vector The authentication token AUTN is sent to the NAF with the derived key and the B-TID. In addition, when the NAF already has a NAF-related key that is protected by the UE, but because the key is valid, or for other reasons, the NAF wants to update the key and the original Bootstrapping session data. (Ks, B-TID, etc.), then the NAF needs to perform Ks key renegotiation with the BSF. In this case, the BSF will obtain a set of authentication vectors from the HSS regardless of whether the existing Ks is valid, and then calculate a new Ks and derived key and B-TID, and will be in the authentication vector. AUTN and derived keys and B-TID are sent to NAF.

In the existing GAA technology, only one type of communication security implementation scheme of the UE initiated service is provided. After the NAF receives the communication request from the UE, if the request carries the B-TID, then a key request is sent to the BSF, that is, a self-boot authentication protocol information request (BIR, Bootstrapping-Info-Request). After the BSF finds the key Ks corresponding to the B-TID, it calculates the Ks derived key according to parameters such as NAF-ID (NAF identification) and Ks, RAND (random number), and then passes the self-guiding authentication protocol information. A response (BIA, Bootstrapping-Info-Answer) message is sent to the NAF. The current GAA push technology does not provide an effective solution for how the NAF notifies the BSF of its request type. This will cause the BSF to receive the NAF key request and not know how to make the request. The correct response. Summary of the invention

The embodiment of the present invention provides a method for determining a key request service type, which can effectively distinguish the Ua interface service communication type after receiving the key request, thereby correctly responding to the NAF request.

An embodiment of the present invention provides a method for determining a key request service type, including: carrying a request service type information in a request service key message;

And determining, according to the service type information carried in the request service key message, the service type of the requested key application is a push service.

An embodiment of the present invention provides a system for determining a key request service type, including: a message generating unit, configured to carry a request push service type information in a request service key message;

The determining unit is configured to determine, according to the service type information carried in the request service key message, a service type of the requested key application as a push service.

The embodiment of the invention further provides a network application function entity, including:

a message generating unit, configured to carry the request push service type information in the request service key message;

a sending unit, configured to send a request service key generated by the message generating unit and carrying the request to push the service type information; %, a packet, and a packet.

The embodiment of the present invention further provides a self-booting authentication protocol service function entity, including: a receiving unit, configured to receive a request service key message carrying the request push service type information; and a determining unit, configured to use the request service key according to the request The service type information carried in the message determines that the service type of the requested key application is a push service.

The technical solution provided by the embodiment of the present invention carries the request service type information in the GAA request service key message, so that the BSF can determine the type of the requested service key according to the information, and correctly respond to the NAF request. The invention can provide guarantee for the selection of the GAA push service key, thereby ensuring the security of the push service. DRAWINGS

1 is a schematic structural diagram of a general authentication framework in the prior art; 2 is a flow chart of an implementation of a preferred embodiment of the present invention. detailed description

The technical solution provided by the embodiment of the present invention is that, in the GAA push service, when the NAF sends a key secret request to the BSF, the BSF is notified of the key request type, so that the BSF responds correctly to the NAF request. In order to enable the BSF to identify the key request type of the NAF, the DIAMETER message of the key request message BIR sent on the existing Zn interface may be extended, and the B-TID parameter in the BIR message is reused to transmit the user identity information, and the information is extended. The other parameter value indicates the request type, or a parameter that identifies the user identity is added to the BIR message. Or extend the Zn interface to define a push service key request message similar to the existing BIR message.

In order to make those skilled in the art better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

Referring to Figure 2, Figure 2 is a flow diagram of an implementation of a preferred embodiment of the present invention:

Step 201: The NAF sends a service key request message to the BSF, where the BSF request type can be indicated as pushing.

Since in the normal GAA process, when the NAF needs to communicate with the UE using the GBA key, it will send a BIR authentication, authorization, accounting protocol Diameter message to the BSF, requesting the Ks-NAF key, and therefore in the GAA push service. In the modification, or by using some parameters in the existing BIR message, the BSF NAF may be notified that the key to be requested is to be used for push service communication.

The structure of the BIR in the prior art is as follows:

< Bootstrapping-Info-Request> ::=< Diameter Header: 311, REQ, PXY, 16777220 >

< Session-Id >

{ Vendor- Specific- Application-Id }

{ Origin-Host } ; NAF address

{ Origin-Realm } ; NAF domain name

{ Destination-Realm } ; BSF i or name

[ Destination-Host ] ; BSF address

* [ GAA-Service-Identifier ]; Business Identity { Transaction-Identifier } ; B-TID( Bootstrapping ^] \^> when the identity is only {NAF-ID } ; NAF ID

[ GBA U- Awareness-Indicator ] ; Logo NAF with GBA U function *[ AVP ]

* [ Proxy-Info ]

* [ Route-Record ]

The above Diameter header contents are shown in Table 1 below:

Table 1: Version number Message length

Command tag command code (Command-Code)

Application ID (Appl ication-ID)

Hop-by-Hop logo

End-to-End identifier

AVPs - Existing GAA Push Processes: BSF needs to know which user NAF wants to push information to. In order for the BSF to find the authentication information corresponding to the user, and to determine whether the NAF has the right to push the information to the user.

Therefore, when the NAF requests a key from the BSF, it needs to send the identity of the user to the BSF, and instructs the BSF to request the service type to be push, that is, to notify the BSF that the key to be requested by the NAF is to be used for pushing the service communication.

In the embodiment of the present invention, the BSF may be notified by modifying or utilizing some parameters in the existing BIR message: The key to be requested by the NAF is to be used for push service communication. The following is a detailed description of the structure of the BIR message in the prior art.

1. Self-boot authentication Bootstrapping key request message using the Diameter protocol message sent on the existing Zn interface.

User identification parameters can be carried in any of the following ways:

(1) Using the B-TID parameter in the BIR message to convey a certain identity of the user, such as the user's IP Multimedia Subsystem Private User Identity (IMPI), International Mobile Subscriber Identity (IMSI), or International Mobile Subscriber Identifier (IPSI). Subsystem public user An identification (IMPU) or the like used to identify the identity of the user. After the BSF receives the BIR message, it can obtain the user identity from the parameter. In this case, other parameters need to be extended to assist the BSF to further distinguish whether the GBA push service. For example, the GAA-Service-Identifier parameter in the BIR message may be extended by a new value, or may be implemented by extending the value of the NAF-Id parameter, or may be implemented by extending the Vendor-Specific-Application-Id value. , or can be achieved by extending the Application-ID of the Diameter header.

Of course, since the format of the B-TID is special (for example, the B-TID suffix is "@BSF_server_domain_name"), the BSF can directly form the user identity itself carried in the Transaction-Identifier parameter carrying the B-TID. The format is used to know whether or not the B-TID is carried, so as to further distinguish whether it is a normal GBA request or a GAApush, and does not need to extend other parameter values.

These methods do not need to increase the parameters of the BIR message, but only need to extend some parameter values.

(2) Add an AVP parameter identifying the user identity in the BIR message. For example, if the NAF needs to notify the BSF of the user's private identity, the AVP parameter of the User-Name can be added to the BIR message. If the NAF needs to notify the BSF of the user's public identity, the AVP parameter of the Public-Identity may be added to the BIR message. If it is another type of identifier, it can be similarly processed, for example, by passing it in User-Name or Public-Identity, or adding similar AVP parameters. At this time, the BSF can determine whether the push service key request is based on whether the newly added user identity parameter or the B-TID parameter is included in the key request message sent by the NAF. For example, if there is a B-TID parameter in the BIR message, it indicates that the normal UE initiates a key request for the service. If there is a User-Name or Public-Identity AVP parameter or other type of AVP parameter in the BIR message, it indicates a key request for the GBA push service.

(3) Add AVP parameters identifying the user identity in the BIR message, and expand at the same time

The GAA-Service-Identifier or Application-ID parameter indicates to the BSF the type of request.

2. Redefine the Diameter message type on the Zn interface and expand the Zn port.

For example, a Bootstrapping-Info-Push-Request (Built-in Authentication Protocol Push Request) message similar to a BIR message is defined. Command-Code in the above Diameter header A new value is defined in the field to indicate the message command, and all the parameters that need to be carried in the GAA push service are defined in this new message.

The format of the message can be specified as:

Bootstrapping-Info-Push-Request::=<Diameter Header: 311, REQ, PXY, 16777220 >

< Session-Id >

{ Vendor- Specific- Application-Id }

{ Origin-Host }; NAF Address

{ Origin-Realm } ; NAF domain name

{ Destination-Realm }; BSF domain name

[ Destination-Host ] ; BSF address

* [ GAA-Service-Identifier ] ; Business ID

{ user identity } ; user ID

{NAF-ID }; NAF logo

[ GBA U- Awareness-Indicator ] ; Identification NAF has GBA U function

{ Other parameters} ; Other parameters

*[ AVP ]

* [ Proxy-Info ]

* [ Route-Record ]

The value of the Diameter Header 311 (or other unused value) indicates that the message is a push service key request.

Step 202: After receiving the request message, the BSF determines the service type of the key application requested by the NAF according to the request type information carried in the message, and selects an available push service key for the NAF.

It can be seen that, by using or modifying an existing BIR message, the NAF can directly and effectively notify the BSF of the service type to which the required key needs to be applied, so that the BSF can correctly process the NAF according to the notification. Select the available keys to secure the push service communication. Step 203: When the NAF needs to update the push service key, send a push service key renegotiation request message to the BSF, and carry the request type information in the message.

Those skilled in the art know that when the NAF already has a NAF-related key that is protected by the UE, but because the key is valid, or for other reasons, the NAF needs to update the key and the original Bootstrapping session data (Ks, B). -TID, etc.). At this time, the NAF needs to send a Ks key renegotiation request to the BSF. After receiving the BSF, the BSF will obtain a new set of authentication vectors from the HSS regardless of whether the existing Ks has expired. Then a new Ks and derived key and B-TID are calculated, and the AUTN and derived key and B-TID in the authentication vector are sent to the NAF.

In the embodiment of the present invention, the Ks renegotiation request may use the same message as the push service key request. Specifically, the BSF can distinguish whether to push the service key request message or the Ks renegotiation request message in the following two manners.

(1) The Ks renegotiation request message extends the push service key request message, that is, the Ks renegotiation request message and the push service key request message use the same Diameter Header and other common parameters, but only set special values for some parameters. To indicate that it is a Ks renegotiation request. For example, the request message carries a B-TID to indicate, or carries a special AVP parameter value, such as adding a GSID (GAA-Service-Identifier) or an application ID or a NAF-ID value. Of course, since the format of the B-TID is special (for example, the B-TID suffix is "@BSF_server_domain_name"), the BSF can directly carry the user identity itself carried in the parameter Transaction-Identifier carrying the B-TID. Form the format to know if the user identity is a B-TID. And further distinguish whether it is a normal GBA request, or GAA push, do not need to extend other parameter values.

(2) All NAF information recorded by the BSF to the BSF during the validity period of a Ks is recorded. If corresponding to a Ks, save all NAFs that have used the Ks in a NAF list. When the key request of any NAF in the list is received again within the validity period of the Ks, it is considered as a Ks renegotiation request.

In addition, it is also possible to define a new message different from the push service key request message specifically for use as a key request message for Ks renegotiation. At this time, both the B-TID and the user's permanent identity can identify a user, so the message can carry the B-TID or carry the user's permanent identity. A new value needs to be defined in the Command-Code field in the Diameter Header of the message. Indicates the message command and defines all the parameters that need to be carried in the GAA push service in this new message.

For example, you can specify the message format as follows:

Bootstrapping-Info-Push-Request::=<Diameter Header: 312, REQ, PXY, 16777220 >

< Session-Id >

{ Vendor- Specific- Application-Id }

{ Origin-Host } ; Address of NAF

{ Origin-Realm }; Realm of NAF

{ Destination-Realm } ; Realm of BSF

[ Destination-Host ] ; Address of the BSF

* [ GAA-Service-Identifier ]; Service identifiers

{ user identity } ; user identity

{NAF-ID } ; NAF - ID

[ GBA U- Awareness-Indicator ]; GBA U awareness of the NAF

{ Other parameters}; Other parameters

*[ AVP ]

* [ Proxy-Info ]

* [ Route-Record ]

Step 204: After receiving the request message, the BSF reselects the push service key according to the request type information carried in the message for the NAF.

The following describes, respectively, the key request sent by the NAF in the present invention and the various implementation processes of the BSF determining the Ua interface service communication type according to the request.

Example 1

1. When the NAF needs to send a push message to the UE, but there is no negotiated GAA push service key in the local area, the GAA push service key request message is sent to the BSF. User identification information is carried in the request message.

The message can be sent in the following way:

Use the BIR message of the Diameter protocol, and carry the user identity in the B-TID of the message. Know the information, and extend the existing GSID or Vendor-Specific-Application-Id or Application ID value or NAF-ID to inform BSF NAF that you want to push services on the Ua interface. The value of B-TID represents the user identity. Logo. The structure of the message is exactly the same as the existing BIRD's. It only extends the value of the parameter GSID or Vendor-Specific-Application-Id, or adds a new value to the NAF-ID or Application ID.

2. After receiving the above request message, the BSF can know that the NAF needs to request the push service key according to the value of the extended parameter GSID or Vendor-Specific-Application-Id or the value of the NAF-ID or the Application ID. Then, the user identity is obtained from the value of the B-TID, and processed according to the existing GAA push process.

Example 2:

1. When the NAF needs to send a push message to the UE, but the local GAA push service key is not negotiated, the GAF push service key request message is sent to the BSF, and the user identity information is carried in the request message. The message may be sent in the following way:

The BIR message of the Diameter protocol is extended, that is, some parameters are added to the existing BIR message to indicate. If the NAF needs to notify the BSF of the user's private identity, the AVP parameter of the User-Name can be added to the BIR message. If the NAF needs to notify the BSF of the user's public identity, then the AVP parameter of the Public-Identity can be added to the BIR message. Similarly, if it is another type of identification, the corresponding AVP parameters are added.

For example, extend an existing BIR message as follows:

< Bootstrapping-Info-Request> ::=<Diameter Header: 311, REQ, PXY,

16777220 >

< Session-Id >

{ Destination-Realm } ; Realm of BSF

[ Destination-Host ] ; Address of the BSF

* [ GAA Service-Identifier ] ; Service identifiers

{ Transaction-Identifier }; B-TID {NAF-ID } ; NAF ID

[ user identity ] ; user's IMPI

[Public-Identity ] ; User's public identity

[ GBA U- Awareness-Indicator ] ; GBA U awareness of the NAF *[ AVP ]

* [ Proxy-Info ]

* [ Route-Record ]

In addition to the two AVP parameters added in the above example ( [ user identity ] , [public-Identity ] ), you can also add the identity AVP parameters of other types of users.

Of course, it is also possible to extend the existing GSID as described in Embodiment 1, or

The Vendor-Specific-Application-Id, or Application ID value, or NAF-ID, is used to inform the BSF that the NAF wants to push the service mode on the Ua interface, and also adds the AVP parameter indicating the user identity.

2. After receiving the above request message, the BSF knows that the NAF is requesting the GAA push service key according to the type of the user identity provided by the NAF. That is, if there is a B-TID in the BIR, it indicates a key request for the normal UE to initiate the service; if the BIR message has the AVP parameter of the User-Name or Public-Identity and other types of AVP parameters, it indicates that the NAF initiates Push the key request for the business. Then follow the existing GAA push process for subsequent processing.

Example 3:

1. When the NAF needs to send a push message to the UE, but the local GAA push service key is not negotiated, the GAA push service key request message is sent to the BSF, and the user identity information is carried in the request message. The message can be sent in the following way:

Redefine the DIAMETER message type on a new Zn interface, which means to expand the Zn port. For example, define a message named Bootstrapping-Info-Push-Request, and give it a new definition of the command code (such as 312), and define all the parameters that need to be carried in the GAA push in this new message, remove the BIR. Some parameters that are not used in GAA push, such as B-TID.

The following message formats can be used: <Bootstrapping-Info-push-Request>::=<Diameter Header: 312, REQ, PXY, 16777220 >

< Session-Id >

{ Vendor- Specific- Application-Id }

{ Origin-Host } ; Address of NAF

{ Origin-Realm } ; Realm of NAF

{ Destination-Realm } ; Realm of BSF

[ Destination-Host ]; Address of the BSF

* [ GAA-Service-Identifier ] ; Service identifiers

{NAF-ID } ; NAF - ID

[ user identity ] ; user's IMPI

[Public-Identity ] ; User's public identity

[ GBA U- Awareness-Indicator ] ; GBA U awareness of the NAF

*[ AVP ]

* [ Proxy-Info ]

* [ Route-Record ]

In addition to the two AVP parameters added in the above example ( [ user identity ] , [public-Identity ] ). You can also increase the AVP parameters that need to be carried in the GAA push.

2. After receiving the above request message, the BSF can know that the message is a requesting GAA push service key according to the type of the request message, and can obtain the required information from each AVP parameter. Then you can follow the existing GAA push process for subsequent processing.

Example 4:

1. When the NAF needs to send a push message to the UE, and the locally negotiated GAA push service key, the key needs to be updated for some reason and thus needs to update the existing Bootstrapping session data. At this time, the NAF sends a push service key renegotiation request message to the BSF, where the request message carries user identity information, which may be a permanent identity identifier or a B-TID.

The push service key renegotiation request message can be implemented in the following manner:

(1) Redefine the Diameter message type on a new Zn interface, the message is different Push the service key request message. For example, define a message called Bootstrapping-Info-Push-Request. And give it a new definition of the command code (such as 312), and all the parameters that need to be carried in the GAA push are defined in this new message, and remove the parameters that are already in the BIR but are not used in the GAA push, such as B. -TID.

For example, you can define the message format as follows:

< Bootstrapping-Info-push-Request> ::=<Diameter Header: 313, REQ, PXY, 16777220 >

< Session-Id >

{ Vendor- Specific- Application-Id }

[ user identity ] User's IMPI

[Public-Identity ] User's public identity

[ GBA U- Awareness-Indicator ] Logo NAF has GBA U function

*[ AVP ]

* [ Proxy-Info ]

* [ Route-Record ]

In addition to the two AVP parameters ( [ user identity ] , [public-Identity ] ) added in the above example, you can also add other AVP parameters that need to be carried in the GAA push.

(2) The extended push service key request message is used as the push service key renegotiation request message, that is, the push service key renegotiation request message and the push service key request message use the same Diameter Header and other common parameters. Just set a special value for some parameters to indicate that it is a Ks renegotiation request. For example, the B-TID is carried in the request message to represent or carry a special AVP parameter.

(3) Push service key renegotiation request message is the same as general push service key request A key request message, and the BSF records all NAF names that have requested the key from the BSF during a certain Ks validity period. For example, corresponding to a Ks, all NAFs that have used the Ks are saved in a NAF list. When the key request of any NAF in the list is received again within the validity period of the Ks, it is considered as a Ks renegotiation request.

It will be understood by those skilled in the art that all or part of the units or steps in the foregoing embodiments may be implemented by a program to instruct related hardware, and the program may be stored in a computer readable storage medium, such as a storage medium, such as ROM/RAM, disk, CD, etc. Alternatively, they may be fabricated into individual integrated circuit modules, or a plurality of modules or steps may be fabricated into a single integrated circuit module. Thus, the invention is not limited to any particular combination of hardware and software.

In summary, the technical solution provided by the embodiment of the present invention in the GAA push service is self-booting (Bossapping) by using the Diameter (New Generation Authentication, Authorization, Accounting Protocol) message sent on the existing Zn interface. The BIR is extended by the BIR message, and the B-TID parameter in the BIR message is used to transmit the user identity information, and the other parameter value indication request type is extended, or the parameter identifying the user identity is added to the BIR message, so that the BSF is based on the BIR. The B-TID parameter or the user identity information carried in the message can determine that the service key request is pushed, and the NAF request is correctly responded. Or, by extending the Zn interface, a push service key request message similar to the existing BIR message is defined. After receiving the request message, the BSF can learn the Ua interface service type from the message type, so that the NAF can be selected for use. Push business key. The invention can provide guarantee for the selection of the GAA push service key, thereby ensuring the security of the push service.

While the invention has been described by the embodiments of the present invention, it is understood that the invention

Claims

Rights request

A method for determining a type of a key request service, comprising:

Carrying the request service type information in the request service key message;

The method according to claim 1, wherein the carrying the request service type information in the request service key message comprises:

Extending the self-booting authentication protocol information request parameters in the BIR message;

The extended BIR message is sent to the BSF to request a service key, and the request type is a push service.

The method according to claim 2, wherein the parameter of the extended self-booting authentication protocol request BIR message is implemented by the following method:

Using the session transaction identifier B-TID field in the BIR message to carry the user identification information, and extending the universal authentication framework service identifier GSID, or the service provider application identifier, or the NAF identifier, or the authentication authorization message in the Diameter header in the BIR message. The value of the application identifier indicates the request type information.

The method according to claim 2, wherein the parameter in the extended self-booting authentication protocol request BIR message is implemented by the following method:

An AVP parameter indicating the user identification and/or an AVP parameter indicating the request type information is added to the BIR message.

The method according to claim 4, wherein the AVP parameter is specifically: an AVP parameter indicating a private identity of the user; or a public identity of the user.

AVP parameter; or AVP parameter representing the user alias pseudonym.

The method according to claim 1, wherein the carrying the request service type information in the request service key message is implemented by the following method:

The request service key message is a dedicated message requesting a push service key.

The method according to any one of claims 1 to 6, wherein the requesting the service type information in the request service key message comprises:

Extend the Transaction-Identifier parameter to carry the user ID; Determining, according to the user identity identifier format carried in the Transaction-Identifier parameter, the requested key service type is a push service.

The method according to any one of claims 1 to 6, wherein the method further comprises:

The BSF records the derived key of the shared key to which the shared key was requested during the validity period of the shared key.

NAF information;

When the push service key request of the NAF to which the derived key of the shared key has been requested is received within the validity period of the shared key, it is determined that the request is a key renegotiation request.

The method according to any one of claims 1 to 6, further comprising:

When a shared key renegotiation is required, a key renegotiation request message indicating that the request type is renegotiation is sent.

10. The method according to claim 9, wherein the key re-negotiation request message indicating that the request type is re-negotiating is a dedicated message requesting key renegotiation.

The method according to claim 9, wherein the key re-negotiation request message indicating that the request type is re-negotiated is implemented by a method of pushing a service key message by an extension request.

The method according to claim 11, wherein the method for pushing the service key message is: carrying the B-TID in the key renegotiation request message; or The negotiation request message carries a special AVP parameter.

A system for determining a key request service type, comprising: a message generating unit, configured to carry a request push service type information in a request service key message;

14. A network application functional entity, comprising:

a sending unit, configured to send the request to push service class generated by the message generating unit Request service key for type information; %, package,.

A self-guided authentication protocol service function entity, comprising: a receiving unit, configured to receive a request service key message carrying a request to push service type information; and a determining unit, configured to use the request service key according to the request The service type information carried in the message determines that the service type of the requested key application is a push service.