One document matched: draft-moskowitz-hip-dns-00.txt
Storage of HIP information in DNS
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
This memo describes how HIP Public Key Hashes [HIP], and public keys
can be stored in DNS.
2. Conventions used in 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. Introduction
HIP is designed to work with Public Key technology like DSA. It
does not use X.509 certificates to hold and transport these keys,
nor to authenticate the owner of the keys. In those cases where it
is desired to authenticate the owner of the HIP keys, DNS can be
used as the storage media and the retrieval mechanism.
4. Background
Moskowitz 1
Storage of HIP information in DNS June 1999
One of the design goals of HIP was to provide for reliable host
identifiers, but also to allow for anonymous behavior where desired.
The later was achieved in the basic structure of HIP where identity
is pasted in band in the HIP payload. This identity can be as much
or as little as desired, and it is not internally authenticatable.
The common practice in most protocols is to provide authenticated
identity via X.509 certificates. The basic design of HIP, that is
its heavy use of DNS record formats, lends it to using secure DNS
[DNSSEC] as its preferred media for host authentication.
5. DNS Resource Records used by HIP
A number of RR are defined in the HIP protocol. Most notably DSA
RRs and NULL (or name) RRs. D-H RRs are also used to enable
encryption [HIP ENC]. Whereas the DSA RR is the principle RR used
to provide the DSA public key, the NULL RR is simply used to convey
an FQDN without any additional baggage.
The RRs that would minimally be placed in DNS would be DSA, A, and
SIG. An A record is not used when there is no binding of an IP
address with the host. Examples of this are multi-homed hosts and
dial up hosts.
5.1. DSA Resource Records
DSA RRs [DSA RR] are the primary resource records in HIP. By
placing this information in DNS, the host that receives the DSA RR
in band will be able to authenticate the information and establish a
trust identity for the sending host.
5.2. Host names
A host name is needed with the DSA record and any other record in
DNS [DNS]. Since this particular usage of DNS is for HIP
authentication, the host name SHOULD contain the HIP Public Key Hash
(PKH). Given a PKH of: 1385 D17F C639 61F5, the host name SHOULD be
1385.D17F.C639.61F5, making the Full Qualified Domain Name something
like 1385.D17F.C639.61F5.HIP.foo.tld. Since names in DNS can have
dots, there is no need to maintain an artificial hierarchy for the
apparent three 'zones' within the host name. The use of the dot
here is not to represent DNS zones, but rather a sound convention
for representing the PKH. This follows a frequent practice found in
IN-ADDR-ARPA records in some networks that have B or A class address
blocks.
5.3. A Resource Records
The A record associates the name of the host with its IP address.
AN A record should only be used where there is an IP address for
such a binding. The A record is optional. For those hosts that
Moskowitz 2
Storage of HIP information in DNS June 1999
have multiple addresses, use dynamic addresses, or are behind a NAT,
the A record SHOULD be omitted.
The host has the FQDN for DNS query either from the HIP payload, or
from information previously loaded in the host.
5.4. SIG Resource Records
Since the purpose of using DNS is to provide authentication of the
DSA RR, the SIG record MUST be present.
6. Security Considerations
HIP is using DNS to authenticate the public keys used. Thus DNSSEC
MUST be used to protect all associated DNS records.
7. IANA Considerations
There are no additional IANA Considerations beyond those in IPsec
and HIP.
8. References
[HIP], Moskowitz, R., "The Host Identity Payload", draft-ietf-
moskowitz-HIP-00.txt, May 1999.
[RFC-2119], Bradner, S, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997
[HIP_ENC], Moskowitz, R., "ESP Encryption support in HIP", draft-
ietf-moskowitz-HIP-ENC-00.txt, May 1999.
[DNS], Mockapetris, P., "Domain Names - Implementation And
Specification", RFC 1035, November 1987.
[DNSSEC], Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[DSA_RR], Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
9. Acknowledgments
The original thoughts on DNS storage of HIP information were
properly shredded by Keith Moore, Patrik F„ltstr÷m, Harald
Alvestrand, and Hugh Daniels. Further conversations with Hugh lead
to this simpler, more manageable model.
10. Author's Addresses
Moskowitz 3
Storage of HIP information in DNS June 1999
Robert Moskowitz
ICSA, Inc.
1200 Walnut Bottom Rd.
Carlisle, PA 17013
Email: rgm@icsa.net
Moskowitz 4
| PAFTECH AB 2003-2026 | 2026-04-22 21:20:46 |