The 3GPP has introduced a recommendation for the combination of GAA/GBA and SSO and authentication mechanisms defined by Liberty Alliance and SAML v2.0. It is therefore possible to benefit from strong authentication based on AKA, the mechanisms defined by Liberty Alliance and SAML v2.0 SSO. However, the main drawback of GAA/GBA is designed for user agents who have some sort of assistance card. OMA has provided authentication solutions, z.B. based on HTTP Digest with user login information, for devices that do not have an ISIM card. All the security mechanisms we have seen are used in access networks and IMS domains. However, it is possible to extend the authentication mechanisms mentioned above in the application or service using the GAA. Attack authentication. An attacker can retrieve password authentication due to a crack or other methods. In principle, an EU does not have a SIM card, as mentioned above, HTTP Digest. This method is based on a username and password that is usually not a high security level. HTTP Digest lists several attacks, z.B.
Brute Force or a repeat attack. From a standardization perspective, there is only one authentication and access control mechanism indicated in 3GPP`s TS 33.203 (Access Security for IP-Based Services) and more generally AKA (Authentication and Key Agreement). However, there are many other authentication and access control mechanisms that have been defined to meet legacy terminal requirements and allow for faster deployment. The most common are: Of the two types of implementation, the most used is based on common secrets. The great advantage of GAA/CCM is that it creates security links between the user agent and the different applications. These partnerships consist mainly of sharing a key (the common secret) allowing the user agent to be authenticated for the application and, if necessary, to other security functions such as ensuring the confidentiality and integrity of the information (by encryption and digital signature), non-contest (digital signature), etc. The problem with these mechanisms is the way to agree on this common secret. As mentioned above, the secret is derived from the authentication keys used in AKA. Before accessing IP multimedia services, a user must register at least one IMPU (IP Multimedia Public Identity), z.B a phone number. The IMS network must then authenticate the IMPI (IP Multimedia Private Identity) during the application.
The registration process is initiated by the IMS terminal, which sends a SIP-REGISTER message to the P-CSCF, which runs its IMPI and IMPU. This message reaches the P-CSCF and sends the message to the I-CSCF. The I-CSCF sends a DIAMETER message authentication request from the user who sent the REGISTER REGISTER UAR message to HSS that responds with another UAA DIAMETER message and parallel to I-CSCF indicates the direction of the S-CSCF assigned to the user. Next, the I-CSCF transmits the registration message to the S-CSCF, which in turn sends the DIAMETER MAR message, including IMPI, which is used by the HSS to calculate the authentication vector (AV) and generates five times and which returns the S-CSCF through the MAA diameter. This message indicates that the network requires the terminal to use its security algorithms to authenticate itself. Then, the S-CSCF sends the message SIP 401 Nonauthorized with four of the five parameters that make up the VA to I-CSCF, which transmits the message to the P-CSCF.