diff options
Diffstat (limited to 'doc/protocol/draft-rescorla-dtls-04.txt')
| -rw-r--r-- | doc/protocol/draft-rescorla-dtls-04.txt | 1338 |
1 files changed, 0 insertions, 1338 deletions
diff --git a/doc/protocol/draft-rescorla-dtls-04.txt b/doc/protocol/draft-rescorla-dtls-04.txt deleted file mode 100644 index 5d7ee14b6f..0000000000 --- a/doc/protocol/draft-rescorla-dtls-04.txt +++ /dev/null @@ -1,1338 +0,0 @@ - E. Rescorla - RTFM, Inc. - N. Modadugu -INTERNET-DRAFT Stanford University -<draft-rescorla-dtls-04.txt> April 2004 (Expires October 2005) - - Datagram Transport Layer Security - -Status of this Memo - -By submitting this Internet-Draft, each author represents that any -applicable patent or other IPR claims of which he or she is aware -have been or will be disclosed, and any of which he or she becomes -aware will be disclosed, in accordance with Section 6 of BCP 79. - -Internet-Drafts are working documents of the Internet Engineering -Task Force (IETF), its areas, and its working groups. Note that -other groups may also distribute working documents as -Internet-Drafts. - -Internet-Drafts are draft documents valid for a maximum of six months -and may be updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet-Drafts as reference -material or to cite them other than as "work in progress." - -The list of current Internet-Drafts can be accessed at -http://www.ietf.org/1id-abstracts.html - -The list of Internet-Draft Shadow Directories can be accessed at -http://www.ietf.org/shadow.html - -Copyright Notice - - Copyright (C) The Internet Society (1999-2004). All Rights Reserved. - - - - - - -Rescorla, Modadugu [Page 1] - - -Abstract - - This document specifies Version 1.0 of the Datagram Transport - Layer Security (DTLS) protocol. The DTLS protocol provides - communications privacy for datagram protocols. The protocol - allows client/server applications to communicate in a way that - is designed to prevent eavesdropping, tampering, or message - forgery. The DTLS protocol is based on the TLS protocol and - provides equivalent security guarantees. Datagram semantics of - the underlying transport are preserved by the DTLS protocol. - - -Contents - - 1 Introduction 3 - 1.1 Requirements Terminology 3 - 2 Usage Model 4 - 3 Overview of DTLS 4 - 3.1 Loss-insensitive messaging 4 - 3.2 Providing Reliability for Handshake 5 - 3.2.1 Packet Loss 5 - 3.2.2 Reordering 6 - 3.2.3 Message Size 6 - 3.3 Replay Detection 6 - 4 Differences from TLS 6 - 4.1 Record Layer 7 - 4.1.1 Transport Layer Mapping 8 - 4.1.1.1 PMTU Discovery 8 - 4.1.2 Record payload protection 9 - 4.1.2.1 MAC 9 - 4.1.2.2 Null or standard stream cipher 9 - 4.1.2.3 Block Cipher 10 - 4.1.2.4 New Cipher Suites 10 - 4.1.2.5 Anti-Replay 10 - 4.2 The DTLS Handshake Protocol 11 - 4.2.1 Denial of Service Countermeasures 11 - 4.2.2 Handshake Message Format 13 - 4.2.3 Message Fragmentation and Reassembly 15 - 4.2.4 Timeout and Retransmission 16 - 4.2.4.1 Timer Values 19 - 4.2.5 ChangeCipherSpec 20 - 4.2.6 Finished messages 20 - 4.2.7 Alert Messages 20 - 4.2 Record Layer 20 - 4.3 Handshake Protocol 21 - 5 Security Considerations 22 - 6 IANA Considerations 22 - - - - -Rescorla, Modadugu [Page 2] - - -1. Introduction - - TLS [TLS] is the most widely deployed protocol for securing - network traffic. It is widely used for protecting Web traffic - and for e-mail protocols such as IMAP [IMAP] and POP [POP]. - The primary advantage of TLS is that it provides a transparent - connection-oriented channel. Thus, it is easy to secure an - application protocol by inserting TLS between the application - layer and the transport layer. However, TLS must run over a - reliable transport channel--typically TCP [TCP]. It therefore - cannot be used to secure unreliable datagram traffic. - - However, over the past few years an increasing number of - application layer protocols have been designed which UDP - transport. In particular such protocols as the Session - Initiation Protocol (SIP) [SIP], and electronic gaming - protocols are increasingly popular. (Note that SIP can run - over both TCP and UDP, but that there are situations in which - UDP is preferable). Currently, designers of these applications - are faced with a number of unsatisfactory choices. First, they - can use IPsec [RFC2401]. However, for a number of reasons - detailed in [WHYIPSEC], this is only suitable for some - applications. Second, they can design a custom application - layer security protocol. SIP, for instance, uses a subsert of - S/MIME to secure its traffic. Unfortunately, while application - layer security protocols generally provide superior security - properties (e.g., end-to-end security in the case of S/MIME) - it typically require a large amount of effort to design--by - contrast to the relatively small amount of effort required to - run the protocol over TLS. - - In many cases, the most desirable way to secure client/server - applications would be to use TLS; however the requirement for - datagram semantics automatically prohibits use of TLS. Thus, a - datagram-compatible variant of TLS would be very desirable. - This memo describes such a protocol: Datagram Transport Layer - Security (DTLS). DTLS is deliberately designed to be as - similar to to TLS as possible, both to minimize new security - invention and to maximize the amount of code and - infrastructure reuse. - - -1.1. Requirements Terminology - - Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD - NOT" and "MAY" that appear in this document are to be - interpreted as described in RFC 2119 [REQ]. - - - - -Rescorla, Modadugu [Page 3] - - -2. Usage Model - - The DTLS protocol is designed to secure data between - communicating applications. It is designed to run in - application space, without requiring any kernel modifications. - - Datagram transport does not require or provide reliable or in- - order delivery of data. The DTLS protocol preserves this - property for payload data. Applications such as media - streaming, Internet telephony and online gaming use datagram - transport for communication due to the delay-sensitive nature - of transported data. The behavior of such applications is - unchanged when the DTLS protocol is used to secure - communication, since the DTLS protocol does not compensate for - lost or re-ordered data traffic. - -3. Overview of DTLS - - The basic design philosophy of DTLS is to construct "TLS over - datagram". The reason that TLS cannot be used directly in - datagram environments is simply that packets may be lost or - reordered. TLS has no internal facilities to handle this kind - of unreliability and therefore TLS implementations break when - rehosted on datagram transport. The purpose of DTLS is to make - only the minimal changes to TLS required to fix this problem. - To the greatest extent possible, DTLS is identical to TLS. - Whenever we need to invent new mechanisms, we attempt to do so - in such a way that it preserves the style of TLS. - - Unreliability creates problems for TLS at two levels: - - 1. TLS's traffic encryption layer does not allow - independent decryption of individual records. If record N - is not received, then record N+1 cannot be decrypted. - - 2. The TLS handshake layer assumes that handshake messages - are delivered reliably and breaks if those messages are - lost. - - The rest of this section describes the approach that DTLS uses - to solve these problems. - -3.1. Loss-insensitive messaging - - In TLS's traffic encryption layer (called the TLS Record - Layer), records are not independent. There are two kinds of - inter-record dependency: - - - - -Rescorla, Modadugu [Page 4] - - - 1. Cryptographic context (CBC state, stream cipher key - stream) is chained between records. - - 2. Anti-replay and message reordering protection are - provided by a MAC which includes a sequence number, but the - sequence numbers are implicit in the records. - - The fix for both of these problems is straightforward and - well-known from IPsec ESP [ESP]: add explicit state to the - records. TLS 1.1 [TLS11] is already adding explicit CBC state - to TLS records. DTLS borrows that mechanism and adds explicit - sequence numbers. - -3.2. Providing Reliability for Handshake - - The TLS handshake is a lockstep cryptographic handshake. - Messages must be transmitted and received in a defined order - and any other order is an error. Clearly, this is incompatible - with reordering and message loss. In addition, TLS handshake - messages are potentially larger than any given datagram, thus - creating the problem of fragmentation. DTLS must provide fixes - for both these problems. - -3.2.1. Packet Loss - - DTLS uses a simple retransmission timer to handle packet loss. - The following figure demonstrates the basic concept using the - first phase of the DTLS handshake: - - Client Server - ------ ------ - ClientHello ------> - - X<-- HelloVerifyRequest - (lost) - - [Timer Expires] - - ClientHello ------> - (retransmit) - - Once the client has transmitted the ClientHello message, it - expects to see a HelloVerifyRequest from the server. However, - if the server's message is lost the client knows that either - the ClientHello or the HelloVerifyRequest has been lost and - retransmits. When the server receives the retransmission, it - knows to retransmit. The server also maintains a - retransmission timer and retransmits when that timer expires. - - - -Rescorla, Modadugu [Page 5] - - - Note: timeout and retransmission do not apply to the - HelloVerifyRequest, because this requires creating state on - the server. - -3.2.2. Reordering - - In DTLS, each handshake message is assigned a specific - sequence number within that handshake. When a peer receives a - handshake message, it can quickly determine whether that - message is the next message it expects. If it is, then it - processes it. If not, it queues it up for future handling once - all previous messages have been received. - -3.2.3. Message Size - - TLS and DTLS handshake messages can be quite large (in theory - up to 2^24-1 bytes, in practice many kilobytes). By contrast, - UDP datagrams are often limited to <1500 bytes if - fragmentation is not desired. In order to compensate for this - limitation, each DTLS handshake message may be fragmented over - several DTLS records. Each DTLS handshake message contains - both a fragment offset and a fragment length. Thus, a - recipient in possession of all bytes of a handshake message - can reassemble the original unfragmented message. - -3.3. Replay Detection - - DTLS optionally supports record replay detection. The - technique used is the same as in IPsec AH/ESP, by maintaining - a bitmap window of received records. Records that are too old - to fit in the window and records that have been previously - received are silently discarded. The replay detection feature - is optional, since packet duplication is not always malicious, - but can also occur due to routing errors. Applications may - conceivably detect duplicate packets and accordingly modify - their data transmission strategy. - -4. Differences from TLS - - As mentioned in Section 3., DTLS is intentionally very similar - to TLS. Therefore, instead of presenting DTLS as a new - protocol, we instead present it as a series of deltas from TLS - 1.1 [TLS11]. Where we do not explicitly call out differences, - DTLS is the same as TLS. - - - - - - - -Rescorla, Modadugu [Page 6] - - -4.1. Record Layer - - The DTLS record layer is extremely similar to that of TLS 1.1. - The only change is the inclusion of an explicit sequence - number in the record. This sequence number allows the - recipient to correctly verify the TLS MAC. The DTLS record - format is shown below: - - struct { - ContentType type; - ProtocolVersion version; - uint16 epoch; // New field - uint48 sequence_number; // New field - uint16 length; - opaque fragment[DTLSPlaintext.length]; - } DTLSPlaintext; - - type - Equivalent to the type field in a TLS 1.1 record. - - version - The version of the protocol being employed. This document - describes DTLS Version 1.0, which uses the version { 254, 255 - }. The version value of 254.255 is the 1's complement of DTLS - Version 1.0. This maximal spacing between TLS and DTLS version - numbers ensures that records from the two protocols can be - easily distinguished. - - epoch - A counter value that is incremented on every cipher state - change. - - sequence_number - The sequence number for this record. - - length - Identical to the length field in a TLS 1.1 record. As in TLS - 1.1, the length should not exceed 2^14. - - fragment - Identical to the fragment field of a TLS 1.1 record. - - DTLS uses an explicit rather than implicit sequence number, - carried in the sequence_number field of the record. As with - TLS, the sequence number is set to zero after each - ChangeCipherSpec message is sent. - - - - - -Rescorla, Modadugu [Page 7] - - - If several handshakes are performed in close succession, there - might be multiple records on the wire with the same sequence - number but from different cipher states. The epoch field - allows recipients to distinguish such packets. The epoch - number is initially zero and is incremented each time the - ChangeCipherSpec messages is sent. In order to ensure that any - given sequence/epoch pair is unique, implementations MUST NOT - allow the same epoch value to be reused within two times the - TCP maximum segment lifetime. In practice, TLS implementations - rehandshake rarely and we therefore do not expect this to be a - problem. - -4.1.1. Transport Layer Mapping - - Each DTLS record MUST fit within a single datagram. In order - to avoid IP fragmentation [MOGUL], DTLS implementations SHOULD - determine the MTU and send records smaller than the MTU. DTLS - implementations SHOULD provide a way for applications to - determine the value of the PMTU (or alternately the maximum - application datagram size, which is the PMTU minus the DTLS - per-record overhead). If the application attempts to send a - record larger than the MTU the DTLS implementation SHOULD - generate an error, thus avoiding sending a packet which will - be fragmented. - - Note that unlike IPsec, DTLS records do not contain any - association identifiers. Applications must arrange to - multiplex between associations. With UDP, this is presumably - done with host/port number. - - Multiple DTLS records may be placed in a single datagram. hey - are simply encoded consecutively. The DTLS record framing is - sufficient to determine the boundaries. Note, however, that - the first byte of the datagram payload must be the beginning - of a record. Records may not span datagrams. - -4.1.1.1. PMTU Discovery - - In general, DTLS's philosophy is to avoid dealing with PMTU - issues. The general strategy is to start with a conservative - MTU and then update it if events require it, but not actively - probe for MTU values. PMTU discovery is left to the - application. - - The PMTU SHOULD be initialized from the interface MTU that - will be used to send packets. If the DTLS implementation - receives an RFC 1191 [RFC1191] ICMP Destination Unreachable - message with the "fragmentation needed and DF set" Code - - - -Rescorla, Modadugu [Page 8] - - - (otherwise known as Datagram Too Big) it should decrease its - PMTU estimate to that given in the ICMP message. A DTLS - implementation SHOULD allow the application to occasionally - reset its PMTU estimate. The DTLS implementation SHOULD also - allow applications to control the status of the DF bit. These - controls allow the application to perform PMTU discovery. - - One special case is the DTLS handshake system. Handshake - messages should be set with DF set. Because some firewalls and - routers screen out ICMP messages, it is difficult for the - handshake layer to distinguish packet loss from an overlarge - PMTU estimate. In order to allow connections under these - circumstances, DTLS implementations SHOULD back off handshake - packet size during the retransmit backoff described in Section - 4.2.4.. For instance, if a large packet is being sent, after 3 - retransmits the handshake layer might choose to fragment the - handshake message on retransmission. In general, choice of a - conservative initial MTU will avoid this problem. - -4.1.2. Record payload protection - - Like TLS, DTLS transmits data as a series of protected - records. The rest of this section describes the details of - that format. - -4.1.2.1. MAC - - The DTLS MAC is the same as that of TLS 1.1. However, rather - than using TLS's implicit sequence number, the sequence number - used to compute the MAC is the 64-bit value formed by - concatenating the epoch and the sequence number in the order - they appear on the wire. Note that the DTLS epoch + sequence - number is the same length as the TLS sequence number. - - Note that one important difference between DTLS and TLS MAC - handling is that in TLS MAC errors must result in connection - termination. In DTLS, the receiving implementation MAY simply - discard the offending record and continue with the connection. - This change is possible because DTLS records are not dependent - on each other the way that TLS records are. - - -4.1.2.2. Null or standard stream cipher - - The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL - cipher. - - - - - -Rescorla, Modadugu [Page 9] - - - The only stream cipher described in TLS 1.1 is RC4, which - cannot be randomly accessed. RC4 MUST NOT be used with DTLS. - -4.1.2.3. Block Cipher - - DTLS block cipher encryption and decryption are performed - exactly as with TLS 1.1. - -4.1.2.4. New Cipher Suites - - Upon registration, new TLS cipher suites MUST indicate whether - they are suitable for DTLS usage and what, if any, adaptations - must be made. - -4.1.2.5. Anti-Replay - - DTLS records contain a sequence number to provide replay - protection. Sequence number verification SHOULD be performed - using the following sliding, window procedure, borrowed from - Section 3.4.3 of [RFC 2402] - - The receiver packet counter for this session MUST be - initialized to zero when the session is established. For each - received record, the receiver MUST verify that the record - contains a Sequence Number that does not duplicate the - Sequence Number of any other record received during the life - of this session. This SHOULD be the first check applied to a - packet after it has been matched to a session, to speed - rejection of duplicate records. - - Duplicates are rejected through the use of a sliding receive - window. (How the window is implemented is a local matter, but - the following text describes the functionality that the - implementation must exhibit.) A minimum window size of 32 MUST - be supported; but a window size of 64 is preferred and SHOULD - be employed as the default. Another window size (larger than - the minimum) MAY be chosen by the receiver. (The receiver does - not notify the sender of the window size.) - - The "right" edge of the window represents the highest, - validated Sequence Number value received on this session. - Records that contain Sequence Numbers lower than the "left" - edge of the window are rejected. Packets falling within the - window are checked against a list of received packets within - the window. An efficient means for performing this check, - based on the use of a bit mask, is described in Appendix C of - [RFC 2401]. - - - - -Rescorla, Modadugu [Page 10] - - - If the received record falls within the window and is new, or - if the packet is to the right of the window, then the receiver - proceeds to MAC verification. If the MAC validation fails, the - receiver MUST discard the received record as invalid. The - receive window is updated only if the MAC verification - succeeds. - -4.2. The DTLS Handshake Protocol - - DTLS uses all of the same handshake messages and flows as TLS, - with three principal changes: - - 1. A stateless cookie exchange has been added to prevent - denial of service attacks. - - 2. Modifications to the handshake header to handle message - loss, reordering and fragmentation. - - 3. Retransmission timers to handle message loss. - - With these exceptions, the DTLS message formats, flows, and - logic are the same as those of TLS 1.1. - -4.2.1. Denial of Service Countermeasures - - Datagram security protocols are extremely susceptible to a - variety of denial of service (DoS) attacks. Two attacks are of - particular concern: - - 1. An attacker can consume excessive resources on the - server by transmitting a series of handshake initiation - requests, causing the server to allocate state and - potentially perform expensive cryptographic operations. - - 2. An attacker can use the server as an amplifier by - sending connection initiation messages with a forged source - of the victim. The server then sends its next message (in - DTLS, a Certificate message, which can be quite large) to - the victim machine, thus flooding it. - - In order to counter both of these attacks, DTLS borrows the - stateless cookie technique used by Photuris [PHOTURIS] and IKE - [IKE]. When the client sends its ClientHello message to the - server, the server MAY respond with a HelloVerifyRequest - message. This message contains a stateless cookie generated - using the technique of [PHOTURIS]. The client MUST retransmit - the ClientHello with the cookie added. The server then - verifies the cookie and proceeds with the handshake only if it - - - -Rescorla, Modadugu [Page 11] - - - is valid. This mechanism forces the attacker/client to be able - to receive the cookie, which makes DoS attacks with spoofed IP - addresses difficult. This mechanism does not provide any - defense against DoS attacks mounted from valid IP addresses. - - The exchange is shown below: - - Client Server - ------ ------ - ClientHello ------> - - <----- HelloVerifyRequest - (contains cookie) - - ClientHello ------> - (with cookie) - - [Rest of handshake] - - DTLS therefore modifies the ClientHello message to add the - cookie value. - - struct { - ProtocolVersion client_version; - Random random; - SessionID session_id; - opaque cookie<0..32>; // New field - CipherSuite cipher_suites<2..2^16-1>; - CompressionMethod compression_methods<1..2^8-1>; - } ClientHello; - - When sending the first ClientHello, the client does not have a - cookie yet; in this case, the Cookie field is left empty (zero - length). - - The definition of HelloVerifyRequest is as follows: - - struct { - Cookie cookie<0..32>; - } HelloVerifyRequest; - - The HelloVerifyRequest message type is - hello_verify_request(3). - - When responding to a HelloVerifyRequest the client MUST use - the same parameter values (version, random, session_id, - cipher_suites, compression_method) as in the original - ClientHello. The server SHOULD use those values to generate - - - -Rescorla, Modadugu [Page 12] - - - its cookie and verify that they are correct upon cookie - receipt. The DTLS server SHOULD generate cookies in such a way - that they can be verified without retaining any per-client - state on the server. One technique is to have a randomly - generated secret and generate cookies as: - Cookie = HMAC(Secret, Client-IP, Client-Parameters) - - When the second ClientHello is received, the server can verify - that the Cookie is valid and that the client can receive - packets at the given IP address. - One potential attack on this scheme is for the attacker to - collect a number of cookies from different addresses and then - reuse them to attack the server. The server can defend against - this attack by changing the Secret value frequently, thus - invalidating those cookies. If the server wishes legitimate - clients to be able to handshake through the transition (e.g., - they received a cookie with Secret 1 and then sent the second - ClientHello after the server has changed to Secret 2), the - server can have a limited window during which it accepts both - secrets. [IKEv2] suggests adding a version number to cookies - to detect this case. An alternative approach is simply to try - verifying with both secrets. - - Although DTLS servers are not required to do a cookie - exchange, they SHOULD do so whenever a new handshake is - performed in order to avoid being used as amplifiers. If the - server is being operated in an environment where amplification - is not a problem, the server MAY choose not to perform a - cookie exchange. In addition, the server MAY choose not do to - a cookie exchange when a session is resumed. Clients MUST be - prepared to do a cookie exchange with every handshake. - - If HelloVerifyRequest is used, the initial ClientHello and - HelloVerifyRequest are not included in the calculation of the - verify_data for the Finished message. - -4.2.2. Handshake Message Format - - In order to support message loss, reordering, and - fragmentation DTLS modifies the TLS 1.1 handshake header: - - struct { - HandshakeType msg_type; - uint24 length; - uint16 message_seq; // New field - uint24 fragment_offset; // New field - uint24 fragment_length; // New field - select (HandshakeType) { - - - -Rescorla, Modadugu [Page 13] - - - case hello_request: HelloRequest; - case client_hello: ClientHello; - case hello_verify_request: HelloVerifyRequest; // New type - case server_hello: ServerHello; - case certificate:Certificate; - case server_key_exchange: ServerKeyExchange; - case certificate_request: CertificateRequest; - case server_hello_done:ServerHelloDone; - case certificate_verify: CertificateVerify; - case client_key_exchange: ClientKeyExchange; - case finished:Finished; - } body; - } Handshake; - - The first message each side transmits in each handshake always - has message_seq = 0. Whenever each new message is generated, - the message_seq value is incremented by one. When a message is - retransmitted, the same message_seq value is used. For - example. - - Client Server - ------ ------ - ClientHello (seq=0) ------> - - X<-- HelloVerifyRequest (seq=0) - (lost) - - [Timer Expires] - - ClientHello (seq=0) ------> - (retransmit) - - <------ HelloVerifyRequest (seq=0) - - ClientHello (seq=1) ------> - (with cookie) - - <------ ServerHello (seq=1) - <------ Certificate (seq=2) - <------ ServerHelloDone (seq=3) - - [Rest of handshake] - - Note, however, that from the perspective of the DTLS record - layer, the retransmission is a new record. This record will - have a new DTLSPlaintext.sequence_number value. - - - - - -Rescorla, Modadugu [Page 14] - - - DTLS implementations maintain (at least notionally) a - next_receive_seq counter. This counter is initially set to - zero. When a message is received, if its sequence number - matches next_receive_seq, next_receive_seq is incremented and - the message is processed. If the sequence number is less than - next_receive_seq the message MUST be discarded. If the - sequence number is greater than next_receive_seq, the - implementation SHOULD queue the message but MAY discard it. - (This is a simple space/bandwidth tradeoff). - -4.2.3. Message Fragmentation and Reassembly - - As noted in Section 4.1.1., each DTLS message MUST fit within - a single transport layer datagram. However, handshake messages - are potentially bigger than the maximum record size. Therefore - DTLS provides a mechanism for fragmenting a handshake message - over a number of records. - - When transmitting the handshake message, the sender divides - the message into a series of N contiguous data ranges. These - range MUST NOT be larger than the maximum handshake fragment - size and MUST jointly contain the entire handshake message. - The ranges SHOULD NOT overlap. The sender then creates N - handshake messages, all with the same message_seq value as the - original handshake message. Each new message is labelled with - the fragment_offset (the number of bytes contained in previous - fragments) and the fragment_length (the length of this - fragment). The length field in all messages is the same as the - length field of the original message. An unfragmented message - is a degenerate case with fragment_offset=0 and - fragment_length=length. - - When a DTLS implementation receives a handshake message - fragment, it MUST buffer it until it has the entire handshake - message. DTLS implementations MUST be able to handle - overlapping fragment ranges. This allows senders to retransmit - handshake messages with smaller fragment sizes during path MTU - discovery. - - Note that as with TLS, multiple handshake messages may be - placed in the same DTLS record, provided that there is room - and that they are part of the same flight. Thus, there are two - acceptable ways to pack two DTLS messages into the same - datagram: in the same record or in separate records. - - - - - - - -Rescorla, Modadugu [Page 15] - - -4.2.4. Timeout and Retransmission - - DTLS messages are grouped into a series of message flights, - according the diagrams below. Although each flight of messages - may consist of a number of messages, they should be viewed as - monolithic for the purpose of timeout and retransmission. - - Client Server - ------ ------ - - ClientHello --------> Flight 1 - - <------- HelloVerifyRequest Flight 2 - - ClientHello --------> Flight 3 - - ServerHello \ - Certificate* \ - ServerKeyExchange* Flight 4 - CertificateRequest* / - <-------- ServerHelloDone / - - Certificate* \ - ClientKeyExchange \ - CertificateVerify* Flight 5 - [ChangeCipherSpec] / - Finished --------> / - - [ChangeCipherSpec] \ Flight 6 - <-------- Finished / - Figure 1: Message flights for full handshake - - - Client Server - ------ ------ - - ClientHello --------> Flight 1 - - ServerHello \ - [ChangeCipherSpec] Flight 2 - <-------- Finished / - - [ChangeCipherSpec] \Flight 3 - Finished --------> / - Figure 2: Message flights for session resuming handshake (no - cookie exchange) - - - - - -Rescorla, Modadugu [Page 16] - - - DTLS uses a simple timeout and retransmission scheme with the - following state machine. Because DTLS clients send the first - message (ClientHello) they start in the PREPARING state. DTLS - servers start in the WAITING state, but with empty buffers and - no retransmit timer. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Rescorla, Modadugu [Page 17] - - - +-----------+ - | PREPARING | - +---> | | - | | | - | +-----------+ - | | - | | - | | Buffer next flight - | | - | \|/ - | +-----------+ - | | | - | | SENDING |<------------------+ - | | | | - | +-----------+ | - Receive | | | - next | | Send flight | - flight | +--------+ | - | | | Set retransmit timer | - | | \|/ | - | | +-----------+ | - | | | | | - +--)--| WAITING |-------------------+ - | | | | Timer expires | - | | +-----------+ | - | | | | - | | | | - | | +------------------------+ - | | Read retransmit - Receive | | - last | | - flight | | - | | - \|/\|/ - - +-----------+ - | | - | FINISHED | - | | - +-----------+ - - Figure 3: DTLS timeout and retransmission state machine - - - The state machine has three basic states. - - In the PREPARING state the implementation does whatever - computations are necessary to prepare the next flight of - - - -Rescorla, Modadugu [Page 18] - - - messages. It then buffers them up for transmission (emptying - the buffer first) and enters the SENDING state. - - In the SENDING state, the implementation transmits the - buffered flight of messages. Once the messages have been sent, - the implementation then enters the FINISHED state if this is - the last flight in the handshake, or, if the implementation - expects to receive more messages, sets a retransmit timer and - then enters the WAITING state. - - There are three ways to exit the WAITING state: - - 1. The retransmit timer expires: the implementation - transitions to the SENDING state, where it retransmits the - flight, resets the retransmit timer, and returns to the - WAITING state. - - 2. The implementation reads a retransmitted flight from the - peer: the implementation transitions to the SENDING state, - where it retransmits the flight, resets the retransmit - timer, and returns to the WAITING state. The rationale here - is that the receipt of a duplicate message is the likely - result of timer expiry on the peer and therefore suggests - that part of one's previous flight was lost. - - 3. The implementation receives the next flight of messages: - if this is the final flight of messages the implementation - transitions to FINISHED. If the implementation needs to - send a new flight, it transitions to the PREPARING state. - Partial reads (whether partial messages or only some of the - messages in the flight) do not cause state transitions or - timer resets. - - Because DTLS clients send the first message (ClientHello) they - start in the PREPARING state. DTLS servers start in the - WAITING state, but with empty buffers and no retransmit timer. - -4.2.4.1. Timer Values - - Timer value choices are a local matter. Implementations SHOULD - use an initial timer value of 500 ms and double the value at - each retransmission, up to twice the TCP maximum segment - lifetime [TCP] (if the recommendations in [TCP] are followed, - this will be 240 seconds). Implementations SHOULD start the - timer value at the initial value with each new flight of - messages. - - - - - -Rescorla, Modadugu [Page 19] - - -4.2.5. ChangeCipherSpec - - As with TLS, the ChangeCipherSpec message is not technically a - handshake message but MUST be treated as part of the same - flight as the associated Finished message for the purposes of - timeout and retransmission. - -4.2.6. Finished messages - - Finished messages have the same format as in TLS. However, in - order to remove sensitivity to fragmentation, the Finished MAC - MUST be computed as if each handshake message had been sent as - a single fragment. Note that in cases where the cookie - exchange is used, the initial ClientHello and - HelloVerifyRequest MUST BE included in the Finished MAC. - -4.2.7. Alert Messages - - Note that Alert messages are not retransmitted at all, even - when they occur in the context of a handshake. However, a DTLS - implementation SHOULD generate a new alert message if the - offending record is received again (e.g., as a retransmitted - handshake message). - - - -A.1Summary of new syntax - - This section includes specifications for the data structures - that have changed between TLS 1.1 and DTLS. - -4.2. Record Layer - struct { - ContentType type; - ProtocolVersion version; - uint16 epoch; // New field - uint48 sequence_number; // New field - uint16 length; - opaque fragment[DTLSPlaintext.length]; - } DTLSPlaintext; - - struct { - ContentType type; - ProtocolVersion version; - uint16 epoch; // New field - uint48 sequence_number; // New field - uint16 length; - opaque fragment[DTLSCompressed.length]; - - - -Rescorla, Modadugu [Page 20] - - - } DTLSCompressed; - - struct { - ContentType type; - ProtocolVersion version; - uint16 epoch; // New field - uint48 sequence_number; // New field - uint16 length; - select (CipherSpec.cipher_type) { - case block: GenericBlockCipher; - } fragment; - } DTLSCiphertext; - -4.3. Handshake Protocol - - enum { - hello_request(0), client_hello(1), server_hello(2), - hello_verify_request(3), // New field - certificate(11), server_key_exchange (12), - certificate_request(13), server_hello_done(14), - certificate_verify(15), client_key_exchange(16), - finished(20), (255) - } HandshakeType; - - struct { - HandshakeType msg_type; - uint24 length; - uint16 message_seq; // New field - uint24 fragment_offset; // New field - uint24 fragment_length; // New field - select (HandshakeType) { - case hello_request: HelloRequest; - case client_hello: ClientHello; - case server_hello: ServerHello; - case hello_verify_request: HelloVerifyRequest; // New field - case certificate:Certificate; - case server_key_exchange: ServerKeyExchange; - case certificate_request: CertificateRequest; - case server_hello_done:ServerHelloDone; - case certificate_verify: CertificateVerify; - case client_key_exchange: ClientKeyExchange; - case finished:Finished; - } body; - } Handshake; - - struct { - ProtocolVersion client_version; - Random random; - - - -Rescorla, Modadugu [Page 21] - - - SessionID session_id; - opaque cookie<0..32>; // New field - CipherSuite cipher_suites<2..2^16-1>; - CompressionMethod compression_methods<1..2^8-1>; - } ClientHello; - - struct { - Cookie cookie<0..32>; - } HelloVerifyRequest; - -5. Security Considerations - - This document describes a variant of TLS 1.1 and therefore - most of the security considerations are the same as those of - TLS 1.1 [TLS11], described in Appendices D, E, and F. - - The primary additional security consideration raised by DTLS - is that of denial of service. DTLS includes a cookie exchange - designed to protect against denial of service. However, - implementations which do not use this cookie exchange are - still vulnerable to DoS. In particular, DTLS servers which do - not use the cookie exchange may be used as attack amplifiers - even if they themselves are not experiencing DoS. Therefore - DTLS servers SHOULD use the cookie exchange unless there is - good reason to believe that amplification is not a threat in - their environment. - -6. IANA Considerations - - This document uses the same identifier space as TLS [TLS11], - so no new IANA registries are required. When new identifiers - are assigned for TLS, authors MUST specify whether they are - suitable for DTLS. - - This document defines a new handshake message, - hello_verify_request, whose value is to be allocated from the - TLS HandshakeType registry defined in [TLS11]. The value "3" - is suggested. - -References - -Normative References - - [RFC1191] Mogul, J. C., Deering, S.E., "Path MTU Discovery", - RFC 1191, November 1990. - - [RFC2401] Kent, S., Atkinson, R., "Security Architecture for the - Internet Protocol", RFC2401, November 1998. - - - -Rescorla, Modadugu [Page 22] - - - [TCP] Postel, J., "Transmission Control Protocol", - RFC 793, September 1981. - - [TLS11] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1", - draft-ietf-tls-rfc2246-bis-05.txt, July 2003. - - -Informative References - - [AH] Kent, S., and Atkinson, R., "IP Authentication Header", - RFC 2402, November 1998. - - [DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram - Congestion Control Protocol", draft-ietf-dccp-spec-11.txt, - 10 March 2005 - - [DNS] Mockapetris, P.V., "Domain names - implementation and - specification", RFC 1035, November 1987. - - [DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation - of Datagram TLS", Proceedings of ISOC NDSS 2004, February 2004. - - [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security - Payload (ESP)", RFC 2406, November 1998. - - - [IKE] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", - RFC 2409, November 1998. - - [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", - draft-ietf-ipsec-ikev2-17.txt, September 2004. - - [IMAP] Crispin, M., "Internet Message Access Protocol - Version - 4rev1", RFC 3501, March 2003. - - [PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management - Protocol", RFC 2521, March 1999. - - - [POP] Myers, J., and Rose, M., "Post Office Protocol - - Version 3", RFC 1939, May 1996. - - - [REQ] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - - [SIP] Rosenberg, J., Schulzrinne, Camarillo, G., Johnston, A., - - - -Rescorla, Modadugu [Page 23] - - - Peterson, J., Sparks, R., Handley, M., Schooler, E., - "SIP: Session Initiation Protocol", RFC 3261, - June 2002. - - [TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", - RFC 2246, January 1999. - - [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", - draft-bellovin-useipsec-02.txt, October 2003 - -Authors' Address - - Eric Rescorla <ekr@rtfm.com> - RTFM, Inc. - 2064 Edgewood Drive - Palo Alto, CA 94303 - - Nagendra Modadugu <nagendra@cs.stanford.edu> - Computer Science Department - 353 Serra Mall - Stanford University - Stanford, CA 94305 - - - -Acknowledgements - - The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ - Housley, Constantine Sapuntzakis, and Hovav Shacham for - discussions and comments on the design of DTLS. Thanks to the - anonymous NDSS reviewers of our original NDSS paper on DTLS - [DTLS] for their comments. Also, thanks to Steve Kent for - feedback that helped clarify many points. The section on PMTU - was cribbed from the DCCP specification [DCCP]. Pasi Eronen - provided a detailed review of this specification. - - - - - - - - - - - - - - - - -Rescorla, Modadugu [Page 24] - - -Full Copyright Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Copyright Notice - Copyright (C) The Internet Society (2003). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - -Rescorla, Modadugu [Page 25] - |