Operator MMSC Considerations – User Authentication

MMS uses the MM1 Protocol (OMA MMS Encapsulation) for transactions between a mobile device and the MMSC. This protocol does not define how the MMSC identifies and authenticates the subscriber when the MMS client on a mobile device sends or receives a message.

The MMSC is expected to interface with other operator network components to identify and authenticate the subscriber.

For example, in the MM1 send request (M-send.req), the NowSMS MMSC expects the From address to be set to a value of insert-address-token, which indicates that the MMSC should insert the sender address automatically when it sends the message. If a different From address is specified, the NowSMS MMSC will ignore this value and always use the authenticated subscriber address.

The purpose of tis document is to explain how this user identification and authentication works, and more specifically, how to configure the NowSMS MMSC, and optionally, the NowWAP Gateway, to receive this information automatically from the operator network.

For laboratory and test configurations, NowSMS allows the MMS subscriber information to be provided with each user be configured with a special MMS Message Server URL. The URL contains the username and password of the user account on the MMSC. For example, http://mmsc:port/user=password. In an operator environment, it is neither practical nor secure to provision phones with these unique MMS Message Server URLs, and it is also not practical to manually configure user accounts on the MMSC for each subscriber.

The connection between the mobile phone and the MMSC is HTTP-based, and contains no information about the MSISDN (phone number) of the user that is making the request.

To integrate into the operator network, the NowSMS MMSC expects to receive user information from an HTTP header. This HTTP header is normally inserted by a WAP Gateway, such was NowWAP. Alternatively, if a WAP Gateway is not used, the NowSMS MMSC can issue an ICAP request for HTTP Header Enrichment to acquire these headers. (NowWAP 2013 and later releases support an ICAP interface to allow the MMSC to retrieve these special headers without requiring devices to route requests through a WAP Gateway or Proxy.)

The default MSISDN header generated by NowWAP is “X-MSISDN:”. This header name is configurable, as there are other header names in use by different operators, including “X-MDN:”, “X-DEVICE-MIN:” and others.

To configure the Now MMSC to read the MSISDN from an HTTP header, configuration settings must be applied to the MMSC.INI file. The following configuration settings may be applied within the [MMSC] section of the MMSC.INI file:

MSISDNHeader=header-name

The MSISDNHeader setting specifies the name of the HTTP header that will contain the MSISDN. For example, with NowWAP, the appropriate setting would be:

MSISDNHeader=X-MSISDN

MSISDNHeaderGateways=1.2.3.4,5.6.7.8,9.10.11.*

The MSISDNHeaderGateways setting specifies a list of one or more IP addresses from which the MMSC will accept the MSISDNHeader. This is to prevent forged requests, where another gateway or application inserts an MSISDN header to attempt to fool the MMSC. One or more IP addresses can be listed in this configuration setting. Each address must be separated by a comma. Wildcard addresses are supported by placing a “*” in place of a position within the IP address. For example, a setting of 9.10.11.* would mean that the MSISDNHeader would be accepted from any request originating from an IP address in the range of 9.10.11.1 thru 9.10.11.255.

It is important that clients not be allowed to generate their own values for these headers. The NowSMS MMSC will ignore MSISDNHeaders originating from an untrusted source. Similarly, NowWAP, when providing HTTP Header Enrichment, will discard any MSISDNHeaders inserted by a client. Without these considerations, it becomes easy to forge MMS requests.

MSISDNHeaderDefaultCountryCode=##

The MSISDNHeaderDefaultCountryCode setting specifies a default country code to be applied to MSISDN numbers presented in the MSISDNHeader, so that the MMSC can convert the MSISDN address to international format automatically.

MSISDNHeaderLocalPrefix=#

The MSISDNHeaderLocalPrefix setting specifies the default prefix that is used for phone numbers in the MSISDN header that are in local (national) format. For example, in the UK, the MSISDNHeaderDefaultCountryCode would be 44, and the MSISDNHeaderLocalPrefix would be 0. With these settings, and MSISDN header of “07778001210” would automatically be converted to “+447778001210” by the MMSC.

MSISDNHeaderAutoProvision=Yes/No

The MSISDNHeaderAutoProvision setting specifies whether or not user accounts should be automatically provisioned on the MMSC the first time that a user sends a message through the MMSC. This removes the requirement to automatically provision accounts. Any user that makes a request through the appropriate WAP gateway with the MSISDNHeader set will be automatically provisioned on the MMSC.

MSISDNHeaderSkipProvision=Yes/No

The MSISDNHeaderSkipProvision setting provides an alternative to MSISDNHeaderAutoProvision. It works the same as, MSISDNHeaderAutoProvision, except that the subscriber does not get added to the “MMSC Users” list of the MMSC. This is for multi-server MMSC configurations where it is not necessary or desirable to maintain an MMS subscriber database on each server.

