As per Relevance of the word association, we have this rfc below:
Network Working Group R.
Request for Comments: 2230
Category: Informational November 1997
Key Exchange Delegation Record for the
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1997). All Rights Reserved
This note describes a mechanism whereby authorisation for one node
act as key exchanger for a second node is delegated and
available via the Secure DNS. This mechanism is intended to be
only with the Secure DNS. It can be used with several
services. For example, a system seeking to use IP Security [RFC
1825, RFC-1826, RFC-1827] to protect IP packets for a
destination can use this mechanism to determine the set of
remote key exchanger systems for that destination
1.
The Domain Name System (DNS) is the standard way that Internet
locate information about addresses, mail exchangers, and other
relating to remote Internet nodes. [RFC-1035, RFC-1034]
recently, Eastlake and Kaufman have defined standards-track
extensions to the DNS. [RFC-2065] These security extensions can
used to authenticate signed DNS data records and can also be used
store signed public keys in the DNS
The KX record is useful in providing an authenticatible method
delegating authorisation for one node to provide key
services on behalf of one or more, possibly different, nodes.
note specifies the syntax and semantics of the KX record, which
currently in limited deployment in certain IP-based networks.
Atkinson Informational [Page 1]
RFC 2230 DNS Key Exchange Delegation Record November 1997
reader is assumed to be familiar with the basics of DNS,
familiarity with [RFC-1035, RFC-1034]. This document is not on
IETF standards-track and does not specify any level of standard
This document merely provides information for the Internet community
1.1 Identity
This document relies upon the concept of "identity domination".
concept might be new to the reader and so is explained in
section. The subject of endpoint naming for security
has historically been somewhat contentious. This document takes
position on what forms of identity should be used. In a network
there are several forms of identity that are possible
For example, IP Security has defined notions of identity
include: IP Address, IP Address Range, Connection ID, Fully-
Domain Name (FQDN), and User with Fully Qualified Domain Name (
FQDN).
A USER FQDN identity dominates a FQDN identity. A FQDN identity
turn dominates an IP Address identity. Similarly, a Connection
dominates an IP Address identity. An IP Address Range dominates
IP Address identity for each IP address within that IP address range
Also, for completeness, an IP Address identity is considered
dominate itself
2.
This document specifies a new kind of DNS Resource Record (RR),
as the Key Exchanger (KX) record. A Key Exchanger Record has
mnemonic "KX" and the type code of 36. Each KX record is
with a fully-qualified domain name. The KX record is modeled on
MX record described in [Part86]. Any given domain, subdomain, or
entry in the DNS might have a KX record
2.1 IPsec
In these two examples, let S be the originating node and let D be
destination node. S2 is another node on the same subnet as S. D2
another node on the same subnet as D. R1 and R2 are IPsec-
routers. The path from S to D goes via first R1 and later R2.
return path from D to S goes via first R2 and later R1.
IETF-standard IP Security uses unidirectional Security
[RFC-1825]. Therefore, a typical IP session will use a pair
related Security Associations, one in each direction. The
below talk about how to setup an example Security Association, but
practice a pair of matched Security Associations will normally
Atkinson Informational [Page 2]
RFC 2230 DNS Key Exchange Delegation Record November 1997
used
2.1.1 Subnet-to-Subnet
If neither S nor D implements IPsec, security can still be
between R1 and R2 by building a secure tunnel. This can use
AH or ESP
S ---+ +----
| |
+- R1 -----[zero or more routers]-------R2-+
| |
S2---+ +----D
Figure 1: Network Diagram for Subnet-to-Subnet
In this example, R1 makes the policy decision to provide the
service for traffic from R1 destined for R2. Once R1 has
that the packet from S to D should be protected, it performs a
DNS lookup for the records associated with domain D. If R1
knows the IP address for D, then a secure reverse DNS lookup will
necessary to determine the domain D, before that forward secure
lookup for records associated with domain D. If these DNS records
domain D include a KX record for the IPsec service, then R1
which set of nodes are authorised key exchanger nodes for
destination D
In this example, let there be at least one KX record for D and
the most preferred KX record for D point at R2. R1 then selects
key exchanger (in this example, R2) for D from the list obtained
the secure DNS. Then R1 initiates a key management session with
key exchanger (in this example, R2) to setup an IPsec
Association between R1 and D. In this example, R1 knows (either
seeing an outbound packet arriving from S destined to D or via
methods) that S will be sending traffic to D. In this example R1'
policy requires that traffic from S to D should be segregated
least on a host-to-host basis, so R1 desires an IPsec
Association with source identity that dominates S, proxy
that dominates R1, and destination identity that dominates R2.
In turn, R2 is able to authenticate the delegation of Key
authorisation for target S to R1 by making an authenticated
DNS lookup for KX records associated with S and verifying that
least one such record points to R1. The identity S is
given to R2 as part of the key management process between R1 and R2.
Atkinson Informational [Page 3]
RFC 2230 DNS Key Exchange Delegation Record November 1997
If D initially only knows the IP address of S, then it will need
perform a secure reverse DNS lookup to obtain the fully-
domain name for S prior to that secure forward DNS lookup
If R2 does not receive an authenticated DNS response indicating
R1 is an authorised key exchanger for S, then D will not accept
SA negotiation from R1 on behalf of identity S
If the proposed IPsec Security Association is acceptable to both R
and R2, each of which might have separate policies, then they
that IPsec Security Association via Key Management
Note that for unicast traffic, Key Management will typically
setup a separate (but related) IPsec Security Association for
return traffic. That return IPsec Security Association will
equivalent identities. In this example, that return IPsec
Association will have a source identity that dominates D, a
identity that dominates R2, and a destination identity that
R1.
Once the IPsec Security Association has been created, then R1 uses
to protect traffic from S destined for D via a secure tunnel
originates at R1 and terminates at R2. For the case of unicast, R
will use the return IPsec Security Association to protect
from D destined for S via a secure tunnel that originates at R2
terminates at R1.
2.1.2 Subnet-to-Host
Consider the case where D and R1 implement IPsec, but S does
implement IPsec, which is an interesting variation on the
example. This example is shown in Figure 2 below
S ---+
|
+- R1 -----[zero or more routers]-------
|
S2---+
Figure 2: Network Diagram for Subnet-to-Host
In this example, R1 makes the policy decision that IP Security
needed for the packet travelling from S to D. Then, R1 performs
secure DNS lookup for D and determines that D is its own
exchanger, either from the existence of a KX record for D pointing
D or from an authenticated DNS response indicating that no KX
exists for D. If R1 does not initially know the domain name of D
then prior to the above forward secure DNS lookup, R1 performs
Atkinson Informational [Page 4]
RFC 2230 DNS Key Exchange Delegation Record November 1997
secure reverse DNS lookup on the IP address of D to determine
fully-qualified domain name for that IP address. R1 then
key management with D to create an IPsec Security Association
behalf of S
In turn, D can verify that R1 is authorised to create an
Security Association on behalf of S by performing a DNS KX
lookup for target S. R1 usually provides identity S to D via
management. If D only has the IP address of S, then D will need
perform a secure reverse lookup on the IP address of S to
domain name S prior to the secure forward DNS lookup on S to
the KX records for S
If D does not receive an authenticated DNS response indicating
R1 is an authorised key exchanger for S, then D will not accept
SA negotiation from R1 on behalf of identity S
If the IPsec Security Association is successfully established
R1 and D, that IPsec Security Association has a source identity
dominates S's IP address, a proxy identity that dominates R1's
address, and a destination identity that dominates D's IP address
Finally, R1 begins providing the security service for packets from
that transit R1 destined for D. When D receives such packets,
examines the SA information during IPsec input processing and
that R1's address is listed as valid proxy address for that SA
that S is the source address for that SA. Hence, D knows at
processing time that R1 is authorised to provide security on
of S. Therefore packets coming from R1 with valid IP security
claim to be from S are trusted by D to have really come from S
2.1.3 Host to Subnet
Now consider the above case from D's perspective (i.e. where D
sending IP packets to S). This variant is sometimes known as
Mobile Host or "roadwarrier" case. The same basic concepts apply,
the details are covered here in hope of improved clarity
S ---+
|
+- R1 -----[zero or more routers]-------
|
S2---+
Figure 3: Network Diagram for Host-to-Subnet
Atkinson Informational [Page 5]
RFC 2230 DNS Key Exchange Delegation Record November 1997
In this example, D makes the policy decision that IP Security
needed for the packets from D to S. Then D performs the secure
lookup for S and discovers that a KX record for S exists and
at R1. If D only has the IP address of S, then it performs a
reverse DNS lookup on the IP address of S prior to the forward
DNS lookup for S
D then initiates key management with R1, where R1 is acting on
of S, to create an appropriate Security Association. Because D
acting as its own key exchanger, R1 does not need to perform a
DNS lookup for KX records associated with D
D and R1 then create an appropriate IPsec Security
Association. This IPsec Security Association is setup as a
tunnel with a source identity that dominates D's IP Address and
destination identity that dominates R1's IP Address. Because
performs IPsec for itself, no proxy identity is needed in this
Security Association. If the proxy identity is non-null in
situation, then the proxy identity must dominate D's IP Address
Finally, D sends secured IP packets to R1. R1 receives
packets, provides IPsec input processing (including
inner/outer IP address validation), and forwards valid packets
to S
2.2 Other
This mechanism can be extended for use with other services as well
To give some insight into other possible uses, this section
use of KX records in environments using a Key Distribution
(KDC), such as Kerberos [KN93], and a possible use of KX records
conjunction with mobile nodes accessing the network via a
service
2.2.1 KDC
This example considers the situation of a destination
implementing IPsec that can only obtain its Security
information from a Key Distribution Center (KDC). Let the
implement both the KDC protocol and also a non-KDC key
protocol (e.g. ISAKMP). In such a case, each client node of the
might have its own KX record pointing at the KDC so that nodes
implementing the KDC protocol can still create Security
with each of the client nodes of the KDC
In the event the session initiator were not using the KDC but
session target was an IPsec node that only used the KDC,
initiator would find the KX record for the target pointing at
Atkinson Informational [Page 6]
RFC 2230 DNS Key Exchange Delegation Record November 1997
KDC. Then, the external key management exchange (e.g. ISAKMP)
be between the initiator and the KDC. Then the KDC would
the IPsec SA to the KDC-only IPsec node using the KDC. The
traffic itself could travel directly between the initiator and
destination node
In the event the initiator node could only use the KDC and the
were not using the KDC, the initiator would send its request for
key to the KDC. The KDC would then initiate an external
management exchange (e.g. ISAKMP) with a node that the target's
record(s) pointed to, on behalf of the initiator node
The target node could verify that the KDC were allowed to proxy
the initiator node by looking up the KX records for the
node and finding a KX record for the initiator that listed the KDC
Then the external key exchange would be performed between the KDC
the target node. Then the KDC would distribute the resulting
Security Association to the initiator. Again, IPsec traffic
could travel directly between the initiator and the destination
2.2.2 Dial-Up Host
This example outlines a possible use of KX records with mobile
that dial into the network via PPP and are dynamically assigned an
address and domain-name at dial-in time
Consider the situation where each mobile node is dynamically
both a domain name and an IP address at the time that node dials
the network. Let the policy require that each mobile node act as
own Key Exchanger. In this case, it is important that dial-in
use addresses from one or more well known IP subnets or address
dedicated to dial-in access. If that is true, then no KX record
other action is needed to ensure that each node will act as its
Key Exchanger because lack of a KX record indicates that the node
its own Key Exchanger
Consider the situation where the mobile node's domain name
constant but its IP address changes. Let the policy require
each mobile node act as its own Key Exchanger. In this case,
might be operational problems when another node attempts to perform
secure reverse DNS lookup on the IP address to determine
corresponding domain name. The authenticated DNS binding (in
form of a PTR record) between the mobile node's currently assigned
address and its permanent domain name will need to be
updated each time the node is assigned a new IP address. There
no mechanisms for accomplishing this that are both IETF-standard
widely deployed as of the time this note was written. Use of
Atkinson Informational [Page 7]
RFC 2230 DNS Key Exchange Delegation Record November 1997
DNS Update without authentication is a significant security risk
hence is not recommended for this situation
3. SYNTAX OF KX
A KX record has the DNS TYPE of "KX" and a numeric value of 36. A
record is a member of the Internet ("IN") CLASS in the DNS. Each
record is associated with a entry in the DNS. A
record has the following textual syntax
IN KX <preference>
For this description, let the item to the left of
"KX" string be called and the item
the right of the "KX" string be called . <preference
is a non-negative integer
Internet nodes about to initiate a key exchange with
should instead contact to initiate the key
for a security service between the initiator and .
more than one KX record exists for , then
<preference> field is used to indicate preference among the
delegated to. Lower values are preferred over higher values.
is authorised to provide key exchange services
behalf of . The MUST have a
record, an A record, or an AAAA record associated with it
3.1 KX RDATA
The KX DNS record has the following RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EXCHANGER /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where
PREFERENCE A 16 bit non-negative integer which specifies
preference given to this RR among other KX
at the same owner. Lower values are preferred
EXCHANGER A which specifies a host willing
act as a mail exchange for the owner name
Atkinson Informational [Page 8]
RFC 2230 DNS Key Exchange Delegation Record November 1997
KX records MUST cause type A additional section processing for
host specified by EXCHANGER. In the event that the host
the DNS transaction supports IPv6, KX records MUST also cause
AAAA additional section processing
The KX RDATA field MUST NOT be compressed
4. SECURITY
KX records MUST always be signed using the method(s) defined by
DNS Security extensions specified in [RFC-2065]. All unsigned
records MUST be ignored because of the security vulnerability
by assuming that unsigned records are valid. All signed KX
whose signatures do not correctly validate MUST be ignored because
the potential security vulnerability in trusting an invalid
record
KX records MUST be ignored by systems not implementing Secure
because such systems have no mechanism to authenticate the KX record
If a node does not have a permanent DNS entry and some form
Dynamic DNS Update is in use, then those dynamic DNS updates MUST
fully authenticated to prevent an adversary from injecting false
records (especially the KX, A, and PTR records) into the Domain
System. If false records were inserted into the DNS without
signed by the Secure DNS mechanisms, then a denial-of-service
results. If false records were inserted into the DNS and
(erroneously) signed by the signing authority, then an active
results
Myriad serious security vulnerabilities can arise if the
throuhout this document are not strictly adhered to.
should carefully consider the openly published issues relating to
security [Bell95,Vixie95] as they build their implementations
Readers should also consider the security considerations discussed
the DNS Security Extensions document [RFC-2065].
5.
[RFC-1825] Atkinson, R., "IP Authentication Header", RFC 1826,
August 1995.
[RFC-1827] Atkinson, R., "IP Encapsulating Security Payload",
RFC 1827, August 1995.
Atkinson Informational [Page 9]
RFC 2230 DNS Key Exchange Delegation Record November 1997
[Bell95] Bellovin, S., "Using the Domain Name System for
Break-ins", Proceedings of 5th USENIX UNIX
Symposium, USENIX Association, Berkeley, CA, June 1995.
ftp://ftp.research.att.com/dist/smb/dnshack.
[RFC-2065] Eastlake, D., and C. Kaufman, "Domain Name
Security Extensions", RFC 2065, January 1997.
[RFC-1510] Kohl J., and C. Neuman, "The Kerberos
Authentication Service", RFC 1510, September 1993.
[RFC-1035] Mockapetris, P., "Domain names - implementation
specification", STD 13, RFC 1035, November 1987.
[RFC-1034] Mockapetris, P., "Domain names - concepts
facilities", STD 13, RFC 1034, November 1987.
[Vixie95] P. Vixie, "DNS and BIND Security Issues", Proceedings
the 5th USENIX UNIX Security Symposium,
Association, Berkeley, CA, June 1995.
ftp://ftp.vix.com/pri/vixie/bindsec.
Development of this DNS record was primarily performed during 1993
through 1995. The author's work on this was sponsored jointly by
Computing Systems Technology Office (CSTO) of the Advanced
Projects Agency (ARPA) and by the Information Security Program
(PD71E), Space & Naval Warface Systems Command (SPAWAR). In
era, Dave Mihelcic and others provided detailed review
constructive feedback. More recently, Bob Moscowitz and Todd
provided detailed review and constructive feedback of a work
progress version of this document
AUTHOR'S
Randall
Code 5544
Naval Research
4555 Overlook Avenue,
Washington, DC 20375-5337
Phone: (DSN) 354-8590
EMail: atkinson@itd.nrl.navy.
Atkinson Informational [Page 10]
RFC 2230 DNS Key Exchange Delegation Record November 1997
Full Copyright
Copyright (C) The Internet Society (1997). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implmentation may be prepared, copied,
andand distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Atkinson Informational [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
