mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-29 05:28:00 +00:00
Code Issues Releases Wiki Activity

added new drafts and removed obsolete ones

Browse Source
This commit is contained in:
Andreas Gustafsson 2000-03-03 21:05:56 +00:00
parent d51f376da2
commit 540c1bf12c
11 changed files with 1210 additions and 2753 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1804
doc/draft/draft-duerst-dns-i18n-01.txt → doc/draft/draft-duerst-dns-i18n-02.txt
View File

File diff suppressed because it is too large Load Diff

470
doc/draft/draft-ietf-dnsind-indirect-key-00.txt
View File

@ -1,470 +0,0 @@
DNSIND Working Group D. Eastlake
INTERNET-DRAFT IBM
Expires October 1999
April 1999
draft-ietf-dnsind-indirect-key-00.txt
Indirect KEY RRs in the Domain Name System (DNS)
-------- --- --- -- --- ------ ---- ------ -----
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-dnsind-indirect-key-00.txt, is
intended to be become a Proposed Standard RFC. Distribution of this
document is unlimited. Comments should be sent to the DNSSEC mailing
list <dns-security@tis.com> or to the author.
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. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``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.
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
[RFC 2535] defines a means for storing cryptographic public keys in
the Domain Name System. An additional code point is defined for the
algorithm field of the KEY resource record (RR) to indicate that the
key is not stored in the KEY RR but is pointed to by the KEY RR.
Encodings to indicate different types of key and pointer formats are
specified.
[This draft is moved from the DNSSEC WG as part of that WG's merger
into me DNSIND WG. It would have been draft-ietf-dnssec-indirect-
key-02.txt in the DNSSEC WG.]
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT Indirect KEY RRs
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
2. The Indirect KEY RR Algorithm...........................3
2.1 The Target Type Field..................................4
2.2 The Target Algorithm Field.............................5
2.3 The Hash Fields........................................5
3. Performance Considerations..............................6
4. IANA Considerations.....................................6
5. Security Considerations.................................6
References.................................................7
Author's Address...........................................7
Expiration and File Name...................................8
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT Indirect KEY RRs
1. Introduction
The Domain Name System (DNS) security extensions [RFC 2535] provide
for the general storage of public keys in the domain name system via
the KEY resource record (RR). These KEY RRs are used in support of
DNS security and may be used to support other security protocols.
KEY RRs can be associated with users, zones, and hosts or other end
entities named in the DNS.
For reasons given below, it will sometimes be desireable to store a
key or keys elsewhere and merely point to it from the KEY RR.
Indirect key storage makes it possible to point to a key service via
a URL, to have a compact pointer to a larger key or set of keys, to
point to a certificate either inside DNS [RFC 2538] or outside the
DNS, and where appropriate, to store a key or key set applicable to
many DNS entries in some place and point to it from those entries.
However, to simplify DNSSEC implementation, this technique MUST NOT
be used for KEY RRs used in for verification in DNSSEC, i.e., the
value of the "protocol" field of an indirect KEY RR MUST NOT be 3.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD",
"RECOMMENDED", and "MAY" in this document are to be interpreted as
described in [RFC 2119].
2. The Indirect KEY RR Algorithm
Domain Name System (DNS) KEY Resource Record (RR) [RFC 2535]
algorithm number 252 is defined as the indirect key algorithm. This
algorithm MAY NOT be used for zone keys in support of DNS security.
All KEYs used in DNSSEC validation MUST be stored directly in the
DNS.
When the algorithm byte of a KEY RR has the value 252, the "public
key" portion of the RR is formated as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| target type | target alg. | hash type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hash size | hash (variable size) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
| /
/ pointer (variable size) /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT Indirect KEY RRs
2.1 The Target Type Field
Target type specifies the type of the key containing data being
pointed at.
Target type
-----------
0 - reserved, see section 4
1 - indicates that the pointer is a domain name from which KEY RRs
[RFC 2535] should be retrieved. Name compression in the pointer
field is prohibited.
2 - indicates that the pointer is a null terminated character string
which is a URL [RFC 1738]. For exisiting data transfer URL
schemes, such as ftp, http, shttp, etc., the data is the same as
the public key portion of a KEY RR. (New URL schemes may be
defined which return multiple keys.)
3 - indicates that the pointer is a domain name from which CERT RRs
[RFC 2538] should be retrieved. Name compression in the pointer
field is prohibited.
4 - indicates that the pointer is a null terminated character string
which is a URL [RFC 1738]. For exisiting data transfer URL
schemes, such as ftp, http, shttp, etc., the data is the same as
the entire RDATA portion of a CERT RR [RFC 2538]. (New URL
schemes may be defined which return multiple such data blocks.)
5 - indicates that the pointer is a null terminated character string
which is a URL [RFC 1738]. For exisiting data transfer URL
schemes, such as ftp, http, shttp, etc., the data is a PKCS#1 [RFC
2437] format key. (New URL schemes may be defined which return
multiple keys.)
6 through 255 - available for assignment, see section 4.
256 through 511 (i.e., 256 + n) - indicate that the pointer is a null
terminated character string which is a URL [RFC 1738]. For
exisiting data transfer URL schemes, such as ftp, http, shttp,
etc., the data is a certificate of the type indicated by a CERT RR
[RFC 2538] certificate type of n. That is, target types 257, 258,
and 259 are PKIX, SPKI, and PGP certificates and target types 509
and 510 are URL and OID private certificate types. (New URL
schemes may be defined which return multiple such certificates.)
512 through 65534 - available for assignment, see section 4.
65535 reserved, see section 4.
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT Indirect KEY RRs
2.2 The Target Algorithm Field
The algorithm field is as defined in [RFC 2535]. If non-zero, it
specifies the algorithm type of the target key or keys pointed. If
zero, it does not specify what algorithm the target key or keys apply
to.
2.3 The Hash Fields
If the indirecting KEY RRset [RFC 2181, 2535] is retrieved from an
appropriately secure DNS zone with a resolver implementing DNS
security, then there would be a high level of confidence in the
entire value of the KEY RRset including any direct keys. This may or
may not be true of any indirect key pointed to. If an indirect key
is embodied in a certificate or retrieved via a secure protocol such
as SHTTP, it may also be secure. But an indirecting KEY RR could,
for example, simply have an FTP URL pointing to a binary key stored
elsewhere, the retrieval of which would not be secure.
The hash option in algorithm 252 KEY RRs provides a means of
extending the security of the indirecting KEY RR to the actual key
material pointed at. By including a hash in a secure indirecting RR,
this secure hash can be checked against the hash of the actual keying
material
Type Hash Algorithm
---- --------------
0 indicates no hash present
1 MD5 [RFC 1321]
2 SHA-1
3 RIPEMD
4-252 available, see section 4
253 private, domain name (see below)
254 private, OID (see below)
255 reserved
Codes 253 and 254 indicate that a private, proprietary, local, or
experimental hash algorithm is used. For code 253, the hash field
begins with a wire encoded domain name (with compression prohibited)
that indicates the algorithm to use. For code 254, the hash field
begins with a one byte unsigned OID length followed by a BER encoded
OID which indicates the algorithm to use.
The hash size field is an unsigned octet count of the hash field size
less the length of any code 253 or 254 prefix. For some hash
algorithms it may be fixed by the algorithm choice but this will not
always be the case. For example, hash size is used to distinguish
between RIPEMD-128 (16 octets) and RIPEMD-160 (20 octets). If the
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT Indirect KEY RRs
hash algorithm field is 0, the hash size MUST be zero and no hash
octets are present.
The hash field itself is variable size with its length specified by
the hash size field and any code 253 or 254 prefix.
3. Performance Considerations
With current public key technology, an indirect key will sometimes be
shorter than the keying material it points at. In addition, there
can be cases where a single indirect KEY RR points to multiple keys
elsewhere. This may improve DNS performance in the retrieval of the
initial KEY RR. However, an additional retrieval step then needs to
be done to get the actually keying material which must be added to
the overall time to get the public key.
4. IANA Considerations
IETF consensus, standards action, and similar terms in this section
are as define in [RFC 2434].
KEY RR algorithm number 252 was already reserved for indirect keys in
RFC 2535.
An IETF standards action is required to allocate target type codes
hex x0000, x0006 through x00FF, x0200 through x0FFF, and xFFFF.
Codes in the range x1000 through x7FFF can be allocated by an IETF
consensus. Codes x8000 through xFEFF are available on a first come
first serve basis. Codes xFF00 through xFFFE are available for
experimentation or private local use without allocation. Use of
codes in this block may result in conflicts outside such experiment
or locality.
An IETF consensus is required to allocate an indirect KEY RR hash
algorithm code in the range 4-252 and a standards action is required
to allocate hash algorithm code 255. Codes 253 and 254 should cover
requirements for local, private, or proprietary algorithms.
5. Security Considerations
The indirecting step of using an indirect KEY RR adds complexity and
additional steps where security could go wrong. If the indirect key
RR was retrieved from a zone that was insecure for the resolver, you
have no security. If the indirect key RR, although secure itself,
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT Indirect KEY RRs
point to a key which can not be securely retrieved and is not
validateted by a secure hash in the indirect key RR, you have no
security.
References
RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities",
STD 13, November 1987.
RFC 1035 - P. Mockapetris, "Domain Names - Implementation and
Specifications", STD 13, November 1987.
RFC 1321 - R. Rivest, "The MD5 Message-Digest Algorithm", April 1992.
RFC 1738 - T. Berners-Lee, L. Masinter & M. McCahill, "Uniform
Resource Locators (URL)", December 1994.
RFC 2119 - "Key words for use in RFCs to Indicate Requirement
Levels", S. Bradner. March 1997.
RFC 2181 - R. Elz, R. Bush, "Clarifications to the DNS
Specification", July 1997.
RFC 2434 - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", October 1998.
RFC 2437 - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2.0", October 1998.
RFC 2535 - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
RFC 2538 - D. Eastlake, O. Gudmundsson, "Storing Certificates in the
Domain Name System (DNS)", March 1999.
Author's Address
Donald E. Eastlake 3rd
IBM
65 shindegan Hill Road, RR #1
Carmel, NY 10512 USA
Telephone: +1-914-784-7913 (w)
+1-914-276-2668 (h)
FAX: +1-914-784-3833 (w)
EMail: dee3@us.ibm.com
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT Indirect KEY RRs
Expiration and File Name
This draft expires October 1999.
Its file name is draft-ietf-dnsind-indirect-key-00.txt.
D. Eastlake 3rd [Page 8]

