-\r
-\r
-DNS Extensions O. Kolkman\r
-Internet-Draft RIPE NCC\r
-Expires: June 3, 2003 J. Schlyter\r
- Carlstedt Research &\r
- Technology\r
- December 3, 2002\r
-\r
-\r
- KEY RR Key-Signing Key (KSK) Flag\r
- draft-ietf-dnsext-keyrr-key-signing-flag-04\r
-\r
-Status of this Memo\r
-\r
- This document is an Internet-Draft and is in full conformance with\r
- all provisions of Section 10 of RFC2026.\r
-\r
- Internet-Drafts are working documents of the Internet Engineering\r
- Task Force (IETF), its areas, and its working groups. Note that\r
- other groups may also distribute working documents as Internet-\r
- Drafts.\r
-\r
- Internet-Drafts are draft documents valid for a maximum of six months\r
- and may be updated, replaced, or obsoleted by other documents at any\r
- time. It is inappropriate to use Internet-Drafts as reference\r
- material or to cite them other than as "work in progress."\r
-\r
- The list of current Internet-Drafts can be accessed at http://\r
- www.ietf.org/ietf/1id-abstracts.txt.\r
-\r
- The list of Internet-Draft Shadow Directories can be accessed at\r
- http://www.ietf.org/shadow.html.\r
-\r
- This Internet-Draft will expire on June 3, 2003.\r
-\r
-Copyright Notice\r
-\r
- Copyright (C) The Internet Society (2002). All Rights Reserved.\r
-\r
-Abstract\r
-\r
- With the DS record [5] the concept of key-signing and zone-signing\r
- keys has been introduced. Key-signing keys are the keys that sign\r
- the keyset only. In general, key-signing keys are the keys that are\r
- pointed to by DS records and are the first keys to be used when\r
- following a chain of trust into the zone. The key-signing keys only\r
- sign the KEY RRset at the apex of a zone, zone- signing keys sign all\r
- other data in a zone. We propose a flag to distinguish the key-\r
- signing key from other keys in the KEY RR set during DNSSEC\r
- operations.\r
-\r
-\r
-\r
-Kolkman & Schlyter Expires June 3, 2003 [Page 1]\r
-\f\r
-Internet-Draft KEY RR Key-Signing Key (KSK) Flag December 2002\r
-\r
-\r
- The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",\r
- "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be\r
- interpreted as described in RFC2119.\r
-\r
-Table of Contents\r
-\r
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3\r
- 2. The Key-Signing Key (KSK) Flag . . . . . . . . . . . . . . . . 3\r
- 3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . 4\r
- 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4\r
- 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4\r
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5\r
- 7. Internationalization Considerations . . . . . . . . . . . . . 5\r
- 8. Document Changes . . . . . . . . . . . . . . . . . . . . . . . 5\r
- 8.1 draft version 00 -> 01 . . . . . . . . . . . . . . . . . . . . 5\r
- 8.2 draft version 01 -> 02 . . . . . . . . . . . . . . . . . . . . 5\r
- 8.3 draft version 02 -> 03 . . . . . . . . . . . . . . . . . . . . 5\r
- 8.4 draft version 03 -> 04 . . . . . . . . . . . . . . . . . . . . 6\r
- 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6\r
- Normative References . . . . . . . . . . . . . . . . . . . . . 6\r
- Informative References . . . . . . . . . . . . . . . . . . . . 6\r
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7\r
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Kolkman & Schlyter Expires June 3, 2003 [Page 2]\r
-\f\r
-Internet-Draft KEY RR Key-Signing Key (KSK) Flag December 2002\r
-\r
-\r
-1. Introduction\r
-\r
- "All keys are equal but some keys are more equal than others" [6]\r
-\r
- With the DS record [5] the concept of key-signing and zone-signing\r
- keys has been introduced into DNSSEC[3]. In general these are the\r
- keys that are pointed to by DS records and are the first keys to be\r
- used when following the chain of trust into a zone ( secure entry\r
- points of the zone). These key-signing keys may also be configured\r
- in resolver systems that use zones as a trusted root[4] for a secure\r
- island.\r
-\r
- Early deployment tests have shown that during the key-exchange\r
- between the parent and the child it is useful to highlight which keys\r
- are to be used as the secure entry point to a zone. We introduce the\r
- Key-Signing Key flag to indicate this special 'administrative' status\r
- of the key. The availability of the flag allows the key exchange to\r
- be automated where, without the flag, some additional out-of-band\r
- communication is needed.\r
-\r
-2. The Key-Signing Key (KSK) Flag\r
-\r
-\r
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3\r
- 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\r
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r
- | flags |K| protocol | algorithm |\r
- | |S| | |\r
- | |K| | |\r
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r
- | /\r
- / public key /\r
- / /\r
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r
-\r
- KEY RR Format\r
-\r
-\r
-\r
- The KSK bit (TBD) in the flags field is assigned to be the key-\r
- signing flag. If set the key is intended to be used as key-signing\r
- key. No special meaning should be assigned to the bit not being set.\r
- The draft proposes using the current 15'th bit [1] as the KSK bit.\r
- This way operators can recognize the key-signing by the parity of the\r
- decimal representation of the flag field.\r
-\r
-\r
-\r
-\r
-\r
-\r
-Kolkman & Schlyter Expires June 3, 2003 [Page 3]\r
-\f\r
-Internet-Draft KEY RR Key-Signing Key (KSK) Flag December 2002\r
-\r
-\r
-3. DNSSEC Protocol Changes\r
-\r
- The use of the KSK flag does not change the DNS resolution and\r
- resolution protocol. The KSK flag is only used to provide a hint\r
- about the different administrative properties and MUST NOT be used\r
- during the resolving process.\r
-\r
-4. Operational Guidelines\r
-\r
- By setting the KSK flag on a particular key, zone administrators\r
- indicate that that key SHOULD be used as the secure entry point for\r
- their zone. Therefore zone administrators SHOULD set the bit only\r
- for zone keys that are used to sign the KEY RRset and are intended to\r
- act as the first link in the chain of trust for their zone.\r
-\r
- Parent zone administrators and resolver administrators that want to\r
- configure a key-signing key as their 'trusted key' MAY choose to\r
- ignore the flag.\r
-\r
- Using the flag a key roll over can be automated. The parent can use\r
- an existing trust relation to verify keysets in which a new key with\r
- the KSK flag appears.\r
-\r
- If the bit is modified during the lifetime of the key then this would\r
- have impact on the keytag in the SIG RRs and on the hash data in the\r
- DS RRs intending to point to this key. The bit SHOULD NOT be\r
- modified once the key has been put into use.\r
-\r
-5. Security Considerations\r
-\r
- The flag MUST NOT be used in the resolution protocol or to determine\r
- the security status of a key. The flag is to be used for\r
- administrative purposes only.\r
-\r
- No trust in a key should be inferred from this flag - trust must be\r
- inferred from an existing chain of trust or an out-of-band exchange.\r
-\r
- Since this flag might be used for automating key exchanges, we think\r
- the following consideration is in place.\r
-\r
- Automated mechanisms for roll over of the DS RR might be vulnerable\r
- to a class of replay attacks. This might happen after a key exchange\r
- where a keyset, containing two keys with the KSK flag set, is sent to\r
- the parent. The parent verifies the keyset with the existing trust\r
- relation and creates the new DS RR from the key that the current DS\r
- is not pointing to. This key exchange might be replayed. Parents\r
- are encouraged to implement a replay defence. A simple defence can\r
- be based on a registry of keys that have been used to generate DS RRs\r
-\r
-\r
-\r
-Kolkman & Schlyter Expires June 3, 2003 [Page 4]\r
-\f\r
-Internet-Draft KEY RR Key-Signing Key (KSK) Flag December 2002\r
-\r
-\r
- during the most recent roll over.\r
-\r
-6. IANA Considerations\r
-\r
- draft-ietf-dnsext-restrict-key-for-dnssec [1] eliminates all flags\r
- field except for the zone key flag in the KEY RR. We propose to use\r
- the 15'th bit as the KSK bit; the decimal representation of the\r
- flagfield will then be odd for key-signing keys.\r
-\r
-7. Internationalization Considerations\r
-\r
- There are no internationalization considerations\r
-\r
-8. Document Changes\r
-\r
-8.1 draft version 00 -> 01\r
-\r
- Clean up of references and correction of typos;\r
-\r
- modified Abstract text a little;\r
-\r
- Added explicit warning for replay attacks to the security section;\r
-\r
- Removed the text that hinted on a distinction between a key-\r
- signing key configured in resolvers and in parent zones.\r
-\r
-\r
-8.2 draft version 01 -> 02\r
-\r
- Added IANA and Internationalization section.\r
-\r
- Split references into informational and normative.\r
-\r
- Spelling and style corrections.\r
-\r
-\r
-8.3 draft version 02 -> 03\r
-\r
- Changed the name from KS to KSK, this to prevent confusion with\r
- NS, DS and other acronyms in DNS.\r
-\r
- In the security section: Rewrote the section so that it does not\r
- suggest to use a particular type of registry and that it is clear\r
- that a key registry is only one of the defences possible.\r
-\r
- Spelling and style corrections\r
-\r
-\r
-\r
-\r
-\r
-Kolkman & Schlyter Expires June 3, 2003 [Page 5]\r
-\f\r
-Internet-Draft KEY RR Key-Signing Key (KSK) Flag December 2002\r
-\r
-\r
-8.4 draft version 03 -> 04\r
-\r
- Text has been made consistent with the statement: ' No special\r
- meaning should be assigned to the bit not being set.'\r
-\r
- Made explicit that the keytag changes in SIG RR.\r
-\r
-\r
-9. Acknowledgements\r
-\r
- The ideas documented in this draft are inspired by communications we\r
- had with numerous people and ideas published by other folk. Among\r
- others Olafur Gudmundsson, Daniel Karrenberg, Ed Lewis, Dan Massey,\r
- Marcos Sanz and Sam Weiler have contributed ideas and provided\r
- feedback.\r
-\r
- This document saw the light during a workshop on DNSSEC operations\r
- hosted by USC/ISI.\r
-\r
-Normative References\r
-\r
- [1] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource\r
- Record out", draft-ietf-dnsext-restrict-key-for-dnssec-04 (work\r
- in progress), September 2002.\r
-\r
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement\r
- Levels", BCP 14, RFC 2119, March 1997.\r
-\r
- [3] Eastlake, D., "Domain Name System Security Extensions", RFC\r
- 2535, March 1999.\r
-\r
- [4] Lewis, E., "DNS Security Extension Clarification on Zone\r
- Status", RFC 3090, March 2001.\r
-\r
-Informative References\r
-\r
- [5] Gudmundsson, O., "Delegation Signer Resource Record", draft-\r
- ietf-dnsext-delegation-signer-09 (work in progress), September\r
- 2002.\r
-\r
- [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy\r
- Story"", ISBN 0151002177 (50th anniversery edition), April 1996.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Kolkman & Schlyter Expires June 3, 2003 [Page 6]\r
-\f\r
-Internet-Draft KEY RR Key-Signing Key (KSK) Flag December 2002\r
-\r
-\r
-Authors' Addresses\r
-\r
- Olaf M. Kolkman\r
- RIPE NCC\r
- Singel 256\r
- Amsterdam 1016 AB\r
- NL\r
-\r
- Phone: +31 20 535 4444\r
- EMail: olaf@ripe.net\r
- URI: http://www.ripe.net/\r
-\r
-\r
- Jakob Schlyter\r
- Carlstedt Research & Technology\r
- Stora Badhusgatan 18-20\r
- Goteborg SE-411 21\r
- Sweden\r
-\r
- EMail: jakob@crt.se\r
- URI: http://www.crt.se/~jakob/\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Kolkman & Schlyter Expires June 3, 2003 [Page 7]\r
-\f\r
-Internet-Draft KEY RR Key-Signing Key (KSK) Flag December 2002\r
-\r
-\r
-Full Copyright Statement\r
-\r
- Copyright (C) The Internet Society (2002). All Rights Reserved.\r
-\r
- This document and translations of it may be copied and furnished to\r
- others, and derivative works that comment on or otherwise explain it\r
- or assist in its implementation may be prepared, copied, published\r
- and distributed, in whole or in part, without restriction of any\r
- kind, provided that the above copyright notice and this paragraph are\r
- included on all such copies and derivative works. However, this\r
- document itself may not be modified in any way, such as by removing\r
- the copyright notice or references to the Internet Society or other\r
- Internet organizations, except as needed for the purpose of\r
- developing Internet standards in which case the procedures for\r
- copyrights defined in the Internet Standards process must be\r
- followed, or as required to translate it into languages other than\r
- English.\r
-\r
- The limited permissions granted above are perpetual and will not be\r
- revoked by the Internet Society or its successors or assigns.\r
-\r
- This document and the information contained herein is provided on an\r
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING\r
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING\r
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION\r
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF\r
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
-\r
-Acknowledgement\r
-\r
- Funding for the RFC Editor function is currently provided by the\r
- Internet Society.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Kolkman & Schlyter Expires June 3, 2003 [Page 8]\r
-\f\r
+
+
+DNS Extensions O. Kolkman
+Internet-Draft RIPE NCC
+Expires: July 4, 2003 J. Schlyter
+ Carlstedt Research &
+ Technology
+ E. Lewis
+ ARIN
+ January 3, 2003
+
+
+ KEY RR Key-Signing Key (KSK) Flag
+ draft-ietf-dnsext-keyrr-key-signing-flag-05
+
+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 July 4, 2003.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ With the DS resource record the concept of key-signing and zone-
+ signing keys has been introduced. During key-exchanges with the
+ parent there is a need to differentiate between these zone- and key-
+ signing keys. We propose a flag to indicate which key is used as
+ key-signing key.
+
+
+
+
+
+Kolkman, et al. Expires July 4, 2003 [Page 1]
+\f
+Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. The Key-Signing Key (KSK) Flag . . . . . . . . . . . . . . . . 4
+ 3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . 4
+ 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
+ 7. Internationalization Considerations . . . . . . . . . . . . . 6
+ 8. Document Changes . . . . . . . . . . . . . . . . . . . . . . . 6
+ 8.1 draft version 00 -> 01 . . . . . . . . . . . . . . . . . . . . 6
+ 8.2 draft version 01 -> 02 . . . . . . . . . . . . . . . . . . . . 6
+ 8.3 draft version 02 -> 03 . . . . . . . . . . . . . . . . . . . . 6
+ 8.4 draft version 03 -> 04 . . . . . . . . . . . . . . . . . . . . 6
+ 8.5 draft version 04 -> 05 . . . . . . . . . . . . . . . . . . . . 7
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
+ Normative References . . . . . . . . . . . . . . . . . . . . . 7
+ Informative References . . . . . . . . . . . . . . . . . . . . 7
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al. Expires July 4, 2003 [Page 2]
+\f
+Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003
+
+
+1. Introduction
+
+ "All keys are equal but some keys are more equal than others" [6]
+
+ With the definition of the DS Resource Record [5] the concept of a
+ key being either a key-signing key (KSK) or zone-signing key(ZSK) has
+ been introduced into DNSSEC[3]. A KSK is one that signs the zone's
+ KEY RR set, and is a key that is either used to generate a DS RR or
+ is distributed to resolvers that use the key as the root of a trusted
+ subtree[4].
+
+ In early deployment tests, the use of two keys has been prevalent,
+ one key for exchange with delegating zone and the other key to sign
+ the zone. These dual roles were defined to allow a zone to more
+ rapidly change the ZSK without a high volume of traffic needed to
+ make new DS RRs. Because of this, participants have had to manage
+ two keys at all times, one acting as a KSK and the other ZSK (per
+ cryptographic algorithm). In practice, participants used a longer
+ key for the KSK or resorted to writing the footprints on paper.
+
+ There is a need to differentiate between a KSK and a ZSK by the zone
+ administrator. This need is driven by knowing which keys are to be
+ sent for DS RRs, which keys are to be distributed to resolvers, and
+ which keys are fed to the signer application at the appropriate time.
+
+ While addressing this need it is important that the distinction is
+ made in a way compatible with single key zone, those whose KSK and
+ ZSK is one in the same. The best way to address this is to define a
+ bit setting in the KEY RR flags field that is ignored in the
+ resolver. This allows for both dual key and single key management to
+ be workable.
+
+ 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, et al. Expires July 4, 2003 [Page 3]
+\f
+Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003
+
+
+2. The Key-Signing Key (KSK) 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| | |
+ | |K| | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | /
+ / public key /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ KEY RR Format
+
+
+
+ The KSK bit (TBD) in the flags field is assigned to be the key-
+ signing key flag. If the the bit is set to 1 the key is intended to
+ be used as key-signing key. No special meaning should be assigned to
+ the bit is set to 0. The draft proposes using the current 15th bit
+ [1] as the KSK bit. This way operators can recognize the key-signing
+ by the even or odd-ness of the decimal representation of the flag
+ field.
+
+3. DNSSEC Protocol Changes
+
+ The use of the KSK flag does not change the DNS resolution and
+ resolution protocol. The KSK flag is only used to provide a hint
+ about the different administrative properties and MUST NOT be used
+ during the resolving and verification process.
+
+4. Operational Guidelines
+
+ The KSK bit is used to indicate that the key represented in the KEY
+ RR is intended to sign the KEY RR set of the zone. As the KSK bit is
+ within the data that is used to compute a KEY RR's footprint,
+ changing the KSK bit will change the identity of the key within DNS.
+
+ When a key pair is created, the operator needs to indicate whether
+ the KSK bit is to be set in the KEY RR. The KSK bit is recommended
+ 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 signing a zone, it is intended that a key with the KSK bit set
+
+
+
+Kolkman, et al. Expires July 4, 2003 [Page 4]
+\f
+Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003
+
+
+ be 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 KSK bit set will sign the KEY RR set, such keys might
+ be pending retirement or not yet in use.
+
+ When verifying an RR set, the KSK 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 KSK flag provides a hint on which key to be used as
+ trusted root, administrators can choose to ignore the flag when
+ configuring a trusted root for their resolvers.
+
+ Using the flag a key roll over can be automated. The parent can use
+ an existing trust relation to verify key sets in which a new key with
+ the KSK flag appears.
+
+5. Security Considerations
+
+ As stated in Section 3 the flag is not to 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 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 key exchange
+ where a key set, containing two keys with the KSK flag set, is sent
+ to the parent. The parent verifies the key set with the existing
+ trust relation and creates the new DS RR from the key that the
+ current DS is not pointing to. This key exchange might be replayed.
+ Parents are encouraged to implement a replay defence. A simple
+ defence can be based on a registry of keys that have been used to
+ generate DS RRs during the most recent roll over.
+
+6. IANA Considerations
+
+ draft-ietf-dnsext-restrict-key-for-dnssec [1] eliminates all flags
+ field except for the zone key flag in the KEY RR. We propose to use
+ the 15'th bit as the KSK bit; the decimal representation of the
+ flagfield will then be odd for key-signing keys.
+
+
+
+
+
+
+Kolkman, et al. Expires July 4, 2003 [Page 5]
+\f
+Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003
+
+
+7. Internationalization Considerations
+
+ There are no internationalization considerations
+
+8. Document Changes
+
+8.1 draft version 00 -> 01
+
+ Clean up of references and correction of typos;
+
+ modified Abstract text a little;
+
+ Added explicit warning for replay attacks to the security section;
+
+ Removed the text that hinted on a distinction between a key-
+ signing key configured in resolvers and in parent zones.
+
+
+8.2 draft version 01 -> 02
+
+ Added IANA and Internationalization section.
+
+ Split references into informational and normative.
+
+ Spelling and style corrections.
+
+
+8.3 draft version 02 -> 03
+
+ Changed the name from KS to KSK, this to prevent confusion with
+ NS, DS and other acronyms in DNS.
+
+ In the security section: Rewrote the section so that it does not
+ suggest to use a particular type of registry and that it is clear
+ that a key registry is only one of the defences possible.
+
+ Spelling and style corrections
+
+
+8.4 draft version 03 -> 04
+
+ Text has been made consistent with the statement: ' No special
+ meaning should be assigned to the bit not being set.'
+
+ Made explicit that the keytag changes in SIG RR.
+
+
+
+
+
+
+Kolkman, et al. Expires July 4, 2003 [Page 6]
+\f
+Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003
+
+
+8.5 draft version 04 -> 05
+
+ References and acronyms where stripped from the Abstract. the
+ Introduction and the the Operational Guideline section were
+ rewritten in such a way that the draft does not suggest any use of
+ the bit in the verification process and that the draft does not
+ enforce, but suggests, the use of a key- and zone-signing key.
+
+ Added 'and verification' in the sentence "MUST NOT be used during
+ the resolving and verification process" (protocol changes
+ section).
+
+
+9. Acknowledgements
+
+ The ideas documented in this draft are inspired by communications we
+ had with numerous people and ideas published by other folk. Among
+ others Mark Andrews, Olafur Gudmundsson, Daniel Karrenberg, Dan
+ Massey, 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.
+
+Normative References
+
+ [1] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
+ Record out", draft-ietf-dnsext-restrict-key-for-dnssec-04 (work
+ in progress), September 2002.
+
+ [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [3] Eastlake, D., "Domain Name System Security Extensions", RFC
+ 2535, March 1999.
+
+ [4] Lewis, E., "DNS Security Extension Clarification on Zone
+ Status", RFC 3090, March 2001.
+
+Informative References
+
+ [5] Gudmundsson, O., "Delegation Signer Resource Record", draft-
+ ietf-dnsext-delegation-signer-12 (work in progress), December
+ 2002.
+
+ [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
+ Story"", ISBN 0151002177 (50th anniversery edition), April 1996.
+
+
+
+
+Kolkman, et al. Expires July 4, 2003 [Page 7]
+\f
+Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003
+
+
+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
+ Carlstedt Research & Technology
+ Stora Badhusgatan 18-20
+ Goteborg SE-411 21
+ Sweden
+
+ EMail: jakob@crt.se
+ URI: http://www.crt.se/~jakob/
+
+
+ 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. Expires July 4, 2003 [Page 8]
+\f
+Internet-Draft KEY RR Key-Signing Key (KSK) Flag January 2003
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). 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, et al. Expires July 4, 2003 [Page 9]
+\f
projects / thirdparty / bind9.git / commitdiff
