Understanding WAP Wireless Applications, Devices, and Services phần 6 docx

Page 134

(not to be mixed up with the multipart sent between the push initiator and the push proxy gateway). If the content

indicated by a service indication, for example, a WML deck, is placed as the first entity in a multipart conveyed to the

mobile client and the service indication is placed as the second entity, then the WML deck will be cached before the

service indication is presented. So when the user chooses to load the indicated service, the content is readily available in

the cache, which will improve the user experience. But remember, given what was said in Section 6.4.6.2, a priori

knowledge of the client's capabilities is recommended if this approach should be used. If a thin client is addressed, it is

usually better to only send the service indication.

Service indication also provides some additional features to improve its usability. These include deletion and

replacement of previously submitted service indications, resolving race conditions, and the possibility to specify the level

of user-intrusiveness (controls when the service indication should be presented to the user if the client is busy when it is

received). It is also possible to specify when a service indication expires and thereby should be automatically deleted.

6.4.8 Service loading

Service loading [7] is also an XML-based content type, and just like service indication, is used to instruct the mobile

client to load content indicated by a URL into a clean user agent context. The difference is that no message can be

presented to the user, and the indicated service will be loaded without any user intervention at all. Hence, the user will

experience the indicated service as if it were pushed and executed or rendered directly. It is also possible to use the

content type to instruct the client to preemptively place the content indicated by the URL in the cache.

This is directly contrary to what was said in Section 6.4.6.2, and the content type should therefore be used very

carefully. The content type is first and foremost intended to be used in services that require some kind of user

interactivity where the user would find it odd if he or she had to confirm every push.

The push initiator management functions discussed in Section 6.4.4.2 included the possibility of controlling what

content types different push initiators should be allowed to include in a push submission. Since service loading is a

content type that can be misused, it is thus a splendid example of a content type of which it should be possible to restrict

the use.

Page 135

6.5 Security aspects

Security is an extensive topic, and in-depth knowledge is often required to understand its implications. As this chapter is

about push, this section is limited to introducing some basic security aspects to be considered when delivering content

using push. A detailed discussion of security issues in WAP can be found in Chapter 7. However, while the focus is on

push, much of the reasoning also applies to pull. Since the push framework defines delivery mechanisms to be used both

on the Internet and in the wireless domain, security considerations need to be addressed in both cases.

6.5.1 Internet security

A range of security protocols to be used on the Internet is already widely available, allowing push initiators and push

proxy gateways to communicate in a safe manner. The secure socket layer (SSL) is the most frequently used security

protocol on top of the transport control protocol/Internet protocol (TCP/IP), especially in conjunction with HTTP (often

referred to as HTTPS). It provides mechanisms for authenticating both servers and clients, encryption to ensure data

confidentiality, and message authentication codes to ensure data integrity. If transport protocols other than HTTP will be

accommodated by the push access protocol in the future, protocols like secure/multipurpose Internet mail extensions

(S/MIME) or Internet protocol secure (IPsec) may be other qualified candidates.

The features provided by protocols like SSL might in some cases be superfluous. For example, if the WAP gateway is

only connected to a corporate intranet, there might not be a need for a security protocol, or the means provided by HTTP

itself (for example, HTTP basic authentication, a simple user/password mechanism) might suffice.

6.5.2 WAP security

In WAP, the WTLS [8] protocol provides the same functions as listed for SSL. As a matter of fact, WTLS is derived

from the transport layer security (TLS) protocol, which in turn is based on SSL version 3.0. WTLS is optimized with

respect to the number and size of the messages sent over the air, and it can also run on top of an unreliable transport

protocol.

Page 136

6.5.3 End-to-end security

So then, are there no hindrances to establishing an adequate security relationship between a push initiator and a mobile

client? Well, that depends on the situation, and especially on which type of service is to be implemented. While, for

instance, SSL may be used on the Internet and WTLS in the wireless domain, to provide sufficient security in each

specific case, the push proxy gateway needs to be able to translate between these protocols and possibly also perform

various transformations on the content. In doing so, the security chain between the push initiator and the mobile client is

broken.

The lower part of Figure 6.6 attempts to illustrate that end-to-end security can only be accomplished when the mobile

client communicates with a WAP server. The WAP Forum has considerably improved end-to-end security in the WAP

1.2 specifications released in November 1999.

An end-to-end solution is most often the only viable one when services like banking and e-commerce are brought

about. However, transitive trust (also known as delegated trust or hop-by-hop security) is an acceptable solution for most

other services.

6.5.4 Transitive trust

Transitive trust can be established if the push proxy gateway, or rather the push proxy gateway operator, can be

considered trusted by the user

Figure 6.6 Security.