19
doc/draft/draft-ietf-dnsind-indirect-key-01.txt Normal file
View File

@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
D. Eastlake 3rd: dee3@torque.pothole.com

662
doc/draft/draft-ietf-dnsind-local-names-07.txt
View File

@ -1,662 +0,0 @@
DNS Working Group Donald E. Eastlake, 3rd
INTERNET-DRAFT IBM
Expires December 1999 June 1999
draft-ietf-dnsind-local-names-07.txt
Local Domain Name System (DNS) Names
----- ------ ---- ------ ----- -----
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-dnsind-local-names-07.txt.
Distribution of this document is unlimited. Comments should be sent
to the DNS mailing list <namedroppers@internic.net> or to the author.
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. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``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.
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
It is increasingly common for their to be "local" domain names which
are not intended to be seen from the global Internet. In some cases
this if for policy reasons, in other cases because they map to IP
addresses or other data which is only locally meaningful [RFC 1918,
2373].
A new top level domain (TLD) name (.local) is reserved and a name
structure suggested below this TLD such that local private DNS zones
can safely be created without fear of conflict if these names should
leak out of a private enclave. It addition, a method of providing
DNS service for these names is suggested such that they are
maintained privately, similar to the reserved private IP addresses,
D. Eastlake 3rd [Page 1]
INTERNET-DRAFT Local DNS Names
yet locally appear to be part of the global DNS name tree and are
reachable by a local resolver with no special knowledge. Additional
second level domain names are assigned under this TLD for IPv6 link
and site local addresses and loopback functions.
Acknowledgments
The valuable contributions of the following persons are gratefully
acknowledged:
Dan Harrington
Michael A. Patton
D. Eastlake 3rd [Page 2]
INTERNET-DRAFT Local DNS Names
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Acknowledgments............................................2
Table of Contents..........................................3
1. Introduction............................................4
2. Local Names Via The .local Top Level Domain.............5
2.1 Local DNS Server Specifics.............................7
2.2 Local in-addr.arpa Zones...............................8
2.3 Name Conflicts.........................................8
2.4 Nested Enclaves........................................9
3. Other Names in .local...................................9
4. Security Considerations.................................9
4.1 Strength of Privacy Offered............................9
4.2 Interaction with DNSSEC...............................10
References................................................11
Author's Address..........................................11
Expiration and File Name..................................11
D. Eastlake 3rd [Page 3]
INTERNET-DRAFT Local DNS Names
1. Introduction
The global Internet Domain Name System (DNS) is documented in [RFC
1034, 1035, 1591, 2606] and numerous additional Requests for Comment.
It defines a tree of names starting with root, ".", immediately below
which are top level domain names such as .com and .us. Below top
level domain names there are normally additional levels of names.
Generally the information in the DNS is public and intended to be
globally accessible. Certainly, in the past, the model of the
Internet was one of end-to-end openness [RFC 1958]. However, with
increasing security threats and concerns, firewalls and enclaves have
appeared. In many cases, organizations have hosts or resources that
they specifically want to reference with DNS names but which they
also want to be walled off from global access and even from global
knowledge of the DNS name for the resource.
In the realm of IP addresses, this has been accomplished by reserving
three blocks of IPv4 addresses as documented in [RFC 1918] and by
allocating parts of the IPv6 address space for link and site local
addresses [RFC 2373]. Familiarity with the contents of these RFCs is
assumed. Addresses in these blocks are not to be globally routed.
In the DNS area, local private names have generally been achieved in
the past by "splitting" DNS at the enclave boundary, giving different
answers to resolvers depending or whether they are inside or outside
of the enclave, using different servers for inside and outside, etc.
as mentioned in [RFC 1918]. Such relatively complex configuration
diddling is at variance with the simple global tree structure of the
initial DNS concept.
This document specifies an alternative approach to achieving the
effect of local names that is more in tune with the concept of a
single global DNS tree or at least the appearance of a single tree.
Use of this approach is not required and older techniques will
continue to work.
[RFC 1918] requires that private IP addresses not be indirectly
exposed to the general Internet via DNS records or otherwise. By
implication, the same would be true of IPv6 local addresses. This
RFC provides the recommended way to accomplish such private IP
address hiding and carves out a limited exception thereto for the
addresses of the servers for some zones which are children of the
.local top level domain name.
D. Eastlake 3rd [Page 4]
INTERNET-DRAFT Local DNS Names
2. Local Names Via The .local Top Level Domain
The fundamental idea, as described in more detail below, is to define
second level domains under .local which are served by DNS name
servers that have private IP addresses. These server's addresses
would only be routed within the domain to which the names are local.
Thus the servers, and the names and resource records inside them,
would not be directly accessible outside the enclave, if the
guidelines in this document are followed.
The following figure shows a highly simplified overview of an example
configuration:
+----------------------------+
| domain/enclave A |
| |
| #====================# |
| H private IP addrs A H |
| H H |
+-----------------------O privhost1 H |
| | H H |
+-----+-----------------O privhost2 H |
| | | H H |
| | | #====================# |
| | a | |
| +--------------------O pubhost3 |
.local | | | | |
+----+ | | +----------------------------+
| | | |
| | | | +----------------------------+
| | | | | domain/enclave B |
(root) | | | | | |
. ----+ | | | | #====================# |
| | | | | H private IP addrs B H |
| | | | | H H |
| +--|--------------------O privhost2 H |
| | | | H H |
+-------+ +-----------------O privhost3 H |
.com | | H : H |
| | #====:===============# |
| | : |
| b +-------------O pubhost4 |
+------+ | |
| +-------------O pubhost5 |
| | |
| +----------------------------+
|
| example
+---------------------O pubhost6
D. Eastlake 3rd [Page 5]
INTERNET-DRAFT Local DNS Names
Starting at the bottom, pubhost6 is intended to illustrate an
ordinary host connected to the Internet with domain name
pubhost6.example.com. Though not indicated in the above diagram,
every DNS zone is in fact served by at least two hosts (and some but
substantially more). The addresses of the servers for the root (.),
.com, and example.com zones would all be in the public portion of the
IP address space, i.e., in the space of all unicast IP addresses not
reserved for private use.
Moving to the top of the figure, enclave A represents some
organization that wishes to have some hosts with publicly visible
names and some with hidden names that are visible only locally.
pubhost3.a.com is an example of a publicly visible host which would
probably have a public IP address although access to pubhost3 from
outside the enclave might be filtered or even blocked by a firewall
or the like. privhost1 and privhost2 are examples of hidden names.
If a zone with privhost1 and privhost2 in it is served by DNS servers
with private IP addresses ("private IP addresses A") such that the
servers are accessible within enclave A but not from outside enclave
A, then the information is that zone will only be locally visible.
As show in the above figure, privhost1 and privhost2 have addresses
that are also private IP addresses, making those hosts inaccessible
outside enclave A, but it is the private addresses of the DNS
servers, not of the hosts pointed to from within the private DNS
zone, that provides the protection for the DNS names and other
private DNS information. (From the above simplified diagram, it
might appear that fully qualified domain names of these hosts would
be privhost1.local and privhost2.local but the names are actually
more complex as explained in Section 2.1.)
Finally, in the middle, another enclave is shown with two hosts with
visible names and public IP addresses, pubhost4.b.com and
pubhost5.b.com. In addition, there are two private host names
privhost2 and privhost3. The duplication of privhost2 between
enclaves A and B would not be a problem as only DNS resolvers in
enclave A can access the DNS servers with the zone having the enclave
A version of privhost2 and only DNS resolvers in enclave B can access
the DNS servers with the zone having the enclave B version of
privhost2.
Publicly visible host names are required by [RFC 1918] to have public
(i.e., globally unique) IP addresses. Private DNS names would
normally have private IP addresses, and all do in the figure above,
but this is not required. A public IP address could be stored under
a private name. And, of course, it is possible for the same physical
host to have multiple IP addresses, including a mix of public and
private. The dotted line in the figure above is intended to indicate
that privhost3 and pubhost4 are actually the same physical machine.
The could be accomplished equally well by storing a single public
address for that host under both the public and private names or by
D. Eastlake 3rd [Page 6]
INTERNET-DRAFT Local DNS Names
having the host answer to both a public IP address stored under the
public name and a private IP address stored under the private name.
In the later case you could even also store the public address along
with the private address under the private name.
2.1 Local DNS Server Specifics
A variety of second level names are provided in the .local zone each
of which is a delegation point to a zone with some number of name
servers in one of the private IP address space blocks. The multiple
second level names permit choice between the different private IP
blocks and different numbers of servers. Thus the actual fully
qualified name for the private host examples in the figure above
would be more like privhost1.a2.local, privhost2.a2.local, etc. (but
see Section 2.3 below).
Glue records are provided to give private IP addresses for initial
name servers; however, it should be noted that the NS and A records
in the local zones will dominate the information stored in the .local
zone. This means that once a resolver has contacted a local server,
the list of NS RRs in the local zone on that server will control and
could contain more or different servers than were given at the chosen
.local delegation point. Nevertheless, the glue A records in the
global .local zone do place some constraints of the private IP
address of the local DNS servers implementing zones which are
children of .local.
It is also possible for an enclave to locally configure its own
version of the .local zone. Depending on its enclave boundary
implementation, it might be able to constrain all of its internal
references to .local to use its own variant version. This version
could have whatever private addresses were desired for the name
servers involved. Such a configuration MAY be used, but it is
recommended that the globally accessible .local specified herein be
used for uniformity. That way, even a unconstrained resolver
starting from the normal root servers (i.e., an "out of the box"
resolver) will correctly resolve or fail to resolve names under
.local depending on the resolvers location in the network as
specified herein.
It is only necessary for the local DNS servers to have private IP
addresses to achieve the effect of local names. However, care MUST
be taken that none of the local DNS servers or any server that might
cache their output is accessible by any network interface that has a
non-private IP address. Otherwise considerable confusion could
result if local names are resolved by a resolver outside a local
enclave to private IP addresses which have a different meaning for
that resolver.
D. Eastlake 3rd [Page 7]
INTERNET-DRAFT Local DNS Names
2.2 Local in-addr.arpa Zones
Inverse lookup of local names corresponding to private IP addresses
needs to be provided via the in-addr.arpa and ip6.int zones. Because
of the fixed naming within this zone, different names with different
numbers of servers or different addresses can not be provided. As
with the forward .local entries, the actual NS RRs in the servers
serving the private portions of the inverse in-addr.arpa will
dominate. When one of these is queried by a resolver, it can provide
information on additional servers for that particular subzone in the
private IP address portion of the in-addr.arpa tree.
2.3 Name Conflicts
The intention is that local names would only be used in the enclave
where the entities they refer to exist, and these names would not be
exported. However, experience indicates that. despite best efforts
to avoid it, some such names will leak out via email cc's, URL's in
HTML, etc. (Such leakage occurs regardless of how the local names
are formed or whether they are accessible via the default root zone.)
These leaked private names can cause confusion if they can conflict
with global names or names local to other enclaves. Use of the
.local top level domain assures no conflict with global names. To
assure no conflict with different local fully qualified names, the
domain name of the enclave SHOULD always be prefixed to .local.
For example, a company might have
host1.company.example
as a globally accessible host and
host2.company.example.b3.local
as a host for internal use only. The global name could normally be
resolvable anywhere on the Internet while the local name could not be
resolved anywhere except within the company enclave.
Note that different names were chosen for the initial label in the
two names above, i.e., host1 and host2. The reason for this is that,
in some environments, local hosts are referred to by an unqualified
names, such as host3. For DNS look up purposes, such a name must be
expanded into a fully qualified domain name and a "search list" of
possible suffix qualifications is tried. If, for example, both
host4.school.ac.example and host4.school.ac.example.b3.local existed,
then a local reference to "host4" would be ambiguous and could lead
to either machine depending on the order of qualifications tried.
This order could even be different in different pieces of local
software or on different local hosts, resulting in substantial
confusion. For this reason, it is strongly recommended that disjoint
name sets be used for global and local entity unqualified domain
names and that fully qualified domain names be used wherever
D. Eastlake 3rd [Page 8]
INTERNET-DRAFT Local DNS Names
practical.
2.4 Nested Enclaves
It is possible to have enclaves within enclaves. In general the best
way to accomplish this is to use a different portion of the private
IP address space at each nesting level of enclave. (Private IP
address space can be reused in enclaves that are siblings or the
like.) Then similar entries to those proposed here for .local can be
made in the private zone referring to name servers with addresses in
the nested enclave's private IP address space.
3. Other Names in .local
Three additional second level domain names are assigned in the .local
top level domain for other types of local names.
In particular,
link.local and
site.local
are reserved for use in qualifying IPv6 link local names and site
local names.
In addition, loopback.local is assigned and given the loopback
address.
4. Security Considerations
This section discusses the strength of the privacy offered by using
subzones of .local and interactions with DNS security.
4.1 Strength of Privacy Offered
Local names, as proposed herein, are not intended to be a strong
security mechanism.
The privacy of the DNS information protected by storing it in servers
with private IP addresses is weak. It is completely dependent on the
integrity of enclave perimeter routing to make these servers
inaccessible. And it may occasionally leak out in any case due to
inclusion in email address fields, web pages, and the like, although
such leakage should be no worse than current split DNS
D. Eastlake 3rd [Page 9]
INTERNET-DRAFT Local DNS Names
implementations of DNS data hiding.
Software should not depend on local names being accessible only
within a particular enclave as someone could deliberately create the
same names within a different enclave. This is true even if, as
recommended herein, the names incorporate the domain name of the
original enclave in an attempt to avoid such conflicts.
4.2 Interaction with DNSSEC
Although an enclave may derive some amount of security by virtue of
its isolation, it will normally be desirable to implement DNS
security [RFC 2535] within the enclave. The enclave owner should
generate their own keys and sign their subzone of .local. However, a
signed copy of their public key can not be included in the .local
zone as it is different for every enclave. Thus, to authenticate the
.local subzone contents, it will be necessary to sign the KEY RR at
the apex of the local subzone of .local with the .local zone key or
another key that is trusted by local resolvers or staticly configure
the public key for the .local subzone in local resolvers.
D. Eastlake 3rd [Page 10]
INTERNET-DRAFT Local DNS Names
References
RFC 1033 - M. Lottor, "Domain Administrators Operations Guide",
November 1987.
RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities",
STD 13, November 1987.
RFC 1035 - P. Mockapetris, "Domain Names - Implementation and
Specifications", STD 13, November 1987.
RFC 1591 - J. Postel, "Domain Name System Structure and Delegation",
03/03/1994.
RFC 1918 - Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E.
Lear, "Address Allocation for Private Internets", 02/29/1996.
RFC 1958 - B. Carpenter, "Architectural Principles of the Internet",
06/06/1996.
RFC 2373 - R. Hinden, S. Deering, "IP Version 6 Addressing
Architecture", July 1998
RFC 2535 - D. Eastlake, "Domain Name System Security Extensions",
March 1999.
RFC 2606 - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
June 1999.
Author's Address
Donald E. Eastlake 3rd
IBM
65 Shindegan Hill Road, RR #1
Carmel, NY 10512 USA
Telephone: +1 914-276-2668 (h)
+1 914-784-7913 (w)
FAX: +1 914-784-3833 (w)
EMail: dee3@us.ibm.com
Expiration and File Name
This draft expires December 1999.
Its file name is draft-ietf-dnsind-local-names-07.txt.
D. Eastlake 3rd [Page 11]
D. Eastlake 3rd [Page 12]

