Proposal for WAP-IETF co-operation on a wireless friendly TLS

1. Proposal for WAP-IETF co-operation on a wireless friendly TLS Tim Wright, Vodafone and chair WAP Security Group timothy.wright@vf.vodafone.co.uk

2. 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?

3. 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

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

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

6. 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

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

8. Shorter parameters • Cipher suite negotiation • Algorithms

9. 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

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

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

12. 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

13. 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

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

15. 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;

16. 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

17. 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

18. 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

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

20. 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)

21. 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

22. 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

23. 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

24. 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?

25. 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

26. 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?

27. 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