Course wireless transport layer security specification

Facebook Tweet Pin Email

1     SCOPE
2     DOCUMENT STATUS
2.1      COPYRIGHT NOTICE
2.2      ERRATA
2.3      COMMENTS
3     REFERENCES
3.1       NORMATIVE REFERENCES
3.2      INFORMATIVE REFERENCES
3.3      ACKNOWLEDGEMENTS
4     DEFINITIONS AND ABBREVIATIONS
4.1      DEFINITIONS
4.2      ABBREVIATIONS
4.3      DOCUMENT CONVENTIONS
5     WTLS ARCHITECTURAL OVERVIEW
5.1      REFERENCE MODEL
6     WTLS ELEMENTS FOR LAYER-TO-LAYER COMMUNICATION
6.1      NOTATIONS USED
6.1.1       Definition of Service Primitives and Parameters
6.1.2       Time Sequence Charts
6.1.3       Primitive Types
6.1.4       Service Parameter Tables
6.2      WTLS TRANSPORT SERVICE
6.2.1       Service Primitives
6.3      WTLS CONNECTION MANAGEMENT
6.3.1       Overview
6.3.2       Service Primitives
6.3.3       Constraints on Using the Service Primitives
7     WTLS STATE TABLES
7.1      CLIENT STATE TABLES
7.2      SERVER STATE TABLES
8     PRESENTATION LANGUAGE
8.1      BASIC BLOCK SIZE
8.1.1       Bit Order
8.2      MISCELLANEOUS
8.3      VECTORS
8.4      NUMBERS
8.5      ENUMERATEDS
8.6      CONSTRUCTED TYPES
8.6.1       Variants
8.7      CRYPTOGRAPHIC ATTRIBUTES
8.8      CONSTANTS
8.9      STRING CONSTANTS
9     RECORD PROTOCOL SPECIFICATION
9.1      CONNECTION STATE
9.2      RECORD LAYER
9.2.1       Fragmentation
9.2.2       Record Compression and Decompression
9.2.3       Record Payload Protection
10       HANDSHAKE PROTOCOL SPECIFICATION
10.1    CHANGE CIPHER SPEC PROTOCOL
10.2    ALERT PROTOCOL
10.2.1     Closure Alerts
10.2.2     Error Alerts
10.3    HANDSHAKE PROTOCOL OVERVIEW
10.4    HANDSHAKE RELIABILITY OVER DATAGRAMS
10.5    HANDSHAKE PROTOCOL
10.5.1     Hello Messages
10.5.2     Server Certificate
10.5.3     Server Key Exchange Message
10.5.4     Certificate Request
10.5.5     Server Hello Done
10.5.6     Client Certificate
10.5.7     Client Key Exchange Message
10.5.8     Certificate Verify
10.5.9     Finished
11       CRYPTOGRAPHIC COMPUTATIONS
11.1    COMPUTING THE MASTER SECRET
11.1.1     RSA Encryption Scheme
11.1.2     Diffie-Hellman
11.1.3     EC Diffie-Hellman
11.1.4     Session resume
11.2    KEY CALCULATION
11.3    HMAC AND THE PSEUDORANDOM FUNCTION
11.3.1     MAC Calculation
11.3.2     Pseudo-random Function
APPENDIX A ALGORITHM DEFINITIONS
APPENDIX B IMPLEMENTATION NOTES
B.1     NEGOTIATING NULL CIPHER SPEC
B.2     ANONYMOUS HANDSHAKES
B.3     KEY REFRESH
B.4     DENIAL-OF-SERVICE ATTACKS
APPENDIX C IMPLEMENTATION CLASSES
APPENDIX D REQUIREMENTS FOR THE WTLS PROTOCOL
APPENDIX E STATIC CONFORMANCE REQUIREMENT
E.1     WTLS SERVER OPTIONS
E.2     WTLS CLIENT OPTIONS

Scope

The Wireless Application Protocol (WAP) is a result of continuous work to define an industry-wide specification for developing applications that operate over wireless communication networks. The scope for the WAP Forum is to define a set of specifications to be used by service applications. The wireless market is growing very quickly, and reaching new customers and services. To enable operators and manufacturers to meet the challenges in advanced services, differentiation and fast/flexible service creation WAP Forum defines a set of protocols in transport, security, transaction, session and application layers. For additional information on the WAP architecture, please refer to “Wireless Application
Protocol Architecture Specification” [WAPARCH].

Document Status

This document is available online in the following formats:
•PDF format at http://www.wapforum.org/.

Errata
Known problems associated with this document are published at http://www.wapforum.org/.

Comments
Comments regarding this document can be submitted to WAP Forum in the manner published at
http://www.wapforum.org/.

References