19
doc/draft/draft-ietf-dnsind-local-names-08.txt Normal file
View File

@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
D. Eastlake: dee3@us.ibm.com

158
doc/draft/draft-ietf-dnsind-verify-00.txt
View File

@ -1,158 +0,0 @@
INTERNET-DRAFT Mark Andrews (ISC)
<draft-ietf-dnsind-verify-00.txt> February 1999
Verifying Resource Records Without Knowing Their Contents
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
This document is an Internet-Draft. 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.
Abstract
DNSSEC [RFC2065] provides a mechanism to cryptographically verify a
DNS resource record provided we can get it into canonical form.
The problem is how do we do this without knowing the contents of all
resource record types?
This document provides one possible solution to this problem.
1 - Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Expires August 1999 [Page 1]
INTERNET-DRAFT draft-ietf-dnsind-verify-00.txt February 1998
2 - Method
In order to be able to canonicalise a resource record a resolver needs
to know where in the data domain names exist so that the resolver can
decompress the domain names and convert the uppercase ASCII in ordinary
labels to lowercase prior to the data being feed into the encryption
routines.
This document propose that all new resource record types defined MUST
have a header at the start of the data section locating where the domain
names are in the data section. A new resource record for the purpose of
this document is any type NOT referenced in section 3 Old Types. Meta
queries such as MAILA (254), MAILB (253), AXFR (252) and IXFR (251) are
not covered by this document as they do not return data of this type.
This table would be a series of unsigned 16 bit words in network order.
The first word contains the length of the table as 16 bit words not
counting the first word. Subsequent words contain the offset from the
start of the data to the start of relevent domain name in the data
assuming all domain names are uncompressed. Offsets in the table are in
the same order as domain names in the data.
3 Old Types
The following types are deemed old and are NOT covered by this document.
A (1), NS (2), MD (3), MF (4), CNAME (5), SOA (6), MB (7), MG (8), MR
(9), NULL (10), WKS (11), PTR (12), HINFO (13), MINFO (14), MX (15), TXT
(16), RP (17), AFSDB (18), X25 (19), ISDN (20), RT (21), NSAP (22),
NSAP-PTR (23), SIG (24), KEY (25), PX (26), GPOS (27), AAAA (28), LOC
(29), NXT (30), EID (31), NIMLOC (32), SRV (33), ATMA (34), NAPTR (35),
KX (36), CERT (37), A6 (38), DNAME (39), UINFO (100), UID (101), GID
(102), UNSPEC (103), OPT (XXX), TKEY (249) and TSIG (250).
4 Security Considerations
It is believed that this document does not introduce any significant
additional security threats other that those that already exist when
using data from the DNS but rather enhances security by allowing new
resource record types to be checked by security aware resolvers.
5 IANA Considerations
This document places no requirements apon IANA.
Expires August 1999 [Page 2]
INTERNET-DRAFT draft-ietf-dnsind-verify-00.txt February 1998
References
[RFC2065]
Eastlake, D. 3rd. and Kaufman, C,. "Domain Name System Security
Extensions," RFC 2065, January 1997
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Lev­
els," BCP 14, RFC 2119, March 1997
Author's Address
Mark Andrews
Internet Software Consortium
1 Seymour St.
Dundas Valley
NSW 2117
AUSTRALIA
+61 2 9871 4742
<Mark_Andrews@isc.org>
Expires August 1999 [Page 3]

