TCP/IP Tutorial and Technical Overview - IBM Redbooks

18.6.7 Security
In a trusted environment, several questions can arise, for example:
► How can the push initiator be authenticated?
► What role does PPG play in a security and trusted model?
► What are the access control policies for a push initiator and pushed content?
► How can a client authenticate something if it has no certificates?
Authenticating a push initiator
Some of the following solutions can be used to implement a security environment
between a push initiator and the PPG:
► Use of session level certificates (TSL and SSL)
If the push content traverses the Internet between the push initiator and PPG,
TSL or SSL can be used.
► Use of object-level certificates
Certificates can be used to sign and encrypt the pushed content on an
end-to-end basis. This strengthens the level of confidence in the content
authenticity at the client’s end.
► HTTP authentication
The basic authentication through user ID and password is available. In
addition, HTTP authentication, for example, based on digests, can be
implemented.
► Combination of technologies
Another approach is combining technologies by using a TLS/SSL session
with a PPG, while HTTP authentication can be used to authenticate the push
initiator. Signed and encrypted content can then be sent over this
authenticated session.
Client authentication
If a client and a PPG are able to create a trusted environment, the PPG can
authenticate a push initiator on behalf of that client, that is, trust can be transitive.
A trust situation can be established between client and PPG by maintaining a list
of trusted PPGs in a client system. Push initiators own a certificate or public key
for end-to-end authentication of the origin server.
Chapter 18. Wireless Application Protocol 669