Presentation on theme: "Proposal for WAP-IETF co- operation on a wireless friendly TLS Tim Wright, Vodafone and chair WAP Security Group"— Presentation transcript:
Proposal for WAP-IETF co- operation on a wireless friendly TLS Tim Wright, Vodafone and chair WAP Security Group firstname.lastname@example.org
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
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 - 450 bytes compared to around 750 for X.509
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
Your consent to our cookies if you continue to use this website.