19
doc/draft/draft-ietf-dnsind-verify-01.txt Normal file
View File

@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
M. Andrews: Mark_Andrews@isc.org

522
doc/draft/draft-ietf-dnssec-as-map-05.txt
View File

@ -1,522 +0,0 @@
INTERNET-DRAFT Mapping AS Number into the DNS
July 1997
Expires January 1998
Mapping Autonomous Systems Number into the Domain Name System
------- ---------- ------- ------ ---- --- ------ ---- ------
Donald E. Eastlake 3rd
Status of This Document
This draft, file name draft-ietf-dnssec-as-map-05.txt, is intended to
be become a Best Current Practice RFC concerning utilization of the
Domain Name System (DNS) to support routing security. Distribution of
this document is unlimited. Comments should be sent to the DNS
Security Working Group mailing list <dns-security@tis.com> or to the
author.
This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (East USA), ftp.isi.edu (West USA),
nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe),
munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa).
Donald E. Eastlake 3rd [Page 1]
INTERNET-DRAFT Mapping AS Numbers into the DNS
Abstract
One requirement of secure routing is that independent routing
entities, such as those identified by Internet Autonomous System
Numbers, be able to authenticate messages to each other. Additions
have developed to the Domain Name System to enable it to be used for
authenticated public key distribution [RFC 2065]. This draft maps
all Autonomous System numbers into DNS Domain Names so that the DNS
security can be used to distribute their public keys.
[Changes from previous version are to accommodate AS numbers larger
than 16 bits and to delegate on decimal boundaries rather than binary
boundaries.]
Acknowledgements
The contributions of the following persons, listed in alphabetic
order, to this draft are gratefully acknowledged:
Ran Atkinson
Christian Huitema
Tony Li
Michael A. Patton.
Donald E. Eastlake 3rd [Page 2]
INTERNET-DRAFT Mapping AS Numbers into the DNS
Table of Contents
Status of This Document....................................1
Abstract...................................................2
Acknowledgements...........................................2
Table of Contents..........................................3
1. Introduction............................................4
2. Autonomous System Number Mapping........................5
3. Meaning of RRs..........................................6
4. Security Considerations.................................8
References.................................................8
Author's Address...........................................8
Expiration and File Name...................................9
Donald E. Eastlake 3rd [Page 3]
INTERNET-DRAFT Mapping AS Numbers into the DNS
1. Introduction
There are a number of elements required to secure routing in the
Internet. One of these is a way that independently operated routing
domains be able to authenticate messages to each other.
Sharing a private symmetric key between each pair of such domains is
impractical. Assuming 2**16 Autonomous System routing entities,
which is what is allowed in current versions of BGP, [RFC 1771], this
would imply approximately 2**31 pairs, an impractical number of keys
to securely generate, install, and periodically replace.
The solution is to use public key technology whereby each routing
domain has a private key it can use to sign messages. Other domains
that know the corresponding public key can then authenticate these
messages. Such authenticated messages can be used to set up and
maintain efficient symmetric keys on an as needed basis.
But how do the domains securely obtain the Autonomous System number
to public key mapping?
Extensions have been developed for the Domain Name System that enable
it to be conveniently used for authenticated public key distribution
[RFC 2065]. A variety of key types can be supported. All that is
required is a mapping of Autonomous System numbers into domain names,
which is provided by this draft.
It should be noted that the public keys retrieved from DNS will
likely be used primarily to authenticate initial connection set up
messages. Autonomous Systems that need to converse with any
frequency will probably negotiate more efficient symmetric session
keys.
Donald E. Eastlake 3rd [Page 4]
INTERNET-DRAFT Mapping AS Numbers into the DNS
2. Autonomous System Number Mapping
Autonomous System (AS) numbers are usually written as decimal number
and when blocks of AS numbers are delegated to a registry, it is
normally on decimal boundaries. Their current use in BGP is limited
to 16 bits providing a maximum value of 65,535. For example, ANS is
autonomous system 690. However, there is no inherent size limit in
the AS concept. AS numbers are mapped into a domain name as
described below.
Write the AS number, as usual, as a decimal number without any
"thousands" punctuation. If it is less than 5 digits, add leading
zeros to bring it up to five digits. Then simply reverse the order
of the digits, put a period between them, and append ".length.in-
as.arpa" where "length" is the number of AS digits. This mapping is
analogous to the IPv4 address mapping into the in-addr.arpa DNS
domain.
Thus the domain name correspond to Autonomous System 690 (decimal) is
0.9.6.0.0.5.in-as.arpa.
the domain corresponding to the largest possible AS number in BGP is
5.3.5.5.6.5.in-as.arpa.
the domain corresponding to AS number 65,000 is
0.0.0.5.6.5.in-as.arpa.
and the domain correspond to a hypothetical future greater than 16
bit AS number 1,234,567 is
7.6.5.4.3.2.1.7.in-as.arpa.
Donald E. Eastlake 3rd [Page 5]
INTERNET-DRAFT Mapping AS Numbers into the DNS
3. Meaning of RRs
The following guidance is given for some resource record (RR) types
that could be stored under the names mapped from AS numbers. The KEY
RR is given first, followed by the SIG RR, the NXT RR, and then some
additional RR types in alphabetic order.
KEY: This type of RR associates a public key with the owner name
which, in this case, corresponds to an Autonomous System (AS). Under
DNS security as proposed in RFC 2065 the KEY RR can be used to store
a variety of digital keys. A KEY for use in securing routing
communications between ASs will have the end entity flag bit on, the
authentication use prohibited flag bit off, and a protocol byte or
flag bit indicating routing communications use. Such a public key can
be used to authenticate communications with or between ASs. The
existence of such KEY RRs in the primary reason for mapping AS names
into the DNS.
SIG: The SIG signature resource record authenticates the RRs
that it signs as described in RFC 2065. Assuming the signer who
generated the SIG is trustworthy, such as the in-as.arpa zone owner,
then the signed RRs can be trusted.
NXT: An NXT RR is used in DNS security to provide authenticated
denial of the existence of types and names as described in RFC 2065.
A, AAAA: Type A or AAAA RRs SHOULD NOT be placed at AS nodes.
AS domain names are reserved for Autonomous Systems only and should
NOT be used for a host or any type of end entity other than an
Autonomous System.
CNAME: This type of RR is an alias pointing to another domain
name. An AS could have a CNAME pointing to a different AS but this
is not likely to be very useful as AS RRs will normally be looked up
when the AS number is actually encountered in use.
MX: There is no special use for an MX RR for an AS name. It
could point to a host that would accept mail related to that AS.
NS: The presence of NS records under an AS name means that it
has been carved out as a subzone. This gives the AS complete control
over the zone refresh parameters and control over the creation of
inferior names. No special meaning is currently assigned to such
inferior names so, although this is not advised, they could be used
for hosts or whatever. In this case, the will also be a zone KEY at
the AS name, indicated by having the zone flag bit on.
PTR: The part of the forward domain tree that administratively
corresponds to the AS SHOULD be indicated by a PTR RR. If some
entity, say example.xx, has several ASs, there would be PTRs to
Donald E. Eastlake 3rd [Page 6]
INTERNET-DRAFT Mapping AS Numbers into the DNS
example.xx from several names in the in-as.arpa hierarchy.
RP: A Responsible Person RR SHOULD appear under each AS name
telling you who you should contact in the case of problems with that
AS
TXT: Text RRs can be used for comments, postal address, or
similar notes under an AS name.
Donald E. Eastlake 3rd [Page 7]
INTERNET-DRAFT Mapping AS Numbers into the DNS
4. Security Considerations
This document concerns a means to map Internet Autonomous System
numbers into the Domain Name System (DNS) so that DNS can be used to
provide secure distribution of Autonomous System's public keys. The
security of the resulting AS to key mapping is dependent on the
security of the DNS security extensions and of the DNS zone where the
key is stored.
The most obvious way of using the AS keys retrieved from DNS is to
authenticate communications with a directly connected AS. However,
this does not prove that any routing information exchanged is
actually correct and note that routing information communicated over
this secured path may be indirectly forwarded from or to yet other
ASs.
References
[RFC 1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
November 1987
[RFC 1035] - Domain Names - Implementation and Specifications, P.
Mockapetris, November 1987.
[RFC 1771] - Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-
4)", 03/21/1995.
[RFC 2065] - Domain Name System Security Extensions, D. Eastlake, C.
Kaufman, January 1997.
Author's Address
Donald E. Eastlake 3rd
CyberCash, Inc.
318 Acton Street
Carlisle, MA 01741 USA
Telephone: +1 508 287 4877
+1 703 620-4200 (main office, Reston, VA)
FAX: +1 508 371 7148
EMail: dee@cybercash.com
Donald E. Eastlake 3rd [Page 8]
INTERNET-DRAFT Mapping AS Numbers into the DNS
Expiration and File Name
This draft expires January 1998.
Its file name is draft-ietf-dnssec-as-map-05.txt.
Donald E. Eastlake 3rd [Page 9]