Normative References
[WAPARCH] “WAP Architecture Specification, WAP Forum, 30-April-1998.
URL: http://www.wapforum.org/
[WAPWDP] “Wireless Datagram Protocol Specification”, WAP Forum, 30-April-1998.
URL: http://www.wapforum.org/
[WAPWTP] “Wireless Transaction Protocol Specification”, WAP Forum, 30-April-1998.
URL: http://www.wapforum.org/
[RFC2119] “Key words for use in RFCs to Indicate Requirement Levels”, Bradner, S., March 1997.
URL: ftp://ftp.isi.edu/in-notes/rfc2119.txt
[TLS] “The TLS Protocol”, Dierks, T. and Allen, C., January 1999.
URL: ftp://ftp.isi.edu/in-notes/rfc2246.txt
[RFC2068] “Hypertext Transfer Protocol — HTTP/1.1”, Fielding, R., et. al., January 1997.
URL: ftp://ftp.isi.edu/in-notes/rfc2068.txt

Informative References
[WAPWSP] “Wireless Session Protocol Specification”, WAP Forum, 30-April-1998.
URL: http://www.wapforum.org/
[GSM03.40] “European Digital Cellular Telecommunication System (phase 2+): Technical realization of Short
Message Service (SMS) Point-to-Point (P)”, ETSI.
[XDR] “XDR: External Data Representation Standard”, Srinivansan, R., RFC-1832:, August 1995. URL:
ftp://ftp.isi.edu/in-notes/rfc1832.txt
[ISO7498] “Information technology – Open Systems Interconnection – Basic Reference Model: The Basic
Model”, ISO/IEC 7498-1:1994.
[ISO10731] “Information Technology – Open Systems Interconnection – Basic Reference Model – Conventions
for the Definition of OSI Services”, ISO/IEC 10731:1994.
[X9.42] “Public Key Cryptography for the Financial Services Industry: Agreement of Symmetric Keys Using
Discrete Logarithm Cryptography”, ANSI X9.42 Working Draft, April 1999.
[X9.63] “Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport
Using Elliptic Curve Cryptography”, ANSI X9.63 Working Draft, October 1998.
[Zuc99] “Methods for Avoiding the ‘Small-Subgroup’ Attacks on the Diffie-Hellman Key Agreement Method
for S/MIME,” IETF Work in progress, March 1999.
[BLEI] « Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS #1 »,
Bleichenbacher D., in Advances in Cryptology — CRYPTO’98, LNCS vol. 1462, pages: 1–12, 1998.

Acknowledgements
WTLS is derived from [TLS]. TLS is based on the SSL 3.0 specification.

Definitions and Abbreviations

Definitions
For the purposes of this specification the following definitions apply.
Abbreviated Handshake
A creation of a new connection state based on an existing secure session. See also Session Resume.
Connection State
The operating environment of the record protocol. The connection state includes all parameters that are needed for the cryptographic operations (encryption/decryption and MAC calculation/verification). Each secure connection has a connection state
Datagram Transport
A transport service that does not guarantee that the sent transport SDUs are not lost, duplicated or delivered out of order.
Handshake
The procedure of agreeing on the protocol options to be used between a client and a server. It includes the negotiation of security parameters (eg, algorithms and key lengths), key exchange and authentication. Handshaking occurs in the beginning of each secure connection.

Abbreviations
For the purposes of this specification the following abbreviations apply.
API Application Programming Interface
CA Certification Authority
CBC Cipher Block Chaining
DH Diffie-Hellman
EC Elliptic Curve
ECC Elliptic Curve Cryptography
ECDH Elliptic Curve Diffie-Hellman
ECDSA Elliptic Curve Digital Signature Algorithm
IV Initialisation Vector
MAC Message Authentication Code
ME Management Entity
OSI Open System Interconnection
PDU Protocol Data Unit
PRF Pseudo-Random Function
SAP Service Access Point
SDU Service Data Unit
SHA-1 Secure Hash Algorithm
SMS Short Message Service
SSL Secure Sockets Layer
TLS Transport Layer Security
WAP Wireless Application Protocol
WDP Wireless Datagram Protocol
WSP Wireless Session Protocol
WTLS Wireless Transport Layer Security
WTP Wireless Transaction Protocol

Document Conventions
This specification uses the same keywords as specified in RFC 2119 [RFC2119] for defining the significance of each particular requirement. These words are:
MUST
This word, or the terms « REQUIRED » or « SHALL », mean that the definition is an absolute requirement of the specification.
MUST NOT
This phrase, or the phrase « SHALL NOT », mean that the definition is an absolute prohibition of the specification.
SHOULD
This word, or the adjective “RECOMMENDED”, means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
SHOULD NOT
This phrase, or the phrase « NOT RECOMMENDED » mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

WTLS Architectural Overview

Reference model
A model of layering the protocols in WAP is illustrated in Figure 1. The layering of WAP protocols and their functions is similar to that of the ISO OSI Reference Model [ISO7498] for upper layers. Layer Management Entities handle protocol initialisation, configuration, and error conditions (such as loss of connectivity due to the mobile terminal roaming out of coverage) that are not handled by the protocol itself.
WTLS is designed to function on connection-oriented and/or datagram transport protocols. Security is assumed to be an optional layer above the transport layer. The security layer preserves the transport service interfaces. The session or application management entities are assumed to provide additional support required to manage (eg, initiate and terminate) secure connections.

……