diff --git a/doc/draft/draft-ietf-dnsext-delegation-signer-01.txt b/doc/draft/draft-ietf-dnsext-delegation-signer-01.txt deleted file mode 100644 index 9c3c892d3e..0000000000 --- a/doc/draft/draft-ietf-dnsext-delegation-signer-01.txt +++ /dev/null @@ -1,618 +0,0 @@ - - - - - - - DNSEXT Working Group Olafur Gudmundsson - INTERNET-DRAFT July 2001 - - - Updates: RFC 1035, RFC 2535, RFC 3008. - - - Delegation Signer record in parent. - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. - - 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 - - Comments should be sent to the authors or the DNSEXT WG mailing list - namedroppers@ops.ietf.org - - This draft expires on January 15, 2002. - - Copyright Notice - - Copyright (C) The Internet Society (2001). All rights reserved. - - - -Abstract - - One of the biggest problems in DNS occur when records of the same type - can appear on both sides of an delegation. If the contents of these - sets differs clients can get confused. RFC2535 KEY records follows - the same model as for NS records, parent is responsible for the - records but the child is responsible for the contents. This document - - - -Gudmundsson Expires January 2002 [Page 1] - -INTERNET-DRAFT Delegation Signer Record July 2001 - - - proposes to store a different record in the parent that specifies - which one of the child's keys are authorized to sign the child's KEY - set. This change is not backwards compatible with RFC2535 but - simplifies DNSSEC operation. - - -1 - Introduction - - Familiarity with the DNS system [RFC1035], DNS security extensions - [RFC2535] and DNSSEC terminology [RFC3090] is important. - - When the same data can reside in two administratively different DNS - zones sources it is common that the data gets out of sync. NS record - in a zone indicates that there is a delegation at this name and the NS - record lists the authorative servers for the real zone. Based on - actual measurements 10-30% of all delegations in the Internet have - differing NS sets at parent and child. There are number of reasons for - this, including lack of communication between parent and child and - bogus name-servers being listed to meet registrar requirements. - - DNSSEC [RFC2535,RFC3008,RFC3090] specifies that child must have its - KEY set signed by the parent to create a verifiable chain of KEYs. - There is some debate, where the signed KEY set should reside, - parent[Parent] or child[RFC2535]. If the KEY set resides at the child, - frequent communication is needed between the two parties, to transmit - key sets up to parent and then the signed set or signatures down to - child. If the KEY set resides at the parent[Parent] the communication - is reduced having only child send updated key sets to parent. - DNSSEC[RFC2535] requires that the parent store NULL key set for - unsecure children, this complicates resolution process as in many - cases as servers for both parent and child need to be queried for KEY - set the [Parent] proposal simplifies this. - - Further complication of the DNSSEC KEY model is that KEY record is - used to store DNS zone keys and public keys for other protocols. This - can lead to large key sets at delegation points. There are number of - potential problems with this including: - 1. KEY set may become quite large if many applications/protocols store - their keys at the zone apex. Example of protocols are IPSEC, HTTP, - SMTP, SSH etc. - 2. Key set may require frequent updates. - 3. Probability of compromised/lost keys increases and triggers - emergency key rollover. - 4. Parent may refuse sign key sets with NON DNS zone keys. - 5. Parent may not have QoS on key changes that meets child's - expectations. - - - - - -Gudmundsson Expires January 2002 [Page 2] - -INTERNET-DRAFT Delegation Signer Record July 2001 - - - Given these and other reasons there is good reason to explore - alternatives to using only KEY records to create chain of trust. - - Some of these problems can be reduced or eliminated by operational - rules or protocol changes. To reduce the number of keys at apex, rule - to require applications to store their KEY records at the SRV name for - that application is one possibility. Another is to restrict KEY record - to DNS keys only and create a new type for all non DNS keys. Third - possible solution is to ban the storage of non DNS related keys at - zone apex. There are other possible solutions but they are outside the - scope of this document. - -1.1 - Delegation Signer Record model - - This document proposes an alternative to the KEY record chain of - trust, that uses a special record that can only reside at the parent. - This record will identify the key(s) that child will use to self sign - its own KEY set. - - The chain of trust is now established by verifying the parent KEY set, - the DS set from the parent and then the KEY set at the child. This is - cryptographically equivalent to just using KEY records. - - Communication between the parent and child is reduced as the parent - only needs to know of changes in DNS zone KEY(s) used to sign the apex - KEY set. If other KEY records are stored at the zone apex, the parent - does not need to be aware of them. - - This approach has the advantage that it minimizes the communication - between the parent and child and the child is the authority for the - KEY set with full control over the contents. This enables each to - operate and maintain each zone independent of each other. Thus if - child wants to have frequent key rollover for its DNS keys parent does - not need to be aware of it as the child can use one key to only sign - its apex KEY set and other keys to sign the other record sets in the - zone. The child can just as well use the same key to sign all records - in its zone. - - Another advantage is that this model fits well with slow rollout of - DNSSEC and islands of security model. In the islands of security model - someone that trusts "good.example." preconfigures a key from - "good.example." as a trusted keys and from then on trusts any data - that is signed by that key or has a chain of trust to that key. If - "example." starts advertising DS records "good.example." does not have - to change operations, by suspending self-signing. If DS records can - also be used to identify trusted keys instead of KEY records. - - - - - -Gudmundsson Expires January 2002 [Page 3] - -INTERNET-DRAFT Delegation Signer Record July 2001 - - - The main disadvantage of this approach is double the number of - signatures that need to be verified for the each delegation KEY set. - There is no impact on verifying other record sets. - - -1.2 - Reserved words - - The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document - are to be interpreted as described in RFC2119. - - - -2 - DS (Delegation KEY signer) record: - -2.1 Protocol change - - DS record MUST only appear at secure delegations in the parent zone. - The record lists the child's keys that SHOULD sign the child's key - set. Insecure delegation MUST NOT have a DS record, the presence of - DS record SHOULD be considered a hint that the child might be secure. - Resolver MUST only trust KEY records that match a DS record. - NOTE: It has been suggested that NULL DS record for insecure children - is better than no record. The advantage is to have authenticated - denial of child's security status, the drawback is for large - delegating zones there will be many NULL DS records. If parent uses - NXT records adding NXT record to the authority section in the cases - when no DS record exists at delegation will give the same result as - NULL DS record. - WG please comment on which approach is better. - - Updates RFC2535 sections 2.3.4 and 3.4, as well as RFC3008 section - 2.7: Delegating zones MUST NOT store KEY records for delegations. The - only records that can appear at delegation in parent are NS, SIG, NXT - and DS. - - Zone MUST self sign its apex KEY set, it SHOULD sign it with a key - that corresponds to a DS record in the parent. The KEY used to sign - the apex KEY RRset CAN sign other RRsets in the zone. - - If child apex KEY RRset is not signed with one of the keys specified - in the DS record the child is locally secure[RFC3090] and SHOULD only - be considered secure the resolver has been instructed to trust the key - used, via preconfiguration. - - Authorative server answering a query, that has the OK bit set[OKbit], - MUST include the DS set in the additional section if the answer is a - referral and there is space. Caching servers SHOULD return the DS - record in the additional section under the same condition. - - - -Gudmundsson Expires January 2002 [Page 4] - -INTERNET-DRAFT Delegation Signer Record July 2001 - - -2.1.1 - Comments on protocol change - - Over the years there has been various discussions on that the - delegation model in DNS is broken as there is no real good way to - assert if delegation exists. In RFC2535 version of DNSSEC the - authentication of a delegation is the NS bit in the NXT bitmap at the - delegation point. Something more explicit is needed and the DS record - addresses this for secure delegations. - - DS record is the first DNS record to be only stored at the upper side - of a delegation. NS records appear at both sides as do SIG and NXT. - All other records can only appear at the lower side. This will cause - some problems as servers authorative for parent may reject DS record - even if the server understands unknown types, or not hand them out - unless explicitly asked. Similarly a nameserver acting as a - authorative for child and as a caching recursive server may never - return the DS record. A caching server does not care from which side - DS record comes from and thus should not have to be changed if it - supports unknown types. Different TTL values on the childs NS set and - parents DS set may cause the DS set to expire before the NS set. In - this case an non-DS aware server would ask the child server for the DS - set and get NXDOMAIN answer. DS aware server will know to ask the - parent for the DS record. - - Secure resolvers need to know about the DS record and how to interpret - it. In the worst case, introducing the DS record, doubles the - signatures that need to be checked to validate a KEY set. - Note: The working group must determine if the tradeoff between more - work in resolvers is justified by the operational simplification of - this model. The author think this is a small price to pay to have a - cleaner delegations structure. One argument put forward is that DNS - should be optimized for read when ever possible, and on the face of it - adding the DS record makes reading data from DNS more expensive. The - operational complexities and legal hurdles that KEY records in parents - or children make prevent DNSSEC to ever get deployed. - - - - - - - - - - - - - - - - -Gudmundsson Expires January 2002 [Page 5] - -INTERNET-DRAFT Delegation Signer Record July 2001 - - -2.2 Wire format of DS record - - The DS record consists of algorithm, size, key tag and SHA-1 digest of - the public key KEY record allowed to sign the child's delegation. - - 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 tag | size | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | algorithm | SHA-1 digest | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | (20 bytes) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - | | - +-+-+-+-+-+-+-+-+ - - The key tag is calculated as specified in RFC2535, the size is the - size of the public key in bits as specified in the document specifying - the algorithm. Algorithm MUST be an algorithm number assigned in the - range 1..251. The SHA-1 digest is calculated over the canonical name - of the delegation followed by the RDATA of the KEY record. - The size of the DS RDATA is 25 bytes, regardless of the key size. - NOTE: if 160 bits is to large the SHA-1 digest can be shortened but - that weakens the overall security of the system. - -2.2.1 Justifications for fields - - The algorithm and size fields are here to allow resolvers to quickly - identify the candidate KEY records to examine. Key Tag is to allow - quick check if this is a good candidate. The key tag is redundant but - provides some greater assurance than SHA-1 digest on its own. SHA-1 is - a strong cryptographic checksum, it is hard for attacker to generate a - KEY record that has the same SHA-1 digest. Making sure that the KEY - record is a valid public key is much harder. Combining the name of the - key and the key data as input to the digest provides stronger - assurance of the binding. Combining the SHA-1 with the other fields - makes the task of the attacker is as hard breaking the public key. - Even if someone creates a database of all SHA-1 key hashes seen so - far, the addition of the name renders that database useless for - attacks against random zones. - - - - -Gudmundsson Expires January 2002 [Page 6] - -INTERNET-DRAFT Delegation Signer Record July 2001 - - -2.3 Presentation format of DS record - - The presentation format of DS record consists of 2 numbers, followed - by either the name of the signature algorithm or the algorithm number. - The digest is to be presented in hex. - -2.4 Justifications for compact format - - This format allows concise representation of the keys that child will - use, thus keeping down the size of the answer for the delegation, - reducing the probability of packet overflow. The SHA-1 hash is strong - enough to uniquely identify the key. This is similar to the PGP - footprint. - - Each DS record has RDATA size of 25, regardless of the size of the - keys, keeping the answers from the parent smaller than if public key - was used. The smallest currently defined KEY record RDATA is 70 bytes. - - Compact DS format is also better suited to list trusted keys for - islands of security in configuration files. - -2.5 Transition issues for installed base - - RFC2535 compliant resolver will assume that all DS secured delegations - are locally secure. This is a bad thing, thus it might be necessary - for a transition period to support both DS and SIG@Child. The cost is - one more signatures in the answer and that early adopters have to - cumbersome communications that DS is supposed to solve. - - Resolvers will not get confused as they will select signatures with - the KEY they trust and ignore the other one. - -3 Resolver Example - - To create a chain of trust resolver goes from trusted KEY to DS to - KEY. - - Assume the key for domain example. is trusted. In zone "example." we - have - example. KEY - secure.example. DS tag=12345 size=1024 alg=dsa - secure.example. NS ns1.secure.example. - NS ns1.secure.example. s - secure.example. NXT NS SIG NXT DS tail.example. - secure.example. SIG(NXT) - secure.example. SIG(DS) - - - - - -Gudmundsson Expires January 2002 [Page 7] - -INTERNET-DRAFT Delegation Signer Record July 2001 - - - In zone "secure.example." we have - secure.example. SOA - secure.example. NS ns1.secure.example. - NS ns1.secure.example. - secure.example. KEY - KEY - KEY - secure.example. SIG(KEY) - secure.example. SIG(SOA) - secure.example. SIG(NS) - - In this example the trusted key for example signs the DS record for - "secure.example.", making that a trusted record. The DS record states - what key is supposed to sign the KEY record at secure.example. In - this example "secure.example." has three different KEY records and the - one corresponding to the KEY identified in the DS record signs the KEY - set, thus the key set is validated and trusted. Note that one of the - other keys in the keyset actually signs the zone data, and resolvers - will trust the signatures as the key appears in the KEY set. - - This example has only one DS record for the child but there no reason - to outlaw multiple DS records. More than one DS record is needed - during signing key rollover. It is strongly recommended that the DS - set be kept small. - -3.1 Resolver cost estimates for DS records - - From a RFC2535 resolver point of view for each delegation followed to - chase down an answer one KEY record has to be verified and possibly - some other records based on policy, for example the contents of the NS - set. Once the resolver gets to the appropriate delegation validating - the answer may require verifying one or more signatures. For a simple - A record lookup requires at least N delegations to be verified and 1 - RRset. For a DS enabled resolver the cost is 2N+1. For MX record the - cost where the target of the MX record is in the same zone as the MX - record the costs are N+2 and 2N+2. In the case of negative answer the - same holds ratios hold true. - Resolver may require an extra query to get the DS record but and this - may add to the overall cost of the query, but this is never worse than - chasing down NULL KEY records from the parent in RFC2535 DNSSEC. - DS adds processing overhead on resolvers, increases the size of - delegation answers. DS requires much less storage in large delegation - zones than SIG@Parent. - - - - - - - - -Gudmundsson Expires January 2002 [Page 8] - -INTERNET-DRAFT Delegation Signer Record July 2001 - - -4 Acknowledgments - - - Number of people have over the last few years contributed number of - ideas that are captured in this document. The core idea of using one - key to that has only the role of signing a key set, comes from - discussions with Bill Manning and Perry Metzger on how to put in a - single root key in all resolver that lives for a long time. Brian - Wellington, Dan Massey, Edward Lewis, Havard Eidnes, Jakob Schlyter, - Mark Kosters, Miek Gieben, Roy Arens, Scott Rosen have provided - usefull comments. - -4 - Security Considerations: - - This document proposes a change to the validation chain of KEY records - in DNS. The change in is not believed to reduce security in the - overall system, in RFC2535 DNSSEC child must communicate keys to - parent and prudent parents will require some authentication on that - handshake. The modified protocol will require same authentication but - allows the child to exert more local control over its own KEY set. - - In the representation of DS record, there is a possibility that an - attacker can generate an valid KEY that matches all the checks thus - starting to forge data from the child. This is considered impractical - as on average more than 2**80 keys must be generated before one is - found that will match. - - DS record is a change to DNSSEC protocol and there is some installed - base of implementations, as well as text books on how to set up - secured delegations. Implementations that do not understand DS record - will not be able to follow the KEY to DS to KEY chain and consider all - zone secured that way insecure. - -5 - IANA Considerations: - - IANA needs to allocate RR type code for DS from the standard RR type - space. - - - - - - - - - - - - - - -Gudmundsson Expires January 2002 [Page 9] - -INTERNET-DRAFT Delegation Signer Record July 2001 - - -References: - -[RFC1035] P. Mockapetris, ``Domain Names - Implementation and - Specification'', STD 13, RFC 1035, November 1987. - - -[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC - 2535, March 1999. - -[RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing - Authority'', RFC 3008, November 2000. - -[RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone - Status'', RFC 3090, March 2001. - -[OKbit] D. Conrad, ``Indicating Resolver Support of DNSSEC'', work in - progress , April 2001. - -[Parent] R. Gieben, T. Lindgreen, ``Parent stores the child's zone - KEYs'', work in progress , May 2001. - -Author Address - - Olafur Gudmundsson - 3826 Legation Street, NW - Washington, DC, 20015 - USA - - -Appendix A: Changes from Prior versions - -Changes from version 00 - Changed name from DK to DS based on working group comments. - Dropped verbose format based on WG comments. - Added text about TTL issue/problem in caching servers. - Added text about islands of security and clarified the cost impact. - Major editing of arguments and some reordering of text for clarity. - Added section on transition issues. - - - - - - - - - - - - -Gudmundsson Expires January 2002 [Page 10] - -INTERNET-DRAFT Delegation Signer Record July 2001 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2001). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published and - distributed, in whole or in part, without restriction of any kind, - provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of developing - Internet standards in which case the procedures for copyrights defined - in the Internet Standards process must be followed, or as required to - translate it into languages other than English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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." - - - - - - - - - - - - - - - - - - - - - - - - - -Gudmundsson Expires January 2002 [Page 11] diff --git a/doc/draft/draft-ietf-dnsext-delegation-signer-04.txt b/doc/draft/draft-ietf-dnsext-delegation-signer-04.txt new file mode 100644 index 0000000000..84f726284d --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-delegation-signer-04.txt @@ -0,0 +1,674 @@ + + + + + + + DNSEXT Working Group Olafur Gudmundsson + INTERNET-DRAFT November 2001 + + + Updates: RFC 1035, RFC 2535, RFC 3008. + + + Delegation Signer record in parent. + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with all + provisions of Section 10 of RFC2026. + + 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 + + Comments should be sent to the authors or the DNSEXT WG mailing list + namedroppers@ops.ietf.org + + This draft expires on May 20, 2002. + + Copyright Notice + + Copyright (C) The Internet Society (2001). All rights reserved. + + + +Abstract + + The Delegation Signer (DS) RR set is stored in a delegating (parent) + zone at each delegation point, and indicates the keys used in the + delegated (child) zone. The main design goal of the DS RR simplify the + operation of secure delegations by eliminating the need to store the + same RR in parent and child, as is done with the NS RR set and the KEY + + + +Gudmundsson Expires May 2002 [Page 1] + +INTERNET-DRAFT Delegation Signer Record November 2001 + + + set in RFC2535. + Secure resolvers need to take an additional step with DS to verify a + child's KEY RR set. Operationally this schema is much simpler as + operation of the two zones at delegation is now decoupled to great + extent. + This document updates RFC1035, RFC2535 and RFC3008. + + +1 - Introduction + + Familiarity with the DNS system [RFC1035], DNS security extensions + [RFC2535] and DNSSEC terminology [RFC3090] is important. + + When the same data can reside in two administratively different DNS + zones, the data frequently gets out of sync. NS record in a zone + indicates that this name is a delegation and the NS record lists the + authorative servers for the real zone. Based on actual measurements + 10-30% of all delegations in the Internet have differing NS sets at + parent and child. There are number of reasons for this, including lack + of communication between parent and child and bogus name-servers being + listed to meet registrar requirements. + + DNSSEC [RFC2535,RFC3008,RFC3090] specifies that child must have its + KEY set signed by the parent to create a verifiable chain of KEYs. + There is some debate, where the signed KEY set should reside, + parent[Parent] or child[RFC2535]. If the KEY set resides at the child, + frequent two way communication is needed between the two parties. + First the child needs to transmit the key set to parent and then the + parent sends the signed set or signatures to child. If the KEY set + resides at the parent the communication is reduced as the child only + sends changed key sets to parent. + + DNSSEC[RFC2535] requires that the parent store NULL key set for + unsecure children, this complicates resolution process in many cases + as servers for both parent and child need to be queried for KEY set if + the child server does not return a KEY set. Storing the KEY record + only in the parent zone simplifies this and allows the elimination of + the NULL key set. + + Another complication of the DNSSEC KEY model is that KEY record is + used to store DNS zone keys and public keys for other protocols. + There are number of potential problems with this including: + 1. KEY set can become quite large if many applications/protocols + store their keys at the zone apex. Possible protocols are IPSEC, + HTTP, SMTP, SSH and others that use public key cryptography. + 2. Key set may require frequent updates. + 3. Probability of compromised/lost keys increases and triggers + emergency key rollover procedures. + + + +Gudmundsson Expires May 2002 [Page 2] + +INTERNET-DRAFT Delegation Signer Record November 2001 + + + 4. Parent may refuse sign key sets with NON DNS zone keys. + 5. Parent may not meet the child's expectations in turnaround time + in resigning the key set. + + Given these and other reasons there is good reason to explore + alternatives to using only KEY records to create chain of trust. + + Some of these problems can be reduced or eliminated by operational + rules or protocol changes. To reduce the number of keys at apex, a + rule to require applications to store their KEY records at the SRV + name for that application is one possibility. Another is to restrict + KEY record to DNS keys only and create a new type for all non DNS + keys. Third possible solution is to ban the storage of non DNS related + keys at zone apex. There are other possible solutions but they are + outside the scope of this document. + + +1.2 - Reserved words + + The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", + "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be + interpreted as described in RFC2119. + +2 - DS (Delegation KEY Signer) + +2.1 - Delegation Signer Record model + + This document proposes an alternative to the KEY record chain of + trust, that uses a special record that can only reside at the parent. + This record will identify the key(s) that child are allowed to self + sign its own KEY set. + + The chain of trust is now established by verifying the parent KEY set, + the DS set from the parent and the KEY set at the child. This is + cryptographically equivalent to just using KEY records. + + Communication between the parent and child is greatly reduced, since + the child only needs to notify parent about changes in keys that sign + its apex KEY RRset. Parent is ignorant of all other keys in the + child's apex KEY RRset, and the child maintains full control over the + apex KEY set and its content. Child can maintain any policies over + its DNS and other KEY usage with minimal impact on parent. Thus if + child wants to have frequent key rollover for its DNS keys parent does + not need to be aware of it as the child can use one key to only sign + its apex KEY set and other keys to sign the other record sets in the + zone. + + + + + +Gudmundsson Expires May 2002 [Page 3] + +INTERNET-DRAFT Delegation Signer Record November 2001 + + + This model fits well with slow roll out of DNSSEC and islands of + security model. In the islands of security model someone that trusts + "good.example." can preconfigure a key from "good.example." as a + trusted keys and from then on trusts any data that is signed by that + key or has a chain of trust to that key. If "example." starts + advertising DS records, "good.example." does not have to change + operations, by suspending self-signing. DS records can also be used to + identify trusted keys instead of KEY records. One further advantage + is the information stored in the parent is minimized, as only records + for secure delegations are needed. + + The main disadvantage of this approach that verifying delegations KEY + set requires twice as many signature verification operations. There + is no impact on the number of signatures verified for other RR sets. + +2.2 Protocol change + + Each secure delegation in a secure zone MUST contain a DS RR set. If + a DS RR set accompanies the NS RR set, the intent is to state that the + child zone is secured. If an NS RR set exists without a DS RR set the + intent is to state that the child zone is unsecure. DS sets MUST NOT + appear at non delegations or at zone APEX. + + In a zone that uses DS, insecure delegations MUST have the NODS[TBD] + bit set in the NXT record. This is required to differenciate this + delegation from Secure RFC2535 delegation. + + Updates RFC2535 sections 2.3.4 and 3.4, as well as RFC3008 section + 2.7: + Delegating zones MUST NOT store KEY records for delegations. The only + records that can appear at delegation in parent are NS, SIG, NXT and + DS. + + Zone MUST self sign its apex KEY set, it SHOULD sign it with a key + that corresponds to a DS record in the parent. The KEY used to sign + the apex KEY RRset MAY sign other RRsets in the zone. + + If child apex KEY RRset is not signed with one of the keys specified + in the DS record the child is locally secure[RFC3090] and SHOULD only + be considered secure if the resolver has been configured to trust the + key used. + + Authorative server answering a query with the OK bit[OKbit] set, MUST + include the DS records and NXT record along with signatures in answers + for a delegation and space is available. DS and NXT records SHOULD + have lower priority than address records but higher priority than KEY. + Caching servers SHOULD return the DS and parent NXT record(s) in the + additional section under the same condition. + + + +Gudmundsson Expires May 2002 [Page 4] + +INTERNET-DRAFT Delegation Signer Record November 2001 + + +2.2.1 - Comments on protocol change + + Over the years there has been various discussions on that the + delegation model in DNS is broken as there is no real good way to + assert if delegation exists. In RFC2535 version of DNSSEC the + authentication of a delegation is the NS bit in the NXT bitmap at the + delegation point. Something more explicit is needed and the DS record + addresses this for secure delegations. + + DS record is the first DNS record that can only appear on the upper + side of a delegation. NS records appear at both sides as do SIG and + NXT. All other records can only appear at the lower side. This will + cause some problems as servers authorative for parent, reject DS + record even if the server understands unknown types, or will not hand + them out unless explicitly asked. Similarly a nameserver acting as a + authorative for child and as a caching recursive server may never + return the DS record. + + A caching server that supports unkown types, does not care from which + side DS record comes from and thus does not have to be changed. + Different TTL values on the child's NS set and parents DS set can + cause the DS set to expire before the NS set. + + Secure resolvers need to know about the DS record and how to interpret + it. In the worst case, introducing the DS record, doubles the + signatures that need to be checked to validate a KEY set. + +2.3 Wire format of DS record + + The DS (type=TDB) record consists of algorithm, key tag and SHA-1 + digest of the public key KEY record allowed to sign the child's + delegation. + + 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 tag | algorithm | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SHA-1 digest | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (20 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Gudmundsson Expires May 2002 [Page 5] + +INTERNET-DRAFT Delegation Signer Record November 2001 + + + The key tag is calculated as specified in RFC2535, Algorithm MUST be + an algorithm number assigned in the range 1..251 and the algorithm + MUST be allowed to sign DNS data. The SHA-1 digest is calculated over + the canonical name of the delegation followed by the RDATA of the KEY + record. + DS records MUST NOT point to a null KEY record, and the KEY records + pointed to by DS records MUST have protocol value 3 (DNSSEC). + DS records MUST NOT point to KEY records where flag field has folowing + bit settings, bit 0 (no authentication) is set, bit 6 MUST be set to 0 + and bit 7 MUST be set to 1 (zone key). Settings of other bits are not + important. + The size of the DS RDATA is 23 bytes, regardless of key size. + +2.3.1 Justifications for fields + + The algorithm and key tag fields are here to allow resolvers to + quickly identify the candidate KEY records to examine. The key tag + adds some greater assurance than SHA-1 digest on its own. SHA-1 is a + strong cryptographic checksum, it is real hard for attacker to + generate a KEY record that has the same SHA-1 digest. Combining the + name of the key and the key data as input to the digest provides + stronger assurance of the binding. + + This format allows concise representation of the keys that child will + use, thus keeping down the size of the answer for the delegation, + reducing the probability of packet overflow. The SHA-1 hash is strong + enough to uniquely identify the key. This is similar to the PGP + footprint. + + DS record is also well suited to lists trusted keys for islands of + security in configuration files. + +2.4 Presentation format of DS record + + The presentation format of DS record consists of 2 numbers followed by + digest presented in hex. + foo.example DS 12345 3 123456789abcdef67890 + + + + + + + + + + + + + + +Gudmundsson Expires May 2002 [Page 6] + +INTERNET-DRAFT Delegation Signer Record November 2001 + + +2.5 Transition issues for installed base + + RFC2535 compliant resolver will assume that all DS secured delegations + are locally secure. This is a bad thing, thus it might be necessary + for a transition period to support both DS and SIG@Child. The cost is + one or more signatures in the answer for KEY records and that early + adopters have to use cumbersome communications that DS solves. #.bp + +2.6 Backwards compatibilty with RFC2535 SIG@child and RFC1035 + + This section documents how a resolver determines the type of + delegation. + RFC1035 delegation has: + + RFC1035 NS + + RFC2535 adds the following two cases: + + Secure RFC2535: NS + NXT + SIG(NXT) + NXT bit map contains: NS SIG NXT + Insecure RFC2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT) + NXT bit map contains: NS SIG KEY NXT + KEY must be null-key. + + DS adds the following two states: + + Secure DS: NS + DS + SIG(DS) + NXT + SIG(NXT) + NXT bit map contains: NS SIG NXT DS + Insecure DS: NS + NXT + SIG(NXT) + NXT bit map contains: NS SIG KEY NXT NODS + + If the NODS bit is not used, a resover can not determine if this is a + DS delegation zone. Thus is not able to determine if this delegtion is + a secure RFC2535 or a insecure DS. + +2.6.1 NODS support in servers + + NODS is a virtual type, servers MUST refuse to store any record of + this type. No special processing is required on answers. + + + + + + + + + + + + +Gudmundsson Expires May 2002 [Page 7] + +INTERNET-DRAFT Delegation Signer Record November 2001 + + +3 Resolver Example + + To create a chain of trust resolver goes from trusted KEY to DS to + KEY. + + Assume the key for domain "example." is trusted. In zone "example." + we have + example. KEY + secure.example. DS tag=10243 alg=3 + secure.example. NS ns1.secure.example. + NS ns2.secure.example. + secure.example. NXT NS SIG NXT DS unsecure.example. + secure.example. SIG(NXT) + secure.example. SIG(DS) + unsecure.example NS ns1.unsecure.example. + unsecure.example NS ns2.unsecure.example. + unsecure.example. NXT NS SIG NXT NODS .example. + unsecure.example. SIG(NXT) + + In zone "secure.example." we have + secure.example. SOA + secure.example. NS ns1.secure.example. + NS ns1.secure.example. + secure.example. KEY + KEY + KEY + secure.example. SIG(KEY) + secure.example. SIG(SOA) + secure.example. SIG(NS) + + In this example the trusted key for "example." signs the DS record for + "secure.example.", making that a trusted record. The DS record states + what key is expected to sign the KEY RRset at "secure.example". Here + "secure.example." has three different KEY records and the KEY + identified in the DS record signs the KEY set, thus the KEY set is + validated and trusted. Note that one of the other keys in the keyset + actually signs the zone data, and resolvers will trust the signatures + as the key appears in the KEY set. + + This example has only one DS record for the child but there no reason + to outlaw multiple DS records. More than one DS record is needed + during signing key rollover. It is strongly recommended that the DS + set be kept small. + + Resolver determines the security status of "unsecure.example." by + examining the parent size NXT for this name. + + + + + +Gudmundsson Expires May 2002 [Page 8] + +INTERNET-DRAFT Delegation Signer Record November 2001 + + +3.1 Resolver cost estimates for DS records + + From a RFC2535 resolver point of view for each delegation followed to + chase down an answer one KEY record has to be verified and possibly + some other records based on policy, for example the contents of the NS + set. Once the resolver gets to the appropriate delegation validating + the answer may require verifying one or more signatures. A simple A + record lookup requires at least N delegations to be verified and 1 + RRset. For a DS enabled resolver the cost is 2N+1. For MX record the + cost where the target of the MX record is in the same zone as the MX + record the costs are N+2 and 2N+2. In the case of negative answer the + same ratios hold true. + + Resolver may require an extra query to get the DS record and this may + add to the overall cost of the query, but this is never worse than + chasing down NULL KEY records from the parent in RFC2535 DNSSEC. + + DS adds processing overhead on resolvers, increases the size of + delegation answers but much less than SIG@Parent. + +4 Acknowledgments + + Number of people have over the last few years contributed number of + ideas that are captured in this document. The core idea of using one + key to only sign key set, comes from discussions with Bill Manning and + Perry Metzger on how to put in a single root key in all resolvers. + Alexis Yushin, Brian Wellington, Jakob Schlyter, Scott Rosen, Edward + Lewis, Dan Massey, Lars-Johan Liman, Mark Kosters, Olaf Kolman, Miek + Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David Blacka, + Rob Austein, Derek Atkins, Roy Arends, and others have provided useful + comments. + +4 - Security Considerations: + + This document proposes a change to the validation chain of KEY records + in DNS. The change in is not believed to reduce security in the + overall system, in RFC2535 DNSSEC child must communicate keys to + parent and prudent parents will require some authentication on that + handshake. The modified protocol will require same authentication but + allows the child to exert more local control over its own KEY set. + + There is a possibility that an attacker can generate an valid KEY that + matches all the DS fields thus starting to forge data from the child. + This is considered impractical as on average more than 2^80 keys must + be generated before one is found that will match. + + DS record is a change to DNSSEC protocol and there is some installed + base of implementations, as well as text books on how to set up + + + +Gudmundsson Expires May 2002 [Page 9] + +INTERNET-DRAFT Delegation Signer Record November 2001 + + + secured delegations. Implementations that do not understand DS record + will not be able to follow the KEY to DS to KEY chain and consider all + zone secured that way insecure. + +5 - IANA Considerations: + + IANA needs to allocate RR type code for DS from the standard RR type + space. + + IANA needs to allocate RR type code for the virtual NODS record from + the standard RR type space. Note: SINK (40) was never implemented and + that type code can be reused for NODS. + +References: + +[RFC1035] P. Mockapetris, ``Domain Names - Implementation and + Specification'', STD 13, RFC 1035, November 1987. + +[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC + 2535, March 1999. + +[RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing + Authority'', RFC 3008, November 2000. + +[RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone + Status'', RFC 3090, March 2001. + +[OKbit] D. Conrad, ``Indicating Resolver Support of DNSSEC'', work in + progress , April 2001. + +[Parent] R. Gieben, T. Lindgreen, ``Parent stores the child's zone + KEYs'', work in progress , May 2001. + +Author Address + + Olafur Gudmundsson + 3826 Legation Street, NW + Washington, DC, 20015 + USA + + + + + + + + + + + +Gudmundsson Expires May 2002 [Page 10] + +INTERNET-DRAFT Delegation Signer Record November 2001 + + +Appendix A: Changes from Prior versions + +Changes from version 03 + Added strict rules on what KEY records can be pointed to by DS. + +Changes from version 02 + Added text outlawing DS at non delegations. + Added table showing the contents of DS, SIG@child, and RFC1034 + delegations. + Added the NODS type/bit definition to distiguish insecure DS + delegation from secure SIG@child one. + Added the requirement that NXT be returned with referal answers. + Minor text edits. + +Changes from version 01 + Deleted KEY size field as it did not contribute anything but + complexity. + Number of wordsmith changes to make document more readable. + The word CAN was used when SHOULD was intended. + Deleted section 2.4 "Justifications for compact format" moved relevant + text to section 2.2. + Reverse alphabetized the acknowledgments section. + Reorganized sections 1 and 2 for readability. + + +Changes from version 00 + Changed name from DK to DS based on working group comments. + Dropped verbose format based on WG comments. + Added text about TTL issue/problem in caching servers. + Added text about islands of security and clarified the cost impact. + Major editing of arguments and some reordering of text for clarity. + Added section on transition issues. + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published and + distributed, in whole or in part, without restriction of any kind, + provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of developing + Internet standards in which case the procedures for copyrights defined + in the Internet Standards process must be followed, or as required to + + + +Gudmundsson Expires May 2002 [Page 11] + +INTERNET-DRAFT Delegation Signer Record November 2001 + + + translate it into languages other than English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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." + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gudmundsson Expires May 2002 [Page 12] diff --git a/doc/draft/draft-ietf-dnsext-gss-tsig-03.txt b/doc/draft/draft-ietf-dnsext-gss-tsig-04.txt similarity index 90% rename from doc/draft/draft-ietf-dnsext-gss-tsig-03.txt rename to doc/draft/draft-ietf-dnsext-gss-tsig-04.txt index df211faeb2..9f8c3858f8 100644 --- a/doc/draft/draft-ietf-dnsext-gss-tsig-03.txt +++ b/doc/draft/draft-ietf-dnsext-gss-tsig-04.txt @@ -1,8 +1,8 @@ INTERNET-DRAFT Stuart Kwan - Praerit Garg -September 20, 2001 James Gilroy -Expires March 20, 2002 Levon Esibov + Praerit Garg +November 19, 2001 James Gilroy +Expires May 19, 2002 Levon Esibov Jeff Westhead Microsoft Corp. Randy Hall @@ -54,9 +54,9 @@ Application Program Interface (GSS-API) (RFC2743). -Expires March 20, 2002 [Page 1] +Expires May 19, 2002 [Page 1] -INTERNET-DRAFT GSS-TSIG September 20, 2001 +INTERNET-DRAFT GSS-TSIG November 19, 2001 Table of Contents @@ -91,12 +91,12 @@ Table of Contents 1. Introduction The Secret Key Transaction Signature for DNS (TSIG) [RFC2845] protocol -was developed to provide a lightweight end to end authentication and -integrity of messages between two DNS entities, such as client and -server or server and server. TSIG can be used to protect dynamic update -messages, authenticate regular message or to off-load complicated -DNSSEC [RFC2535] processing from a client to a server and still allow -the client to be assured of the integrity off the answers. +was developed to provide a lightweight authentication and integrity of +messages between two DNS entities, such as client and server or server +and server. TSIG can be used to protect dynamic update messages, +authenticate regular message or to off-load complicated DNSSEC +[RFC2535] processing from a client to a server and still allow the +client to be assured of the integrity off the answers. The TSIG protocol [RFC2845] is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic @@ -108,13 +108,13 @@ include authentication, integrity, and confidentiality. The GSS-API framework has several benefits: * Mechanism and protocol independence. The underlying mechanisms that realize the security services can be negotiated on the fly and varied -over time. For example, a client and server may use Kerberos [RFC1964] -for one transaction, whereas that same server may use SPKM [RFC2025] +over time. For example, a client and server MAY use Kerberos [RFC1964] +for one transaction, whereas that same server MAY use SPKM [RFC2025] with a different client. -Expires March 20, 2002 [Page 2] +Expires May 19, 2002 [Page 2] -INTERNET-DRAFT GSS-TSIG September 20, 2001 +INTERNET-DRAFT GSS-TSIG November 19, 2001 * The protocol developer is removed from the responsibility of creating and managing a security infrastructure. For example, the @@ -130,9 +130,9 @@ of [RFC2743] before examining this protocol in detail. It is also assumed that the reader is familiar with [RFC2845], [RFC2930], [RFC1034] and [RFC1035]. -The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and -"MAY" in this document are to be interpreted as described in RFC 2119 -[RFC2119]. +The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", +"RECOMMENDED", and "MAY" in this document are to be interpreted as +described in RFC 2119 [RFC2119]. 2. Algorithm Overview @@ -170,9 +170,9 @@ states of a context associated with a connection: | | +----------+ -Expires March 20, 2002 [Page 3] +Expires May 19, 2002 [Page 3] -INTERNET-DRAFT GSS-TSIG September 20, 2001 +INTERNET-DRAFT GSS-TSIG November 19, 2001 Every connection begins in the uninitialized state. @@ -211,6 +211,13 @@ the owner name of the TKEY and TSIG records sent between a client and a server to indicate to each other which context MUST be used to process the current request. +DNS client and server MAY use various underlying security mechanisms to +establish security context as described in sections 3 and 4. At the +same time, in order to guarantee interoperability between DNS clients +and servers that support GSS-TSIG it is required that security +mechanism used by client enables use of Kerberos v5 (see Section 9 +for more information). + 3.1 Negotiating Context @@ -220,6 +227,11 @@ initial token and sends it to the server. The server processes the token and if necessary, returns a subsequent token to the client. The client processes this token, and so on, until the negotiation is complete. The number of times the client and server exchange tokens + +Expires May 19, 2002 [Page 4] + +INTERNET-DRAFT GSS-TSIG November 19, 2001 + depends on the underlying security mechanism. A completed negotiation results in a context handle. @@ -228,11 +240,6 @@ tokens between client and server. The TKEY record is a general mechanism for establishing secret keys for use with TSIG. For more information, see [RFC2930]. -Expires March 20, 2002 [Page 4] - -INTERNET-DRAFT GSS-TSIG September 20, 2001 - - 3.1.1 Call GSS_Init_sec_context @@ -278,19 +285,17 @@ indicated with the output values below. Consult Sections 2.2.1 BOOLEAN deleg_state BOOLEAN sequence_state BOOLEAN anon_state + +Expires May 19, 2002 [Page 5] + +INTERNET-DRAFT GSS-TSIG November 19, 2001 + BOOLEAN trans_state BOOLEAN prot_ready_state BOOLEAN conf_avail BOOLEAN integ_avail INTEGER lifetime_rec - - -Expires March 20, 2002 [Page 5] - -INTERNET-DRAFT GSS-TSIG September 20, 2001 - - The client MUST abandon the algorithm if returned major_status is set to one of the following errors: @@ -339,14 +344,9 @@ context to both the client and server, and thus the client SHOULD use a value which is globally unique as described in [RFC2930]. To achieve global uniqueness, the name MAY contain a UUID/GUID [ISO11578]. +Expires May 19, 2002 [Page 6] - - - - -Expires March 20, 2002 [Page 6] - -INTERNET-DRAFT GSS-TSIG September 20, 2001 +INTERNET-DRAFT GSS-TSIG November 19, 2001 TKEY Record @@ -394,17 +394,17 @@ signature in the TSIG record MUST be verified using the procedure detailed in section 5, Sending and Verifying Signed Messages. If the response is not signed, OR if the response is signed but signature is invalid, then an attacker has tampered with the message in transit or -has attempted to send the client a false response. The client MUST +has attempted to send the client a false response. The client MAY continue waiting for a response to its last TKEY query until the time period since the client sent last TKEY query expires. Such a time period -is specified by the policy local to the client. +is specified by the policy local to the client. This is a new option +that allows DNS client to accept multiple answers for one query ID and +select one (not necessarily the first one) based on some criteria. + +Expires May 19, 2002 [Page 7] - - -Expires March 20, 2002 [Page 7] - -INTERNET-DRAFT GSS-TSIG September 20, 2001 +INTERNET-DRAFT GSS-TSIG November 19, 2001 If the signature is verified the context state is advanced to Context @@ -423,7 +423,7 @@ context by calling GSS_Delete_sec_context providing the associated context_handle. The client MAY repeat the negotiation sequence starting with the uninitialized state as described in section 3.1. To prevent infinite looping the number of attempts to establish a security context -must be limited. +MUST be limited to ten or less. If the DNS message error is NO_ERROR and error filed in the TKEY record is 0 (i.e. no error), then the client MUST pass a token specified in the @@ -460,9 +460,9 @@ If OUTPUT major_status is set to one of the following values GSS_S_BAD_MECH GSS_S_FAILURE -Expires March 20, 2002 [Page 8] +Expires May 19, 2002 [Page 8] -INTERNET-DRAFT GSS-TSIG September 20, 2001 +INTERNET-DRAFT GSS-TSIG November 19, 2001 the client MUST abandon this negotiation sequence. The client MUST @@ -470,7 +470,7 @@ delete an active context by calling GSS_Delete_sec_context providing the associated context_handle. The client MAY repeat the negotiation sequence starting with the uninitialized state as described in section 3.1. To prevent infinite looping the number of attempts to establish a -security context must be limited. +security context MUST be limited to ten or less. If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE then client MUST act as described below. @@ -483,8 +483,8 @@ negotiation sequence. The client MUST delete an active context by calling GSS_Delete_sec_context providing the associated context_handle. The client MAY repeat the negotiation sequence starting with the uninitialized state as described in section 3.1. To prevent infinite -looping the number of attempts to establish a security context must be -limited. +looping the number of attempts to establish a security context MUST be +limited to ten or less. If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet finished. The token output_token MUST be passed to the server in a TKEY @@ -518,9 +518,9 @@ in section 5, Sending and Verifying Signed Messages. -Expires March 20, 2002 [Page 9] +Expires May 19, 2002 [Page 9] -INTERNET-DRAFT GSS-TSIG September 20, 2001 +INTERNET-DRAFT GSS-TSIG November 19, 2001 3.2.1 Terminating a Context @@ -576,9 +576,9 @@ context negotiation. -Expires March 20, 2002 [Page 10] +Expires May 19, 2002 [Page 10] -INTERNET-DRAFT GSS-TSIG September 20, 2001 +INTERNET-DRAFT GSS-TSIG November 19, 2001 4.1.2 Call GSS_Accept_sec_context @@ -634,9 +634,9 @@ RCODE = NOERROR, that contains a TKEY record in the answer section. -Expires March 20, 2002 [Page 11] +Expires May 19, 2002 [Page 11] -INTERNET-DRAFT GSS-TSIG September 20, 2001 +INTERNET-DRAFT GSS-TSIG November 19, 2001 If OUTPUT major_status is one of the following errors the error field in the TKEY record set to BADKEY. @@ -692,9 +692,9 @@ Error, Other Size and Data Fields, MUST be set according to [RFC2930]. -Expires March 20, 2002 [Page 12] +Expires May 19, 2002 [Page 12] -INTERNET-DRAFT GSS-TSIG September 20, 2001 +INTERNET-DRAFT GSS-TSIG November 19, 2001 @@ -750,9 +750,9 @@ call" of the RFC 2743[RFC2743] for syntax definitions. -Expires March 20, 2002 [Page 13] +Expires May 19, 2002 [Page 13] -INTERNET-DRAFT GSS-TSIG September 20, 2001 +INTERNET-DRAFT GSS-TSIG November 19, 2001 INPUTS CONTEXT HANDLE context_handle = context_handle for key_name @@ -808,9 +808,9 @@ For the GSS algorithm, a signature is verified by using GSS_VerifyMIC: INTEGER minor_status INTEGER qop_state -Expires March 20, 2002 [Page 14] +Expires May 19, 2002 [Page 14] -INTERNET-DRAFT GSS-TSIG September 20, 2001 +INTERNET-DRAFT GSS-TSIG November 19, 2001 If major_status is GSS_S_COMPLETE, the signature is authentic and the message was delivered intact. Per [RFC2845], the timer values of the @@ -866,9 +866,9 @@ to the algorithm described above. -Expires March 20, 2002 [Page 15] +Expires May 19, 2002 [Page 15] -INTERNET-DRAFT GSS-TSIG September 20, 2001 +INTERNET-DRAFT GSS-TSIG November 19, 2001 Client verifies that replay_det_state and mutual_state values are TRUE. Since the major_status is GSS_S_CONTINUE_NEEDED, which is a @@ -924,9 +924,9 @@ INTERNET-DRAFT GSS-TSIG September 20, 2001 -Expires March 20, 2002 [Page 16] +Expires May 19, 2002 [Page 16] -INTERNET-DRAFT GSS-TSIG September 20, 2001 +INTERNET-DRAFT GSS-TSIG November 19, 2001 V. Server responds to the TKEY query Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's @@ -982,9 +982,9 @@ INTERNET-DRAFT GSS-TSIG September 20, 2001 -Expires March 20, 2002 [Page 17] +Expires May 19, 2002 [Page 17] -INTERNET-DRAFT GSS-TSIG September 20, 2001 +INTERNET-DRAFT GSS-TSIG November 19, 2001 VIII. Server receives a TKEY query When the server receives a TKEY query, the server verifies that Mode @@ -1040,9 +1040,9 @@ INTERNET-DRAFT GSS-TSIG September 20, 2001 Signature field in the TSIG record is set to per_msg_token. -Expires March 20, 2002 [Page 18] +Expires May 19, 2002 [Page 18] -INTERNET-DRAFT GSS-TSIG September 20, 2001 +INTERNET-DRAFT GSS-TSIG November 19, 2001 XI. Client processes token returned by server @@ -1074,6 +1074,9 @@ This document describes a protocol for DNS security using GSS-API. The security provided by this protocol is only as effective as the security provided by the underlying GSS mechanisms. +All the security considerations from RFC2845, RFC2930 and RFC 2743 +apply to the protocol described in this document. + 8. IANA Considerations @@ -1095,12 +1098,9 @@ mech_type in their GSS API calls. At the same time, in order to guarantee interoperability between DNS clients and servers that support GSS-TSIG it is required that +Expires May 19, 2002 [Page 19] - - -Expires March 20, 2002 [Page 19] - -INTERNET-DRAFT GSS-TSIG September 20, 2001 +INTERNET-DRAFT GSS-TSIG November 19, 2001 - DNS servers specify SPNEGO mech_type @@ -1156,9 +1156,9 @@ Ram Viswanathan, Olafur Gudmundsson and Donald E. Eastlake 3rd. [RFC2478] Baize, E., Pinkas, D., "The Simple and Protected GSS-API Negotiation Mechanism", RFC 2478, Bull, December 1998. -Expires March 20, 2002 [Page 20] +Expires May 19, 2002 [Page 20] -INTERNET-DRAFT GSS-TSIG September 20, 2001 +INTERNET-DRAFT GSS-TSIG November 19, 2001 [ISO11578]"Information technology", "Open Systems @@ -1175,14 +1175,14 @@ Microsoft Corporation Microsoft Corporation One Microsoft Way One Microsoft Way Redmond, WA 98052 Redmond, WA 98052 USA USA -skwan@microsoft.com +skwan@microsoft.com praeritg@microsoft.com James Gilroy Levon Esibov Microsoft Corporation Microsoft Corporation One Microsoft Way One Microsoft Way Redmond, WA 98052 Redmond, WA 98052 USA USA - levone@microsoft.com +jamesg@microsoft.com levone@microsoft.com Randy Hall Jeff Westhead @@ -1190,8 +1190,8 @@ Lucent Technologies Microsoft Corporation 400 Lapp Road One Microsoft Way Malvern PA 19355 Redmond, WA 98052 USA USA -randyhall@lucent.com +randyhall@lucent.com jwesth@microsoft.com -Expires March 20, 2002 [Page 21] +Expires May 19, 2002 [Page 21] diff --git a/doc/draft/draft-ietf-dnsext-mdns-01.txt b/doc/draft/draft-ietf-dnsext-mdns-07.txt similarity index 64% rename from doc/draft/draft-ietf-dnsext-mdns-01.txt rename to doc/draft/draft-ietf-dnsext-mdns-07.txt index fe00e18c19..1a7eb5c41a 100644 --- a/doc/draft/draft-ietf-dnsext-mdns-01.txt +++ b/doc/draft/draft-ietf-dnsext-mdns-07.txt @@ -7,14 +7,14 @@ DNSEXT Working Group Levon Esibov INTERNET-DRAFT Bernard Aboba Category: Standards Track Dave Thaler - Microsoft -6 July 2001 + Microsoft +15 November 2001 Multicast DNS This document is an Internet-Draft and is in full conformance with all -provisions of Section 10 of RFC2026. +provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups @@ -61,28 +61,28 @@ Esibov, Aboba & Thaler Standards Track [Page 1] -INTERNET-DRAFT Multicast DNS 6 July 2001 +INTERNET-DRAFT Multicast DNS 15 November 2001 Table of Contents 1. Introduction .......................................... 3 2. Name resolution using multicast DNS ................... 3 - 2.1 Behavior of the sender and responder ............ 3 -3. Usage model ........................................... 4 -4. Sequence of events .................................... 8 -5. Conflict resolution ................................... 8 - 5.1 Considerations for multiple interfaces .......... 10 -6. IANA considerations ................................... 11 -7. ARPA domain considerations ............................ 11 -8. References ............................................ 12 -9. Security considerations ............................... 13 -ACKNOWLEDGMENTS .............................................. 13 -AUTHORS' ADDRESSES ........................................... 14 -Intellectual Property Statement .............................. 14 -Full Copyright Statement ..................................... 15 - - + 2.1 Behavior of the sender and responder ............ 4 +3. Usage model ........................................... 7 + 3.1 mDNS configuration .............................. 8 +4. Sequence of events .................................... 9 +5. Conflict resolution ................................... 9 + 5.1 Considerations for multiple interfaces .......... 11 + 5.2 API issues ...................................... 12 +6. IANA considerations ................................... 13 +7. ARPA domain considerations ............................ 13 +8. References ............................................ 14 +9. Security considerations ............................... 15 +Acknowledgments .............................................. 16 +Authors' Addresses ........................................... 16 +Intellectual Property Statement .............................. 16 +Full Copyright Statement ..................................... 17 @@ -121,7 +121,7 @@ Esibov, Aboba & Thaler Standards Track [Page 2] -INTERNET-DRAFT Multicast DNS 6 July 2001 +INTERNET-DRAFT Multicast DNS 15 November 2001 1. Introduction @@ -145,33 +145,33 @@ Service discovery in general as well as discovery of DNS servers using mDNS in particular is outside of the scope of this document, as is name resolution over non-multicast capable media. -In this document, the key words "MAY", "MUST, "MUST NOT", "optional", -"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as -described in [1]. +In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", +"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as +described in RFC 2119 [1]. 2. Name resolution using Multicast DNS This extension to the DNS protocol consists of a single change to the -method of use, and no change to the current format of DNS packets. -Namely, this extension allows multicast DNS queries to be sent to and -received on port 53. +method of use, and no change to the current format of DNS packets, It +allows multicast DNS queries to be sent to and received on port 53 using +a LINKLOCAL address as specified in "Administratively Scoped IP +Multicast" [2] for IPv4 and the "solicited name" LINKLOCAL multicast +addresses for IPv6. The mDNS LINKLOCAL address to be used for IPv4 is +. LINKLOCAL addresses are used to prevent propagation of multicast +DNS traffic across routers, potentially flooding the network. -The messages are sent using the LINKLOCAL addresses [2] for IPv4 and -IPv6 (below referred as the LINKLOCAL address), which are yet to be -assigned by IANA. LINKLOCAL addresses are used to prevent propagation of -multicast DNS traffic across routers, potentially flooding the network. +Propagation of multicast DNS packets on the local link is considered +sufficient to enable DNS name resolution in small adhoc networks. The +assumption is that if a network has a router, then the network either +has a DNS server or the router can function as a DNS proxy. + +By implementing DHCPv4 as well as a DNS proxy and dynamic DNS, routers +can provide name resolution for the names of IPv4 hosts on the local +network. Where all IPv6 hosts also support IPv4, and the DNS proxy +supports AAAA RRs, resolution for the names of dual stack IPv6 hosts on +the local network can also be provided using this mechanism. -Propagation of multicast DNS packets within the local subnet is -considered sufficient to enable DNS name resolution in small adhoc -networks. The assumption is that if a network has a router, then the -network either has a DNS server or the router can function as a DNS -proxy, possibly implementing dynamic DNS. -In the future, mDNS may be defined to support greater than LINKLOCAL -multicast scope. This would occur if LINKLOCAL mDNS deployment is -successful, the assumption that mDNS is not needed in multiple subnets -proves incorrect, and multicast routing becomes ubiquitous. For -example, it is not clear that this assumption will be valid in large @@ -181,9 +181,24 @@ Esibov, Aboba & Thaler Standards Track [Page 3] -INTERNET-DRAFT Multicast DNS 6 July 2001 +INTERNET-DRAFT Multicast DNS 15 November 2001 +Within small adhoc IPv6 networks, stateful autoconfiguration is the most +likely configuration mechanism. If DHCPv6 is not present, then in order +to support resolution of names of IPv6-only hosts on the local network, +the DNS proxy will need to support dynamic client update as well as DNS +over IPv6. + +Given the above mechanisms enabling DNS name resolution in small +networks with a router, it is assumed that multicast DNS need not be +enabled by default. + +In the future, mDNS may be defined to support greater than LINKLOCAL +multicast scope. This would occur if LINKLOCAL mDNS deployment is +successful, the assumption that mDNS is not needed on multiple links +proves incorrect, and multicast routing becomes ubiquitous. For +example, it is not clear that this assumption will be valid in large adhoc networking scenarios. Once we have experience in mDNS deployment in terms of administrative @@ -206,6 +221,31 @@ LINKLOCAL address. The RD (Recursion Desired) bit MUST NOT be set. If a responder receives a query with the header containing RD set bit, the responder MUST ignore the RD bit. +The IPv6 LINKLOCAL address a given responder listens to, and to which a +sender sends, is a link-local multicast address formed as follows: The +name of the resource record in question is expressed in its canonical +form (see RFC 2535 [15], section 8.1), which is uncompressed with all +alphabetic characters in lower case. The first label of the resource +record name is then hashed using the MD5 algorithm (see RFC 1321 [16]). +The first 32 bits of the resultant 128-bit hash is then appended to the +prefix FF02:0:0:0:0:2::/96 to yield the 128-bit "solicited name +multicast address". (Note: this procedure is intended to be the same as +that specified in section 3 of "IPv6 Node Information Queries" [14]). A +responder that listens for queries for multiple names will necessarily + + + +Esibov, Aboba & Thaler Standards Track [Page 4] + + + + + +INTERNET-DRAFT Multicast DNS 15 November 2001 + + +listen to multiple of these solicited name multicast addresses. + If the multicast query is not positively resolved ("positively resolved" refers in this document to a response with the RCODE set to 0) during a limited amount of time, then a sender MAY repeat the transmission of a @@ -214,14 +254,14 @@ a host capable of responding to the query. Repetition MUST NOT be attempted more than 3 times and SHOULD NOT be repeated more often than once per second to reduce unnecessary network -traffic. The delay between attempts should be randomised so as to avoid -synchronisation effects. +traffic. The delay between attempts should be randomized so as to avoid +synchronization effects. 2.1.2. Behavior of responders -A responder listens on port 53 on the LINKLOCAL address. Responders MUST -respond to multicast queries to those and only those names for which -they are authoritative. As an example, computer +A responder listens on port 53 on the LINKLOCAL address. Responders +MUST respond to multicast queries to those and only those names for +which they are authoritative. As an example, computer "host.example.com.local.arpa." is authoritative for the domain "host.example.com.local.arpa.". On receiving a multicast DNS A record query for the name "host.example.com.local.arpa." such a host responds @@ -232,18 +272,6 @@ authoritative for all the domain names under the zone root except for the branches delegated into separate zones. Contrary to conventional DNS terminology, a responder is authoritative only for the zone root. For example the host "host.example.com.local.arpa." is not authoritative for - - - -Esibov, Aboba & Thaler Standards Track [Page 4] - - - - - -INTERNET-DRAFT Multicast DNS 6 July 2001 - - the name "child.host.example.com.local.arpa." unless the host is configured with multiple names, including "host.example.com.local.arpa." and "child.host.example.com.local.arpa.". The purpose of limiting the @@ -265,12 +293,24 @@ for the NS and glue A record to "host.example.com.local.arpa.", but this approach significantly complicates implementation of multicast DNS and would not be acceptable for lightweight hosts. + + +Esibov, Aboba & Thaler Standards Track [Page 5] + + + + + +INTERNET-DRAFT Multicast DNS 15 November 2001 + + A response to a multicast query is composed in exactly the same manner -as a response to the unicast DNS query as specified in [4]. Responders -MUST never respond using cached data, and the AA (Authoritative Answer) -bit MUST be set. The response is sent to the sender via unicast. A -response to an mDNS query MUST have RCODE set to zero, since mDNS -responders MUST NOT send error replies in response to mDNS queries. +as a response to the unicast DNS query as specified in RFC 1035 [4]. +Responders MUST never respond using cached data, and the AA +(Authoritative Answer) bit MUST be set. The response is sent to the +sender via unicast. A response to an mDNS query MUST have RCODE set to +zero. mDNS responders may respond only to queries which they can resolve +positively. If a TC (truncation) bit is set in the response, then the sender MAY use the response if it contains all necessary information, or the sender MAY @@ -282,28 +322,17 @@ it. 2.1.3. mDNS addressing -For IPv4 LINKLOCAL addressing, section 2.4 of [6] lays out the rules -with respect to source address selection, TTL settings, and acceptable +For IPv4 LINKLOCAL addressing, section 2.4 of "Dynamic Configuration of +IPv4 Link-Local Addresses" [18] lays out the rules with respect to +source address selection, TTL settings, and acceptable source/destination address combinations. IPv6 LINKLOCAL addressing is -described in [9]. mDNS queries and responses MUST obey the rules laid -out in these documents. +described in RFC 2373 [9]. mDNS queries and responses MUST obey the +rules laid out in these documents. In composing an mDNS response, the responder MUST set the Hop Limit field in the IPv6 header and the TTL field in IPv4 header of the multicast DNS response to 255. The sender MUST verify that the Hop Limit field in IPv6 header and TTL field in IPv4 header of each response to - - - -Esibov, Aboba & Thaler Standards Track [Page 5] - - - - - -INTERNET-DRAFT Multicast DNS 6 July 2001 - - the multicast DNS query is set to 255. If it is not, then sender MUST ignore the response. @@ -313,16 +342,28 @@ ignore the response. options are used to specify the TTL of outgoing unicast and multicast packets. The IP_RECVTTL socket option is available on some platforms to receive the IPv4 TTL of received packets with recvmsg(). RFC 2292 - specifies similar options for specifying and receiving the IPv6 Hop - Limit. + [20] specifies similar options for specifying and receiving the IPv6 + Hop Limit. 2.1.4. Use of DNS TTL -The responder should use a pre-configured TTL [5] value in the records +The responder should use a pre-configured TTL value in the records returned in the multicast DNS query response. Due to the TTL minimalization necessary when caching an RRset, all TTLs in an RRset MUST be set to the same value. In the additional and authority section of the response the responder includes the same records as a DNS server + + + +Esibov, Aboba & Thaler Standards Track [Page 6] + + + + + +INTERNET-DRAFT Multicast DNS 15 November 2001 + + would insert in the response to the unicast DNS query. 2.1.5. No/multiple responses @@ -348,29 +389,12 @@ ordinarily. A host configured to be an mDNS "responder" MUST also be configured as a "sender". A host not configured as a "responder" MUST NOT be a "sender". -Multicast DNS usage is determined by the domain search configuration as -well as by special treatment of the ".local.arpa." namespace. Any host -whose domain search configuration contains the ".local.arpa." domain is -configured to behave as "responder". The sender treats queries for +Multicast DNS usage is determined by special treatment of the +".local.arpa." namespace. The sender treats queries for ".local.arpa." +as a special case. A sender MUST NOT send a unicast query for names +ending with the ".local.arpa." suffix except when: - - -Esibov, Aboba & Thaler Standards Track [Page 6] - - - - - -INTERNET-DRAFT Multicast DNS 6 July 2001 - - -".local.arpa." as a special case. The domain search list can be -configured manually or automatically via a DHCP option [3]. - -A sender MUST NOT send a unicast query for names ending with the -".local.arpa." suffix except when: - - a. A sender repeats a query over TCP after it received a response + a. A sender repeats a query after it received a response to the previous multicast query with the TC bit set, or b. The sender's cache contains an NS resource record that enables @@ -387,30 +411,6 @@ when a responder with the name "host.example.com." receives an A type query for the name "host.example.com.local.arpa." it authoritatively responds to the query. -If ".local.arpa" is not in the domain search list, then multicast DNS -MUST NOT be used. This implies that the host will neither listen on the -DNS LINKLOCAL multicast address, nor will it send queries to that -address. An auto-configured host will typically have ".local.arpa" first -in its search list so that it will be enabled to use multicast DNS. -Typically an enterprise host will not have ".local.arpa" in its search -list at all so that it will not use multicast DNS. - -The same host MAY use multicast DNS queries for the resolution of names -ending with ".local.arpa.", and unicast DNS queries for resolution of -all other names. When a user or application requests a DNS client to -resolve a dot-terminated name that contains a ".local.arpa" suffix, the -query for such a name MUST be multicast and the name SHOULD NOT be -concatenated with any suffix. - -If a DNS server is running on a host, the host MUST NOT listen for -multicast DNS queries, to prevent the host from listening on port 53 and -intercepting DNS queries directed to a DNS server. By default, a DNS -server MUST NOT listen to multicast DNS queries. For a DNS server, the -presence of ".local.arpa." in the domain search list MUST NOT enable -multicast DNS. - - - @@ -421,9 +421,81 @@ Esibov, Aboba & Thaler Standards Track [Page 7] -INTERNET-DRAFT Multicast DNS 6 July 2001 +INTERNET-DRAFT Multicast DNS 15 November 2001 +The same host MAY use multicast DNS queries for the resolution of names +ending with ".local.arpa.", and unicast DNS queries for resolution of +all other names. When a user or application requests a DNS client to +resolve a dot-terminated name that contains a ".local.arpa" suffix, the +query for such a name MUST be multicast and the name SHOULD NOT be +concatenated with any suffix. + +If a DNS server is running on a host, then responder MUST NOT listen for +the multicast DNS queries on the same IP addresses on which the DNS +server listens, since otherwise they would intercept DNS queries +directed to a DNS server. The DNS server MUST respond to the multicast +DNS queries only for the RRSets owned by the host on which the server is +running, but MUST NOT respond for the records for which the server is +authoritative. + +3.1. mDNS configuration + +Multicast DNS usage can be configured manually or automatically. On +interfaces where no manual or automatic configuration has been performed +for a given protocol (IPv4 or IPv6), multicast DNS SHOULD be enabled by +default for that protocol. + +For IPv6, the stateless DNS discovery mechanisms described in "IPv6 +Stateless DNS Discovery" [19] can be used to discover whether multicast +DNS should be enabled or disabled on a per-interface basis. + +Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to +configure multicast DNS on an interface. The mDNS Enable Option, +described in [6], can be used to explicitly enable or disable use of +multicast DNS on an interface for a given protocol, as well as to +specify the order in which DNS and multicast DNS is used on that +interface. + +The mDNS Enable Option affects only DNS resolver behavior, that is, how +DNS resolution is performed, and whether multicast DNS is used. The +mDNS Enable Option does not determine whether or in which order DNS +itself is used for name resolution. This can be specified, for example, +using the Name Service Search Option for DHCP, RFC 2937 [3], which can +be used to globally determine where DNS is used within the name service +search order. + +If an interface has been configured for a given protocol via any +automatic configuration mechanism which is able to supply DNS +configuration information, then multicast DNS SHOULD NOT be used on that +interface for that protocol unless it has been explicitly enabled, +whether via that mechanism or any other. This ensures that upgraded +hosts do not change their default behavior, without requiring the source +of the configuration information to be simultaneously updated. This + + + +Esibov, Aboba & Thaler Standards Track [Page 8] + + + + + +INTERNET-DRAFT Multicast DNS 15 November 2001 + + +implies that on the interface, the host will neither listen on the DNS +LINKLOCAL multicast address, nor will it send queries to that address. + +Note that it is possible for mDNS to be enabled for use with IPv6 at the +same time it is disabled for IPv4, and vice versa. For example, where a +home gateway implements a DNS proxy and DHCPv4, but not DHCPv6 or DNS +autoconfiguration, there may be no mechanism for allowing IPv6 hosts to +resolve the names of other IPv6 hosts on the home network. In this +situation, mDNS is useful for resolution of dynamic names, and it will +be enabled for use with IPv6, even though it is disabled for use with +IPv4. + 4. Sequence of events The sequence of events for multicast DNS usage is as follows: @@ -438,11 +510,12 @@ The sequence of events for multicast DNS usage is as follows: 3. Upon the reception of the response, the sender verifies that the Hop Limit field in IPv6 header or TTL field in IPv4 header (depending on - the protocol used) of the response is set to 255. If the destination - address is a LINKLOCAL address, then the sender verifies use of a - LINKLOCAL source address. If these conditions are met, then the sender - uses and caches the returned response. If not, then the sender ignores - the response and continues waiting for the response. + the protocol used) of the response is set to 255. The sender then + verifies compliance with the addressing requirements for IPv4, + described in [18], and IPv6, described in RFC 2373 [9]. If these + conditions are met, then the sender uses and caches the returned + response. If not, then the sender ignores the response and continues + waiting for the response. 5. Conflict resolution @@ -459,6 +532,18 @@ query and type of the query. For example it is expected that: - only a single host may respond to a query for an A type record for a hostname. + + + +Esibov, Aboba & Thaler Standards Track [Page 9] + + + + + +INTERNET-DRAFT Multicast DNS 15 November 2001 + + Every responder that responds to a multicast DNS query and/or dynamic update request AND includes a UNIQUE record in the response: @@ -472,18 +557,6 @@ Where a host is configured to respond to multicast DNS queries on more than one interface, the host MUST verify resource record uniqueness on each interface for each UNIQUE resource record that could be used on that interface. To accomplish this, the host MUST multicast a dynamic - - - -Esibov, Aboba & Thaler Standards Track [Page 8] - - - - - -INTERNET-DRAFT Multicast DNS 6 July 2001 - - DNS update request as specified in RFC 2136 [11] for each new UNIQUE resource record. Uniqueness verification is carried out when the host: @@ -497,7 +570,7 @@ Below we describe the data to be specified in the dynamic update request: Header section - contains values according to [RFC 2136]. + contains values according to RFC 2136 [11]. Zone section The zone name in the zone section MUST be set to the name of the @@ -519,31 +592,34 @@ Additional section When a host that owns a UNIQUE record receives a dynamic update request that requests that the UNIQUE resource record set does not exist, the + + + +Esibov, Aboba & Thaler Standards Track [Page 10] + + + + + +INTERNET-DRAFT Multicast DNS 15 November 2001 + + host MUST respond via unicast with the YXRRSET error, according to the rules described in Section 3 of RFC 2136 [11]. After client receives an YXRRSET response to its dynamic update request -that a UNIQUE resource record does not exist, the host MUST not use the -UNIQUE resource record in responses to multicast queries and dynamic -update requests. +that a UNIQUE resource record does not exist, the host MUST check +whether the response arrived on another interface. If this is the case, +then the client can use the UNIQUE resource record in response to +multicast queries and dynamic update requests. If not, then it MUST NOT +use the UNIQUE resource record in response to multicast queries and +dynamic update requests. Note that this name conflict detection mechanism doesn't prevent name conflicts when previously partitioned segments are connected by a bridge. In such a situation, name conflicts are detected when a sender receives more than one response to its multicast DNS query. In this case, the sender sends the first response that it received to all - - - -Esibov, Aboba & Thaler Standards Track [Page 9] - - - - - -INTERNET-DRAFT Multicast DNS 6 July 2001 - - responders that responded to this query except the first one, using unicast. A host that receives a query response containing a UNIQUE resource record that it owns, even if it didn't send such a query, MUST @@ -564,9 +640,7 @@ take. Implementers who are not planning to support multicast DNS on multiple interfaces simultaneously may skip this section. A multi-homed host checks the uniqueness of UNIQUE records as described -in Section 5. - -The situation is illustrated in figure 1 below: +in Section 5. The situation is illustrated in figure 1 below: ---------- ---------- | | | | @@ -576,8 +650,22 @@ The situation is illustrated in figure 1 below: 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, and as a result, the multi-homed myhost -will not be able to respond with a host RR for "myhost". +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 + + + +Esibov, Aboba & Thaler Standards Track [Page 11] + + + + + +INTERNET-DRAFT Multicast DNS 15 November 2001 + + +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 mDNS client sends requests over multiple @@ -592,35 +680,70 @@ illustrated in figure 2 below. Figure 2. Off-segment name conflict - - - -Esibov, Aboba & Thaler Standards Track [Page 10] - - - - - -INTERNET-DRAFT Multicast DNS 6 July 2001 - - If host myhost is configured to use mDNS on both interfaces, it will send mDNS 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 will then forward a response from the first responder to the second responder, who will attempt to verify the uniqueness of host RR for its name, but will not discover a conflict, -since the conflicting host resides on a different subnet. Therefore it -will continue using its name. This illustrates that the proposed name -conflict resolution mechanism does not support resolution of conflicts -between hosts on different subnets. This problem can also occur with -unicast 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. +since the conflicting host resides on a different link. Therefore it +will continue using its name. + +Indeed, 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 unicast 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. + +5.2. API issues + +RFC 2553 [13] provides an API which can partially solve the name +ambiguity problem for applications written to use this API, since the + + + +Esibov, Aboba & Thaler Standards Track [Page 12] + + + + + +INTERNET-DRAFT Multicast DNS 15 November 2001 + + +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. mDNS 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. 6. IANA Considerations -Authors will contact IANA to reserve LINKLOCAL IPv4 and IPv6 addresses. +This specification requires allocation of a link scope IPv4 multicast +addresses for use by multicast DNS. 7. ARPA domain considerations @@ -637,10 +760,10 @@ namespace differs from others in the following respects: scope of authority, not extending to sub-domains of domain they are authoritative for. - - DNS servers SHOULD NOT forward queries for domain names - in the local.arpa domain - if the server cannot answer - the query from its own database, it should reply with a - non-authoritative NXDOMAIN. + - DNS servers SHOULD NOT forward or recursively resolve + queries for domain names in the local.arpa domain - if the + server cannot answer the query from its own database, + it MUST NOT reply. - Hosts may derive their own names in this namespace, independent of centralized authorization and registration @@ -649,21 +772,21 @@ namespace differs from others in the following respects: - There is no delegation or administrative structure to sub-domains of '.local.arpa'. + + + +Esibov, Aboba & Thaler Standards Track [Page 13] + + + + + +INTERNET-DRAFT Multicast DNS 15 November 2001 + + How protocol objects are mapped into lookup keys: Names are associated with resources which can be requested - - - -Esibov, Aboba & Thaler Standards Track [Page 11] - - - - - -INTERNET-DRAFT Multicast DNS 6 July 2001 - - according to the DNS protocol. However, recursive lookup is impossible. Further, mDNS specifies only the use of multicast to transmit these requests. @@ -676,8 +799,8 @@ INTERNET-DRAFT Multicast DNS 6 July 2001 [2] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. -[3] Aboba, B., "DHCP Domain Search Option", Internet draft (work in - progress), draft-aboba-dhc-domsearch-02.txt, June 2001. +[3] Smith, C., "The Name Service Search Option for DHCP", RFC 2937, + September 2000. [4] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987. @@ -685,9 +808,8 @@ INTERNET-DRAFT Multicast DNS 6 July 2001 [5] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November, 1987. -[6] Cheshire, S., Aboba, B., "Dynamic Configuration of IPv4 Link-Local - Addresses", Internet draft (work in progress), draft-ietf-zeroconf- - ipv4-linklocal-03.txt, June 2001. +[6] Guttman, E., "DHCP mDNS Enable Option", Internet draft (work in + progress), draft-guttman-mdns-enable-01.txt, July 2001. [7] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. @@ -709,20 +831,45 @@ INTERNET-DRAFT Multicast DNS 6 July 2001 [12] Huston, G., "Management Guidelines & Operational Requirements for the Internet Infrastructure Domain ("ARPA")", Internet draft (work - in progress), draft-iab-arpa-02.txt, May 2001. + in progress), draft-iab-arpa-03.txt, July 2001. + + + +Esibov, Aboba & Thaler Standards Track [Page 14] -Esibov, Aboba & Thaler Standards Track [Page 12] +INTERNET-DRAFT Multicast DNS 15 November 2001 +[13] Gilligan, R., Thomson, S., Bound, J., Stevens, W., "Basic Socket + Interface Extensions for IPv6", RFC 2553, March 1999. +[14] Crawford, Matt, "IPv6 Node Information Queries", Internet draft + (work in progress), draft-ietf-ipn-gwg-icmp-name-lookups-07.txt, + August 2000. +[15] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, + March 1999. -INTERNET-DRAFT Multicast DNS 6 July 2001 +[16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April + 1992. +[17] Aboba, B., "DHCP Domain Search Option", Internet draft (work in + progress), draft-aboba-dhc-domsearch-08.txt, November 2001. + +[18] Cheshire, S., Aboba, B., "Dynamic Configuration of IPv4 Link-Local + Addresses", Internet draft (work in progress), draft-ietf-zeroconf- + ipv4-linklocal-05.txt, November 2001. + +[19] Thaler, D., Hagino, I., "IPv6 Stateless DNS Discovery", Internet + draft (work in progress), draft-ietf-ipngwg-dns-discovery-02.txt, + July 2001. + +[20] Stevens, W., Thomas, M., "Advanced Sockets API for IPv6", RFC 2292, + February 1998. 9. Security Considerations @@ -739,51 +886,46 @@ In all received responses, the Hop Limit field in IPv6 and the TTL field in IPv4 are verified to contain 255, the maximum legal value. Since routers decrement the Hop Limit on all packets they forward, received packets containing a Hop Limit of 255 must have originated from a -neighbor. Packets destined for a LINKLOCAL address are verified to have -been sent from a LINKLOCAL source address. +neighbor. These threats are most serious in wireless networks such as 802.11, since attackers on a wired network will require physical access to the home network, while wireless attackers may reside outside the home. Link-layer security will serve to secure mDNS against the above threats + + + +Esibov, Aboba & Thaler Standards Track [Page 15] + + + + + +INTERNET-DRAFT Multicast DNS 15 November 2001 + + if it is available. For example, where 802.11 "Wired Equivalency Privacy" (WEP) [10] is implemented, a casual attacker is likely to be deterred from gaining access to the home network. -The mechanism specified in this draft does not require use of the -DNSSEC, which means that the responses to the multicast DNS queries may -not be authenticated. If a network contains a "signed key distribution -center" for all (or at least some) of the DNS zones that the responders -are authoritative for, then hosts on such a network are configured with -the key for the top zone, "local.arpa." (hosted by "signed keys -distribution center") and may use DNSSEC for authentication of the -responders using DNSSEC. +The mechanism specified in this draft does not require use of DNSSEC. +As a result, responses to multicast DNS queries MAY NOT be +authenticated. If a network contains a "signed key distribution center" +for some of the DNS zones that the responders are authoritative for, and +senders on that network are configured with the key for the top zone +"local.arpa." (hosted by "signed keys distribution center"), then +senders MAY authenticate the responses using DNSSEC. Acknowledgments This work builds upon original work done on multicast DNS by Bill -Manning and Bill Woodcock. The authors gratefully acknowledge their +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, Stuart Cheshire, Robert Elz, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron Hattig, Thomas Narten, Erik Nordmark, Sander Van-Valkenburg and Tomohide Nagashima. - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 13] - - - - - -INTERNET-DRAFT Multicast DNS 6 July 2001 - - Authors' Addresses Levon Esibov @@ -798,7 +940,7 @@ Microsoft Corporation One Microsoft Way Redmond, WA 98052 -Phone: +1 (425) 936-6605 +Phone: +1 425 936 6605 EMail: bernarda@microsoft.com Dave Thaler @@ -806,9 +948,22 @@ Microsoft Corporation One Microsoft Way Redmond, WA 98052 -Phone: +1 (425) 703-8835 +Phone: +1 425 703 8835 EMail: dthaler@microsoft.com + + + + +Esibov, Aboba & Thaler Standards Track [Page 16] + + + + + +INTERNET-DRAFT Multicast DNS 15 November 2001 + + Intellectual Property Statement The IETF takes no position regarding the validity or scope of any @@ -831,19 +986,6 @@ which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. - - - - -Esibov, Aboba & Thaler Standards Track [Page 14] - - - - - -INTERNET-DRAFT Multicast DNS 6 July 2001 - - Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. @@ -869,8 +1011,21 @@ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Expiration Date -This memo is filed as , and expires -January 15, 2002. + + + + +Esibov, Aboba & Thaler Standards Track [Page 17] + + + + + +INTERNET-DRAFT Multicast DNS 15 November 2001 + + +This memo is filed as , and expires May +22, 2002. @@ -895,6 +1050,31 @@ January 15, 2002. -Esibov, Aboba & Thaler Standards Track [Page 15] + + + + + + + + + + + + + + + + + + + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 18]