19
doc/draft/draft-ietf-dnssec-as-map-06.txt Normal file
View File

@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
D. Eastlake: dee3@us.ibm.com

193
doc/draft/draft-skwan-gss-tsig-04.txt → doc/draft/draft-skwan-gss-tsig-05.txt
View File

@ -2,11 +2,13 @@ INTERNET-DRAFT Stuart Kwan
Praerit Garg
James Gilroy
Microsoft Corp.
June 1999
<draft-skwan-gss-tsig-04.txt> Expires January 2000
February 2000
<draft-skwan-gss-tsig-05.txt> Expires August 2000
GSS Algorithm for TSIG (GSS-TSIG)
Status of this Memo
This document is an Internet-Draft and is in full conformance
@ -29,6 +31,7 @@ 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.
Abstract
The TSIG protocol provides transaction level authentication for DNS.
@ -36,9 +39,21 @@ TSIG is extensible through the definition of new algorithms. This
document specifies an algorithm based on the Generic Security Service
Application Program Interface (GSS-API) [RFC2078].
Expires January 2000 [Page 1]
INTERNET-DRAFT GSS-TSIG June 1999
Expires August 2000 [Page 1]
INTERNET-DRAFT GSS-TSIG February 2000
Table of Contents
@ -65,6 +80,7 @@ Table of Contents
7: Acknowledgements.................................................13
8: References.......................................................13
1. Introduction
The Secret Key Transaction Signature for DNS [TSIG] protocol was
@ -87,9 +103,14 @@ over time. For example, a client and server may use Kerberos for one
transaction, whereas that same server may use TLS with a different
client.
Expires January 2000 [Page 2]
INTERNET-DRAFT GSS-TSIG June 1999
Expires August 2000 [Page 2]
INTERNET-DRAFT GSS-TSIG February 2000
* The protocol developer is removed from the responsibility of
creating and managing a security infrastructure. For example, the
@ -97,6 +118,7 @@ developer does not need to create new key distribution or key
management systems. Instead the developer relies on the security
service mechanism to manage this on its behalf.
2. Protocol Overview
Readers that are unfamiliar with the GSS-API concepts are encouraged
@ -114,6 +136,7 @@ server. Once a context has been established, it has a finite lifetime
for which it can be used to secure messages. Thus there are three
states of a context associated with a connection:
+----------+
| |
V |
@ -138,9 +161,13 @@ states of a context associated with a connection:
Every connection begins in the uninitialized state.
Expires January 2000 [Page 3]
INTERNET-DRAFT GSS-TSIG June 1999
Expires August 2000 [Page 3]
INTERNET-DRAFT GSS-TSIG February 2000
2.1 GSS Details
@ -155,6 +182,7 @@ Not all error return values from GSS-API interfaces are specified in
this document. When errors are encountered, the caller should act
appropriately.
3. Client Protocol Details
A unique context is required for each server to which the client sends
@ -167,6 +195,7 @@ The value key_name also identifies a context handle, and is used on
the wire to indicate to a server which context should be used to
process the current request.
3.1 Negotiating Context
In GSS, establishing a security context involves the passing of opaque
@ -183,9 +212,19 @@ tokens between client and server. The TKEY record is a general
mechanism for establishing secret keys for use with TSIG. For more
information, see [TKEY].
Expires January 2000 [Page 4]
INTERNET-DRAFT GSS-TSIG June 1999
Expires August 2000 [Page 4]
INTERNET-DRAFT GSS-TSIG February 2000
3.1.1 Call GSS_Init_sec_context
@ -227,9 +266,22 @@ The handle output_context_handle is unique to this negotiation and
is stored in the client's mapping table as the context_handle that
maps to target_server_name.
Expires January 2000 [Page 5]
INTERNET-DRAFT GSS-TSIG June 1999
Expires August 2000 [Page 5]
INTERNET-DRAFT GSS-TSIG February 2000
3.1.2 Send TKEY Query to Server
@ -261,6 +313,7 @@ and Verifying Signed Messages, for the signing procedure.
The query is transmitted to the server.
3.1.3 Receive TKEY Query-Response from Server
The server will return a standard TKEY query-response (see [TKEY]).
@ -277,9 +330,15 @@ next processing step depends on the value of major_status from the
most recent call to GSS_Init_sec_context: either GSS_S_COMPLETE or
GSS_S_CONTINUE.
Expires January 2000 [Page 6]
INTERNET-DRAFT GSS-TSIG June 1999
Expires August 2000 [Page 6]
INTERNET-DRAFT GSS-TSIG February 2000
3.1.3.1 Value of major_status == GSS_S_COMPLETE
@ -299,6 +358,7 @@ signature was not included, the context state is advanced to Context
Established. Proceed to section 3.2 for usage of the security
context.
3.1.3.2 Value of major_status == GSS_S_CONTINUE
If the last call to GSS_Init_sec_context yielded a major_status value
@ -327,9 +387,15 @@ with section 3.1.2. The client should place a limit on the number
of continuations in a context negotiation to prevent endless
looping.
Expires January 2000 [Page 7]
INTERNET-DRAFT GSS-TSIG June 1999
Expires August 2000 [Page 7]
INTERNET-DRAFT GSS-TSIG February 2000
If major_status is GSS_S_COMPLETE and output_token is non-NULL,
the client-side component of the negotiation is complete but the
@ -347,6 +413,7 @@ signature was not included, the context state is advanced to Context
Established. Proceed to section 3.2 for usage of the security
context.
3.2 Context Established
When context negotiation is complete, the handle context_handle is
@ -355,6 +422,7 @@ used for the generation and verification of transaction signatures.
The procedures for sending and receiving signed messages are given in
section 5, Sending and Verifying Signed Messages.
4. Server Protocol Details
As on the client-side, the result of a successful context negotiation
@ -366,14 +434,25 @@ request. The server maintains a mapping of key names to handles:
(key_name, context_handle)
4.1 Negotiating Context
A server recognizes TKEY queries as security context negotiation
messages.
Expires January 2000 [Page 8]
INTERNET-DRAFT GSS-TSIG June 1999
Expires August 2000 [Page 8]
INTERNET-DRAFT GSS-TSIG February 2000
4.1.1 Receive TKEY Query from Client
@ -384,6 +463,7 @@ the NAME value of the TKEY record. If the name is found in the table,
the corresponding context_handle is used in following GSS operations.
If the name is not found a new negotiation is started.
4.1.2 Call GSS_Accept_sec_context
The server performs its side of a context negotiation by calling
@ -407,6 +487,7 @@ negotiation, then output_context_handle is stored in the server's
key-mapping table as the context_handle that maps to the name of the
TKEY record.
4.1.3 Send TKEY Query-Response to Client
If major_status returns a GSS failure code, the negotiation has
@ -416,9 +497,19 @@ BADKEY.
Success values for major_status are GSS_S_COMPLETE or GSS_S_CONTINUE.
Expires January 2000 [Page 9]
INTERNET-DRAFT GSS-TSIG June 1999
Expires August 2000 [Page 9]
INTERNET-DRAFT GSS-TSIG February 2000
If major_status is GSS_S_COMPLETE the server component of the
negotiation is finished. The message from the client may be signed
@ -442,6 +533,7 @@ repeats beginning with section 4.1.1. The server must limit the
number of times that a given context is allowed to repeat, to prevent
endless looping.
4.2 Context Established
When context negotiation is complete, the handle context_handle
@ -453,6 +545,7 @@ a context at any time.
The procedures for sending and receiving signed messages are given in
section 5, Sending and Verifying Signed Messages.
4.2.1 Terminating a Context
A server can terminate any established context at any time. The
@ -463,9 +556,17 @@ by including a TKEY RR in a response with the mode field set to
An active context is deleted by calling GSS_Delete_sec_context
providing the associated context_handle.
Expires January 2000 [Page 10]
INTERNET-DRAFT GSS-TSIG June 1999
Expires August 2000 [Page 10]
INTERNET-DRAFT GSS-TSIG February 2000
5. Sending and Verifying Signed Messages
@ -475,7 +576,7 @@ The procedure for sending a signature-protected message is specified
in [TSIG]. The data to be passed to the signature routine includes
the whole DNS message with specific TSIG variables appended. For the
exact format, see [TSIG]. For this protocol, use the following
TSIG variable values:
TSIG variable values:
TSIG Record
NAME = key_name that identifies this context
@ -505,9 +606,24 @@ If major_status is GSS_S_CONTEXT_EXPIRED or GSS_S_CREDENTIALS_EXPIRED,
the caller needs to return to the uninitialized state and negotiate
a new security context.
Expires January 2000 [Page 11]
INTERNET-DRAFT GSS-TSIG June 1999
Expires August 2000 [Page 11]
INTERNET-DRAFT GSS-TSIG February 2000
5.2 Verifying a Signed Message - Call GSS_VerifyMIC
@ -547,15 +663,24 @@ If this error checking fails when a server is processing a client
request, the appropriate error response must be sent to the client
per [TSIG].
6. Security Considerations
This document describes a protocol for DNS security using GSS-API.
The security provided by this protocol is only as effective as the
security provided by the underlying GSS mechanisms.
Expires January 2000 [Page 12]
INTERNET-DRAFT GSS-TSIG June 1999
Expires August 2000 [Page 12]
INTERNET-DRAFT GSS-TSIG February 2000
7. Acknowledgements
@ -563,6 +688,7 @@ The authors of this document would like to thank the following people
for their contribution to this specification: Chuck Chan, Mike Swift,
Ram Viswanathan and Donald E. Eastlake 3rd.
8. References
[RFC2078] J. Linn, "Generic Security Service Application Program
@ -582,6 +708,7 @@ Ram Viswanathan and Donald E. Eastlake 3rd.
[RFC2137] D. Eastlake 3rd, "Secure Domain Name System Dynamic Update,"
RFC 2137, CyberCash, April 1997.
9. Author's Addresses
Stuart Kwan Praerit Garg
@ -597,3 +724,15 @@ One Microsoft Way
Redmond, WA 98052
USA
<jamesg@microsoft.com>
Expires August 2000 [Page 13]

