452 lines
16 KiB
Plaintext
452 lines
16 KiB
Plaintext
|
|
|
|
|
|
|
|
|
|
|
|
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]
|
|
|
|
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]
|
|
|
|
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]
|
|
|
|
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]
|
|
|
|
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]
|
|
|
|
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]
|
|
|
|
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]
|
|
|
|
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]
|
|
|