From: Mark Andrews Date: Thu, 29 May 2003 22:03:38 +0000 (+0000) Subject: new draft X-Git-Tag: v9.3.4^3~6 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=7ba2d9d567a61b351c0b28dbbdb2d4a87e156438;p=thirdparty%2Fbind9.git new draft --- diff --git a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-06.txt b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-06.txt deleted file mode 100644 index dba5f909f80..00000000000 --- a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-06.txt +++ /dev/null @@ -1,560 +0,0 @@ - - -DNS Extensions O. Kolkman -Internet-Draft RIPE NCC -Expires: August 18, 2003 J. Schlyter - Carlstedt Research & - Technology - E. Lewis - ARIN - February 17, 2003 - - - KEY RR Key-Signing Key (KSK) Flag - draft-ietf-dnsext-keyrr-key-signing-flag-06 - -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 August 18, 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 August 18, 2003 [Page 1] - -Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 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 . . . . . . . . . . . . . 5 - 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 . . . . . . . . . . . . . . . . . . . . 6 - 8.6 draft version 05 -> 06 . . . . . . . . . . . . . . . . . . . . 7 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 - Normative References . . . . . . . . . . . . . . . . . . . . . 7 - Informative References . . . . . . . . . . . . . . . . . . . . 8 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 - Intellectual Property and Copyright Statements . . . . . . . . 9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman, et al. Expires August 18, 2003 [Page 2] - -Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 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 August 18, 2003 [Page 3] - -Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 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. One SHOULD NOT assign special meaning - to the key if the bit is set to 0. The document 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 bit MUST NOT be used during the resolving and verification - process. The KSK flag is only used to provide a hint about the - different administrative properties of the key and therefore the use - of the KSK flag does not change the DNS resolution and resolution - protocol. - -4. Operational Guidelines - - The KSK bit is set by the key-generator and used by the zone signer: - - 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 the key(s) with the KSK bit - - - -Kolkman, et al. Expires August 18, 2003 [Page 4] - -Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 - - - 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 KSK bit set will sign the KEY - RR set, such keys might be pending retirement or not yet in use. - - When verifying a 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. - -7. Internationalization Considerations - - - - -Kolkman, et al. Expires August 18, 2003 [Page 5] - -Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 - - - 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. - - -8.5 draft version 04 -> 05 - - One occurrence of must and one occurrence of should uppercased - - - -Kolkman, et al. Expires August 18, 2003 [Page 6] - -Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 - - - (RFC2119). - - Reordering of sentences in section 3, so that the point of the bit - NOT being used in resolving is made directly. - - To make explicit that the KSK is used at key generation and at - signing time I added the first sentence to section 4. - - Some minor style and spelling corrections. - - -8.6 draft version 05 -> 06 - - 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 document 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 - - - -Kolkman, et al. Expires August 18, 2003 [Page 7] - -Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 - - - 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. - - -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 August 18, 2003 [Page 8] - -Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property 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; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication 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 implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -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 assignees. - - 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 - - - -Kolkman, et al. Expires August 18, 2003 [Page 9] - -Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003 - - - 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 August 18, 2003 [Page 10] - diff --git a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-07.txt b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-07.txt new file mode 100644 index 00000000000..c360faf9dcf --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-07.txt @@ -0,0 +1,562 @@ + + + + +DNS Extensions O. Kolkman +Internet-Draft RIPE NCC +Expires: July 2, 2003 J. Schlyter + Carlstedt Research & + Technology + E. Lewis + ARIN + January 2003 + + + KEY RR Secure Entry Point (SEP) Flag + draft-ietf-dnsext-keyrr-key-signing-flag-07 + +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 2, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + With the DS resource record the concept of a key acting as a secure + entry point has been introduced. During key-exchanges with the + parent there is a need to differentiate secure entry point keys from + other keys in the KEY resource record set. A flag bit in the KEY RR + is defined to indicate that KEY is to be used as a secure entry + point. + + + + +Kolkman, et al. Expires July 2, 2003 [Page 1] + +Internet-Draft KEY RR Secure Entry Point (SEP) Flag January 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Secure Entry Point (SEP) 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 + 8.6 draft version 05 -> 06 . . . . . . . . . . . . . . . . . . . . 7 + 8.7 draft version 06 -> 07 . . . . . . . . . . . . . . . . . . . . 7 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 + Normative References . . . . . . . . . . . . . . . . . . . . . 7 + Informative References . . . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman, et al. Expires July 2, 2003 [Page 2] + +Internet-Draft KEY RR Secure Entry Point (SEP) 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] it has become + important to differentiate between the zone keys that are (to be) + pointed to by parental DS RRs and other keys in the zone. We refer + to these keys as Secure Entry Point (SEP) keys. A SEP key is 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) keys in each + zone has been prevalent. One key is used to sign just the zone's KEY + RR set and is the key referenced by a DS RR at the parent or + configured statically in a resolver. Another key is used to sign the + rest of the zone's data sets. The former key 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, but there + will be multiples of each at times. + + It should be noted that division of zone keys 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. + + The reason for the term "SEP" is a result of the observation that the + distinction between KSK and ZSK is only significant to the signer + element of the DNS. Servers, resolvers and verifiers do not need to + make the distinction. Further, distinguishing between a KSK and ZSK + requires more than one bit, as a key could be fulfilling both roles. + Hence, there is no definition for a ZSK bit and another for a KSK + bit, just a single bit to assist operational procedures to correctly + generate DS RRs, or to indicate what keys are intended for static + configuration. + + 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 2, 2003 [Page 3] + +Internet-Draft KEY RR Secure Entry Point (SEP) Flag January 2003 + + +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 / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + KEY RR Format + + + + The SEP bit (TBD) in the flags field is assigned to be the secure + entry point flag. If the 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. The document proposes + using the current 15th bit [4] as the SEP bit. This way 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 and resolution + protocol. + +4. Operational Guidelines + + The SEP bit is set by the key-generator and MAY be used by the zone + signer to decide whether the key is to be prepared for input to a DS + RR generation function. As the SEP bit is within the data that is + used to compute a KEY RR's footprint, changing the SEP bit will + change the identity of the key within DNS. + + When a key pair is created, the operator needs to indicate whether + the SEP bit is to be set in the KEY RR. The SEP 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. + + + +Kolkman, et al. Expires July 2, 2003 [Page 4] + +Internet-Draft KEY RR Secure Entry Point (SEP) Flag January 2003 + + + 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 KEY + 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 key to be used as + trusted root, administrators can choose to ignore the fact that a KEY + has its SEP bit set or not 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 SEP 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 SEP 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 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. + +6. IANA Considerations + + draft-ietf-dnsext-restrict-key-for-dnssec [4] eliminates all flags + field except for the zone key flag in the KEY RR. We propose to use + the 15'th bit as the SEP bit; the decimal representation of the + flagfield will then be odd for key-signing keys. + + + +Kolkman, et al. Expires July 2, 2003 [Page 5] + +Internet-Draft KEY RR Secure Entry Point (SEP) Flag January 2003 + + +7. Internationalization Considerations + + Although SEP is a popular acronym in many different languages, 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 defenses 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 key tag changes in SIG RR. + + + + + +Kolkman, et al. Expires July 2, 2003 [Page 6] + +Internet-Draft KEY RR Secure Entry Point (SEP) Flag January 2003 + + +8.5 draft version 04 -> 05 + + One occurrence of must and one occurrence of should uppercased + (RFC2119). + + Reordering of sentences in section 3, so that the point of the bit + NOT being used in resolving is made directly. + + To make explicit that the KSK is used at key generation and at + signing time I added the first sentence to section 4. + + Some minor style and spelling corrections. + + +8.6 draft version 05 -> 06 + + 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). + + +8.7 draft version 06 -> 07 + + Based on comments during the last call we changed the name from + KSK-flag to SEP flag. The introduction was rewritten to reflect + the motivations of this name change and to stress that the SEP key + is not relevant to the signer process. + + +9. 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, Miek Gieben, 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 + + + + +Kolkman, et al. Expires July 2, 2003 [Page 7] + +Internet-Draft KEY RR Secure Entry Point (SEP) Flag January 2003 + + + [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] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource + Record (RR)", RFC 3445, December 2002. + +Informative References + + [5] Gudmundsson, O., "Delegation Signer Resource Record", draft- + ietf-dnsext-delegation-signer-14 (work in progress), May 2003. + + [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy + Story"", ISBN 0151002177 (50th anniversery edition), April 1996. + + +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/ + + + + + + + + + +Kolkman, et al. Expires July 2, 2003 [Page 8] + +Internet-Draft KEY RR Secure Entry Point (SEP) Flag January 2003 + + + 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 2, 2003 [Page 9] + +Internet-Draft KEY RR Secure Entry Point (SEP) 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 2, 2003 [Page 10] +