Compare commits
1 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
d763866a41 |
@@ -1,899 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group R. Hinden
|
||||
Request for Comments: 4193 Nokia
|
||||
Category: Standards Track B. Haberman
|
||||
JHU-APL
|
||||
October 2005
|
||||
|
||||
|
||||
Unique Local IPv6 Unicast Addresses
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2005).
|
||||
|
||||
Abstract
|
||||
|
||||
This document defines an IPv6 unicast address format that is globally
|
||||
unique and is intended for local communications, usually inside of a
|
||||
site. These addresses are not expected to be routable on the global
|
||||
Internet.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................2
|
||||
2. Acknowledgements ................................................3
|
||||
3. Local IPv6 Unicast Addresses ....................................3
|
||||
3.1. Format .....................................................3
|
||||
3.1.1. Background ..........................................4
|
||||
3.2. Global ID ..................................................4
|
||||
3.2.1. Locally Assigned Global IDs .........................5
|
||||
3.2.2. Sample Code for Pseudo-Random Global ID Algorithm ...5
|
||||
3.2.3. Analysis of the Uniqueness of Global IDs ............6
|
||||
3.3. Scope Definition ...........................................6
|
||||
4. Operational Guidelines ..........................................7
|
||||
4.1. Routing ....................................................7
|
||||
4.2. Renumbering and Site Merging ...............................7
|
||||
4.3. Site Border Router and Firewall Packet Filtering ...........8
|
||||
4.4. DNS Issues .................................................8
|
||||
4.5. Application and Higher Level Protocol Issues ...............9
|
||||
4.6. Use of Local IPv6 Addresses for Local Communication ........9
|
||||
4.7. Use of Local IPv6 Addresses with VPNs .....................10
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 1]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
5. Global Routing Considerations ..................................11
|
||||
5.1. From the Standpoint of the Internet .......................11
|
||||
5.2. From the Standpoint of a Site .............................11
|
||||
6. Advantages and Disadvantages ...................................12
|
||||
6.1. Advantages ................................................12
|
||||
6.2. Disadvantages .............................................13
|
||||
7. Security Considerations ........................................13
|
||||
8. IANA Considerations ............................................13
|
||||
9. References .....................................................13
|
||||
9.1. Normative References ......................................13
|
||||
9.2. Informative References ....................................14
|
||||
|
||||
1. Introduction
|
||||
|
||||
This document defines an IPv6 unicast address format that is globally
|
||||
unique and is intended for local communications [IPV6]. These
|
||||
addresses are called Unique Local IPv6 Unicast Addresses and are
|
||||
abbreviated in this document as Local IPv6 addresses. They are not
|
||||
expected to be routable on the global Internet. They are routable
|
||||
inside of a more limited area such as a site. They may also be
|
||||
routed between a limited set of sites.
|
||||
|
||||
Local IPv6 unicast addresses have the following characteristics:
|
||||
|
||||
- Globally unique prefix (with high probability of uniqueness).
|
||||
|
||||
- Well-known prefix to allow for easy filtering at site
|
||||
boundaries.
|
||||
|
||||
- Allow sites to be combined or privately interconnected without
|
||||
creating any address conflicts or requiring renumbering of
|
||||
interfaces that use these prefixes.
|
||||
|
||||
- Internet Service Provider independent and can be used for
|
||||
communications inside of a site without having any permanent or
|
||||
intermittent Internet connectivity.
|
||||
|
||||
- If accidentally leaked outside of a site via routing or DNS,
|
||||
there is no conflict with any other addresses.
|
||||
|
||||
- In practice, applications may treat these addresses like global
|
||||
scoped addresses.
|
||||
|
||||
This document defines the format of Local IPv6 addresses, how to
|
||||
allocate them, and usage considerations including routing, site
|
||||
border routers, DNS, application support, VPN usage, and guidelines
|
||||
for how to use for local communication inside a site.
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 2]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
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].
|
||||
|
||||
2. Acknowledgements
|
||||
|
||||
The underlying idea of creating Local IPv6 addresses described in
|
||||
this document has been proposed a number of times by a variety of
|
||||
people. The authors of this document do not claim exclusive credit.
|
||||
Credit goes to Brian Carpenter, Christian Huitema, Aidan Williams,
|
||||
Andrew White, Charlie Perkins, and many others. The authors would
|
||||
also like to thank Brian Carpenter, Charlie Perkins, Harald
|
||||
Alvestrand, Keith Moore, Margaret Wasserman, Shannon Behrens, Alan
|
||||
Beard, Hans Kruse, Geoff Huston, Pekka Savola, Christian Huitema, Tim
|
||||
Chown, Steve Bellovin, Alex Zinin, Tony Hain, Bill Fenner, Sam
|
||||
Hartman, and Elwyn Davies for their comments and suggestions on this
|
||||
document.
|
||||
|
||||
3. Local IPv6 Unicast Addresses
|
||||
|
||||
3.1. Format
|
||||
|
||||
The Local IPv6 addresses are created using a pseudo-randomly
|
||||
allocated global ID. They have the following format:
|
||||
|
||||
| 7 bits |1| 40 bits | 16 bits | 64 bits |
|
||||
+--------+-+------------+-----------+----------------------------+
|
||||
| Prefix |L| Global ID | Subnet ID | Interface ID |
|
||||
+--------+-+------------+-----------+----------------------------+
|
||||
|
||||
Where:
|
||||
|
||||
Prefix FC00::/7 prefix to identify Local IPv6 unicast
|
||||
addresses.
|
||||
|
||||
L Set to 1 if the prefix is locally assigned.
|
||||
Set to 0 may be defined in the future. See
|
||||
Section 3.2 for additional information.
|
||||
|
||||
Global ID 40-bit global identifier used to create a
|
||||
globally unique prefix. See Section 3.2 for
|
||||
additional information.
|
||||
|
||||
Subnet ID 16-bit Subnet ID is an identifier of a subnet
|
||||
within the site.
|
||||
|
||||
Interface ID 64-bit Interface ID as defined in [ADDARCH].
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 3]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
3.1.1. Background
|
||||
|
||||
There were a range of choices available when choosing the size of the
|
||||
prefix and Global ID field length. There is a direct tradeoff
|
||||
between having a Global ID field large enough to support foreseeable
|
||||
future growth and not using too much of the IPv6 address space
|
||||
needlessly. A reasonable way of evaluating a specific field length
|
||||
is to compare it to a projected 2050 world population of 9.3 billion
|
||||
[POPUL] and the number of resulting /48 prefixes per person. A range
|
||||
of prefix choices is shown in the following table:
|
||||
|
||||
Prefix Global ID Number of Prefixes % of IPv6
|
||||
Length /48 Prefixes per Person Address Space
|
||||
|
||||
/11 37 137,438,953,472 15 0.049%
|
||||
/10 38 274,877,906,944 30 0.098%
|
||||
/9 39 549,755,813,888 59 0.195%
|
||||
/8 40 1,099,511,627,776 118 0.391%
|
||||
/7 41 2,199,023,255,552 236 0.781%
|
||||
/6 42 4,398,046,511,104 473 1.563%
|
||||
|
||||
A very high utilization ratio of these allocations can be assumed
|
||||
because the Global ID field does not require internal structure, and
|
||||
there is no reason to be able to aggregate the prefixes.
|
||||
|
||||
The authors believe that a /7 prefix resulting in a 41-bit Global ID
|
||||
space (including the L bit) is a good choice. It provides for a
|
||||
large number of assignments (i.e., 2.2 trillion) and at the same time
|
||||
uses less than .8% of the total IPv6 address space. It is unlikely
|
||||
that this space will be exhausted. If more than this were to be
|
||||
needed, then additional IPv6 address space could be allocated for
|
||||
this purpose.
|
||||
|
||||
3.2. Global ID
|
||||
|
||||
The allocation of Global IDs is pseudo-random [RANDOM]. They MUST
|
||||
NOT be assigned sequentially or with well-known numbers. This is to
|
||||
ensure that there is not any relationship between allocations and to
|
||||
help clarify that these prefixes are not intended to be routed
|
||||
globally. Specifically, these prefixes are not designed to
|
||||
aggregate.
|
||||
|
||||
This document defines a specific local method to allocate Global IDs,
|
||||
indicated by setting the L bit to 1. Another method, indicated by
|
||||
clearing the L bit, may be defined later. Apart from the allocation
|
||||
method, all Local IPv6 addresses behave and are treated identically.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 4]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
The local assignments are self-generated and do not need any central
|
||||
coordination or assignment, but have an extremely high probability of
|
||||
being unique.
|
||||
|
||||
3.2.1. Locally Assigned Global IDs
|
||||
|
||||
Locally assigned Global IDs MUST be generated with a pseudo-random
|
||||
algorithm consistent with [RANDOM]. Section 3.2.2 describes a
|
||||
suggested algorithm. It is important that all sites generating
|
||||
Global IDs use a functionally similar algorithm to ensure there is a
|
||||
high probability of uniqueness.
|
||||
|
||||
The use of a pseudo-random algorithm to generate Global IDs in the
|
||||
locally assigned prefix gives an assurance that any network numbered
|
||||
using such a prefix is highly unlikely to have that address space
|
||||
clash with any other network that has another locally assigned prefix
|
||||
allocated to it. This is a particularly useful property when
|
||||
considering a number of scenarios including networks that merge,
|
||||
overlapping VPN address space, or hosts mobile between such networks.
|
||||
|
||||
3.2.2. Sample Code for Pseudo-Random Global ID Algorithm
|
||||
|
||||
The algorithm described below is intended to be used for locally
|
||||
assigned Global IDs. In each case the resulting global ID will be
|
||||
used in the appropriate prefix as defined in Section 3.2.
|
||||
|
||||
1) Obtain the current time of day in 64-bit NTP format [NTP].
|
||||
|
||||
2) Obtain an EUI-64 identifier from the system running this
|
||||
algorithm. If an EUI-64 does not exist, one can be created from
|
||||
a 48-bit MAC address as specified in [ADDARCH]. If an EUI-64
|
||||
cannot be obtained or created, a suitably unique identifier,
|
||||
local to the node, should be used (e.g., system serial number).
|
||||
|
||||
3) Concatenate the time of day with the system-specific identifier
|
||||
in order to create a key.
|
||||
|
||||
4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1];
|
||||
the resulting value is 160 bits.
|
||||
|
||||
5) Use the least significant 40 bits as the Global ID.
|
||||
|
||||
6) Concatenate FC00::/7, the L bit set to 1, and the 40-bit Global
|
||||
ID to create a Local IPv6 address prefix.
|
||||
|
||||
This algorithm will result in a Global ID that is reasonably unique
|
||||
and can be used to create a locally assigned Local IPv6 address
|
||||
prefix.
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 5]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
3.2.3. Analysis of the Uniqueness of Global IDs
|
||||
|
||||
The selection of a pseudo random Global ID is similar to the
|
||||
selection of an SSRC identifier in RTP/RTCP defined in Section 8.1 of
|
||||
[RTP]. This analysis is adapted from that document.
|
||||
|
||||
Since Global IDs are chosen randomly (and independently), it is
|
||||
possible that separate networks have chosen the same Global ID. For
|
||||
any given network, with one or more random Global IDs, that has
|
||||
inter-connections to other such networks, having a total of N such
|
||||
IDs, the probability that two or more of these IDs will collide can
|
||||
be approximated using the formula:
|
||||
|
||||
P = 1 - exp(-N**2 / 2**(L+1))
|
||||
|
||||
where P is the probability of collision, N is the number of
|
||||
interconnected Global IDs, and L is the length of the Global ID.
|
||||
|
||||
The following table shows the probability of a collision for a range
|
||||
of connections using a 40-bit Global ID field.
|
||||
|
||||
Connections Probability of Collision
|
||||
|
||||
2 1.81*10^-12
|
||||
10 4.54*10^-11
|
||||
100 4.54*10^-09
|
||||
1000 4.54*10^-07
|
||||
10000 4.54*10^-05
|
||||
|
||||
Based on this analysis, the uniqueness of locally generated Global
|
||||
IDs is adequate for sites planning a small to moderate amount of
|
||||
inter-site communication using locally generated Global IDs.
|
||||
|
||||
3.3. Scope Definition
|
||||
|
||||
By default, the scope of these addresses is global. That is, they
|
||||
are not limited by ambiguity like the site-local addresses defined in
|
||||
[ADDARCH]. Rather, these prefixes are globally unique, and as such,
|
||||
their applicability is greater than site-local addresses. Their
|
||||
limitation is in the routability of the prefixes, which is limited to
|
||||
a site and any explicit routing agreements with other sites to
|
||||
propagate them (also see Section 4.1). Also, unlike site-locals, a
|
||||
site may have more than one of these prefixes and use them at the
|
||||
same time.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 6]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
4. Operational Guidelines
|
||||
|
||||
The guidelines in this section do not require any change to the
|
||||
normal routing and forwarding functionality in an IPv6 host or
|
||||
router. These are configuration and operational usage guidelines.
|
||||
|
||||
4.1. Routing
|
||||
|
||||
Local IPv6 addresses are designed to be routed inside of a site in
|
||||
the same manner as other types of unicast addresses. They can be
|
||||
carried in any IPv6 routing protocol without any change.
|
||||
|
||||
It is expected that they would share the same Subnet IDs with
|
||||
provider-based global unicast addresses, if they were being used
|
||||
concurrently [GLOBAL].
|
||||
|
||||
The default behavior of exterior routing protocol sessions between
|
||||
administrative routing regions must be to ignore receipt of and not
|
||||
advertise prefixes in the FC00::/7 block. A network operator may
|
||||
specifically configure prefixes longer than FC00::/7 for inter-site
|
||||
communication.
|
||||
|
||||
If BGP is being used at the site border with an ISP, the default BGP
|
||||
configuration must filter out any Local IPv6 address prefixes, both
|
||||
incoming and outgoing. It must be set both to keep any Local IPv6
|
||||
address prefixes from being advertised outside of the site as well as
|
||||
to keep these prefixes from being learned from another site. The
|
||||
exception to this is if there are specific /48 or longer routes
|
||||
created for one or more Local IPv6 prefixes.
|
||||
|
||||
For link-state IGPs, it is suggested that a site utilizing IPv6 local
|
||||
address prefixes be contained within one IGP domain or area. By
|
||||
containing an IPv6 local address prefix to a single link-state area
|
||||
or domain, the distribution of prefixes can be controlled.
|
||||
|
||||
4.2. Renumbering and Site Merging
|
||||
|
||||
The use of Local IPv6 addresses in a site results in making
|
||||
communication that uses these addresses independent of renumbering a
|
||||
site's provider-based global addresses.
|
||||
|
||||
When merging multiple sites, the addresses created with these
|
||||
prefixes are unlikely to need to be renumbered because all of the
|
||||
addresses have a high probability of being unique. Routes for each
|
||||
specific prefix would have to be configured to allow routing to work
|
||||
correctly between the formerly separate sites.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 7]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
4.3. Site Border Router and Firewall Packet Filtering
|
||||
|
||||
While no serious harm will be done if packets with these addresses
|
||||
are sent outside of a site via a default route, it is recommended
|
||||
that routers be configured by default to keep any packets with Local
|
||||
IPv6 addresses from leaking outside of the site and to keep any site
|
||||
prefixes from being advertised outside of their site.
|
||||
|
||||
Site border routers and firewalls should be configured to not forward
|
||||
any packets with Local IPv6 source or destination addresses outside
|
||||
of the site, unless they have been explicitly configured with routing
|
||||
information about specific /48 or longer Local IPv6 prefixes. This
|
||||
will ensure that packets with Local IPv6 destination addresses will
|
||||
not be forwarded outside of the site via a default route. The
|
||||
default behavior of these devices should be to install a "reject"
|
||||
route for these prefixes. Site border routers should respond with
|
||||
the appropriate ICMPv6 Destination Unreachable message to inform the
|
||||
source that the packet was not forwarded. [ICMPV6]. This feedback is
|
||||
important to avoid transport protocol timeouts.
|
||||
|
||||
Routers that maintain peering arrangements between Autonomous Systems
|
||||
throughout the Internet should obey the recommendations for site
|
||||
border routers, unless configured otherwise.
|
||||
|
||||
4.4. DNS Issues
|
||||
|
||||
At the present time, AAAA and PTR records for locally assigned local
|
||||
IPv6 addresses are not recommended to be installed in the global DNS.
|
||||
|
||||
For background on this recommendation, one of the concerns about
|
||||
adding AAAA and PTR records to the global DNS for locally assigned
|
||||
Local IPv6 addresses stems from the lack of complete assurance that
|
||||
the prefixes are unique. There is a small possibility that the same
|
||||
locally assigned IPv6 Local addresses will be used by two different
|
||||
organizations both claiming to be authoritative with different
|
||||
contents. In this scenario, it is likely there will be a connection
|
||||
attempt to the closest host with the corresponding locally assigned
|
||||
IPv6 Local address. This may result in connection timeouts,
|
||||
connection failures indicated by ICMP Destination Unreachable
|
||||
messages, or successful connections to the wrong host. Due to this
|
||||
concern, adding AAAA records for these addresses to the global DNS is
|
||||
thought to be unwise.
|
||||
|
||||
Reverse (address-to-name) queries for locally assigned IPv6 Local
|
||||
addresses MUST NOT be sent to name servers for the global DNS, due to
|
||||
the load that such queries would create for the authoritative name
|
||||
servers for the ip6.arpa zone. This form of query load is not
|
||||
specific to locally assigned Local IPv6 addresses; any current form
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 8]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
of local addressing creates additional load of this kind, due to
|
||||
reverse queries leaking out of the site. However, since allowing
|
||||
such queries to escape from the site serves no useful purpose, there
|
||||
is no good reason to make the existing load problems worse.
|
||||
|
||||
The recommended way to avoid sending such queries to nameservers for
|
||||
the global DNS is for recursive name server implementations to act as
|
||||
if they were authoritative for an empty d.f.ip6.arpa zone and return
|
||||
RCODE 3 for any such query. Implementations that choose this
|
||||
strategy should allow it to be overridden, but returning an RCODE 3
|
||||
response for such queries should be the default, both because this
|
||||
will reduce the query load problem and also because, if the site
|
||||
administrator has not set up the reverse tree corresponding to the
|
||||
locally assigned IPv6 Local addresses in use, returning RCODE 3 is in
|
||||
fact the correct answer.
|
||||
|
||||
4.5. Application and Higher Level Protocol Issues
|
||||
|
||||
Application and other higher level protocols can treat Local IPv6
|
||||
addresses in the same manner as other types of global unicast
|
||||
addresses. No special handling is required. This type of address
|
||||
may not be reachable, but that is no different from other types of
|
||||
IPv6 global unicast address. Applications need to be able to handle
|
||||
multiple addresses that may or may not be reachable at any point in
|
||||
time. In most cases, this complexity should be hidden in APIs.
|
||||
|
||||
From a host's perspective, the difference between Local IPv6 and
|
||||
other types of global unicast addresses shows up as different
|
||||
reachability and could be handled by default in that way. In some
|
||||
cases, it is better for nodes and applications to treat them
|
||||
differently from global unicast addresses. A starting point might be
|
||||
to give them preference over global unicast, but fall back to global
|
||||
unicast if a particular destination is found to be unreachable. Much
|
||||
of this behavior can be controlled by how they are allocated to nodes
|
||||
and put into the DNS. However, it is useful if a host can have both
|
||||
types of addresses and use them appropriately.
|
||||
|
||||
Note that the address selection mechanisms of [ADDSEL], and in
|
||||
particular the policy override mechanism replacing default address
|
||||
selection, are expected to be used on a site where Local IPv6
|
||||
addresses are configured.
|
||||
|
||||
4.6. Use of Local IPv6 Addresses for Local Communication
|
||||
|
||||
Local IPv6 addresses, like global scope unicast addresses, are only
|
||||
assigned to nodes if their use has been enabled (via IPv6 address
|
||||
autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually). They are
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 9]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
not created automatically in the way that IPv6 link-local addresses
|
||||
are and will not appear or be used unless they are purposely
|
||||
configured.
|
||||
|
||||
In order for hosts to autoconfigure Local IPv6 addresses, routers
|
||||
have to be configured to advertise Local IPv6 /64 prefixes in router
|
||||
advertisements, or a DHCPv6 server must have been configured to
|
||||
assign them. In order for a node to learn the Local IPv6 address of
|
||||
another node, the Local IPv6 address must have been installed in a
|
||||
naming system (e.g., DNS, proprietary naming system, etc.) For these
|
||||
reasons, controlling their usage in a site is straightforward.
|
||||
|
||||
To limit the use of Local IPv6 addresses the following guidelines
|
||||
apply:
|
||||
|
||||
- Nodes that are to only be reachable inside of a site: The local
|
||||
DNS should be configured to only include the Local IPv6
|
||||
addresses of these nodes. Nodes with only Local IPv6 addresses
|
||||
must not be installed in the global DNS.
|
||||
|
||||
- Nodes that are to be limited to only communicate with other
|
||||
nodes in the site: These nodes should be set to only
|
||||
autoconfigure Local IPv6 addresses via [ADDAUTO] or to only
|
||||
receive Local IPv6 addresses via [DHCP6]. Note: For the case
|
||||
where both global and Local IPv6 prefixes are being advertised
|
||||
on a subnet, this will require a switch in the devices to only
|
||||
autoconfigure Local IPv6 addresses.
|
||||
|
||||
- Nodes that are to be reachable from inside of the site and from
|
||||
outside of the site: The DNS should be configured to include
|
||||
the global addresses of these nodes. The local DNS may be
|
||||
configured to also include the Local IPv6 addresses of these
|
||||
nodes.
|
||||
|
||||
- Nodes that can communicate with other nodes inside of the site
|
||||
and outside of the site: These nodes should autoconfigure global
|
||||
addresses via [ADDAUTO] or receive global address via [DHCP6].
|
||||
They may also obtain Local IPv6 addresses via the same
|
||||
mechanisms.
|
||||
|
||||
4.7. Use of Local IPv6 Addresses with VPNs
|
||||
|
||||
Local IPv6 addresses can be used for inter-site Virtual Private
|
||||
Networks (VPN) if appropriate routes are set up. Because the
|
||||
addresses are unique, these VPNs will work reliably and without the
|
||||
need for translation. They have the additional property that they
|
||||
will continue to work if the individual sites are renumbered or
|
||||
merged.
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 10]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
5. Global Routing Considerations
|
||||
|
||||
Section 4.1 provides operational guidelines that forbid default
|
||||
routing of local addresses between sites. Concerns were raised to
|
||||
the IPv6 working group and to the IETF as a whole that sites may
|
||||
attempt to use local addresses as globally routed provider-
|
||||
independent addresses. This section describes why using local
|
||||
addresses as globally-routed provider-independent addresses is
|
||||
unadvisable.
|
||||
|
||||
5.1. From the Standpoint of the Internet
|
||||
|
||||
There is a mismatch between the structure of IPv6 local addresses and
|
||||
the normal IPv6 wide area routing model. The /48 prefix of an IPv6
|
||||
local addresses fits nowhere in the normal hierarchy of IPv6 unicast
|
||||
addresses. Normal IPv6 unicast addresses can be routed
|
||||
hierarchically down to physical subnet (link) level and only have to
|
||||
be flat-routed on the physical subnet. IPv6 local addresses would
|
||||
have to be flat-routed even over the wide area Internet.
|
||||
|
||||
Thus, packets whose destination address is an IPv6 local address
|
||||
could be routed over the wide area only if the corresponding /48
|
||||
prefix were carried by the wide area routing protocol in use, such as
|
||||
BGP. This contravenes the operational assumption that long prefixes
|
||||
will be aggregated into many fewer short prefixes, to limit the table
|
||||
size and convergence time of the routing protocol. If a network uses
|
||||
both normal IPv6 addresses [ADDARCH] and IPv6 local addresses, these
|
||||
types of addresses will certainly not aggregate with each other,
|
||||
since they differ from the most significant bit onwards. Neither
|
||||
will IPv6 local addresses aggregate with each other, due to their
|
||||
random bit patterns. This means that there would be a very
|
||||
significant operational penalty for attempting to use IPv6 local
|
||||
address prefixes generically with currently known wide area routing
|
||||
technology.
|
||||
|
||||
5.2. From the Standpoint of a Site
|
||||
|
||||
There are a number of design factors in IPv6 local addresses that
|
||||
reduce the likelihood that IPv6 local addresses will be used as
|
||||
arbitrary global unicast addresses. These include:
|
||||
|
||||
- The default rules to filter packets and routes make it very
|
||||
difficult to use IPv6 local addresses for arbitrary use across
|
||||
the Internet. For a site to use them as general purpose unicast
|
||||
addresses, it would have to make sure that the default rules
|
||||
were not being used by all other sites and intermediate ISPs
|
||||
used for their current and future communication.
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 11]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
- They are not mathematically guaranteed to be unique and are not
|
||||
registered in public databases. Collisions, while highly
|
||||
unlikely, are possible and a collision can compromise the
|
||||
integrity of the communications. The lack of public
|
||||
registration creates operational problems.
|
||||
|
||||
- The addresses are allocated randomly. If a site had multiple
|
||||
prefixes that it wanted to be used globally, the cost of
|
||||
advertising them would be very high because they could not be
|
||||
aggregated.
|
||||
|
||||
- They have a long prefix (i.e., /48) so a single local address
|
||||
prefix doesn't provide enough address space to be used
|
||||
exclusively by the largest organizations.
|
||||
|
||||
6. Advantages and Disadvantages
|
||||
|
||||
6.1. Advantages
|
||||
|
||||
This approach has the following advantages:
|
||||
|
||||
- Provides Local IPv6 prefixes that can be used independently of
|
||||
any provider-based IPv6 unicast address allocations. This is
|
||||
useful for sites not always connected to the Internet or sites
|
||||
that wish to have a distinct prefix that can be used to localize
|
||||
traffic inside of the site.
|
||||
|
||||
- Applications can treat these addresses in an identical manner as
|
||||
any other type of global IPv6 unicast addresses.
|
||||
|
||||
- Sites can be merged without any renumbering of the Local IPv6
|
||||
addresses.
|
||||
|
||||
- Sites can change their provider-based IPv6 unicast address
|
||||
without disrupting any communication that uses Local IPv6
|
||||
addresses.
|
||||
|
||||
- Well-known prefix that allows for easy filtering at site
|
||||
boundary.
|
||||
|
||||
- Can be used for inter-site VPNs.
|
||||
|
||||
- If accidently leaked outside of a site via routing or DNS, there
|
||||
is no conflict with any other addresses.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 12]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
6.2. Disadvantages
|
||||
|
||||
This approach has the following disadvantages:
|
||||
|
||||
- Not possible to route Local IPv6 prefixes on the global Internet
|
||||
with current routing technology. Consequentially, it is
|
||||
necessary to have the default behavior of site border routers to
|
||||
filter these addresses.
|
||||
|
||||
- There is a very low probability of non-unique locally assigned
|
||||
Global IDs being generated by the algorithm in Section 3.2.3.
|
||||
This risk can be ignored for all practical purposes, but it
|
||||
leads to a theoretical risk of clashing address prefixes.
|
||||
|
||||
7. Security Considerations
|
||||
|
||||
Local IPv6 addresses do not provide any inherent security to the
|
||||
nodes that use them. They may be used with filters at site
|
||||
boundaries to keep Local IPv6 traffic inside of the site, but this is
|
||||
no more or less secure than filtering any other type of global IPv6
|
||||
unicast addresses.
|
||||
|
||||
Local IPv6 addresses do allow for address-based security mechanisms,
|
||||
including IPsec, across end to end VPN connections.
|
||||
|
||||
8. IANA Considerations
|
||||
|
||||
The IANA has assigned the FC00::/7 prefix to "Unique Local Unicast".
|
||||
|
||||
9. References
|
||||
|
||||
9.1. Normative References
|
||||
|
||||
[ADDARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6
|
||||
(IPv6) Addressing Architecture", RFC 3513, April 2003.
|
||||
|
||||
[FIPS] "Federal Information Processing Standards Publication",
|
||||
(FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
|
||||
|
||||
[GLOBAL] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
|
||||
Unicast Address Format", RFC 3587, August 2003.
|
||||
|
||||
[ICMPV6] Conta, A. and S. Deering, "Internet Control Message
|
||||
Protocol (ICMPv6) for the Internet Protocol Version 6
|
||||
(IPv6) Specification", RFC 2463, December 1998.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 13]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
|
||||
(IPv6) Specification", RFC 2460, December 1998.
|
||||
|
||||
[NTP] Mills, D., "Network Time Protocol (Version 3)
|
||||
Specification, Implementation and Analysis", RFC 1305,
|
||||
March 1992.
|
||||
|
||||
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
|
||||
"Randomness Requirements for Security", BCP 106, RFC 4086,
|
||||
June 2005.
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[SHA1] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
|
||||
(SHA1)", RFC 3174, September 2001.
|
||||
|
||||
9.2. Informative References
|
||||
|
||||
[ADDAUTO] Thomson, S. and T. Narten, "IPv6 Stateless Address
|
||||
Autoconfiguration", RFC 2462, December 1998.
|
||||
|
||||
[ADDSEL] Draves, R., "Default Address Selection for Internet
|
||||
Protocol version 6 (IPv6)", RFC 3484, February 2003.
|
||||
|
||||
[DHCP6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and
|
||||
M. Carney, "Dynamic Host Configuration Protocol for IPv6
|
||||
(DHCPv6)", RFC 3315, July 2003.
|
||||
|
||||
[POPUL] Population Reference Bureau, "World Population Data Sheet
|
||||
of the Population Reference Bureau 2002", August 2002.
|
||||
|
||||
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V.
|
||||
Jacobson, "RTP: A Transport Protocol for Real-Time
|
||||
Applications", STD 64, RFC 3550, July 2003.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 14]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Robert M. Hinden
|
||||
Nokia
|
||||
313 Fairchild Drive
|
||||
Mountain View, CA 94043
|
||||
USA
|
||||
|
||||
Phone: +1 650 625-2004
|
||||
EMail: bob.hinden@nokia.com
|
||||
|
||||
|
||||
Brian Haberman
|
||||
Johns Hopkins University
|
||||
Applied Physics Lab
|
||||
11100 Johns Hopkins Road
|
||||
Laurel, MD 20723
|
||||
USA
|
||||
|
||||
Phone: +1 443 778 1319
|
||||
EMail: brian@innovationslab.net
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 15]
|
||||
|
||||
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2005).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at ietf-
|
||||
ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hinden & Haberman Standards Track [Page 16]
|
||||
|
||||
@@ -1,507 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group J. Schlyter
|
||||
Request for Comments: 4255 OpenSSH
|
||||
Category: Standards Track W. Griffin
|
||||
SPARTA
|
||||
January 2006
|
||||
|
||||
|
||||
Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes a method of verifying Secure Shell (SSH) host
|
||||
keys using Domain Name System Security (DNSSEC). The document
|
||||
defines a new DNS resource record that contains a standard SSH key
|
||||
fingerprint.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................2
|
||||
2. SSH Host Key Verification .......................................2
|
||||
2.1. Method .....................................................2
|
||||
2.2. Implementation Notes .......................................2
|
||||
2.3. Fingerprint Matching .......................................3
|
||||
2.4. Authentication .............................................3
|
||||
3. The SSHFP Resource Record .......................................3
|
||||
3.1. The SSHFP RDATA Format .....................................4
|
||||
3.1.1. Algorithm Number Specification ......................4
|
||||
3.1.2. Fingerprint Type Specification ......................4
|
||||
3.1.3. Fingerprint .........................................5
|
||||
3.2. Presentation Format of the SSHFP RR ........................5
|
||||
4. Security Considerations .........................................5
|
||||
5. IANA Considerations .............................................6
|
||||
6. Normative References ............................................7
|
||||
7. Informational References ........................................7
|
||||
8. Acknowledgements ................................................8
|
||||
|
||||
|
||||
|
||||
|
||||
Schlyter & Griffin Standards Track [Page 1]
|
||||
|
||||
RFC 4255 DNS and SSH Fingerprints January 2006
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
The SSH [6] protocol provides secure remote login and other secure
|
||||
network services over an insecure network. The security of the
|
||||
connection relies on the server authenticating itself to the client
|
||||
as well as the user authenticating itself to the server.
|
||||
|
||||
If a connection is established to a server whose public key is not
|
||||
already known to the client, a fingerprint of the key is presented to
|
||||
the user for verification. If the user decides that the fingerprint
|
||||
is correct and accepts the key, the key is saved locally and used for
|
||||
verification for all following connections. While some security-
|
||||
conscious users verify the fingerprint out-of-band before accepting
|
||||
the key, many users blindly accept the presented key.
|
||||
|
||||
The method described here can provide out-of-band verification by
|
||||
looking up a fingerprint of the server public key in the DNS [1][2]
|
||||
and using DNSSEC [5] to verify the lookup.
|
||||
|
||||
In order to distribute the fingerprint using DNS, this document
|
||||
defines a new DNS resource record, "SSHFP", to carry the fingerprint.
|
||||
|
||||
Basic understanding of the DNS system [1][2] and the DNS security
|
||||
extensions [5] is assumed by this document.
|
||||
|
||||
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 RFC 2119 [3].
|
||||
|
||||
2. SSH Host Key Verification
|
||||
|
||||
2.1. Method
|
||||
|
||||
Upon connection to an SSH server, the SSH client MAY look up the
|
||||
SSHFP resource record(s) for the host it is connecting to. If the
|
||||
algorithm and fingerprint of the key received from the SSH server
|
||||
match the algorithm and fingerprint of one of the SSHFP resource
|
||||
record(s) returned from DNS, the client MAY accept the identity of
|
||||
the server.
|
||||
|
||||
2.2. Implementation Notes
|
||||
|
||||
Client implementors SHOULD provide a configurable policy used to
|
||||
select the order of methods used to verify a host key. This document
|
||||
defines one method: Fingerprint storage in DNS. Another method
|
||||
defined in the SSH Architecture [6] uses local files to store keys
|
||||
for comparison. Other methods that could be defined in the future
|
||||
might include storing fingerprints in LDAP or other databases. A
|
||||
|
||||
|
||||
|
||||
Schlyter & Griffin Standards Track [Page 2]
|
||||
|
||||
RFC 4255 DNS and SSH Fingerprints January 2006
|
||||
|
||||
|
||||
configurable policy will allow administrators to determine which
|
||||
methods they want to use and in what order the methods should be
|
||||
prioritized. This will allow administrators to determine how much
|
||||
trust they want to place in the different methods.
|
||||
|
||||
One specific scenario for having a configurable policy is where
|
||||
clients do not use fully qualified host names to connect to servers.
|
||||
In this scenario, the implementation SHOULD verify the host key
|
||||
against a local database before verifying the key via the fingerprint
|
||||
returned from DNS. This would help prevent an attacker from
|
||||
injecting a DNS search path into the local resolver and forcing the
|
||||
client to connect to a different host.
|
||||
|
||||
2.3. Fingerprint Matching
|
||||
|
||||
The public key and the SSHFP resource record are matched together by
|
||||
comparing algorithm number and fingerprint.
|
||||
|
||||
The public key algorithm and the SSHFP algorithm number MUST
|
||||
match.
|
||||
|
||||
A message digest of the public key, using the message digest
|
||||
algorithm specified in the SSHFP fingerprint type, MUST match the
|
||||
SSHFP fingerprint.
|
||||
|
||||
2.4. Authentication
|
||||
|
||||
A public key verified using this method MUST NOT be trusted if the
|
||||
SSHFP resource record (RR) used for verification was not
|
||||
authenticated by a trusted SIG RR.
|
||||
|
||||
Clients that do validate the DNSSEC signatures themselves SHOULD use
|
||||
standard DNSSEC validation procedures.
|
||||
|
||||
Clients that do not validate the DNSSEC signatures themselves MUST
|
||||
use a secure transport (e.g., TSIG [9], SIG(0) [10], or IPsec [8])
|
||||
between themselves and the entity performing the signature
|
||||
validation.
|
||||
|
||||
3. The SSHFP Resource Record
|
||||
|
||||
The SSHFP resource record (RR) is used to store a fingerprint of an
|
||||
SSH public host key that is associated with a Domain Name System
|
||||
(DNS) name.
|
||||
|
||||
The RR type code for the SSHFP RR is 44.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schlyter & Griffin Standards Track [Page 3]
|
||||
|
||||
RFC 4255 DNS and SSH Fingerprints January 2006
|
||||
|
||||
|
||||
3.1. The SSHFP RDATA Format
|
||||
|
||||
The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
|
||||
type and the fingerprint of the public host key.
|
||||
|
||||
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
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| algorithm | fp type | /
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
|
||||
/ /
|
||||
/ fingerprint /
|
||||
/ /
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|
||||
3.1.1. Algorithm Number Specification
|
||||
|
||||
This algorithm number octet describes the algorithm of the public
|
||||
key. The following values are assigned:
|
||||
|
||||
Value Algorithm name
|
||||
----- --------------
|
||||
0 reserved
|
||||
1 RSA
|
||||
2 DSS
|
||||
|
||||
Reserving other types requires IETF consensus [4].
|
||||
|
||||
3.1.2. Fingerprint Type Specification
|
||||
|
||||
The fingerprint type octet describes the message-digest algorithm
|
||||
used to calculate the fingerprint of the public key. The following
|
||||
values are assigned:
|
||||
|
||||
Value Fingerprint type
|
||||
----- ----------------
|
||||
0 reserved
|
||||
1 SHA-1
|
||||
|
||||
Reserving other types requires IETF consensus [4].
|
||||
|
||||
For interoperability reasons, as few fingerprint types as possible
|
||||
should be reserved. The only reason to reserve additional types is
|
||||
to increase security.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schlyter & Griffin Standards Track [Page 4]
|
||||
|
||||
RFC 4255 DNS and SSH Fingerprints January 2006
|
||||
|
||||
|
||||
3.1.3. Fingerprint
|
||||
|
||||
The fingerprint is calculated over the public key blob as described
|
||||
in [7].
|
||||
|
||||
The message-digest algorithm is presumed to produce an opaque octet
|
||||
string output, which is placed as-is in the RDATA fingerprint field.
|
||||
|
||||
3.2. Presentation Format of the SSHFP RR
|
||||
|
||||
The RDATA of the presentation format of the SSHFP resource record
|
||||
consists of two numbers (algorithm and fingerprint type) followed by
|
||||
the fingerprint itself, presented in hex, e.g.:
|
||||
|
||||
host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890
|
||||
|
||||
The use of mnemonics instead of numbers is not allowed.
|
||||
|
||||
4. Security Considerations
|
||||
|
||||
Currently, the amount of trust a user can realistically place in a
|
||||
server key is proportional to the amount of attention paid to
|
||||
verifying that the public key presented actually corresponds to the
|
||||
private key of the server. If a user accepts a key without verifying
|
||||
the fingerprint with something learned through a secured channel, the
|
||||
connection is vulnerable to a man-in-the-middle attack.
|
||||
|
||||
The overall security of using SSHFP for SSH host key verification is
|
||||
dependent on the security policies of the SSH host administrator and
|
||||
DNS zone administrator (in transferring the fingerprint), detailed
|
||||
aspects of how verification is done in the SSH implementation, and in
|
||||
the client's diligence in accessing the DNS in a secure manner.
|
||||
|
||||
One such aspect is in which order fingerprints are looked up (e.g.,
|
||||
first checking local file and then SSHFP). We note that, in addition
|
||||
to protecting the first-time transfer of host keys, SSHFP can
|
||||
optionally be used for stronger host key protection.
|
||||
|
||||
If SSHFP is checked first, new SSH host keys may be distributed by
|
||||
replacing the corresponding SSHFP in DNS.
|
||||
|
||||
If SSH host key verification can be configured to require SSHFP,
|
||||
SSH host key revocation can be implemented by removing the
|
||||
corresponding SSHFP from DNS.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schlyter & Griffin Standards Track [Page 5]
|
||||
|
||||
RFC 4255 DNS and SSH Fingerprints January 2006
|
||||
|
||||
|
||||
As stated in Section 2.2, we recommend that SSH implementors provide
|
||||
a policy mechanism to control the order of methods used for host key
|
||||
verification. One specific scenario for having a configurable policy
|
||||
is where clients use unqualified host names to connect to servers.
|
||||
In this case, we recommend that SSH implementations check the host
|
||||
key against a local database before verifying the key via the
|
||||
fingerprint returned from DNS. This would help prevent an attacker
|
||||
from injecting a DNS search path into the local resolver and forcing
|
||||
the client to connect to a different host.
|
||||
|
||||
A different approach to solve the DNS search path issue would be for
|
||||
clients to use a trusted DNS search path, i.e., one not acquired
|
||||
through DHCP or other autoconfiguration mechanisms. Since there is
|
||||
no way with current DNS lookup APIs to tell whether a search path is
|
||||
from a trusted source, the entire client system would need to be
|
||||
configured with this trusted DNS search path.
|
||||
|
||||
Another dependency is on the implementation of DNSSEC itself. As
|
||||
stated in Section 2.4, we mandate the use of secure methods for
|
||||
lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This
|
||||
is especially important if SSHFP is to be used as a basis for host
|
||||
key rollover and/or revocation, as described above.
|
||||
|
||||
Since DNSSEC only protects the integrity of the host key fingerprint
|
||||
after it is signed by the DNS zone administrator, the fingerprint
|
||||
must be transferred securely from the SSH host administrator to the
|
||||
DNS zone administrator. This could be done manually between the
|
||||
administrators or automatically using secure DNS dynamic update [11]
|
||||
between the SSH server and the nameserver. We note that this is no
|
||||
different from other key enrollment situations, e.g., a client
|
||||
sending a certificate request to a certificate authority for signing.
|
||||
|
||||
5. IANA Considerations
|
||||
|
||||
IANA has allocated the RR type code 44 for SSHFP from the standard RR
|
||||
type space.
|
||||
|
||||
IANA has opened a new registry for the SSHFP RR type for public key
|
||||
algorithms. The defined types are:
|
||||
|
||||
0 is reserved
|
||||
1 is RSA
|
||||
2 is DSA
|
||||
|
||||
Adding new reservations requires IETF consensus [4].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schlyter & Griffin Standards Track [Page 6]
|
||||
|
||||
RFC 4255 DNS and SSH Fingerprints January 2006
|
||||
|
||||
|
||||
IANA has opened a new registry for the SSHFP RR type for fingerprint
|
||||
types. The defined types are:
|
||||
|
||||
0 is reserved
|
||||
1 is SHA-1
|
||||
|
||||
Adding new reservations requires IETF consensus [4].
|
||||
|
||||
6. Normative References
|
||||
|
||||
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
|
||||
13, RFC 1034, November 1987.
|
||||
|
||||
[2] Mockapetris, P., "Domain names - implementation and
|
||||
specification", STD 13, RFC 1035, November 1987.
|
||||
|
||||
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
||||
Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
|
||||
Considerations Section in RFCs", BCP 26, RFC 2434, October
|
||||
1998.
|
||||
|
||||
[5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"DNS Security Introduction and Requirements", RFC 4033, March
|
||||
2005.
|
||||
|
||||
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"Resource Records for the DNS Security Extensions", RFC 4034,
|
||||
March 2005.
|
||||
|
||||
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"Protocol Modifications for the DNS Security Extensions", RFC
|
||||
4035, March 2005.
|
||||
|
||||
[6] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
|
||||
Protocol Architecture", RFC 4251, January 2006.
|
||||
|
||||
[7] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
|
||||
Transport Layer Protocol", RFC 4253, January 2006.
|
||||
|
||||
7. Informational References
|
||||
|
||||
[8] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document
|
||||
Roadmap", RFC 2411, November 1998.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schlyter & Griffin Standards Track [Page 7]
|
||||
|
||||
RFC 4255 DNS and SSH Fingerprints January 2006
|
||||
|
||||
|
||||
[9] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
|
||||
Wellington, "Secret Key Transaction Authentication for DNS
|
||||
(TSIG)", RFC 2845, May 2000.
|
||||
|
||||
[10] Eastlake 3rd, D., "DNS Request and Transaction Signatures
|
||||
( SIG(0)s )", RFC 2931, September 2000.
|
||||
|
||||
[11] Wellington, B., "Secure Domain Name System (DNS) Dynamic
|
||||
Update", RFC 3007, November 2000.
|
||||
|
||||
8. Acknowledgements
|
||||
|
||||
The authors gratefully acknowledge, in no particular order, the
|
||||
contributions of the following persons:
|
||||
|
||||
Martin Fredriksson
|
||||
|
||||
Olafur Gudmundsson
|
||||
|
||||
Edward Lewis
|
||||
|
||||
Bill Sommerfeld
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Jakob Schlyter
|
||||
OpenSSH
|
||||
812 23rd Avenue SE
|
||||
Calgary, Alberta T2G 1N8
|
||||
Canada
|
||||
|
||||
EMail: jakob@openssh.com
|
||||
URI: http://www.openssh.com/
|
||||
|
||||
|
||||
Wesley Griffin
|
||||
SPARTA
|
||||
7075 Samuel Morse Drive
|
||||
Columbia, MD 21046
|
||||
USA
|
||||
|
||||
EMail: wgriffin@sparta.com
|
||||
URI: http://www.sparta.com/
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schlyter & Griffin Standards Track [Page 8]
|
||||
|
||||
RFC 4255 DNS and SSH Fingerprints January 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Schlyter & Griffin Standards Track [Page 9]
|
||||
|
||||
@@ -1,563 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group D. Eastlake 3rd
|
||||
Request for Comments: 4343 Motorola Laboratories
|
||||
Updates: 1034, 1035, 2181 January 2006
|
||||
Category: Standards Track
|
||||
|
||||
|
||||
Domain Name System (DNS) Case Insensitivity Clarification
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
Domain Name System (DNS) names are "case insensitive". This document
|
||||
explains exactly what that means and provides a clear specification
|
||||
of the rules. This clarification updates RFCs 1034, 1035, and 2181.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................2
|
||||
2. Case Insensitivity of DNS Labels ................................2
|
||||
2.1. Escaping Unusual DNS Label Octets ..........................2
|
||||
2.2. Example Labels with Escapes ................................3
|
||||
3. Name Lookup, Label Types, and CLASS .............................3
|
||||
3.1. Original DNS Label Types ...................................4
|
||||
3.2. Extended Label Type Case Insensitivity Considerations ......4
|
||||
3.3. CLASS Case Insensitivity Considerations ....................4
|
||||
4. Case on Input and Output ........................................5
|
||||
4.1. DNS Output Case Preservation ...............................5
|
||||
4.2. DNS Input Case Preservation ................................5
|
||||
5. Internationalized Domain Names ..................................6
|
||||
6. Security Considerations .........................................6
|
||||
7. Acknowledgements ................................................7
|
||||
Normative References................................................7
|
||||
Informative References..............................................8
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 1]
|
||||
|
||||
RFC 4343 DNS Case Insensitivity Clarification January 2006
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
The Domain Name System (DNS) is the global hierarchical replicated
|
||||
distributed database system for Internet addressing, mail proxy, and
|
||||
other information. Each node in the DNS tree has a name consisting
|
||||
of zero or more labels [STD13, RFC1591, RFC2606] that are treated in
|
||||
a case insensitive fashion. This document clarifies the meaning of
|
||||
"case insensitive" for the DNS. This clarification updates RFCs
|
||||
1034, 1035 [STD13], and [RFC2181].
|
||||
|
||||
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].
|
||||
|
||||
2. Case Insensitivity of DNS Labels
|
||||
|
||||
DNS was specified in the era of [ASCII]. DNS names were expected to
|
||||
look like most host names or Internet email address right halves (the
|
||||
part after the at-sign, "@") or to be numeric, as in the in-addr.arpa
|
||||
part of the DNS name space. For example,
|
||||
|
||||
foo.example.net.
|
||||
aol.com.
|
||||
www.gnu.ai.mit.edu.
|
||||
or 69.2.0.192.in-addr.arpa.
|
||||
|
||||
Case-varied alternatives to the above [RFC3092] would be DNS names
|
||||
like
|
||||
|
||||
Foo.ExamplE.net.
|
||||
AOL.COM.
|
||||
WWW.gnu.AI.mit.EDU.
|
||||
or 69.2.0.192.in-ADDR.ARPA.
|
||||
|
||||
However, the individual octets of which DNS names consist are not
|
||||
limited to valid ASCII character codes. They are 8-bit bytes, and
|
||||
all values are allowed. Many applications, however, interpret them
|
||||
as ASCII characters.
|
||||
|
||||
2.1. Escaping Unusual DNS Label Octets
|
||||
|
||||
In Master Files [STD13] and other human-readable and -writable ASCII
|
||||
contexts, an escape is needed for the byte value for period (0x2E,
|
||||
".") and all octet values outside of the inclusive range from 0x21
|
||||
("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in
|
||||
the two inclusive ranges from 0x00 to 0x20 and from 0x7F to 0xFF.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 2]
|
||||
|
||||
RFC 4343 DNS Case Insensitivity Clarification January 2006
|
||||
|
||||
|
||||
One typographic convention for octets that do not correspond to an
|
||||
ASCII printing graphic is to use a back-slash followed by the value
|
||||
of the octet as an unsigned integer represented by exactly three
|
||||
decimal digits.
|
||||
|
||||
The same convention can be used for printing ASCII characters so that
|
||||
they will be treated as a normal label character. This includes the
|
||||
back-slash character used in this convention itself, which can be
|
||||
expressed as \092 or \\, and the special label separator period
|
||||
("."), which can be expressed as and \046 or \. It is advisable to
|
||||
avoid using a backslash to quote an immediately following non-
|
||||
printing ASCII character code to avoid implementation difficulties.
|
||||
|
||||
A back-slash followed by only one or two decimal digits is undefined.
|
||||
A back-slash followed by four decimal digits produces two octets, the
|
||||
first octet having the value of the first three digits considered as
|
||||
a decimal number, and the second octet being the character code for
|
||||
the fourth decimal digit.
|
||||
|
||||
2.2. Example Labels with Escapes
|
||||
|
||||
The first example below shows embedded spaces and a period (".")
|
||||
within a label. The second one shows a 5-octet label where the
|
||||
second octet has all bits zero, the third is a backslash, and the
|
||||
fourth octet has all bits one.
|
||||
|
||||
Donald\032E\.\032Eastlake\0323rd.example.
|
||||
and a\000\\\255z.example.
|
||||
|
||||
3. Name Lookup, Label Types, and CLASS
|
||||
|
||||
According to the original DNS design decision, comparisons on name
|
||||
lookup for DNS queries should be case insensitive [STD13]. That is
|
||||
to say, a lookup string octet with a value in the inclusive range
|
||||
from 0x41 to 0x5A, the uppercase ASCII letters, MUST match the
|
||||
identical value and also match the corresponding value in the
|
||||
inclusive range from 0x61 to 0x7A, the lowercase ASCII letters. A
|
||||
lookup string octet with a lowercase ASCII letter value MUST
|
||||
similarly match the identical value and also match the corresponding
|
||||
value in the uppercase ASCII letter range.
|
||||
|
||||
(Historical note: The terms "uppercase" and "lowercase" were invented
|
||||
after movable type. The terms originally referred to the two font
|
||||
trays for storing, in partitioned areas, the different physical type
|
||||
elements. Before movable type, the nearest equivalent terms were
|
||||
"majuscule" and "minuscule".)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 3]
|
||||
|
||||
RFC 4343 DNS Case Insensitivity Clarification January 2006
|
||||
|
||||
|
||||
One way to implement this rule would be to subtract 0x20 from all
|
||||
octets in the inclusive range from 0x61 to 0x7A before comparing
|
||||
octets. Such an operation is commonly known as "case folding", but
|
||||
implementation via case folding is not required. Note that the DNS
|
||||
case insensitivity does NOT correspond to the case folding specified
|
||||
in [ISO-8859-1] or [ISO-8859-2]. For example, the octets 0xDD (\221)
|
||||
and 0xFD (\253) do NOT match, although in other contexts, where they
|
||||
are interpreted as the upper- and lower-case version of "Y" with an
|
||||
acute accent, they might.
|
||||
|
||||
3.1. Original DNS Label Types
|
||||
|
||||
DNS labels in wire-encoded names have a type associated with them.
|
||||
The original DNS standard [STD13] had only two types: ASCII labels,
|
||||
with a length from zero to 63 octets, and indirect (or compression)
|
||||
labels, which consist of an offset pointer to a name location
|
||||
elsewhere in the wire encoding on a DNS message. (The ASCII label of
|
||||
length zero is reserved for use as the name of the root node of the
|
||||
name tree.) ASCII labels follow the ASCII case conventions described
|
||||
herein and, as stated above, can actually contain arbitrary byte
|
||||
values. Indirect labels are, in effect, replaced by the name to
|
||||
which they point, which is then treated with the case insensitivity
|
||||
rules in this document.
|
||||
|
||||
3.2. Extended Label Type Case Insensitivity Considerations
|
||||
|
||||
DNS was extended by [RFC2671] so that additional label type numbers
|
||||
would be available. (The only such type defined so far is the BINARY
|
||||
type [RFC2673], which is now Experimental [RFC3363].)
|
||||
|
||||
The ASCII case insensitivity conventions only apply to ASCII labels;
|
||||
that is to say, label type 0x0, whether appearing directly or invoked
|
||||
by indirect labels.
|
||||
|
||||
3.3. CLASS Case Insensitivity Considerations
|
||||
|
||||
As described in [STD13] and [RFC2929], DNS has an additional axis for
|
||||
data location called CLASS. The only CLASS in global use at this
|
||||
time is the "IN" (Internet) CLASS.
|
||||
|
||||
The handling of DNS label case is not CLASS dependent. With the
|
||||
original design of DNS, it was intended that a recursive DNS resolver
|
||||
be able to handle new CLASSes that were unknown at the time of its
|
||||
implementation. This requires uniform handling of label case
|
||||
insensitivity. Should it become desirable, for example, to allocate
|
||||
a CLASS with "case sensitive ASCII labels", it would be necessary to
|
||||
allocate a new label type for these labels.
|
||||
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 4]
|
||||
|
||||
RFC 4343 DNS Case Insensitivity Clarification January 2006
|
||||
|
||||
|
||||
4. Case on Input and Output
|
||||
|
||||
While ASCII label comparisons are case insensitive, [STD13] says case
|
||||
MUST be preserved on output and preserved when convenient on input.
|
||||
However, this means less than it would appear, since the preservation
|
||||
of case on output is NOT required when output is optimized by the use
|
||||
of indirect labels, as explained below.
|
||||
|
||||
4.1. DNS Output Case Preservation
|
||||
|
||||
[STD13] views the DNS namespace as a node tree. ASCII output is as
|
||||
if a name were marshaled by taking the label on the node whose name
|
||||
is to be output, converting it to a typographically encoded ASCII
|
||||
string, walking up the tree outputting each label encountered, and
|
||||
preceding all labels but the first with a period ("."). Wire output
|
||||
follows the same sequence, but each label is wire encoded, and no
|
||||
periods are inserted. No "case conversion" or "case folding" is done
|
||||
during such output operations, thus "preserving" case. However, to
|
||||
optimize output, indirect labels may be used to point to names
|
||||
elsewhere in the DNS answer. In determining whether the name to be
|
||||
pointed to (for example, the QNAME) is the "same" as the remainder of
|
||||
the name being optimized, the case insensitive comparison specified
|
||||
above is done. Thus, such optimization may easily destroy the output
|
||||
preservation of case. This type of optimization is commonly called
|
||||
"name compression".
|
||||
|
||||
4.2. DNS Input Case Preservation
|
||||
|
||||
Originally, DNS data came from an ASCII Master File as defined in
|
||||
[STD13] or a zone transfer. DNS Dynamic update and incremental zone
|
||||
transfers [RFC1995] have been added as a source of DNS data [RFC2136,
|
||||
RFC3007]. When a node in the DNS name tree is created by any of such
|
||||
inputs, no case conversion is done. Thus, the case of ASCII labels
|
||||
is preserved if they are for nodes being created. However, when a
|
||||
name label is input for a node that already exists in DNS data being
|
||||
held, the situation is more complex. Implementations are free to
|
||||
retain the case first loaded for such a label, to allow new input to
|
||||
override the old case, or even to maintain separate copies preserving
|
||||
the input case.
|
||||
|
||||
For example, if data with owner name "foo.bar.example" [RFC3092] is
|
||||
loaded and then later data with owner name "xyz.BAR.example" is
|
||||
input, the name of the label on the "bar.example" node (i.e., "bar")
|
||||
might or might not be changed to "BAR" in the DNS stored data. Thus,
|
||||
later retrieval of data stored under "xyz.bar.example" in this case
|
||||
can use "xyz.BAR.example" in all returned data, use "xyz.bar.example"
|
||||
in all returned data, or even, when more than one RR is being
|
||||
returned, use a mixture of these two capitalizations. This last case
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 5]
|
||||
|
||||
RFC 4343 DNS Case Insensitivity Clarification January 2006
|
||||
|
||||
|
||||
is unlikely, as optimization of answer length through indirect labels
|
||||
tends to cause only one copy of the name tail ("bar.example" or
|
||||
"BAR.example") to be used for all returned RRs. Note that none of
|
||||
this has any effect on the number or completeness of the RR set
|
||||
returned, only on the case of the names in the RR set returned.
|
||||
|
||||
The same considerations apply when inputting multiple data records
|
||||
with owner names differing only in case. For example, if an "A"
|
||||
record is the first resource record stored under owner name
|
||||
"xyz.BAR.example" and then a second "A" record is stored under
|
||||
"XYZ.BAR.example", the second MAY be stored with the first (lower
|
||||
case initial label) name, the second MAY override the first so that
|
||||
only an uppercase initial label is retained, or both capitalizations
|
||||
MAY be kept in the DNS stored data. In any case, a retrieval with
|
||||
either capitalization will retrieve all RRs with either
|
||||
capitalization.
|
||||
|
||||
Note that the order of insertion into a server database of the DNS
|
||||
name tree nodes that appear in a Master File is not defined so that
|
||||
the results of inconsistent capitalization in a Master File are
|
||||
unpredictable output capitalization.
|
||||
|
||||
5. Internationalized Domain Names
|
||||
|
||||
A scheme has been adopted for "internationalized domain names" and
|
||||
"internationalized labels" as described in [RFC3490, RFC3454,
|
||||
RFC3491, and RFC3492]. It makes most of [UNICODE] available through
|
||||
a separate application level transformation from internationalized
|
||||
domain name to DNS domain name and from DNS domain name to
|
||||
internationalized domain name. Any case insensitivity that
|
||||
internationalized domain names and labels have varies depending on
|
||||
the script and is handled entirely as part of the transformation
|
||||
described in [RFC3454] and [RFC3491], which should be seen for
|
||||
further details. This is not a part of the DNS as standardized in
|
||||
STD 13.
|
||||
|
||||
6. Security Considerations
|
||||
|
||||
The equivalence of certain DNS label types with case differences, as
|
||||
clarified in this document, can lead to security problems. For
|
||||
example, a user could be confused by believing that two domain names
|
||||
differing only in case were actually different names.
|
||||
|
||||
Furthermore, a domain name may be used in contexts other than the
|
||||
DNS. It could be used as a case sensitive index into some database
|
||||
or file system. Or it could be interpreted as binary data by some
|
||||
integrity or authentication code system. These problems can usually
|
||||
be handled by using a standardized or "canonical" form of the DNS
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 6]
|
||||
|
||||
RFC 4343 DNS Case Insensitivity Clarification January 2006
|
||||
|
||||
|
||||
ASCII type labels; that is, always mapping the ASCII letter value
|
||||
octets in ASCII labels to some specific pre-chosen case, either
|
||||
uppercase or lower case. An example of a canonical form for domain
|
||||
names (and also a canonical ordering for them) appears in Section 6
|
||||
of [RFC4034]. See also [RFC3597].
|
||||
|
||||
Finally, a non-DNS name may be stored into DNS with the false
|
||||
expectation that case will always be preserved. For example,
|
||||
although this would be quite rare, on a system with case sensitive
|
||||
email address local parts, an attempt to store two Responsible Person
|
||||
(RP) [RFC1183] records that differed only in case would probably
|
||||
produce unexpected results that might have security implications.
|
||||
That is because the entire email address, including the possibly case
|
||||
sensitive local or left-hand part, is encoded into a DNS name in a
|
||||
readable fashion where the case of some letters might be changed on
|
||||
output as described above.
|
||||
|
||||
7. Acknowledgements
|
||||
|
||||
The contributions to this document by Rob Austein, Olafur
|
||||
Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
|
||||
Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman
|
||||
are gratefully acknowledged.
|
||||
|
||||
Normative References
|
||||
|
||||
[ASCII] ANSI, "USA Standard Code for Information Interchange",
|
||||
X3.4, American National Standards Institute: New York,
|
||||
1968.
|
||||
|
||||
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
|
||||
August 1996.
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
|
||||
"Dynamic Updates in the Domain Name System (DNS
|
||||
UPDATE)", RFC 2136, April 1997.
|
||||
|
||||
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
|
||||
Specification", RFC 2181, July 1997.
|
||||
|
||||
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
|
||||
Update", RFC 3007, November 2000.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 7]
|
||||
|
||||
RFC 4343 DNS Case Insensitivity Clarification January 2006
|
||||
|
||||
|
||||
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
|
||||
(RR) Types", RFC 3597, September 2003.
|
||||
|
||||
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Resource Records for the DNS Security
|
||||
Extensions", RFC 4034, March 2005.
|
||||
|
||||
[STD13] Mockapetris, P., "Domain names - concepts and
|
||||
facilities", STD 13, RFC 1034, November 1987.
|
||||
|
||||
Mockapetris, P., "Domain names - implementation and
|
||||
specification", STD 13, RFC 1035, November 1987.
|
||||
|
||||
Informative References
|
||||
|
||||
[ISO-8859-1] International Standards Organization, Standard for
|
||||
Character Encodings, Latin-1.
|
||||
|
||||
[ISO-8859-2] International Standards Organization, Standard for
|
||||
Character Encodings, Latin-2.
|
||||
|
||||
[RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P.
|
||||
Mockapetris, "New DNS RR Definitions", RFC 1183, October
|
||||
1990.
|
||||
|
||||
[RFC1591] Postel, J., "Domain Name System Structure and
|
||||
Delegation", RFC 1591, March 1994.
|
||||
|
||||
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
|
||||
Names", BCP 32, RFC 2606, June 1999.
|
||||
|
||||
[RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
|
||||
"Domain Name System (DNS) IANA Considerations", BCP 42,
|
||||
RFC 2929, September 2000.
|
||||
|
||||
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
|
||||
2671, August 1999.
|
||||
|
||||
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
|
||||
RFC 2673, August 1999.
|
||||
|
||||
[RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology
|
||||
of "Foo"", RFC 3092, 1 April 2001.
|
||||
|
||||
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
|
||||
Hain, "Representing Internet Protocol version 6 (IPv6)
|
||||
Addresses in the Domain Name System (DNS)", RFC 3363,
|
||||
August 2002.
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 8]
|
||||
|
||||
RFC 4343 DNS Case Insensitivity Clarification January 2006
|
||||
|
||||
|
||||
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
|
||||
Internationalized Strings ("stringprep")", RFC 3454,
|
||||
December 2002.
|
||||
|
||||
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
|
||||
"Internationalizing Domain Names in Applications
|
||||
(IDNA)", RFC 3490, March 2003.
|
||||
|
||||
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
|
||||
Profile for Internationalized Domain Names (IDN)", RFC
|
||||
3491, March 2003.
|
||||
|
||||
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of
|
||||
Unicode for Internationalized Domain Names in
|
||||
Applications (IDNA)", RFC 3492, March 2003.
|
||||
|
||||
[UNICODE] The Unicode Consortium, "The Unicode Standard",
|
||||
<http://www.unicode.org/unicode/standard/standard.html>.
|
||||
|
||||
Author's Address
|
||||
|
||||
Donald E. Eastlake 3rd
|
||||
Motorola Laboratories
|
||||
155 Beaver Street
|
||||
Milford, MA 01757 USA
|
||||
|
||||
Phone: +1 508-786-7554 (w)
|
||||
EMail: Donald.Eastlake@motorola.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 9]
|
||||
|
||||
RFC 4343 DNS Case Insensitivity Clarification January 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Eastlake 3rd Standards Track [Page 10]
|
||||
|
||||
@@ -1,955 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group J. Rosenberg, Ed.
|
||||
Request for Comments: 4367 IAB
|
||||
Category: Informational February 2006
|
||||
|
||||
|
||||
What's in a Name: False Assumptions about DNS Names
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This memo provides information for the Internet community. It does
|
||||
not specify an Internet standard of any kind. Distribution of this
|
||||
memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
The Domain Name System (DNS) provides an essential service on the
|
||||
Internet, mapping structured names to a variety of data, usually IP
|
||||
addresses. These names appear in email addresses, Uniform Resource
|
||||
Identifiers (URIs), and other application-layer identifiers that are
|
||||
often rendered to human users. Because of this, there has been a
|
||||
strong demand to acquire names that have significance to people,
|
||||
through equivalence to registered trademarks, company names, types of
|
||||
services, and so on. There is a danger in this trend; the humans and
|
||||
automata that consume and use such names will associate specific
|
||||
semantics with some names and thereby make assumptions about the
|
||||
services that are, or should be, provided by the hosts associated
|
||||
with the names. Those assumptions can often be false, resulting in a
|
||||
variety of failure conditions. This document discusses this problem
|
||||
in more detail and makes recommendations on how it can be avoided.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Rosenberg Informational [Page 1]
|
||||
|
||||
RFC 4367 Name Assumptions February 2006
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................2
|
||||
2. Target Audience .................................................4
|
||||
3. Modeling Usage of the DNS .......................................4
|
||||
4. Possible Assumptions ............................................5
|
||||
4.1. By the User ................................................5
|
||||
4.2. By the Client ..............................................6
|
||||
4.3. By the Server ..............................................7
|
||||
5. Consequences of False Assumptions ...............................8
|
||||
6. Reasons Why the Assumptions Can Be False ........................9
|
||||
6.1. Evolution ..................................................9
|
||||
6.2. Leakage ...................................................10
|
||||
6.3. Sub-Delegation ............................................10
|
||||
6.4. Mobility ..................................................12
|
||||
6.5. Human Error ...............................................12
|
||||
7. Recommendations ................................................12
|
||||
8. A Note on RFC 2219 and RFC 2782 ................................13
|
||||
9. Security Considerations ........................................14
|
||||
10. Acknowledgements ..............................................14
|
||||
11. IAB Members ...................................................14
|
||||
12. Informative References ........................................15
|
||||
|
||||
1. Introduction
|
||||
|
||||
The Domain Name System (DNS) [1] provides an essential service on the
|
||||
Internet, mapping structured names to a variety of different types of
|
||||
data. Most often it is used to obtain the IP address of a host
|
||||
associated with that name [2] [1] [3]. However, it can be used to
|
||||
obtain other information, and proposals have been made for nearly
|
||||
everything, including geographic information [4].
|
||||
|
||||
Domain names are most often used in identifiers used by application
|
||||
protocols. The most well known include email addresses and URIs,
|
||||
such as the HTTP URL [5], Real Time Streaming Protocol (RTSP) URL
|
||||
[6], and SIP URI [7]. These identifiers are ubiquitous, appearing on
|
||||
business cards, web pages, street signs, and so on. Because of this,
|
||||
there has been a strong demand to acquire domain names that have
|
||||
significance to people through equivalence to registered trademarks,
|
||||
company names, types of services, and so on. Such identifiers serve
|
||||
many business purposes, including extension of brand, advertising,
|
||||
and so on.
|
||||
|
||||
People often make assumptions about the type of service that is or
|
||||
should be provided by a host associated with that name, based on
|
||||
their expectations and understanding of what the name implies. This,
|
||||
in turn, triggers attempts by organizations to register domain names
|
||||
based on that presumed user expectation. Examples of this are the
|
||||
|
||||
|
||||
|
||||
Rosenberg Informational [Page 2]
|
||||
|
||||
RFC 4367 Name Assumptions February 2006
|
||||
|
||||
|
||||
various proposals for a Top-Level Domain (TLD) that could be
|
||||
associated with adult content [8], the requests for creation of TLDs
|
||||
associated with mobile devices and services, and even phishing
|
||||
attacks.
|
||||
|
||||
When these assumptions are codified into the behavior of an
|
||||
automaton, such as an application client or server, as a result of
|
||||
implementor choice, management directive, or domain owner policy, the
|
||||
overall system can fail in various ways. This document describes a
|
||||
number of typical ways in which these assumptions can be codified,
|
||||
how they can be wrong, the consequences of those mistakes, and the
|
||||
recommended ways in which they can be avoided.
|
||||
|
||||
Section 4 describes some of the possible assumptions that clients,
|
||||
servers, and people can make about a domain name. In this context,
|
||||
an "assumption" is defined as any behavior that is expected when
|
||||
accessing a service at a domain name, even though the behavior is not
|
||||
explicitly codified in protocol specifications. Frequently, these
|
||||
assumptions involve ignoring parts of a specification based on an
|
||||
assumption that the client or server is deployed in an environment
|
||||
that is more rigid than the specification allows. Section 5
|
||||
overviews some of the consequences of these false assumptions.
|
||||
Generally speaking, these consequences can include a variety of
|
||||
different interoperability failures, user experience failures, and
|
||||
system failures. Section 6 discusses why these assumptions can be
|
||||
false from the very beginning or become false at some point in the
|
||||
future. Most commonly, they become false because the environment
|
||||
changes in unexpected ways over time, and what was a valid assumption
|
||||
before, no longer is. Other times, the assumptions prove wrong
|
||||
because they were based on the belief that a specific community of
|
||||
clients and servers was participating, and an element outside of that
|
||||
community began participating.
|
||||
|
||||
Section 7 then provides some recommendations. These recommendations
|
||||
encapsulate some of the engineering mantras that have been at the
|
||||
root of Internet protocol design for decades. These include:
|
||||
|
||||
Follow the specifications.
|
||||
|
||||
Use the capability negotiation techniques provided in the
|
||||
protocols.
|
||||
|
||||
Be liberal in what you accept, and conservative in what you send.
|
||||
[18]
|
||||
|
||||
Overall, automata should not change their behavior within a protocol
|
||||
based on the domain name, or some component of the domain name, of
|
||||
the host they are communicating with.
|
||||
|
||||
|
||||
|
||||
Rosenberg Informational [Page 3]
|
||||
|
||||
RFC 4367 Name Assumptions February 2006
|
||||
|
||||
|
||||
2. Target Audience
|
||||
|
||||
This document has several audiences. Firstly, it is aimed at
|
||||
implementors who ultimately develop the software that make the false
|
||||
assumptions that are the subject of this document. The
|
||||
recommendations described here are meant to reinforce the engineering
|
||||
guidelines that are often understood by implementors, but frequently
|
||||
forgotten as deadlines near and pressures mount.
|
||||
|
||||
The document is also aimed at technology managers, who often develop
|
||||
the requirements that lead to these false assumptions. For them,
|
||||
this document serves as a vehicle for emphasizing the importance of
|
||||
not taking shortcuts in the scope of applicability of a project.
|
||||
|
||||
Finally, this document is aimed at domain name policy makers and
|
||||
administrators. For them, it points out the perils in establishing
|
||||
domain policies that get codified into the operation of applications
|
||||
running within that domain.
|
||||
|
||||
3. Modeling Usage of the DNS
|
||||
|
||||
|
||||
+--------+
|
||||
| |
|
||||
| |
|
||||
| DNS |
|
||||
|Service |
|
||||
| |
|
||||
+--------+
|
||||
^ |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
/--\ | |
|
||||
| | | V
|
||||
| | +--------+ +--------+
|
||||
\--/ | | | |
|
||||
| | | | |
|
||||
---+--- | Client |-------------------->| Server |
|
||||
| | | | |
|
||||
| | | | |
|
||||
/\ +--------+ +--------+
|
||||
/ \
|
||||
/ \
|
||||
|
||||
User
|
||||
Figure 1
|
||||
|
||||
|
||||
|
||||
|
||||
Rosenberg Informational [Page 4]
|
||||
|
||||
RFC 4367 Name Assumptions February 2006
|
||||
|
||||
|
||||
Figure 1 shows a simple conceptual model of how the DNS is used by
|
||||
applications. A user of the application obtains an identifier for
|
||||
particular content or service it wishes to obtain. This identifier
|
||||
is often a URL or URI that contains a domain name. The user enters
|
||||
this identifier into its client application (for example, by typing
|
||||
in the URL in a web browser window). The client is the automaton (a
|
||||
software and/or hardware system) that contacts a server for that
|
||||
application in order to provide service to the user. To do that, it
|
||||
contacts a DNS server to resolve the domain name in the identifier to
|
||||
an IP address. It then contacts the server at that IP address. This
|
||||
simple model applies to application protocols such as HTTP [5], SIP
|
||||
[7], RTSP [6], and SMTP [9].
|
||||
|
||||
>From this model, it is clear that three entities in the system can
|
||||
potentially make false assumptions about the service provided by the
|
||||
server. The human user may form expectations relating to the content
|
||||
of the service based on a parsing of the host name from which the
|
||||
content originated. The server might assume that the client
|
||||
connecting to it supports protocols that it does not, can process
|
||||
content that it cannot, or has capabilities that it does not.
|
||||
Similarly, the client might assume that the server supports
|
||||
protocols, content, or capabilities that it does not. Furthermore,
|
||||
applications can potentially contain a multiplicity of humans,
|
||||
clients, and servers, all of which can independently make these false
|
||||
assumptions.
|
||||
|
||||
4. Possible Assumptions
|
||||
|
||||
For each of the three elements, there are many types of false
|
||||
assumptions that can be made.
|
||||
|
||||
4.1. By the User
|
||||
|
||||
The set of possible assumptions here is nearly boundless. Users
|
||||
might assume that an HTTP URL that looks like a company name maps to
|
||||
a server run by that company. They might assume that an email from a
|
||||
email address in the .gov TLD is actually from a government employee.
|
||||
They might assume that the content obtained from a web server within
|
||||
a TLD labeled as containing adult materials (for example, .sex)
|
||||
actually contains adult content [8]. These assumptions are
|
||||
unavoidable, may all be false, and are not the focus of this
|
||||
document.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Rosenberg Informational [Page 5]
|
||||
|
||||
RFC 4367 Name Assumptions February 2006
|
||||
|
||||
|
||||
4.2. By the Client
|
||||
|
||||
Even though the client is an automaton, it can make some of the same
|
||||
assumptions that a human user might make. For example, many clients
|
||||
assume that any host with a hostname that begins with "www" is a web
|
||||
server, even though this assumption may be false.
|
||||
|
||||
In addition, the client concerns itself with the protocols needed to
|
||||
communicate with the server. As a result, it might make assumptions
|
||||
about the operation of the protocols for communicating with the
|
||||
server. These assumptions manifest themselves in an implementation
|
||||
when a standardized protocol negotiation technique defined by the
|
||||
protocol is ignored, and instead, some kind of rule is coded into the
|
||||
software that comes to its own conclusion about what the negotiation
|
||||
would have determined. The result is often a loss of
|
||||
interoperability, degradation in reliability, and worsening of user
|
||||
experience.
|
||||
|
||||
Authentication Algorithm: Though a protocol might support a
|
||||
multiplicity of authentication techniques, a client might assume
|
||||
that a server always supports one that is only optional according
|
||||
to the protocol. For example, a SIP client contacting a SIP
|
||||
server in a domain that is apparently used to identify mobile
|
||||
devices (for example, www.example.cellular) might assume that the
|
||||
server supports the optional Authentication and Key Agreement
|
||||
(AKA) digest technique [10], just because of the domain name that
|
||||
was used to access the server. As another example, a web client
|
||||
might assume that a server with the name https.example.com
|
||||
supports HTTP over Transport Layer Security (TLS) [16].
|
||||
|
||||
Data Formats: Though a protocol might allow a multiplicity of data
|
||||
formats to be sent from the server to the client, the client might
|
||||
assume a specific one, rather than using the content labeling and
|
||||
negotiation capabilities of the underlying protocol. For example,
|
||||
an RTSP client might assume that all audio content delivered to it
|
||||
from media.example.cellular uses a low-bandwidth codec. As
|
||||
another example, a mail client might assume that the contents of
|
||||
messages it retrieves from a mail server at mail.example.cellular
|
||||
are always text, instead of checking the MIME headers [11] in the
|
||||
message in order to determine the actual content type.
|
||||
|
||||
Protocol Extensions: A client may attempt an operation on the server
|
||||
that requires the server to support an optional protocol
|
||||
extension. However, rather than implementing the necessary
|
||||
fallback logic, the client may falsely assume that the extension
|
||||
is supported. As an example, a SIP client that requires reliable
|
||||
provisional responses to its request (RFC 3262 [17]) might assume
|
||||
that this extension is supported on servers in the domain
|
||||
|
||||
|
||||
|
||||
Rosenberg Informational [Page 6]
|
||||
|
||||
RFC 4367 Name Assumptions February 2006
|
||||
|
||||
|
||||
sip.example.telecom. Furthermore, the client would not implement
|
||||
the fallback behavior defined in RFC 3262, since it would assume
|
||||
that all servers it will communicate with are in this domain and
|
||||
that all therefore support this extension. However, if the
|
||||
assumptions prove wrong, the client is unable to make any phone
|
||||
calls.
|
||||
|
||||
Languages: A client may support facilities for processing text
|
||||
content differently depending on the language of the text. Rather
|
||||
than determining the language from markers in the message from the
|
||||
server, the client might assume a language based on the domain
|
||||
name. This assumption can easily be wrong. For example, a client
|
||||
might assume that any text in a web page retrieved from a server
|
||||
within the .de country code TLD (ccTLD) is in German, and attempt
|
||||
a translation to Finnish. This would fail dramatically if the
|
||||
text was actually in French. Unfortunately, this client behavior
|
||||
is sometimes exhibited because the server has not properly labeled
|
||||
the language of the content in the first place, often because the
|
||||
server assumed such a labeling was not needed. This is an example
|
||||
of how these false assumptions can create vicious cycles.
|
||||
|
||||
4.3. By the Server
|
||||
|
||||
The server, like the client, is an automaton. Let us consider one
|
||||
servicing a particular domain -- www.company.cellular, for example.
|
||||
It might assume that all clients connecting to this domain support
|
||||
particular capabilities, rather than using the underlying protocol to
|
||||
make this determination. Some examples include:
|
||||
|
||||
Authentication Algorithm: The server can assume that a client
|
||||
supports a particular, optional, authentication technique, and it
|
||||
therefore does not support the mandatory one.
|
||||
|
||||
Language: The server can serve content in a particular language,
|
||||
based on an assumption that clients accessing the domain speak a
|
||||
particular language, or based on an assumption that clients coming
|
||||
from a particular IP address speak a certain language.
|
||||
|
||||
Data Formats: The server can assume that the client supports a
|
||||
particular set of MIME types and is only capable of sending ones
|
||||
within that set. When it generates content in a protocol
|
||||
response, it ignores any content negotiation headers that were
|
||||
present in the request. For example, a web server might ignore
|
||||
the Accept HTTP header field and send a specific image format.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Rosenberg Informational [Page 7]
|
||||
|
||||
RFC 4367 Name Assumptions February 2006
|
||||
|
||||
|
||||
Protocol Extensions: The server might assume that the client supports
|
||||
a particular optional protocol extension, and so it does not
|
||||
support the fallback behavior necessary in the case where the
|
||||
client does not.
|
||||
|
||||
Client Characteristics: The server might assume certain things about
|
||||
the physical characteristics of its clients, such as memory
|
||||
footprint, processing power, screen sizes, screen colors, pointing
|
||||
devices, and so on. Based on these assumptions, it might choose
|
||||
specific behaviors when processing a request. For example, a web
|
||||
server might always assume that clients connect through cell
|
||||
phones, and therefore return content that lacks images and is
|
||||
tuned for such devices.
|
||||
|
||||
5. Consequences of False Assumptions
|
||||
|
||||
There are numerous negative outcomes that can arise from the various
|
||||
false assumptions that users, servers, and clients can make. These
|
||||
include:
|
||||
|
||||
Interoperability Failure: In these cases, the client or server
|
||||
assumed some kind of protocol operation, and this assumption was
|
||||
wrong. The result is that the two are unable to communicate, and
|
||||
the user receives some kind of an error. This represents a total
|
||||
interoperability failure, manifesting itself as a lack of service
|
||||
to users of the system. Unfortunately, this kind of failure
|
||||
persists. Repeated attempts over time by the client to access the
|
||||
service will fail. Only a change in the server or client software
|
||||
can fix this problem.
|
||||
|
||||
System Failure: In these cases, the client or server misinterpreted a
|
||||
protocol operation, and this misinterpretation was serious enough
|
||||
to uncover a bug in the implementation. The bug causes a system
|
||||
crash or some kind of outage, either transient or permanent (until
|
||||
user reset). If this failure occurs in a server, not only will
|
||||
the connecting client lose service, but other clients attempting
|
||||
to connect will not get service. As an example, if a web server
|
||||
assumes that content passed to it from a client (created, for
|
||||
example, by a digital camera) is of a particular content type, and
|
||||
it always passes image content to a codec for decompression prior
|
||||
to storage, the codec might crash when it unexpectedly receives an
|
||||
image compressed in a different format. Of course, it might crash
|
||||
even if the Content-Type was correct, but the compressed bitstream
|
||||
was invalid. False assumptions merely introduce additional
|
||||
failure cases.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Rosenberg Informational [Page 8]
|
||||
|
||||
RFC 4367 Name Assumptions February 2006
|
||||
|
||||
|
||||
Poor User Experience: In these cases, the client and server
|
||||
communicate, but the user receives a diminished user experience.
|
||||
For example, if a client on a PC connects to a web site that
|
||||
provides content for mobile devices, the content may be
|
||||
underwhelming when viewed on the PC. Or, a client accessing a
|
||||
streaming media service may receive content of very low bitrate,
|
||||
even though the client supported better codecs. Indeed, if a user
|
||||
wishes to access content from both a cellular device and a PC
|
||||
using a shared address book (that is, an address book shared
|
||||
across multiple devices), the user would need two entries in that
|
||||
address book, and would need to use the right one from the right
|
||||
device. This is a poor user experience.
|
||||
|
||||
Degraded Security: In these cases, a weaker security mechanism is
|
||||
used than the one that ought to have been used. As an example, a
|
||||
server in a domain might assume that it is only contacted by
|
||||
clients with a limited set of authentication algorithms, even
|
||||
though the clients have been recently upgraded to support a
|
||||
stronger set.
|
||||
|
||||
6. Reasons Why the Assumptions Can Be False
|
||||
|
||||
Assumptions made by clients and servers about the operation of
|
||||
protocols when contacting a particular domain are brittle, and can be
|
||||
wrong for many reasons. On the server side, many of the assumptions
|
||||
are based on the notion that a domain name will only be given to, or
|
||||
used by, a restricted set of clients. If the holder of the domain
|
||||
name assumes something about those clients, and can assume that only
|
||||
those clients use the domain name, then it can configure or program
|
||||
the server to operate specifically for those clients. Both parts of
|
||||
this assumption can be wrong, as discussed in more detail below.
|
||||
|
||||
On the client side, the notion is similar, being based on the
|
||||
assumption that a server within a particular domain will provide a
|
||||
specific type of service. Sub-delegation and evolution, both
|
||||
discussed below, can make these assumptions wrong.
|
||||
|
||||
6.1. Evolution
|
||||
|
||||
The Internet and the devices that access it are constantly evolving,
|
||||
often at a rapid pace. Unfortunately, there is a tendency to build
|
||||
for the here and now, and then worry about the future at a later
|
||||
time. Many of the assumptions above are predicated on
|
||||
characteristics of today's clients and servers. Support for specific
|
||||
protocols, authentication techniques, or content are based on today's
|
||||
standards and today's devices. Even though they may, for the most
|
||||
part, be true, they won't always be. An excellent example is mobile
|
||||
devices. A server servicing a domain accessed by mobile devices
|
||||
|
||||
|
||||
|
||||
Rosenberg Informational [Page 9]
|
||||
|
||||
RFC 4367 Name Assumptions February 2006
|
||||
|
||||
|
||||
might try to make assumptions about the protocols, protocol
|
||||
extensions, security mechanisms, screen sizes, or processor power of
|
||||
such devices. However, all of these characteristics can and will
|
||||
change over time.
|
||||
|
||||
When they do change, the change is usually evolutionary. The result
|
||||
is that the assumptions remain valid in some cases, but not in
|
||||
others. It is difficult to fix such systems, since it requires the
|
||||
server to detect what type of client is connecting, and what its
|
||||
capabilities are. Unless the system is built and deployed with these
|
||||
capability negotiation techniques built in to begin with, such
|
||||
detection can be extremely difficult. In fact, fixing it will often
|
||||
require the addition of such capability negotiation features that, if
|
||||
they had been in place and used to begin with, would have avoided the
|
||||
problem altogether.
|
||||
|
||||
6.2. Leakage
|
||||
|
||||
Servers also make assumptions because of the belief that they will
|
||||
only be accessed by specific clients, and in particular, those that
|
||||
are configured or provisioned to use the domain name. In essence,
|
||||
there is an assumption of community -- that a specific community
|
||||
knows and uses the domain name, while others outside of the community
|
||||
do not.
|
||||
|
||||
The problem is that this notion of community is a false one. The
|
||||
Internet is global. The DNS is global. There is no technical
|
||||
barrier that separates those inside of the community from those
|
||||
outside. The ease with which information propagates across the
|
||||
Internet makes it extremely likely that such domain names will
|
||||
eventually find their way into clients outside of the presumed
|
||||
community. The ubiquitous presence of domain names in various URI
|
||||
formats, coupled with the ease of conveyance of URIs, makes such
|
||||
leakage merely a matter of time. Furthermore, since the DNS is
|
||||
global, and since it can only have one root [12], it becomes possible
|
||||
for clients outside of the community to search and find and use such
|
||||
"special" domain names.
|
||||
|
||||
Indeed, this leakage is a strength of the Internet architecture, not
|
||||
a weakness. It enables global access to services from any client
|
||||
with a connection to the Internet. That, in turn, allows for rapid
|
||||
growth in the number of customers for any particular service.
|
||||
|
||||
6.3. Sub-Delegation
|
||||
|
||||
Clients and users make assumptions about domains because of the
|
||||
notion that there is some kind of centralized control that can
|
||||
enforce those assumptions. However, the DNS is not centralized; it
|
||||
|
||||
|
||||
|
||||
Rosenberg Informational [Page 10]
|
||||
|
||||
RFC 4367 Name Assumptions February 2006
|
||||
|
||||
|
||||
is distributed. If a domain doesn't delegate its sub-domains and has
|
||||
its records within a single zone, it is possible to maintain a
|
||||
centralized policy about operation of its domain. However, once a
|
||||
domain gets sufficiently large that the domain administrators begin
|
||||
to delegate sub-domains to other authorities, it becomes increasingly
|
||||
difficult to maintain any kind of central control on the nature of
|
||||
the service provided in each sub-domain.
|
||||
|
||||
Similarly, the usage of domain names with human semantic connotation
|
||||
tends to lead to a registration of multiple domains in which a
|
||||
particular service is to run. As an example, a service provider with
|
||||
the name "example" might register and set up its services in
|
||||
"example.com", "example.net", and generally example.foo for each foo
|
||||
that is a valid TLD. This, like sub-delegation, results in a growth
|
||||
in the number of domains over which it is difficult to maintain
|
||||
centralized control.
|
||||
|
||||
Not that it is not possible, since there are many examples of
|
||||
successful administration of policies across sub-domains many levels
|
||||
deep. However, it takes an increasing amount of effort to ensure
|
||||
this result, as it requires human intervention and the creation of
|
||||
process and procedure. Automated validation of adherence to policies
|
||||
is very difficult to do, as there is no way to automatically verify
|
||||
many policies that might be put into place.
|
||||
|
||||
A less costly process for providing centralized management of
|
||||
policies is to just hope that any centralized policies are being
|
||||
followed, and then wait for complaints or perform random audits.
|
||||
Those approaches have many problems.
|
||||
|
||||
The invalidation of assumptions due to sub-delegation is discussed in
|
||||
further detail in Section 4.1.3 of [8] and in Section 3.3 of [20].
|
||||
|
||||
As a result of the fragility of policy continuity across sub-
|
||||
delegations, if a client or user assumes some kind of property
|
||||
associated with a TLD (such as ".wifi"), it becomes increasingly more
|
||||
likely with the number of sub-domains that this property will not
|
||||
exist in a server identified by a particular name. For example, in
|
||||
"store.chain.company.provider.wifi", there may be four levels of
|
||||
delegation from ".wifi", making it quite likely that, unless the
|
||||
holder of ".wifi" is working diligently, the properties that the
|
||||
holder of ".wifi" wishes to enforce are not present. These
|
||||
properties may not be present due to human error or due to a willful
|
||||
decision not to adhere to them.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Rosenberg Informational [Page 11]
|
||||
|
||||
RFC 4367 Name Assumptions February 2006
|
||||
|
||||
|
||||
6.4. Mobility
|
||||
|
||||
One of the primary value propositions of a hostname as an identifier
|
||||
is its persistence. A client can change IP addresses, yet still
|
||||
retain a persistent identifier used by other hosts to reach it.
|
||||
Because their value derives from their persistence, hostnames tend to
|
||||
move with a host not just as it changes IP addresses, but as it
|
||||
changes access network providers and technologies. For this reason,
|
||||
assumptions made about a host based on the presumed access network
|
||||
corresponding to that hostname tend to be wrong over time. As an
|
||||
example, a PC might normally be connected to its broadband provider,
|
||||
and through dynamic DNS have a hostname within the domain of that
|
||||
provider. However, one cannot assume that any host within that
|
||||
network has access over a broadband link; the user could connect
|
||||
their PC over a low-bandwidth wireless access network and still
|
||||
retain its domain name.
|
||||
|
||||
6.5. Human Error
|
||||
|
||||
Of course, human error can be the source of errors in any system, and
|
||||
the same is true here. There are many examples relevant to the
|
||||
problem under discussion.
|
||||
|
||||
A client implementation may make the assumption that, just because a
|
||||
DNS SRV record exists for a particular protocol in a particular
|
||||
domain, indicating that the service is available on some port, that
|
||||
the service is, in fact, running there. This assumption could be
|
||||
wrong because the SRV records haven't been updated by the system
|
||||
administrators to reflect the services currently running. As another
|
||||
example, a client might assume that a particular domain policy
|
||||
applies to all sub-domains. However, a system administrator might
|
||||
have omitted to apply the policy to servers running in one of those
|
||||
sub-domains.
|
||||
|
||||
7. Recommendations
|
||||
|
||||
Based on these problems, the clear conclusion is that clients,
|
||||
servers, and users should not make assumptions on the nature of the
|
||||
service provided to, or by, a domain. More specifically, however,
|
||||
the following can be said:
|
||||
|
||||
Follow the specifications: When specifications define mandatory
|
||||
baseline procedures and formats, those should be implemented and
|
||||
supported, even if the expectation is that optional procedures
|
||||
will most often be used. For example, if a specification mandates
|
||||
a particular baseline authentication technique, but allows others
|
||||
to be negotiated and used, implementations need to implement the
|
||||
baseline authentication algorithm even if the other ones are used
|
||||
|
||||
|
||||
|
||||
Rosenberg Informational [Page 12]
|
||||
|
||||
RFC 4367 Name Assumptions February 2006
|
||||
|
||||
|
||||
most of the time. Put more simply, the behavior of the protocol
|
||||
machinery should never change based on the domain name of the
|
||||
host.
|
||||
|
||||
Use capability negotiation: Many protocols are engineered with
|
||||
capability negotiation mechanisms. For example, a content
|
||||
negotiation framework has been defined for protocols using MIME
|
||||
content [13] [14] [15]. SIP allows for clients to negotiate the
|
||||
media types used in the multimedia session, as well as protocol
|
||||
parameters. HTTP allows for clients to negotiate the media types
|
||||
returned in requests for content. When such features are
|
||||
available in a protocol, client and servers should make use of
|
||||
them rather than making assumptions about supported capabilities.
|
||||
A corollary is that protocol designers should include such
|
||||
mechanisms when evolution is expected in the usage of the
|
||||
protocol.
|
||||
|
||||
"Be liberal in what you accept, and conservative in what you send"
|
||||
[18]: This axiom of Internet protocol design is applicable here
|
||||
as well. Implementations should be prepared for the full breadth
|
||||
of what a protocol allows another entity to send, rather than be
|
||||
limiting in what it is willing to receive.
|
||||
|
||||
To summarize -- there is never a need to make assumptions. Rather
|
||||
than doing so, utilize the specifications and the negotiation
|
||||
capabilities they provide, and the overall system will be robust and
|
||||
interoperable.
|
||||
|
||||
8. A Note on RFC 2219 and RFC 2782
|
||||
|
||||
Based on the definition of an assumption given here, the behavior
|
||||
hinted at by records in the DNS also represents an assumption. RFC
|
||||
2219 [19] defines well-known aliases that can be used to construct
|
||||
domain names for reaching various well-known services in a domain.
|
||||
This approach was later followed by the definition of a new resource
|
||||
record, the SRV record [2], which specifies that a particular service
|
||||
is running on a server in a domain. Although both of these
|
||||
mechanisms are useful as a hint that a particular service is running
|
||||
in a domain, both of them represent assumptions that may be false.
|
||||
However, they differ in the set of reasons why those assumptions
|
||||
might be false.
|
||||
|
||||
A client that assumes that "ftp.example.com" is an FTP server may be
|
||||
wrong because the presumed naming convention in RFC 2219 was not
|
||||
known by, or not followed by, the owner of domain.com. With RFC
|
||||
2782, an SRV record for a particular service would be present only by
|
||||
explicit choice of the domain administrator, and thus a client that
|
||||
|
||||
|
||||
|
||||
|
||||
Rosenberg Informational [Page 13]
|
||||
|
||||
RFC 4367 Name Assumptions February 2006
|
||||
|
||||
|
||||
assumes that the corresponding host provides this service would be
|
||||
wrong only because of human error in configuration. In this case,
|
||||
the assumption is less likely to be wrong, but it certainly can be.
|
||||
|
||||
The only way to determine with certainty that a service is running on
|
||||
a host is to initiate a connection to the port for that service, and
|
||||
check. Implementations need to be careful not to codify any
|
||||
behaviors that cause failures should the information provided in the
|
||||
record actually be false. This borders on common sense for robust
|
||||
implementations, but it is valuable to raise this point explicitly.
|
||||
|
||||
9. Security Considerations
|
||||
|
||||
One of the assumptions that can be made by clients or servers is the
|
||||
availability and usage (or lack thereof) of certain security
|
||||
protocols and algorithms. For example, a client accessing a service
|
||||
in a particular domain might assume a specific authentication
|
||||
algorithm or hash function in the application protocol. It is
|
||||
possible that, over time, weaknesses are found in such a technique,
|
||||
requiring usage of a different mechanism. Similarly, a system might
|
||||
start with an insecure mechanism, and then decide later on to use a
|
||||
secure one. In either case, assumptions made on security properties
|
||||
can result in interoperability failures, or worse yet, providing
|
||||
service in an insecure way, even though the client asked for, and
|
||||
thought it would get, secure service. These kinds of assumptions are
|
||||
fundamentally unsound even if the records themselves are secured with
|
||||
DNSSEC.
|
||||
|
||||
10. Acknowledgements
|
||||
|
||||
The IAB would like to thank John Klensin, Keith Moore and Peter Koch
|
||||
for their comments.
|
||||
|
||||
11. IAB Members
|
||||
|
||||
Internet Architecture Board members at the time of writing of this
|
||||
document are:
|
||||
|
||||
Bernard Aboba
|
||||
|
||||
Loa Andersson
|
||||
|
||||
Brian Carpenter
|
||||
|
||||
Leslie Daigle
|
||||
|
||||
Patrik Faltstrom
|
||||
|
||||
|
||||
|
||||
|
||||
Rosenberg Informational [Page 14]
|
||||
|
||||
RFC 4367 Name Assumptions February 2006
|
||||
|
||||
|
||||
Bob Hinden
|
||||
|
||||
Kurtis Lindqvist
|
||||
|
||||
David Meyer
|
||||
|
||||
Pekka Nikander
|
||||
|
||||
Eric Rescorla
|
||||
|
||||
Pete Resnick
|
||||
|
||||
Jonathan Rosenberg
|
||||
|
||||
12. Informative References
|
||||
|
||||
[1] Mockapetris, P., "Domain names - concepts and facilities",
|
||||
STD 13, RFC 1034, November 1987.
|
||||
|
||||
[2] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
|
||||
specifying the location of services (DNS SRV)", RFC 2782,
|
||||
February 2000.
|
||||
|
||||
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
|
||||
Three: The Domain Name System (DNS) Database", RFC 3403,
|
||||
October 2002.
|
||||
|
||||
[4] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means
|
||||
for Expressing Location Information in the Domain Name System",
|
||||
RFC 1876, January 1996.
|
||||
|
||||
[5] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
|
||||
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
|
||||
HTTP/1.1", RFC 2616, June 1999.
|
||||
|
||||
[6] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
|
||||
Protocol (RTSP)", RFC 2326, April 1998.
|
||||
|
||||
[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
|
||||
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
|
||||
Session Initiation Protocol", RFC 3261, June 2002.
|
||||
|
||||
[8] Eastlake, D., ".sex Considered Dangerous", RFC 3675,
|
||||
February 2004.
|
||||
|
||||
[9] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
|
||||
April 2001.
|
||||
|
||||
|
||||
|
||||
|
||||
Rosenberg Informational [Page 15]
|
||||
|
||||
RFC 4367 Name Assumptions February 2006
|
||||
|
||||
|
||||
[10] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
|
||||
Protocol (HTTP) Digest Authentication Using Authentication and
|
||||
Key Agreement (AKA)", RFC 3310, September 2002.
|
||||
|
||||
[11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
||||
Extensions (MIME) Part One: Format of Internet Message Bodies",
|
||||
RFC 2045, November 1996.
|
||||
|
||||
[12] Internet Architecture Board, "IAB Technical Comment on the
|
||||
Unique DNS Root", RFC 2826, May 2000.
|
||||
|
||||
[13] Klyne, G., "Indicating Media Features for MIME Content",
|
||||
RFC 2912, September 2000.
|
||||
|
||||
[14] Klyne, G., "A Syntax for Describing Media Feature Sets",
|
||||
RFC 2533, March 1999.
|
||||
|
||||
[15] Klyne, G., "Protocol-independent Content Negotiation
|
||||
Framework", RFC 2703, September 1999.
|
||||
|
||||
[16] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
|
||||
|
||||
[17] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
|
||||
Responses in Session Initiation Protocol (SIP)", RFC 3262,
|
||||
June 2002.
|
||||
|
||||
[18] Braden, R., "Requirements for Internet Hosts - Communication
|
||||
Layers", STD 3, RFC 1122, October 1989.
|
||||
|
||||
[19] Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
|
||||
Services", BCP 17, RFC 2219, October 1997.
|
||||
|
||||
[20] Faltstrom, P., "Design Choices When Expanding DNS", Work in
|
||||
Progress, June 2005.
|
||||
|
||||
Author's Address
|
||||
|
||||
Jonathan Rosenberg, Editor
|
||||
IAB
|
||||
600 Lanidex Plaza
|
||||
Parsippany, NJ 07054
|
||||
US
|
||||
|
||||
Phone: +1 973 952-5000
|
||||
EMail: jdrosen@cisco.com
|
||||
URI: http://www.jdrosen.net
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Rosenberg Informational [Page 16]
|
||||
|
||||
RFC 4367 Name Assumptions February 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Rosenberg Informational [Page 17]
|
||||
|
||||
@@ -1,955 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group S. Josefsson
|
||||
Request for Comments: 4398 March 2006
|
||||
Obsoletes: 2538
|
||||
Category: Standards Track
|
||||
|
||||
|
||||
Storing Certificates in the Domain Name System (DNS)
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
Cryptographic public keys are frequently published, and their
|
||||
authenticity is demonstrated by certificates. A CERT resource record
|
||||
(RR) is defined so that such certificates and related certificate
|
||||
revocation lists can be stored in the Domain Name System (DNS).
|
||||
|
||||
This document obsoletes RFC 2538.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 1]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................3
|
||||
2. The CERT Resource Record ........................................3
|
||||
2.1. Certificate Type Values ....................................4
|
||||
2.2. Text Representation of CERT RRs ............................6
|
||||
2.3. X.509 OIDs .................................................6
|
||||
3. Appropriate Owner Names for CERT RRs ............................7
|
||||
3.1. Content-Based X.509 CERT RR Names ..........................8
|
||||
3.2. Purpose-Based X.509 CERT RR Names ..........................9
|
||||
3.3. Content-Based OpenPGP CERT RR Names ........................9
|
||||
3.4. Purpose-Based OpenPGP CERT RR Names .......................10
|
||||
3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX ...........10
|
||||
4. Performance Considerations .....................................11
|
||||
5. Contributors ...................................................11
|
||||
6. Acknowledgements ...............................................11
|
||||
7. Security Considerations ........................................12
|
||||
8. IANA Considerations ............................................12
|
||||
9. Changes since RFC 2538 .........................................13
|
||||
10. References ....................................................14
|
||||
10.1. Normative References .....................................14
|
||||
10.2. Informative References ...................................15
|
||||
Appendix A. Copying Conditions ...................................16
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 2]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
Public keys are frequently published in the form of a certificate,
|
||||
and their authenticity is commonly demonstrated by certificates and
|
||||
related certificate revocation lists (CRLs). A certificate is a
|
||||
binding, through a cryptographic digital signature, of a public key,
|
||||
a validity interval and/or conditions, and identity, authorization,
|
||||
or other information. A certificate revocation list is a list of
|
||||
certificates that are revoked, and of incidental information, all
|
||||
signed by the signer (issuer) of the revoked certificates. Examples
|
||||
are X.509 certificates/CRLs in the X.500 directory system or OpenPGP
|
||||
certificates/revocations used by OpenPGP software.
|
||||
|
||||
Section 2 specifies a CERT resource record (RR) for the storage of
|
||||
certificates in the Domain Name System [1] [2].
|
||||
|
||||
Section 3 discusses appropriate owner names for CERT RRs.
|
||||
|
||||
Sections 4, 7, and 8 cover performance, security, and IANA
|
||||
considerations, respectively.
|
||||
|
||||
Section 9 explains the changes in this document compared to RFC 2538.
|
||||
|
||||
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 [3].
|
||||
|
||||
2. The CERT Resource Record
|
||||
|
||||
The CERT resource record (RR) has the structure given below. Its RR
|
||||
type code is 37.
|
||||
|
||||
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
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| type | key tag |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| algorithm | /
|
||||
+---------------+ certificate or CRL /
|
||||
/ /
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
|
||||
|
||||
The type field is the certificate type as defined in Section 2.1
|
||||
below.
|
||||
|
||||
The key tag field is the 16-bit value computed for the key embedded
|
||||
in the certificate, using the RRSIG Key Tag algorithm described in
|
||||
Appendix B of [12]. This field is used as an efficiency measure to
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 3]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
pick which CERT RRs may be applicable to a particular key. The key
|
||||
tag can be calculated for the key in question, and then only CERT RRs
|
||||
with the same key tag need to be examined. Note that two different
|
||||
keys can have the same key tag. However, the key MUST be transformed
|
||||
to the format it would have as the public key portion of a DNSKEY RR
|
||||
before the key tag is computed. This is only possible if the key is
|
||||
applicable to an algorithm and complies to limits (such as key size)
|
||||
defined for DNS security. If it is not, the algorithm field MUST be
|
||||
zero and the tag field is meaningless and SHOULD be zero.
|
||||
|
||||
The algorithm field has the same meaning as the algorithm field in
|
||||
DNSKEY and RRSIG RRs [12], except that a zero algorithm field
|
||||
indicates that the algorithm is unknown to a secure DNS, which may
|
||||
simply be the result of the algorithm not having been standardized
|
||||
for DNSSEC [11].
|
||||
|
||||
2.1. Certificate Type Values
|
||||
|
||||
The following values are defined or reserved:
|
||||
|
||||
Value Mnemonic Certificate Type
|
||||
----- -------- ----------------
|
||||
0 Reserved
|
||||
1 PKIX X.509 as per PKIX
|
||||
2 SPKI SPKI certificate
|
||||
3 PGP OpenPGP packet
|
||||
4 IPKIX The URL of an X.509 data object
|
||||
5 ISPKI The URL of an SPKI certificate
|
||||
6 IPGP The fingerprint and URL of an OpenPGP packet
|
||||
7 ACPKIX Attribute Certificate
|
||||
8 IACPKIX The URL of an Attribute Certificate
|
||||
9-252 Available for IANA assignment
|
||||
253 URI URI private
|
||||
254 OID OID private
|
||||
255 Reserved
|
||||
256-65279 Available for IANA assignment
|
||||
65280-65534 Experimental
|
||||
65535 Reserved
|
||||
|
||||
These values represent the initial content of the IANA registry; see
|
||||
Section 8.
|
||||
|
||||
The PKIX type is reserved to indicate an X.509 certificate conforming
|
||||
to the profile defined by the IETF PKIX working group [8]. The
|
||||
certificate section will start with a one-octet unsigned OID length
|
||||
and then an X.500 OID indicating the nature of the remainder of the
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 4]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
certificate section (see Section 2.3, below). (NOTE: X.509
|
||||
certificates do not include their X.500 directory-type-designating
|
||||
OID as a prefix.)
|
||||
|
||||
The SPKI and ISPKI types are reserved to indicate the SPKI
|
||||
certificate format [15], for use when the SPKI documents are moved
|
||||
from experimental status. The format for these two CERT RR types
|
||||
will need to be specified later.
|
||||
|
||||
The PGP type indicates an OpenPGP packet as described in [5] and its
|
||||
extensions and successors. This is used to transfer public key
|
||||
material and revocation signatures. The data is binary and MUST NOT
|
||||
be encoded into an ASCII armor. An implementation SHOULD process
|
||||
transferable public keys as described in Section 10.1 of [5], but it
|
||||
MAY handle additional OpenPGP packets.
|
||||
|
||||
The ACPKIX type indicates an Attribute Certificate format [9].
|
||||
|
||||
The IPKIX and IACPKIX types indicate a URL that will serve the
|
||||
content that would have been in the "certificate, CRL, or URL" field
|
||||
of the corresponding type (PKIX or ACPKIX, respectively).
|
||||
|
||||
The IPGP type contains both an OpenPGP fingerprint for the key in
|
||||
question, as well as a URL. The certificate portion of the IPGP CERT
|
||||
RR is defined as a one-octet fingerprint length, followed by the
|
||||
OpenPGP fingerprint, followed by the URL. The OpenPGP fingerprint is
|
||||
calculated as defined in RFC 2440 [5]. A zero-length fingerprint or
|
||||
a zero-length URL are legal, and indicate URL-only IPGP data or
|
||||
fingerprint-only IPGP data, respectively. A zero-length fingerprint
|
||||
and a zero-length URL are meaningless and invalid.
|
||||
|
||||
The IPKIX, ISPKI, IPGP, and IACPKIX types are known as "indirect".
|
||||
These types MUST be used when the content is too large to fit in the
|
||||
CERT RR and MAY be used at the implementer's discretion. They SHOULD
|
||||
NOT be used where the DNS message is 512 octets or smaller and could
|
||||
thus be expected to fit a UDP packet.
|
||||
|
||||
The URI private type indicates a certificate format defined by an
|
||||
absolute URI. The certificate portion of the CERT RR MUST begin with
|
||||
a null-terminated URI [10], and the data after the null is the
|
||||
private format certificate itself. The URI SHOULD be such that a
|
||||
retrieval from it will lead to documentation on the format of the
|
||||
certificate. Recognition of private certificate types need not be
|
||||
based on URI equality but can use various forms of pattern matching
|
||||
so that, for example, subtype or version information can also be
|
||||
encoded into the URI.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 5]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
The OID private type indicates a private format certificate specified
|
||||
by an ISO OID prefix. The certificate section will start with a
|
||||
one-octet unsigned OID length and then a BER-encoded OID indicating
|
||||
the nature of the remainder of the certificate section. This can be
|
||||
an X.509 certificate format or some other format. X.509 certificates
|
||||
that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
|
||||
type, not the OID private type. Recognition of private certificate
|
||||
types need not be based on OID equality but can use various forms of
|
||||
pattern matching such as OID prefix.
|
||||
|
||||
2.2. Text Representation of CERT RRs
|
||||
|
||||
The RDATA portion of a CERT RR has the type field as an unsigned
|
||||
decimal integer or as a mnemonic symbol as listed in Section 2.1,
|
||||
above.
|
||||
|
||||
The key tag field is represented as an unsigned decimal integer.
|
||||
|
||||
The algorithm field is represented as an unsigned decimal integer or
|
||||
a mnemonic symbol as listed in [12].
|
||||
|
||||
The certificate/CRL portion is represented in base 64 [16] and may be
|
||||
divided into any number of white-space-separated substrings, down to
|
||||
single base-64 digits, which are concatenated to obtain the full
|
||||
signature. These substrings can span lines using the standard
|
||||
parenthesis.
|
||||
|
||||
Note that the certificate/CRL portion may have internal sub-fields,
|
||||
but these do not appear in the master file representation. For
|
||||
example, with type 254, there will be an OID size, an OID, and then
|
||||
the certificate/CRL proper. However, only a single logical base-64
|
||||
string will appear in the text representation.
|
||||
|
||||
2.3. X.509 OIDs
|
||||
|
||||
OIDs have been defined in connection with the X.500 directory for
|
||||
user certificates, certification authority certificates, revocations
|
||||
of certification authority, and revocations of user certificates.
|
||||
The following table lists the OIDs, their BER encoding, and their
|
||||
length-prefixed hex format for use in CERT RRs:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 6]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
id-at-userCertificate
|
||||
= { joint-iso-ccitt(2) ds(5) at(4) 36 }
|
||||
== 0x 03 55 04 24
|
||||
id-at-cACertificate
|
||||
= { joint-iso-ccitt(2) ds(5) at(4) 37 }
|
||||
== 0x 03 55 04 25
|
||||
id-at-authorityRevocationList
|
||||
= { joint-iso-ccitt(2) ds(5) at(4) 38 }
|
||||
== 0x 03 55 04 26
|
||||
id-at-certificateRevocationList
|
||||
= { joint-iso-ccitt(2) ds(5) at(4) 39 }
|
||||
== 0x 03 55 04 27
|
||||
|
||||
3. Appropriate Owner Names for CERT RRs
|
||||
|
||||
It is recommended that certificate CERT RRs be stored under a domain
|
||||
name related to their subject, i.e., the name of the entity intended
|
||||
to control the private key corresponding to the public key being
|
||||
certified. It is recommended that certificate revocation list CERT
|
||||
RRs be stored under a domain name related to their issuer.
|
||||
|
||||
Following some of the guidelines below may result in DNS names with
|
||||
characters that require DNS quoting as per Section 5.1 of RFC 1035
|
||||
[2].
|
||||
|
||||
The choice of name under which CERT RRs are stored is important to
|
||||
clients that perform CERT queries. In some situations, the clients
|
||||
may not know all information about the CERT RR object it wishes to
|
||||
retrieve. For example, a client may not know the subject name of an
|
||||
X.509 certificate, or the email address of the owner of an OpenPGP
|
||||
key. Further, the client might only know the hostname of a service
|
||||
that uses X.509 certificates or the Key ID of an OpenPGP key.
|
||||
|
||||
Therefore, two owner name guidelines are defined: content-based owner
|
||||
names and purpose-based owner names. A content-based owner name is
|
||||
derived from the content of the CERT RR data; for example, the
|
||||
Subject field in an X.509 certificate or the User ID field in OpenPGP
|
||||
keys. A purpose-based owner name is a name that a client retrieving
|
||||
CERT RRs ought to know already; for example, the host name of an
|
||||
X.509 protected service or the Key ID of an OpenPGP key. The
|
||||
content-based and purpose-based owner name may be the same; for
|
||||
example, when a client looks up a key based on the From: address of
|
||||
an incoming email.
|
||||
|
||||
Implementations SHOULD use the purpose-based owner name guidelines
|
||||
described in this document and MAY use CNAME RRs at content-based
|
||||
owner names (or other names), pointing to the purpose-based owner
|
||||
name.
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 7]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
Note that this section describes an application-based mapping from
|
||||
the name space used in a certificate to the name space used by DNS.
|
||||
The DNS does not infer any relationship amongst CERT resource records
|
||||
based on similarities or differences of the DNS owner name(s) of CERT
|
||||
resource records. For example, if multiple labels are used when
|
||||
mapping from a CERT identifier to a domain name, then care must be
|
||||
taken in understanding wildcard record synthesis.
|
||||
|
||||
3.1. Content-Based X.509 CERT RR Names
|
||||
|
||||
Some X.509 versions, such as the PKIX profile of X.509 [8], permit
|
||||
multiple names to be associated with subjects and issuers under
|
||||
"Subject Alternative Name" and "Issuer Alternative Name". For
|
||||
example, the PKIX profile has such Alternate Names with an ASN.1
|
||||
specification as follows:
|
||||
|
||||
GeneralName ::= CHOICE {
|
||||
otherName [0] OtherName,
|
||||
rfc822Name [1] IA5String,
|
||||
dNSName [2] IA5String,
|
||||
x400Address [3] ORAddress,
|
||||
directoryName [4] Name,
|
||||
ediPartyName [5] EDIPartyName,
|
||||
uniformResourceIdentifier [6] IA5String,
|
||||
iPAddress [7] OCTET STRING,
|
||||
registeredID [8] OBJECT IDENTIFIER }
|
||||
|
||||
The recommended locations of CERT storage are as follows, in priority
|
||||
order:
|
||||
|
||||
1. If a domain name is included in the identification in the
|
||||
certificate or CRL, that ought to be used.
|
||||
2. If a domain name is not included but an IP address is included,
|
||||
then the translation of that IP address into the appropriate
|
||||
inverse domain name ought to be used.
|
||||
3. If neither of the above is used, but a URI containing a domain
|
||||
name is present, that domain name ought to be used.
|
||||
4. If none of the above is included but a character string name is
|
||||
included, then it ought to be treated as described below for
|
||||
OpenPGP names.
|
||||
5. If none of the above apply, then the distinguished name (DN)
|
||||
ought to be mapped into a domain name as specified in [4].
|
||||
|
||||
Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
|
||||
DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
|
||||
string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
|
||||
URI <https://www.secure.john-doe.com:8080/>. The storage locations
|
||||
recommended, in priority order, would be
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 8]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
1. john-doe.com,
|
||||
2. www.secure.john-doe.com, and
|
||||
3. Doe.com.xy.
|
||||
|
||||
Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
|
||||
L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
|
||||
domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
|
||||
(c) string "James Hacker <hacker@mail.widget.foo.example>". The
|
||||
storage locations recommended, in priority order, would be
|
||||
|
||||
1. widget.foo.example,
|
||||
2. 201.13.251.10.in-addr.arpa, and
|
||||
3. hacker.mail.widget.foo.example.
|
||||
|
||||
3.2. Purpose-Based X.509 CERT RR Names
|
||||
|
||||
Due to the difficulty for clients that do not already possess a
|
||||
certificate to reconstruct the content-based owner name,
|
||||
purpose-based owner names are recommended in this section.
|
||||
Recommendations for purpose-based owner names vary per scenario. The
|
||||
following table summarizes the purpose-based X.509 CERT RR owner name
|
||||
guidelines for use with S/MIME [17], SSL/TLS [13], and IPsec [14]:
|
||||
|
||||
Scenario Owner name
|
||||
------------------ ----------------------------------------------
|
||||
S/MIME Certificate Standard translation of an RFC 2822 email
|
||||
address. Example: An S/MIME certificate for
|
||||
"postmaster@example.org" will use a standard
|
||||
hostname translation of the owner name,
|
||||
"postmaster.example.org".
|
||||
|
||||
TLS Certificate Hostname of the TLS server.
|
||||
|
||||
IPsec Certificate Hostname of the IPsec machine and/or, for IPv4
|
||||
or IPv6 addresses, the fully qualified domain
|
||||
name in the appropriate reverse domain.
|
||||
|
||||
An alternate approach for IPsec is to store raw public keys [18].
|
||||
|
||||
3.3. Content-Based OpenPGP CERT RR Names
|
||||
|
||||
OpenPGP signed keys (certificates) use a general character string
|
||||
User ID [5]. However, it is recommended by OpenPGP that such names
|
||||
include the RFC 2822 [7] email address of the party, as in "Leslie
|
||||
Example <Leslie@host.example>". If such a format is used, the CERT
|
||||
ought to be under the standard translation of the email address into
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 9]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
a domain name, which would be leslie.host.example in this case. If
|
||||
no RFC 2822 name can be extracted from the string name, no specific
|
||||
domain name is recommended.
|
||||
|
||||
If a user has more than one email address, the CNAME type can be used
|
||||
to reduce the amount of data stored in the DNS. For example:
|
||||
|
||||
$ORIGIN example.org.
|
||||
smith IN CERT PGP 0 0 <OpenPGP binary>
|
||||
john.smith IN CNAME smith
|
||||
js IN CNAME smith
|
||||
|
||||
3.4. Purpose-Based OpenPGP CERT RR Names
|
||||
|
||||
Applications that receive an OpenPGP packet containing encrypted or
|
||||
signed data but do not know the email address of the sender will have
|
||||
difficulties constructing the correct owner name and cannot use the
|
||||
content-based owner name guidelines. However, these clients commonly
|
||||
know the key fingerprint or the Key ID. The key ID is found in
|
||||
OpenPGP packets, and the key fingerprint is commonly found in
|
||||
auxiliary data that may be available. In this case, use of an owner
|
||||
name identical to the key fingerprint and the key ID expressed in
|
||||
hexadecimal [16] is recommended. For example:
|
||||
|
||||
$ORIGIN example.org.
|
||||
0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
|
||||
F835EDA21E94B565716F IN CERT PGP ...
|
||||
B565716F IN CERT PGP ...
|
||||
|
||||
If the same key material is stored for several owner names, the use
|
||||
of CNAME may help avoid data duplication. Note that CNAME is not
|
||||
always applicable, because it maps one owner name to the other for
|
||||
all purposes, which may be sub-optimal when two keys with the same
|
||||
Key ID are stored.
|
||||
|
||||
3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX
|
||||
|
||||
These types are stored under the same owner names, both purpose- and
|
||||
content-based, as the PKIX, SPKI, PGP, and ACPKIX types.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 10]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
4. Performance Considerations
|
||||
|
||||
The Domain Name System (DNS) protocol was designed for small
|
||||
transfers, typically below 512 octets. While larger transfers will
|
||||
perform correctly and work is underway to make larger transfers more
|
||||
efficient, it is still advisable at this time that every reasonable
|
||||
effort be made to minimize the size of certificates stored within the
|
||||
DNS. Steps that can be taken may include using the fewest possible
|
||||
optional or extension fields and using short field values for
|
||||
necessary variable-length fields.
|
||||
|
||||
The RDATA field in the DNS protocol may only hold data of size 65535
|
||||
octets (64kb) or less. This means that each CERT RR MUST NOT contain
|
||||
more than 64kb of payload, even if the corresponding certificate or
|
||||
certificate revocation list is larger. This document addresses this
|
||||
by defining "indirect" data types for each normal type.
|
||||
|
||||
Deploying CERT RRs to support digitally signed email changes the
|
||||
access patterns of DNS lookups from per-domain to per-user. If
|
||||
digitally signed email and a key/certificate lookup based on CERT RRs
|
||||
are deployed on a wide scale, this may lead to an increased DNS load,
|
||||
with potential performance and cache effectiveness consequences.
|
||||
Whether or not this load increase will be noticeable is not known.
|
||||
|
||||
5. Contributors
|
||||
|
||||
The majority of this document is copied verbatim from RFC 2538, by
|
||||
Donald Eastlake 3rd and Olafur Gudmundsson.
|
||||
|
||||
6. Acknowledgements
|
||||
|
||||
Thanks to David Shaw and Michael Graff for their contributions to
|
||||
earlier works that motivated, and served as inspiration for, this
|
||||
document.
|
||||
|
||||
This document was improved by suggestions and comments from Olivier
|
||||
Dubuisson, Scott Hollenbeck, Russ Housley, Peter Koch, Olaf M.
|
||||
Kolkman, Ben Laurie, Edward Lewis, John Loughney, Allison Mankin,
|
||||
Douglas Otis, Marcos Sanz, Pekka Savola, Jason Sloderbeck, Samuel
|
||||
Weiler, and Florian Weimer. No doubt the list is incomplete. We
|
||||
apologize to anyone we left out.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 11]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
7. Security Considerations
|
||||
|
||||
By definition, certificates contain their own authenticating
|
||||
signatures. Thus, it is reasonable to store certificates in
|
||||
non-secure DNS zones or to retrieve certificates from DNS with DNS
|
||||
security checking not implemented or deferred for efficiency. The
|
||||
results may be trusted if the certificate chain is verified back to a
|
||||
known trusted key and this conforms with the user's security policy.
|
||||
|
||||
Alternatively, if certificates are retrieved from a secure DNS zone
|
||||
with DNS security checking enabled and are verified by DNS security,
|
||||
the key within the retrieved certificate may be trusted without
|
||||
verifying the certificate chain if this conforms with the user's
|
||||
security policy.
|
||||
|
||||
If an organization chooses to issue certificates for its employees,
|
||||
placing CERT RRs in the DNS by owner name, and if DNSSEC (with NSEC)
|
||||
is in use, it is possible for someone to enumerate all employees of
|
||||
the organization. This is usually not considered desirable, for the
|
||||
same reason that enterprise phone listings are not often publicly
|
||||
published and are even marked confidential.
|
||||
|
||||
Using the URI type introduces another level of indirection that may
|
||||
open a new vulnerability. One method of securing that indirection is
|
||||
to include a hash of the certificate in the URI itself.
|
||||
|
||||
If DNSSEC is used, then the non-existence of a CERT RR and,
|
||||
consequently, certificates or revocation lists can be securely
|
||||
asserted. Without DNSSEC, this is not possible.
|
||||
|
||||
8. IANA Considerations
|
||||
|
||||
The IANA has created a new registry for CERT RR: certificate types.
|
||||
The initial contents of this registry is:
|
||||
|
||||
Decimal Type Meaning Reference
|
||||
------- ---- ------- ---------
|
||||
0 Reserved RFC 4398
|
||||
1 PKIX X.509 as per PKIX RFC 4398
|
||||
2 SPKI SPKI certificate RFC 4398
|
||||
3 PGP OpenPGP packet RFC 4398
|
||||
4 IPKIX The URL of an X.509 data object RFC 4398
|
||||
5 ISPKI The URL of an SPKI certificate RFC 4398
|
||||
6 IPGP The fingerprint and URL RFC 4398
|
||||
of an OpenPGP packet
|
||||
7 ACPKIX Attribute Certificate RFC 4398
|
||||
8 IACPKIX The URL of an Attribute RFC 4398
|
||||
Certificate
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 12]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
9-252 Available for IANA assignment
|
||||
by IETF Standards action
|
||||
253 URI URI private RFC 4398
|
||||
254 OID OID private RFC 4398
|
||||
255 Reserved RFC 4398
|
||||
256-65279 Available for IANA assignment
|
||||
by IETF Consensus
|
||||
65280-65534 Experimental RFC 4398
|
||||
65535 Reserved RFC 4398
|
||||
|
||||
Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
|
||||
only be assigned by an IETF standards action [6]. This document
|
||||
assigns 0x0001 through 0x0008 and 0x00FD and 0x00FE. Certificate
|
||||
types 0x0100 through 0xFEFF are assigned through IETF Consensus [6]
|
||||
based on RFC documentation of the certificate type. The availability
|
||||
of private types under 0x00FD and 0x00FE ought to satisfy most
|
||||
requirements for proprietary or private types.
|
||||
|
||||
The CERT RR reuses the DNS Security Algorithm Numbers registry. In
|
||||
particular, the CERT RR requires that algorithm number 0 remain
|
||||
reserved, as described in Section 2. The IANA will reference the
|
||||
CERT RR as a user of this registry and value 0, in particular.
|
||||
|
||||
9. Changes since RFC 2538
|
||||
|
||||
1. Editorial changes to conform with new document requirements,
|
||||
including splitting reference section into two parts and
|
||||
updating the references to point at latest versions, and to add
|
||||
some additional references.
|
||||
2. Improve terminology. For example replace "PGP" with "OpenPGP",
|
||||
to align with RFC 2440.
|
||||
3. In Section 2.1, clarify that OpenPGP public key data are binary,
|
||||
not the ASCII armored format, and reference 10.1 in RFC 2440 on
|
||||
how to deal with OpenPGP keys, and acknowledge that
|
||||
implementations may handle additional packet types.
|
||||
4. Clarify that integers in the representation format are decimal.
|
||||
5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
|
||||
terminology. Improve reference for Key Tag Algorithm
|
||||
calculations.
|
||||
6. Add examples that suggest use of CNAME to reduce bandwidth.
|
||||
7. In Section 3, appended the last paragraphs that discuss
|
||||
"content-based" vs "purpose-based" owner names. Add Section 3.2
|
||||
for purpose-based X.509 CERT owner names, and Section 3.4 for
|
||||
purpose-based OpenPGP CERT owner names.
|
||||
8. Added size considerations.
|
||||
9. The SPKI types has been reserved, until RFC 2692/2693 is moved
|
||||
from the experimental status.
|
||||
10. Added indirect types IPKIX, ISPKI, IPGP, and IACPKIX.
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 13]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
11. An IANA registry of CERT type values was created.
|
||||
|
||||
10. References
|
||||
|
||||
10.1. Normative References
|
||||
|
||||
[1] Mockapetris, P., "Domain names - concepts and facilities",
|
||||
STD 13, RFC 1034, November 1987.
|
||||
|
||||
[2] Mockapetris, P., "Domain names - implementation and
|
||||
specification", STD 13, RFC 1035, November 1987.
|
||||
|
||||
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
||||
Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[4] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
|
||||
"Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
|
||||
January 1998.
|
||||
|
||||
[5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
|
||||
"OpenPGP Message Format", RFC 2440, November 1998.
|
||||
|
||||
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
|
||||
Considerations Section in RFCs", BCP 26, RFC 2434,
|
||||
October 1998.
|
||||
|
||||
[7] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
|
||||
|
||||
[8] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
|
||||
Public Key Infrastructure Certificate and Certificate
|
||||
Revocation List (CRL) Profile", RFC 3280, April 2002.
|
||||
|
||||
[9] Farrell, S. and R. Housley, "An Internet Attribute Certificate
|
||||
Profile for Authorization", RFC 3281, April 2002.
|
||||
|
||||
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
|
||||
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
|
||||
January 2005.
|
||||
|
||||
[11] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"DNS Security Introduction and Requirements", RFC 4033,
|
||||
March 2005.
|
||||
|
||||
[12] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"Resource Records for the DNS Security Extensions", RFC 4034,
|
||||
March 2005.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 14]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
10.2. Informative References
|
||||
|
||||
[13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
|
||||
RFC 2246, January 1999.
|
||||
|
||||
[14] Kent, S. and K. Seo, "Security Architecture for the Internet
|
||||
Protocol", RFC 4301, December 2005.
|
||||
|
||||
[15] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
|
||||
and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
|
||||
September 1999.
|
||||
|
||||
[16] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
|
||||
RFC 3548, July 2003.
|
||||
|
||||
[17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
|
||||
(S/MIME) Version 3.1 Message Specification", RFC 3851,
|
||||
July 2004.
|
||||
|
||||
[18] Richardson, M., "A Method for Storing IPsec Keying Material in
|
||||
DNS", RFC 4025, March 2005.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 15]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
Appendix A. Copying Conditions
|
||||
|
||||
Regarding the portion of this document that was written by Simon
|
||||
Josefsson ("the author", for the remainder of this section), the
|
||||
author makes no guarantees and is not responsible for any damage
|
||||
resulting from its use. The author grants irrevocable permission to
|
||||
anyone to use, modify, and distribute it in any way that does not
|
||||
diminish the rights of anyone else to use, modify, and distribute it,
|
||||
provided that redistributed derivative works do not contain
|
||||
misleading author or version information. Derivative works need not
|
||||
be licensed under similar terms.
|
||||
|
||||
Author's Address
|
||||
|
||||
Simon Josefsson
|
||||
|
||||
EMail: simon@josefsson.org
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 16]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 17]
|
||||
|
||||
2691
doc/rfc/rfc4408.txt
2691
doc/rfc/rfc4408.txt
File diff suppressed because it is too large
Load Diff
@@ -1,227 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group M. Andrews
|
||||
Request for Comments: 4431 Internet Systems Consortium
|
||||
Category: Informational S. Weiler
|
||||
SPARTA, Inc.
|
||||
February 2006
|
||||
|
||||
|
||||
The DNSSEC Lookaside Validation (DLV) DNS Resource Record
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This memo provides information for the Internet community. It does
|
||||
not specify an Internet standard of any kind. Distribution of this
|
||||
memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
This document defines a new DNS resource record, called the DNSSEC
|
||||
Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors
|
||||
outside of the DNS delegation chain.
|
||||
|
||||
1. Introduction
|
||||
|
||||
DNSSEC [1] [2] [3] authenticates DNS data by building public-key
|
||||
signature chains along the DNS delegation chain from a trust anchor,
|
||||
ideally a trust anchor for the DNS root.
|
||||
|
||||
This document defines a new resource record for publishing such trust
|
||||
anchors outside of the DNS's normal delegation chain. Use of these
|
||||
records by DNSSEC validators is outside the scope of this document,
|
||||
but it is expected that these records will help resolvers validate
|
||||
DNSSEC-signed data from zones whose ancestors either aren't signed or
|
||||
refuse to publish delegation signer (DS) records for their children.
|
||||
|
||||
2. DLV Resource Record
|
||||
|
||||
The DLV resource record has exactly the same wire and presentation
|
||||
formats as the DS resource record, defined in RFC 4034, Section 5.
|
||||
It uses the same IANA-assigned values in the algorithm and digest
|
||||
type fields as the DS record. (Those IANA registries are known as
|
||||
the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
|
||||
Numbers" registries.)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Andrews & Weiler Informational [Page 1]
|
||||
|
||||
RFC 4431 DLV Resource Record February 2006
|
||||
|
||||
|
||||
The DLV record is a normal DNS record type without any special
|
||||
processing requirements. In particular, the DLV record does not
|
||||
inherit any of the special processing or handling requirements of the
|
||||
DS record type (described in Section 3.1.4.1 of RFC 4035). Unlike
|
||||
the DS record, the DLV record may not appear on the parent's side of
|
||||
a zone cut. A DLV record may, however, appear at the apex of a zone.
|
||||
|
||||
3. Security Considerations
|
||||
|
||||
For authoritative servers and resolvers that do not attempt to use
|
||||
DLV RRs as part of DNSSEC validation, there are no particular
|
||||
security concerns -- DLV RRs are just like any other DNS data.
|
||||
|
||||
Software using DLV RRs as part of DNSSEC validation will almost
|
||||
certainly want to impose constraints on their use, but those
|
||||
constraints are best left to be described by the documents that more
|
||||
fully describe the particulars of how the records are used. At a
|
||||
minimum, it would be unwise to use the records without some sort of
|
||||
cryptographic authentication. More likely than not, DNSSEC itself
|
||||
will be used to authenticate the DLV RRs. Depending on how a DLV RR
|
||||
is used, failure to properly authenticate it could lead to
|
||||
significant additional security problems including failure to detect
|
||||
spoofed DNS data.
|
||||
|
||||
RFC 4034, Section 8, describes security considerations specific to
|
||||
the DS RR. Those considerations are equally applicable to DLV RRs.
|
||||
Of particular note, the key tag field is used to help select DNSKEY
|
||||
RRs efficiently, but it does not uniquely identify a single DNSKEY
|
||||
RR. It is possible for two distinct DNSKEY RRs to have the same
|
||||
owner name, the same algorithm type, and the same key tag. An
|
||||
implementation that uses only the key tag to select a DNSKEY RR might
|
||||
select the wrong public key in some circumstances.
|
||||
|
||||
For further discussion of the security implications of DNSSEC, see
|
||||
RFC 4033, RFC 4034, and RFC 4035.
|
||||
|
||||
4. IANA Considerations
|
||||
|
||||
IANA has assigned DNS type code 32769 to the DLV resource record from
|
||||
the Specification Required portion of the DNS Resource Record Type
|
||||
registry, as defined in [4].
|
||||
|
||||
The DLV resource record reuses the same algorithm and digest type
|
||||
registries already used for the DS resource record, currently known
|
||||
as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
|
||||
Numbers" registries.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Andrews & Weiler Informational [Page 2]
|
||||
|
||||
RFC 4431 DLV Resource Record February 2006
|
||||
|
||||
|
||||
5. Normative References
|
||||
|
||||
[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"DNS Security Introduction and Requirements", RFC 4033,
|
||||
March 2005.
|
||||
|
||||
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"Resource Records for the DNS Security Extensions", RFC 4034,
|
||||
March 2005.
|
||||
|
||||
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"Protocol Modifications for the DNS Security Extensions",
|
||||
RFC 4035, March 2005.
|
||||
|
||||
[4] Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain Name
|
||||
System (DNS) IANA Considerations", BCP 42, RFC 2929,
|
||||
September 2000.
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Mark Andrews
|
||||
Internet Systems Consortium
|
||||
950 Charter St.
|
||||
Redwood City, CA 94063
|
||||
US
|
||||
|
||||
EMail: Mark_Andrews@isc.org
|
||||
|
||||
|
||||
Samuel Weiler
|
||||
SPARTA, Inc.
|
||||
7075 Samuel Morse Drive
|
||||
Columbia, Maryland 21046
|
||||
US
|
||||
|
||||
EMail: weiler@tislabs.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Andrews & Weiler Informational [Page 3]
|
||||
|
||||
RFC 4431 DLV Resource Record February 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Andrews & Weiler Informational [Page 4]
|
||||
|
||||
@@ -1,451 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group S. Weiler
|
||||
Request for Comments: 4470 SPARTA, Inc.
|
||||
Updates: 4035, 4034 J. Ihren
|
||||
Category: Standards Track Autonomica AB
|
||||
April 2006
|
||||
|
||||
|
||||
Minimally Covering NSEC Records and DNSSEC On-line Signing
|
||||
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes how to construct DNSSEC NSEC resource records
|
||||
that cover a smaller range of names than called for by RFC 4034. By
|
||||
generating and signing these records on demand, authoritative name
|
||||
servers can effectively stop the disclosure of zone contents
|
||||
otherwise made possible by walking the chain of NSEC records in a
|
||||
signed zone.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................1
|
||||
2. Applicability of This Technique .................................2
|
||||
3. Minimally Covering NSEC Records .................................2
|
||||
4. Better Epsilon Functions ........................................4
|
||||
5. Security Considerations .........................................5
|
||||
6. Acknowledgements ................................................6
|
||||
7. Normative References ............................................6
|
||||
|
||||
1. Introduction
|
||||
|
||||
With DNSSEC [1], an NSEC record lists the next instantiated name in
|
||||
its zone, proving that no names exist in the "span" between the
|
||||
NSEC's owner name and the name in the "next name" field. In this
|
||||
document, an NSEC record is said to "cover" the names between its
|
||||
owner name and next name.
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Standards Track [Page 1]
|
||||
|
||||
RFC 4470 NSEC Epsilon April 2006
|
||||
|
||||
|
||||
Through repeated queries that return NSEC records, it is possible to
|
||||
retrieve all of the names in the zone, a process commonly called
|
||||
"walking" the zone. Some zone owners have policies forbidding zone
|
||||
transfers by arbitrary clients; this side effect of the NSEC
|
||||
architecture subverts those policies.
|
||||
|
||||
This document presents a way to prevent zone walking by constructing
|
||||
NSEC records that cover fewer names. These records can make zone
|
||||
walking take approximately as many queries as simply asking for all
|
||||
possible names in a zone, making zone walking impractical. Some of
|
||||
these records must be created and signed on demand, which requires
|
||||
on-line private keys. Anyone contemplating use of this technique is
|
||||
strongly encouraged to review the discussion of the risks of on-line
|
||||
signing in Section 5.
|
||||
|
||||
1.2. Keywords
|
||||
|
||||
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in RFC 2119 [4].
|
||||
|
||||
2. Applicability of This Technique
|
||||
|
||||
The technique presented here may be useful to a zone owner that wants
|
||||
to use DNSSEC, is concerned about exposure of its zone contents via
|
||||
zone walking, and is willing to bear the costs of on-line signing.
|
||||
|
||||
As discussed in Section 5, on-line signing has several security
|
||||
risks, including an increased likelihood of private keys being
|
||||
disclosed and an increased risk of denial of service attack. Anyone
|
||||
contemplating use of this technique is strongly encouraged to review
|
||||
the discussion of the risks of on-line signing in Section 5.
|
||||
|
||||
Furthermore, at the time this document was published, the DNSEXT
|
||||
working group was actively working on a mechanism to prevent zone
|
||||
walking that does not require on-line signing (tentatively called
|
||||
NSEC3). The new mechanism is likely to expose slightly more
|
||||
information about the zone than this technique (e.g., the number of
|
||||
instantiated names), but it may be preferable to this technique.
|
||||
|
||||
3. Minimally Covering NSEC Records
|
||||
|
||||
This mechanism involves changes to NSEC records for instantiated
|
||||
names, which can still be generated and signed in advance, as well as
|
||||
the on-demand generation and signing of new NSEC records whenever a
|
||||
name must be proven not to exist.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Standards Track [Page 2]
|
||||
|
||||
RFC 4470 NSEC Epsilon April 2006
|
||||
|
||||
|
||||
In the "next name" field of instantiated names' NSEC records, rather
|
||||
than list the next instantiated name in the zone, list any name that
|
||||
falls lexically after the NSEC's owner name and before the next
|
||||
instantiated name in the zone, according to the ordering function in
|
||||
RFC 4034 [2] Section 6.1. This relaxes the requirement in Section
|
||||
4.1.1 of RFC 4034 that the "next name" field contains the next owner
|
||||
name in the zone. This change is expected to be fully compatible
|
||||
with all existing DNSSEC validators. These NSEC records are returned
|
||||
whenever proving something specifically about the owner name (e.g.,
|
||||
that no resource records of a given type appear at that name).
|
||||
|
||||
Whenever an NSEC record is needed to prove the non-existence of a
|
||||
name, a new NSEC record is dynamically produced and signed. The new
|
||||
NSEC record has an owner name lexically before the QNAME but
|
||||
lexically following any existing name and a "next name" lexically
|
||||
following the QNAME but before any existing name.
|
||||
|
||||
The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
|
||||
bits set and SHOULD NOT have any other bits set. This relaxes the
|
||||
requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
|
||||
names that did not exist before the zone was signed.
|
||||
|
||||
The functions to generate the lexically following and proceeding
|
||||
names need not be perfect or consistent, but the generated NSEC
|
||||
records must not cover any existing names. Furthermore, this
|
||||
technique works best when the generated NSEC records cover as few
|
||||
names as possible. In this document, the functions that generate the
|
||||
nearby names are called "epsilon" functions, a reference to the
|
||||
mathematical convention of using the greek letter epsilon to
|
||||
represent small deviations.
|
||||
|
||||
An NSEC record denying the existence of a wildcard may be generated
|
||||
in the same way. Since the NSEC record covering a non-existent
|
||||
wildcard is likely to be used in response to many queries,
|
||||
authoritative name servers using the techniques described here may
|
||||
want to pregenerate or cache that record and its corresponding RRSIG.
|
||||
|
||||
For example, a query for an A record at the non-instantiated name
|
||||
example.com might produce the following two NSEC records, the first
|
||||
denying the existence of the name example.com and the second denying
|
||||
the existence of a wildcard:
|
||||
|
||||
exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
|
||||
|
||||
\).com 3600 IN NSEC +.com ( RRSIG NSEC )
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Standards Track [Page 3]
|
||||
|
||||
RFC 4470 NSEC Epsilon April 2006
|
||||
|
||||
|
||||
Before answering a query with these records, an authoritative server
|
||||
must test for the existence of names between these endpoints. If the
|
||||
generated NSEC would cover existing names (e.g., exampldd.com or
|
||||
*bizarre.example.com), a better epsilon function may be used or the
|
||||
covered name closest to the QNAME could be used as the NSEC owner
|
||||
name or next name, as appropriate. If an existing name is used as
|
||||
the NSEC owner name, that name's real NSEC record MUST be returned.
|
||||
Using the same example, assuming an exampldd.com delegation exists,
|
||||
this record might be returned from the parent:
|
||||
|
||||
exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
|
||||
|
||||
Like every authoritative record in the zone, each generated NSEC
|
||||
record MUST have corresponding RRSIGs generated using each algorithm
|
||||
(but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
|
||||
described in RFC 4035 [3] Section 2.2. To minimize the number of
|
||||
signatures that must be generated, a zone may wish to limit the
|
||||
number of algorithms in its DNSKEY RRset.
|
||||
|
||||
4. Better Epsilon Functions
|
||||
|
||||
Section 6.1 of RFC 4034 defines a strict ordering of DNS names.
|
||||
Working backward from that definition, it should be possible to
|
||||
define epsilon functions that generate the immediately following and
|
||||
preceding names, respectively. This document does not define such
|
||||
functions. Instead, this section presents functions that come
|
||||
reasonably close to the perfect ones. As described above, an
|
||||
authoritative server should still ensure than no generated NSEC
|
||||
covers any existing name.
|
||||
|
||||
To increment a name, add a leading label with a single null (zero-
|
||||
value) octet.
|
||||
|
||||
To decrement a name, decrement the last character of the leftmost
|
||||
label, then fill that label to a length of 63 octets with octets of
|
||||
value 255. To decrement a null (zero-value) octet, remove the octet
|
||||
-- if an empty label is left, remove the label. Defining this
|
||||
function numerically: fill the leftmost label to its maximum length
|
||||
with zeros (numeric, not ASCII zeros) and subtract one.
|
||||
|
||||
In response to a query for the non-existent name foo.example.com,
|
||||
these functions produce NSEC records of the following:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Standards Track [Page 4]
|
||||
|
||||
RFC 4470 NSEC Epsilon April 2006
|
||||
|
||||
|
||||
fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
|
||||
|
||||
\)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
|
||||
|
||||
The first of these NSEC RRs proves that no exact match for
|
||||
foo.example.com exists, and the second proves that there is no
|
||||
wildcard in example.com.
|
||||
|
||||
Both of these functions are imperfect: they do not take into account
|
||||
constraints on number of labels in a name nor total length of a name.
|
||||
As noted in the previous section, though, this technique does not
|
||||
depend on the use of perfect epsilon functions: it is sufficient to
|
||||
test whether any instantiated names fall into the span covered by the
|
||||
generated NSEC and, if so, substitute those instantiated owner names
|
||||
for the NSEC owner name or next name, as appropriate.
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
This approach requires on-demand generation of RRSIG records. This
|
||||
creates several new vulnerabilities.
|
||||
|
||||
First, on-demand signing requires that a zone's authoritative servers
|
||||
have access to its private keys. Storing private keys on well-known
|
||||
Internet-accessible servers may make them more vulnerable to
|
||||
unintended disclosure.
|
||||
|
||||
Second, since generation of digital signatures tends to be
|
||||
computationally demanding, the requirement for on-demand signing
|
||||
makes authoritative servers vulnerable to a denial of service attack.
|
||||
|
||||
Last, if the epsilon functions are predictable, on-demand signing may
|
||||
enable a chosen-plaintext attack on a zone's private keys. Zones
|
||||
using this approach should attempt to use cryptographic algorithms
|
||||
that are resistant to chosen-plaintext attacks. It is worth noting
|
||||
that although DNSSEC has a "mandatory to implement" algorithm, that
|
||||
is a requirement on resolvers and validators -- there is no
|
||||
requirement that a zone be signed with any given algorithm.
|
||||
|
||||
The success of using minimally covering NSEC records to prevent zone
|
||||
walking depends greatly on the quality of the epsilon functions
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Standards Track [Page 5]
|
||||
|
||||
RFC 4470 NSEC Epsilon April 2006
|
||||
|
||||
|
||||
chosen. An increment function that chooses a name obviously derived
|
||||
from the next instantiated name may be easily reverse engineered,
|
||||
destroying the value of this technique. An increment function that
|
||||
always returns a name close to the next instantiated name is likewise
|
||||
a poor choice. Good choices of epsilon functions are the ones that
|
||||
produce the immediately following and preceding names, respectively,
|
||||
though zone administrators may wish to use less perfect functions
|
||||
that return more human-friendly names than the functions described in
|
||||
Section 4 above.
|
||||
|
||||
Another obvious but misguided concern is the danger from synthesized
|
||||
NSEC records being replayed. It is possible for an attacker to
|
||||
replay an old but still validly signed NSEC record after a new name
|
||||
has been added in the span covered by that NSEC, incorrectly proving
|
||||
that there is no record at that name. This danger exists with DNSSEC
|
||||
as defined in [3]. The techniques described here actually decrease
|
||||
the danger, since the span covered by any NSEC record is smaller than
|
||||
before. Choosing better epsilon functions will further reduce this
|
||||
danger.
|
||||
|
||||
6. Acknowledgements
|
||||
|
||||
Many individuals contributed to this design. They include, in
|
||||
addition to the authors of this document, Olaf Kolkman, Ed Lewis,
|
||||
Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
|
||||
Jakob Schlyter, Bill Manning, and Joao Damas.
|
||||
|
||||
In addition, the editors would like to thank Ed Lewis, Scott Rose,
|
||||
and David Blacka for their careful review of the document.
|
||||
|
||||
7. Normative References
|
||||
|
||||
[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"DNS Security Introduction and Requirements", RFC 4033, March
|
||||
2005.
|
||||
|
||||
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"Resource Records for the DNS Security Extensions", RFC 4034,
|
||||
March 2005.
|
||||
|
||||
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"Protocol Modifications for the DNS Security Extensions", RFC
|
||||
4035, March 2005.
|
||||
|
||||
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
||||
Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Standards Track [Page 6]
|
||||
|
||||
RFC 4470 NSEC Epsilon April 2006
|
||||
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Samuel Weiler
|
||||
SPARTA, Inc.
|
||||
7075 Samuel Morse Drive
|
||||
Columbia, Maryland 21046
|
||||
US
|
||||
|
||||
EMail: weiler@tislabs.com
|
||||
|
||||
|
||||
Johan Ihren
|
||||
Autonomica AB
|
||||
Bellmansgatan 30
|
||||
Stockholm SE-118 47
|
||||
Sweden
|
||||
|
||||
EMail: johani@autonomica.se
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Standards Track [Page 7]
|
||||
|
||||
RFC 4470 NSEC Epsilon April 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Standards Track [Page 8]
|
||||
|
||||
6051
doc/rfc/rfc4634.txt
6051
doc/rfc/rfc4634.txt
File diff suppressed because it is too large
Load Diff
1963
doc/rfc/rfc4641.txt
1963
doc/rfc/rfc4641.txt
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user