datatracker.ietf.org
Sign in
Version 5.8.1, 2014-12-18
Report a bug

Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag
RFC 3757

Document type: RFC - Proposed Standard (May 2004; Errata)
Obsoleted by RFC 4033, RFC 4035, RFC 4034
Document stream: IETF
Last updated: 2014-06-21
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 3757 (Proposed Standard)
Responsible AD: Thomas Narten
Send notices to: No addresses provided

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

[include full document text]