idnits 2.17.1 draft-rfced-info-atkinson-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 114 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 14 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([Atk95a,Atk95b,, Atk95c]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 231: '...The MUST be associated...' RFC 2119 keyword, line 260: '... KX records MUST always be signed...' RFC 2119 keyword, line 262: '... records MUST be ignored because of ...' RFC 2119 keyword, line 264: '...rrectly validate MUST be ignored becau...' RFC 2119 keyword, line 268: '... KX records MUST be ignored by sy...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 27 has weird spacing: '... node to ac...' == Line 28 has weird spacing: '...d to be used...' == Line 29 has weird spacing: '... only with ...' == Line 32 has weird spacing: '... this mecha...' == Line 37 has weird spacing: '...NS) is the ...' == (109 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1997) is 9784 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Part86' is mentioned on line 62, but not defined == Unused Reference: 'Atk95b' is defined on line 279, but no explicit reference was found in the text == Unused Reference: 'Atk95c' is defined on line 281, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1825 (ref. 'Atk95a') (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (ref. 'Atk95b') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (ref. 'Atk95c') (Obsoleted by RFC 2406) ** Obsolete normative reference: RFC 2065 (ref. 'EK97') (Obsoleted by RFC 2535) ** Obsolete normative reference: RFC 1510 (ref. 'KN93') (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 1036 (ref. 'Mock87b') (Obsoleted by RFC 5536, RFC 5537) Summary: 18 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Randall Atkinson 2 Internet Draft NRL 3 draft-rfced-info-atkinson-00.txt June 1997 5 Key Exchange Delegation Record for the DNS 6 8 STATUS OF THIS MEMO 9 This document is an Internet Draft. Internet Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its Areas, and 11 its working groups. Note that other groups may also distribute working 12 documents as Internet Drafts. 14 Internet Drafts are draft documents valid for a maximum of 6 months. 15 Internet Drafts may be updated, replaced, or obsoleted by other 16 documents at any time. It is not appropriate to use Internet Drafts as 17 reference material or to cite them other than as "work in progress". 19 This particular Internet Draft describes an extension to the Domain 20 Name System that is in limited deployment in certain IP-based networks. 21 It does not specify any level of standard and is not intended for 22 the IETF standards-track. 24 ABSTRACT 26 This note describes a mechanism whereby authorisation for one 27 node to act as key exchanger for a second node is delegated and made 28 available via the Secure DNS. This mechanism is intended to be used 29 only with the Secure DNS. It can be used with several security 30 services. For example, a system seeking to use IP Security [Atk95a, 31 Atk95b, Atk95c] to protect IP packets for a given destination can use 32 this mechanism to determine the set of authorised remote key 33 exchanger systems for that destination. 35 1. INTRODUCTION 37 The Domain Name System (DNS) is the standard way that 38 Internet nodes locate information about addresses, mail exchangers, 39 and other data relating to remote Internet nodes. [Mock87a, Mock87b] 40 More recently, Eastlake and Kaufman have defined standards-track 41 security extensions to the DNS. [EK97] These security extensions can 42 be used to authenticate signed DNS data records and can also be used 43 to store signed public keys in the DNS. 45 The KX record is useful in providing an authenticatible 46 method of delegating authorisation for one node to provide key 47 exchange services on behalf of one or more, possibly different, 48 nodes. This note specifies the syntax and semantics of the KX 49 record, which is currently in limited deployment in certain IP-based 50 networks. The reader is assumed to be familiar with the basics of 51 DNS, including familiarity with [Mock87a, Mock87b]. This document is 52 not on the IETF standards-track and does not specify any level of 53 standard. This document merely provides information for the Internet 54 community. 56 2. APPROACH 58 This document specifies a new kind of DNS Resource Record 59 (RR), known as the Key Exchanger (KX) record. A Key Exchanger Record 60 has the mnemonic "KX" and the type code of . 61 Each KX record is associated with a fully-qualified domain name. The 62 KX record is modeled on the MX record described in [Part86]. Any 63 given domain, subdomain, or host entry in the DNS might have a KX 64 record. 66 2.1 IPsec Examples 68 In these two examples, let S be the originating node and let 69 D be the destination node. R1 and R2 are IPsec-capable routers. The 70 path from S to D goes via first R1 and later R2. The return path 71 from D to S goes via first R2 and later R1. IETF-standard IP 72 Security uses unidirectional Security Associations [Atk95a]. 73 Therefore, a typical IP session will use a pair of related Security 74 Associations, one in each direction. The examples below talk about 75 how to setup an example Security Association, but in practice a pair 76 of matched Security Associations will normally be used. 78 2.1.1 Subnet-to-Subnet Example 80 If neither S nor D implements IPsec, security can still be 81 provided between R1 and R2 by building a secure tunnel. This can use 82 either AH or ESP. 84 In this example, the decision to provide the IPsec service 85 for traffic from R1 destined for R2 is made by R1. Once R1 has 86 decided that the packet to D should be protected, it performs a 87 secure DNS lookup for the records associated with domain D. If these 88 records include a KX record for the IPsec service, then R1 knows 89 which set of nodes are possible key exchanger nodes for the 90 destination D. In this example, let there be at least one KX record 91 for D and let the most preferred KX record for D point at R2. R1 92 then selects a key exchanger (in this example, R2) for D from the 93 list obtained from the secure DNS. Then R1 initiates a key 94 management session with that key exchanger (in this example, R2) to 95 setup an IPsec Security Association between R1 and D on behalf of S. 96 R2 is able to authenticate the delegation of Key Exchanger 97 authorisation for target S to R1 by making an authenticated DNS 98 lookup for KX records associated with S and verifying that at least 99 one such record points to R1. 101 If the key exchanger for D (in this example, R2) 102 authentically informs R1 via the key management that the IPsec 103 Security Association should have source address of S, proxy address 104 of R1, and destination address of R2, then R1 sets up such an 105 association with R2 to protect traffic from S to D. Otherwise, R1 106 creates an IPsec Security Association for a secure tunnel with source 107 address of S, proxy address of R1, and destination address of D via 108 negotiation with D's key exchanger. In each case, the Security 109 Association has a source identity that is either (1) S or (2) an 110 address range that includes S's address. Once the IPsec Security 111 Association has been created, then R1 uses it to protect traffic from 112 S destined for D. The destination identity is either (1) D or (2) an 113 address range that includes the destination address. 115 2.1.2 Subnet-to-Host Example 117 If D implements IPsec but S does not implement IPsec, then 118 things are more interesting. In this case, R1 determines that the 119 security service is needed for the packet. Then R1 performs the 120 secure DNS lookup for D and determines that D is its own key 121 exchanger either from the existence of a KX record for domain D 122 pointing to domain D or from an authenticated DNS response indicating 123 that no KX record exists for domain D. R1 then initiates key 124 management with D to create an IPsec Security Association on behalf 125 of S. D can verify that R1 is authorised to create an IPsec Security 126 Association on behalf of S by performing a DNS KX record lookup for 127 target S. If there is no authenticated DNS response indicating that 128 R1 is an authorised key exchanger for S, then D will not accept the 129 SA negotiation from R1 on behalf of identity S. 131 If the IPsec Security Association is accepted and 132 established, it has a source address of S, a proxy address of R1, and 133 a destination address of D. This IPsec Security Association has a 134 source identity that is either (1) S or (2) an address range that 135 includes S's address and a destination identity that is either (1) D 136 or (2) an address range that includes D's address. 138 Finally, R1 begins providing the security service for packets 140 from S that transit R1 destined for D. When D receives such packets, 141 D examines the SA information during IPsec input processing and sees 142 that R1's address is listed as valid proxy address for that SA and 143 that S is the source address for that SA. Hence, D knows at input 144 processing time that R1 is authorised to provide security on behalf 145 of S. Therefore packets coming from R1 with valid IP security that 146 claim to be from S are trusted by D to have really come from S. 148 2.1.3 Host to Subnet Example 150 Now consider the above case from D's perspective (i.e. where 151 D is sending IP packets to S). The same concept applies. However, 152 in this case, D determines that the security service is needed for 153 the packets to S. Then D performs the secure DNS lookup for S and 154 discovers that a KX record for S exists and points at R1. D then 155 initiates key management with R1, where R1 is acting on behalf of S, 156 to create an appropriate Security Association. 158 If R1 indicates to D via key management that the IPsec 159 Security Association should be between D and R1, then the IPsec 160 Security Association is setup as a secure tunnel with a source 161 address of D, a destination address of R1, source identity of either 162 (1) D or (2) an address range including D, and a destination identity 163 of either (1) S or (2) an address range including S. 165 Otherwise, the IPsec Security Association is setup with 166 source address of D, destination address of S, source identity of 167 either (1) D or (2) an address range including D, and a destination 168 identity of either (1) S or (2) an address range including S. 170 Finally, D sends secured IP packets to the IPsec SA's 171 destination. If the IPsec SA destination is R1, then R1 receives 172 those packets, provides IPsec input processing, and forwards valid 173 packets along to S. Again, authenticated DNS lookups for KX records 174 is used to authenticate the delegation of Key Exchanger authority for 175 a particular identity to a particular Key Exchanger node. 177 2.2 Other Examples 179 This mechanism can be extended for use with other services as 180 well. For example, consider a destination node implementing IPsec 181 that can only obtain its Security Association information from a key 182 distribution center (for example, using Kerberos [KN93]). If that 183 node's key distribution center implemented key management gateway 184 capabilities that could negotiate security associations using a 185 different key management protocol (e.g. ISAKMP), then that 186 destination node might have a KX record pointing at its key 187 distribution center. 189 In the event the initiator were not using the KDC but the 190 target was an IPsec node that only used the KDC, the initiator would 191 find the KX record for the target pointing at the KDC. Then, the 192 external key management exchange (e.g. ISAKMP) would be between the 193 initiator and the KDC. Then the KDC would distribute the IPsec SA to 194 the KDC-only IPsec node using the KDC. The IPsec traffic itself 195 could travel directly between the initiator and the destination node. 197 In the event the initiator could only use the KDC and the target 198 were not using the KDC, the initiator would send its request for a 199 key to the KDC. The KDC would then initiate an external key 200 management exchange (e.g. ISAKMP) with a node that the target's KX 201 record(s) pointed to, on behalf of the node that could only use the 202 KDC. The target could verify that the KDC were allowed to proxy for 203 the node only using the KDC by looking up the KX records for that 204 node only using the KDC and finding a pointer to the KDC. The 205 external key exchange would be performed between the KDC and the 206 target. Then the KDC would distribute the IPsec SA to the initiator. 207 Again, IPsec traffic itself travels directly between the initiator 208 and the destination. 210 3. SYNTAX OF KX RECORD 212 A KX record has the DNS TYPE of "KX" and a numeric value of . A KX record is a member of the Internet ("IN") 214 CLASS in the DNS. Each KX record is associated with a 215 entry in the DNS. A KX record has the following textual syntax: 217 IN KX 219 For this description, let the item to the left of the 220 "KX" string be called and the item to 221 the right of the "KX" string be called . 222 is a non-negative integer. 224 Internet nodes about to initiate a key exchange with should instead contact to initiate the key 226 exchange for a security service between the initiator and . If more than one KX record exists for , then 228 the field is used to indicate preference among the 229 systems delegated to. Lower values are preferred over higher values. 230 The is authorised to provide key exchange services on 231 behalf of . The MUST be associated 232 with either a Fully Qualified Domain Name, a CNAME record, an A 233 record, or an AAAA record. 235 3.1 KX RDATA format 237 The KX DNS record has the following RDATA format: 239 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 240 | PREFERENCE | 241 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 242 / EXCHANGER / 243 / / 244 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 246 where: 248 PREFERENCE A 16 bit non-negative integer which specifies the 249 preference given to this RR among other KX records 250 at the same owner. Lower values are preferred. 252 EXCHANGER A which specifies a host willing to act as 253 a mail exchange for the owner name. 255 KX records cause type A additional section processing for the host 256 specified by EXCHANGER. 258 4. SECURITY CONSIDERATIONS 260 KX records MUST always be signed using the method(s) defined 261 by the DNS Security extensions specified in [EK97]. All unsigned KX 262 records MUST be ignored because of the security vulnerability caused 263 by assuming that unsigned records are valid. All signed KX records 264 whose signatures do not correctly validate MUST be ignored because of 265 the potential security vulnerability in trusting an invalid KX 266 record. 268 KX records MUST be ignored by systems not implementing Secure 269 DNS because such systems have no mechanism to authenticate the KX 270 record. 272 Myriad serious security vulnerabilities can arise if the 273 above restrictions are not strictly adhered to. 275 5. REFERENCES 277 [Atk95a] R. Atkinson, "IP Security Architecture", RFC-1825, August 1995. 279 [Atk95b] R. Atkinson, "IP Authentication Header", RFC-1826, August 1995. 281 [Atk95c] R. Atkinson, "IP Encapsulating Security Payload", RFC-1827, 282 August 1995. 284 [EK97] D. Eastlake, C. Kaufman, "Domain Name System Security Extensions", 285 RFC-2065, 3 January 1997. 287 [KN93] J. Kohl & B. Neuman, "The Kerberos Network Authentication Service", 288 RFC-1510, 10 September 1993. 290 [Mock87a] P. Mockapetris, "Domain names - implementation and specification", 291 RFC-1035, 1 November 1987. 293 [Mock87b] P. Mockapetris, "Domain names - concepts and facilities", 294 RFC-1036, 1 November 1987 296 ACKNOWLEDGEMENTS 298 Development of this DNS record was primarily performed during 299 1993 through 1995. The author's work on this was sponsored jointly 300 by the Computing Systems Technology Office (CSTO) of the Advanced 301 Research Projects Agency (ARPA) and by the Information Security 302 Program Office (PD71E), Space & Naval Warface Systems Command 303 (SPAWAR). 305 AUTHOR'S ADDRESS: 307 Randall Atkinson 308 Code 5544 309 Naval Research Laboratory 310 4555 Overlook Avenue, SW 311 Washington, DC 20375-5337 313 Email: rja@cs.nrl.navy.mil 314 Telephone: (DSN) 354-8590 316 --PART-BOUNDARY=.1970606161952.ZM10146.eos.home.net--