mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-30 22:15:20 +00:00
Code Issues Releases Wiki Activity

new draft

Browse Source
This commit is contained in:
Mark Andrews
2002-10-25 22:11:35 +00:00
parent 555bbd0321
commit 81a35f00a0
6 changed files with 1002 additions and 766 deletions
Download Patch File Download Diff File Expand all files Collapse all files

277
doc/draft/draft-ietf-dnsext-delegation-signer-08.txt → doc/draft/draft-ietf-dnsext-delegation-signer-10.txt
View File

@@ -4,9 +4,10 @@
DNSEXT Working Group Olafur Gudmundsson
INTERNET-DRAFT June 2002
<draft-ietf-dnsext-delegation-signer-08.txt>
INTERNET-DRAFT October 2002
<draft-ietf-dnsext-delegation-signer-10.txt>
Updates: RFC 1035, RFC 2535, RFC 3008, RFC 3090.
@@ -38,7 +39,7 @@ Status of this Memo
Comments should be sent to the authors or the DNSEXT WG mailing list
namedroppers@ops.ietf.org
This draft expires on December 30, 2002.
This draft expires on April 16, 2003.
Copyright Notice
@@ -56,9 +57,9 @@ Abstract
Gudmundsson Expires December 2002 [Page 1]
INTERNET-DRAFT Delegation Signer Record June 2002
Gudmundsson Expires April 2003 [Page 1]
INTERNET-DRAFT Delegation Signer Record October 2002
operational considerations. The intent is to use this resource record
@@ -85,7 +86,7 @@ INTERNET-DRAFT Delegation Signer Record June 2002
on the Internet have differing NS RRsets at parent and child. There
are a number of reasons for this, including a lack of communication
between parent and child and bogus name servers being listed to meet
registrar requirements.
registry requirements.
DNSSEC [RFC2535,RFC3008,RFC3090] specifies that a child zone needs to
have its KEY RRset signed by its parent to create a verifiable chain
@@ -113,9 +114,9 @@ INTERNET-DRAFT Delegation Signer Record June 2002
Gudmundsson Expires December 2002 [Page 2]
INTERNET-DRAFT Delegation Signer Record June 2002
Gudmundsson Expires April 2003 [Page 2]
INTERNET-DRAFT Delegation Signer Record October 2002
Another complication of the DNSSEC key model is that the KEY record
@@ -170,9 +171,9 @@ INTERNET-DRAFT Delegation Signer Record June 2002
Gudmundsson Expires December 2002 [Page 3]
INTERNET-DRAFT Delegation Signer Record June 2002
Gudmundsson Expires April 2003 [Page 3]
INTERNET-DRAFT Delegation Signer Record October 2002
This is cryptographically equivalent to using just KEY records.
@@ -215,34 +216,38 @@ INTERNET-DRAFT Delegation Signer Record June 2002
RRset. If a query contains the OK bit, a server returning a referral
for the delegation MUST include the following RRsets in the authority
section in this order:
If DS RRset is present:
parent NS RRset
DS and SIG(DS) (if DS is present)
parent NXT and SIG(NXT) (If no DS)
DS and SIG(DS)
If no DS RRset is present:
parent NS RRset
parent NXT and SIG(NXT)
This increases the size of referral messages and may cause some or
all glue to be omitted. If the DS or NXT RRsets with signatures do
Gudmundsson Expires April 2003 [Page 4]
INTERNET-DRAFT Delegation Signer Record October 2002
not fit in the DNS message, the TC bit MUST be set. Additional
section processing is not changed.
Gudmundsson Expires December 2002 [Page 4]
INTERNET-DRAFT Delegation Signer Record June 2002
A DS RRset accompanying an NS RRset indicates that the child zone is
secure. If an NS RRset exists without a DS RRset, the child zone is
unsecure. DS RRsets MUST NOT appear at non-delegation points or at a
zone's apex.
unsecure (from the parents point of view). DS RRsets MUST NOT appear
at non-delegation points or at a zone's apex.
The following section 2.2.1 replaces RFC2535 sections 2.3.4 and 3.4,
section 2.2.2 replaces RFC3008 section 2.7, and RFC3090 updates are
in section 2.2.3.
Section 2.2.1 defines special considerations related to authoritative
servers responding to DS queries. Section 2.2.2 replaces RFC2535
sections 2.3.4 and 3.4, section 2.2.3 replaces RFC3008 section 2.7,
and section 2.2.4 updates RFC3090.
2.2.1 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points
2.2.2 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points
DNS security views each zone as a unit of data completely under the
control of the zone owner with each entry (RRset) signed by a special
@@ -255,13 +260,13 @@ INTERNET-DRAFT Delegation Signer Record June 2002
since one server could be serving both the zone above and below a
delegation point [RFC 2181].
Each DS RRset stored in the parent zone MUST be signed by one of the
parent zone's private key. The parent zone MUST NOT contain a KEY
RRset at any delegation point. Delegations in the parent MAY contain
only the following RR types: NS, DS, NXT and SIG. The NS RRset MUST
NOT be signed. The NXT RRset is the exceptional case: it will always
appear differently and authoritatively in both the parent and child
zones if both are secure.
Each DS RRset stored in the parent zone MUST be signed by, at least,
one of the parent zone's private key. The parent zone MUST NOT
contain a KEY RRset at any delegation point. Delegations in the
parent MAY contain only the following RR types: NS, DS, NXT and SIG.
The NS RRset MUST NOT be signed. The NXT RRset is the exceptional
case: it will always appear differently and authoritatively in both
the parent and child zones if both are secure.
A secure zone MUST contain a self-signed KEY RRset at its apex. Upon
verifying the DS RRset from the parent, a resolver MAY trust any KEY
@@ -275,20 +280,51 @@ INTERNET-DRAFT Delegation Signer Record June 2002
in the answer section.
2.2.2 Signer's Name (replaces RFC3008 section 2.7)
Gudmundsson Expires April 2003 [Page 5]
INTERNET-DRAFT Delegation Signer Record October 2002
2.2.2.1 Special processing for DS queries
When a server is authoritative for the parent zone at a delegation
point and receives a query for the DS record at that name, it will
return the DS from the parent zone. This is true whether or not it
is also authoritative for the child zone.
When the server is authoritative for the child zone at a delegation
point but not the parent zone, there is no natural response, since
the child zone is not authoritative for the DS record at the zone's
apex. As these queries are only expected to originate from recursive
servers which are not DS-aware, the authoritative server MUST answer
with:
RCODE: NOERROR
AA bit: set
Answer Section: Empty
Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
That is, it answers as if it is authoritative and the DS record does
not exist. DS-aware recursive servers will query the parent zone at
delegation points, so will not be affected by this.
A server authoritative for only the child zone at a delegation point
that is also a caching server MAY (if the RD bit is set in the query)
perform recursion to find the DS record at the delegation point, and
may return the DS record from its cache. In this case, the AA bit
MUST not be set in the response.
2.2.3 Signer's Name (replaces RFC3008 section 2.7)
The signer's name field of a SIG RR MUST contain the name of the zone
to which the data and signature belong. The combination of signer's
name, key tag, and algorithm MUST identify a zone key if the SIG is
to be considered material. This document defines a standard policy
Gudmundsson Expires December 2002 [Page 5]
INTERNET-DRAFT Delegation Signer Record June 2002
for DNSSEC validation; local policy may override the standard policy.
There are no restrictions on the signer field of a SIG(0) record.
@@ -302,6 +338,15 @@ INTERNET-DRAFT Delegation Signer Record June 2002
record.
Gudmundsson Expires April 2003 [Page 6]
INTERNET-DRAFT Delegation Signer Record October 2002
2.2.4.1 RFC3090: Updates to section 1: Introduction
Most of the text is still relevant but the words ``NULL key'' are to
@@ -338,26 +383,27 @@ INTERNET-DRAFT Delegation Signer Record June 2002
DNS delegation model, declaring it to be broken because there is no
good way to assert if a delegation exists. In the RFC2535 version of
DNSSEC, the presence of the NS bit in the NXT bit map proves there is
Gudmundsson Expires December 2002 [Page 6]
INTERNET-DRAFT Delegation Signer Record June 2002
a delegation at this name. Something more explicit is needed and the
DS record addresses this need for secure delegations.
The DS record is a major change to DNS: it is the first resource
record that can appear only on the upper side of a delegation. Adding
it will cause interoperability problems and requires a flag day for
it will cause interoperabilty problems and requires a flag day for
DNSSEC. Many old servers and resolvers MUST be upgraded to take
advantage of DS. Some old servers will be able to be authoritative
for zones with DS records but will not add the NXT or DS records to
the authority section. The same is true for caching servers; in
fact, some may even refuse to pass on the DS or NXT records.
Gudmundsson Expires April 2003 [Page 7]
INTERNET-DRAFT Delegation Signer Record October 2002
2.4 Wire Format of the DS record
The DS (type=TDB) record contains these fields: key tag, algorithm,
@@ -393,16 +439,8 @@ INTERNET-DRAFT Delegation Signer Record June 2002
KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key
Digest type value 0 is reserved, value 1 is SHA-1, and reserving
other types requires IETF standards action. For interoperability
other types requires IETF standards action. For interoperabilty
reasons, as few digest algorithms as possible should be reserved. The
Gudmundsson Expires December 2002 [Page 7]
INTERNET-DRAFT Delegation Signer Record June 2002
only reason to reserve additional digest types is to increase
security.
@@ -415,6 +453,14 @@ INTERNET-DRAFT Delegation Signer Record June 2002
The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless
of key size, new digest types probably will have larger digests.
Gudmundsson Expires April 2003 [Page 8]
INTERNET-DRAFT Delegation Signer Record October 2002
2.4.1 Justifications for Fields
The algorithm and key tag fields are present to allow resolvers to
@@ -452,14 +498,6 @@ INTERNET-DRAFT Delegation Signer Record June 2002
delegations are locally secure. This is bad, but the DNSEXT Working
Group has determined that rather than dealing with both
RFC2535-secured zones and DS-secured zones, a rapid adoption of DS is
Gudmundsson Expires December 2002 [Page 8]
INTERNET-DRAFT Delegation Signer Record June 2002
preferable. Thus the only option for early adopters is to upgrade to
DS as soon as possible.
@@ -473,6 +511,13 @@ INTERNET-DRAFT Delegation Signer Record June 2002
RFC2535 adds the following two cases:
Gudmundsson Expires April 2003 [Page 9]
INTERNET-DRAFT Delegation Signer Record October 2002
Secure RFC2535: NS + NXT + SIG(NXT)
NXT bit map contains: NS SIG NXT
Unsecure RFC2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT)
@@ -512,9 +557,22 @@ INTERNET-DRAFT Delegation Signer Record June 2002
Gudmundsson Expires December 2002 [Page 9]
INTERNET-DRAFT Delegation Signer Record June 2002
Gudmundsson Expires April 2003 [Page 10]
INTERNET-DRAFT Delegation Signer Record October 2002
3 Resolver
@@ -547,9 +605,12 @@ INTERNET-DRAFT Delegation Signer Record June 2002
secure.example. SOA <soa stuff>
secure.example. NS ns1.secure.example.
secure.example. KEY <tag=12345 alg=3>
secure.example. KEY <tag=54321 alg=5>
secure.example. NXT <nxt stuff>
secure.example. SIG(KEY) <key-tag=12345 alg=3>
secure.example. SIG(SOA) <key-tag=12345 alg=3>
secure.example. SIG(NS) <key-tag=12345 alg=5>
secure.example. SIG(SOA) <key-tag=54321 alg=5>
secure.example. SIG(NS) <key-tag=54321 alg=5>
secure.example. SIG(NXT) <key-tag=54321 alg=5>
In this example the private key for "example." signs the DS record
for "secure.example.", making that a secure delegation. The DS record
@@ -559,20 +620,22 @@ INTERNET-DRAFT Delegation Signer Record June 2002
and trusted.
This example has only one DS record for the child, but parents MUST
allow multiple DS records to facilitate key rollover. It is strongly
recommended that the DS RRset be kept small: two or three DS records
SHOULD be sufficient in all cases.
allow multiple DS records to facilitate key rollover and multiple KEY
algorithms.
Gudmundsson Expires April 2003 [Page 11]
INTERNET-DRAFT Delegation Signer Record October 2002
The resolver determines the security status of "unsecure.example." by
examining the parent zone's NXT record for this name. The absence of
the DS bit indicates an unsecure delegation.
Gudmundsson Expires December 2002 [Page 10]
INTERNET-DRAFT Delegation Signer Record June 2002
the DS bit indicates an unsecure delegation. Note the NXT record
SHOULD only be examined after verifying the corresponding signature.
3.1 Resolver Cost Estimates for DS Records
@@ -618,19 +681,18 @@ INTERNET-DRAFT Delegation Signer Record June 2002
The DS record represents a change to the DNSSEC protocol and there is
an installed base of implementations, as well as textbooks on how to
Gudmundsson Expires April 2003 [Page 12]
INTERNET-DRAFT Delegation Signer Record October 2002
set up secure delegations. Implementations that do not understand the
DS record will not be able to follow the KEY to DS to KEY chain and
will consider all zones secured that way as unsecure.
Gudmundsson Expires December 2002 [Page 11]
INTERNET-DRAFT Delegation Signer Record June 2002
5 IANA Considerations:
IANA needs to allocate an RR type code for DS from the standard RR
@@ -675,19 +737,19 @@ Normative References:
[RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC
3225, December 2001.
Gudmundsson Expires April 2003 [Page 13]
INTERNET-DRAFT Delegation Signer Record October 2002
[RFC3226] O. Gudmundsson, ``DNSSEC and IPv6 A6 aware server/resolver
message size requirements'', RFC 3226, December 2001.
Gudmundsson Expires December 2002 [Page 12]
INTERNET-DRAFT Delegation Signer Record June 2002
Author Address
Olafur Gudmundsson
@@ -736,8 +798,5 @@ Full Copyright Statement
Gudmundsson Expires April 2003 [Page 14]
Gudmundsson Expires December 2002 [Page 13]

206
doc/draft/draft-ietf-dnsext-dnssec-intro-02.txt → doc/draft/draft-ietf-dnsext-dnssec-intro-03.txt
View File

@@ -1,18 +1,18 @@
Network Working Group R. Arends
Internet-Draft Nominum
Expires: January 21, 2003 M. Larson
DNS Extensions R. Arends
Internet-Draft
Expires: April 24, 2003 M. Larson
VeriSign
D. Massey
USC/ISI
S. Rose
NIST
July 23, 2002
October 24, 2002
DNS Security Introduction and Requirements
draft-ietf-dnsext-dnssec-intro-02
draft-ietf-dnsext-dnssec-intro-03
Status of this Memo
@@ -35,7 +35,7 @@ Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 21, 2003.
This Internet-Draft will expire on April 24, 2003.
Copyright Notice
@@ -52,9 +52,9 @@ Abstract
Arends, et al. Expires January 21, 2003 [Page 1]
Arends, et al. Expires April 24, 2003 [Page 1]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Internet-Draft DNSSEC Intro. and Requirements October 2002
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ -108,9 +108,9 @@ Table of Contents
Arends, et al. Expires January 21, 2003 [Page 2]
Arends, et al. Expires April 24, 2003 [Page 2]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Internet-Draft DNSSEC Intro. and Requirements October 2002
1. Introduction
@@ -164,34 +164,34 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002
Arends, et al. Expires January 21, 2003 [Page 3]
Arends, et al. Expires April 24, 2003 [Page 3]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Internet-Draft DNSSEC Intro. and Requirements October 2002
2. Definitions of Important DNSSEC Terms
trusted key: A public key, for a zone or a host, that a resolver
trusts and that can therefore be used to verify data. A key can
become trusted in two ways. First, it can be statically
configured and declared as trusted in the resolver's
configuration. Second, if a new key is referenced by a DS record
that is signed by an already trusted key, and the signature
verifies, the new key becomes trusted.
authentication key: A public key, for a zone or a host, that a
resolver trusts and that can therefore be used to verify data. A
key can become trusted in two ways: First, it can be statically
configured and declared in the resolver's initial configuration.
Second, if a new key is referenced by a DS record that is signed
by an already known authentication key, and the signature
verifies, the new key becomes trusted by the resolver.
chain of trust: In DNSSEC, a key signs a DS record, which points to
another key, which in turn signs another DS record, which points
to yet another key, etc. This alternating succession of KEY and
DS records forms a chain of signed data, with each link in the
chain vouching for the next. A resolver starting at a piece of
data in the chain signed by a trusted key can verify all
subsequent signatures. Thus all subsequent data in the chain is
trusted.
authentication path: In DNSSEC, a key signs a DS record, which points
to another key, which in turn signs another DS record, which
points to yet another key, etc. This alternating succession of
KEY and DS records forms a chain of signed data, with each link in
the chain vouching for the next. A resolver starting at a piece
of data in the chain signed by a known authentication key can
verify all subsequent signatures. Thus all subsequent data in the
chain is verified and authenticated.
security-aware resolver: A resolver (defined in section 2.4 of [4])
that understands the DNS security extensions. In particular, a
security-aware resolver uses trusted keys to verify signatures
over RRsets and (optionally) DNS messages.
security-aware resolver uses known authentication keys to verify
signatures over RRsets and (optionally) DNS messages.
security-aware server: A name server (also defined in section 2.4 of
[4]) that understands the DNS security extensions. In particular,
@@ -204,7 +204,7 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002
unsigned zone: The proper term for the opposite of a secure zone.
secure zone: A zone whose RRsets are signed and which contains
signed zone: A zone whose RRsets are signed and which contains
properly constructed KEY, SIG, NXT and (optionally) DS records.
@@ -220,9 +220,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002
Arends, et al. Expires January 21, 2003 [Page 4]
Arends, et al. Expires April 24, 2003 [Page 4]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Internet-Draft DNSSEC Intro. and Requirements October 2002
3. Services Provided by DNS Security
@@ -258,34 +258,36 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002
record (see Section 3.2 below). (Note that the private keys used to
sign zone data must be kept secure and best practices call for them
to be stored offline.) To reliably discover a public key by DNS
resolution, the key itself needs to be signed by another key that the
resolver trusts. Zone information is authenticated by forming a
chain of trust from a newly learned public key back to a trusted
public key (which is either statically configured or previously
learned and verified). Therefore, the resolver must be configured
with at least one public key that authenticates one zone as a
starting point. To establish this chain of trust, security-aware
servers attempt to send the signature(s) needed to authenticate a
zone's public key in the DNS reply message along with the public key
itself, provided there is space available in the message.
resolution, the key itself needs to be signed by either a statically
configured authentication key or another key that has been previously
authenticated. Zone information is authenticated by forming a chain
from a newly learned public key back to a previously known
authentication public key (which is either statically configured or
previously learned and verified). Therefore, the resolver must be
configured with at least one public key that authenticates one zone
as a starting point. To establish this authentication chain,
security-aware servers attempt to send the signature(s) needed to
authenticate a zone's public key in the DNS reply message along with
the public key itself, provided there is space available in the
message.
The chain of trust specified in the original DNS security extensions
proceeded from signed KEY record to signed KEY record, as necessary,
and finally to the queried RRset. A new record, the delegation
signer (DS), has been added for additional flexibility. The DS RRset
The authentication chain specified in the original DNS security
extensions proceeded from signed KEY record to signed KEY record, as
Arends, et al. Expires January 21, 2003 [Page 5]
Arends, et al. Expires April 24, 2003 [Page 5]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Internet-Draft DNSSEC Intro. and Requirements October 2002
resides at a delegation point in a parent zone and specifies the keys
used by the specified child zone to self-sign the KEY RRset at its
apex. The child, in turn, uses one of these keys to sign its zone
data. The chain of trust is therefore DS->KEY->[DS->KEY->...]-
>RRset.
necessary, and finally to the queried RRset. A new record, the
delegation signer (DS), has been added for additional flexibility.
The DS RRset resides at a delegation point in a parent zone and
specifies the keys used by the specified child zone to self-sign the
KEY RRset at its apex. The child, in turn, uses one of these keys to
sign its zone data. The authentication chain is therefore DS->KEY-
>[DS->KEY->...]->RRset.
Adding data origin authentication and data integrity requires minor
changes to the on-the-wire DNS protocol. Several new resource record
@@ -313,8 +315,8 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002
The KEY resource record is defined to associate public keys with DNS
names. This record permits the DNS to be used as a public key
distribution mechanism in support of DNSSEC. Security-aware
resolvers can query for a zone's public key when establishing a chain
of trust.
resolvers can query for a zone's public key when establishing a
authentication chain.
The syntax of the KEY resource record (and the other additional
resource records required for DNSSEC) is described in [9]. It
@@ -327,17 +329,19 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002
now restricted for use with DNSSEC only. Work is in progress on
storing public keys [14] and certificates [15] used by other
protocols and applications in the DNS. A secure DNS tree could then
be used as a lightweight trust mechanism. Some administrators and
users may consider a validated DNSSEC signature to be sufficient to
Arends, et al. Expires January 21, 2003 [Page 6]
Arends, et al. Expires April 24, 2003 [Page 6]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Internet-Draft DNSSEC Intro. and Requirements October 2002
trust a public key stored in the DNS.
be used as a lightweight key distribution mechanism that could
support other protocols. However, this should not lead to the
conclusion that the DNS is then safe to use as a trusted protocol or
a Public Key Infrastructure. DNSSEC lacks many features found in a
PKI such as a Certificate Revocation List (CRL).
3.3 Transaction Security
@@ -384,13 +388,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002
Arends, et al. Expires January 21, 2003 [Page 7]
Arends, et al. Expires April 24, 2003 [Page 7]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Internet-Draft DNSSEC Intro. and Requirements October 2002
4. Services Not Provided by DNS Security
@@ -444,9 +444,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002
Arends, et al. Expires January 21, 2003 [Page 8]
Arends, et al. Expires April 24, 2003 [Page 8]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Internet-Draft DNSSEC Intro. and Requirements October 2002
5. Resolver Considerations
@@ -454,11 +454,12 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002
A security-aware resolver needs to be able to perform necessary
cryptographic functions to verify digital signatures using at least
the mandatory-to-implement algorithms. Also, security-aware
resolvers must be capable of forming a chain of trust from a newly
learned zone back to a trusted key. This might require additional
queries to intermediate DNS zones for necessary KEY, DS and SIG
records. It is assumed that a security-aware resolver will be
configured with at least one trusted key to aid this process.
resolvers must be capable of forming a authentication chain from a
newly learned zone back to a trusted authentication key. This might
require additional queries to intermediate DNS zones for necessary
KEY, DS and SIG records. It is assumed that a security-aware
resolver will be configured with at least one authentication key to
aid this process.
The stub resolver found in many hosts may be augmented to provide a
different set of security features instead of the full security
@@ -472,7 +473,7 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002
part of the DNS resolution path, the resolver cannot ensure security.
If a security-aware resolver must rely on an unsecure server (or
unsigned zone), the resolver cannot verify DNS responses and should
rely on local policy when trusting responses.
rely on local policy when following responses.
@@ -499,10 +500,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002
Arends, et al. Expires January 21, 2003 [Page 9]
Arends, et al. Expires April 24, 2003 [Page 9]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Internet-Draft DNSSEC Intro. and Requirements October 2002
6. Zone Considerations
@@ -556,9 +556,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002
Arends, et al. Expires January 21, 2003 [Page 10]
Arends, et al. Expires April 24, 2003 [Page 10]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Internet-Draft DNSSEC Intro. and Requirements October 2002
7. Server Considerations
@@ -612,9 +612,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002
Arends, et al. Expires January 21, 2003 [Page 11]
Arends, et al. Expires April 24, 2003 [Page 11]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Internet-Draft DNSSEC Intro. and Requirements October 2002
8. DNS Security Document Family
@@ -638,7 +638,7 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002
|
+-----------+ +-------------+
| DNSSEC | | New |
| Protocol |<-------->| Security |
| Protocol |--------->| Security |
| Documents | | Uses |
+-----------+ +-------------+
|
@@ -668,9 +668,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002
Arends, et al. Expires January 21, 2003 [Page 12]
Arends, et al. Expires April 24, 2003 [Page 12]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Internet-Draft DNSSEC Intro. and Requirements October 2002
2. Resource Records for DNS Security Extensions [9]
@@ -724,9 +724,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002
Arends, et al. Expires January 21, 2003 [Page 13]
Arends, et al. Expires April 24, 2003 [Page 13]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Internet-Draft DNSSEC Intro. and Requirements October 2002
9. IANA Considerations
@@ -780,9 +780,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002
Arends, et al. Expires January 21, 2003 [Page 14]
Arends, et al. Expires April 24, 2003 [Page 14]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Internet-Draft DNSSEC Intro. and Requirements October 2002
10. Security Considerations
@@ -836,9 +836,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002
Arends, et al. Expires January 21, 2003 [Page 15]
Arends, et al. Expires April 24, 2003 [Page 15]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Internet-Draft DNSSEC Intro. and Requirements October 2002
11. Acknowledgements
@@ -892,9 +892,9 @@ Internet-Draft DNSSEC Intro. and Requirements July 2002
Arends, et al. Expires January 21, 2003 [Page 16]
Arends, et al. Expires April 24, 2003 [Page 16]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Internet-Draft DNSSEC Intro. and Requirements October 2002
Normative References
@@ -948,9 +948,9 @@ Normative References
Arends, et al. Expires January 21, 2003 [Page 17]
Arends, et al. Expires April 24, 2003 [Page 17]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Internet-Draft DNSSEC Intro. and Requirements October 2002
Informative References
@@ -968,12 +968,11 @@ Informative References
Authors' Addresses
Roy Arends
Nominum, Inc.
2385 Bay Street
Redwood City, CA 94063
USA
Bankastraat 41-E
1094 EB Amsterdam
NL
EMail: roy.arends@nominum.com
EMail: roy@logmess.com
Matt Larson
@@ -997,16 +996,17 @@ Authors' Addresses
Scott Rose
National Institute for Standards and Technology
100 Bureau Drive
Gaithersburg, MD 20899-3460
Gaithersburg, MD 20899-8920
USA
EMail: scott.rose@nist.gov
Arends, et al. Expires January 21, 2003 [Page 18]
Arends, et al. Expires April 24, 2003 [Page 18]
Internet-Draft DNSSEC Intro. and Requirements July 2002
Internet-Draft DNSSEC Intro. and Requirements October 2002
Full Copyright Statement
@@ -1060,5 +1060,5 @@ Acknowledgement
Arends, et al. Expires January 21, 2003 [Page 19]
Arends, et al. Expires April 24, 2003 [Page 19]

529
doc/draft/draft-ietf-dnsext-dnssec-opt-in-02.txt → doc/draft/draft-ietf-dnsext-dnssec-opt-in-03.txt
View File

@@ -1,13 +1,15 @@
Network Working Group R. Arends
Internet-Draft Nominum, Inc.
Expires: December 26, 2002 M. Kosters
Internet-Draft
Expires: April 14, 2003 M. Kosters
D. Blacka
Verisign, Inc.
June 27, 2002
October 14, 2002
DNSSEC Opt-In
draft-ietf-dnsext-dnssec-opt-in-02
draft-ietf-dnsext-dnssec-opt-in-03
Status of this Memo
@@ -30,7 +32,7 @@ Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 26, 2002.
This Internet-Draft will expire on April 14, 2003.
Copyright Notice
@@ -42,7 +44,7 @@ Abstract
secured. Maintaining this cryptography is not practical or
necessary. This document describes an "Opt-In" model that allows
administrators to omit this cryptography and manage the cost of
adopting DNSSEC.
adopting DNSSEC with large zones.
@@ -50,28 +52,36 @@ Abstract
Arends, et al. Expires December 26, 2002 [Page 1]
Arends, et al. Expires April 14, 2003 [Page 1]
Internet-Draft DNSSEC Opt-In June 2002
Internet-Draft DNSSEC Opt-In October 2002
Table of Contents
1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Server Considerations . . . . . . . . . . . . . . . . . . . . 5
3.2 Client Considerations . . . . . . . . . . . . . . . . . . . . 6
4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 16
B. Changes from Prior Versions . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19
1. Definitions and Terminology . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Additions . . . . . . . . . . . . . . . . . . . . . 5
3.1 Server Considerations . . . . . . . . . . . . . . . . . . . 6
3.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2 Insecure Delegation Responses . . . . . . . . . . . . . . . 6
3.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . . . . 6
3.2 Client Considerations . . . . . . . . . . . . . . . . . . . 7
3.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2 Validation Process Changes . . . . . . . . . . . . . . . . . 7
3.2.3 NXT Record Caching . . . . . . . . . . . . . . . . . . . . . 8
3.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . . . . 8
4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Transition Issues . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15
References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
A. Implementing Opt-In using "Views" . . . . . . . . . . . . . 18
B. Changes from Prior Versions . . . . . . . . . . . . . . . . 20
Full Copyright Statement . . . . . . . . . . . . . . . . . . 21
@@ -98,17 +108,9 @@ Table of Contents
Arends, et al. Expires December 26, 2002 [Page 2]
Arends, et al. Expires April 14, 2003 [Page 2]
Internet-Draft DNSSEC Opt-In June 2002
Internet-Draft DNSSEC Opt-In October 2002
1. Definitions and Terminology
@@ -121,16 +123,19 @@ Internet-Draft DNSSEC Opt-In June 2002
RR: is used to refer to a DNS resource record.
RRset: refers to a Resource Record Set, as defined by [3].
RRset: refers to a Resource Record Set, as defined by [3]. In this
document, the RRset is also defined to include the covering SIG
records, if any exist.
covering NXT record/RRset: is the NXT record used to prove
(non)existance of a particular name or RRset. This means that for
(non)existence of a particular name or RRset. This means that for
a RRset or name 'N', the covering NXT record has the name 'N', or
has an owner name less than 'N' and "next" name greater than 'N'.
delegation: refers to a NS RRset with a name different from the
current zone apex (non-zone-apex), signifying a delegation to a
subzone.
subzone. A delegation returned in a DNS response is also called a
"referral".
secure delegation: refers to the NS, DS, NXT and SIG RRsets for a
non-zone-apex owner name, signifying a delegation to a DNSSEC
@@ -159,12 +164,9 @@ Internet-Draft DNSSEC Opt-In June 2002
Arends, et al. Expires December 26, 2002 [Page 3]
Arends, et al. Expires April 14, 2003 [Page 3]
Internet-Draft DNSSEC Opt-In June 2002
Internet-Draft DNSSEC Opt-In October 2002
2. Overview
@@ -218,9 +220,9 @@ Internet-Draft DNSSEC Opt-In June 2002
Arends, et al. Expires December 26, 2002 [Page 4]
Arends, et al. Expires April 14, 2003 [Page 4]
Internet-Draft DNSSEC Opt-In June 2002
Internet-Draft DNSSEC Opt-In October 2002
3. Protocol Additions
@@ -228,12 +230,12 @@ Internet-Draft DNSSEC Opt-In June 2002
In RFC 2535, delegation NS RRsets are not signed, but instead are
accompanied by a NXT RRset of the same name, and possibly a ("no-
key") KEY RR [4] or DS record [7]. The security status of the
subzone is determined by the presence or absence of the KEY or DS
records, cryptographically proven by the NXT record. Opt-In expands
this definition by allowing insecure delegations to exist within an
subzone is determined by the presence of the KEY or DS records,
cryptographically proven by the NXT record. Opt-In expands this
definition by allowing insecure delegations to exist within an
otherwise signed zone without the corresponding NXT record at the
delegation's owner name. These insecure delegations are proven
insecure by using the covering NXT record.
insecure by using a covering NXT record.
Since this represents a change of the interpretation of NXT records,
resolvers must be able to distinguish between RFC 2535 NXT records
@@ -264,79 +266,174 @@ Internet-Draft DNSSEC Opt-In June 2002
o A RFC2535 NXT type is identified by a one-valued NXT bit in the
type bit map of the NXT record.
and,
o An Opt-In NXT record does not assert the non-existence of a name
between its owner name and "next" name, although it does assert
that any name in this span MUST be an insecure delegation.
o An Opt-In NXT record does assert the (non)existence of RRsets with
Arends, et al. Expires April 14, 2003 [Page 5]
Internet-Draft DNSSEC Opt-In October 2002
the same owner name.
3.1 Server Considerations
This protocol change dictates a number of changes to the operation of
an authoritative server:
Opt-In imposes some new requirements on authoritative DNS servers.
o The server MUST enforce the protocol requirement that ONLY
3.1.1 Delegations Only
This specification dictates that only insecure delegations may exist
between the owner and "next" names of an Opt-In tagged NXT record.
Servers and signing tools MUST enforce this restriction.
3.1.2 Insecure Delegation Responses
When returning an Opt-In insecure delegation, the server MUST return
the covering NXT RRset in the Authority section.
This presents a change from RFC 2535, where the "no-key" KEY RRset
would be returned instead. However, in the delegation signer
proposal, NXT records already must be returned along with the
insecure delegation. The primary difference that this proposal
introduces is that the Opt-In tagged NXT record will have a different
owner name from the delegation RRset. This may require
implementations to do a NXT search on cached responses.
3.1.3 Wildcards and Opt-In
RFC 2535, in section 5.3, describes the practice of returning NXT
records to prove the non-existence of an applicable wildcard in non-
existent name responses. This NXT record can be described as a
"negative wildcard proof". The use of Opt-In NXT records changes the
necessity for this practice. For both non-existent name (NXDOMAIN)
responses and Opt-In insecure delegation responses, servers MUST NOT
return negative wildcard proof records when the query name (qname) is
covered by an Opt-In tagged NXT record.
The intent of the RFC 2535 negative wildcard proof requirement is to
prevent malicious users from undetectably removing valid wildcard
responses. In order for this cryptographic proof to work, the
resolver must be able to prove:
1. The exact qname does not exist. This is done by the "normal" NXT
record.
2. No applicable wildcard exists. This is done by returning one or
more NXT records proving that the wildcards do not exist
(negative wildcard proofs).
Arends, et al. Expires December 26, 2002 [Page 5]
Arends, et al. Expires April 14, 2003 [Page 6]
Internet-Draft DNSSEC Opt-In June 2002
Internet-Draft DNSSEC Opt-In October 2002
insecure delegation nodes may exist between the secure nodes of
the zone.
However, if the NXT record covering the exact qname is an Opt-In NXT
record, the resolver will not be able to prove the first part of this
equation, as the qname might exist as an insecure delegation. Thus,
since the total proof cannot be completed, the negative wildcard
proof records are not useful.
o The server must be able to retrieve the proper NXT records along
with referrals to insecure subzone.
The negative wildcard proofs are also not useful when returned as
part of an Opt-In insecure delegation response for a similar reason:
the resolver cannot prove that the qname does or does not exist, and
therefore cannot prove that a wildcard expansion is valid.
In the delegation signer proposal, NXT records already must be
returned along with referrals to insecure delegations. The primary
difference that this proposal introduces is that the appropriate NXT
record will have a different owner name.
The presence of an Opt-In tagged NXT record does not change the
practice of returning a NXT along with a wildcard expansion. Even
though the Opt-In NXT will not be able to prove that the wildcard
expansion is valid, it will prove that the wildcard expansion is not
masking any signed records.
3.2 Client Considerations
Opt-In imposes some new requirements on the DNS resolver (caching or
otherwise):
Opt-In imposes some new requirements on DNS resolvers (caching or
otherwise).
o Resolvers MUST be able to use Opt-In style NXT records to
cryptographically prove the validity and security status (as
insecure) of a referral:
3.2.1 Delegations Only
* In RFC 2535, this is proven by existence of a verified "no-key"
KEY RRset.
As stated in the "Server Considerations" section above, this
specification restricts the namespace covered by Opt-In tagged NXT
records to insecure delegations only. Thus, resolvers MUST reject as
invalid any records that fall within an Opt-In NXT record's span that
are not NS records or corresponding glue records.
* Using Delegation Signer, this is proven by the existence of a
verified NXT record. This NXT record has same name as the
delegation RRset and does not have the DS bit set in the type
map.
3.2.2 Validation Process Changes
* Using Opt-In, this is proven by the existence of a verified
Opt-In NXT record. This NXT record does not have the NXT bit
set in the type map (that is, it is an Opt-In style NXT record)
and the name of the delegation RRset is lexicographically
between the owner and next names of the NXT record.
This specification does not change the resolver's resolution
algorithm. However, it does change the DNSSEC validation process.
Resolvers MUST be able to use Opt-In tagged NXT records to
cryptographically prove the validity and security status (as
insecure) of a referral. Resolvers determine the security status of
the referred-to zone as follows:
Note that using Opt-In does not substantially change the nature of
following referrals within DNSSEC. At every delegation point, the
resolver will have cryptographic proof that the subzone is secure
or insecure.
o In RFC 2535, the security status is proven by existence of a
verified "no-key" KEY RRset. The absence of the "no-key" KEY
RRset indicates that the referred-to zone is secure.
o Resolvers MUST reject as invalid non-NS RRsets that fall within an
Opt-In tagged NXT record's span.
o Caching resolvers must be able to retrieve the appropriate
covering Opt-In NXT record when returning referrals that need
them. This is only a difference when you consider that the
covering NXT record will not have the same name as the delegation
RRset itself.
o Using Delegation Signer, the security status is proven by the
existence or absence of a DS record at the same name as the
delegation. The absence is proven using a verified NXT record of
the same name that does not have the DS bit set in the type map.
This NXT record MAY also be tagged as Opt-In.
Arends, et al. Expires December 26, 2002 [Page 6]
Arends, et al. Expires April 14, 2003 [Page 7]
Internet-Draft DNSSEC Opt-In June 2002
Internet-Draft DNSSEC Opt-In October 2002
o The AD bit (as defined by [8]) MUST NOT be set in a response
containing an Opt-In tagged NXT record in the authority section.
o Using Opt-In, the security status is proven by the existence of a
DS record (for secure) or the presence of a verified Opt-In tagged
NXT record that covers the delegation name. That is, the NXT
record does not have the NXT bit set in the type map, and the
delegation name falls between the NXT's owner and "next" name.
Using Opt-In does not substantially change the nature of following
referrals within DNSSEC. At every delegation point, the resolver
will have cryptographic proof that the subzone is secure or insecure.
When receiving either an Opt-In insecure delegation response or a
non-existent name response where that name is covered by an Opt-In
tagged NXT record, the resolver MUST NOT require proof (in the form
of a NXT record) that a wildcard did not exist.
3.2.3 NXT Record Caching
Caching resolvers MUST be able to retrieve the appropriate covering
Opt-In NXT record when returning referrals that need them. This
requirement differs from Delegation Signer in that the covering NXT
will not have the same owner name as the delegation. Some
implementations may have to use new methods for finding these NXT
records.
3.2.4 Use of the AD bit
The AD bit, as defined by [8], MUST NOT be set when:
o sending a non-existent name (NXDOMAIN) response where the covering
NXT is tagged as Opt-In, unless the NXT record's owner name equals
the qname.
o sending an Opt-In insecure delegation response, unless the
covering (Opt-In) NXT record's owner name equals the delegation
name.
This rule is based on what the Opt-In NXT record actually proves.
For names that exist between the Opt-In NXT record's owner and "next"
names, the Opt-In NXT record cannot prove the non-existence or
existence of the name. As such, not all data in the response has
been cryptographically verified, so the AD bit cannot be set.
@@ -347,48 +444,9 @@ Internet-Draft DNSSEC Opt-In June 2002
Arends, et al. Expires December 26, 2002 [Page 7]
Arends, et al. Expires April 14, 2003 [Page 8]
Internet-Draft DNSSEC Opt-In June 2002
Internet-Draft DNSSEC Opt-In October 2002
4. Benefits
@@ -442,9 +500,9 @@ Internet-Draft DNSSEC Opt-In June 2002
Arends, et al. Expires December 26, 2002 [Page 8]
Arends, et al. Expires April 14, 2003 [Page 9]
Internet-Draft DNSSEC Opt-In June 2002
Internet-Draft DNSSEC Opt-In October 2002
5. Example
@@ -483,10 +541,12 @@ Internet-Draft DNSSEC Opt-In June 2002
In this example, a query for a signed RRset (e.g., "FIRST-
SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND-
SECURE.EXAMPLE A") will result in a standard RFC 2535 response. A
query for a nonexistent RRset will result in a response that differs
from RFC 2535 only in the fact that the NXT record will be tagged as
Opt-In.
SECURE.EXAMPLE A") will result in a standard RFC 2535 response.
A query for a nonexistent RRset will result in a response that
differs from RFC 2535 by: the NXT record will be tagged as Opt-In,
there will be no NXT record proving the non-existence of a matching
wildcard record, and the AD bit will not be set.
A query for an insecure delegation RRset (or a referral) will return
both the answer (in the Authority section) and the corresponding Opt-
@@ -496,17 +556,15 @@ Internet-Draft DNSSEC Opt-In June 2002
Arends, et al. Expires December 26, 2002 [Page 9]
Arends, et al. Expires April 14, 2003 [Page 10]
Internet-Draft DNSSEC Opt-In June 2002
Internet-Draft DNSSEC Opt-In October 2002
Example A.1: Response to query for WWW.UNSECURE.EXAMPLE. A
Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A
RCODE=NOERROR
RCODE=NOERROR, AD=0
Answer Section:
@@ -554,19 +612,79 @@ Internet-Draft DNSSEC Opt-In June 2002
Arends, et al. Expires December 26, 2002 [Page 10]
Arends, et al. Expires April 14, 2003 [Page 11]
Internet-Draft DNSSEC Opt-In June 2002
Internet-Draft DNSSEC Opt-In October 2002
6. Security Considerations
6. Transition Issues
Opt-In allows for unsigned delegations. All unsigned names are
insecure, and their validity (or existence) can not be
Opt-In is not backwards compatible with RFC 2535. RFC 2535 compliant
DNSSEC implementations will not recognize Opt-In tagged NXT records
as different from RFC 2535 NXT records. Because of this, RFC 2535
implementations will reject all Opt-In insecure delegations within a
zone as invalid.
Arends, et al. Expires April 14, 2003 [Page 12]
Internet-Draft DNSSEC Opt-In October 2002
7. Security Considerations
Opt-In allows for unsigned names. All unsigned names are, by
definition, insecure, and their validity (or existence) can not be
cryptographically proven. With Opt-In, a malicious entity is able
to: insert, modify, or delete insecure delegation RRsets within a
secured zone. For example, if a resolver received the following
response from the example zone above:
to: insert, modify, or delete insecure delegation RRsets within the
Opt-In spans of a otherwise secured zone. In addition, a malicious
entity is able to replay or delete wildcard expansions (if there is
an existing applicable wildcard) in the Opt-In spans of the zone.
For example, if a resolver received the following response from the
example zone above:
Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A
@@ -606,16 +724,12 @@ Internet-Draft DNSSEC Opt-In June 2002
Arends, et al. Expires December 26, 2002 [Page 11]
Arends, et al. Expires April 14, 2003 [Page 13]
Internet-Draft DNSSEC Opt-In June 2002
Internet-Draft DNSSEC Opt-In October 2002
7. IANA Considerations
8. IANA Considerations
None.
@@ -666,12 +780,12 @@ Internet-Draft DNSSEC Opt-In June 2002
Arends, et al. Expires December 26, 2002 [Page 12]
Arends, et al. Expires April 14, 2003 [Page 14]
Internet-Draft DNSSEC Opt-In June 2002
Internet-Draft DNSSEC Opt-In October 2002
8. Acknowledgments
9. Acknowledgments
The contributions, suggestions and remarks of the following persons
(in alphabetic order) to this draft are acknowledged:
@@ -722,9 +836,9 @@ Internet-Draft DNSSEC Opt-In June 2002
Arends, et al. Expires December 26, 2002 [Page 13]
Arends, et al. Expires April 14, 2003 [Page 15]
Internet-Draft DNSSEC Opt-In June 2002
Internet-Draft DNSSEC Opt-In October 2002
References
@@ -748,39 +862,22 @@ References
December 2001.
[7] Gudmundsson, O., "Delegation Signer Resource Record", draft-
ietf-dnsext-delegation-signer-07 (work in progress), March 2002.
ietf-dnsext-delegation-signer-09 (work in progress), September
2002.
[8] Gudmundsson, O. and B. Wellington, "Redefinition of DNS AD bit",
draft-ietf-dnsext-ad-is-secure-05 (work in progress), March
2002.
draft-ietf-dnsext-ad-is-secure-06 (work in progress), June 2002.
Authors' Addresses
Roy Arends
Nominum, Inc.
950 Charter Street
Redwood City, CA 94063
US
Bankastraat 41-E
1094 EB Amsterdam
NL
Phone: +1 650 381 6000
EMail: Roy.Arends@nominum.com
URI: http://www.nominum.com
Arends, et al. Expires December 26, 2002 [Page 14]
Internet-Draft DNSSEC Opt-In June 2002
Phone: +31206931681
EMail: roy@logmess.com
Mark Kosters
@@ -794,6 +891,12 @@ Internet-Draft DNSSEC Opt-In June 2002
URI: http://www.verisignlabs.com
Arends, et al. Expires April 14, 2003 [Page 16]
Internet-Draft DNSSEC Opt-In October 2002
David Blacka
Verisign, Inc.
21355 Ridgetop Circle
@@ -834,9 +937,20 @@ Internet-Draft DNSSEC Opt-In June 2002
Arends, et al. Expires December 26, 2002 [Page 15]
Arends, et al. Expires April 14, 2003 [Page 17]
Internet-Draft DNSSEC Opt-In June 2002
Internet-Draft DNSSEC Opt-In October 2002
Appendix A. Implementing Opt-In using "Views"
@@ -890,9 +1004,9 @@ Appendix A. Implementing Opt-In using "Views"
Arends, et al. Expires December 26, 2002 [Page 16]
Arends, et al. Expires April 14, 2003 [Page 18]
Internet-Draft DNSSEC Opt-In June 2002
Internet-Draft DNSSEC Opt-In October 2002
For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
@@ -946,13 +1060,20 @@ Internet-Draft DNSSEC Opt-In June 2002
Arends, et al. Expires December 26, 2002 [Page 17]
Arends, et al. Expires April 14, 2003 [Page 19]
Internet-Draft DNSSEC Opt-In June 2002
Internet-Draft DNSSEC Opt-In October 2002
Appendix B. Changes from Prior Versions
Changes from version 02:
Added text on changes to validation process, use of the AD bit,
and interactions with wildcards. Added wildcard caveats to the
"Security Considerations" section. Added "Transition Issues"
section.
Changes from version 01:
Changed to "delegation only". Strengthened "Security
@@ -995,16 +1116,9 @@ Appendix B. Changes from Prior Versions
Arends, et al. Expires December 26, 2002 [Page 18]
Arends, et al. Expires April 14, 2003 [Page 20]
Internet-Draft DNSSEC Opt-In June 2002
Internet-Draft DNSSEC Opt-In October 2002
Full Copyright Statement
@@ -1058,4 +1172,5 @@ Acknowledgement
Arends, et al. Expires December 26, 2002 [Page 19]
Arends, et al. Expires April 14, 2003 [Page 21]

336
doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-00.txt
View File

@@ -1,336 +0,0 @@
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]
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]
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]
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]
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]
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]

