| < draft-rescorla-dtls-04.txt | draft-rescorla-dtls-05.txt > | |||
|---|---|---|---|---|
| E. Rescorla | ||||
| E. Rescorla | ||||
| RTFM, Inc. | RTFM, Inc. | |||
| N. Modadugu | N. Modadugu | |||
| INTERNET-DRAFT Stanford University | INTERNET-DRAFT Stanford University | |||
| <draft-rescorla-dtls-04.txt> April 2004 (Expires October 2005) | <draft-rescorla-dtls-05.txt> June 2004 (Expires December 2005) | |||
| Datagram Transport Layer Security | Datagram Transport Layer Security | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | 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 | 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. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| skipping to change at page 1, line 35 ¶ | skipping to change at page 1, line 36 ¶ | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/1id-abstracts.html | http://www.ietf.org/1id-abstracts.html | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html | http://www.ietf.org/shadow.html | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (1999-2004). All Rights Reserved. | Copyright (C) The Internet Society (2005). All Rights Reserved. | |||
| Abstract | Abstract | |||
| This document specifies Version 1.0 of the Datagram Transport | This document specifies Version 1.0 of the Datagram Transport | |||
| Layer Security (DTLS) protocol. The DTLS protocol provides | Layer Security (DTLS) protocol. The DTLS protocol provides | |||
| communications privacy for datagram protocols. The protocol | communications privacy for datagram protocols. The protocol | |||
| allows client/server applications to communicate in a way that | allows client/server applications to communicate in a way that | |||
| is designed to prevent eavesdropping, tampering, or message | is designed to prevent eavesdropping, tampering, or message | |||
| forgery. The DTLS protocol is based on the TLS protocol and | forgery. The DTLS protocol is based on the TLS protocol and | |||
| provides equivalent security guarantees. Datagram semantics of | provides equivalent security guarantees. Datagram semantics of | |||
| skipping to change at page 2, line 31 ¶ | skipping to change at page 2, line 31 ¶ | |||
| 3 Overview of DTLS 4 | 3 Overview of DTLS 4 | |||
| 3.1 Loss-insensitive messaging 4 | 3.1 Loss-insensitive messaging 4 | |||
| 3.2 Providing Reliability for Handshake 5 | 3.2 Providing Reliability for Handshake 5 | |||
| 3.2.1 Packet Loss 5 | 3.2.1 Packet Loss 5 | |||
| 3.2.2 Reordering 6 | 3.2.2 Reordering 6 | |||
| 3.2.3 Message Size 6 | 3.2.3 Message Size 6 | |||
| 3.3 Replay Detection 6 | 3.3 Replay Detection 6 | |||
| 4 Differences from TLS 6 | 4 Differences from TLS 6 | |||
| 4.1 Record Layer 7 | 4.1 Record Layer 7 | |||
| 4.1.1 Transport Layer Mapping 8 | 4.1.1 Transport Layer Mapping 8 | |||
| 4.1.1.1 PMTU Discovery 8 | 4.1.1.1 PMTU Discovery 9 | |||
| 4.1.2 Record payload protection 9 | 4.1.2 Record payload protection 9 | |||
| 4.1.2.1 MAC 9 | 4.1.2.1 MAC 10 | |||
| 4.1.2.2 Null or standard stream cipher 9 | 4.1.2.2 Null or standard stream cipher 10 | |||
| 4.1.2.3 Block Cipher 10 | 4.1.2.3 Block Cipher 10 | |||
| 4.1.2.4 New Cipher Suites 10 | 4.1.2.4 New Cipher Suites 10 | |||
| 4.1.2.5 Anti-Replay 10 | 4.1.2.5 Anti-Replay 10 | |||
| 4.2 The DTLS Handshake Protocol 11 | 4.2 The DTLS Handshake Protocol 11 | |||
| 4.2.1 Denial of Service Countermeasures 11 | 4.2.1 Denial of Service Countermeasures 12 | |||
| 4.2.2 Handshake Message Format 13 | 4.2.2 Handshake Message Format 14 | |||
| 4.2.3 Message Fragmentation and Reassembly 15 | 4.2.3 Message Fragmentation and Reassembly 16 | |||
| 4.2.4 Timeout and Retransmission 16 | 4.2.4 Timeout and Retransmission 16 | |||
| 4.2.4.1 Timer Values 19 | 4.2.4.1 Timer Values 19 | |||
| 4.2.5 ChangeCipherSpec 20 | 4.2.5 ChangeCipherSpec 20 | |||
| 4.2.6 Finished messages 20 | 4.2.6 Finished messages 20 | |||
| 4.2.7 Alert Messages 20 | 4.2.7 Alert Messages 20 | |||
| 4.2 Record Layer 20 | 4.2 Record Layer 21 | |||
| 4.3 Handshake Protocol 21 | 4.3 Handshake Protocol 21 | |||
| 5 Security Considerations 22 | 5 Security Considerations 22 | |||
| 6 IANA Considerations 22 | 6 IANA Considerations 23 | |||
| 1. Introduction | 1. Introduction | |||
| TLS [TLS] is the most widely deployed protocol for securing | TLS [TLS] is the most widely deployed protocol for securing | |||
| network traffic. It is widely used for protecting Web traffic | network traffic. It is widely used for protecting Web traffic | |||
| and for e-mail protocols such as IMAP [IMAP] and POP [POP]. | and for e-mail protocols such as IMAP [IMAP] and POP [POP]. | |||
| The primary advantage of TLS is that it provides a transparent | The primary advantage of TLS is that it provides a transparent | |||
| connection-oriented channel. Thus, it is easy to secure an | connection-oriented channel. Thus, it is easy to secure an | |||
| application protocol by inserting TLS between the application | application protocol by inserting TLS between the application | |||
| layer and the transport layer. However, TLS must run over a | layer and the transport layer. However, TLS must run over a | |||
| reliable transport channel--typically TCP [TCP]. It therefore | reliable transport channel--typically TCP [TCP]. It therefore | |||
| cannot be used to secure unreliable datagram traffic. | cannot be used to secure unreliable datagram traffic. | |||
| However, over the past few years an increasing number of | However, over the past few years an increasing number of | |||
| application layer protocols have been designed which UDP | application layer protocols have been designed which use UDP | |||
| transport. In particular such protocols as the Session | transport. In particular such protocols as the Session | |||
| Initiation Protocol (SIP) [SIP], and electronic gaming | Initiation Protocol (SIP) [SIP], and electronic gaming | |||
| protocols are increasingly popular. (Note that SIP can run | protocols are increasingly popular. (Note that SIP can run | |||
| over both TCP and UDP, but that there are situations in which | over both TCP and UDP, but that there are situations in which | |||
| UDP is preferable). Currently, designers of these applications | UDP is preferable). Currently, designers of these applications | |||
| are faced with a number of unsatisfactory choices. First, they | are faced with a number of unsatisfactory choices. First, they | |||
| can use IPsec [RFC2401]. However, for a number of reasons | can use IPsec [RFC2401]. However, for a number of reasons | |||
| detailed in [WHYIPSEC], this is only suitable for some | detailed in [WHYIPSEC], this is only suitable for some | |||
| applications. Second, they can design a custom application | applications. Second, they can design a custom application | |||
| layer security protocol. SIP, for instance, uses a subsert of | layer security protocol. SIP, for instance, uses a subset of | |||
| S/MIME to secure its traffic. Unfortunately, while application | S/MIME to secure its traffic. Unfortunately, while application | |||
| layer security protocols generally provide superior security | layer security protocols generally provide superior security | |||
| properties (e.g., end-to-end security in the case of S/MIME) | properties (e.g., end-to-end security in the case of S/MIME) | |||
| it typically require a large amount of effort to design--by | it typically requires a large amount of effort to design--by | |||
| contrast to the relatively small amount of effort required to | contrast to the relatively small amount of effort required to | |||
| run the protocol over TLS. | run the protocol over TLS. | |||
| In many cases, the most desirable way to secure client/server | In many cases, the most desirable way to secure client/server | |||
| applications would be to use TLS; however the requirement for | applications would be to use TLS; however the requirement for | |||
| datagram semantics automatically prohibits use of TLS. Thus, a | datagram semantics automatically prohibits use of TLS. Thus, a | |||
| datagram-compatible variant of TLS would be very desirable. | datagram-compatible variant of TLS would be very desirable. | |||
| This memo describes such a protocol: Datagram Transport Layer | This memo describes such a protocol: Datagram Transport Layer | |||
| Security (DTLS). DTLS is deliberately designed to be as | Security (DTLS). DTLS is deliberately designed to be as | |||
| similar to to TLS as possible, both to minimize new security | similar to to TLS as possible, both to minimize new security | |||
| skipping to change at page 6, line 48 ¶ | skipping to change at page 6, line 48 ¶ | |||
| but can also occur due to routing errors. Applications may | but can also occur due to routing errors. Applications may | |||
| conceivably detect duplicate packets and accordingly modify | conceivably detect duplicate packets and accordingly modify | |||
| their data transmission strategy. | their data transmission strategy. | |||
| 4. Differences from TLS | 4. Differences from TLS | |||
| As mentioned in Section 3., DTLS is intentionally very similar | As mentioned in Section 3., DTLS is intentionally very similar | |||
| to TLS. Therefore, instead of presenting DTLS as a new | to TLS. Therefore, instead of presenting DTLS as a new | |||
| protocol, we instead present it as a series of deltas from TLS | protocol, we instead present it as a series of deltas from TLS | |||
| 1.1 [TLS11]. Where we do not explicitly call out differences, | 1.1 [TLS11]. Where we do not explicitly call out differences, | |||
| DTLS is the same as TLS. | DTLS is the same as in [TLS11]. | |||
| 4.1. Record Layer | 4.1. Record Layer | |||
| The DTLS record layer is extremely similar to that of TLS 1.1. | The DTLS record layer is extremely similar to that of TLS 1.1. | |||
| The only change is the inclusion of an explicit sequence | The only change is the inclusion of an explicit sequence | |||
| number in the record. This sequence number allows the | number in the record. This sequence number allows the | |||
| recipient to correctly verify the TLS MAC. The DTLS record | recipient to correctly verify the TLS MAC. The DTLS record | |||
| format is shown below: | format is shown below: | |||
| struct { | struct { | |||
| skipping to change at page 8, line 35 ¶ | skipping to change at page 8, line 35 ¶ | |||
| per-record overhead). If the application attempts to send a | per-record overhead). If the application attempts to send a | |||
| record larger than the MTU the DTLS implementation SHOULD | record larger than the MTU the DTLS implementation SHOULD | |||
| generate an error, thus avoiding sending a packet which will | generate an error, thus avoiding sending a packet which will | |||
| be fragmented. | be fragmented. | |||
| Note that unlike IPsec, DTLS records do not contain any | Note that unlike IPsec, DTLS records do not contain any | |||
| association identifiers. Applications must arrange to | association identifiers. Applications must arrange to | |||
| multiplex between associations. With UDP, this is presumably | multiplex between associations. With UDP, this is presumably | |||
| done with host/port number. | done with host/port number. | |||
| Multiple DTLS records may be placed in a single datagram. hey | Multiple DTLS records may be placed in a single datagram. They | |||
| are simply encoded consecutively. The DTLS record framing is | are simply encoded consecutively. The DTLS record framing is | |||
| sufficient to determine the boundaries. Note, however, that | sufficient to determine the boundaries. Note, however, that | |||
| the first byte of the datagram payload must be the beginning | the first byte of the datagram payload must be the beginning | |||
| of a record. Records may not span datagrams. | of a record. Records may not span datagrams. | |||
| Some transports, such as DCCP [DCCP] provide their own | ||||
| sequence numbers. When carried over those transports, both the | ||||
| DTLS and the transport sequence numbers will be present. | ||||
| Although this introduces a small amount of inefficiency, the | ||||
| transport layer and DTLS sequence numbers serve different | ||||
| purposes and therefore for conceptual simplicity it is | ||||
| superior to use both sequence numbers. In the future, | ||||
| extensions to DTLS may be specified that allow the use of only | ||||
| one set of sequence numbers for deployment in constrained | ||||
| environments. | ||||
| Some transports, such as DCCP, provide congestion control | ||||
| for traffic carried over them. If the congestion window is | ||||
| sufficiently narrow, DTLS handshake retransmissions may be | ||||
| held rather than transmitted immediately, potentially leading | ||||
| to timeouts and spurious retransmission. When DTLS is used | ||||
| over such transports, care should be taken not to overrun the | ||||
| likely congestion window. In the future, a DTLS-DCCP mapping | ||||
| may be specificied to provide optimal behavior for this | ||||
| interaction. | ||||
| 4.1.1.1. PMTU Discovery | 4.1.1.1. PMTU Discovery | |||
| In general, DTLS's philosophy is to avoid dealing with PMTU | In general, DTLS's philosophy is to avoid dealing with PMTU | |||
| issues. The general strategy is to start with a conservative | issues. The general strategy is to start with a conservative | |||
| MTU and then update it if events require it, but not actively | MTU and then update it if events during the handshake or | |||
| probe for MTU values. PMTU discovery is left to the | actual application data transport phase require it. | |||
| application. | ||||
| The PMTU SHOULD be initialized from the interface MTU that | The PMTU SHOULD be initialized from the interface MTU that | |||
| will be used to send packets. If the DTLS implementation | will be used to send packets. If the DTLS implementation | |||
| receives an RFC 1191 [RFC1191] ICMP Destination Unreachable | receives an RFC 1191 [RFC1191] ICMP Destination Unreachable | |||
| message with the "fragmentation needed and DF set" Code | message with the "fragmentation needed and DF set" Code | |||
| (otherwise known as Datagram Too Big) it should decrease its | (otherwise known as Datagram Too Big) it should decrease its | |||
| PMTU estimate to that given in the ICMP message. A DTLS | PMTU estimate to that given in the ICMP message. A DTLS | |||
| implementation SHOULD allow the application to occasionally | implementation SHOULD allow the application to occasionally | |||
| reset its PMTU estimate. The DTLS implementation SHOULD also | reset its PMTU estimate. The DTLS implementation SHOULD also | |||
| allow applications to control the status of the DF bit. These | allow applications to control the status of the DF bit. These | |||
| controls allow the application to perform PMTU discovery. | controls allow the application to perform PMTU discovery. RFC | |||
| 1981 [RFC1981] procedures SHOULD be followed for IPv6. | ||||
| One special case is the DTLS handshake system. Handshake | One special case is the DTLS handshake system. Handshake | |||
| messages should be set with DF set. Because some firewalls and | messages should be set with DF set. Because some firewalls and | |||
| routers screen out ICMP messages, it is difficult for the | routers screen out ICMP messages, it is difficult for the | |||
| handshake layer to distinguish packet loss from an overlarge | handshake layer to distinguish packet loss from an overlarge | |||
| PMTU estimate. In order to allow connections under these | PMTU estimate. In order to allow connections under these | |||
| circumstances, DTLS implementations SHOULD back off handshake | circumstances, DTLS implementations SHOULD back off handshake | |||
| packet size during the retransmit backoff described in Section | packet size during the retransmit backoff described in Section | |||
| 4.2.4.. For instance, if a large packet is being sent, after 3 | 4.2.4.. For instance, if a large packet is being sent, after 3 | |||
| retransmits the handshake layer might choose to fragment the | retransmits the handshake layer might choose to fragment the | |||
| skipping to change at page 9, line 44 ¶ | skipping to change at page 10, line 20 ¶ | |||
| concatenating the epoch and the sequence number in the order | concatenating the epoch and the sequence number in the order | |||
| they appear on the wire. Note that the DTLS epoch + sequence | they appear on the wire. Note that the DTLS epoch + sequence | |||
| number is the same length as the TLS sequence number. | number is the same length as the TLS sequence number. | |||
| Note that one important difference between DTLS and TLS MAC | Note that one important difference between DTLS and TLS MAC | |||
| handling is that in TLS MAC errors must result in connection | handling is that in TLS MAC errors must result in connection | |||
| termination. In DTLS, the receiving implementation MAY simply | termination. In DTLS, the receiving implementation MAY simply | |||
| discard the offending record and continue with the connection. | discard the offending record and continue with the connection. | |||
| This change is possible because DTLS records are not dependent | This change is possible because DTLS records are not dependent | |||
| on each other the way that TLS records are. | on each other the way that TLS records are. | |||
| In general, DTLS implementations SHOULD silently discard | ||||
| data with bad MACs. If a DTLS implementation chooses to | ||||
| generate an alert when it receives a message with an invalid | ||||
| MAC, it MUST generate bad_record_mac alert with level fatal | ||||
| and terminate its connection state. | ||||
| 4.1.2.2. Null or standard stream cipher | 4.1.2.2. Null or standard stream cipher | |||
| The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL | The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL | |||
| cipher. | cipher. | |||
| The only stream cipher described in TLS 1.1 is RC4, which | The only stream cipher described in TLS 1.1 is RC4, which | |||
| cannot be randomly accessed. RC4 MUST NOT be used with DTLS. | cannot be randomly accessed. RC4 MUST NOT be used with DTLS. | |||
| 4.1.2.3. Block Cipher | 4.1.2.3. Block Cipher | |||
| skipping to change at page 10, line 23 ¶ | skipping to change at page 10, line 49 ¶ | |||
| 4.1.2.4. New Cipher Suites | 4.1.2.4. New Cipher Suites | |||
| Upon registration, new TLS cipher suites MUST indicate whether | Upon registration, new TLS cipher suites MUST indicate whether | |||
| they are suitable for DTLS usage and what, if any, adaptations | they are suitable for DTLS usage and what, if any, adaptations | |||
| must be made. | must be made. | |||
| 4.1.2.5. Anti-Replay | 4.1.2.5. Anti-Replay | |||
| DTLS records contain a sequence number to provide replay | DTLS records contain a sequence number to provide replay | |||
| protection. Sequence number verification SHOULD be performed | protection. Sequence number verification SHOULD be performed | |||
| using the following sliding, window procedure, borrowed from | using the following sliding window procedure, borrowed from | |||
| Section 3.4.3 of [RFC 2402] | Section 3.4.3 of [RFC 2402]. | |||
| The receiver packet counter for this session MUST be | The receiver packet counter for this session MUST be | |||
| initialized to zero when the session is established. For each | initialized to zero when the session is established. For each | |||
| received record, the receiver MUST verify that the record | received record, the receiver MUST verify that the record | |||
| contains a Sequence Number that does not duplicate the | contains a Sequence Number that does not duplicate the | |||
| Sequence Number of any other record received during the life | Sequence Number of any other record received during the life | |||
| of this session. This SHOULD be the first check applied to a | of this session. This SHOULD be the first check applied to a | |||
| packet after it has been matched to a session, to speed | packet after it has been matched to a session, to speed | |||
| rejection of duplicate records. | rejection of duplicate records. | |||
| skipping to change at page 12, line 22 ¶ | skipping to change at page 13, line 4 ¶ | |||
| ------ ------ | ------ ------ | |||
| ClientHello ------> | ClientHello ------> | |||
| <----- HelloVerifyRequest | <----- HelloVerifyRequest | |||
| (contains cookie) | (contains cookie) | |||
| ClientHello ------> | ClientHello ------> | |||
| (with cookie) | (with cookie) | |||
| [Rest of handshake] | [Rest of handshake] | |||
| DTLS therefore modifies the ClientHello message to add the | DTLS therefore modifies the ClientHello message to add the | |||
| cookie value. | cookie value. | |||
| struct { | struct { | |||
| ProtocolVersion client_version; | ProtocolVersion client_version; | |||
| Random random; | Random random; | |||
| SessionID session_id; | SessionID session_id; | |||
| opaque cookie<0..32>; // New field | opaque cookie<0..32>; // New field | |||
| CipherSuite cipher_suites<2..2^16-1>; | CipherSuite cipher_suites<2..2^16-1>; | |||
| CompressionMethod compression_methods<1..2^8-1>; | CompressionMethod compression_methods<1..2^8-1>; | |||
| } ClientHello; | } ClientHello; | |||
| When sending the first ClientHello, the client does not have a | When sending the first ClientHello, the client does not have a | |||
| cookie yet; in this case, the Cookie field is left empty (zero | cookie yet; in this case, the Cookie field is left empty (zero | |||
| length). | length). | |||
| The definition of HelloVerifyRequest is as follows: | The definition of HelloVerifyRequest is as follows: | |||
| struct { | struct { | |||
| Cookie cookie<0..32>; | ProtocolVersion server_version; | |||
| opaque cookie<0..32>; | ||||
| } HelloVerifyRequest; | } HelloVerifyRequest; | |||
| The HelloVerifyRequest message type is | The HelloVerifyRequest message type is | |||
| hello_verify_request(3). | hello_verify_request(3). | |||
| The server_version field is defined as in TLS. | ||||
| When responding to a HelloVerifyRequest the client MUST use | When responding to a HelloVerifyRequest the client MUST use | |||
| the same parameter values (version, random, session_id, | the same parameter values (version, random, session_id, | |||
| cipher_suites, compression_method) as in the original | cipher_suites, compression_method) as in the original | |||
| ClientHello. The server SHOULD use those values to generate | ClientHello. The server SHOULD use those values to generate | |||
| its cookie and verify that they are correct upon cookie | its cookie and verify that they are correct upon cookie | |||
| receipt. The DTLS server SHOULD generate cookies in such a way | receipt. The server MUST use the same version number in the | |||
| that they can be verified without retaining any per-client | HelloVerifyRequest that it would use when sending a | |||
| state on the server. One technique is to have a randomly | ServerHello. Upon receipt of the ServerHello, the client MUST | |||
| generated secret and generate cookies as: | verify that the server version values match. | |||
| 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) | Cookie = HMAC(Secret, Client-IP, Client-Parameters) | |||
| When the second ClientHello is received, the server can verify | When the second ClientHello is received, the server can verify | |||
| that the Cookie is valid and that the client can receive | that the Cookie is valid and that the client can receive | |||
| packets at the given IP address. | packets at the given IP address. | |||
| One potential attack on this scheme is for the attacker to | One potential attack on this scheme is for the attacker to | |||
| collect a number of cookies from different addresses and then | collect a number of cookies from different addresses and then | |||
| reuse them to attack the server. The server can defend against | reuse them to attack the server. The server can defend against | |||
| this attack by changing the Secret value frequently, thus | this attack by changing the Secret value frequently, thus | |||
| invalidating those cookies. If the server wishes legitimate | invalidating those cookies. If the server wishes legitimate | |||
| clients to be able to handshake through the transition (e.g., | clients to be able to handshake through the transition (e.g., | |||
| they received a cookie with Secret 1 and then sent the second | they received a cookie with Secret 1 and then sent the second | |||
| ClientHello after the server has changed to Secret 2), the | ClientHello after the server has changed to Secret 2), the | |||
| server can have a limited window during which it accepts both | server can have a limited window during which it accepts both | |||
| secrets. [IKEv2] suggests adding a version number to cookies | secrets. [IKEv2] suggests adding a version number to cookies | |||
| to detect this case. An alternative approach is simply to try | to detect this case. An alternative approach is simply to try | |||
| verifying with both secrets. | verifying with both secrets. | |||
| Although DTLS servers are not required to do a cookie | DTLS servers SHOULD perform a cookie exchange whenever a new | |||
| exchange, they SHOULD do so whenever a new handshake is | handshake is being performed. If the server is being operated | |||
| performed in order to avoid being used as amplifiers. If the | in an environment where amplification is not a problem, the | |||
| server is being operated in an environment where amplification | server MAY be configured to not to perform a cookie exchange. | |||
| is not a problem, the server MAY choose not to perform a | The default SHOULD be that the exchange is performed, however. | |||
| cookie exchange. In addition, the server MAY choose not do to | In addition, the server MAY choose not do to a cookie exchange | |||
| a cookie exchange when a session is resumed. Clients MUST be | when a session is resumed. Clients MUST be prepared to do a | |||
| prepared to do a cookie exchange with every handshake. | cookie exchange with every handshake. | |||
| If HelloVerifyRequest is used, the initial ClientHello and | If HelloVerifyRequest is used, the initial ClientHello and | |||
| HelloVerifyRequest are not included in the calculation of the | HelloVerifyRequest are not included in the calculation of the | |||
| verify_data for the Finished message. | verify_data for the Finished message. | |||
| 4.2.2. Handshake Message Format | 4.2.2. Handshake Message Format | |||
| In order to support message loss, reordering, and | In order to support message loss, reordering, and | |||
| fragmentation DTLS modifies the TLS 1.1 handshake header: | fragmentation DTLS modifies the TLS 1.1 handshake header: | |||
| skipping to change at page 17, line 4 ¶ | skipping to change at page 17, line 43 ¶ | |||
| ClientHello --------> Flight 1 | ClientHello --------> Flight 1 | |||
| ServerHello \ | ServerHello \ | |||
| [ChangeCipherSpec] Flight 2 | [ChangeCipherSpec] Flight 2 | |||
| <-------- Finished / | <-------- Finished / | |||
| [ChangeCipherSpec] \Flight 3 | [ChangeCipherSpec] \Flight 3 | |||
| Finished --------> / | Finished --------> / | |||
| Figure 2: Message flights for session resuming handshake (no | Figure 2: Message flights for session resuming handshake (no | |||
| cookie exchange) | cookie exchange) | |||
| DTLS uses a simple timeout and retransmission scheme with the | DTLS uses a simple timeout and retransmission scheme with the | |||
| following state machine. Because DTLS clients send the first | following state machine. Because DTLS clients send the first | |||
| message (ClientHello) they start in the PREPARING state. DTLS | message (ClientHello) they start in the PREPARING state. DTLS | |||
| servers start in the WAITING state, but with empty buffers and | servers start in the WAITING state, but with empty buffers and | |||
| no retransmit timer. | no retransmit timer. | |||
| +-----------+ | +-----------+ | |||
| | PREPARING | | | PREPARING | | |||
| +---> | | | +---> | | <--------------------+ | |||
| | | | | | | | | | |||
| | +-----------+ | | +-----------+ | | |||
| | | | | | | | |||
| | | | | | | | |||
| | | Buffer next flight | | | Buffer next flight | | |||
| | | | | | | | |||
| | \|/ | | \|/ | | |||
| | +-----------+ | | +-----------+ | | |||
| | | | | | | | | | |||
| | | SENDING |<------------------+ | | | SENDING |<------------------+ | | |||
| | | | | | | | | | | Send | |||
| | +-----------+ | | | +-----------+ | | HelloRequest | |||
| Receive | | | | Receive | | | | | |||
| next | | Send flight | | next | | Send flight | | or | |||
| flight | +--------+ | | flight | +--------+ | | | |||
| | | | Set retransmit timer | | | | | Set retransmit timer | | Receive | |||
| | | \|/ | | | | \|/ | | HelloRequest | |||
| | | +-----------+ | | | | +-----------+ | | Send | |||
| | | | | | | | | | | | | ClientHello | |||
| +--)--| WAITING |-------------------+ | +--)--| WAITING |-------------------+ | | |||
| | | | | Timer expires | | | | | | Timer expires | | | |||
| | | +-----------+ | | | | +-----------+ | | | |||
| | | | | | | | | | | | |||
| | | | | | | | | | | | |||
| | | +------------------------+ | | | +------------------------+ | | |||
| | | Read retransmit | | | Read retransmit | | |||
| Receive | | | Receive | | | | |||
| last | | | last | | | | |||
| flight | | | flight | | | | |||
| | | | | | | | |||
| \|/\|/ | \|/\|/ | | |||
| | | ||||
| +-----------+ | +-----------+ | | |||
| | | | | | | | |||
| | FINISHED | | | FINISHED | -------------------------------+ | |||
| | | | | | | |||
| +-----------+ | +-----------+ | |||
| Figure 3: DTLS timeout and retransmission state machine | Figure 3: DTLS timeout and retransmission state machine | |||
| The state machine has three basic states. | The state machine has three basic states. | |||
| In the PREPARING state the implementation does whatever | In the PREPARING state the implementation does whatever | |||
| computations are necessary to prepare the next flight of | computations are necessary to prepare the next flight of | |||
| messages. It then buffers them up for transmission (emptying | messages. It then buffers them up for transmission (emptying | |||
| the buffer first) and enters the SENDING state. | the buffer first) and enters the SENDING state. | |||
| In the SENDING state, the implementation transmits the | In the SENDING state, the implementation transmits the | |||
| buffered flight of messages. Once the messages have been sent, | buffered flight of messages. Once the messages have been sent, | |||
| skipping to change at page 19, line 41 ¶ | skipping to change at page 19, line 41 ¶ | |||
| transitions to FINISHED. If the implementation needs to | transitions to FINISHED. If the implementation needs to | |||
| send a new flight, it transitions to the PREPARING state. | send a new flight, it transitions to the PREPARING state. | |||
| Partial reads (whether partial messages or only some of the | Partial reads (whether partial messages or only some of the | |||
| messages in the flight) do not cause state transitions or | messages in the flight) do not cause state transitions or | |||
| timer resets. | timer resets. | |||
| Because DTLS clients send the first message (ClientHello) they | Because DTLS clients send the first message (ClientHello) they | |||
| start in the PREPARING state. DTLS servers start in the | start in the PREPARING state. DTLS servers start in the | |||
| WAITING state, but with empty buffers and no retransmit timer. | WAITING state, but with empty buffers and no retransmit timer. | |||
| When the server desires a rehandshake, it transitions from the | ||||
| FINISHED state to the PREPARING state to transmit the | ||||
| HelloRequest. When the client receives a HelloRequest it | ||||
| transitions from FINISHED to PREPARING to transmit the | ||||
| ClientHello. | ||||
| 4.2.4.1. Timer Values | 4.2.4.1. Timer Values | |||
| Timer value choices are a local matter. Implementations SHOULD | Though timer value choices are the choice of the | |||
| use an initial timer value of 500 ms and double the value at | implementation, mishandling of the timer can lead to serious | |||
| each retransmission, up to twice the TCP maximum segment | congestion problems, for example if many instances of a DTLS | |||
| lifetime [TCP] (if the recommendations in [TCP] are followed, | time out early and retransmit too quickly on a congested link. | |||
| this will be 240 seconds). Implementations SHOULD start the | Implementations SHOULD use an initial timer value of 1 second | |||
| timer value at the initial value with each new flight of | (the minimum defined in RFC 2988 [RFC2988]) and double the | |||
| messages. | value at each retransmission, up to no less than the the RFC | |||
| 2988 maximum of 60 seconds. Note that we recommend a 1 second | ||||
| timer rather than the 3 second RFC 2988 default in order to | ||||
| improve latency for time-sensitive applications. Because DTLS | ||||
| only uses retransmission for handshake and not dataflow, the | ||||
| effect on congestion should be minimal. | ||||
| Implementations SHOULD retain the current timer value until | ||||
| a transmission without loss occurs, at which time the value | ||||
| may be reset to the initial value. After a long period of | ||||
| idleness, no less than 10 times the current timer value, | ||||
| implementations may reset the timer to the initial value. One | ||||
| situation where this might occur is when a rehandshake is used | ||||
| after substantial data transfer. | ||||
| 4.2.5. ChangeCipherSpec | 4.2.5. ChangeCipherSpec | |||
| As with TLS, the ChangeCipherSpec message is not technically a | As with TLS, the ChangeCipherSpec message is not technically a | |||
| handshake message but MUST be treated as part of the same | handshake message but MUST be treated as part of the same | |||
| flight as the associated Finished message for the purposes of | flight as the associated Finished message for the purposes of | |||
| timeout and retransmission. | timeout and retransmission. | |||
| 4.2.6. Finished messages | 4.2.6. Finished messages | |||
| Finished messages have the same format as in TLS. However, in | Finished messages have the same format as in TLS. However, in | |||
| order to remove sensitivity to fragmentation, the Finished MAC | order to remove sensitivity to fragmentation, the Finished MAC | |||
| MUST be computed as if each handshake message had been sent as | MUST be computed as if each handshake message had been sent as | |||
| a single fragment. Note that in cases where the cookie | a single fragment. Note that in cases where the cookie | |||
| exchange is used, the initial ClientHello and | exchange is used, the initial ClientHello and | |||
| HelloVerifyRequest MUST BE included in the Finished MAC. | HelloVerifyRequest MUST NOT included in the Finished MAC. | |||
| 4.2.7. Alert Messages | 4.2.7. Alert Messages | |||
| Note that Alert messages are not retransmitted at all, even | Note that Alert messages are not retransmitted at all, even | |||
| when they occur in the context of a handshake. However, a DTLS | when they occur in the context of a handshake. However, a DTLS | |||
| implementation SHOULD generate a new alert message if the | implementation SHOULD generate a new alert message if the | |||
| offending record is received again (e.g., as a retransmitted | offending record is received again (e.g., as a retransmitted | |||
| handshake message). | handshake message). Implementations SHOULD detect when a peer | |||
| is persistently sending bad messages and terminate the local | ||||
| connection state after such misbehavior is detected. | ||||
| A.1Summary of new syntax | A.1Summary of new syntax | |||
| This section includes specifications for the data structures | This section includes specifications for the data structures | |||
| that have changed between TLS 1.1 and DTLS. | that have changed between TLS 1.1 and DTLS. | |||
| 4.2. Record Layer | 4.2. Record Layer | |||
| struct { | struct { | |||
| ContentType type; | ContentType type; | |||
| ProtocolVersion version; | ProtocolVersion version; | |||
| uint16 epoch; // New field | uint16 epoch; // New field | |||
| uint48 sequence_number; // New field | uint48 sequence_number; // New field | |||
| uint16 length; | uint16 length; | |||
| skipping to change at page 22, line 11 ¶ | skipping to change at page 22, line 31 ¶ | |||
| struct { | struct { | |||
| ProtocolVersion client_version; | ProtocolVersion client_version; | |||
| Random random; | Random random; | |||
| SessionID session_id; | SessionID session_id; | |||
| opaque cookie<0..32>; // New field | opaque cookie<0..32>; // New field | |||
| CipherSuite cipher_suites<2..2^16-1>; | CipherSuite cipher_suites<2..2^16-1>; | |||
| CompressionMethod compression_methods<1..2^8-1>; | CompressionMethod compression_methods<1..2^8-1>; | |||
| } ClientHello; | } ClientHello; | |||
| struct { | struct { | |||
| Cookie cookie<0..32>; | opaque cookie<0..32>; | |||
| } HelloVerifyRequest; | } HelloVerifyRequest; | |||
| 5. Security Considerations | 5. Security Considerations | |||
| This document describes a variant of TLS 1.1 and therefore | This document describes a variant of TLS 1.1 and therefore | |||
| most of the security considerations are the same as those of | most of the security considerations are the same as those of | |||
| TLS 1.1 [TLS11], described in Appendices D, E, and F. | TLS 1.1 [TLS11], described in Appendices D, E, and F. | |||
| The primary additional security consideration raised by DTLS | The primary additional security consideration raised by DTLS | |||
| is that of denial of service. DTLS includes a cookie exchange | is that of denial of service. DTLS includes a cookie exchange | |||
| designed to protect against denial of service. However, | designed to protect against denial of service. However, | |||
| implementations which do not use this cookie exchange are | implementations which do not use this cookie exchange are | |||
| still vulnerable to DoS. In particular, DTLS servers which do | still vulnerable to DoS. In particular, DTLS servers which do | |||
| not use the cookie exchange may be used as attack amplifiers | not use the cookie exchange may be used as attack amplifiers | |||
| even if they themselves are not experiencing DoS. Therefore | even if they themselves are not experiencing DoS. Therefore | |||
| DTLS servers SHOULD use the cookie exchange unless there is | DTLS servers SHOULD use the cookie exchange unless there is | |||
| good reason to believe that amplification is not a threat in | good reason to believe that amplification is not a threat in | |||
| their environment. | their environment. Clients MUST be prepared to do a cookie | |||
| exchange with every handshake. | ||||
| 6. IANA Considerations | 6. IANA Considerations | |||
| This document uses the same identifier space as TLS [TLS11], | This document uses the same identifier space as TLS [TLS11], | |||
| so no new IANA registries are required. When new identifiers | so no new IANA registries are required. When new identifiers | |||
| are assigned for TLS, authors MUST specify whether they are | are assigned for TLS, authors MUST specify whether they are | |||
| suitable for DTLS. | suitable for DTLS. | |||
| This document defines a new handshake message, | This document defines a new handshake message, | |||
| hello_verify_request, whose value is to be allocated from the | hello_verify_request, whose value is to be allocated from the | |||
| TLS HandshakeType registry defined in [TLS11]. The value "3" | TLS HandshakeType registry defined in [TLS11]. The value "3" | |||
| is suggested. | is suggested. | |||
| References | References | |||
| Normative References | Normative References | |||
| [RFC1191] Mogul, J. C., Deering, S.E., "Path MTU Discovery", | [RFC1191] Mogul, J. C., Deering, S.E., "Path MTU Discovery", | |||
| RFC 1191, November 1990. | RFC 1191, November 1990. | |||
| [RFC1981] J. McCann, S. Deering, J. Mogul, "Path MTU Discovery | ||||
| for IP version 6", RFC1981, August 1996. | ||||
| [RFC2401] Kent, S., Atkinson, R., "Security Architecture for the | [RFC2401] Kent, S., Atkinson, R., "Security Architecture for the | |||
| Internet Protocol", RFC2401, November 1998. | Internet Protocol", RFC2401, November 1998. | |||
| [RFC2988] Paxson, V., Allman, M., "Computing TCP's Retransmission | ||||
| Timer", RFC 2988, November 2000. | ||||
| [TCP] Postel, J., "Transmission Control Protocol", | [TCP] Postel, J., "Transmission Control Protocol", | |||
| RFC 793, September 1981. | RFC 793, September 1981. | |||
| [TLS11] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1", | [TLS11] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1", | |||
| draft-ietf-tls-rfc2246-bis-05.txt, July 2003. | draft-ietf-tls-rfc2246-bis-05.txt, July 2003. | |||
| Informative References | Informative References | |||
| [AESCACHE] Bernstein, D.J., "Cache-timing attacks on AES" | ||||
| http://cr.yp.to/antiforgery/cachetiming-20050414.pdf. | ||||
| [AH] Kent, S., and Atkinson, R., "IP Authentication Header", | [AH] Kent, S., and Atkinson, R., "IP Authentication Header", | |||
| RFC 2402, November 1998. | RFC 2402, November 1998. | |||
| [DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram | [DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram | |||
| Congestion Control Protocol", draft-ietf-dccp-spec-11.txt, | Congestion Control Protocol", draft-ietf-dccp-spec-11.txt, | |||
| 10 March 2005 | 10 March 2005 | |||
| [DNS] Mockapetris, P.V., "Domain names - implementation and | [DNS] Mockapetris, P.V., "Domain names - implementation and | |||
| specification", RFC 1035, November 1987. | specification", RFC 1035, November 1987. | |||
| skipping to change at page 23, line 47 ¶ | skipping to change at page 24, line 30 ¶ | |||
| [PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management | [PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management | |||
| Protocol", RFC 2521, March 1999. | Protocol", RFC 2521, March 1999. | |||
| [POP] Myers, J., and Rose, M., "Post Office Protocol - | [POP] Myers, J., and Rose, M., "Post Office Protocol - | |||
| Version 3", RFC 1939, May 1996. | Version 3", RFC 1939, May 1996. | |||
| [REQ] Bradner, S., "Key words for use in RFCs to Indicate | [REQ] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [SCTP] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, | ||||
| T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson, | ||||
| Stream Control Transmission Protocol", RFC 2960, | ||||
| October 2000. | ||||
| [SIP] Rosenberg, J., Schulzrinne, Camarillo, G., Johnston, A., | [SIP] Rosenberg, J., Schulzrinne, Camarillo, G., Johnston, A., | |||
| Peterson, J., Sparks, R., Handley, M., Schooler, E., | Peterson, J., Sparks, R., Handley, M., Schooler, E., | |||
| "SIP: Session Initiation Protocol", RFC 3261, | "SIP: Session Initiation Protocol", RFC 3261, | |||
| June 2002. | June 2002. | |||
| [TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", | [TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", | |||
| RFC 2246, January 1999. | RFC 2246, January 1999. | |||
| [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", | [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", | |||
| draft-bellovin-useipsec-02.txt, October 2003 | draft-bellovin-useipsec-02.txt, October 2003 | |||
| skipping to change at page 24, line 15 ¶ | skipping to change at page 25, line 4 ¶ | |||
| "SIP: Session Initiation Protocol", RFC 3261, | "SIP: Session Initiation Protocol", RFC 3261, | |||
| June 2002. | June 2002. | |||
| [TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", | [TLS] Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", | |||
| RFC 2246, January 1999. | RFC 2246, January 1999. | |||
| [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", | [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", | |||
| draft-bellovin-useipsec-02.txt, October 2003 | draft-bellovin-useipsec-02.txt, October 2003 | |||
| Authors' Address | Authors' Address | |||
| Eric Rescorla <ekr@rtfm.com> | Eric Rescorla <ekr@rtfm.com> | |||
| RTFM, Inc. | RTFM, Inc. | |||
| 2064 Edgewood Drive | 2064 Edgewood Drive | |||
| Palo Alto, CA 94303 | Palo Alto, CA 94303 | |||
| Nagendra Modadugu <nagendra@cs.stanford.edu> | Nagendra Modadugu <nagendra@cs.stanford.edu> | |||
| Computer Science Department | Computer Science Department | |||
| 353 Serra Mall | 353 Serra Mall | |||
| Stanford University | Stanford University | |||
| Stanford, CA 94305 | Stanford, CA 94305 | |||
| Acknowledgements | Acknowledgements | |||
| The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ | The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ | |||
| Housley, Constantine Sapuntzakis, and Hovav Shacham for | Housley, Constantine Sapuntzakis, and Hovav Shacham for | |||
| discussions and comments on the design of DTLS. Thanks to the | discussions and comments on the design of DTLS. Thanks to the | |||
| anonymous NDSS reviewers of our original NDSS paper on DTLS | anonymous NDSS reviewers of our original NDSS paper on DTLS | |||
| [DTLS] for their comments. Also, thanks to Steve Kent for | [DTLS] for their comments. Also, thanks to Steve Kent for | |||
| feedback that helped clarify many points. The section on PMTU | feedback that helped clarify many points. The section on PMTU | |||
| was cribbed from the DCCP specification [DCCP]. Pasi Eronen | was cribbed from the DCCP specification [DCCP]. Pasi Eronen | |||
| provided a detailed review of this specification. | provided a detailed review of this specification. Helpful | |||
| comments on the document were also received from Mark Allman, | ||||
| Jari Arkko, Joel Halpern, Ted Hardie and Allison Mankin. | ||||
| Full Copyright Statement | Full Copyright Statement | |||
| The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
| Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
| pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
| this document or the extent to which any license under such rights | 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 | might or might not be available; nor does it represent that it has | |||
| made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
| on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
| End of changes. 39 change blocks. | ||||
| 91 lines changed or deleted | 160 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||