wtls.xml

The Kannel Open Source WAP and SMS gateway works as both an SMS gateway, for implementing keyword b

				<listitem>
					<para>
						<emphasis role="bold">Datagram support.</emphasis> WTLS operates directly above WAP&apos;s Wireless Datagram  Protocol (WDP), and therefore needs to accommodate the unreliability and unpredictability of connectionless datagram communication. Rigorous confirmation and retransmission procedures are rendered doubly important by the intermittency and variable quality of radio transmission.</para>
				</listitem>
				<listitem>
					<para>
						<emphasis role="bold">Optimised handshakes.</emphasis> WTLS allows the WAP gateway, acting as a server to the mobile WAP client, to authenticate the client by obtaining the client&apos;s digital certificate from an external source, rather than the client itself. This reduces the processing and memory burden on the client.</para>
				</listitem>
				<listitem>
					<para>
						<emphasis role="bold">Dynamic key refreshing.</emphasis> Communication via radio signals is particularly vulnerable to &apos;tapping&apos; by third parties. As an extra security measure against eavesdropping, WTLS allows for the symmetric session key to be changed regularly over the course of the session, without the need for a clean handshake.</para>
				</listitem>
				<listitem>
					<para>
						<emphasis role="bold">Fast encryption and hashing algorithms.</emphasis> WTLS uses the quickest, most efficient algorithms available for hashing and encryption (see Section 2), so that client processing time and power consumption are kept within reasonable limits.</para>
				</listitem>
				<listitem>
					<para>
						<emphasis role="bold">Client-gateway rather than client-server coverage.</emphasis> Unlike SSL, WTLS does not span the whole of the communication channel from the client to the content provider&apos;s HTTP server, but only communication over the mobile telephone network between the client and the WAP gateway. If security is also required between the gateway and the HTTP server, it must be implemented using SSL.</para>
				</listitem>
			</itemizedlist>
			<para>The complete WTLS specification can be found on the WAP Forum&apos;s Web site at <ulink url="www.wapforum.org">www.wapforum.org</ulink>.
</para>
			<section>
				<title>3.1.1 WTLS Implementation Classes
</title>
				<para>The WTLS specification allows for three classes (levels) of WTLS implementation:
</para>
				<itemizedlist>
					<listitem>
						<para>
							<emphasis role="bold">Class 1: Anonymous encryption.</emphasis> Data is encrypted, but certificates are not exchanged between the client and the gateway.</para>
					</listitem>
					<listitem>
						<para>
							<emphasis role="bold">Class 2: Encryption with server authentication.</emphasis> Data is encrypted and the client requires a digital certificate from the server.</para>
					</listitem>
					<listitem>
						<para>
							<emphasis role="bold">Class 3: Encryption with client and server authentication.</emphasis> Data is encrypted and the client and the server exchange digital certificates.</para>
					</listitem>
				</itemizedlist>
			</section>
			<section>
				<title>3.1.2 WTLS Handshake
</title>
				<para>The WTLS handshake is very similar to the SSL handshake. The following example illustrates the most common form of the WTLS handshake, that for WTLS class 2 (see Section 3.1.1). This involves the client authenticating the gateway, but not vice versa. It is illustrated in Figure 9.
</para>
				<para>This example shows the <emphasis role="bold">full handshake</emphasis>. WTLS also uses an <emphasis role="bold">abbreviated handshake</emphasis> for resumption of a previously established session. This involves re-exchanging a session identification code agreed when the session was first established.
</para>
				<orderedlist inheritnum="ignore" continuation="restarts">
					<listitem>
						<para>Bollocks!</para>
					</listitem>
					<listitem>
						<para>Abigail, a WAP phone user user, sees an item she would like to buy on a WAP site.</para>
					</listitem>
					<listitem>
						<para>Abigail activates a link on her WAP phone that sends a request for a secure Internet session to the WAP gateway. The following information is appended to the request:</para>
						<para>- Various information about what versions of WTLS Abigail&apos;s WAP browser supports, what encryption algorithms it supports, and so on.</para>
						<para>- Some randomly generated data. This will be used, along with other data, to generate the session key (see steps 5 onward).</para>
					</listitem>
					<listitem>
						<para>The gateway receives Abigail&apos;s request for a secure session and sends her the following items:
</para>
						<para>- Its digital certificate, including its public key. The certificate is signed by a trusted CA using its private key.
</para>
						<para>- Information about what versions of WTLS, encryption algorithms and so on are supported by the WAP gateway.
</para>
						<para>- Some randomly generated data which will be used in the generation of the session key.
</para>
						<para>In WTLS class 3 (see Section 3.1.1) the gateway would also request Abigail&apos;s digital certificate at this point. Alternatively, it could obtain Abigail&apos;s certificate from an external source on the Internet - a procedure which characterises the <emphasis role="bold">optimised WTLS handshake</emphasis>.</para>
					</listitem>
					<listitem>
						<para>Abigail validates the gateway&apos;s certificate as outlined in Section 2.6.1. If the validation is successful, she is happy that the gateway&apos;s proprietor is genuine and trustworthy.
</para>
					</listitem>
					<listitem>
						<para>Abigail performs a series of operations on the random data she sent to the gateway, and the random data the gateway sent to her, to produce the premaster secret.