MSISDNICAPServer=ip.addresss:port

This setting allows the MMSC to request HTTP header enrichment from an ICAP-based service, such as NowWAP. ip.address:port should point to the IP address and ICAP port number of the ICAP service. The MMSC will contact the ICAP server for HTTP header enrichment for any requests that are originate outside of any configured MSISDNHeaderGateways range. This allows proxied requests to receive HTTP Header Enrichment from the WAP gateway or proxy, while proxy-less requests receive HTTP Header Enrichment via ICAP.

Configuring the NowWAP Proxy to Forward MSISDN

When a mobile device connects to a mobile network for IP-based services, the mobile device is assigned an IP address when it connects to the GGSN (or network access server for legacy dial-up connections, collectively we’ll refer to them as this point on as an “access server”). This IP address is dynamically assigned and usually changes between sessions.

NowWAP needs to receive information from the “access server” in order to identify the MSISDN of a device associated with the IP address making a request.

The NowWAP proxy integrates with access servers using the Radius accounting protocol, which is one of the Radius (Remote Authentication Dial In User Service) protocols. The Radius authentication protocol is defined in internet RFC 2865, and the Radius accounting protocol is defined in internet RFC 2866. The two protocols are frequently used together.

The Radius authentication protocol is used to authenticate a user. When a new connection is received by an access server (including a GGSN), the access server can be configured to use Radius authentication to determine whether or not to accept the connection. The access server sends a Radius authentication request over UDP to a Radius server. This request includes the username presented and a hash of the password against a shared secret, and usually the CLI (caller line identification) of the station making the request. The Radius server responds back over UDP to the access server telling the access server whether or not to allow the connection, and in some configurations, the Radius server can also tell the access server what IP address to assign to the client.

After a connection has been authenticated, the access server can be configured to use the Radius accounting protocol to inform an accounting server of a new connection. Similarly, the access server notifies of a dropped connection. The Radius accounting protocol is also UDP-based, but it is an informational protocol. After a new connection is authenticated, the access server sends a Radius accounting packet over UDP to the configured accounting server(s). This packet includes a hash of a shared secret for packet validation, and typically includes the username that connected, the IP address that was assigned, and the CLI of the station that connected.

In an operator environment, users are typically not assigned their own username for the purposes of Radius authentication. Instead CLI is the determining factor.

To provide MSISDN support, NowWAP needs to be configured as a Radius accounting server, so that it receives Radius accounting packets from the access server. This support is activated in NowWAP on the MSISDN configuration dialog.

In the configuration dialog, you must specify a port (1813 is the default according to the specification, but some access servers default to 1646 which is an incorrect default from an older specification), and the appropriate shared secret.

This setting enables the NowWAP Proxy to receive Radius accounting packets from the access server.

Check “Forward MSISDN to Content Servers”, and add your local domain name as a content domain. NowWAP will then include the MSISDN in any requests to content servers within any listed domains. For example, if “operator.net” is listed as a supported content domain, then the MSISDN would be forwarded to a content server named “mms.operator.net”, or a content server simply named “operator.net”. NowWAP will forward the MSISDN to the content server in all HTTP requests sent to the content server, using the HTTP “X-MSISDN:” header.

As long as the Radius accounting feed from the access server is reliable, it may be desirable to require an MSISDN for any connections to NowWAP. This can be enabled by checking “Require MSISDN for all gateway connections”. Connections from IP addresses where NowWAP has not received an MSISDN assignment from the access server will be rejected.

Getting the Radius accounting feed setup in the access server correctly, so that it is sent to the WAP gateway is the hardest part of this process. NowWAP will log information about received RADIUS packets into RADIUS-yyyymmdd.LOG files in the NowWAP directory. If these log files do not exist, NowWAP is not receiving any RADIUS packets. When testing, it can be helpful to enable the debug log in NowWAP (edit WAPGW.INI, add Debug=Yes under [WAPGW] section header), and monitor the WAPDEBUG.LOG for a keyword of “Radius”, where it will log all Radius packets that the gateway receives. If you have problems getting the Radius configuration working, then it is best to contact NowWAP technical support for further advice.

NowWAP can also be configured to be a Radius authentication server, but it is a VERY simple Radius authentication server. When NowWAP is a Radius authentication server, it will accept any authentication request. We do not recommend the use of this setting, except for testing purposes. (This setting was added originally for a particular customer that needed it.)

Configuring NowWAP to Forward MSISDN over ICAP

Recent releases of the NowSMS MMSC and NowWAP allow the MMSC to request HTTP Header Enrichment (X-MSISDN: header) from NowWAP using the ICAP protocol.

on the “MSISDN” page of the NowWAP configuration, enable the ICAP Server Interface, and assign a unique port number for its use. Use the MSISDNICAPServer setting in MMSC.INI to configure the MMSC to connect to NowWAP on the ICAP server port.