--- /dev/null
+
+
+
+
+
+
+Network Working Group O. Kolkman
+Request for Comments: 3757 RIPE NCC
+Updates: 3755, 2535 J. Schlyter
+Category: Standards Track NIC-SE
+ E. Lewis
+ ARIN
+ April 2004
+
+
+ Domain Name System KEY (DNSKEY) Resource Record (RR)
+ Secure Entry Point (SEP) Flag
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ With the Delegation Signer (DS) resource record (RR), the concept of
+ a public key acting as a secure entry point (SEP) has been
+ introduced. During exchanges of public keys with the parent there is
+ a need to differentiate SEP keys from other public keys in the Domain
+ Name System KEY (DNSKEY) resource record set. A flag bit in the
+ DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP.
+ The flag bit is intended to assist in operational procedures to
+ correctly generate DS resource records, or to indicate what DNSKEYs
+ are intended for static configuration. The flag bit is not to be
+ used in the DNS verification protocol. This document updates RFC
+ 2535 and RFC 3755.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al. Standard Track [Page 1]
+\f
+RFC 3757 DNSKEY RR SEP Flag April 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. The Secure Entry Point (SEP) Flag. . . . . . . . . . . . . . . 4
+ 3. DNSSEC Protocol Changes. . . . . . . . . . . . . . . . . . . . 4
+ 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4
+ 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
+ 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
+ 7. Internationalization Considerations. . . . . . . . . . . . . . 6
+ 8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 6
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . 6
+ 9.2. Informative References . . . . . . . . . . . . . . . . . 6
+ 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
+ 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
+
+1. Introduction
+
+ "All keys are equal but some keys are more equal than others" [6].
+
+ With the definition of the Delegation Signer Resource Record (DS RR)
+ [5], it has become important to differentiate between the keys in the
+ DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
+ other keys in the DNSKEY RR set. We refer to these public keys as
+ Secure Entry Point (SEP) keys. A SEP key either used to generate a
+ DS RR or is distributed to resolvers that use the key as the root of
+ a trusted subtree [3].
+
+ In early deployment tests, the use of two (kinds of) key pairs for
+ each zone has been prevalent. For one kind of key pair the private
+ key is used to sign just the zone's DNSKEY resource record (RR) set.
+ Its public key is intended to be referenced by a DS RR at the parent
+ or configured statically in a resolver. The private key of the other
+ kind of key pair is used to sign the rest of the zone's data sets.
+ The former key pair is called a key-signing key (KSK) and the latter
+ is called a zone-signing key (ZSK). In practice there have been
+ usually one of each kind of key pair, but there will be multiples of
+ each at times.
+
+ It should be noted that division of keys pairs into KSK's and ZSK's
+ is not mandatory in any definition of DNSSEC, not even with the
+ introduction of the DS RR. But, in testing, this distinction has
+ been helpful when designing key roll over (key super-cession)
+ schemes. Given that the distinction has proven helpful, the labels
+ KSK and ZSK have begun to stick.
+
+
+
+
+
+
+Kolkman, et al. Standard Track [Page 2]
+\f
+RFC 3757 DNSKEY RR SEP Flag April 2004
+
+
+ There is a need to differentiate the public keys for the key pairs
+ that are used for key signing from keys that are not used key signing
+ (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to
+ be sent for generating DS RRs, which DNSKEYs are to be distributed to
+ resolvers, and which keys are fed to the signer application at the
+ appropriate time.
+
+ In other words, the SEP bit provides an in-band method to communicate
+ a DNSKEY RR's intended use to third parties. As an example we
+ present 3 use cases in which the bit is useful:
+
+ The parent is a registry, the parent and the child use secured DNS
+ queries and responses, with a preexisting trust-relation, or plain
+ DNS over a secured channel to exchange the child's DNSKEY RR sets.
+ Since a DNSKEY RR set will contain a complete DNSKEY RRset the SEP
+ bit can be used to isolate the DNSKEYs for which a DS RR needs to
+ be created.
+
+ An administrator has configured a DNSKEY as root for a trusted
+ subtree into security aware resolver. Using a special purpose
+ tool that queries for the KEY RRs from that domain's apex, the
+ administrator will be able to notice the roll over of the trusted
+ anchor by a change of the subset of KEY RRs with the DS flag set.
+
+ A signer might use the SEP bit on the public key to determine
+ which private key to use to exclusively sign the DNSKEY RRset and
+ which private key to use to sign the other RRsets in the zone.
+
+ As demonstrated in the above examples it is important to be able to
+ differentiate the SEP keys from the other keys in a DNSKEY RR set in
+ the flow between signer and (parental) key-collector and in the flow
+ between the signer and the resolver configuration. The SEP flag is
+ to be of no interest to the flow between the verifier and the
+ authoritative data store.
+
+ The reason for the term "SEP" is a result of the observation that the
+ distinction between KSK and ZSK key pairs is made by the signer, a
+ key pair could be used as both a KSK and a ZSK at the same time. To
+ be clear, the term SEP was coined to lessen the confusion caused by
+ the overlap. (Once this label was applied, it had the side effect of
+ removing the temptation to have both a KSK flag bit and a ZSK flag
+ bit.)
+
+ 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 BCP 14, RFC 2119 [1].
+
+
+
+
+
+Kolkman, et al. Standard Track [Page 3]
+\f
+RFC 3757 DNSKEY RR SEP Flag April 2004
+
+
+2. The Secure Entry Point (SEP) Flag
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | flags |S| protocol | algorithm |
+ | |E| | |
+ | |P| | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | /
+ / public key /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ DNSKEY RR Format
+ This document assigns the 15th bit in the flags field as the secure
+ entry point (SEP) bit. If the bit is set to 1 the key is intended to
+ be used as secure entry point key. One SHOULD NOT assign special
+ meaning to the key if the bit is set to 0. Operators can recognize
+ the secure entry point key by the even or odd-ness of the decimal
+ representation of the flag field.
+
+3. DNSSEC Protocol Changes
+
+ The bit MUST NOT be used during the resolving and verification
+ process. The SEP flag is only used to provide a hint about the
+ different administrative properties of the key and therefore the use
+ of the SEP flag does not change the DNS resolution protocol or the
+ resolution process.
+
+4. Operational Guidelines
+
+ The SEP bit is set by the key-pair-generator and MAY be used by the
+ zone signer to decide whether the public part of the key pair is to
+ be prepared for input to a DS RR generation function. The SEP bit is
+ recommended to be set (to 1) whenever the public key of the key pair
+ will be distributed to the parent zone to build the authentication
+ chain or if the public key is to be distributed for static
+ configuration in verifiers.
+
+ When a key pair is created, the operator needs to indicate whether
+ the SEP bit is to be set in the DNSKEY RR. As the SEP bit is within
+ the data that is used to compute the 'key tag field' in the SIG RR,
+ changing the SEP bit will change the identity of the key within DNS.
+ In other words, once a key is used to generate signatures, the
+ setting of the SEP bit is to remain constant. If not, a verifier
+ will not be able to find the relevant KEY RR.
+
+
+
+
+Kolkman, et al. Standard Track [Page 4]
+\f
+RFC 3757 DNSKEY RR SEP Flag April 2004
+
+
+ When signing a zone, it is intended that the key(s) with the SEP bit
+ set (if such keys exist) are used to sign the KEY RR set of the zone.
+ The same key can be used to sign the rest of the zone data too. It
+ is conceivable that not all keys with a SEP bit set will sign the
+ DNSKEY RR set, such keys might be pending retirement or not yet in
+ use.
+
+ When verifying a RR set, the SEP bit is not intended to play a role.
+ How the key is used by the verifier is not intended to be a
+ consideration at key creation time.
+
+ Although the SEP flag provides a hint on which public key is to be
+ used as trusted root, administrators can choose to ignore the fact
+ that a DNSKEY has its SEP bit set or not when configuring a trusted
+ root for their resolvers.
+
+ Using the SEP flag a key roll over can be automated. The parent can
+ use an existing trust relation to verify DNSKEY RR sets in which a
+ new DNSKEY RR with the SEP flag appears.
+
+5. Security Considerations
+
+ As stated in Section 3 the flag is not to be used in the resolution
+ protocol or to determine the security status of a key. The flag is
+ to be used for administrative purposes only.
+
+ No trust in a key should be inferred from this flag - trust MUST be
+ inferred from an existing chain of trust or an out-of-band exchange.
+
+ Since this flag might be used for automating public key exchanges, we
+ think the following consideration is in place.
+
+ Automated mechanisms for roll over of the DS RR might be vulnerable
+ to a class of replay attacks. This might happen after a public key
+ exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
+ SEP flag set, is sent to the parent. The parent verifies the DNSKEY
+ RR set with the existing trust relation and creates the new DS RR
+ from the DNSKEY RR that the current DS RR is not pointing to. This
+ key exchange might be replayed. Parents are encouraged to implement
+ a replay defense. A simple defense can be based on a registry of
+ keys that have been used to generate DS RRs during the most recent
+ roll over. These same considerations apply to entities that
+ configure keys in resolvers.
+
+
+
+
+
+
+
+
+Kolkman, et al. Standard Track [Page 5]
+\f
+RFC 3757 DNSKEY RR SEP Flag April 2004
+
+
+6. IANA Considerations
+
+ IANA has assigned the 15th bit in the DNSKEY Flags Registry (see
+ Section 4.3 of [4]) as the Secure Entry Point (SEP) bit.
+
+7. Internationalization Considerations
+
+ Although SEP is a popular acronym in many different languages, there
+ are no internationalization considerations.
+
+8. Acknowledgments
+
+ The ideas documented in this document are inspired by communications
+ we had with numerous people and ideas published by other folk. Among
+ others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
+ Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
+ have contributed ideas and provided feedback.
+
+ This document saw the light during a workshop on DNSSEC operations
+ hosted by USC/ISI in August 2002.
+
+9. References
+
+9.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Eastlake, D., "Domain Name System Security Extensions", RFC
+ 2535, March 1999.
+
+ [3] Lewis, E., "DNS Security Extension Clarification on Zone
+ Status", RFC 3090, March 2001.
+
+ [4] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer
+ (DS)", RFC 3755, April 2004.
+
+9.2. Informative References
+
+ [5] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
+ RFC 3658, December 2003.
+
+ [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
+ Story", ISBN 0151002177 (50th anniversary edition), April 1996.
+
+
+
+
+
+
+
+Kolkman, et al. Standard Track [Page 6]
+\f
+RFC 3757 DNSKEY RR SEP Flag April 2004
+
+
+10. Authors' Addresses
+
+ Olaf M. Kolkman
+ RIPE NCC
+ Singel 256
+ Amsterdam 1016 AB
+ NL
+
+ Phone: +31 20 535 4444
+ EMail: olaf@ripe.net
+ URI: http://www.ripe.net/
+
+
+ Jakob Schlyter
+ NIC-SE
+ Box 5774
+ SE-114 87 Stockholm
+ Sweden
+
+ EMail: jakob@nic.se
+ URI: http://www.nic.se/
+
+
+ Edward P. Lewis
+ ARIN
+ 3635 Concorde Parkway Suite 200
+ Chantilly, VA 20151
+ US
+
+ Phone: +1 703 227 9854
+ EMail: edlewis@arin.net
+ URI: http://www.arin.net/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al. Standard Track [Page 7]
+\f
+RFC 3757 DNSKEY RR SEP Flag April 2004
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78 and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+ INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed
+ to pertain to the implementation or use of the technology
+ described in this document or the extent to which any license
+ under such rights might or might not be available; nor does it
+ represent that it has made any independent effort to identify any
+ such rights. Information on the procedures with respect to
+ rights in RFC documents can be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use
+ of such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository
+ at http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention
+ any copyrights, patents or patent applications, or other
+ proprietary rights that may cover technology that may be required
+ to implement this standard. Please address the information to the
+ IETF at ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Kolkman, et al. Standard Track [Page 8]
+\f
projects / thirdparty / bind9.git / commitdiff
