draft-ietf-dnsop-cookies-07.txt   draft-ietf-dnsop-cookies-08.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: June 23, 2016 December 24, 2015
Domain Name System (DNS) Cookies Domain Name System (DNS) Cookies
<draft-ietf-dnsop-cookies-07.txt> <draft-ietf-dnsop-cookies-08.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 4, line 21 skipping to change at page 4, line 21
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
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 37 skipping to change at page 11, line 37
Client Cookie, and a secret quantity known only to the server. (See Client Cookie, and a secret quantity known only to the server. (See
Section 6 for a discussion of why the Client Cookie is used as input Section 6 for a discussion of why the Client Cookie is used as input
to the Server Cookie but the Server Cookie is not used as an input to to the Server Cookie but the Server Cookie is not used as an input to
the Client Cookie.) This server secret SHOULD have at least 64 bits the Client Cookie.) This server secret SHOULD have at least 64 bits
of entropy [RFC4086] and be changed periodically (see Section 5.5). of entropy [RFC4086] and be changed periodically (see Section 5.5).
The selection of the pseudo-random function is a matter private to The selection of the pseudo-random function is a matter private to
the server as only the server needs to recognize its own DNS cookies. 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
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
skipping to change at page 14, line 8 skipping to change at page 14, line 8
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 respond to such requests to inform the client of the correct Server
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
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 examination will result in a
determination of whether the Server Cookie is valid or not. If the determination of whether the Server Cookie is valid or not. 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.
skipping to change at page 15, line 28 skipping to change at page 15, line 28
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
skipping to change at page 16, line 43 skipping to change at page 16, line 43
be applied to the time until a scheduled rollover of a DNS cookie be applied to the time until a scheduled rollover of a DNS cookie
secret. secret.
It is RECOMMENDED that a client keep the Client Cookie it is It is RECOMMENDED that a client keep the Client Cookie it is
expecting in a reply associated with the outstanding request to avoid expecting in a reply associated with the outstanding request to avoid
rejection of replies due to a bad Client Cookie right after a change 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 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 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 than 5 minutes, after a change in its secret, and consider requests
with Server Cookies based on its previous secret to have a correct with Server Cookies based on its previous secret to have a correct
Server Cookie during that time. 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.
When a server or client starts receiving an increased level of When a server or client starts receiving an increased level of
requests with bad server cookies or replies with bad client cookies, requests with bad server cookies or replies with bad client cookies,
it would be reasonable for it to believe it is likely under attack 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 and it should consider a more frequent rollover of its secret. More
rapid rollover decreases the benefit to a cookie guessing attacker if rapid rollover decreases the benefit to a cookie guessing attacker if
they succeed in guessing a cookie. 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 indefinitely 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 19, line 20 skipping to change at page 19, line 20
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.
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.
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 38 skipping to change at page 21, line 38
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.
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
the need for somewhat stronger security without a significant
increase in computational load should consider more frequent changes
in their client and/or server secret; however, this does require more
frequent generation of a cryptographically strong random number
[RFC4086]. See Appendices A and B for specific examples of cookie
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
computation algorithms. DNS processor has adequate computational resources available. DNS
processors that feel the need for somewhat stronger security without
a significant increase in computational load should consider more
frequent changes in their client and/or server secret; however, this
does require more frequent generation of a cryptographically strong
random number [RFC4086]. See Appendices A and B for specific examples
of cookie 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 a experimental option code.
INTERNET-DRAFT DNS Cookies INTERNET-DRAFT DNS Cookies
skipping to change at page 26, line 12 skipping to change at page 26, 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 Bob Harold, Paul Hoffman, Yoav Nir, Gayle Noble, Tim Wicinski
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 An simple example method to compute Client Cookies is the FNV-64
[FNV] of the server IP address and the client secret. That is [FNV] of the server IP address and the client secret. That is
Client Cookie = FNV-64 ( Client Secret | Server IP Address ) Client Cookie = FNV-64 ( Server IP Address | Client Secret )
where "|" indicates concatenation. where "|" indicates concatenation. (If the order of the items
concatenated above were reversed, it might be possible to reduce the
computational effort by pre-computing FNV-64 through the bytes of 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 ( Client Secret,
Server IP Address ) Server IP Address )
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 ( Request IP Address | Client Cookie | Server Secret )
where "|" represents concatenation. where "|" represents concatenation. (If the order of the items
concatenated above were reversed, 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 the
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
beta release of BIND, 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
 End of changes. 32 change blocks. 
57 lines changed or deleted 81 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/