Thursday, September 4, 2014

NASS Bundled IMS Authentication : Detailed

The Network Attachment Subsystem (NASS) provides registration at access level and initialization of User Equipment (UE) for accessing to the TISPAN NGN services. The NASS provides network level identification and authentication, manages the IP address space of the Access Network and authenticates access sessions. The NASS also announces the contact point of the TISPAN NGN Service/Applications Subsystems to the UE. Network attachment through NASS is based on implicit or explicit user identity and authentication credentials stored in the NASS. 
 
Subsystem Discovery :
The contact information provided by the NASS should either be in the form of the IP address of the contact point or in the form of the FQDN of the contact point (in which case the NASS provides the IP address of the DNS server that is able to resolve this FQDN into the IP address of the contact point). Alternatively, the contact point to the TISPAN NGN Service/Applications Subsystems may be statically configured in the UE e.g. using Fully Qualified Domain Names (FQDN) and DNS resolution to retrieve the contact points IP addresses. This option applies in the non-roaming case. 

NASS Bundled IMS Authentication
NASS based models do not implement any authentication mechanism at all, to reduce authentication delay. The IMS users are authenticated by underlying access network authentication and their identity and their IP address are sent to IMS network as the proof of authentication. Both solutions assume anti-spoofing mechanisms in access networks while forging of IP address would lead to forged identity in IMS network. The security level of IMS network corresponds to the security level of underlying access network.
Initial registration using NASS-IMS bundled authentication

@I-CSCF
Different UEs, each with its own private user identity, can register the same shared public user identity. Registrations of all public user identities belonging to these UEs are directed to the same S-CSCF.
If the REGISTER request does not include an Authorization header field and private user identity, the I-CSCF shall derive the private user identity from the public user identity being registered, contained in the To header field, by removing URI scheme and the following parts of the URI if present: port number, URI parameters, and To header field parameters.

@ S-CSCF- HSS
Upon receipt of a REGISTER request without the "integrity-protected" header field parameter in the Authorization header field or without an Authorization header field, which is not for an already registered public user identity linked to the same private user identity, the S-CSCF shall:

1)   identify the user by the public user identity as received in the To header field of the REGISTER request and if the Authorization header field is present, the private user identity as received in the Authorization header field of the REGISTER request. If the Authorization header field is not present, the S-CSCF shall derive the private user identity from the public user identity being registered by removing SIP URI scheme and the following parts of the SIP URI if present: port number, URI parameters, and To header field parameters;
2)   check whether one or more Line-Identifiers previously received over the Cx interface, and stored as a result of a Authentication procedure with the HSS, are available for the user. If not, the S-CSCF performs the Authentication procedure with the HSS, in order to obtain these Line-Identifiers;
3)   in the particular case where the S-CSCF received via the Cx interface one or more Line-Identifiers, compare each of Line-Identifiers with the "dsl-location", "eth-location" or "fiber-location" parameter of the P-Access-Network-Info header field (if present and if it includes the "network-provided" parameter):
-     if one of these match, the user is considered authenticated.
-     otherwise i.e. if these do not match, return a 403 (Forbidden) response to the REGISTER request; and

4)   if no Line-Identifier is received over the Cx interface, send a 500 (Server Internal Error) response to the REGISTER request.



No comments:

Post a Comment