78
doc/draft/draft-skwan-utf8-dns-02.txt → doc/draft/draft-skwan-utf8-dns-03.txt
View File

@ -1,11 +1,14 @@
INTERNET-DRAFT Stuart Kwan
James Gilroy
Microsoft Corp.
June 1999
<draft-skwan-utf8-dns-02.txt> Expires January 2000
February 2000
<draft-skwan-utf8-dns-03.txt> Expires August 2000
Using the UTF-8 Character Set in the Domain Name System
Status of this Memo
This document is an Internet-Draft and is in full conformance
@ -28,16 +31,29 @@ 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.
Abstract
The Domain Name System standard specifies that names are represented
using the ASCII character encoding. This document expands that
The Domain Name System standard specifies that names are represented
using the ASCII character encoding. This document expands that
specification to allow the use of the UTF-8 character encoding, a
superset of ASCII and a translation of the UCS-2 character encoding.
Expires January 2000 [Page 1]
INTERNET-DRAFT UTF-8 DNS June 1999
Expires August 2000 [Page 1]
INTERNET-DRAFT UTF-8 DNS February 2000
1. Introduction
@ -62,6 +78,7 @@ allowed in a name. In addition, names that are intended to be
globally visible [RFC1958] should contain ASCII-only characters
per [RFC1123].
2. Protocol Description
A UTF-8-aware DNS server is a DNS server that can load and store DNS
@ -86,9 +103,14 @@ and record data before transmitting those names in any message.
A UTF-8-aware DNS client/resolver must downcase all names containing
UTF-8 characters before transmitting those names in any message.
Expires January 2000 [Page 2]
INTERNET-DRAFT UTF-8 DNS June 1999
Expires August 2000 [Page 2]
INTERNET-DRAFT UTF-8 DNS February 2000
For consistency, UTF-8-aware DNS servers must compare names that
contain UTF-8 characters byte-for-byte, as opposed to using Unicode
@ -106,6 +128,7 @@ Names encoded in UTF-8 must not exceed the size limits clarified in
[RFC2181]. Character count is insufficient to determine size, since
some UTF-8 characters exceed one octet in length.
3. Interoperability Considerations
The UTF-8 character encoding is ideal for use with existing protocol
@ -125,10 +148,12 @@ names to a zone file or reload those names from a zone file.
Administrators should exercise caution when transferring a zone
containing UTF-8 names to a non-UTF-8-aware DNS server.
4. Security Considerations
The choice of character encoding for names does not impact the
security of the DNS protocol.
security of the DNS protocol.
5. Acknowledgements
@ -136,16 +161,20 @@ The authors of this document would like to thank the following people
for their contribution to this specification: John McConnell,
Cliff Van Dyke and Bjorn Rettig.
Expires January 2000 [Page 3]
INTERNET-DRAFT UTF-8 DNS June 1999
Expires August 2000 [Page 3]
INTERNET-DRAFT UTF-8 DNS February 2000
6. References
[RFC1035] P.V. Mockapetris, "Domain Names - Implementation and
Specification," RFC 1035, ISI, Nov 1987.
[RFC2044] F. Yergeau, "UTF-8, a transformation format of Unicode
[RFC2044] F. Yergeau, "UTF-8, a transformation format of Unicode
and ISO 10646," RFC 2044, Alis Technologies, Oct 1996.
[RFC1958] B. Carpenter, "Architectural Principles of the
@ -154,17 +183,18 @@ INTERNET-DRAFT UTF-8 DNS June 1999
[RFC1123] R. Braden, "Requirements for Internet Hosts -
Application and Support," STD 3, RFC 1123, January 1989.
[RFC2130] C. Weider et. al., "The Report of the IAB Character
[RFC2130] C. Weider et. al., "The Report of the IAB Character
Set Workshop held 29 February - 1 March 1996",
RFC 2130, Apr 1997.
[RFC2181] R. Elz and R. Bush, "Clarifications to the DNS
[RFC2181] R. Elz and R. Bush, "Clarifications to the DNS
Specification," RFC 2181, University of Melbourne and
RGnet Inc, July 1997.
[UNICODE 2.0] The Unicode Consortium, "The Unicode Standard, Version
2.0," Addison-Wesley, 1996. ISBN 0-201-48345-9.
7. Author's Addresses
Stuart Kwan James Gilroy
@ -174,4 +204,22 @@ Redmond, WA 98052 Redmond, WA 98052
USA USA
<skwan@microsoft.com> <jamesg@microsoft.com>
Expires January 2000 [Page 4]
Expires August 2000 [Page 4]