Proposal for WAP-IETF co- operation on a wireless friendly TLS Tim Wright, Vodafone and chair WAP Security Group

Contents Introduction to WAP, WTLS and other WAP security functions Differences between WTLS and TLS WAP-NG WSG part in WAP-NG A wireless friendly TLS?

WAP Formed by Ericsson, Motorola, Nokia, phone.com Opened up (“Opened up?”) in Spring 1998 Wireless friendly versions of html, http, TCP/IP for delivery of “Internet content and services” to wireless clients

Stack WSP (carrying WML and WMLScript) WTP WTLS WDP Bearer

WTLS Wireless friendly version of TLS Several differences designed to: –optimise bandwidth use –accommodate unreliable link –reduce client code size and processor requirements

Other WAP security features WAP Identity Module (WIM) –specification of interface to tamper-resistant device for storage of crypto parameters signText –WMLScript function for signature generation Profile of X.509 for client certs –based on RFC 2459 WPKI –client and server cert request, root download

Major differences between WTLS and TLS Datagram support No fragmentation Key refresh for long-lived connections Optimized handshaking Shared-secret handshake Compact certificate (WTLSCertificate)

Shorter parameters Cipher suite negotiation Algorithms

Datagram Support Mandatory use of explicit sequence numbers Concatenation of successive handshake messages in one direction into one transport SDU Extra conditions for handshake to deal with lost messages

No fragmentation Assumed not needed as optimisations will mean application data is less than 16K Reduces WTLS code size

Key Refresh for long lived connections ClientHello and ServerHello include setting of key refresh rate Recalculation of key_block every n records, n=2 k, k is uint 8 Allows key refresh without handshake

Optimised handshaking Server can retrieve client cert from own sources after Client Hello, if client sends public key id (hash) or cert URL, and do abbreviated handshake Client indicates the roots it has in ClientHello (trusted_key_ids), so that server can send appropriate certs

Shared Secret Handshake Pre-master secret is a shared secret previously loaded into client and server Handshake is as for (W)TLS abbreviated handshake (Hello’s, ChangeCipherSpec’s and Finished’s only) Allows implicit authentication and confidentiality/integrity, with risk of extraction of secret from terminal

Compact certificate “WTLSCert” defined in specification Designed for authentication of WAP gateway only No extensions length bytes compared to around 750 for X.509

Format struct { uint8 certificate_version; SignatureAlgorithm signature_algorithm; Identifier issuer; uint32 valid_not_before; uint32 valid_not_after; Identifier subject; PublicKeyType public_key_type; ParameterSpecifier parameter_specifier; PublicKey public_key; } ToBeSignedCertificate;

Shorter parameters Truncated (40 and 80 bit versions) of SHA- 1 and MD5 allowed Pre-master secret is only 20 bytes, not 48 Client and Server Random’s only 16 bytes, not 32 Session ID is 8 bytes, not 32

Cipher suite negotiation Key exchange/authentication algorithm negotiated separately from cipher and MAC Allows negotiation of strong authentication with weak encryption where legislation requires Allow theoretical possibility of NULL key exchange with strong ciphering and MAC

Algorithms - anonymous handshake RSA_ANON, with 512 and 768 bit limited versions DH_ANON, with 512 and 768 bit limited versions ECDH_ANON, with 113 and 131 bit limited versions

Algorithms - server/client authentication RSA, with 512 and 768 bit limited versions No temporary keys ECDH_ECDSA –4 basic curves, 4 non-basic

Algorithms - MAC SHA-1, MD5 and 40/80 bit truncations allowed Only one used “XOR MAC” - divide the message into 5 bit blocks and XOR together –designed for low end devices –warnings in specification against use –attack publicised (Saarinen, Wagner)

Algorithms - encryption RC5-32/16/16 is recommended for client and server –56 and 40 bit versions, use shorter key, pad to 128 bit and use RC5-32/16/16 Others –DES, 3DES, IDEA –None of these in production handsets

Attacks XOR MAC Possibility of negotiating NULL key exchange gives middleperson attack Possibility of low entropy IV allows intruder possibility of guessing key if can control channel Redirection attacks as for TLS

WAP Next Generation (NG) WAP NG is the great leap back to Internet compliant specs http, html, TLS, TCP/IP to the handset But wireless friendly versions of these protocols –initially with PEP’s WSG task is TLS to the handset

WSG plans re TLS Wireless profile of TLS 1.0, including: –Profile of client and server X.509 –Specified ciphersuites –Guidelines on TLS options Specification of use of WIM for TLS Development within WSG and IETF of wireless-friendly TLS 1.1?

Changes required? Possibilities (early thoughts, and TBD): –Algorithms - ECC & RC5? –Client certificate URL –Client to indicate trusted roots in Hello –NOT necessarily datagram support and WTLS certs

Timescales WAP NG specs to be ready summer 2001 (though WG’s have some flexibility) TLS standardisation timescales? –waiting on RFC 2459 progress –time for some minor changes for wireless to TLS 1.0?

Next Steps WSG to determine changes necessary/”nice to have” for wireless friendly TLS TLS to determine what can be squeezed into TLS 1.0 and what needs new version Make changes to TLS 1.0 Begin work on TLS 1.1 as required