392
doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-01.txt Normal file
View File

@@ -0,0 +1,392 @@
DNS Extensions O. Kolkman
Internet-Draft RIPE NCC
Expires: March 2, 2003 J. Schlyter
Carlstedt Research &
Technology
September 2002
KEY RR Key Signing (KS) Flag
draft-ietf-dnsext-keyrr-key-signing-flag-01
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 2, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
With the DS record [1] the concept of key signing and zone signing
keys has been introduced. Key signing keys are the keys that sign
the keyset only. In general, key signing keys are the keys that are
pointed to by DS records and are the first keys to be used when
following a chain of trust into the 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.
Kolkman & Schlyter Expires March 2, 2003 [Page 1]
Internet-Draft KEY RR Key Signing (KS) Flag September 2002
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.
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. Document Changes . . . . . . . . . . . . . . . . . . . . . . . 4
6.1 draft version 00 -> 01 . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7
Kolkman & Schlyter Expires March 2, 2003 [Page 2]
Internet-Draft KEY RR Key Signing (KS) Flag September 2002
1. Introduction
"All keys are equal but some keys are more equal than others" [2]
With the DS record [1] the concept of key signing and zone signing
keys has been introduced. In general these are the keys that are
pointed to by DS records and are the first keys to be used when
following the chain of trust into a zone ( secure entry points of the
zone). These key signing keys may also be configured in resolver
systems that use zones as a trusted root[4] for a secure island.
Early deployment tests have shown that during the key-exchange
between the parent and the child 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. The availability of the flag allows the key exchange to
be automated where, without the flag, some additional out-of-band
communication is needed.
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, no special meaning should be assigned.
The 15th bit is currently reserved [3].
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 & Schlyter Expires March 2, 2003 [Page 3]
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 first link in the chain of trust for their zone.
Parent zone administrators and resolver administrators that want to
configure a keysigning key as their 'trusted key' MAY choose to
ignore the flag.
Using the flag a key rollover can be automated. The parent can use
an existing trust relation to verify keysets in which a new key with
the KS flag appears.
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.
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 MAY be used for automating key exchanges, we think
the following consideration is in place.
Automated mechanisms for rollover of the DS RR may be vulnerable to a
class of replay attacks. This may happen after a key exchange where
a keyset, containing two keys with the KS flag set, is sent to the
parent. The parent verifies the keyset 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 may be replayed, if the parent
does not maintain state of which DS RRs where used previously so that
the new DS RR is replaced by the old DS RR again. These kinds of
attacks can be prevented by maintaining a registry of keys that have
been used to generate DS RRs from previously.
6. Document Changes
Kolkman & Schlyter Expires March 2, 2003 [Page 4]
Internet-Draft KEY RR Key Signing (KS) Flag September 2002
6.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 keysigning
key configured in resolvers and in parent zones.
7. Acknowledgments
The ideas documented in this draft are inspired by communications we
had with numerous people and ideas published by other folk, Olafur
Gudmundsson, Daniel Karrenberg, Dan Massey and Sam Weiler have been
helping with providing ideas and feedback.
This document saw the light during a workshop on DNSSEC operations
hosted by USC/ISI.
References
[1] Gudmundsson, "Delegation Signer Resource Record", work in
progress draft-ietf-dnsext-delegation-signer-08.txt, June 2002.
[2] Orwell, "Animal Farm; a Fairy Story"", 1945, <http://
www.ddc.net/ygg/etext/animal.htm#10>.
[3] 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.
[4] Lewis, E., "DNS Security Extension Clarification on Zone
Status", RFC 3090, March 2001.
Kolkman & Schlyter Expires March 2, 2003 [Page 5]
Internet-Draft KEY RR Key Signing (KS) Flag September 2002
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 & Schlyter Expires March 2, 2003 [Page 6]
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 & Schlyter Expires March 2, 2003 [Page 7]

