| < draft-ietf-dnsop-cookies-07.txt | draft-ietf-dnsop-cookies-10.txt > | |||
|---|---|---|---|---|
| INTERNET-DRAFT Donald Eastlake | INTERNET-DRAFT Donald Eastlake | |||
| Intended Status: Proposed Standard Huawei | Intended Status: Proposed Standard Huawei | |||
| Mark Andrews | Mark Andrews | |||
| ISC | ISC | |||
| Expires: May 1, 2016 November 2, 2015 | Expires: October 4, 2016 April 5, 2016 | |||
| Domain Name System (DNS) Cookies | Domain Name System (DNS) Cookies | |||
| <draft-ietf-dnsop-cookies-07.txt> | <draft-ietf-dnsop-cookies-10.txt> | |||
| Abstract | Abstract | |||
| DNS cookies are a lightweight DNS transaction security mechanism that | DNS cookies are a lightweight DNS transaction security mechanism that | |||
| provides limited protection to DNS servers and clients against a | provides limited protection to DNS servers and clients against a | |||
| variety of increasingly common denial-of-service and amplification / | variety of increasingly common denial-of-service and amplification / | |||
| forgery or cache poisoning attacks by off-path attackers. DNS Cookies | forgery or cache poisoning attacks by off-path attackers. DNS Cookies | |||
| are tolerant of NAT, NAT-PT, and anycast and can be incrementally | are tolerant of NAT, NAT-PT, and anycast and can be incrementally | |||
| deployed. | deployed. (Since DNS Cookies are only returned to the IP address from | |||
| which they were originally received, they cannot be used to generally | ||||
| track Internet users.) | ||||
| Status of This Document | Status of This Document | |||
| This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Distribution of this document is unlimited. Comments should be sent | Distribution of this document is unlimited. Comments should be sent | |||
| to the author or the DNSEXT mailing list <dnsext@ietf.org>. | to the author or the DNSEXT mailing list <dnsext@ietf.org>. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| skipping to change at page 2, line 36 ¶ | skipping to change at page 2, line 36 ¶ | |||
| 4.2 Server Cookie.........................................11 | 4.2 Server Cookie.........................................11 | |||
| 5. DNS Cookies Protocol Specification.....................12 | 5. DNS Cookies Protocol Specification.....................12 | |||
| 5.1 Originating Requests..................................12 | 5.1 Originating Requests..................................12 | |||
| 5.2 Responding to Request.................................12 | 5.2 Responding to Request.................................12 | |||
| 5.2.1 No Opt RR or No COOKIE OPT option...................13 | 5.2.1 No Opt RR or No COOKIE OPT option...................13 | |||
| 5.2.2 Malformed COOKIE OPT option.........................13 | 5.2.2 Malformed COOKIE OPT option.........................13 | |||
| 5.2.3 Only a Client Cookie................................13 | 5.2.3 Only a Client Cookie................................13 | |||
| 5.2.4 A Client Cookie and an Invalid Server Cookie........14 | 5.2.4 A Client Cookie and an Invalid Server Cookie........14 | |||
| 5.2.5 A Client Cookie and a Valid Server Cookie...........14 | 5.2.5 A Client Cookie and a Valid Server Cookie...........14 | |||
| 5.3 Processing Responses..................................14 | 5.3 Processing Responses..................................15 | |||
| 5.4 QUERYing for a Server Cookie..........................15 | 5.4 QUERYing for a Server Cookie..........................15 | |||
| 5.5 Client and Server Secret Rollover.....................16 | ||||
| 6. NAT Considerations and AnyCast Server Considerations...17 | 6. NAT Considerations and AnyCast Server Considerations...17 | |||
| 7. Deployment.............................................19 | ||||
| 8. IANA Considerations....................................20 | ||||
| 9. Security Considerations................................21 | 7. Operational and Deployment Considerations..............19 | |||
| 9.1 Cookie Algorithm Considerations.......................21 | 7.1 Client and Server Secret Rollover.....................19 | |||
| 7.2 Counters..............................................20 | ||||
| 10. Implementation Considerations.........................23 | 8. IANA Considerations....................................21 | |||
| Normative References......................................24 | 9. Security Considerations................................22 | |||
| Informative References....................................24 | 9.1 Cookie Algorithm Considerations.......................23 | |||
| Acknowledgements..........................................26 | ||||
| Appendix A: Example Client Cookie Algorithms..............27 | 10. Implementation Considerations.........................24 | |||
| A.1 A Simple Algorithm....................................27 | ||||
| A.2 A More Complex Algorithm..............................27 | Normative References......................................25 | |||
| Informative References....................................25 | ||||
| Acknowledgements..........................................27 | ||||
| INTERNET-DRAFT DNS Cookies | INTERNET-DRAFT DNS Cookies | |||
| Table of Contents (continued) | Table of Contents (continued) | |||
| Appendix B: Example Server Cookie Algorithms..............28 | Appendix A: Example Client Cookie Algorithms..............28 | |||
| B.1 A Simple Algorithm....................................28 | A.1 A Simple Algorithm....................................28 | |||
| B.2 A More Complex Algorithm..............................28 | A.2 A More Complex Algorithm..............................28 | |||
| Author's Address..........................................30 | Appendix B: Example Server Cookie Algorithms..............29 | |||
| B.1 A Simple Algorithm....................................29 | ||||
| B.2 A More Complex Algorithm..............................29 | ||||
| Author's Address..........................................31 | ||||
| INTERNET-DRAFT DNS Cookies | INTERNET-DRAFT DNS Cookies | |||
| 1. Introduction | 1. Introduction | |||
| As with many core Internet protocols, the Domain Name System (DNS) | As with many core Internet protocols, the Domain Name System (DNS) | |||
| was originally designed at a time when the Internet had only a small | was originally designed at a time when the Internet had only a small | |||
| pool of trusted users. As the Internet has grown exponentially to a | pool of trusted users. As the Internet has grown exponentially to a | |||
| global information utility, the DNS has increasingly been subject to | global information utility, the DNS has increasingly been subject to | |||
| abuse. | abuse. | |||
| This document describes DNS cookies, a lightweight DNS transaction | This document describes DNS cookies, a lightweight DNS transaction | |||
| security mechanism specified as an OPT [RFC6891] option. The DNS | security mechanism specified as an OPT [RFC6891] option. The DNS | |||
| cookies mechanism provides limited protection to DNS servers and | cookies mechanism provides limited protection to DNS servers and | |||
| clients against a variety of increasingly common abuses by off-path | clients against a variety of increasingly common abuses by off-path | |||
| attackers. It is compatible with and can be used in conjunction with | attackers. It is compatible with and can be used in conjunction with | |||
| other DNS transaction forgery resistance measures such as those in | other DNS transaction forgery resistance measures such as those in | |||
| [RFC5452]. | [RFC5452]. (Since DNS Cookies are only returned to the IP address | |||
| from which they were originally received, they cannot be used to | ||||
| generally track Internet users.) | ||||
| The protection provided by DNS cookies is similar to that provided by | The protection provided by DNS cookies is similar to that provided by | |||
| using TCP for DNS transactions. To bypass the weak protection | using TCP for DNS transactions. To bypass the weak protection | |||
| provided by using TCP requires, among other things, that an off-path | provided by using TCP requires, among other things, that an off-path | |||
| attacker guessing the 32-bit TCP sequence number in use. To bypass | attacker guess the 32-bit TCP sequence number in use. To bypass the | |||
| the weak protection provided by DNS Cookies requires such an attacker | weak protection provided by DNS Cookies requires such an attacker to | |||
| to guess a 64-bit pseudo-random "cookie" quantity. Where DNS Cookies | guess a 64-bit pseudo-random "cookie" quantity. Where DNS Cookies are | |||
| are not available but TCP is, falling back to using TCP is | not available but TCP is, falling back to using TCP is reasonable. | |||
| reasonable. | ||||
| If only one party to a DNS transaction supports DNS cookies, the | If only one party to a DNS transaction supports DNS cookies, the | |||
| mechanism does not provide a benefit or significantly interfere; but, | mechanism does not provide a benefit or significantly interfere; but, | |||
| if both support it, the additional security provided is automatically | if both support it, the additional security provided is automatically | |||
| available. | available. | |||
| The DNS cookies mechanism is designed to work in the presence of NAT | The DNS cookies mechanism is designed to work in the presence of NAT | |||
| and NAT-PT boxes and guidance is provided herein on supporting the | and NAT-PT boxes and guidance is provided herein on supporting the | |||
| DNS cookies mechanism in anycast servers. | DNS cookies mechanism in anycast servers. | |||
| skipping to change at page 4, line 54 ¶ | skipping to change at page 5, line 4 ¶ | |||
| mechanism provides some protection. | mechanism provides some protection. | |||
| Section 3 describes existing DNS security mechanisms and why they are | Section 3 describes existing DNS security mechanisms and why they are | |||
| not adequate substitutes for DNS cookies. | not adequate substitutes for DNS cookies. | |||
| Section 4 describes the COOKIE OPT option. | Section 4 describes the COOKIE OPT option. | |||
| Section 5 provides a protocol description. | Section 5 provides a protocol description. | |||
| Section 6 discusses some NAT and anycast related DNS Cookies design | Section 6 discusses some NAT and anycast related DNS Cookies design | |||
| considerations. | ||||
| INTERNET-DRAFT DNS Cookies | INTERNET-DRAFT DNS Cookies | |||
| considerations. | ||||
| Section 7 discusses incremental deployment considerations. | Section 7 discusses incremental deployment considerations. | |||
| Sections 8 and 9 describe IANA and Security Considerations. | Sections 8 and 9 describe IANA and Security Considerations. | |||
| 1.2 Definitions | 1.2 Definitions | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| document are to be interpreted as described in [RFC2119]. | "OPTIONAL" in this document are to be interpreted as described in | |||
| [RFC2119]. | ||||
| "Off-path attacker", for a particular DNS client and server, is | "Off-path attacker", for a particular DNS client and server, is | |||
| defined as an attacker who cannot observe the DNS request and | defined as an attacker who cannot observe the DNS request and | |||
| response messages between that client and server. | response messages between that client and server. | |||
| "Soft state" indicates information learned or derived by a host which | "Soft state" indicates information learned or derived by a host which | |||
| may be discarded when indicated by the policies of that host | may be discarded when indicated by the policies of that host | |||
| but can be later re-instantiated if needed. For example, it | but can be later re-instantiated if needed. For example, it | |||
| could be discarded after a period of time or when storage for | could be discarded after a period of time or when storage for | |||
| caching such data becomes full. If operations requiring that | caching such data becomes full. If operations requiring that | |||
| soft state continue after it has been discarded, it will be | soft state continue after it has been discarded, it will be | |||
| automatically re-generated, albeit at some cost. | automatically re-generated, albeit at some cost. | |||
| "Silently discarded" indicates that there are no DNS protocol message | "Silently discarded" indicates that there are no DNS protocol message | |||
| consequences; however, it is RECOMMENDED that appropriate | consequences. | |||
| network management facilities be included in implementations, | ||||
| such as a counter of the occurrences of each such event type. | ||||
| "IP address" is used herein as a length independent term and includes | "IP address" is used herein as a length independent term and includes | |||
| both IPv4 and IPv6 addresses. | both IPv4 and IPv6 addresses. | |||
| INTERNET-DRAFT DNS Cookies | INTERNET-DRAFT DNS Cookies | |||
| 2. Threats Considered | 2. Threats Considered | |||
| DNS cookies are intended to provide significant but limited | DNS cookies are intended to provide significant but limited | |||
| protection against certain attacks by off-path attackers as described | protection against certain attacks by off-path attackers as described | |||
| skipping to change at page 8, line 28 ¶ | skipping to change at page 8, line 28 ¶ | |||
| forged data and cache poisoning; however, it has the unintended | forged data and cache poisoning; however, it has the unintended | |||
| effect of making some denial-of-service attacks worse because of the | effect of making some denial-of-service attacks worse because of the | |||
| cryptographic computational load it can require and the increased | cryptographic computational load it can require and the increased | |||
| size in DNS response packets that it tends to produce. | size in DNS response packets that it tends to produce. | |||
| 3.2 DNS Message/Transaction Security | 3.2 DNS Message/Transaction Security | |||
| The second form of security that has been added to DNS provides | The second form of security that has been added to DNS provides | |||
| "transaction" security through TSIG [RFC2845] or SIG(0) [RFC2931]. | "transaction" security through TSIG [RFC2845] or SIG(0) [RFC2931]. | |||
| TSIG could provide strong protection against the attacks for which | TSIG could provide strong protection against the attacks for which | |||
| the DNS Cookies mechanism provides weak protection; however, TSIG is | the DNS Cookies mechanism provides weaker protection; however, TSIG | |||
| non-trivial to deploy in the general Internet because of the burdens | is non-trivial to deploy in the general Internet because of the | |||
| it imposes. Among these burdens are pre-agreement and key | burdens it imposes. Among these burdens are pre-agreement and key | |||
| distribution between client and server, keeping track of server side | distribution between client and server, keeping track of server side | |||
| key state, and required time synchronization between client and | key state, and required time synchronization between client and | |||
| server. | server. | |||
| TKEY [RFC2930] can solve the problem of key distribution for TSIG but | TKEY [RFC2930] can solve the problem of key distribution for TSIG but | |||
| some modes of TKEY impose a substantial cryptographic computation | some modes of TKEY impose a substantial cryptographic computation | |||
| load and can be dependent on the deployment of DNS data security (see | load and can be dependent on the deployment of DNS data security (see | |||
| Section 3.1). | Section 3.1). | |||
| SIG(0) [RFC2931] provides less denial of service protection than TSIG | SIG(0) [RFC2931] provides less denial of service protection than TSIG | |||
| skipping to change at page 11, line 9 ¶ | skipping to change at page 11, line 9 ¶ | |||
| / Server Cookie (variable size, 8 to 32 bytes) / | / Server Cookie (variable size, 8 to 32 bytes) / | |||
| / / | / / | |||
| +-+-+-+-... | +-+-+-+-... | |||
| Figure 2. COOKIE Option, Known Server Cookie | Figure 2. COOKIE Option, Known Server Cookie | |||
| INTERNET-DRAFT DNS Cookies | INTERNET-DRAFT DNS Cookies | |||
| 4.1 Client Cookie | 4.1 Client Cookie | |||
| The Client Cookie SHOULD be a pseudo-random function of the server IP | The Client Cookie SHOULD be a pseudo-random function of the client IP | |||
| address and a secret quantity known only to the client. This client | address, the server IP address, and a secret quantity known only to | |||
| secret SHOULD have at least 64 bits of entropy [RFC4086] and be | the client. This client secret SHOULD have at least 64 bits of | |||
| changed periodically (see Section 5.5). The selection of the pseudo- | entropy [RFC4086] and be changed periodically (see Section 7.1). The | |||
| random function is a matter private to the client as only the client | selection of the pseudo-random function is a matter private to the | |||
| needs to recognize its own DNS cookies. | client as only the client needs to recognize its own DNS cookies. | |||
| The client IP address is included so that the Client Cookie cannot be | ||||
| used (1) to track a client if the client IP address changes due to | ||||
| privacy mechanisms or (2) to impersonate the client by some network | ||||
| device that was formerly on path but is no longer on path when the | ||||
| client IP address changes due to mobility. However, if the client IP | ||||
| address is being changed very often, it may be necessary to fix the | ||||
| Client Cookie for a particular server for several requests to avoid | ||||
| undue inefficiency due to retries caused by that server not | ||||
| recognizing the Client Cookie. | ||||
| For further discussion of the Client Cookie field, see Section 5.1. | For further discussion of the Client Cookie field, see Section 5.1. | |||
| For example methods of determining a Client Cookie, see Appendix A. | For example methods of determining a Client Cookie, see Appendix A. | |||
| In order to provide minimal authentication, a client MUST send Client | In order to provide minimal authentication, a client MUST send Client | |||
| Cookies that will usually be different for any two servers at | Cookies that will usually be different for any two servers at | |||
| different IP addresses. | different IP addresses. | |||
| 4.2 Server Cookie | 4.2 Server Cookie | |||
| The Server Cookie SHOULD consist of or include a 64-bit or larger | The Server Cookie SHOULD consist of or include a 64-bit or larger | |||
| pseudo-random function of the request source IP address, the request | pseudo-random function of the request source (client) IP address, a | |||
| Client Cookie, and a secret quantity known only to the server. (See | secret quantity known only to the server, and the request Client | |||
| Section 6 for a discussion of why the Client Cookie is used as input | Cookie. (See Section 6 for a discussion of why the Client Cookie is | |||
| to the Server Cookie but the Server Cookie is not used as an input to | used as input to the Server Cookie but the Server Cookie is not used | |||
| the Client Cookie.) This server secret SHOULD have at least 64 bits | as an input to the Client Cookie.) This server secret SHOULD have at | |||
| of entropy [RFC4086] and be changed periodically (see Section 5.5). | least 64 bits of entropy [RFC4086] and be changed periodically (see | |||
| The selection of the pseudo-random function is a matter private to | Section 7.1). The selection of the pseudo-random function is a | |||
| the server as only the server needs to recognize its own DNS cookies. | matter private to the server as only the server needs to recognize | |||
| its own DNS cookies. | ||||
| For further discussion of the Server Cookie field see Section 5.2. | For further discussion of the Server Cookie field see Section 5.2. | |||
| For example methods of determining a Server Cookie, see Appendix B. | For example methods of determining a Server Cookie, see Appendix B. | |||
| When implemented as recommended, the server need not maintain any | ||||
| cookie related per client state. | ||||
| In order to provide minimal authentication, a server MUST send Server | In order to provide minimal authentication, a server MUST send Server | |||
| Cookies that will usually be different for clients at any two | Cookies that will usually be different for clients at any two | |||
| different IP addresses or with different Client Cookies. | different IP addresses or with different Client Cookies. | |||
| INTERNET-DRAFT DNS Cookies | INTERNET-DRAFT DNS Cookies | |||
| 5. DNS Cookies Protocol Specification | 5. DNS Cookies Protocol Specification | |||
| This section discusses using DNS Cookies in the DNS Protocol. The | This section discusses using DNS Cookies in the DNS Protocol. The | |||
| cycle of originating a request, responding to that request, and | cycle of originating a request, responding to that request, and | |||
| processing the response are covered in Sections 5.1, 5.2, and 5.3. A | processing the response are covered in Sections 5.1, 5.2, and 5.3. A | |||
| de facto extension to QUERY to allow pre-fetching a Server Cookie is | de facto extension to QUERY to allow pre-fetching a Server Cookie is | |||
| specified in Section 5.4. Rollover of the client and server secrets | specified in Section 5.4. Rollover of the client and server secrets | |||
| and transient retention of the old cookie or secret is covered in | and transient retention of the old cookie or secret is covered in | |||
| Section 5.5. | Section 7.1. | |||
| DNS clients and servers SHOULD implement DNS cookies to decrease | DNS clients and servers SHOULD implement DNS cookies to decrease | |||
| their vulnerability to the threats discussed in Section 2. | their vulnerability to the threats discussed in Section 2. | |||
| 5.1 Originating Requests | 5.1 Originating Requests | |||
| A DNS client that implements DNS Cookies includes one DNS COOKIE OPT | A DNS client that implements DNS Cookies includes one DNS COOKIE OPT | |||
| option containing a Client Cookie in every DNS request it sends | option containing a Client Cookie in every DNS request it sends | |||
| unless DNS cookies are disabled. | unless DNS cookies are disabled. | |||
| skipping to change at page 12, line 37 ¶ | skipping to change at page 12, line 37 ¶ | |||
| IP address it uses the longer cookie form and includes that Server | IP address it uses the longer cookie form and includes that Server | |||
| Cookie in the option along with the Client Cookie (Figure 2). | Cookie in the option along with the Client Cookie (Figure 2). | |||
| Otherwise it just sends the shorter form option with a Client Cookie | Otherwise it just sends the shorter form option with a Client Cookie | |||
| (Figure 1). | (Figure 1). | |||
| 5.2 Responding to Request | 5.2 Responding to Request | |||
| The Server Cookie, when it occurs in a COOKIE OPT option in a | The Server Cookie, when it occurs in a COOKIE OPT option in a | |||
| request, is intended to weakly assure the server that the request | request, is intended to weakly assure the server that the request | |||
| came from a client that is both at the source IP address of the | came from a client that is both at the source IP address of the | |||
| request and using the Client Cookie included in the option. This weak | request and using the Client Cookie included in the option. This | |||
| assurance is provided by the Server Cookie that server sent to that | assurance is provided by the Server Cookie that server sent to that | |||
| client in an earlier response appearing as the Server Cookie field in | client in an earlier response appearing as the Server Cookie field in | |||
| the request. | the request. | |||
| At a server where DNS Cookies are not implemented and enabled, | At a server where DNS Cookies are not implemented and enabled, | |||
| presence of a COOKIE OPT option is ignored and the server responds as | presence of a COOKIE OPT option is ignored and the server responds as | |||
| if no COOKIE OPT option had been included in the request. | if no COOKIE OPT option had been included in the request. | |||
| When DNS Cookies are implemented and enabled, there are five | When DNS Cookies are implemented and enabled, there are five | |||
| possibilities: (1) there is no OPT RR at all in the request or there | possibilities: (1) there is no OPT RR at all in the request or there | |||
| is a OPT RR but the the COOKIE OPT option is absent from the OPT RR; | is a OPT RR but the COOKIE OPT option is absent from the OPT RR; (2) | |||
| (2) a COOKIE OPT is present but is not a legal length or otherwise | a COOKIE OPT is present but is not a legal length or otherwise | |||
| malformed; (3) there is a valid length cookie option in the request | malformed; (3) there is a valid length cookie option in the request | |||
| with no Server Cookie; (4) there is a valid length COOKIE OPT in the | with no Server Cookie; (4) there is a valid length COOKIE OPT in the | |||
| request with a Server Cookie but that Server Cookie is invalid; or | request with a Server Cookie but that Server Cookie is invalid; or | |||
| INTERNET-DRAFT DNS Cookies | INTERNET-DRAFT DNS Cookies | |||
| (5) there is a valid length COOKIE OPT in the request with a correct | (5) there is a valid length COOKIE OPT in the request with a correct | |||
| Server Cookie. | Server Cookie. | |||
| The five possibilities are discussed in the subsections below. | The five possibilities are discussed in the subsections below. | |||
| skipping to change at page 13, line 26 ¶ | skipping to change at page 13, line 26 ¶ | |||
| 5.2.1 No Opt RR or No COOKIE OPT option | 5.2.1 No Opt RR or No COOKIE OPT option | |||
| If there is no OPT record or no COOKIE OPT option present in the | If there is no OPT record or no COOKIE OPT option present in the | |||
| request then the server responds to the request as if the server | request then the server responds to the request as if the server | |||
| doesn't implement the COOKIE OPT. | doesn't implement the COOKIE OPT. | |||
| 5.2.2 Malformed COOKIE OPT option | 5.2.2 Malformed COOKIE OPT option | |||
| If the COOKIE OPT is too short to contain a Client Cookie then | If the COOKIE OPT is too short to contain a Client Cookie then | |||
| FORMERR is generated. If the COOKIE OPT is longer than that required | FORMERR is generated. If the COOKIE OPT is longer than that required | |||
| to hold a COOKIE OPT with just a Client Cookie (8) but is shorter | to hold a COOKIE OPT with just a Client Cookie (8 bytes) but is | |||
| that the minimum COOKIE OPT with both a Client and Server Cookie (16) | shorter that the minimum COOKIE OPT with both a Client and Server | |||
| then FORMERR is generated. If the COOKIE OPT is longer than the | Cookie (16 bytes) then FORMERR is generated. If the COOKIE OPT is | |||
| maximum valid COOKIE OPT (40) then a FORMERR is generated. | longer than the maximum valid COOKIE OPT (40 bytes) then a FORMERR is | |||
| generated. | ||||
| In summary, valid cookie lengths are 8 and 16 to 40 inclusive. | In summary, valid cookie lengths are 8 and 16 to 40 inclusive. | |||
| 5.2.3 Only a Client Cookie | 5.2.3 Only a Client Cookie | |||
| Based on server policy, including rate limiting, the server chooses | Based on server policy, including rate limiting, the server chooses | |||
| one of the following: | one of the following: | |||
| (1) Silently discard the request. | (1) Silently discard the request. | |||
| (2) Send a BADCOOKIE error response. | (2) Send a BADCOOKIE error response. | |||
| (3) Process the request and provide a normal response. The RCODE is | (3) Process the request and provide a normal response. The RCODE is | |||
| NOERROR unless some non-cookie error occurs in processing the | NOERROR unless some non-cookie error occurs in processing the | |||
| request. | request. | |||
| If the server responds, choosing 2 or 3 above, it SHALL generate its | If the server responds, choosing 2 or 3 above, it SHALL generate its | |||
| own COOKIE OPT containing both the Client Cookie copied from the | own COOKIE OPT containing both the Client Cookie copied from the | |||
| request and a Server Cookie it has generated and adds this COOKIE OPT | request and a Server Cookie it has generated and adds this COOKIE OPT | |||
| to the response's OPT record. Servers MUST, at least occasionally, | to the response's OPT record. Servers MUST, at least occasionally, | |||
| respond to such requests to inform the client of the correct Server | ||||
| INTERNET-DRAFT DNS Cookies | INTERNET-DRAFT DNS Cookies | |||
| respond to such requests to inform the client of the correct Server | ||||
| Cookie. This is necessary so that such a client can bootstrap to the | Cookie. This is necessary so that such a client can bootstrap to the | |||
| weakly secure state where requests and responses have recognized | more secure state where requests and responses have recognized Server | |||
| Server Cookies and Client Cookies. A server is not expected to | Cookies and Client Cookies. A server is not expected to maintain per | |||
| maintain per client state to achieve this. For example, it could | client state to achieve this. For example, it could respond to every | |||
| respond to every Nth request across all clients. | Nth request across all clients. | |||
| If the request was received over TCP, the server SHOULD take the weak | If the request was received over TCP, the server SHOULD take the | |||
| authentication provided by the use of TCP into account and SHOULD | authentication provided by the use of TCP into account and SHOULD | |||
| choose 3. In this case, if the server is not willing to accept the | choose 3. In this case, if the server is not willing to accept the | |||
| weak security provided by TCP as a substitute for the weak security | security provided by TCP as a substitute for the security provided by | |||
| provided by DNS Cookies but instead chooses 2, there is some danger | DNS Cookies but instead chooses 2, there is some danger of an | |||
| of an indefinite loop of retries (see Section 5.3). | indefinite loop of retries (see Section 5.3). | |||
| 5.2.4 A Client Cookie and an Invalid Server Cookie | 5.2.4 A Client Cookie and an Invalid Server Cookie | |||
| The server examines the Server Cookie to determine if it is a valid | The server examines the Server Cookie to determine if it is a valid | |||
| Server Cookie it has generated. This examination will result in a | Server Cookie it has generated. This determination normally involves | |||
| determination of whether the Server Cookie is valid or not. If the | re-calculating the Server Cookie (or the hash part thereof) based on | |||
| the server secret (or the previous server secret if it has just | ||||
| changed), the received Client Cookie, the client IP address, and | ||||
| possibly other fields -- see Appendix B.2 for an example. If the | ||||
| cookie is invalid, it can be because of a stale Server Cookie, or a | cookie is invalid, it can be because of a stale Server Cookie, or a | |||
| client's IP address or Client Cookie changing without the DNS server | client's IP address or Client Cookie changing without the DNS server | |||
| being aware, or an anycast server cluster that is not consistently | being aware, or an anycast server cluster that is not consistently | |||
| configured, or an attempt to spoof the client. | configured, or an attempt to spoof the client. | |||
| The server SHALL process the request as if the invalid Server Cookie | The server SHALL process the request as if the invalid Server Cookie | |||
| was not present as described in Section 5.2.3. | was not present as described in Section 5.2.3. | |||
| 5.2.5 A Client Cookie and a Valid Server Cookie | 5.2.5 A Client Cookie and a Valid Server Cookie | |||
| When a valid Server Cookie is present in the request the server can | When a valid Server Cookie is present in the request the server can | |||
| assume that the request is from a client that it has talked to before | assume that the request is from a client that it has talked to before | |||
| and defensive measures for spoofed UDP requests, if any, are no | and defensive measures for spoofed UDP requests, if any, are no | |||
| longer required. | longer required. | |||
| The server SHALL process the request and include a COOKIE OPT in the | The server SHALL process the request and include a COOKIE OPT in the | |||
| response by (a) copying the complete COOKIE OPT from the request or | response by (a) copying the complete COOKIE OPT from the request or | |||
| (b) generating a new COOKIE OPT containing both the Client Cookie | (b) generating a new COOKIE OPT containing both the Client Cookie | |||
| copied from the request and a valid Server Cookie it has generated. | copied from the request and a valid Server Cookie it has generated. | |||
| INTERNET-DRAFT DNS Cookies | ||||
| 5.3 Processing Responses | 5.3 Processing Responses | |||
| The Client Cookie, when it occurs in a COOKIE OPT option in a DNS | The Client Cookie, when it occurs in a COOKIE OPT option in a DNS | |||
| reply, is intended to weakly assure the client that the reply came | reply, is intended to weakly assure the client that the reply came | |||
| from a server at the source IP address used in the response packet | from a server at the source IP address used in the response packet | |||
| because the Client Cookie value is the value that client would send | because the Client Cookie value is the value that client would send | |||
| INTERNET-DRAFT DNS Cookies | ||||
| to that server in a request. In a DNS reply with multiple COOKIE OPT | to that server in a request. In a DNS reply with multiple COOKIE OPT | |||
| options, all but the first (the one closest to the DNS Header) are | options, all but the first (the one closest to the DNS Header) are | |||
| ignored. | ignored. | |||
| A DNS client where DNS cookies are implemented and enabled examines | A DNS client where DNS cookies are implemented and enabled examines | |||
| the response for DNS cookies and MUST discard the response if it | the response for DNS cookies and MUST discard the response if it | |||
| contains an illegal COOKIE OPT option length or an incorrect Client | contains an illegal COOKIE OPT option length or an incorrect Client | |||
| Cookie value. If the COOKIE OPT option Client Cookie is correct, the | Cookie value. If the client is expecting the response to contain a | |||
| client caches the Server Cookie provided even if the response is an | COOKIE OPT and it is missing the response MUST be discarded. If the | |||
| error response (RCODE non-zero). | COOKIE OPT option Client Cookie is correct, the client caches the | |||
| Server Cookie provided even if the response is an error response | ||||
| (RCODE non-zero). | ||||
| If the reply extended RCODE is BADCOOKIE and the Client Cookie | If the reply extended RCODE is BADCOOKIE and the Client Cookie | |||
| matches what was sent, it means that the server was unwilling to | matches what was sent, it means that the server was unwilling to | |||
| process the request because it did not have the correct Server Cookie | process the request because it did not have the correct Server Cookie | |||
| in it. The client SHOULD retry the request using the new Server | in it. The client SHOULD retry the request using the new Server | |||
| Cookie from the response. Repeated BADCOOKIE responses to requests | Cookie from the response. Repeated BADCOOKIE responses to requests | |||
| that use the Server Cookie provided in the previous response may be | that use the Server Cookie provided in the previous response may be | |||
| an indication that the shared secrets / secret generation method in | an indication that the shared secrets / secret generation method in | |||
| an anycast cluster of servers are inconsistent. If the reply to a | an anycast cluster of servers are inconsistent. If the reply to a | |||
| retried request with a fresh Server Cookie is BADCOOKIE, the client | retried request with a fresh Server Cookie is BADCOOKIE, the client | |||
| SHOULD retry using TCP as the transport since the server will likely | SHOULD retry using TCP as the transport since the server will likely | |||
| process the request normally based on the weak security provided by | process the request normally based on the security provided by TCP | |||
| TCP (see Section 5.2.3). | (see Section 5.2.3). | |||
| If the RCODE is some value other than BADCOOKIE, including zero, the | If the RCODE is some value other than BADCOOKIE, including zero, the | |||
| further processing of the response proceeds normally. | further processing of the response proceeds normally. | |||
| 5.4 QUERYing for a Server Cookie | 5.4 QUERYing for a Server Cookie | |||
| In many cases a client will learn the Server Cookie for a server as | In many cases a client will learn the Server Cookie for a server as | |||
| the side effect of another transaction; however, there may be times | the side effect of another transaction; however, there may be times | |||
| when this is not desirable. Therefore a means is provided for | when this is not desirable. Therefore a means is provided for | |||
| obtaining a Server Cookie through an extension to the QUERY opcode | obtaining a Server Cookie through an extension to the QUERY opcode | |||
| for which opcode most existing implementations require that QDCOUNT | for which opcode most existing implementations require that QDCOUNT | |||
| be one (see Section 4.1.2 of [RFC1035]). | be one (see Section 4.1.2 of [RFC1035]). | |||
| For servers with DNS Cookies enabled, the QUERY opcode behavior is | For servers with DNS Cookies enabled, the QUERY opcode behavior is | |||
| extended to support queries with a empty question section (QDCOUNT | extended to support queries with an empty question section (QDCOUNT | |||
| zero) provided that an OPT record is present with a COOKIE option. | zero) provided that an OPT record is present with a COOKIE option. | |||
| Such servers will reply with an empty answer section and a COOKIE | Such servers will reply with an empty answer section and a COOKIE | |||
| INTERNET-DRAFT DNS Cookies | ||||
| option giving the Client Cookie provided in the query and a valid | option giving the Client Cookie provided in the query and a valid | |||
| Server Cookie. | Server Cookie. | |||
| If such a query provided just a Client Cookie and no Server Cookie, | If such a query provided just a Client Cookie and no Server Cookie, | |||
| the response SHALL have the RCODE NOERROR. | the response SHALL have the RCODE NOERROR. | |||
| This mechanism can also be used to confirm/re-establish a existing | This mechanism can also be used to confirm/re-establish an existing | |||
| Server Cookie by sending a cached Server Cookie with the Client | Server Cookie by sending a cached Server Cookie with the Client | |||
| INTERNET-DRAFT DNS Cookies | ||||
| Cookie. In this case the response SHALL have the RCODE BADCOOKIE if | Cookie. In this case the response SHALL have the RCODE BADCOOKIE if | |||
| the Server Cookie sent with the query was invalid and the RCODE | the Server Cookie sent with the query was invalid and the RCODE | |||
| NOERROR if it was valid. | NOERROR if it was valid. | |||
| Servers which don't support the COOKIE option will normally send | Servers which don't support the COOKIE option will normally send | |||
| FORMERR in response to such a query, though REFUSED, NOTIMP, and | FORMERR in response to such a query, though REFUSED, NOTIMP, and | |||
| NOERROR without a COOKIE option are also possible in such responses. | NOERROR without a COOKIE option are also possible in such responses. | |||
| 5.5 Client and Server Secret Rollover | ||||
| The longer a secret is used, the higher the probability it has been | ||||
| compromised. Thus clients and servers MUST NOT continue to use the | ||||
| same secret in new requests and responses for more than 36 days and | ||||
| SHOULD NOT continue to do so for more than 26 hours. These values are | ||||
| chosen to assure that a secret will not be used for longer than about | ||||
| a month and normally no longer than one day. The odd values are to | ||||
| allow for long holiday weekends and daylight savings time shifts and | ||||
| the like while still staying within the limits. | ||||
| Many clients rolling over their secret at the same time could briefly | ||||
| increase server traffic and exactly predictable rollover times for | ||||
| clients or servers might facilitate guessing attacks. For example, an | ||||
| attacker might increase the priority of attacking secrets they | ||||
| believe will be in effect for an extended period of time. To avoid | ||||
| rollover synchronization and predictability, it is RECOMMENDED that | ||||
| pseudorandom jitter in the range of plus zero to minus at least 40% | ||||
| be applied to the time until a scheduled rollover of a DNS cookie | ||||
| secret. | ||||
| It is RECOMMENDED that a client keep the Client Cookie it is | ||||
| expecting in a reply associated with the outstanding request to avoid | ||||
| rejection of replies due to a bad Client Cookie right after a change | ||||
| in the client secret. It is RECOMMENDED that a server retain its | ||||
| previous secret for a period of time not less than 1 second or more | ||||
| than 5 minutes, after a change in its secret, and consider requests | ||||
| with Server Cookies based on its previous secret to have a correct | ||||
| Server Cookie during that time. | ||||
| When a server or client starts receiving an increased level of | ||||
| requests with bad server cookies or replies with bad client cookies, | ||||
| it would be reasonable for it to believe it is likely under attack | ||||
| and it should consider a more frequent rollover of its secret. More | ||||
| rapid rollover decreases the benefit to a cookie guessing attacker if | ||||
| they succeed in guessing a cookie. | ||||
| INTERNET-DRAFT DNS Cookies | INTERNET-DRAFT DNS Cookies | |||
| 6. NAT Considerations and AnyCast Server Considerations | 6. NAT Considerations and AnyCast Server Considerations | |||
| In the Classic Internet, DNS Cookies could simply be a pseudo-random | In the Classic Internet, DNS Cookies could simply be a pseudo-random | |||
| function of the client IP address and a server secret or the server | function of the client IP address and a server secret or the server | |||
| IP address and a client secret. You would want to compute the Server | IP address and a client secret. You would want to compute the Server | |||
| Cookie that way, so a client could cache its Server Cookie for a | Cookie that way, so a client could cache its Server Cookie for a | |||
| particular server for an indefinitely amount of time and the server | particular server for an indefinite amount of time and the server | |||
| could easily regenerate and check it. You could consider the Client | could easily regenerate and check it. You could consider the Client | |||
| Cookie to be a weak client signature over the server IP address that | Cookie to be a weak client signature over the server IP address that | |||
| the client checks in replies and you could extend this weak signature | the client checks in replies and you could extend this signature to | |||
| to cover the request ID, for example, or any other information that | cover the request ID, for example, or any other information that is | |||
| is returned unchanged in the reply. | returned unchanged in the reply. | |||
| But we have this reality called NAT [RFC3022], Network Address | But we have this reality called NAT [RFC3022], Network Address | |||
| Translation (including, for the purposes of this document, NAT-PT, | Translation (including, for the purposes of this document, NAT-PT, | |||
| Network Address and Protocol Translation, which has been declared | Network Address and Protocol Translation, which has been declared | |||
| Historic [RFC4966]). There is no problem with DNS transactions | Historic [RFC4966]). There is no problem with DNS transactions | |||
| between clients and servers behind a NAT box using local IP | between clients and servers behind a NAT box using local IP | |||
| addresses. Nor is there a problem with NAT translation of internal | addresses. Nor is there a problem with NAT translation of internal | |||
| addresses to external addresses or translations between IPv4 and IPv6 | addresses to external addresses or translations between IPv4 and IPv6 | |||
| addresses, as long as the address mapping is relatively stable. | addresses, as long as the address mapping is relatively stable. | |||
| Should the external IP address an internal client is being mapped to | Should the external IP address an internal client is being mapped to | |||
| skipping to change at page 18, line 42 ¶ | skipping to change at page 18, line 42 ¶ | |||
| are not unduly burdensome. (When such anycast-accessed servers act | are not unduly burdensome. (When such anycast-accessed servers act | |||
| as recursive servers or otherwise act as clients they normally use a | as recursive servers or otherwise act as clients they normally use a | |||
| different unique address to source their requests to avoid confusion | different unique address to source their requests to avoid confusion | |||
| in the delivery of responses.) | in the delivery of responses.) | |||
| For simplicity, it is RECOMMENDED that the same server secret be used | For simplicity, it is RECOMMENDED that the same server secret be used | |||
| by each DNS server in a set of anycast servers. If there is limited | by each DNS server in a set of anycast servers. If there is limited | |||
| time skew in updating this secret in different anycast servers, this | time skew in updating this secret in different anycast servers, this | |||
| can be handled by a server accepting requests containing a Server | can be handled by a server accepting requests containing a Server | |||
| Cookie based on either its old or new secret for the maximum likely | Cookie based on either its old or new secret for the maximum likely | |||
| time period of such time skew (see also Section 5.5). | time period of such time skew (see also Section 7.1). | |||
| INTERNET-DRAFT DNS Cookies | INTERNET-DRAFT DNS Cookies | |||
| 7. Deployment | 7. Operational and Deployment Considerations | |||
| The DNS cookies mechanism is designed for incremental deployment and | The DNS cookies mechanism is designed for incremental deployment and | |||
| to complement the orthogonal techniques in [RFC5452]. Either or both | to complement the orthogonal techniques in [RFC5452]. Either or both | |||
| techniques can be deployed independently at each DNS server and | techniques can be deployed independently at each DNS server and | |||
| client. | client. Thus installation at the client and server end need not be | |||
| synchronized. | ||||
| In particular, a DNS server or client that implements the DNS COOKIE | In particular, a DNS server or client that implements the DNS COOKIE | |||
| mechanism can interoperate successfully with a DNS client or server | mechanism can interoperate successfully with a DNS client or server | |||
| that does not implement this mechanism although, of course, in this | that does not implement this mechanism although, of course, in this | |||
| case it will not get the benefit of the mechanism and the server | case it will not get the benefit of the mechanism and the server | |||
| involved might choose to severely rate limit responses. When such a | involved might choose to severely rate limit responses. When such a | |||
| server or client interoperates with a client or server which also | server or client interoperates with a client or server which also | |||
| implements the DNS cookies mechanism, they get the weak security | implements the DNS cookies mechanism, they get the security benefits | |||
| benefits of the DNS Cookies mechanism. | of the DNS Cookies mechanism. | |||
| 7.1 Client and Server Secret Rollover | ||||
| The longer a secret is used, the higher the probability it has been | ||||
| compromised. Thus clients and servers are configured with a lifetime | ||||
| for their secret and rollover to a new secret when that lifetime | ||||
| expires or earlier due to deliberate jitter as described below. The | ||||
| default lifetime is one day and the maximum permitted is one month. | ||||
| To be precise and to make it practical to stay within limits despite | ||||
| long holiday weekends and daylight savings time shifts and the like, | ||||
| clients and servers MUST NOT continue to use the same secret in new | ||||
| requests and responses for more than 36 days and SHOULD NOT continue | ||||
| to do so for more than 26 hours. | ||||
| Many clients rolling over their secret at the same time could briefly | ||||
| increase server traffic and exactly predictable rollover times for | ||||
| clients or servers might facilitate guessing attacks. For example, an | ||||
| attacker might increase the priority of attacking secrets they | ||||
| believe will be in effect for an extended period of time. To avoid | ||||
| rollover synchronization and predictability, it is RECOMMENDED that | ||||
| pseudorandom jitter in the range of plus zero to minus at least 40% | ||||
| be applied to the time until a scheduled rollover of a DNS cookie | ||||
| secret. | ||||
| It is RECOMMENDED that a client keep the Client Cookie it is | ||||
| expecting in a reply until there is no longer an outstanding request | ||||
| associated with that Client Cookie that the client is tracking. This | ||||
| avoids rejection of replies due to a bad Client Cookie right after a | ||||
| change in the client secret. | ||||
| It is RECOMMENDED that a server retain its previous secret after a | ||||
| rollover to a new secret for a configurable period of time not less | ||||
| INTERNET-DRAFT DNS Cookies | ||||
| than 1 second or more than 5 minutes with default configuration of 2 | ||||
| 1/2 minutes. Requests with Server Cookies based on its previous | ||||
| secret are treated as a correct Server Cookie during that time. When | ||||
| a server responds to a request containing a old Server Cookie that | ||||
| the server is treating as correct, the server MUST include a new | ||||
| Server Cookie in its response. | ||||
| 7.2 Counters | ||||
| It is RECOMMENDED that implementations include counters of the | ||||
| occurrences of the various types of requests and responses described | ||||
| in Section 5. | ||||
| INTERNET-DRAFT DNS Cookies | INTERNET-DRAFT DNS Cookies | |||
| 8. IANA Considerations | 8. IANA Considerations | |||
| IANA has assigned the following OPT option value: | IANA has assigned the following OPT option value: | |||
| Value Name Status Reference | Value Name Status Reference | |||
| -------- ------ -------- --------------- | -------- ------ -------- --------------- | |||
| 10 COOKIE Standard [this document] | 10 COOKIE Standard [this document] | |||
| skipping to change at page 21, line 20 ¶ | skipping to change at page 22, line 20 ¶ | |||
| responses. In particular, they provide no protection against "on- | responses. In particular, they provide no protection against "on- | |||
| path" adversaries; that is, they provide no protection against any | path" adversaries; that is, they provide no protection against any | |||
| adversary that can observe the plain text DNS traffic, such as an on- | adversary that can observe the plain text DNS traffic, such as an on- | |||
| path router, bridge, or any device on an on-path shared link (unless | path router, bridge, or any device on an on-path shared link (unless | |||
| the DNS traffic in question on that path is encrypted). | the DNS traffic in question on that path is encrypted). | |||
| For example, if a host is connected via an unsecured IEEE Std 802.11 | For example, if a host is connected via an unsecured IEEE Std 802.11 | |||
| link (Wi-Fi), any device in the vicinity that could receive and | link (Wi-Fi), any device in the vicinity that could receive and | |||
| decode the 802.11 transmissions must be considered "on-path". On the | decode the 802.11 transmissions must be considered "on-path". On the | |||
| other hand, in a similar situation but one where 802.11 Robust | other hand, in a similar situation but one where 802.11 Robust | |||
| Security (WPAv2) is appropriately deployed on the Wi-Fi network | Security (WPA2) is appropriately deployed on the Wi-Fi network nodes, | |||
| nodes, only the Access Point via which the host is connecting is "on- | only the Access Point via which the host is connecting is "on-path" | |||
| path" as far as the 802.11 link is concerned. | as far as the 802.11 link is concerned. | |||
| Despite these limitations, deployment of DNS Cookies on the global | Despite these limitations, deployment of DNS Cookies on the global | |||
| Internet is expected to provide a significant reduction in the | Internet is expected to provide a significant reduction in the | |||
| available launch points for the traffic amplification and denial of | available launch points for the traffic amplification and denial of | |||
| service forgery attacks described in Section 2 above. | service forgery attacks described in Section 2 above. | |||
| Work is underway in the IETF DPRIVE working group to provide | ||||
| confidentiality for DNS requests and responses which would be | ||||
| compatible with DNS cookies. | ||||
| Should stronger message/transaction security be desired, it is | Should stronger message/transaction security be desired, it is | |||
| suggested that TSIG or SIG(0) security be used (see Section 3.2); | suggested that TSIG or SIG(0) security be used (see Section 3.2); | |||
| however, it may be useful to use DNS Cookies in conjunction with | however, it may be useful to use DNS Cookies in conjunction with | |||
| these features. In particular, DNS Cookies could screen out many DNS | these features. In particular, DNS Cookies could screen out many DNS | |||
| messages before the cryptographic computations of TSIG or SIG(0) are | messages before the cryptographic computations of TSIG or SIG(0) are | |||
| required and, if SIG(0) is in use, DNS Cookies could usefully screen | required and, if SIG(0) is in use, DNS Cookies could usefully screen | |||
| out many requests given that SIG(0) does not screen requests but only | out many requests given that SIG(0) does not screen requests but only | |||
| authenticates the response of complete transactions. | authenticates the response of complete transactions. | |||
| An attacker that does not know the Server Cookie could do a variety | ||||
| of things, such as omitting the COOKIE OPT option or sending a random | ||||
| Server Cookie. In general, DNS servers need to take other measures, | ||||
| including rate limiting responses, to protect from abuse in such | ||||
| cases. See further information in Section 5.2. | ||||
| When a server or client starts receiving an increased level of | ||||
| requests with bad server cookies or replies with bad client cookies, | ||||
| it would be reasonable for it to believe it is likely under attack | ||||
| and it should consider a more frequent rollover of its secret. More | ||||
| rapid rollover decreases the benefit to a cookie guessing attacker if | ||||
| they succeed in guessing a cookie. | ||||
| INTERNET-DRAFT DNS Cookies | ||||
| 9.1 Cookie Algorithm Considerations | 9.1 Cookie Algorithm Considerations | |||
| The cookie computation algorithm for use in DNS Cookies SHOULD be | The cookie computation algorithm for use in DNS Cookies SHOULD be | |||
| based on a pseudo-random function at least as strong as 64-bit FNV | based on a pseudo-random function at least as strong as 64-bit FNV | |||
| (Fowler-Noll-Vo [FNV]) because an excessively weak or trivial | (Fowler-Noll-Vo [FNV]) because an excessively weak or trivial | |||
| algorithm could enable adversaries to guess cookies. However, in | algorithm could enable adversaries to guess cookies. However, in | |||
| light of the weak plain-text token security provided by DNS Cookies, | light of the lightweight plain-text token security provided by DNS | |||
| a strong cryptography hash algorithm may not be warranted in many | Cookies, a strong cryptography hash algorithm may not be warranted in | |||
| cases, and would cause an increased computational burden. | many cases, and would cause an increased computational burden. | |||
| Nevertheless there is nothing wrong with using something stronger, | Nevertheless there is nothing wrong with using something stronger, | |||
| for example, HMAC-SHA256-64 [RFC6234], assuming a DNS processor has | for example, HMAC-SHA256 [RFC6234] truncated to 64 bits, assuming a | |||
| adequate computational resources available. DNS processors that feel | DNS processor has adequate computational resources available. DNS | |||
| the need for somewhat stronger security without a significant | processors that feel the need for somewhat stronger security without | |||
| increase in computational load should consider more frequent changes | a significant increase in computational load should consider more | |||
| in their client and/or server secret; however, this does require more | frequent changes in their client and/or server secret; however, this | |||
| frequent generation of a cryptographically strong random number | does require more frequent generation of a cryptographically strong | |||
| [RFC4086]. See Appendices A and B for specific examples of cookie | random number [RFC4086]. See Appendices A and B for specific examples | |||
| of cookie computation algorithms. | ||||
| INTERNET-DRAFT DNS Cookies | ||||
| computation algorithms. | ||||
| INTERNET-DRAFT DNS Cookies | INTERNET-DRAFT DNS Cookies | |||
| 10. Implementation Considerations | 10. Implementation Considerations | |||
| The DNS Cookie Option specified herein is implemented in BIND 9.10 | The DNS Cookie Option specified herein is implemented in BIND 9.10 | |||
| using a experimental option code. | using an experimental option code. | |||
| INTERNET-DRAFT DNS Cookies | INTERNET-DRAFT DNS Cookies | |||
| Normative References | Normative References | |||
| [RFC1035] - Mockapetris, P., "Domain names - implementation and | [RFC1035] - Mockapetris, P., "Domain names - implementation and | |||
| specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | |||
| November 1987, <http://www.rfc-editor.org/info/rfc1035>. | November 1987, <http://www.rfc-editor.org/info/rfc1035>. | |||
| [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate | |||
| skipping to change at page 26, line 12 ¶ | skipping to change at page 27, line 12 ¶ | |||
| 10.17487/RFC6234, May 2011, <http://www.rfc- | 10.17487/RFC6234, May 2011, <http://www.rfc- | |||
| editor.org/info/rfc6234>. | editor.org/info/rfc6234>. | |||
| INTERNET-DRAFT DNS Cookies | INTERNET-DRAFT DNS Cookies | |||
| Acknowledgements | Acknowledgements | |||
| The suggestions and contributions of the following are gratefully | The suggestions and contributions of the following are gratefully | |||
| acknowledged: | acknowledged: | |||
| Bob Harold, Paul Hoffman, Gayle Noble, Tim Wicinski | Alissa Cooper, Bob Harold, Paul Hoffman, David Malone, Yoav Nir, | |||
| Gayle Noble, Dan Romascanu, | ||||
| Tim Wicinski, Peter Yee | ||||
| The document was prepared in raw nroff. All macros used were defined | The document was prepared in raw nroff. All macros used were defined | |||
| within the source file. | within the source file. | |||
| INTERNET-DRAFT DNS Cookies | INTERNET-DRAFT DNS Cookies | |||
| Appendix A: Example Client Cookie Algorithms | Appendix A: Example Client Cookie Algorithms | |||
| A.1 A Simple Algorithm | A.1 A Simple Algorithm | |||
| An simple example method to compute Client Cookies is the FNV-64 | A simple example method to compute Client Cookies is the FNV-64 [FNV] | |||
| [FNV] of the server IP address and the client secret. That is | of the client IP address, the server IP address, and the client | |||
| secret. That is | ||||
| Client Cookie = FNV-64 ( Client Secret | Server IP Address ) | Client Cookie = | |||
| FNV-64( Client IP Address | Server IP Address | Client Secret ) | ||||
| where "|" indicates concatenation. | where "|" indicates concatenation. Some computational resources may | |||
| be saved by precomputing FNV-64 through the Client IP Address. (If | ||||
| the order of the items concatenated above is changed to put the | ||||
| Server IP Address last, it might be possible to further reduce the | ||||
| computational effort by pre-computing FNV-64 through the bytes of | ||||
| both the Client IP Address and the Client Secret but this would | ||||
| reduce the strength of the Client Cookie and is NOT RECOMMENDED.) | ||||
| A.2 A More Complex Algorithm | A.2 A More Complex Algorithm | |||
| A more complex algorithm to calculate Client Cookies is given below. | A more complex algorithm to calculate Client Cookies is given below. | |||
| It uses more computational resources than the simpler algorithm shown | It uses more computational resources than the simpler algorithm shown | |||
| in A.1. | in A.1. | |||
| Client Cookie = HMAC-SHA256-64 ( Client Secret, | Client Cookie = HMAC-SHA256-64( | |||
| Server IP Address ) | Client IP Address | Server IP Address, | |||
| Client Secret ) | ||||
| INTERNET-DRAFT DNS Cookies | INTERNET-DRAFT DNS Cookies | |||
| Appendix B: Example Server Cookie Algorithms | Appendix B: Example Server Cookie Algorithms | |||
| B.1 A Simple Algorithm | B.1 A Simple Algorithm | |||
| An example of a simple method producing a 64-bit Server Cookie is the | An example of a simple method producing a 64-bit Server Cookie is the | |||
| FNV-64 [FNV] of the request IP address, the Client Cookie, and the | FNV-64 [FNV] of the request IP address, the Client Cookie, and the | |||
| server secret. That is | server secret. | |||
| Server Cookie = | Server Cookie = | |||
| FNV-64 ( Server Secret | Request IP Address | Client Cookie ) | FNV-64( Client IP Address | Client Cookie | Server Secret ) | |||
| where "|" represents concatenation. | where "|" represents concatenation. (If the order of the items | |||
| concatenated was changed, it might be possible to reduce the | ||||
| computational effort by pre-computing FNV-64 through the bytes of the | ||||
| Sever Secret and Client Cookie but this would reduce the strength of | ||||
| the Server Cookie and is NOT RECOMMENDED.) | ||||
| B.2 A More Complex Algorithm | B.2 A More Complex Algorithm | |||
| Since the Server Cookie has a variable size, the server can store | Since the Server Cookie has a variable size, the server can store | |||
| various information in that field as long as it is hard for an | various information in that field as long as it is hard for an | |||
| adversary to guess the entire quantity used for weak authentication. | adversary to guess the entire quantity used for authentication. There | |||
| There should be 64 bits of entropy in the Server Cookie; for example | should be 64 bits of entropy in the Server Cookie; for example it | |||
| it could have a sub-field of 64-bits computed pseudo-randomly with | could have a sub-field of 64-bits computed pseudo-randomly with the | |||
| the server secret as one of the inputs to the pseudo-random function. | server secret as one of the inputs to the pseudo-random function. | |||
| Types of additional information that could be stored include a time | Types of additional information that could be stored include a time | |||
| stamp and/or a nonce. | stamp and/or a nonce. | |||
| The example below is one variation for the Server Cookie that has | The example below is one variation for the Server Cookie that has | |||
| been implemented in a beta release of BIND where the Server Cookie is | been implemented in BIND 9.10.3 (and later) releases where the Server | |||
| 128 bits composed as follows: | Cookie is 128 bits composed as follows: | |||
| Sub-field Size | Sub-field Size | |||
| --------- --------- | --------- --------- | |||
| Nonce 32 bits | Nonce 32 bits | |||
| Time 32 bits | Time 32 bits | |||
| Hash 64 bits | Hash 64 bits | |||
| With this algorithm, the server sends a new 128-bit cookie back with | With this algorithm, the server sends a new 128-bit cookie back with | |||
| every request. The Nonce field assures a low probability that there | every request. The Nonce field assures a low probability that there | |||
| would be a duplicate. | would be a duplicate. | |||
| The Time field gives the server time and makes it easy to reject old | The Time field gives the server time and makes it easy to reject old | |||
| cookies. | cookies. | |||
| The Hash part of the Server Cookie is the hard-to-guess part. In the | The Hash part of the Server Cookie is the hard-to-guess part. In BIND | |||
| beta release of BIND, its computation can be configured to use AES, | ||||
| HMAC-SHA1, or, as shown below, HMAC-SHA256: | ||||
| INTERNET-DRAFT DNS Cookies | INTERNET-DRAFT DNS Cookies | |||
| 9.10.3 (and later), its computation can be configured to use AES, | ||||
| HMAC-SHA1, or, as shown below, HMAC-SHA256: | ||||
| hash = | hash = | |||
| HMAC-SHA256-64 ( Server Secret, | HMAC-SHA256-64( Server Secret, | |||
| (Client Cookie | nonce | time | client IP Address) ) | (Client Cookie | nonce | time | Client IP Address) ) | |||
| where "|" represents concatenation. | where "|" represents concatenation. | |||
| INTERNET-DRAFT DNS Cookies | INTERNET-DRAFT DNS Cookies | |||
| Author's Address | Author's Address | |||
| Donald E. Eastlake 3rd | Donald E. Eastlake 3rd | |||
| Huawei Technologies | Huawei Technologies | |||
| 155 Beaver Street | 155 Beaver Street | |||
| skipping to change at page 30, line 26 ¶ | skipping to change at page 31, line 26 ¶ | |||
| Mark Andrews | Mark Andrews | |||
| Internet Systems Consortium | Internet Systems Consortium | |||
| 950 Charter Street | 950 Charter Street | |||
| Redwood City, CA 94063 USA | Redwood City, CA 94063 USA | |||
| Email: marka@isc.org | Email: marka@isc.org | |||
| Copyright, Disclaimer, and Additional IPR Provisions | Copyright, Disclaimer, and Additional IPR Provisions | |||
| Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2016 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| End of changes. 67 change blocks. | ||||
| 167 lines changed or deleted | 235 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/ | ||||