Message Flow with AS and OP co-hosting

The solution to utilize SIP Digest authentication for SSO can maximize commonality with the already defined 3GPP approaches for interworking with non-3GPP-defined SSO system as described in TR33.924 [9] and TR33.980 [8].In the following a message flow is defined to allow the interworking with OpenID and the specific message flow is depicted as shown in Figure 7.3-7.

Figure 7.3-7 Interworking of SDALS with OpenID that co-hosts AS and OP

The basic message flow is as follows:

To initiate OpenID Authentication, the Relying Party should present the end user with a form that has a field for entering a User-Supplied Identifier. The form field's "name" attribute should have the value "openid_identifier".

NOTE 1: The Diffie-Hellman Key Exchange Protocol between the OP and the RP lies outside of the 3GPP specifications, this association using Diffie Hellman is an optional feature and not required for

interworking purposes. If the OP and RP do not both reside under the control of the same MNO, the usage of this option seems strongly advisable。

4) The RP redirects the ME's browser to the OP with an OpenID Authentication Request as defined in chapter 9 in [14]. The RP inserts into the openid.claimed_id and into the openid.identity fields the user supplied identifier of step 1.

5) Following this redirection the ME sends a HTTPS GET request to the OP.

6) The OP/AS initiates the ME authentication and responds with a HTTPS response code 401 "Unauthorized", which contains a WWW Authenticate header carrying a challenge requesting the UE to use SIP Digest

Authentication with SSO_APS. The response message also includes the OP/AS credential (OP/AS_credential). NOTE 2: The OP/AS and the IdP shall have a shared secret (Ko,i) using existing mechanism, for example, using the

Diffie-Hellman Key Exchange Protocol or pre-shared secret, the details of shared key establishment between the OP/AS and IdP are out of scope.

7) If no valid K0 is available, then the ME sends a second HTTP request to the IdP with a UE Authentication Request carrying the UE credential (U_credential) and OP/AS_credential.

8) The IdP obtains the OP/AS_credential; The IdP authenticates the RP based on the OP/AS_credential; then generates and stores related authentication result OP/AS_Auth. According to the U_credential, the IdP first checks whether there is already a shared secret K0 between the UE and IdP. If K0 exists, the process jumps to step 15; otherwise, the process goes on to the next step.

9) The IdP sends authentication request to the HSS, it then obtains the SIP Digest authentication vector SD-AV and the user profile based on the U_credential from the HSS. The SD-AV consists of the qop (quality of protection) value, the authentication algorithm, realm, and a hash, called H (A1), of the U_credential, realm, and password. Refer to RFC 2617[5] for additional information on the values in the authentication vector for SIP Digest based authentication. In a multiple HSS environment, the IdP may have to obtain the address of the HSS where the UE is stored by querying the SLF.

10) The IdP generates a random nonce, stores H(A1) and the nonce against the U_credential.

11) The IdP sends a 401 Auth_Challenge to the UE which includes the nonce, the realm, qop, algorithm and U_credential.

12) Upon receiving the challenge, the UE generates a random cnonce and the H(A1), and then generates the shared secret K0 based on the H(A1), the cnonce, etc. It then uses the cnonce as well as parameters provided in the 401 Auth_Challenge such as nonce, U_credential and qop to calculate an authentication response according to RFC 2617[5].

13) The UE sends a response to the IdP which includes the cnonce, the nonce, the response, the realm, the U_credential, qop, algorithm, nonce-count and digest-url.

14) Upon receiving the response, the IdP uses the previously stored nonce to check against the nonce included in the response. If the check is successful, the IdP calculates the expected response (Xresponse) using the previously stored H (A1) and the nonce together with other parameters contained in the response (e.g.cnonce, nonce-count, qop, as specified in RFC 2617[5]) and uses this to check against the response sent by the UE. If the check is successful, the authentication of the UE is succeeded, else the authentication fails. If the UE is successfully authenticated, the IdP calculates the value of rspauth based on SIP Digest as specified in RFC 2617 [5] and generates the shared secret K0 based on the H(A1), the cnonce, etc.

15) The IdP knows the User authentication conclusion (UE_Auth); and then the IdP generates a random nonce1 and generates a shared secret K1 based on K0 and nonce1. The IdP encrypts the nonce1 and OP/AS_Auth using K0, i.e. EK0(nonce1,OP/AS_Auth); and encrypts the K1 and UE_Auth using Ko,i, i.e. EKo,i (K1,UE_Auth).

16) The IdP sends the UE an message including EK0(nonce1,OP/AS_Auth), EKo,i (K1,UE_Auth) ,and the value of

17) The UE decrypts the EK0(nonce1,OP/AS_Auth) and then obtains OP/AS_Auth and nonce1. Based on the

OP/AS_Auth the UE knows the legitimacy of the requested OP/AS. If the authentication result indicates that the OP/AS is not valid, the UE will stop visiting the OP/AS. The UE calculates the rspauth in the same way as the IdP did in step 14, and uses it to check against the rspauth sent by the IdP. If the check is successful, the authentication of the Network is succeeded, else the authentication fails. If the Network is successfully authenticated, and then the UE will generates the shared secret K1 based on K0, nonce1.

18) The message sent by the IdP is redirected to the OP/AS including EKo,i (K1,UE_Auth).

19) The OP/AS decrypts the EKo,i (K1,UE_Auth), and obtains UE_Auth and K1. The OP/AS establishes whether the

end user is authorized to perform OpenID Authentication and wishes to do so based on the authorization information stored in the UE_Auth. In particular, the UE_Auth may contain information about the type of information which is allowed to be shared with the RP. The OP/AS authenticates the user of OpenID using SSOa reference point, and generates an assertion based on the authorization information.

20) The OP/AS redirects the browser to the return OpenID address i.e. the OP/AS redirects the ME's browser back to the RP with either an assertion that authentication is approved or a message that authentication failed. The response header contains a number of fields defining the authentication assertion which may be protected by the shared secret between OP/AS and RP. The protection is especially important if the OP/AS and the RP do not reside both in the same MNO network.

21) The RP validates the assertion i.e. checks if the authentication was approved. The authenticated identity of the user is provided in the response message towards the RP. If a shared secret was established in step 3, then it is now used to verify the message from the OP/AS. If the validation of the assertion and the verification of the message are successful, then the user is logged in to the service of the RP.

If there is a failure in steps 1 through 21 – the authentication procedure stops.