28
doc/draft/draft-ietf-idn-punycode-02.txt → doc/draft/draft-ietf-idn-punycode-03.txt
View File

@@ -1,8 +1,8 @@
INTERNET-DRAFT Adam M. Costello
draft-ietf-idn-punycode-02.txt 2002-May-23
Expires 2002-Nov-23
draft-ietf-idn-punycode-03.txt 2002-Oct-08
Expires 2003-Apr-08
Punycode: An encoding of Unicode for use with IDNA
Punycode: A Bootstring encoding of Unicode for IDNA
Status of this Memo
@@ -81,6 +81,12 @@ Contents
constraints. For the details of the prefix and constraints, see
[IDNA] and [NAMEPREP].
Punycode is an instance of a more general algorithm called
Bootstring, which allows strings composed from a small set of
"basic" code points to uniquely represent any string of code points
drawn from a larger set. Punycode is Bootstring with particular
parameter values appropriate for IDNA.
1.1 Features
Bootstring has been designed to have the following features:
@@ -92,7 +98,7 @@ Contents
* Uniqueness: There is at most one basic string that represents a
given extended string.
* Reversibility: Any extended string mapped to a basic string can
be recovered from that basic string.
@@ -100,7 +106,7 @@ Contents
extended string length is small. This is important in the
context of domain names because RFC 1034 [RFC1034] restricts the
length of a domain label to 63 characters.
* Simplicity: The encoding and decoding algorithms are reasonably
simple to implement. The goals of efficiency and simplicity are
at odds; Bootstring aims at a good balance between them.
@@ -145,7 +151,7 @@ Contents
An overflow is an attempt to compute a value that exceeds the
maximum value of an integer variable.
3. Bootstring description
Bootstring represents an arbitrary sequence of code points (the
@@ -154,7 +160,7 @@ Contents
"Bootstring algorithms" presents the algorithms as pseudocode.
Sections 7.1 "Decoding traces" and 7.2 "Encoding traces" trace the
algorithms for sample inputs.
The following sections describe the four techniques used in
Bootstring. "Basic code point segregation" is a very simple
and efficient encoding for basic code points occurring in the
@@ -541,7 +547,7 @@ Contents
code points less than initial_n are basic code points (which is true
for Punycode if code points are unsigned).
The brace-enclosed conditions "non-basic" and "or m is basic" can be
The brace-enclosed conditions "non-basic" and "or c is basic" can be
omitted if initial_n exceeds all basic code points (which is true
for Punycode), because the code point being tested is never less
than initial_n.
@@ -965,13 +971,13 @@ C. Disclaimer and license
D. Punycode sample implementation
/*
punycode.c from draft-ietf-idn-punycode-02
punycode.c from draft-ietf-idn-punycode-03
http://www.nicemice.net/idn/
Adam M. Costello
http://www.nicemice.net/amc/
This is ANSI C code (C89) implementing
Punycode (draft-ietf-idn-punycode-02).
Punycode (draft-ietf-idn-punycode-03).
*/
@@ -1486,4 +1492,4 @@ int main(int argc, char **argv)
INTERNET-DRAFT expires 2002-Nov-23
INTERNET-DRAFT expires 2003-Apr-08