</para>
					</listitem>
					<listitem>
						<para>Abigail encrypts the premaster secret using the gateway&apos;s public key and sends it to the gateway. (In WTLS class 3, she would also send her digital certificate for the gateway to validate.)
</para>
					</listitem>
					<listitem>
						<para>The gateway receives the premaster secret from Abigail.
</para>
					</listitem>
					<listitem>
						<para>The gateway decrypts the premaster secret. The gateway and Abigail simultaneously perform a series of operations on it, to arrive at the master secret.</para>
					</listitem>
					<listitem>
						<para>Abigail and the gateway simultaneously perform a series of operations on the master secret to arrive at the session key (see Section 2.4.3), which will be used to encrypt the information they want to send to each other.
</para>
					</listitem>
					<listitem>
						<para>Abigail sends the gateway two messages. The first confirms that all further messages from her will be encrypted using the session key. The second is an encrypted message that formally ends the handshake from her side.
</para>
					</listitem>
					<listitem>
						<para>The gateway sends Abigail two messages. The first confirms that all further messages from it will be encrypted using the session key. The second is an encrypted message that formally ends the handshake from the gateway&apos;s side.
</para>
					</listitem>
				</orderedlist>
				<mediaobject>
					<imageobject>
						<imagedata fileref="fig5out&figtype;">
					</imageobject>
					<caption>
						<para>Figure 9: WTLS handshake
</para>
					</caption>
				</mediaobject>
			</section>
			<section>
				<title>3.1.3 Digital Certificate Formats
</title>
				<para>WTLS specifies two possible formats for digital certificates:</para>
				<itemizedlist>
					<listitem>
						<para>
							<emphasis role="bold">X.509.</emphasis> This is the standard format for digital certificates in SSL, and is optional in implementations of WTLS. However, it is not supported by the current generation of WAP client devices.
</para>
						<para>The principal information contained in an X.509 certificate is:
<itemizedlist>
								<listitem>
									<para>The subject&apos;s name</para>
								</listitem>
								<listitem>
									<para>The issuing CA&apos;s name</para>
								</listitem>
								<listitem>
									<para>The certificate&apos;s validity period
</para>
								</listitem>
								<listitem>
									<para>The asymmetric and symmetric algorithms used for key exchange
</para>
								</listitem>
								<listitem>
									<para>The subject&apos;s public key
</para>
								</listitem>
								<listitem>
									<para>The digital signature of the issuing CA
</para>
								</listitem>
								<listitem>
									<para>Alternative names for the subject (optional)
</para>
								</listitem>
								<listitem>
									<para>Allowed key usage - for example, whether the subject&apos;s public key may be used for encryption, server authentication, signing other certificates, and so on (optional) 
</para>
								</listitem>
							</itemizedlist>
						</para>
					</listitem>
					<listitem>
						<para>
							<emphasis role="bold">WTLS.</emphasis> WTLS certificates are similar to X.509 certificates but more compactly coded, so as to suit the high latencies and low bandwidth of wireless networks, and the limited processing reources of WAP client devices. WTLS certificates also omit some of X.509&apos;s non-essential fields, such as alternative subject names and key usage options.
</para>
						<para>A WTLS certificate includes the following information:</para>
						<itemizedlist>
							<listitem>
								<para>The subject&apos;s name
</para>
							</listitem>
							<listitem>
								<para>The issuing CA&apos;s name
</para>
							</listitem>
							<listitem>
								<para>The certificate&apos;s validity period
</para>
							</listitem>
							<listitem>
								<para>The asymmetric and symmetric algorithms used for key exchange
</para>
							</listitem>
							<listitem>
								<para>The subject&apos;s public key
</para>
							</listitem>
							<listitem>
								<para>The digital signature of the issuing CA</para>
							</listitem>
						</itemizedlist>
					</listitem>
				</itemizedlist>
			</section>
			<section>
				<title>3.1.4 Certificate Revocation in WTLS
</title>
				<para>On the terrestrial Internet, a CA can revoke a certificate it has issued before the end of the certificate&apos;s validity period, if the security of the owner&apos;s private key has been compromised or if there is new reason to doubt the owner&apos;s identity or integrity.

</para>
				<para>Certificate revocation on the terrestrial Internet is implemented by means of <emphasis role="bold">certificate revocation lists</emphasis> issued by CAs. When an Internet client receives a certificate from a secure server, it retrieves the signing CA&apos;s certificate revocation list from the Internet, checks that the certificate does not appear it, and if not, accepts the certificate.
</para>
				<para>On the Mobile Internet, it is impracticable for a small client device to check a revocation list every time it downloads a gateway&apos;s certificate. The problem of revocation is therefore addressed by the use of <emphasis role="bold">short-lived certificates</emphasis>. The CA, instead of issuing the secure WAP gateway with a single certificate valid for a long period, sends it a fresh certificate at short intervals throughout that period - for example every 25 hours. Each certificate is only valid until the next one arrives. If the CA needs to revoke its endorsement of a gateway (for example, because the security of the gateway&apos;s private key has been compromised), it simply stops sending the gateway certificates. Clients of the gateway will begin receiving expired certificates, and therefore will know that its security can no longer be relied on.
</para>
			</section>
		</section>
		<section>
			<title>3.2 WTLS in Alligata Secure
</title>
				<para>NOTE: THIS SECTION WILL NEED UPDATING.
				</para>
			<section>
				<title>3.2.1 Supported WTLS Implementation Classes