--- /dev/null
+
+
+DNS Extentions O. Kolkman
+Internet-Draft RIPE NCC
+Expires: March 4, 2003 September 3, 2002
+
+
+ KEY RR Key Signing (KS) Flag
+ draft-ietf-dnsext-keyrr-key-signing-flag-00.txt
+
+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.
+
+ This Internet-Draft will expire on March 4, 2003.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ The Introduction of the DS [1] record has introduced the concept of
+ KEY signing and zone signing keys. In general, KEY signing keys are
+ the keys that are pointed to by DS records and are the secure entry
+ points to a zone. The key signing keys only sign the KEY RRset at
+ the apex of a zone, zone signing keys sign all data in a zone. We
+ propose a flag to distinguish the KEY signing key from other keys in
+ the KEY RR set during DNSSEC operations.
+
+ 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.
+
+
+
+
+Kolkman Expires March 4, 2003 [Page 1]
+\f
+Internet-Draft KEY RR Key Signing (KS) Flag September 2002
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. The Key Signing flag . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. DNSSEC Protocol changes . . . . . . . . . . . . . . . . . . . . 3
+ 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 4
+ 5. Security considerations . . . . . . . . . . . . . . . . . . . . 4
+ 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
+ References . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman Expires March 4, 2003 [Page 2]
+\f
+Internet-Draft KEY RR Key Signing (KS) Flag September 2002
+
+
+1. Introduction
+
+ The Introduction of the DS record has introduced the concept of KEY
+ signing keys. In general these are the keys that are pointed to by
+ DS records and are the secure entry points to a zone. These key
+ signing keys may also be configured in resolver systems that use
+ zones as a root for a secure island.
+
+ Early deployment tests have shown that during DNSSEC parent-child
+ interactions it is useful to indicate which keys are to be used as
+ the secure entry point to a zone. We introduce the Key Signing Key
+ flag to indicate this special 'administrative' status of the key.
+
+ During DNSSEC parent-child interactions it is useful to indicate
+ which keys are to be used as the secure entry point to a zone.
+ During key rollovers the KS-flag can be used by the parent to
+ determine from which key the DS RR is to be generated from.
+
+2. The Key Signing 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 |K| protocol | algorithm |
+ | |S| | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | /
+ / public key /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ KEY RR Format
+
+
+
+ The bit 15th bit (TBD) in the flags field is assigned to be the key
+ signing flag. If set the key is intended to be used as key signing
+ key. If the bit is not set then no special meaning should be
+ assigned. The 15th bit is currently reserved [2].
+
+3. DNSSEC Protocol changes
+
+ The use of the KS flag does NOT change the DNS resolution and
+ resolution protocol. The KS flag is only used to provide a hint
+ about the different administrative properties and MUST NOT be used
+ during the resolving process.
+
+
+
+
+Kolkman Expires March 4, 2003 [Page 3]
+\f
+Internet-Draft KEY RR Key Signing (KS) Flag September 2002
+
+
+4. Operational Guidelines
+
+ By setting the KS-flag on a particular key, zone administrators
+ indicate that that key should be used as the secure entry point for
+ their zone. Therefore zone administrators SHOULD set the bit only
+ for zone keys that are used to sign the KEY RRset and are intended to
+ act as the top of the chain of trust for their zone.
+
+ Parent zone administrators and resolver administrators MAY choose to
+ ignore the flag.
+
+ Even with the KS-flag there is no mechanism to distinguish between
+ keys that should be used by the parent to point DS records to or keys
+ to be used by resolver administrators as statically configured keys.
+
+ If the bit is modified during the lifetime of the key then this would
+ have impact on the keytag and on the hash data in the DS RRs
+ intending to point to this key. The bit SHOULD NOT be modified once
+ the key has been put into use.
+
+5. Security considerations
+
+ The flag MUST NOT 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.
+
+ If the flag is used to determine which key is to be used as the
+ secure entry point then the trust in the key should be inferred from
+ an existing DNS chain of trust or by an out of band key exchange.
+
+6. Acknowledgments
+
+ The ideas documented in this draft are inspired by communications we
+ had with numerous people and ideas published by other folk, Jakob
+ Schlyter and Olafur Gudmundsson and Dan Massey have been most
+ substantial in providing ideas and feedback.
+
+ This document saw the light during a workshop on DNSSEC operations
+ hosted by USC/ISI.
+
+ "Animal Farm; a Fairy Story" was first published by George Orwell in
+ 1945, The version illustrated by Ralph Steadman is one we recommend (
+ ISBN: 0151002177 ).
+
+References
+
+ [1] Gudmundsson, "Delegation Signer Resource Record", work in
+ progress draft-ietf-dnsext-delegation-signer-08.txt, June 2002.
+
+
+
+Kolkman Expires March 4, 2003 [Page 4]
+\f
+Internet-Draft KEY RR Key Signing (KS) Flag September 2002
+
+
+ [2] Massey and Rose, "Limiting the Scope of the KEY Resource
+ Record", work in progress draft-ietf-dnsext-restrict-key-for-
+ dnssec-03, June 28 2002.
+
+
+Author's Address
+
+ 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/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman Expires March 4, 2003 [Page 5]
+\f
+Internet-Draft KEY RR Key Signing (KS) Flag September 2002
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman Expires March 4, 2003 [Page 6]
+\f
projects / thirdparty / bind9.git / commitdiff
