+++ /dev/null
-
-
-
-
-
-
-DNSEXT Working Group Bernard Aboba
-INTERNET-DRAFT Dave Thaler
-Category: Standards Track Levon Esibov
-<draft-ietf-dnsext-mdns-46.txt> Microsoft Corporation
-16 April 2006
-
- Linklocal Multicast Name Resolution (LLMNR)
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on October 15, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society 2006.
-
-Abstract
-
- The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
- name resolution in scenarios in which conventional DNS name
- resolution is not possible. LLMNR supports all current and future
- DNS formats, types and classes, while operating on a separate port
- from DNS, and with a distinct resolver cache. Since LLMNR only
- operates on the local link, it cannot be considered a substitute for
- DNS.
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 1]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-Table of Contents
-
-1. Introduction .......................................... 3
- 1.1 Requirements .................................... 4
- 1.2 Terminology ..................................... 4
-2. Name Resolution Using LLMNR ........................... 4
- 2.1 LLMNR Packet Format ............................. 5
- 2.2 Sender Behavior ................................. 8
- 2.3 Responder Behavior .............................. 8
- 2.4 Unicast Queries and Responses ................... 11
- 2.5 Off-link Detection .............................. 11
- 2.6 Responder Responsibilities ...................... 12
- 2.7 Retransmission and Jitter ....................... 13
- 2.8 DNS TTL ......................................... 14
- 2.9 Use of the Authority and Additional Sections .... 14
-3. Usage model ........................................... 15
- 3.1 LLMNR Configuration ............................. 16
-4. Conflict Resolution ................................... 18
- 4.1 Uniqueness Verification ......................... 18
- 4.2 Conflict Detection and Defense .................. 19
- 4.3 Considerations for Multiple Interfaces .......... 20
- 4.4 API issues ...................................... 22
-5. Security Considerations ............................... 22
- 5.1 Denial of Service ............................... 22
- 5.2 Spoofing ...............,........................ 23
- 5.3 Authentication .................................. 24
- 5.4 Cache and Port Separation ....................... 24
-6. IANA considerations ................................... 25
-7. Constants ............................................. 25
-8. References ............................................ 26
- 8.1 Normative References ............................ 26
- 8.2 Informative References .......................... 26
-Acknowledgments .............................................. 28
-Authors' Addresses ........................................... 28
-Intellectual Property Statement .............................. 29
-Disclaimer of Validity ....................................... 29
-Copyright Statement .......................................... 29
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 2]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-1. Introduction
-
- This document discusses Link Local Multicast Name Resolution (LLMNR),
- which is based on the DNS packet format and supports all current and
- future DNS formats, types and classes. LLMNR operates on a separate
- port from the Domain Name System (DNS), with a distinct resolver
- cache.
-
- Since LLMNR only operates on the local link, it cannot be considered
- a substitute for DNS. Link-scope multicast addresses are used to
- prevent propagation of LLMNR traffic across routers, potentially
- flooding the network. LLMNR queries can also be sent to a unicast
- address, as described in Section 2.4.
-
- Propagation of LLMNR packets on the local link is considered
- sufficient to enable name resolution in small networks. In such
- networks, if a network has a gateway, then typically the network is
- able to provide DNS server configuration. Configuration issues are
- discussed in Section 3.1.
-
- In the future, it may be desirable to consider use of multicast name
- resolution with multicast scopes beyond the link-scope. This could
- occur if LLMNR deployment is successful, the need arises for
- multicast name resolution beyond the link-scope, or multicast routing
- becomes ubiquitous. For example, expanded support for multicast name
- resolution might be required for mobile ad-hoc networks.
-
- Once we have experience in LLMNR deployment in terms of
- administrative issues, usability and impact on the network, it will
- be possible to reevaluate which multicast scopes are appropriate for
- use with multicast name resolution. IPv4 administratively scoped
- multicast usage is specified in "Administratively Scoped IP
- Multicast" [RFC2365].
-
- Service discovery in general, as well as discovery of DNS servers
- using LLMNR in particular, is outside of the scope of this document,
- as is name resolution over non-multicast capable media.
-
-1.1. Requirements
-
- In this document, several words are used to signify the requirements
- of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
- "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
- and "OPTIONAL" in this document are to be interpreted as described in
- [RFC2119].
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 3]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-1.2. Terminology
-
- This document assumes familiarity with DNS terminology defined in
- [RFC1035]. Other terminology used in this document includes:
-
-Routable Address
- An address other than a Link-Local address. This includes globally
- routable addresses, as well as private addresses.
-
-Reachable
- An LLMNR responder considers one of its addresses reachable over a
- link if it will respond to an ARP or Neighbor Discovery query for
- that address received on that link.
-
-Responder
- A host that listens to LLMNR queries, and responds to those for
- which it is authoritative.
-
-Sender
- A host that sends an LLMNR query.
-
-UNIQUE
- There are some scenarios when multiple responders may respond to
- the same query. There are other scenarios when only one responder
- may respond to a query. Names for which only a single responder is
- anticipated are referred to as UNIQUE. Name uniqueness is
- configured on the responder, and therefore uniqueness verification
- is the responder's responsibility.
-
-2. Name Resolution Using LLMNR
-
- LLMNR queries are sent to and received on port 5355. The IPv4 link-
- scope multicast address a given responder listens to, and to which a
- sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast
- address a given responder listens to, and to which a sender sends all
- queries, is FF02:0:0:0:0:0:1:3.
-
- Typically a host is configured as both an LLMNR sender and a
- responder. A host MAY be configured as a sender, but not a
- responder. However, a host configured as a responder MUST act as a
- sender, if only to verify the uniqueness of names as described in
- Section 4. This document does not specify how names are chosen or
- configured. This may occur via any mechanism, including DHCPv4
- [RFC2131] or DHCPv6 [RFC3315].
-
- A typical sequence of events for LLMNR usage is as follows:
-
- [a] An LLMNR sender sends an LLMNR query to the link-scope
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 4]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- multicast address(es), unless a unicast query is indicated,
- as specified in Section 2.4.
-
- [b] A responder responds to this query only if it is authoritative
- for the name in the query. A responder responds to a
- multicast query by sending a unicast UDP response to the sender.
- Unicast queries are responded to as indicated in Section 2.4.
-
- [c] Upon reception of the response, the sender processes it.
-
- The sections that follow provide further details on sender and
- responder behavior.
-
-2.1. LLMNR Packet Format
-
- LLMNR is based on the DNS packet format defined in [RFC1035] Section
- 4 for both queries and responses. LLMNR implementations SHOULD send
- UDP queries and responses only as large as are known to be
- permissible without causing fragmentation. When in doubt a maximum
- packet size of 512 octets SHOULD be used. LLMNR implementations MUST
- accept UDP queries and responses as large as the smaller of the link
- MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22
- octets for the header, VLAN tag and CRC).
-
-2.1.1. LLMNR Header Format
-
- LLMNR queries and responses utilize the DNS header format defined in
- [RFC1035] with exceptions noted below:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ID |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- |QR| Opcode | C|TC| T| Z| Z| Z| Z| RCODE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QDCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ANCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | NSCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ARCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- where:
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 5]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-ID A 16 bit identifier assigned by the program that generates any kind
- of query. This identifier is copied from the query to the response
- and can be used by the sender to match responses to outstanding
- queries. The ID field in a query SHOULD be set to a pseudo-random
- value. For advice on generation of pseudo-random values, please
- consult [RFC1750].
-
-QR Query/Response. A one bit field, which if set indicates that the
- message is an LLMNR response; if clear then the message is an LLMNR
- query.
-
-OPCODE
- A four bit field that specifies the kind of query in this message.
- This value is set by the originator of a query and copied into the
- response. This specification defines the behavior of standard
- queries and responses (opcode value of zero). Future
- specifications may define the use of other opcodes with LLMNR.
- LLMNR senders and responders MUST support standard queries (opcode
- value of zero). LLMNR queries with unsupported OPCODE values MUST
- be silently discarded by responders.
-
-C Conflict. When set within a request, the 'C'onflict bit indicates
- that a sender has received multiple LLMNR responses to this query.
- In an LLMNR response, if the name is considered UNIQUE, then the
- 'C' bit is clear, otherwise it is set. LLMNR senders do not
- retransmit queries with the 'C' bit set. Responders MUST NOT
- respond to LLMNR queries with the 'C' bit set, but may start the
- uniqueness verification process, as described in Section 4.2.
-
-TC TrunCation - specifies that this message was truncated due to
- length greater than that permitted on the transmission channel.
- The TC bit MUST NOT be set in an LLMNR query and if set is ignored
- by an LLMNR responder. If the TC bit is set in an LLMNR response,
- then the sender SHOULD resend the LLMNR query over TCP using the
- unicast address of the responder as the destination address. If
- the sender receives a response to the TCP query, then it SHOULD
- discard the UDP response with the TC bit set. See [RFC2181] and
- Section 2.4 of this specification for further discussion of the TC
- bit.
-
-T Tentative. The 'T'entative bit is set in a response if the
- responder is authoritative for the name, but has not yet verified
- the uniqueness of the name. A responder MUST ignore the 'T' bit in
- a query, if set. A response with the 'T' bit set is silently
- discarded by the sender, except if it is a uniqueness query, in
- which case a conflict has been detected and a responder MUST
- resolve the conflict as described in Section 4.1.
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 6]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-Z Reserved for future use. Implementations of this specification
- MUST set these bits to zero in both queries and responses. If
- these bits are set in a LLMNR query or response, implementations of
- this specification MUST ignore them. Since reserved bits could
- conceivably be used for different purposes than in DNS,
- implementors are advised not to enable processing of these bits in
- an LLMNR implementation starting from a DNS code base.
-
-RCODE
- Response code -- this 4 bit field is set as part of LLMNR
- responses. In an LLMNR query, the sender MUST set RCODE to zero;
- the responder ignores the RCODE and assumes it to be zero. The
- response to a multicast LLMNR query MUST have RCODE set to zero. A
- sender MUST silently discard an LLMNR response with a non-zero
- RCODE sent in response to a multicast query.
-
- If an LLMNR responder is authoritative for the name in a multicast
- query, but an error is encountered, the responder SHOULD send an
- LLMNR response with an RCODE of zero, no RRs in the answer section,
- and the TC bit set. This will cause the query to be resent using
- TCP, and allow the inclusion of a non-zero RCODE in the response to
- the TCP query. Responding with the TC bit set is preferable to not
- sending a response, since it enables errors to be diagnosed. This
- may be required, for example, when an LLMNR query includes a TSIG
- RR in the additional section, and the responder encounters a
- problem that requires returning a non-zero RCODE. TSIG error
- conditions defined in [RFC2845] include a TSIG RR in an
- unacceptable position (RCODE=1) or a TSIG RR which does not
- validate (RCODE=9 with TSIG ERROR 17 (BADKEY) or 16 (BADSIG)).
-
- Since LLMNR responders only respond to LLMNR queries for names for
- which they are authoritative, LLMNR responders MUST NOT respond
- with an RCODE of 3; instead, they should not respond at all.
-
- LLMNR implementations MUST support EDNS0 [RFC2671] and extended
- RCODE values.
-
-QDCOUNT
- An unsigned 16 bit integer specifying the number of entries in the
- question section. A sender MUST place only one question into the
- question section of an LLMNR query. LLMNR responders MUST silently
- discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders
- MUST silently discard LLMNR responses with QDCOUNT not equal to
- one.
-
-ANCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the answer section. LLMNR responders MUST silently
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 7]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- discard LLMNR queries with ANCOUNT not equal to zero.
-
-NSCOUNT
- An unsigned 16 bit integer specifying the number of name server
- resource records in the authority records section. Authority
- record section processing is described in Section 2.9. LLMNR
- responders MUST silently discard LLMNR queries with NSCOUNT not
- equal to zero.
-
-ARCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the additional records section. Additional record
- section processing is described in Section 2.9.
-
-2.2. Sender Behavior
-
- A sender MAY send an LLMNR query for any legal resource record type
- (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address.
- As described in Section 2.4, a sender MAY also send a unicast query.
-
- The sender MUST anticipate receiving no replies to some LLMNR
- queries, in the event that no responders are available within the
- link-scope. If no response is received, a resolver treats it as a
- response that the name does not exist (RCODE=3 is returned). A
- sender can handle duplicate responses by discarding responses with a
- source IP address and ID field that duplicate a response already
- received.
-
- When multiple valid LLMNR responses are received with the 'C' bit
- set, they SHOULD be concatenated and treated in the same manner that
- multiple RRs received from the same DNS server would be. However,
- responses with the 'C' bit set SHOULD NOT be concatenated with
- responses with the 'C' bit clear; instead, only the responses with
- the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are
- received along with error response(s), then the error responses are
- silently discarded.
-
- Since the responder may order the RRs in the response so as to
- indicate preference, the sender SHOULD preserve ordering in the
- response to the querying application.
-
-2.3. Responder Behavior
-
- An LLMNR response MUST be sent to the sender via unicast.
-
- Upon configuring an IP address, responders typically will synthesize
- corresponding A, AAAA and PTR RRs so as to be able to respond to
- LLMNR queries for these RRs. An SOA RR is synthesized only when a
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 8]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- responder has another RR in addition to the SOA RR; the SOA RR MUST
- NOT be the only RR that a responder has. However, in general whether
- RRs are manually or automatically created is an implementation
- decision.
-
- For example, a host configured to have computer name "host1" and to
- be a member of the "example.com" domain, and with IPv4 address
- 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
- authoritative for the following records:
-
- host1. IN A 192.0.2.1
- IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
- host1.example.com. IN A 192.0.2.1
- IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
- 1.2.0.192.in-addr.arpa. IN PTR host1.
- IN PTR host1.example.com.
-
- 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.
- ip6.arpa IN PTR host1. (line split for formatting reasons)
- IN PTR host1.example.com.
-
- An LLMNR responder might be further manually configured with the name
- of a local mail server with an MX RR included in the "host1." and
- "host1.example.com." records.
-
- In responding to queries:
-
-[a] Responders MUST listen on UDP port 5355 on the link-scope multicast
- address(es) defined in Section 2, and on TCP port 5355 on the
- unicast address(es) that could be set as the source address(es)
- when the responder responds to the LLMNR query.
-
-[b] Responders MUST direct responses to the port from which the query
- was sent. When queries are received via TCP this is an inherent
- part of the transport protocol. For queries received by UDP the
- responder MUST take note of the source port and use that as the
- destination port in the response. Responses MUST always be sent
- from the port to which they were directed.
-
-[c] Responders MUST respond to LLMNR queries for names and addresses
- they are authoritative for. This applies to both forward and
- reverse lookups, with the exception of queries with the 'C' bit
- set, which do not elicit a response.
-
-[d] Responders MUST NOT respond to LLMNR queries for names they are not
- authoritative for.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 9]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-[e] Responders MUST NOT respond using data from the LLMNR or DNS
- resolver cache.
-
-[f] If a DNS server is running on a host that supports LLMNR, the DNS
- server MUST respond to LLMNR queries only for the RRSets relating
- to the host on which the server is running, but MUST NOT respond
- for other records for which the server is authoritative. DNS
- servers also MUST NOT send LLMNR queries in order to resolve DNS
- queries.
-
-[g] If a responder is authoritative for a name, it MUST respond with
- RCODE=0 and an empty answer section, if the type of query does not
- match a RR that the responder has.
-
- As an example, a host configured to respond to LLMNR queries for the
- name "foo.example.com." is authoritative for the name
- "foo.example.com.". On receiving an LLMNR query for an A RR with the
- name "foo.example.com." the host authoritatively responds with A
- RR(s) that contain IP address(es) in the RDATA of the resource
- record. If the responder has a AAAA RR, but no A RR, and an A RR
- query is received, the responder would respond with RCODE=0 and an
- empty answer section.
-
- In conventional DNS terminology a DNS server authoritative for a zone
- is authoritative for all the domain names under the zone apex except
- for the branches delegated into separate zones. Contrary to
- conventional DNS terminology, an LLMNR responder is authoritative
- only for the zone apex.
-
- For example the host "foo.example.com." is not authoritative for the
- name "child.foo.example.com." unless the host is configured with
- multiple names, including "foo.example.com." and
- "child.foo.example.com.". As a result, "foo.example.com." cannot
- reply to an LLMNR query for "child.foo.example.com." with RCODE=3
- (authoritative name error). The purpose of limiting the name
- authority scope of a responder is to prevent complications that could
- be caused by coexistence of two or more hosts with the names
- representing child and parent (or grandparent) nodes in the DNS tree,
- for example, "foo.example.com." and "child.foo.example.com.".
-
- Without the restriction on authority an LLMNR query for an A resource
- record for the name "child.foo.example.com." would result in two
- authoritative responses: RCODE=3 (authoritative name error) received
- from "foo.example.com.", and a requested A record - from
- "child.foo.example.com.". To prevent this ambiguity, LLMNR enabled
- hosts could perform a dynamic update of the parent (or grandparent)
- zone with a delegation to a child zone; for example a host
- "child.foo.example.com." could send a dynamic update for the NS and
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 10]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- glue A record to "foo.example.com.". However, this approach
- significantly complicates implementation of LLMNR and would not be
- acceptable for lightweight hosts.
-
-2.4. Unicast Queries and Responses
-
- Unicast queries SHOULD be sent when:
-
- [a] A sender repeats a query after it received a response
- with the TC bit set to the previous LLMNR multicast query, or
-
- [b] The sender queries for a PTR RR of a fully formed IP address
- within the "in-addr.arpa" or "ip6.arpa" zones.
-
- Unicast LLMNR queries MUST be done using TCP and the responses MUST
- be sent using the same TCP connection as the query. Senders MUST
- support sending TCP queries, and responders MUST support listening
- for TCP queries. If the sender of a TCP query receives a response to
- that query not using TCP, the response MUST be silently discarded.
-
- Unicast UDP queries MUST be silently discarded.
-
- A unicast PTR RR query for an off-link address will not elicit a
- response, but instead an ICMP TTL or Hop Limit exceeded message will
- be received. An implementation receiving an ICMP message in response
- to a TCP connection setup attempt can return immediately, treating
- this as a response that no such name exists (RCODE=3 is returned).
- An implementation that cannot process ICMP messages MAY send
- multicast UDP queries for PTR RRs. Since TCP implementations will
- not retransmit prior to RTOmin, a considerable period will elapse
- before TCP retransmits multiple times, resulting in a long timeout
- for TCP PTR RR queries sent to an off-link destination.
-
-2.5. "Off link" Detection
-
- A sender MUST select a source address for LLMNR queries that is
- assigned on the interface on which the query is sent. The
- destination address of an LLMNR query MUST be a link-scope multicast
- address or a unicast address.
-
- A responder MUST select a source address for responses that is
- assigned on the interface on which the query was received. The
- destination address of an LLMNR response MUST be a unicast address.
-
- On receiving an LLMNR query, the responder MUST check whether it was
- sent to a LLMNR multicast addresses defined in Section 2. If it was
- sent to another multicast address, then the query MUST be silently
- discarded.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 11]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- Section 2.4 discusses use of TCP for LLMNR queries and responses. In
- composing an LLMNR query using TCP, the sender MUST set the Hop Limit
- field in the IPv6 header and the TTL field in the IPv4 header of the
- response to one (1). The responder SHOULD set the TTL or Hop Limit
- settings on the TCP listen socket to one (1) so that SYN-ACK packets
- will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
- prevents an incoming connection from off-link since the sender will
- not receive a SYN-ACK from the responder.
-
- For UDP queries and responses, the Hop Limit field in the IPv6 header
- and the TTL field in the IPV4 header MAY be set to any value.
- However, it is RECOMMENDED that the value 255 be used for
- compatibility with early implementations of [RFC3927].
-
- Implementation note:
-
- In the sockets API for IPv4 [POSIX], the IP_TTL and
- IP_MULTICAST_TTL socket options are used to set the TTL of
- outgoing unicast and multicast packets. The IP_RECVTTL socket
- option is available on some platforms to retrieve the IPv4 TTL of
- received packets with recvmsg(). [RFC2292] specifies similar
- options for setting and retrieving the IPv6 Hop Limit.
-
-2.6. Responder Responsibilities
-
- It is the responsibility of the responder to ensure that RRs returned
- in LLMNR responses MUST only include values that are valid on the
- local interface, such as IPv4 or IPv6 addresses valid on the local
- link or names defended using the mechanism described in Section 4.
- IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local
- addresses are defined in [RFC2373]. In particular:
-
- [a] If a link-scope IPv6 address is returned in a AAAA RR,
- that address MUST be valid on the local link over which
- LLMNR is used.
-
- [b] If an IPv4 address is returned, it MUST be reachable
- through the link over which LLMNR is used.
-
- [c] If a name is returned (for example in a CNAME, MX
- or SRV RR), the name MUST be resolvable on the local
- link over which LLMNR is used.
-
- Where multiple addresses represent valid responses to a query, the
- order in which the addresses are returned is as follows:
-
- [d] If the source address of the query is a link-scope address,
- then the responder SHOULD include a link-scope address first
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 12]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- in the response, if available.
-
- [e] If the source address of the query is a routable address,
- then the responder MUST include a routable address first
- in the response, if available.
-
-2.7. Retransmission and Jitter
-
- An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
- when to retransmit an LLMNR query. An LLMNR sender SHOULD either
- estimate the LLMNR_TIMEOUT for each interface, or set a reasonably
- high initial timeout. Suggested constants are described in Section
- 7.
-
- If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
- then a sender SHOULD repeat the transmission of the query in order to
- assure that it was received by a host capable of responding to it.
- An LLMNR query SHOULD NOT be sent more than three times.
-
- Where LLMNR queries are sent using TCP, retransmission is handled by
- the transport layer. Queries with the 'C' bit set MUST be sent using
- multicast UDP and MUST NOT be retransmitted.
-
- An LLMNR sender cannot know in advance if a query sent using
- multicast will receive no response, one response, or more than one
- response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
- has been received, or if it is necessary to collect all potential
- responses, such as if a uniqueness verification query is being made.
- Otherwise an LLMNR sender SHOULD consider a multicast query answered
- after the first response is received, if that response has the 'C'
- bit clear.
-
- However, if the first response has the 'C' bit set, then the sender
- SHOULD wait for LLMNR_TIMEOUT + JITTER_INTERVAL in order to collect
- all possible responses. When multiple valid answers are received,
- they may first be concatenated, and then treated in the same manner
- that multiple RRs received from the same DNS server would. A unicast
- query sender considers the query answered after the first response is
- received.
-
- Since it is possible for a response with the 'C' bit clear to be
- followed by a response with the 'C' bit set, an LLMNR sender SHOULD
- be prepared to process additional responses for the purposes of
- conflict detection, even after it has considered a query answered.
-
- In order to avoid synchronization, the transmission of each LLMNR
- query and response SHOULD delayed by a time randomly selected from
- the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 13]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- responders responding with names which they have previously
- determined to be UNIQUE (see Section 4 for details).
-
-2.8. DNS TTL
-
- The responder should insert a pre-configured TTL value in the records
- returned in an LLMNR response. A default value of 30 seconds is
- RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc
- networks), the TTL value may need to be reduced.
-
- Due to the TTL minimalization necessary when caching an RRset, all
- TTLs in an RRset MUST be set to the same value.
-
-2.9. Use of the Authority and Additional Sections
-
- Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
- concept of delegation. In LLMNR, the NS resource record type may be
- stored and queried for like any other type, but it has no special
- delegation semantics as it does in the DNS. Responders MAY have NS
- records associated with the names for which they are authoritative,
- but they SHOULD NOT include these NS records in the authority
- sections of responses.
-
- Responders SHOULD insert an SOA record into the authority section of
- a negative response, to facilitate negative caching as specified in
- [RFC2308]. The TTL of this record is set from the minimum of the
- MINIMUM field of the SOA record and the TTL of the SOA itself, and
- indicates how long a resolver may cache the negative answer. The
- owner name of the SOA record (MNAME) MUST be set to the query name.
- The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored
- by senders. Negative responses without SOA records SHOULD NOT be
- cached.
-
- In LLMNR, the additional section is primarily intended for use by
- EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set,
- senders MAY only include pseudo RR-types in the additional section of
- a query; unless the 'C' bit is set, responders MUST ignore the
- additional section of queries containing other RR types.
-
- In queries where the 'C' bit is set, the sender SHOULD include the
- conflicting RRs in the additional section. Since conflict
- notifications are advisory, responders SHOULD log information from
- the additional section, but otherwise MUST ignore the additional
- section.
-
- Senders MUST NOT cache RRs from the authority or additional section
- of a response as answers, though they may be used for other purposes
- such as negative caching.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 14]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-3. Usage Model
-
- LLMNR is a peer-to-peer name resolution protocol that is not intended
- as a replacement for DNS; rather, it enables name resolution in
- scenarios in which conventional DNS name resolution is not possible.
- This includes situations in which hosts are not configured with the
- address of a DNS server; where the DNS server is unavailable or
- unreachable; where there is no DNS server authoritative for the name
- of a host, or where the authoritative DNS server does not have the
- desired RRs.
-
- By default, an LLMNR sender SHOULD send LLMNR queries only for
- single-label names. In order to reduce unnecessary DNS queries, stub
- resolvers supporting both DNS and LLMNR SHOULD avoid sending DNS
- queries for single-label names. An LLMNR sender SHOULD NOT be
- enabled to send a query for any name, except where security
- mechanisms (described in Section 5.3) can be utilized.
-
- Regardless of whether security mechanisms can be utilized, LLMNR
- queries SHOULD NOT be sent unless one of the following conditions are
- met:
-
- [1] No manual or automatic DNS configuration has been performed.
- If DNS server address(es) have been configured, a
- host SHOULD attempt to reach DNS servers over all protocols
- on which DNS server address(es) are configured, prior to sending
- LLMNR queries. For dual stack hosts configured with DNS server
- address(es) for one protocol but not another, this implies that
- DNS queries SHOULD be sent over the protocol configured with
- a DNS server, prior to sending LLMNR queries.
-
- [2] All attempts to resolve the name via DNS on all interfaces
- have failed after exhausting the searchlist. This can occur
- because DNS servers did not respond, or because they
- responded to DNS queries with RCODE=3 (Authoritative Name
- Error) or RCODE=0, and an empty answer section. Where a
- single resolver call generates DNS queries for A and AAAA RRs,
- an implementation MAY choose not to send LLMNR queries if any
- of the DNS queries is successful. An LLMNR query SHOULD only
- be sent for the originally requested name; a searchlist
- is not used to form additional LLMNR queries.
-
- Since LLMNR is a secondary name resolution mechanism, its usage is in
- part determined by the behavior of DNS implementations. In general,
- robust DNS resolver implementations are more likely to avoid
- unnecessary LLMNR queries.
-
- As noted in [DNSPerf], even when DNS servers are configured, a
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 15]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- significant fraction of DNS queries do not receive a response, or
- result in negative responses due to missing inverse mappings or NS
- records that point to nonexistent or inappropriate hosts. This has
- the potential to result in a large number of unnecessary LLMNR
- queries.
-
- [RFC1536] describes common DNS implementation errors and fixes. If
- the proposed fixes are implemented, unnecessary LLMNR queries will be
- reduced substantially, and so implementation of [RFC1536] is
- recommended.
-
- For example, [RFC1536] Section 1 describes issues with retransmission
- and recommends implementation of a retransmission policy based on
- round trip estimates, with exponential back-off. [RFC1536] Section 4
- describes issues with failover, and recommends that resolvers try
- another server when they don't receive a response to a query. These
- policies are likely to avoid unnecessary LLMNR queries.
-
- [RFC1536] Section 3 describes zero answer bugs, which if addressed
- will also reduce unnecessary LLMNR queries.
-
- [RFC1536] Section 6 describes name error bugs and recommended
- searchlist processing that will reduce unnecessary RCODE=3
- (authoritative name) errors, thereby also reducing unnecessary LLMNR
- queries.
-
- If error responses are received from both DNS and LLMNR, then the
- lowest RCODE value should be returned. For example, if either DNS or
- LLMNR receives a response with RCODE=0, then this should returned to
- the caller.
-
-3.1. LLMNR Configuration
-
- LLMNR usage MAY be configured manually or automatically on a per
- interface basis. By default, LLMNR responders SHOULD be enabled on
- all interfaces, at all times. Enabling LLMNR for use in situations
- where a DNS server has been configured will result in a change in
- default behavior without a simultaneous update to configuration
- information. Where this is considered undesirable, LLMNR SHOULD NOT
- be enabled by default, so that hosts will neither listen on the link-
- scope multicast address, nor will they send queries to that address.
-
- Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
- possible for a dual stack host to be configured with the address of a
- DNS server over IPv4, while remaining unconfigured with a DNS server
- suitable for use over IPv6.
-
- In these situations, a dual stack host will send AAAA queries to the
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 16]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- configured DNS server over IPv4. However, an IPv6-only host
- unconfigured with a DNS server suitable for use over IPv6 will be
- unable to resolve names using DNS. Automatic IPv6 DNS configuration
- mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
- deployed, and not all DNS servers support IPv6. Therefore lack of
- IPv6 DNS configuration may be a common problem in the short term, and
- LLMNR may prove useful in enabling link-local name resolution over
- IPv6.
-
- Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
- IPv6-only hosts may not be configured with a DNS server. Where there
- is no DNS server authoritative for the name of a host or the
- authoritative DNS server does not support dynamic client update over
- IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
- be able to do DNS dynamic update, and other hosts will not be able to
- resolve its name.
-
- For example, if the configured DNS server responds to a AAAA RR query
- sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or
- RCODE=0 and an empty answer section, then a AAAA RR query sent using
- LLMNR over IPv6 may be successful in resolving the name of an
- IPv6-only host on the local link.
-
- Similarly, if a DHCPv4 server is available providing DNS server
- configuration, and DNS server(s) exist which are authoritative for
- the A RRs of local hosts and support either dynamic client update
- over IPv4 or DHCPv4-based dynamic update, then the names of local
- IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no
- DNS server is authoritative for the names of local hosts, or the
- authoritative DNS server(s) do not support dynamic update, then LLMNR
- enables linklocal name resolution over IPv4.
-
- Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
- configure LLMNR on an interface. The LLMNR Enable Option, described
- in [LLMNREnable], can be used to explicitly enable or disable use of
- LLMNR on an interface. The LLMNR Enable Option does not determine
- whether or in which order DNS itself is used for name resolution.
- The order in which various name resolution mechanisms should be used
- can be specified using the Name Service Search Option (NSSO) for DHCP
- [RFC2937], using the LLMNR Enable Option code carried in the NSSO
- data.
-
- It is possible that DNS configuration mechanisms will go in and out
- of service. In these circumstances, it is possible for hosts within
- an administrative domain to be inconsistent in their DNS
- configuration.
-
- For example, where DHCP is used for configuring DNS servers, one or
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 17]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- more DHCP servers can fail. As a result, hosts configured prior to
- the outage will be configured with a DNS server, while hosts
- configured after the outage will not. Alternatively, it is possible
- for the DNS configuration mechanism to continue functioning while
- configured DNS servers fail.
-
- An outage in the DNS configuration mechanism may result in hosts
- continuing to use LLMNR even once the outage is repaired. Since
- LLMNR only enables linklocal name resolution, this represents a
- degradation in capabilities. As a result, hosts without a configured
- DNS server may wish to periodically attempt to obtain DNS
- configuration if permitted by the configuration mechanism in use. In
- the absence of other guidance, a default retry interval of one (1)
- minute is RECOMMENDED.
-
-4. Conflict Resolution
-
- By default, a responder SHOULD be configured to behave as though its
- name is UNIQUE on each interface on which LLMNR is enabled. However,
- it is also possible to configure multiple responders to be
- authoritative for the same name. For example, multiple responders
- MAY respond to a query for an A or AAAA type record for a cluster
- name (assigned to multiple hosts in the cluster).
-
- To detect duplicate use of a name, an administrator can use a name
- resolution utility which employs LLMNR and lists both responses and
- responders. This would allow an administrator to diagnose behavior
- and potentially to intervene and reconfigure LLMNR responders who
- should not be configured to respond to the same name.
-
-4.1. Uniqueness Verification
-
- Prior to sending an LLMNR response with the 'T' bit clear, a
- responder configured with a UNIQUE name MUST verify that there is no
- other host within the scope of LLMNR query propagation that is
- authoritative for the same name on that interface.
-
- Once a responder has verified that its name is UNIQUE, if it receives
- an LLMNR query for that name, with the 'C' bit clear, it MUST
- respond, with the 'T' bit clear. Prior to verifying that its name is
- UNIQUE, a responder MUST set the 'T' bit in responses.
-
- Uniqueness verification is carried out when the host:
-
- - starts up or is rebooted
- - wakes from sleep (if the network interface was inactive
- during sleep)
- - is configured to respond to LLMNR queries on an interface
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 18]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- enabled for transmission and reception of IP traffic
- - is configured to respond to LLMNR queries using additional
- UNIQUE resource records
- - verifies the acquisition of a new IP address and configuration
- on an interface
-
- To verify uniqueness, a responder MUST send an LLMNR query with the
- 'C' bit clear, over all protocols on which it responds to LLMNR
- queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify
- uniqueness of a name by sending a query for the name with type='ANY'.
-
- If no response is received, the sender retransmits the query, as
- specified in Section 2.7. If a response is received, the sender MUST
- check if the source address matches the address of any of its
- interfaces; if so, then the response is not considered a conflict,
- since it originates from the sender. To avoid triggering conflict
- detection, a responder that detects that it is connected to the same
- link on multiple interfaces SHOULD set the 'C' bit in responses.
-
- If a response is received with the 'T' bit clear, the responder MUST
- NOT use the name in response to LLMNR queries received over any
- protocol (IPv4 or IPv6). If a response is received with the 'T' bit
- set, the responder MUST check if the source IP address in the
- response, interpreted as an unsigned integer, is less than the source
- IP address in the query. If so, the responder MUST NOT use the name
- in response to LLMNR queries received over any protocol (IPv4 or
- IPv6). For the purpose of uniqueness verification, the contents of
- the answer section in a response is irrelevant.
-
- Periodically carrying out uniqueness verification in an attempt to
- detect name conflicts is not necessary, wastes network bandwidth, and
- may actually be detrimental. For example, if network links are
- joined only briefly, and are separated again before any new
- communication is initiated, temporary conflicts are benign and no
- forced reconfiguration is required. LLMNR responders SHOULD NOT
- periodically attempt uniqueness verification.
-
-4.2. Conflict Detection and Defense
-
- Hosts on disjoint network links may configure the same name for use
- with LLMNR. If these separate network links are later joined or
- bridged together, then there may be multiple hosts which are now on
- the same link, trying to use the same name.
-
- In order to enable ongoing detection of name conflicts, when an LLMNR
- sender receives multiple LLMNR responses to a query, it MUST check if
- the 'C' bit is clear in any of the responses. If so, the sender
- SHOULD send another query for the same name, type and class, this
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 19]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- time with the 'C' bit set, with the potentially conflicting resource
- records included in the additional section.
-
- Queries with the 'C' bit set are considered advisory and responders
- MUST verify the existence of a conflict before acting on it. A
- responder receiving a query with the 'C' bit set MUST NOT respond.
-
- If the query is for a UNIQUE name, then the responder MUST send its
- own query for the same name, type and class, with the 'C' bit clear.
- If a response is received, the sender MUST check if the source
- address matches the address of any of its interfaces; if so, then the
- response is not considered a conflict, since it originates from the
- sender. To avoid triggering conflict detection, a responder that
- detects that it is connected to the same link on multiple interfaces
- SHOULD set the 'C' bit in responses.
-
- An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
- log them. Upon detecting a conflict, an LLMNR responder MUST
- immediately stop using the conflicting name in response to LLMNR
- queries received over any supported protocol, if the source IP
- address in the response, interpreted as an unsigned integer, is less
- than the source IP address in the uniqueness verification query.
-
- After stopping the use of a name, the responder MAY elect to
- configure a new name. However, since name reconfiguration may be
- disruptive, this is not required, and a responder may have been
- configured to respond to multiple names so that alternative names may
- already be available. A host that has stopped the use of a name may
- attempt uniqueness verification again after the expiration of the TTL
- of the conflicting response.
-
-4.3. Considerations for Multiple Interfaces
-
- A multi-homed host may elect to configure LLMNR on only one of its
- active interfaces. In many situations this will be adequate.
- However, should a host need to configure LLMNR on more than one of
- its active interfaces, there are some additional precautions it MUST
- take. Implementers who are not planning to support LLMNR on multiple
- interfaces simultaneously may skip this section.
-
- Where a host is configured to issue LLMNR queries on more than one
- interface, each interface maintains its own independent LLMNR
- resolver cache, containing the responses to LLMNR queries.
-
- A multi-homed host checks the uniqueness of UNIQUE records as
- described in Section 4. The situation is illustrated in figure 1.
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 20]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- ---------- ----------
- | | | |
- [A] [myhost] [myhost]
-
- Figure 1. Link-scope name conflict
-
- In this situation, the multi-homed myhost will probe for, and defend,
- its host name on both interfaces. A conflict will be detected on one
- interface, but not the other. The multi-homed myhost will not be
- able to respond with a host RR for "myhost" on the interface on the
- right (see Figure 1). The multi-homed host may, however, be
- configured to use the "myhost" name on the interface on the left.
-
- Since names are only unique per-link, hosts on different links could
- be using the same name. If an LLMNR client sends requests over
- multiple interfaces, and receives replies from more than one, the
- result returned to the client is defined by the implementation. The
- situation is illustrated in figure 2.
-
- ---------- ----------
- | | | |
- [A] [myhost] [A]
-
-
- Figure 2. Off-segment name conflict
-
- If host myhost is configured to use LLMNR on both interfaces, it will
- send LLMNR queries on both interfaces. When host myhost sends a
- query for the host RR for name "A" it will receive a response from
- hosts on both interfaces.
-
- Host myhost cannot distinguish between the situation shown in Figure
- 2, and that shown in Figure 3 where no conflict exists.
-
- [A]
- | |
- ----- -----
- | |
- [myhost]
-
- Figure 3. Multiple paths to same host
-
- This illustrates that the proposed name conflict resolution mechanism
- does not support detection or resolution of conflicts between hosts
- on different links. This problem can also occur with DNS when a
- multi-homed host is connected to two different networks with
- separated name spaces. It is not the intent of this document to
- address the issue of uniqueness of names within DNS.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 21]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-4.4. API Issues
-
- [RFC2553] provides an API which can partially solve the name
- ambiguity problem for applications written to use this API, since the
- sockaddr_in6 structure exposes the scope within which each scoped
- address exists, and this structure can be used for both IPv4 (using
- v4-mapped IPv6 addresses) and IPv6 addresses.
-
- Following the example in Figure 2, an application on 'myhost' issues
- the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
- ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
- interfaces and the resolver library will return a list containing
- multiple addrinfo structures, each with an associated sockaddr_in6
- structure. This list will thus contain the IPv4 and IPv6 addresses
- of both hosts responding to the name 'A'. Link-local addresses will
- have a sin6_scope_id value that disambiguates which interface is used
- to reach the address. Of course, to the application, Figures 2 and 3
- are still indistinguishable, but this API allows the application to
- communicate successfully with any address in the list.
-
-5. Security Considerations
-
- LLMNR is a peer-to-peer name resolution protocol designed for use on
- the local link. While LLMNR limits the vulnerability of responders
- to off-link senders, it is possible for an off-link responder to
- reach a sender.
-
- In scenarios such as public "hotspots" attackers can be present on
- the same link. These threats are most serious in wireless networks
- such as 802.11, since attackers on a wired network will require
- physical access to the network, while wireless attackers may mount
- attacks from a distance. Link-layer security such as [IEEE-802.11i]
- can be of assistance against these threats if it is available.
-
- This section details security measures available to mitigate threats
- from on and off-link attackers.
-
-5.1. Denial of Service
-
- Attackers may take advantage of LLMNR conflict detection by
- allocating the same name, denying service to other LLMNR responders
- and possibly allowing an attacker to receive packets destined for
- other hosts. By logging conflicts, LLMNR responders can provide
- forensic evidence of these attacks.
-
- An attacker may spoof LLMNR queries from a victim's address in order
- to mount a denial of service attack. Responders setting the IPv6 Hop
- Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 22]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- response may be able to reach the victim across the Internet.
-
- While LLMNR responders only respond to queries for which they are
- authoritative and LLMNR does not provide wildcard query support, an
- LLMNR response may be larger than the query, and an attacker can
- generate multiple responses to a query for a name used by multiple
- responders. A sender may protect itself against unsolicited
- responses by silently discarding them as rapidly as possible.
-
-5.2. Spoofing
-
- LLMNR is designed to prevent reception of queries sent by an off-link
- attacker. LLMNR requires that responders receiving UDP queries check
- that they are sent to a link-scope multicast address. However, it is
- possible that some routers may not properly implement link-scope
- multicast, or that link-scope multicast addresses may leak into the
- multicast routing system. To prevent successful setup of TCP
- connections by an off-link sender, responders receiving a TCP SYN
- reply with a TCP SYN-ACK with TTL set to one (1).
-
- While it is difficult for an off-link attacker to send an LLMNR query
- to a responder, it is possible for an off-link attacker to spoof a
- response to a query (such as an A or AAAA query for a popular
- Internet host), and by using a TTL or Hop Limit field larger than one
- (1), for the forged response to reach the LLMNR sender. Since the
- forged response will only be accepted if it contains a matching ID
- field, choosing a pseudo-random ID field within queries provides some
- protection against off-link responders.
-
- Since LLMNR queries can be sent when DNS server(s) do not respond, an
- attacker can execute a denial of service attack on the DNS server(s)
- and then poison the LLMNR cache by responding to an LLMNR query with
- incorrect information. As noted in "Threat Analysis of the Domain
- Name System (DNS)" [RFC3833] these threats also exist with DNS, since
- DNS response spoofing tools are available that can allow an attacker
- to respond to a query more quickly than a distant DNS server.
- However, while switched networks or link layer security may make it
- difficult for an on-link attacker to snoop unicast DNS queries,
- multicast LLMNR queries are propagated to all hosts on the link,
- making it possible for an on-link attacker to spoof LLMNR responses
- without having to guess the value of the ID field in the query.
-
- Since LLMNR queries are sent and responded to on the local-link, an
- attacker will need to respond more quickly to provide its own
- response prior to arrival of the response from a legitimate
- responder. If an LLMNR query is sent for an off-link host, spoofing
- a response in a timely way is not difficult, since a legitimate
- response will never be received.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 23]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- This vulnerability can be reduced by limiting use of LLMNR to
- resolution of single-label names as described in Section 3, or by
- implementation of authentication (see Section 5.3).
-
-5.3. Authentication
-
- LLMNR is a peer-to-peer name resolution protocol, and as a result,
- it is often deployed in situations where no trust model can be
- assumed. Where a pre-arranged security configuration is possible,
- the following security mechanisms may be used:
-
-[a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
- [RFC2931] security mechanisms. "DNS Name Service based on Secure
- Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes
- the use of TSIG to secure LLMNR, based on group keys. While group
- keys can be used to demonstrate membership in a group, they do not
- protect against forgery by an attacker that is a member of the
- group.
-
-[b] IPsec ESP with a null-transform MAY be used to authenticate unicast
- LLMNR queries and responses or LLMNR responses to multicast
- queries. In a small network without a certificate authority, this
- can be most easily accomplished through configuration of a group
- pre-shared key for trusted hosts. As with TSIG, this does not
- protect against forgery by an attacker with access to the group
- pre-shared key.
-
-[c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order to
- support DNSSEC, LLMNR implementations MAY be configured with trust
- anchors, or they MAY make use of keys obtained from DNS queries.
- Since LLMNR does not support "delegated trust" (CD or AD bits),
- LLMNR implementations cannot make use of DNSSEC unless they are
- DNSSEC-aware and support validation. Unlike approaches [a] or [b],
- DNSSEC permits a responder to demonstrate ownership of a name, not
- just membership within a trusted group. As a result, it enables
- protection against forgery.
-
-5.4. Cache and Port Separation
-
- In order to prevent responses to LLMNR queries from polluting the DNS
- cache, LLMNR implementations MUST use a distinct, isolated cache for
- LLMNR on each interface. The use of separate caches is most
- effective when LLMNR is used as a name resolution mechanism of last
- resort, since this minimizes the opportunities for poisoning the
- LLMNR cache, and decreases reliance on it.
-
- LLMNR operates on a separate port from DNS, reducing the likelihood
- that a DNS server will unintentionally respond to an LLMNR query.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 24]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- If LLMNR is given higher priority than DNS among the enabled name
- resolution mechanisms, a denial of service attack on the DNS server
- would not be necessary in order to poison the LLMNR cache, since
- LLMNR queries would be sent even when the DNS server is available.
- In addition, the LLMNR cache, once poisoned, would take precedence
- over the DNS cache, eliminating the benefits of cache separation. As
- a result, LLMNR SHOULD NOT be used as a primary name resolution
- mechanism.
-
-6. IANA Considerations
-
- LLMNR requires allocation of port 5355 for both TCP and UDP.
-
- LLMNR requires allocation of link-scope multicast IPv4 address
- 224.0.0.252, as well as link-scope multicast IPv6 address
- FF02:0:0:0:0:0:1:3.
-
- This specification creates two new name spaces: the LLMNR namespace
- and the reserved bits in the LLMNR header. The reserved bits in the
- LLMNR header are allocated by IETF Consensus, in accordance with BCP
- 26 [RFC2434].
-
- In order to to avoid creating any new administrative procedures,
- administration of the LLMNR namespace will piggyback on the
- administration of the DNS namespace.
-
- The rights to use a fully qualified domain name (FQDN) within LLMNR
- are obtained coincident with acquiring the rights to use that name
- within DNS. Those wishing to use a FQDN within LLMNR should first
- acquire the rights to use the corresponding FQDN within DNS. Using a
- FQDN within LLMNR without ownership of the corresponding name in DNS
- creates the possibility of conflict and therefore is discouraged.
-
- LLMNR responders may self-allocate a name within the single-label
- name space, first defined in [RFC1001]. Since single-label names are
- not unique, no registration process is required.
-
-7. Constants
-
- The following timing constants are used in this protocol; they are
- not intended to be user configurable.
-
- JITTER_INTERVAL 100 ms
- LLMNR_TIMEOUT 1 second (if set statically on all interfaces)
- 100 ms (IEEE 802 media, including IEEE 802.11)
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 25]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-8. References
-
-8.1. Normative References
-
-[RFC1001] Auerbach, K. and A. Aggarwal, "Protocol Standard for a NetBIOS
- Service on a TCP/UDP Transport: Concepts and Methods", RFC
- 1001, March 1987.
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC 1035, November 1987.
-
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
-[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
- RFC 2308, March 1998.
-
-[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
-[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October
- 1998.
-
-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
- August 1999.
-
-[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC
- 2845, May 2000.
-
-[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
- (SIG(0)s)", RFC 2931, September 2000.
-
-8.2. Informative References
-
-[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
- Caching", IEEE/ACM Transactions on Networking, Volume 10,
- Number 5, pp. 589, October 2002.
-
-[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
- unicast addresses to communicate with recursive DNS servers",
- Internet draft (work in progress), draft-ietf-ipv6-dns-
- discovery-07.txt, October 2002.
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 26]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-[IEEE-802.11i]
- Institute of Electrical and Electronics Engineers, "Supplement
- to Standard for Telecommunications and Information Exchange
- Between Systems - LAN/MAN Specific Requirements - Part 11:
- Wireless LAN Medium Access Control (MAC) and Physical Layer
- (PHY) Specifications: Specification for Enhanced Security",
- IEEE 802.11i, July 2004.
-
-[LLMNREnable]
- Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
- in progress), draft-guttman-mdns-enable-02.txt, April 2002.
-
-[LLMNRSec]
- Jeong, J., Park, J. and H. Kim, "DNS Name Service based on
- Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT
- 2004, Phoenix Park, Korea, February 9-11, 2004.
-
-[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
- Portable Operating System Interface (POSIX). Open Group
- Technical Standard: Base Specifications, Issue 6, December
- 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
-
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
- Fixes", RFC 1536, October 1993.
-
-[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
- Recommendations for Security", RFC 1750, December 1994.
-
-[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- March 1997.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
- RFC 2292, February 1998.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
- 2365, July 1998.
-
-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
- Socket Interface Extensions for IPv6", RFC 2553, March 1999.
-
-[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
- 2937, September 2000.
-
-[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
- IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
- System (DNS)", RFC 3833, August 2004.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 27]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
- of Link-Local IPv4 Addresses", RFC 3927, October 2004.
-
-[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
- "DNS Security Introduction and Requirement", RFC 4033, March
- 2005.
-
-Acknowledgments
-
- This work builds upon original work done on multicast DNS by Bill
- Manning and Bill Woodcock. Bill Manning's work was funded under
- DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge
- their contribution to the current specification. Constructive input
- has also been received from Mark Andrews, Rob Austein, Randy Bush,
- Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur
- Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig,
- Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore,
- Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike
- St. Johns, Sander Van-Valkenburg, and Brian Zill.
-
-Authors' Addresses
-
- Bernard Aboba
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- Phone: +1 425 706 6605
- EMail: bernarda@microsoft.com
-
- Dave Thaler
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- Phone: +1 425 703 8835
- EMail: dthaler@microsoft.com
-
- Levon Esibov
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- EMail: levone@microsoft.com
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 28]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 29]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-Open Issues
-
- Open issues with this specification are tracked on the following web
- site:
-
- http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 30]
-
-
-
+++ /dev/null
-
-INTERNET-DRAFT DSA Information in the DNS
-OBSOLETES: RFC 2536 Donald E. Eastlake 3rd
- Motorola Laboratories
-Expires: September 2006 March 2006
-
-
- DSA Keying and Signature Information in the DNS
- --- ------ --- --------- ----------- -- --- ---
- <draft-ietf-dnsext-rfc2536bis-dsa-07.txt>
- Donald E. Eastlake 3rd
-
-
-Status of This Document
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNS extensions working group mailing list
- <namedroppers@ops.ietf.org>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-
-Abstract
-
- The standard method of encoding US Government Digital Signature
- Algorithm keying and signature information for use in the Domain Name
- System is specified.
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
-
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 2. DSA Keying Information..................................3
- 3. DSA Signature Information...............................4
- 4. Performance Considerations..............................4
- 5. Security Considerations.................................5
- 6. IANA Considerations.....................................5
- Copyright, Disclaimer, and Additional IPR Provisions.......5
-
- Normative References.......................................7
- Informative References.....................................7
-
- Author's Address...........................................8
- Expiration and File Name...................................8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- other information [RFC 1034, 1035]. The DNS has been extended to
- include digital signatures and cryptographic keys as described in
- [RFC 4033, 4034, 4035] and additional work is underway which would
- require the storage of keying and signature information in the DNS.
-
- This document describes how to encode US Government Digital Signature
- Algorithm (DSA) keys and signatures in the DNS. Familiarity with the
- US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
-
-
-
-2. DSA Keying Information
-
- When DSA public keys are stored in the DNS, the structure of the
- relevant part of the RDATA part of the RR being used is the fields
- listed below in the order given.
-
- The period of key validity is not included in this data but is
- indicated separately, for example by an RR such as RRSIG which signs
- and authenticates the RR containing the keying information.
-
- Field Size
- ----- ----
- T 1 octet
- Q 20 octets
- P 64 + T*8 octets
- G 64 + T*8 octets
- Y 64 + T*8 octets
-
- As described in [FIPS 186-2] and [Schneier], T is a key size
- parameter chosen such that 0 <= T <= 8. (The meaning if the T octet
- is greater than 8 is reserved and the remainder of the data may have
- a different format in that case.) Q is a prime number selected at
- key generation time such that 2**159 < Q < 2**160. Thus Q is always
- 20 octets long and, as with all other fields, is stored in "big-
- endian" network order. P, G, and Y are calculated as directed by the
- [FIPS 186-2] key generation algorithm [Schneier]. P is in the range
- 2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G
- and Y are quantities modulo P and so can be up to the same length as
- P and are allocated fixed size fields with the same number of octets
- as P.
-
- During the key generation process, a random number X must be
- generated such that 1 <= X <= Q-1. X is the private key and is used
- in the final step of public key generation where Y is computed as
-
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- Y = G**X mod P
-
-
-
-3. DSA Signature Information
-
- The portion of the RDATA area used for US Digital Signature Algorithm
- signature information is shown below with fields in the order they
- are listed and the contents of each multi-octet field in "big-endian"
- network order.
-
- Field Size
- ----- ----
- T 1 octet
- R 20 octets
- S 20 octets
-
- First, the data signed must be determined. Then the following steps
- are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
- specified in the public key [Schneier]:
-
- hash = SHA-1 ( data )
-
- Generate a random K such that 0 < K < Q.
-
- R = ( G**K mod P ) mod Q
-
- S = ( K**(-1) * (hash + X*R) ) mod Q
-
- For information on the SHA-1 hash function see [FIPS 180-2] and [RFC
- 3174].
-
- Since Q is 160 bits long, R and S can not be larger than 20 octets,
- which is the space allocated.
-
- T is copied from the public key. It is not logically necessary in
- the SIG but is present so that values of T > 8 can more conveniently
- be used as an escape for extended versions of DSA or other algorithms
- as later standardized.
-
-
-
-4. Performance Considerations
-
- General signature generation speeds are roughly the same for RSA [RFC
- 3110] and DSA. With sufficient pre-computation, signature generation
- with DSA is faster than RSA. Key generation is also faster for DSA.
- However, signature verification is an order of magnitude slower than
- RSA when the RSA public exponent is chosen to be small, as is
- recommended for some applications.
-
-
-D. Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- Current DNS implementations are optimized for small transfers,
- typically less than 512 bytes including DNS overhead. Larger
- transfers will perform correctly and extensions have been
- standardized [RFC 2671] to make larger transfers more efficient, it
- is still advisable at this time to make reasonable efforts to
- minimize the size of RR sets containing keying and/or signature
- inforamtion consistent with adequate security.
-
-
-
-5. Security Considerations
-
- Keys retrieved from the DNS should not be trusted unless (1) they
- have been securely obtained from a secure resolver or independently
- verified by the user and (2) this secure resolver and secure
- obtainment or independent verification conform to security policies
- acceptable to the user. As with all cryptographic algorithms,
- evaluating the necessary strength of the key is essential and
- dependent on local policy.
-
- The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
- current DSA standard may limit the security of DSA. For particular
- applications, implementors are encouraged to consider the range of
- available algorithms and key sizes.
-
- DSA assumes the ability to frequently generate high quality random
- numbers. See [random] for guidance. DSA is designed so that if
- biased rather than random numbers are used, high bandwidth covert
- channels are possible. See [Schneier] and more recent research. The
- leakage of an entire DSA private key in only two DSA signatures has
- been demonstrated. DSA provides security only if trusted
- implementations, including trusted random number generation, are
- used.
-
-
-
-6. IANA Considerations
-
- Allocation of meaning to values of the T parameter that are not
- defined herein (i.e., > 8 ) requires an IETF standards actions. It
- is intended that values unallocated herein be used to cover future
- extensions of the DSS standard.
-
-
-
-Copyright, Disclaimer, and Additional IPR Provisions
-
- Copyright (C) The Internet Society (2006). This document is subject to
- the rights, licenses and restrictions contained in BCP 78, and except
- as set forth therein, the authors retain all their rights.
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Normative References
-
- [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
- Signature Standard, 27 January 2000.
-
- [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-
-
-Informative References
-
- [RFC 1034] - "Domain names - concepts and facilities", P.
- Mockapetris, 11/01/1987.
-
- [RFC 1035] - "Domain names - implementation and specification", P.
- Mockapetris, 11/01/1987.
-
- [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
- 1999.
-
- [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
- (DNS)", D. Eastlake 3rd. May 2001.
-
- [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
- Jones, September 2001.
-
- [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC 4033, March
- 2005.
-
- [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security Extensions", RFC
- 4035, March 2005.
-
- [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
- "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
-
- [Schneier] - "Applied Cryptography Second Edition: protocols,
- algorithms, and source code in C" (second edition), Bruce Schneier,
- 1996, John Wiley and Sons, ISBN 0-471-11709-9.
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Labortories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554(w)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in September 2006.
-
- Its file name is draft-ietf-dnsext-rfc2536bis-dsa-07.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
+++ /dev/null
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-OBSOLETES: RFC 2539 Donald E. Eastlake 3rd
- Motorola Laboratories
-Expires: September 2006 March 2006
-
-
-
-
- Storage of Diffie-Hellman Keying Information in the DNS
- ------- -- -------------- ------ ----------- -- --- ---
- <draft-ietf-dnsext-rfc2539bis-dhk-07.txt>
-
-
-
-Status of This Document
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNS extensions working group mailing list
- <namedroppers@ops.ietf.org>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- The standard method for encoding Diffie-Hellman keys in the Domain
- Name System is specified.
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Acknowledgements
-
- Part of the format for Diffie-Hellman keys and the description
- thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
- and Hemma Prafullchandra. In addition, the following persons
- provided useful comments that were incorporated into the predecessor
- of this document: Ran Atkinson, Thomas Narten.
-
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
-
- Acknowledgements...........................................2
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 1.1 About This Document....................................3
- 1.2 About Diffie-Hellman...................................3
- 2. Encoding Diffie-Hellman Keying Information..............4
- 3. Performance Considerations..............................5
- 4. IANA Considerations.....................................5
- 5. Security Considerations.................................5
- Copyright, Disclaimer, and Additional IPR Provisions.......5
-
- Normative References.......................................7
- Informative Refences.......................................7
-
- Author's Address...........................................8
- Expiration and File Name...................................8
-
- Appendix A: Well known prime/generator pairs...............9
- A.1. Well-Known Group 1: A 768 bit prime..................9
- A.2. Well-Known Group 2: A 1024 bit prime.................9
- A.3. Well-Known Group 3: A 1536 bit prime................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- similar information [RFC 1034, 1035]. The DNS has been extended to
- include digital signatures and cryptographic keys as described in
- [RFC 4033, 4034, 4035] and additonal work is underway which would use
- the storage of keying information in the DNS.
-
-
-
-1.1 About This Document
-
- This document describes how to store Diffie-Hellman keys in the DNS.
- Familiarity with the Diffie-Hellman key exchange algorithm is assumed
- [Schneier, RFC 2631].
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119.
-
-
-
-1.2 About Diffie-Hellman
-
- Diffie-Hellman requires two parties to interact to derive keying
- information which can then be used for authentication. Thus Diffie-
- Hellman is inherently a key agreement algorithm. As a result, no
- format is defined for Diffie-Hellman "signature information". For
- example, assume that two parties have local secrets "i" and "j".
- Assume they each respectively calculate X and Y as follows:
-
- X = g**i ( mod p )
-
- Y = g**j ( mod p )
-
- They exchange these quantities and then each calculates a Z as
- follows:
-
- Zi = Y**i ( mod p )
-
- Zj = X**j ( mod p )
-
- Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
- secret between the two parties that an adversary who does not know i
- or j will not be able to learn from the exchanged messages (unless
- the adversary can derive i or j by performing a discrete logarithm
- mod p which is hard for strong p and g).
-
- The private key for each party is their secret i (or j). The public
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
- key is the pair p and g, which is the same for both parties, and
- their individual X (or Y).
-
- For further information about Diffie-Hellman and precautions to take
- in deciding on a p and g, see [RFC 2631].
-
-
-
-2. Encoding Diffie-Hellman Keying Information
-
- When Diffie-Hellman keys appear within the RDATA portion of a RR,
- they are encoded as shown below.
-
- The period of key validity is not included in this data but is
- indicated separately, for example by an RR such as RRSIG which signs
- and authenticates the RR containing the keying information.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | KEY flags | protocol | algorithm=2 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | prime length (or flag) | prime (p) (or special) /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / prime (p) (variable length) | generator length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | generator (g) (variable length) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | public value length | public value (variable length)/
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / public value (g^i mod p) (variable length) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Prime length is the length of the Diffie-Hellman prime (p) in bytes
- if it is 16 or greater. Prime contains the binary representation of
- the Diffie-Hellman prime with most significant byte first (i.e., in
- network order). If "prime length" field is 1 or 2, then the "prime"
- field is actually an unsigned index into a table of 65,536
- prime/generator pairs and the generator length SHOULD be zero. See
- Appedix A for defined table entries and Section 4 for information on
- allocating additional table entries. The meaning of a zero or 3
- through 15 value for "prime length" is reserved.
-
- Generator length is the length of the generator (g) in bytes.
- Generator is the binary representation of generator with most
- significant byte first. PublicValueLen is the Length of the Public
- Value (g**i (mod p)) in bytes. PublicValue is the binary
- representation of the DH public value with most significant byte
- first.
-
-
-
-D. Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-3. Performance Considerations
-
- Current DNS implementations are optimized for small transfers,
- typically less than 512 bytes including DNS overhead. Larger
- transfers will perform correctly and extensions have been
- standardized [RFC 2671] to make larger transfers more efficient. But
- it is still advisable at this time to make reasonable efforts to
- minimize the size of RR sets containing keying information consistent
- with adequate security.
-
-
-
-4. IANA Considerations
-
- Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
- an IETF consensus as defined in [RFC 2434].
-
- Well known prime/generator pairs number 0x0000 through 0x07FF can
- only be assigned by an IETF standards action. [RFC 2539], the
- Proposed Standard predecessor of this document, assigned 0x0001
- through 0x0002. This document additionally assigns 0x0003. Pairs
- number 0s0800 through 0xBFFF can be assigned based on RFC
- documentation. Pairs number 0xC000 through 0xFFFF are available for
- private use and are not centrally coordinated. Use of such private
- pairs outside of a closed environment may result in conflicts and/or
- security failures.
-
-
-
-5. Security Considerations
-
- Keying information retrieved from the DNS should not be trusted
- unless (1) it has been securely obtained from a secure resolver or
- independently verified by the user and (2) this secure resolver and
- secure obtainment or independent verification conform to security
- policies acceptable to the user. As with all cryptographic
- algorithms, evaluating the necessary strength of the key is important
- and dependent on security policy.
-
- In addition, the usual Diffie-Hellman key strength considerations
- apply. (p-1)/2 SHOULD also be prime, g SHOULD be primitive mod p, p
- SHOULD be "large", etc. See [RFC 2631, Schneier].
-
-
-
-Copyright, Disclaimer, and Additional IPR Provisions
-
- Copyright (C) The Internet Society (2006). This document is subject to
- the rights, licenses and restrictions contained in BCP 78, and except
- as set forth therein, the authors retain all their rights.
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Normative References
-
- [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC 2434] - "Guidelines for Writing an IANA Considerations Section
- in RFCs", T. Narten, H. Alvestrand, October 1998.
-
- [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
- 1999.
-
- [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-
-
-Informative Refences
-
- [RFC 1034] - "Domain names - concepts and facilities", P.
- Mockapetris, November 1987.
-
- [RFC 1035] - "Domain names - implementation and specification", P.
- Mockapetris, November 1987.
-
- [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
- System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
-
- [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
- 1999.
-
- [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC 4033, March
- 2005.
-
- [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security Extensions", RFC
- 4035, March 2005.
-
- [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
- Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
- and Sons.
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in September 2006.
-
- Its file name is draft-ietf-dnsext-rfc2539bis-dhk-07.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Appendix A: Well known prime/generator pairs
-
- These numbers are copied from the IPSEC effort where the derivation
- of these values is more fully explained and additional information is
- available. Richard Schroeppel performed all the mathematical and
- computational work for this appendix.
-
-
-
-A.1. Well-Known Group 1: A 768 bit prime
-
- The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its
- decimal value is
- 155251809230070893513091813125848175563133404943451431320235
- 119490296623994910210725866945387659164244291000768028886422
- 915080371891804634263272761303128298374438082089019628850917
- 0691316593175367469551763119843371637221007210577919
-
- Prime modulus: Length (32 bit words): 24, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-A.2. Well-Known Group 2: A 1024 bit prime
-
- The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
- Its decimal value is
- 179769313486231590770839156793787453197860296048756011706444
- 423684197180216158519368947833795864925541502180565485980503
- 646440548199239100050792877003355816639229553136239076508735
- 759914822574862575007425302077447712589550957937778424442426
- 617334727629299387668709205606050270810842907692932019128194
- 467627007
-
- Prime modulus: Length (32 bit words): 32, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
- EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
- FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-
-D. Eastlake 3rd [Page 9]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-A.3. Well-Known Group 3: A 1536 bit prime
-
- The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
- Its decimal value is
- 241031242692103258855207602219756607485695054850245994265411
- 694195810883168261222889009385826134161467322714147790401219
- 650364895705058263194273070680500922306273474534107340669624
- 601458936165977404102716924945320037872943417032584377865919
- 814376319377685986952408894019557734611984354530154704374720
- 774996976375008430892633929555996888245787241299381012913029
- 459299994792636526405928464720973038494721168143446471443848
- 8520940127459844288859336526896320919633919
-
- Prime modulus Length (32 bit words): 48, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
- EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
- C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
- 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
- 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 10]
-\f
+++ /dev/null
-
-
-Network Working Group B. Laurie
-Internet-Draft Nominet
-Expires: March 2, 2005 R. Loomis
- SAIC
- September 2004
-
-
-
- Requirements related to DNSSEC Signed Proof of Non-Existence
- draft-ietf-dnsext-signed-nonexistence-requirements-01
-
-
-Status of this Memo
-
-
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which he or she is aware have been or will be disclosed, and any of
- which he or she become aware will be disclosed, in accordance with
- RFC 3668.
-
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-
- This Internet-Draft will expire on March 2, 2005.
-
-
-Copyright Notice
-
-
- Copyright (C) The Internet Society (2004).
-
-
-Abstract
-
-
- DNSSEC-bis uses the NSEC record to provide authenticated denial of
- existence of RRsets. NSEC also has the side-effect of permitting
- zone enumeration, even if zone transfers have been forbidden.
- Because some see this as a problem, this document has been assembled
- to detail the possible requirements for denial of existence A/K/A
- signed proof of non-existence.
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 1]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
-Table of Contents
-
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Non-purposes . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. Zone Enumeration . . . . . . . . . . . . . . . . . . . . . . 3
- 4. Zone Enumeration II . . . . . . . . . . . . . . . . . . . . 4
- 5. Zone Enumeration III . . . . . . . . . . . . . . . . . . . . 4
- 6. Exposure of Contents . . . . . . . . . . . . . . . . . . . . 4
- 7. Zone Size . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 8. Single Method . . . . . . . . . . . . . . . . . . . . . . . 5
- 9. Empty Non-terminals . . . . . . . . . . . . . . . . . . . . 5
- 10. Prevention of Precomputed Dictionary Attacks . . . . . . . . 6
- 11. DNSSEC-Adoption and Zone-Growth Relationship . . . . . . . . 6
- 12. Non-overlap of denial records with possible zone records . . 7
- 13. Exposure of Private Keys . . . . . . . . . . . . . . . . . . 7
- 14. Minimisation of Zone Signing Cost . . . . . . . . . . . . . 8
- 15. Minimisation of Asymmetry . . . . . . . . . . . . . . . . . 8
- 16. Minimisation of Client Complexity . . . . . . . . . . . . . 8
- 17. Completeness . . . . . . . . . . . . . . . . . . . . . . . . 8
- 18. Purity of Namespace . . . . . . . . . . . . . . . . . . . . 8
- 19. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 8
- 20. Compatibility with NSEC . . . . . . . . . . . . . . . . . . 8
- 21. Compatibility with NSEC II . . . . . . . . . . . . . . . . . 9
- 22. Compatibility with NSEC III . . . . . . . . . . . . . . . . 9
- 23. Coexistence with NSEC . . . . . . . . . . . . . . . . . . . 9
- 24. Coexistence with NSEC II . . . . . . . . . . . . . . . . . . 9
- 25. Protocol Design . . . . . . . . . . . . . . . . . . . . . . 9
- 26. Process . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
- 28. Requirements notation . . . . . . . . . . . . . . . . . . . 9
- 29. Security Considerations . . . . . . . . . . . . . . . . . . 10
- 30. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 30.1 Normative References . . . . . . . . . . . . . . . . . . . 10
- 30.2 Informative References . . . . . . . . . . . . . . . . . . 10
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10
- Intellectual Property and Copyright Statements . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 2]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
-1. Introduction
-
-
- NSEC records allow trivial enumeration of zones - a situation that
- has existed for several years but which has recently been raised as a
- significant concern for DNSSECbis deployment in several zones.
- Alternate proposals have been made that make zone enumeration more
- difficult, and some previous proposals to modify DNSSEC had related
- requirements/desirements that are relevant to the discussion. In
- addition the original designs for NSEC/NXT records were based on
- working group discussions and the choices made were not always
- documented with context and requirements-- so some of those choices
- may need to be restated as requirements. Overall, the working group
- needs to better understand the requirements for denial of existence
- (and certain other requirements related to DNSSECbis deployment) in
- order to evaluate the proposals that may replace NSEC.
-
-
- In the remainder of this document, "NSEC++" is used as shorthand for
- "a denial of existence proof that will replace NSEC". "NSECbis" has
- also been used as shorthand for this, but we avoid that usage since
- NSECbis will not be part of DNSSECbis and therefore there might be
- some confusion.
-
-
-2. Non-purposes
-
-
- This document does not currently document the reasons why zone
- enumeration might be "bad" from a privacy, security, business, or
- other perspective--except insofar as those reasons result in
- requirements. Once the list of requirements is complete and vaguely
- coherent, the trade-offs (reducing zone enumeration will have X cost,
- while providing Y benefit) may be revisited. The editors of this
- compendium received inputs on the potential reasons why zone
- enumeration is bad (and there was significant discussion on the
- DNSEXT WG mailing list) but that information fell outside the scope
- of this document.
-
-
- Note also that this document does not assume that NSEC *must* be
- replaced with NSEC++, if the requirements can be met through other
- methods (e.g., "white lies" with the current NSEC). As is stated
- above, this document is focused on requirements collection and
- (ideally) prioritization rather than on the actual implementation.
-
-
-3. Zone Enumeration
-
-
- Authenticated denial should not permit trivial zone enumeration.
-
-
- Additional discussion: NSEC (and NXT before it) provide a linked
- list that could be "walked" to trivially enumerate all the signed
- records in a zone. This requirement is primarily (though not
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 3]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
- exclusively) important for zones that either are delegation-only/
- -mostly or do not have reverse lookup (PTR) records configured, since
- enterprises that have PTR records for all A records have already
- provided a similar capability to enumerate the contents of DNS zones.
-
-
- Contributor: various
-
-
-4. Zone Enumeration II
-
-
- Zone enumeration should be at least as difficult as it would be to
- effect a dictionary attack using simple DNS queries to do the same in
- an unsecured zone.
-
-
- (Editor comment: it is not clear how to measure difficulty in this
- case. Some examples could be monetary cost, bandwidth, processing
- power or some combination of these. It has also been suggested that
- the requirement is that the graph of difficulty of enumeration vs.
- the fraction of the zone enumerated should be approximately the same
- shape in the two cases)
-
-
- Contributor: Nominet
-
-
-5. Zone Enumeration III
-
-
- Enumeration of a zone with random contents should computationally
- infeasible.
-
-
- Editor comment: this is proposed as a way of evaluating the
- effectiveness of a proposal rather than as a requirement anyone would
- actually have in practice.
-
-
- Contributor: Alex Bligh
-
-
-6. Exposure of Contents
-
-
- NSEC++ should not expose any of the contents of the zone (apart from
- the NSEC++ records themselves, of course).
-
-
- Editor comment: this is a weaker requirement than prevention of
- enumeration, but certainly any zone that satisfied this requirement
- would also satisfy the trivial prevention of enumeration requirement.
-
-
- Contributor: Ed Lewis
-
-
-7. Zone Size
-
-
- Requirement: NSEC++ should make it possible to take precautions
- against trivial zone size estimates. Since not all zone owners care
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 4]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
- about others estimation of the size of a zone, it is not always
- necessary to prohibit trivial estimation of the size of the zone but
- NSEC++ should allow such measures.
-
-
- Additional Discussion: Even with proposals based on obfuscating names
- with hashes it is trivial to give very good estimates of the number
- of domains in a certain zone. Just send 10 random queries and look
- at the range between the two hash values returned in each NSEC++. As
- hash output can be assumed to follow a rectangular random
- distribution, using the mean difference between the two values, you
- can estimate the total number of records. It is probably sufficient
- to look at even one NSEC++, since the two hash values should follow a
- (I believe) Poisson distribution.
-
-
- The concern is motivated by some wording remembered from NSEC, which
- stated that NSEC MUST only be present for existing owner names in the
- zone, and MUST NOT be present for non-existing owner names. If
- similar wording were carried over to NSEC++, introducing bogus owner
- names in the hash chain (an otherwise simple solution to guard
- against trivial estimates of zone size) wouldn't be allowed.
-
-
- One simple attempt at solving this is to describe in the
- specifications how zone signer tools can add a number of random
- "junk" records.
-
-
- Editor's comment: it is interesting that obfuscating names might
- actually make it easier to estimate zone size.
-
-
- Contributor: Simon Josefsson.
-
-
-8. Single Method
-
-
- Requirement: A single NSEC++ method must be able to carry both
- old-style denial (i.e. plain labels) and whatever the new style
- looks like. Having two separate denial methods could result in
- cornercases where one method can deny the other and vice versa.
-
-
- Additional discussion: This requirement can help -bis folks to a
- smooth upgrade to -ter. First they'd change the method while the
- content is the same, then they can change content of the method.
-
-
- Contributor: Roy Arends.
-
-
-9. Empty Non-terminals
-
-
- Requirement: Empty-non-terminals (ENT) should remain empty. In
- other words, adding NSEC++ records to an existing DNS structure
- should not cause the creation of NSEC++ records (or related records)
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 5]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
- at points that are otherwise ENT.
-
-
- Additional discussion: Currently NSEC complies with ENT requirement:
- b.example.com NSEC a.c.example.com implies the existence of an ENT
- with ownername c.example.com. NSEC2 breaks that requirement, since
- the ownername is entirely hashed causing the structure to disappear.
- This is why EXIST was introduced. But EXIST causes ENT to be
- non-empty-terminals. Next to the dissappearance of ENT, it causes
- (some) overhead since an EXIST record needs a SIG, NSEC2 and
- SIG(NSEC2). DNSNR honours this requirement by hashing individual
- labels instead of ownernames. However this causes very long labels.
- Truncation is a measure against very long ownernames, but that is
- controversial. There is a fair discussion of the validity of
- truncation in the DNSNR draft, but that hasn't got proper review yet.
-
-
- Contributor: Roy Arends.
-
-
- (Editor comment: it is not clear to us that an EXIST record needs an
- NSEC2 record, since it is a special purpose record only used for
- denial of existence)
-
-
-10. Prevention of Precomputed Dictionary Attacks
-
-
- Requirement: NSEC++ needs to provide a method to reduce the
- effectiveness of precomputed dictionary attacks.
-
-
- Additional Discussion: Salt is a measure against dictionary attacks.
- There are other possible measures (such as iterating hashes in
- NSEC2). The salt needs to be communicated in every response, since
- it is needed in every verification. Some have suggested to move the
- salt to a special record instead of the denial record. I think this
- is not wise. Response size has more priority over zone size. An
- extra record causes a larger response than a larger existing record.
-
-
- Contributor: Roy Arends.
-
-
- (Editor comment: the current version of NSEC2 also has the salt in
- every NSEC2 record)
-
-
-11. DNSSEC-Adoption and Zone-Growth Relationship
-
-
- Background: Currently with NSEC, when a delegation centric zone
- deploys DNSSEC, the zone-size multiplies by a non-trivial factor even
- when the DNSSEC-adoption rate of the subzones remains low--because
- each delegation point creates at least one NSEC record and
- corresponding signature in the parent even if the child is not
- signed.
-
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 6]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
- Requirements: A delegation-only (or delegation-mostly) zone that is
- signed but which has no signed child zones should initially need only
- to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with some
- minimal set of NSEC++ records to cover zone contents. Further,
- during the transition of a delegation-only zone from 0% signed
- children to 100% signed children, the growth in the delegation-only
- zone should be roughly proportional to the percentage of signed child
- zones.
-
-
- Additional Discussion: This is why DNSNR has the Authoritative Only
- bit. This is similar to opt-in for delegations only. This (bit) is
- currently the only method to help delegation-centric zone cope with
- zone-growth due to DNSSEC adoption. As an example, A delegation only
- zone which deploys DNSSEC with the help of this bit, needs to add
- SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex. No
- more than that.
-
-
- Contributor: Roy Arends.
-
-
-12. Non-overlap of denial records with possible zone records
-
-
- Requirement: NSEC++ records should in some way be differentiated
- from regular zone records, so that there is no possibility that a
- record in the zone could be duplicated by a non-existence proof
- (NSEC++) record.
-
-
- Additional discussion: This requirement is derived from a discussion
- on the DNSEXT mailing list related to copyrights and domain names.
- As was outlined there, one solution is to put NSEC++ records in a
- separate namespace, e.g.: $ORIGIN co.uk.
- 873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your
- delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345...
- ; for amazon.co.uk.
-
-
- Contributor: various
-
-
- (Editor comment: One of us still does not see why a conflict
- matters. Even if there is an apparent conflict or overlap, the
- "conflicting" NSEC2 name _only_ appears in NSEC2 records, and the
- other name _never_ appears in NSEC2 records.)
-
-
-13. Exposure of Private Keys
-
-
- Private keys associated with the public keys in the DNS should be
- exposed as little as possible. It is highly undesirable for private
- keys to be distributed to nameservers, or to otherwise be available
- in the run-time environment of nameservers.
-
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 7]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
- Contributors: Nominet, Olaf Kolkman, Ed Lewis
-
-
-14. Minimisation of Zone Signing Cost
-
-
- The additional cost of creating an NSEC++ signed zone should not
- significantly exceed the cost of creating an ordinary signed zone.
-
-
- Contributor: Nominet
-
-
-15. Minimisation of Asymmetry
-
-
- Nameservers should have to do as little additional work as necessary.
- More precisely, it is desirable for any increase in cost incurred by
- the nameservers to be offset by a proportionate increase in cost to
- DNS `clients', e.g. stub and/or `full-service' resolvers.
-
-
- Contributor: Nominet
-
-
-16. Minimisation of Client Complexity
-
-
- Caching, wildcards, CNAMEs, DNAMEs should continue to work without
- adding too much complexity at the client side.
-
-
- Contributor: Olaf Kolkman
-
-
-17. Completeness
-
-
- A proof of nonexistence should be possible for all nonexistent data
- in the zone.
-
-
- Contributor: Olaf Kolkman
-
-
-18. Purity of Namespace
-
-
- The name space should not be muddied with fake names or data sets.
-
-
- Contributor: Ed Lewis
-
-
-19. Replay Attacks
-
-
- NSEC++ should not allow a replay to be used to deny existence of an
- RR that actually exists.
-
-
- Contributor: Ed Lewis
-
-
-20. Compatibility with NSEC
-
-
- NSEC++ should not introduce changes incompatible with NSEC.
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 8]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
- Contributor: Ed Lewis
-
-
-21. Compatibility with NSEC II
-
-
- NSEC++ should differ from NSEC in a way that is transparent to the
- resolver or validator.
-
-
- Contributor: Ed Lewis
-
-
-22. Compatibility with NSEC III
-
-
- NSEC++ should differ from NSEC as little as possible whilst achieving
- other requirements.
-
-
- Contributor: Alex Bligh
-
-
-23. Coexistence with NSEC
-
-
- NSEC++ should be optional, allowing NSEC to be used instead.
-
-
- Contributor: Ed Lewis, Alex Bligh
-
-
-24. Coexistence with NSEC II
-
-
- NSEC++ should not impose extra work on those content with NSEC.
-
-
- Contributor: Ed Lewis
-
-
-25. Protocol Design
-
-
- A good security protocol would allow signing the nonexistence of some
- selected names without revealing anything about other names.
-
-
- Contributor: Dan Bernstein
-
-
-26. Process
-
-
- Clearly not all of these requirements can be met. Therefore the next
- phase of this document will be to either prioritise them or narrow
- them down to a non-contradictory set, which should then allow us to
- judge proposals on the basis of their fit.
-
-
-27. Acknowledgements
-
-
-28. Requirements notation
-
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 9]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
- document are to be interpreted as described in [RFC2119].
-
-
-29. Security Considerations
-
-
- There are currently no security considerations called out in this
- draft. There will be security considerations in the choice of which
- requirements will be implemented, but there are no specific security
- requirements during the requirements collection process.
-
-
-30. References
-
-
-30.1 Normative References
-
-
- [dnssecbis-protocol]
- "DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some
- Month 2004.
-
-
-30.2 Informative References
-
-
- [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
- 3", BCP 9, RFC 2026, October 1996.
-
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
- [RFC2418] Bradner, S., "IETF Working Group Guidelines and
- Procedures", BCP 25, RFC 2418, September 1998.
-
-
-
-Authors' Addresses
-
-
- Ben Laurie
- Nominet
- 17 Perryn Road
- London W3 7LR
- England
-
-
- Phone: +44 (20) 8735 0686
- EMail: ben@algroup.co.uk
-
-
-
- Rip Loomis
- Science Applications International Corporation
- 7125 Columbia Gateway Drive, Suite 300
- Columbia, MD 21046
- US
-
-
- EMail: gilbert.r.loomis@saic.com
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 10]
-Internet-Draft signed-nonexistence-requirements September 2004
-
-
-
-Intellectual Property Statement
-
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Disclaimer of Validity
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Copyright Statement
-
-
- Copyright (C) The Internet Society (2004). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-
-Acknowledgment
-
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-Laurie & Loomis Expires March 2, 2005 [Page 11]
\ No newline at end of file
+++ /dev/null
-
-
-
-
-
-DNS Extensions Yuji Kamite
-Internet-Draft NTT Communications
-Expires: April 15, 2005 Masaya Nakayama
- The University of Tokyo
- October 14, 2004
-
-
-
- TKEY Secret Key Renewal Mode
- draft-ietf-dnsext-tkey-renewal-mode-05
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of section 3 of RFC 3667. By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which he or she is aware have been or will be disclosed, and any of
- which he or she become aware will be disclosed, in accordance with
- RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on April 15, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004).
-
-Abstract
-
- This document defines a new mode in TKEY and proposes an atomic
- method for changing secret keys used for TSIG periodically.
- Originally, TKEY provides methods of setting up shared secrets other
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 1]
-\f
-INTERNET-DRAFT October 2004
-
-
- than manual exchange, but it cannot control timing of key renewal
- very well though it can add or delete shared keys separately. This
- proposal is a systematical key renewal procedure intended for
- preventing signing DNS messages with old and non-safe keys
- permanently.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . 3
- 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . 4
- 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . 4
- 2. Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . 5
- 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . 5
- 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . 6
- 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . 7
- 2.3.1 Query for Key Renewal . . . . . . . . . . . . . . . . 7
- 2.3.2 Response for Key Renewal . . . . . . . . . . . . . . . 7
- 2.3.3 Attributes of Generated Key . . . . . . . . . . . . . 8
- 2.3.4 TKEY RR structure . . . . . . . . . . . . . . . . . . 8
- 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . 10
- 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . 10
- 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . 10
- 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . 11
- 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . 11
- 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . 12
- 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . 13
- 2.6 Considerations about Non-compliant Hosts . . . . . . . . . 14
- 3. Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . 15
- 4. Compulsory Key Revocation . . . . . . . . . . . . . . . . . . 15
- 4.1 Compulsory Key Revocation by Server . . . . . . . . . . . 15
- 4.2 Authentication Methods Considerations . . . . . . . . . . 15
- 5. Special Considerations for Two Servers' Case . . . . . . . . 16
- 5.1 To Cope with Collisions of Renewal Requests . . . . . . . 16
- 6. Key Name Considerations . . . . . . . . . . . . . . . . . . . 17
- 7. Example Usage of Secret Key Renewal Mode . . . . . . . . . . 17
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
- 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
- 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
- 11.1 Normative References . . . . . . . . . . . . . . . . . . . 21
- 11.2 Informative References . . . . . . . . . . . . . . . . . . 21
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
- Intellectual Property and Copyright Statements . . . . . . . . 23
-
-
-
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 2]
-\f
-INTERNET-DRAFT October 2004
-
-
-1. Introduction
-
- TSIG [RFC2845] provides DNS message integrity and the
- request/transaction authentication by means of message authentication
- codes (MAC). TSIG is a practical solution in view of calculation
- speed and availability. However, TSIG does not have exchanging
- mechanism of shared secret keys between server and resolver, and
- administrators might have to exchange secret keys manually. TKEY
- [RFC2930] is introduced to solve such problem and it can exchange
- secrets for TSIG via networks.
-
- In various modes of TKEY, a server and a resolver can add or delete a
- secret key be means of TKEY message exchange. However, the existing
- TKEY does not care fully about the management of keys which became
- too old, or dangerous after long time usage.
-
- It is ideal that the number of secret which a pair of hosts share
- should be limited only one, because having too many keys for the same
- purpose might not only be a burden to resolvers for managing and
- distinguishing according to servers to query, but also does not seem
- to be safe in terms of storage and protection against attackers.
- Moreover, perhaps holding old keys long time might give attackers
- chances to compromise by scrupulous calculation.
-
- Therefore, when a new shared secret is established by TKEY, the
- previous old secret should be revoked immediately. To accomplish
- this, DNS servers must support a protocol for key renewal. This
- document specifies procedure to refresh secret keys between two hosts
- which is defined within the framework of TKEY, and it is called "TKEY
- Secret Key Renewal Mode".
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and
- "OPTIONAL" in this document are to be interpreted as described in
- [RFC2119].
-
-
-1.1. Defined Words
-
- * Inception Time: Beginning of the shared secret key lifetime. This
- value is determined when the key is generated.
-
- * Expiry Limit: Time limit of the key's validity. This value is
- determined when a new key is generated. After Expiry Limit, server
- and client (resolver) must not authenticate TSIG signed with the key.
- Therefore, Renewal to the next key should be carried out before
- Expiry Limit.
-
- * Partial Revocation Time: Time when server judges the key is too old
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 3]
-\f
-INTERNET-DRAFT October 2004
-
-
- and must be updated. It must be between Inception Time and Expiry
- Limit. This value is determined by server freely following its
- security policy. e.g., If the time from Inception to Partial
- Revocation is short, renewal will be carried out more often, which
- might be safer.
-
- * Revocation Time: Time when the key becomes invalid and can be
- removed. This value is not determined in advance because it is the
- actual time when revocation is completed.
-
- * Adoption Time: Time when the new key is adopted as the next key
- formally. After Adoption, the key is valid and server and client can
- generate or verify TSIG making use of it. Adoption Time also means
- the time when it becomes possible to remove the previous key, so
- Revocation and Adoption are usually done at the same time.
-
-
- Partial
- Inception Revocation Revocation Expiry Limit
- | | | |
- |----------------|- - - - - - >>|- (revoked) -|
- | | | |
- previous key | | |
- |- - - -|-------------------->> time
- | | new key
- Inception Adoption
-
-
-1.2. New Format and Assigned Numbers
-
- TSIG
- ERROR = (PartialRevoke), TBD
-
- TKEY
- Mode = (server assignment for key renewal), TBD
- Mode = (Diffie-Hellman exchange for key renewal), TBD
- Mode = (resolver assignment for key renewal), TBD
- Mode = (key adoption), TBD
-
-
-1.3. Overview of Secret Key Renewal Mode
-
- When a server receives a query from a client signed with a TSIG key,
- It always checks if the present time is within the range of usage
- duration it considers safe. If it is judged that the key is too old,
- i.e., after Partial Revocation Time, the server comes to be in
- Partial Revocation state about the key, and this key is called
- partially revoked.
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 4]
-\f
-INTERNET-DRAFT October 2004
-
-
- In this state, if a client sends a normal query (e.g., question about
- A RR) other than TKEY Renewal request with TSIG signed with the old
- key, the server returns an error message to notify that the time to
- renew has come. This is called "PartialRevoke" error message. It is
- server's choice whether it returns PartialRevoke or not. If and only
- if the server is ready for changing its own key, it decides to return
- PartialRevoke.
-
- The client which got this error is able to notice that it is
- necessary to refresh the secret. To make a new shared secret, it
- sends a TKEY Renewal request, in which several keying methods are
- available. It can make use of TSIG authentication signed with the
- partially revoked key mentioned above.
-
- After new secret establishment, the client sends a TKEY Adoption
- request for renewal confirmation. This can also be authenticated with
- the partially revoked key. If this is admitted by the server, the new
- key is formally adopted, and at the same time the corresponding old
- secret is invalidated. Then the client can send the first query again
- signed with the new key.
-
- Key renewal procedure is executed based on two-phase commit
- mechanism. The first phase is the TKEY Renewal request and its
- response, which means preparatory confirmation for key update. The
- second phase is Adoption request and its response. If the server gets
- request and client receives the response successfully, they can
- finish renewal process. If any error happens and renewal process
- fails during these phases, client should roll back to the beginning
- of the first phase, and send TKEY Renewal request again. This
- rollback can be done until the Expiry Limit of the key.
-
-
-2. Shared Secret Key Renewal
-
- Suppose a server and a client agree to change their TSIG keys
- periodically. Key renewal procedure is defined between two hosts.
-
-2.1. Key Usage Time Check
-
- Whenever a server receives a query with TSIG and can find a key that
- is used for signing it, the server checks its Inception Time, Partial
- Revocation Time and Expiry Limit (this information is usually
- memorized by the server).
-
- When the present time is before Inception Time, the server MUST NOT
- verify TSIG with the key, and server acts the same way as when the
- key used by the client is not recognized. It follows [RFC2845] 4.5.1.
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 5]
-\f
-INTERNET-DRAFT October 2004
-
-
- When the present time is equal to Inception Time, or between
- Inception Time and Partial Revocation Time, the behavior of the
- server is the same as when a valid key is found. It follows [RFC2845]
- 4.5.2 and 4.5.3.
-
- When the present time is the same as the Partial Revocation Time, or
- between the Partial Revocation Time and Expiry Limit, the server
- comes to be in Partial Revocation state about the TSIG key and
- behaves according to the next section.
-
- When the present time is the same as the Expiry Time or after it, the
- server MUST NOT verify TSIG with the key, and returns error messages
- in the same way as when the key used by the client is not recognized.
- It follows [RFC2845] 4.5.1.
-
-
-2.2. Partial Revocation
-
- In Partial Revocation state, we say the server has partially revoked
- the key and the key has become a "partially revoked key".
-
- If server has received a query signed with the partially revoked key
- for TKEY Renewal request (See section 2.3.) or Key Adoption request
- (See section 2.4.), then server does proper process following each
- specification. If it is for TKEY key deletion request ([RFC2930]
- 4.2), server MAY process usual deletion operation defined therein.
-
- If server receives other types of query signed with the partially
- revoked key, and both the corresponding MAC and signed TIME are
- verified, then server begins returning answer whose TSIG error code
- is "PartialRevoke" (See section 9.). Server MUST randomly but with
- increasing frequency return PartialRevoke when in the Partial
- Revocation state.
-
- Server can decide when it actually sends PartialRevoke, checking if
- it is appropriate time for renewal. Server MUST NOT return
- PartialRevoke if this is apart long lived TSIG transaction (such as
- AXFR) that started before the Partial Revocation Time.
-
- If the client receives PartialRevoke and understands it, then it MUST
- retry the query with the old key unless a new key has been adopted.
- Client SHOULD start the process to renew the TSIG key. For key
- renewal procedure, see details in Section 2.3 and 2.4.
-
- PartialRevoke period (i.e., time while server returns PartialRevoke
- randomely) SHOULD be small, say 2-5% of key lifetime. This is
- server's choice.
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 6]
-\f
-INTERNET-DRAFT October 2004
-
-
- Server MUST keep track of clients ignoring PartialRevoke, thus
- indicating ignorance of this TKEY mode.
-
- PartialRevoke error messages have the role to inform clients of the
- keys' partial revocation and urge them to send TKEY Renewal requests.
- These error responses MUST be signed with those partial revoked keys
- if the queries are signed with them. They are sent only when the
- signing keys are found to be partially revoked. If the MAC of TSIG
- cannot be verified with the partially revoked keys, servers MUST NOT
- return PartialRevoke error with MAC, but MUST return another error
- such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other
- words, a server informs its key's partial revocation only when the
- MAC in the received query is valid.
-
-
-2.3. Key Renewal Message Exchange
-
-2.3.1. Query for Key Renewal
-
- If a client has received a PartialRevoke error and authenticated the
- response based on TSIG MAC, it sends a TKEY query for Key Renewal (in
- this document, we call it Renewal request, too.) to the server. The
- request MUST be signed with TSIG or SIG(0) [RFC2931] for
- authentication. If TSIG is selected, the client can sign it with the
- partial revoked key.
-
- Key Renewal can use one of several keying methods which is indicated
- in "Mode" field of TKEY RR, and its message structure is dependent on
- that method.
-
-
-2.3.2. Response for Key Renewal
-
- The server which has received Key Renewal request first tries to
- verify TSIG or SIG(0) accompanying it. If the TSIG is signed and
- verified with the partially revoked key, the request MUST be
- authenticated.
-
- After authentication, server must check existing old key's validity.
- If the partially revoked key indicated in the request TKEY's OldName
- and OldAlgorithm field (See section 2.3.4.) does not exist at the
- server, "BADKEY" [RFC2845] is given in Error field for response. If
- any other error happens, server returns appropriate error messages
- following the specification described in section 2.5. If there are no
- errors, server returns a Key Renewal answer. This answer MUST be
- signed with TSIG or SIG(0) for authentication.
-
- When this answer is successfully returned and no error is detected by
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 7]
-\f
-INTERNET-DRAFT October 2004
-
-
- client, a new shared secret can be established. The details of
- concrete keying procedure are given in the section 2.5.
-
- Note:
- Sometimes Adoption message and new Renewal request will cross on
- the wire. In this case the newly generated key Adoption message is
- resent.
-
-
-2.3.3. Attributes of Generated Key
-
- As a result of this message exchange, client comes to know the newly
- generated key's attributes such as key's name, Inception Time and
- Expiry Limit. They are decided by the server and told to the client;
- in particular, however, once the server has decided Expiry Limit and
- returned a response, it should obey the decision as far as it can. In
- other words, they SHOULD NOT change time values for checking Expiry
- Limit in the future without any special reason, such as security
- issue like "Emergency Compulsory Revocation" described in section 8.
-
- On the other hand, Partial Revocation Time of this generated key is
- not decided based on the request, and not informed to the client. The
- server can determine any value as long as it is between Inception
- Time and Expiry Limit. However, the period from Inception to Partial
- Revocation SHOULD be fixed as the server side's configuration or be
- set the same as the corresponding old key's one.
-
- Note:
- Even if client sends Key Renewal request though the key described
- in OldName has not been partially revoked yet, server does renewal
- processes. At the moment when the server accepts such requests
- with valid authentication, it MUST forcibly consider the key is
- already partially revoked, that is, the key's Partial Revocation
- Time must be changed into the present time (i.e., the time when
- the server receives the request).
-
-
-2.3.4. TKEY RR structure
-
- TKEY RR for Key Renewal message has the structure given below. In
- principle, format and definition for each field follows [RFC2930].
- Note that each keying scheme sometimes needs different interpretation
- of RDATA field; for detail, see section 2.5.
-
- Field Type Comment
- ------- ------ -------
- NAME domain used for a new key, see below
- TYPE u_int16_t (defined in [RFC2930])
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 8]
-\f
-INTERNET-DRAFT October 2004
-
-
- CLASS u_int16_t (defined in [RFC2930])
- TTL u_int32_t (defined in [RFC2930])
- RDLEN u_int16_t (defined in [RFC2930])
- RDATA:
- Algorithm: domain algorithm for a new key
- Inception: u_int32_t about the keying material
- Expiration: u_int32_t about the keying material
- Mode: u_int16_t scheme for key agreement
- see section 9.
- Error: u_int16_t see description below
- Key Size: u_int16_t see description below
- Key Data: octet-stream
- Other Size: u_int16_t (defined in [RFC2930])
- size of other data
- Other Data: newly defined: see description below
-
-
- For "NAME" field, both non-root and root name are allowed. It may
- be used for a new key's name in the same manner as [RFC2930] 2.1.
-
- "Algorithm" specifies which algorithm is used for agreed keying
- material, which is used for identification of the next key.
-
- "Inception" and "Expiration" are used for the valid period of
- keying material. The meanings differ somewhat according to whether
- the message is request or answer, and its keying scheme.
-
- "Key Data" has different meanings according to keying schemes.
-
- "Mode" field stores the value in accordance with the keying method,
- and see section 2.5. Servers and clients supporting TKEY Renewal
- method MUST implement "Diffie-Hellman exchange for key renewal"
- scheme. All other modes are OPTIONAL.
-
- "Error" is an extended RCODE which includes "PartialRevoke" value
- too. See section 9.
-
- "Other Data" field has the structure given below. They describe
- attributes of the key to be renewed.
-
- in Other Data filed:
-
- Field Type Comment
- ------- ------ -------
- OldNAME domain name of the old key
- OldAlgorithm domain algorithm of the old key
-
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 9]
-\f
-INTERNET-DRAFT October 2004
-
-
- "OldName" indicates the name of the previous key (usually,
- this is partially revoked key's name that client noticed by
- PartialRevoke answer from server), and "OldAlogirthm"
- indicates its algorithm.
-
-
-2.4. Key Adoption
-
-2.4.1. Query for Key Adoption
-
- After receiving a TKEY Renewal answer, the client gets the same
- secret as the server. Then, it sends a TKEY Adoption request. The
- request's question section's QNAME field is the same as the NAME
- filed of TKEY written below. In additional section, there is one TKEY
- RR that has the structure and values described below.
-
- "NAME" field is the new key's name to be adopted which was already
- generated by Renewal message exchange. "Algorithm" is its
- algorithm. "Inception" means the key's Inception Time, and
- "Expiration" means Expiry Limit.
-
- "Mode" field is the value of "key adoption". See section 9.
-
- "Other Data" field in Adoption has the same structure as that of
- Renewal request message. "OldName" means the previous old key, and
- "OldAlogirthm" means its algorithm.
-
- Key Adoption request MUST be signed with TSIG or SIG(0) for
- authentication. The client can sign TSIG with the previous key. Note
- that until Adoption is finished, the new key is treated as invalid,
- thus it cannot be used for authentication immediately.
-
-
-2.4.2. Response for Key Adoption
-
- The server which has received Adoption request, it verifies TSIG or
- SIG(0) accompanying it. If the TSIG is signed with the partially
- revoked key and can be verified, the message MUST be authenticated.
-
- If the next new key indicated by the request TKEY's "NAME" is not
- present at the server, BADNAME [RFC2845] is given in Error field and
- the error message is returned.
-
- If the next key exists but it has not been adopted formally yet, the
- server confirms the previous key's existence indicated by the
- "OldName" and "OldAlgorithm" field. If it succeeds, the server
- executes Adoption of the next key and Revocation of the previous key.
- Response message duplicates the request's TKEY RR with NOERROR,
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 10]
-\f
-INTERNET-DRAFT October 2004
-
-
- including "OldName" and "OldAlgorithm" that indicate the revoked key.
-
- If the next key exists but it is already adopted, the server returns
- a response message regardless of the substance of the request TKEY's
- "OldName". In this response, Response TKEY RR has the same data as
- the request's one except as to its "Other Data" that is changed into
- null (i.e., "Other Size" is zero), which is intended for telling the
- client that the previous key name was ignored, and the new key is
- already available.
-
- Client sometimes has to retry Adoption request. Suppose the client
- sent request signed with the partially revoked key, but its response
- did not return successfully (e.g., due to the drop of UDP packet).
- Client will probably retry Adoption request; however, the request
- will be refused in the form of TSIG "BADKEY" error because the
- previous key was already revoked. In this case, client will
- retransmit Adoption request signed with the next key, and expect a
- response which has null "Other Data" for confirming the completion of
- renewal.
-
-
-2.5. Keying Schemes
-
- In Renewal message exchanges, there are no limitations as to which
- keying method is actually used. The specification of keying
- algorithms is independent of the general procedure of Renewal that is
- described in section 2.3.
-
- Now this document specifies three algorithms in this section, but
- other future documents can make extensions defining other methods.
-
-
-2.5.1. DH Exchange for Key Renewal
-
- This scheme is defined as an extended method of [RFC2930] 4.1. This
- specification only describes the difference from it and special
- notice; assume that all other points, such as keying material
- computation, are the exactly same as the specification of [RFC2930]
- 4.1.
-
- Query
- In Renewal request for type TKEY with this mode, there is one TKEY
- RR and one KEY RR in the additional information section. KEY RR is
- the client's Diffie-Hellman public key [RFC2539].
-
- QNAME in question section is the same as that of "NAME" field in
- TKEY RR, i.e., it means the requested new key's name.
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 11]
-\f
-INTERNET-DRAFT October 2004
-
-
- TKEY "Mode" field stores the value of "DH exchange for key
- renewal". See section 9.
-
- TKEY "Inception" and "Expiration" are those requested for the
- keying material, that is, requested usage period of a new key.
-
- TKEY "Key Data" is used as a random, following [RFC2930] 4.1.
-
- Response
- The server which received this request first verifies the TSIG,
- SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
- old key's existence validity is checked, following section 2.3. If
- any incompatible DH key is found in the request, "BADKEY"
- [RFC2845] is given in Error field for response. "FORMERR" is given
- if the query included no DH KEY.
-
- If there are no errors, the server processes a response according
- to Diffie-Hellman algorithm and returns the answer. In this
- answer, there is one TKEY RR in answer section and KEY RR(s) in
- additional section.
-
- As long as no error has occurred, all values of TKEY are equal to
- that of the request message except TKEY NAME, TKEY RDLEN, RDATA's
- Inception, Expiration, Key Size and Key Data.
-
- TKEY "NAME" field in the answer specifies the name of newly
- produced key which the client MUST use.
-
- TKEY "Inception" and "Expiration" mean the periods of the produced
- key usage. "Inception" is set to be the time when the new key is
- actually generated or the time before it, and it will be regarded
- as Inception Time. "Expiration" is determined by the server, and
- it will be regarded as Expiry Limit.
-
- TKEY "Key Data" is used as an additional nonce, following
- [RFC2930] 4.1.
-
- The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in
- the additional section and a server Diffie-Hellman KEY RR will
- also be present in the answer section, following [RFC2930] 4.1.
-
-
-2.5.2. Server Assigned Keying for Key Renewal
-
- This scheme is defined as an extended method of [RFC2930] 4.4. This
- specification only describes the difference from it and special
- notice; assume that all other points, such as secret encrypting
- method, are the exactly same as the specification of [RFC2930] 4.4.
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 12]
-\f
-INTERNET-DRAFT October 2004
-
-
- Query
- In Renewal request for type TKEY with this mode, there is one TKEY
- RR and one KEY RR in the additional information section. KEY RR is
- used in encrypting the response.
-
- QNAME in question section is the same as that of "NAME" field in
- TKEY RR, i.e., it means the requested new key's name.
-
- TKEY "Mode" field stores the value of "server assignment for key
- renewal". See section 9.
-
- TKEY "Inception" and "Expiration" are those requested for the
- keying material, that is, requested usage period of a new key.
-
- TKEY "Key Data" is provided following the specification of
- [RFC2930] 4.4.
-
- Response
- The server which received this request first verifies the TSIG,
- SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
- old key's existence validity is checked, following section 2.3.
- "FORMERR" is given if the query specified no encryption key.
-
- If there are no errors, the server response contains one TKEY RR
- in the answer section, and echoes the KEY RR provided in the query
- in the additional information section.
-
- TKEY "NAME" field in the answer specifies the name of newly
- produced key which the client MUST use.
-
- TKEY "Inception" and "Expiration" mean the periods of the produced
- key usage. "Inception" is set to be the time when the new key is
- actually generated or the time before it, and it will be regarded
- as Inception Time. "Expiration" is determined by the server, and
- it will be regarded as Expiry Limit.
-
- TKEY "Key Data" is the assigned keying data encrypted under the
- public key in the resolver provided KEY RR, which is the same as
- [RFC2930] 4.4.
-
-
-2.5.3. Resolver Assigned Keying for Key Renewal
-
- This scheme is defined as an extended method of [RFC2930] 4.5. This
- specification only describes the difference from it and special
- notice; assume that all other points, such as secret encrypting
- method, are the exactly same as the specification of [RFC2930] 4.5.
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 13]
-\f
-INTERNET-DRAFT October 2004
-
-
- Query
- In Renewal request for type TKEY with this mode, there is one TKEY
- RR and one KEY RR in the additional information section. TKEY RR
- has the encrypted keying material and KEY RR is the server public
- key used to encrypt the data.
-
- QNAME in question section is the same as that of "NAME" field in
- TKEY RR, i.e., it means the requested new key's name.
-
- TKEY "Mode" field stores the value of "resolver assignment for key
- renewal". See section 9.
-
- TKEY "Inception" and "Expiration" are those requested for the
- keying material, that is, requested usage period of a new key.
-
- TKEY "Key Data" is the encrypted keying material.
-
- Response
- The server which received this request first verifies the TSIG,
- SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
- old key's existence validity is checked, following section 2.3.
- "FORMERR" is given if the server does not have the corresponding
- private key for the KEY RR that was shown sin the request.
-
- If there are no errors, the server returns a response. The
- response contains a TKEY RR in the answer section to tell the
- shared key's name and its usage time values.
-
- TKEY "NAME" field in the answer specifies the name of newly
- produced key which the client MUST use.
-
- TKEY "Inception" and "Expiration" mean the periods of the produced
- key usage. "Inception" is set to be the time when the new key is
- actually generated or the time before it, and it will be regarded
- as Inception Time. "Expiration" is determined by the server, and
- it will be regarded as Expiry Limit.
-
-
-2.6. Considerations about Non-compliant Hosts
-
- Key Renewal requests and responses must be exchanged between hosts
- which can understand them and do proper processes. PartialRevoke
- error messages will be only ignored if they should be returned to
- non-compliant hosts.
-
- Note that server does not inform actively the necessity of renewal to
- clients, but inform it as responses invoked by client's query.
- Server needs not care whether the PartialRevoke errors has reached
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 14]
-\f
-INTERNET-DRAFT October 2004
-
-
- client or not. If client has not received yet because of any reasons
- such as packet drops, it will resend the queries, and finally will be
- able to get PartialRevoke information.
-
-
-3. Secret Storage
-
- Every server keeps all secrets and attached information, e.g.,
- Inception Time, Expiry Limit, etc. safely to be able to recover from
- unexpected stop. To accomplish this, formally adopted keys SHOULD be
- memorized not only on memory, but also be stored in the form of some
- files. It will become more secure if they are stored in ecrypted
- form.
-
-
-4. Compulsory Key Revocation
-
-4.1. Compulsory Key Revocation by Server
-
- There is a rare but possible case that although servers have already
- partially revoked keys, clients do not try to send any Renewal
- requests. If this state continues, in the future it will become the
- time of Expiry Limit. After Expiry Limit, the keys will be expired
- and completely removed, so this is called Compulsory Key Revocation
- by server.
-
- If Expiry Limit is too distant from the Partial Revocation Time, then
- even though very long time passes, clients will be able to refresh
- secrets only if they add TSIG signed with those old partially revoked
- keys into requests, which is not safe.
-
- On the other hand, if Expiry Limit is too close to Partial Revocation
- Time, perhaps clients might not be able to notice their keys' Partial
- Revocation by getting "PartialRevoke" errors.
-
- Therefore, servers should set proper Expiry Limit to their keys,
- considering both their keys' safety, and enough time for clients to
- send requests and process renewal.
-
-
-4.2. Authentication Methods Considerations
-
- It might be ideal to provide both SIG(0) and TSIG as authentication
- methods. For example:
-
- A client and a server start SIG(0) authentication at first, to
- establish TSIG shared keys by means of "Query for Diffie-Hellman
- Exchanged Keying" as described in [RFC2930] 4.1. Once they get
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 15]
-\f
-INTERNET-DRAFT October 2004
-
-
- shared secret, they keep using TSIG for queries and responses.
- After a while the server returns a "ParitalRevoke" error and they
- begin a key renewal process. Both TSIG signed with partially
- revoked keys and SIG(0) are okay for authentication, but TSIG would
- be easier to use considering calculation efficiency.
-
- Suppose now client is halted for long time with some reason.
- Because server does not execute any renewal process, it will
- finally do Compulsory Revocation. Even if client restarts and sends
- a key Renewal request, it will fail because old key is already
- deleted at server.
-
- At this moment, however, if client also uses SIG(0) as another
- authentication method, it can make a new shared key again and
- recover successfully by sending "Query for Diffie-Hellman Exchanged
- Keying" with SIG(0).
-
-
-5. Special Considerations for Two servers' Case
-
- This section refers to the case where both hosts are DNS servers
- which can act as full resolvers as well and using one shared key
- only. If one server (called Server A) wants to refresh a shared key
- (called "Key A-B"), it will await a TKEY Renewal request from the
- other server (called Server B). However, perhaps Server A wants to
- refresh the key right now.
-
- In this case, Server A is allowed to send a Renewal request to Server
- B, if Server A knows the Key A-B is too old and wants to renew it
- immediately.
-
- Note that the initiative in key renewal belongs to Server A because
- it can notice the Partial Revocation Time and decide key renewal. If
- Server B has information about Partial Revocation Time as well, it
- can also decide for itself to send Renewal request to Server A.
- However, it is not essential for both two servers have information
- about key renewal timing.
-
-5.1. To Cope with Collisions of Renewal Requests
-
- At least one of two hosts which use Key Renewal must know their key
- renewal information such as Partial Revocation Time. It is okay that
- both hosts have it.
-
- Provided that both two servers know key renewal timing information,
- there is possibility for them to begin partial revocation and sending
- Renewal requests to each other at the same time. Such collisions will
- not happen so often because Renewal requests are usually invoked when
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 16]
-\f
-INTERNET-DRAFT October 2004
-
-
- hosts want to send queries, but it is possible.
-
- When one of two servers tries to send Renewal requests, it MUST
- protect old secrets that it has partially revoked and prevent it from
- being refreshed by any requests from the other server (i.e., it must
- lock the old secret during the process of renewal). While the server
- is sending Renewal requests and waiting responses, it ignores the
- other server's Renewal requests.
-
- Therefore, servers might fail to change secrets by means of their own
- requests to others. After failure they will try to resend, but they
- should wait for random delays by the next retries. If they get any
- Renewal requests from others while they are waiting, their shared
- keys may be refreshed, then they do not need to send any Renewal
- requests now for themselves.
-
-
-6. Key Name Considerations
-
- Since both servers and clients have only to distinguish new secrets
- and old ones, keys' names do not need to be specified strictly.
- However, it is recommended that some serial number or key generation
- time be added to the name and that the names of keys between the same
- pair of hosts should have some common labels among their keys. For
- example, suppose A.example.com. and B.example.com. share the key
- "<serial number>.A.example.com.B.example.com." such as
- "10010.A.example.com.B.example.com.". After key renewal, they change
- their secret and name into "10011.A.example.com.B.example.com."
-
- Servers and clients must be able to use keys properly for each query.
- Because TSIG secret keys themselves do not have any particular IDs to
- be distinguished and would be identified by their names and
- algorithm, it must be understood correctly what keys are refreshed.
-
-
-7. Example Usage of Secret Key Renewal Mode
-
- This is an example of Renewal mode usage where a Server,
- server.example.com, and a Client, client.exmple.com have an initial
- shared secret key named "00.client.example.com.server.example.com".
-
- (1) The time values for key
- "00.client.example.com.server.example.com" was set as follows:
- Inception Time is at 1:00, Expiry Limit is at 21:00.
-
- (2) At Server, renewal time has been set: Partial Revocation Time
- is at 20:00.
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 17]
-\f
-INTERNET-DRAFT October 2004
-
-
- (3) Suppose the present time is 19:55. If Client sends a query
- signed with key "00.client.example.com.server.example.com" to ask
- the IP address of "www.example.com", finally it will get a proper
- answer from Server with valid TSIG (NOERROR).
-
- (4) At 20:05. Client sends a query to ask the IP address of
- "www2.example.com". It is signed with key
- "00.client.example.com.server.example.com". Server returns an
- answer for the IP address. However, server has begun retuning
- PartialRevoke Error randomely. This answer includes valid TSIG MAC
- signed with "00.client.example.com.server.example.com", and its
- Error Code indicates PartialRevoke. Client understands that the
- current key is partially revoked.
-
- (5) At 20:06. Client sends a Renewal request to Server. This
- request is signed with key
- "00.client.example.com.server.example.com". It includes data such
- as:
-
- Question Section:
- QNAME = 01.client.example.com. (Client can set this freely)
- TYPE = TKEY
-
- Additional Section:
- 01.client.example.com. TKEY
- Algorithm = hmac-md5-sig-alg.reg.int.
- Inception = (value meaning 20:00)
- Expiration = (value meaning next day's 16:00)
- Mode = (DH exchange for key renewal)
- OldName = 00.client.example.com.server.example.com.
- OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
- Additional Section also contains a KEY RR for DH and a TSIG RR.
-
- (6) As soon as Server receives this request, it verifies TSIG. It
- is signed with the partially revoked key
- "00.client.example.com.server.example.com". and Server accepts the
- request. It creates a new key by Diffie-Hellman calculation and
- returns an answer which includes data such as:
-
- Answer Section:
- 01.client.example.com.server.example.com. TKEY
- Algorithm = hmac-md5-sig-alg.reg.int.
- Inception = (value meaning 20:00)
- Expiration = (value meaning next day's 16:00)
- Mode = (DH exchange for key renewal)
- OldName = 00.client.example.com.server.example.com.
- OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 18]
-\f
-INTERNET-DRAFT October 2004
-
-
- Answer Section also contains KEY RRs for DH.
-
- Additional Section also contains a TSIG RR.
- This response is signed with key
- "00.client.example.com.server.example.com" without error.
-
- At the same time, Server decides to set the Partial Revocation Time
- of this new key "01.client.example.com.server.example.com." as next
- day's 15:00.
-
- (7) Client gets the response and checks TSIG MAC, and calculates
- Diffie-Hellman. It will get a new key, and it has been named
- "01.client.example.com.server.example.com" by Server.
-
- (8) At 20:07. Client sends an Adoption request to Server. This
- request is signed with the previous key
- "00.client.example.com.server.example.com". It includes:
-
- Question Section:
- QNAME = 01.client.example.com.server.example.com.
- TYPE = TKEY
-
- Additional Section:
- 01.client.example.com.server.example.com. TKEY
- Algorithm = hmac-md5-sig-alg.reg.int.
- Inception = (value meaning 20:00)
- Expiration = (value meaning next day's 16:00)
- Mode = (key adoption)
- OldName = 00.client.example.com.server.example.com.
- OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
- Additional Section also contains a TSIG RR.
-
- (9) Server verifies the query's TSIG. It is signed with the
- previous key and authenticated. It returns a response whose TKEY RR
- is the same as the request's one. The response is signed with key
- "00.client.example.com.server.example.com.". As soon as the
- response is sent, Server revokes and removes the previous key. At
- the same time, key "01.client.example.com.server.example.com." is
- validated.
-
- (10) Client acknowledges the success of Adoption by receiving the
- response. Then, it retries to send an original question about
- "www2.example.com". It is signed with the adopted key
- "01.client.example.com.server.example.com", so Server authenticates
- it and returns an answer.
-
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 19]
-\f
-INTERNET-DRAFT October 2004
-
-
- (11) This key is used until next day's 15:00. After that, it will
- be partially revoked again.
-
-
-8. Security Considerations
-
- This document considers about how to refresh shared secret. Secret
- changed by this method is used at servers in support of TSIG
- [RFC2845].
-
- [RFC2104] says that current attacks to HMAC do not indicate a
- specific recommended frequency for key changes but periodic key
- refreshment is a fundamental security practice that helps against
- potential weaknesses of the function and keys, and limits the damage
- of an exposed key. TKEY Secret Key Renewal provides the method of
- periodical key refreshment.
-
- In TKEY Secret Key Renewal, clients need to send two requests
- (Renewal and Adoption) and spend time to finish their key renewal
- processes. Thus the usage period of secrets should be considered
- carefully based on both TKEY processing performance and security.
-
- This document specifies the procedure of periodical key renewal, but
- actually there is possibility for servers to have no choice other
- than revoking their secret keys immediately especially when the keys
- are found to be compromised by attackers. This is called "Emergency
- Compulsory Revocation". For example, suppose the original Expiry
- Limit was set at 21:00, Partial Revocation Time at 20:00 and
- Inception Time at 1:00. if at 11:00 the key is found to be
- compromised, the server sets Expiry Limit forcibly to be 11:00 or
- before it.
-
- Consequently, once Compulsory Revocation (See section 4.) is carried
- out, normal renewal process described in this document cannot be done
- any more as far as the key is concerned. However, after such
- accidents happened, the two hosts are able to establish secret keys
- and begin renewal procedure only if they have other (non-compromised)
- shared TSIG keys or safe SIG(0) keys for the authentication of
- initial secret establishment such as Diffie-Hellman Exchanged Keying.
-
-
-9. IANA Considerations
-
- IANA needs to allocate a value for "DH exchange for key renewal",
- "server assignment for key renewal", "resolver assignment for key
- renewal" and "key adoption" in the mode filed of TKEY. It also needs
- to allocate a value for "PartialRevoke" from the extended RCODE
- space.
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 20]
-\f
-INTERNET-DRAFT October 2004
-
-
-10. Acknowledgements
-
- The authors would like to thank Olafur Gudmundsson, whose helpful
- input and comments contributed greatly to this document.
-
-
-11. References
-
-11.1. Normative References
-
-[RFC2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119, March 1997.
-
-[RFC2539]
- D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name
- System (DNS)", RFC 2539, March 1999.
-
-[RFC2845]
- Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845,
- May 2000.
-
-[RFC2930]
- D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'',
- RFC 2930, September 2000.
-
-[RFC2931]
- D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s
- )", RFC 2931, September 2000.
-
-11.2. Informative References
-
-[RFC2104]
- H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
- Authentication", RFC2104, February 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 21]
-\f
-INTERNET-DRAFT October 2004
-
-
-Authors' Addresses
-
- Yuji Kamite
- NTT Communications Corporation
- Tokyo Opera City Tower
- 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo
- 163-1421, Japan
- EMail: y.kamite@ntt.com
-
-
- Masaya Nakayama
- Information Technology Center, The University of Tokyo
- 2-11-16 Yayoi, Bunkyo-ku, Tokyo
- 113-8658, Japan
- EMail: nakayama@nc.u-tokyo.ac.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 22]
-\f
-INTERNET-DRAFT October 2004
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2004). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Kamite, et. al. Expires April 15, 2005 [Page 23]
-\f
-
-
projects / thirdparty / bind9.git / commitdiff
