idnits 2.17.1 draft-ietf-ipsec-isakmp-mode-cfg-02.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-04-26) 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. == There is 1 instance of lines with non-ascii characters in the document. == 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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 12, 1998) is 9570 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: 'Thayer97' is mentioned on line 71, but not defined == Missing Reference: 'Radius' is mentioned on line 344, but not defined == Unused Reference: 'Radius97' is defined on line 382, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-arch-sec-01 == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-isakmp-08 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp (ref. 'ISAKMP') == Outdated reference: A later version (-07) exists of draft-ietf-ipsec-isakmp-oakley-05 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp-oakley (ref. 'Harkins97') ** Obsolete normative reference: RFC 2138 (ref. 'Radius97') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2251 (ref. 'Ldap97') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force R. Pereira, TimeStep Corp. 2 IP Security Working Group S. Anand, Microsoft Corp. 3 Internet Draft B. Patel, Intel Corp. 4 Expires in six months 5 February 12, 1998 7 The ISAKMP Configuration Method 8 10 Status of this Memo 12 This document is a submission to the IETF Internet Protocol 13 Security (IPSECond) Working Group. Comments are solicited and 14 should be addressed to the working group mailing list 15 (ipsec@tis.com) or to the editor. 17 This document is an Internet-Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts. 22 Internet-Drafts draft documents are valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 To learn the current status of any Internet-Draft, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Distribution of this memo is unlimited. 36 Abstract 38 This document describes a new ISAKMP method that allows information 39 like configuration items to be exchanged securely by using both 40 push/acknowledge or request/reply paradigms. 42 Internet Draft The ISAKMP Configuration Method February, 98 44 Table of Contents 46 1. Introduction...................................................2 47 1.1. Specification of Requirements..............................2 48 2. Configuration And Information Method...........................3 49 3. Configuration Transaction......................................3 50 3.1. Configuration NOTIFY Codes.................................4 51 3.2. Configuration NOTIFY Data And Attributes...................5 52 3.3. Retransmission.............................................6 53 4. Examples.......................................................6 54 5. Enterprise Management Considerations...........................8 55 6. Security Considerations........................................8 56 7. References.....................................................9 57 8. Acknowledgments................................................9 58 9. Editors' Addresses.............................................9 60 1. Introduction 62 ISAKMP provides a framework to negotiate and derive Security 63 Associations, but since it is used within the IPSec framework it 64 may also be used to configure or retrieve information from secure 65 hosts. This configuration may take place between a gateway, an 66 end-host client, or a configuration manager. For example, this can 67 be used to configure multi-protocol IP tunnels securely. 69 It is assumed that the reader is familiar with the terms and 70 concepts described in the "Security Architecture for the Internet 71 Protocol" [Atkinso95] and "IP Security Document Roadmap" [Thayer97] 72 documents. 74 Readers are advised to be familiar with both [Harkins97] and 75 [ISAKMP] because of the terminology used within this document and 76 the fact that this document is an extension of both of those 77 documents. 79 1.1. Specification of Requirements 81 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 82 NOT", and "MAY" that appear in this document are to be interpreted 83 as described in [Bradner97]. 85 Internet Draft The ISAKMP Configuration Method February, 98 87 2. Configuration And Information Method 89 The premise behind this method is to utilize the existing ISAKMP 90 protocol as much as possible to build more functionality. The 91 Configuration and Information method described in this document 92 uses the ISAKMP NOTIFY payload to transfer information between two 93 hosts. Within the ISAKMP NOTIFY payload are ISAKMP attributes that 94 relay the actual information. 96 Depending on the type of information relayed by the exchange, it 97 MIGHT have to be secured. For example, if password information 98 were being exchanged, then the exchange would be REQUIRED to be 99 secured (both encrypted and authenticated). 101 The NOTIFY payload MAY be sent within an ISAKMP exchange (like Main 102 Mode or Aggressive Mode) or by itself. When sent by itself, it 103 MUST be sent in an Info Mode exchange. 105 If security is required for the attributes being exchanged, and the 106 exchange is occurring in an Info Mode ISAKMP exchange, then 107 security is exactly as defined in [Harkins97] under the section 108 entitled "ISAKMP Information Exchanges". 110 3. Configuration Transaction 112 A "Configuration Transaction" is defined as two Configuration 113 Method exchanges, the first being either a Set or a Request and the 114 second being either a Acknowledge or a Reply respectively. The SPI 115 within the ISAKMP NOTIFY payload header identifies the 116 configuration transaction. A SPI length of 4 octets SHOULD be 117 sufficient, but any length greater than zero MUST be supported and 118 returned in the reply and acknowledgement. 120 There are two paradigms to follow for this method. 122 o "Set/Acknowledge" works on the push principle that allows a 123 configuration manager (a host that wishes to send information to 124 another) to start the configuration transaction. This code 125 sends attributes that it wants the peer to alter. The 126 Acknowledge code MUST return the zero length attributes that it 127 accepted. Those attributes that it did not accept will NOT be 128 sent back in the acknowledgement. 130 Initiator Responder 131 --------------- ------------------- 132 NOTIFY(SET) --> 133 <-- NOTIFY(ACKNOWLEDGE) 135 Internet Draft The ISAKMP Configuration Method February, 98 137 o "Request/Reply" allows a host to request information from an 138 informed host (a configuration manager). IF the attributes in 139 the Request message are not empty, then these attributes are 140 taken as suggestions for that attribute. The Reply message MAY 141 wish to choose those values, or return new values. It MAY also 142 add new attributes and not include some requested attributes. 144 Initiator Responder 145 --------------- -------------- 146 NOTIFY(REQUEST) --> 147 <-- NOTIFY(REPLY) 149 Transactions are completed once the Reply or Acknowledge code is 150 received. If one is not received, the implementation MAY wish to 151 retransmit the original exchange. 153 The initiator and responder MAY not be the same as the initiator 154 and responder of the ISAKMP exchange. 156 If a badly formatted exchange is received, the message SHOULD be 157 silently discarded and perhaps logged locally, as per local policy. 158 Badly formatted exchanges MIGHT also include those with unknown 159 codes or unknown attributes within the Configuration Method. 161 3.1. Configuration NOTIFY Codes 163 Code Value 164 ========================== =========== 165 ISKAMP_CFG_REQUEST 101 166 ISKAMP_CFG_REPLY 102 167 ISKAMP_CFG_SET 103 168 ISKAMP_CFG_ACK 104 170 Since the Configuration Method uses NOTIFY codes for information 171 exchange, if the peer does not support this functionality, it will 172 quietly discard the message without breaking. 174 Internet Draft The ISAKMP Configuration Method February, 98 176 3.2. Configuration NOTIFY Data And Attributes 178 Zero or more ISAKMP attributes [ISAKMP] make up the NOTIFY 179 payload�s data. The following attributes are defined to be valid 180 within the payload: 182 Attribute Value Type Length 183 ====================== ======= ================ =================== 184 INTERNAL_ADDRESS 1 Variable 0 or 4 octets 185 INTERNAL_NETMASK 2 Variable 0 or 4 octets 186 INTERNAL_DNS 3 Variable 0 or 4 octets 187 INTERNAL_NBNS 4 Variable 0 or 4 octets 188 INTERNAL_ADDRESS_EXPIRY 5 Basic/Variable 0 or 2 or 4 octets 189 INTERNAL_DHCP 6 Variable 0 or 4 octets 190 APPLICATION_VERSION 7 Variable variable 192 Reserved for future use 8-16383 193 Private use 16384-32767 195 o INTERNAL_ADDRESS - Specifies an IPv4 address within the internal 196 network. This address is sometimes called a red node address or 197 a private address and MAY be an illegal address on the Internet. 198 Multiple internal addresses MAY be requested. The responder MAY 199 only send up to the number of addresses requested. 201 The requested address is valid until the expiry time, or until 202 the ISAKMP SA that was used to secure the request, expires. If 203 no ISAKMP SA was used to secure the request, then the response 204 MUST include an expiry. 206 o INTERNAL_NETMASK - The internal network's netmask. Only one 207 netmask is allowed in the request and reply messages. (eg. 208 255.255.255.0) 210 o INTERNAL_DNS - Specifies an IPv4 address of a DNS server within 211 the network. Multiple DNS servers MAY be requested. The 212 responder MAY respond with any number of DNS server attributes. 214 o INTERNAL_NBNS - Specifies an IPv4 address of a NetBios Name 215 Server (WINS) within the network. Multiple NBNS servers MAY be 216 requested. The responder MAY respond with any number of NBNS 217 server attributes. 219 o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that 220 the host can use the internal IP address. The host MUST renew 221 the IP address before this expiry time. Only one attribute MAY 222 be present in the reply. 224 Internet Draft The ISAKMP Configuration Method February, 98 226 o INTERNAL_DHCP - Instructs the host to send any internal DHCP 227 requests to the address contained within the attribute. 228 Multiple DHCP servers MAY be requested. The responder MAY 229 respond with any number of DHCP server attributes. 231 o APPLICATION_VERSION - The version or application information of 232 the IPSec host. This is a string of printable ASCII characters 233 that MIGHT NOT be null delimited. This attributed does NOT need 234 to be secured. 236 It is hoped that more attribute types will be defined in the 237 future. Some suggestions would be to distribute local policy, or 238 even authenticate certificates. Also, note that no recommendations 239 are made to how an implementation actually figures out what 240 information to send. i.e. we do not recommend any specific method 241 of (a gateway) determining which DNS server should be returned to a 242 requesting host. 244 3.3. Retransmission 246 Retransmission of Configuration messages SHOULD follow the same 247 retransmission rules used with standard ISAKMP messages. 249 While a response does not have to be sent in the next ISAKMP 250 message, it SHOULD be made within a time period. If a response is 251 not received within that time period, the initiator MIGHT 252 retransmit the same request. 254 4. Examples 256 Some examples of positioning this configuration method follow. 257 These are meant only as examples and should not be thought of as 258 the only possibilities for this protocol. 260 Example 1: Initiator requesting his internal IP address during the 261 last exchange in Main Mode using the shared secret authentication 262 method. 264 Initiator Responder 265 ----------------------------- -------------------------------- 266 HDR(Main), SA --> 267 <-- HDR(Main), SA 268 HDR(Main), KEY, Ni --> 269 <-- HDR(Main), KEY, Nr 270 HDR(Main)*,ID,HASH,NOTIFY(REQUEST) --> 271 <-- HDR(Main)*,ID,HASH,NOTIFY(REPLY) 273 Internet Draft The ISAKMP Configuration Method February, 98 275 REQUEST = 276 INTERNAL_ADDRESS(0.0.0.0), 277 INTERNAL_NETMASK(0.0.0.0), 278 INTERNAL_DNS(0.0.0.0) 279 REPLY = 280 INTERNAL_ADDRESS(192.168.219.202), 281 INTERNAL_NETMASK(255.255.255.0), 282 INTERNAL_DNS(291.168.219.4) 284 Please note that the responder MAY have sent the reply within the 285 Main Mode exchange as well as sending the reply by itself using 286 InfoMode; 288 HDR(Main)*,ID,HASH,NOTIFY(REQUEST) --> 289 <-- HDR(Main)*, ID, HASH 290 <-- HDR(Info)*, NOTIFY(REPLY) 292 Or the initiator could have sent the request in an InfoMode message 293 after MainMode completed. 295 If another tunneled SA is negotiated with this ISAKMP SA and an 296 internal IP address is required, then the initiator would perform 297 the request through a InfoMode request before the QuickMode 298 negotiation. 300 Initiator Responder 301 ----------------------------- -------------------------- 302 HDR(Info)*, NOTIFY(REQUEST) --> 303 <-- HDR(Info)*, NOTIFY(REPLY) 305 Example 2: A central configuration manager application sends out 306 some information to an IPSec host. 308 Initiator Responder 309 ----------------------------- -------------------------- 310 HDR(Info)*, NOTIFY(SET) --> 311 <-- HDR(Info)*, NOTIFY(ACK) 313 Internet Draft The ISAKMP Configuration Method February, 98 315 Example 3: An IPSec host inquires about the peer's version 316 information (without security). 318 Initiator Responder 319 ----------------------------- -------------------------- 320 HDR(Info), NOTIFY(REQUEST) --> 321 <-- HDR(Info), NOTIFY(REPLY) 323 REQUEST = APPLICATION_VERSION("") 324 REPLY = APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.") 326 Example 4: Same as Example 1, but using Aggressive Mode (Aggr). 327 Notice how the replay comes back secured since Aggressive Mode has 328 completed and created an ISAKMP SA. 330 Initiator Responder 331 ------------------------------- -------------------------- 332 HDR(Aggr), SA, KE, N, ID --> 333 <-- HDR(Aggr), SA, KE, N, ID, HASH 334 HDR(Aggr), HASH, NOTIFY(REQUEST) --> 335 <-- HDR(Info)*, NOTIFY(REPLY) 337 5. Enterprise Management Considerations 339 The method defined in this document SHOULD NOT be used for wide 340 scale management. Its main intent is to provide a bootstrap 341 mechanism to exchange information within IPSec. While it MAY be 342 useful to use such a method of exchange information to some 343 outlying IPSec hosts or small networks, existing management 344 protocols such as DHCP [Droms97], RADIUS [Radius], SNMP or LDAP 345 [Ldap97] should be considered for enterprise management as well as 346 subsequent information exchanges. 348 6. Security Considerations 350 This entire draft discusses a new ISAKMP configuration method to 351 allow IPSec-enabled entities to acquire and share configuration 352 information. 354 The draft mandates that this exchange should normally occur after 355 the Phase I Security Association has been set up and that the 356 entire exchange be protected by that Phase I SA. Thus the exchange 357 is as secure as any Phase II SA negotiation. 359 This exchange MAY be secured (encrypted and authenticated) by other 360 means as well, such as pre-configured ESP or data-link security. 362 Internet Draft The ISAKMP Configuration Method February, 98 364 7. References 366 [Atkinso95] R. Atkinson, "Security Architecture for the Internet 367 Protocol", draft-ietf-ipsec-arch-sec-01 369 [Bradner97] S. Bradner, "Key words for use in RFCs to indicate 370 Requirement Levels", RFC2119 372 [ISAKMP] D. Maughan, M. Schertler, M. Schneider, J. Turner, 373 "Internet Security Association and Key Management 374 Protocol", draft-ietf-ipsec-isakmp-08 376 [Harkins97] D. Harkins, "The Resolution of ISAKMP and Oakley", 377 draft-ietf-ipsec-isakmp-oakley-05 379 [Droms97] R. Droms, "Dynamic Host Configuration Protocol", 380 RFC2131 382 [Radius97] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote 383 Authentication Dial In User Service (RADIUS)", RFC2138 385 [Ldap97] M. Wahl, T. Howes, S. Kille., "Lightweight Directory 386 Access Protocol (v3)", RFC2251 388 8. Acknowledgments 390 The editors would like to thank Tim Jenkins, Peter Ford, Bob 391 Moskowitz and Shawn Mamros. 393 9. Editors' Addresses 395 Roy Pereira 396 rpereira@timestep.com 397 TimeStep Corporation 398 +1 (613) 599-3610 x 4808 400 Sanjay Anand 401 sanjayan@microsoft.com 402 Microsoft Corporation 403 +1 (206) 936-6367 405 Baiju V. Patel 406 baiju@mailbox.jf.intel.com 407 Intel Corporation 408 +1 (503) 264 2422 410 Internet Draft The ISAKMP Configuration Method February, 98 412 The IPSec working group can be contacted via the IPSec working 413 group's mailing list (ipsec@tis.com) or through its chairs: 415 Robert Moskowitz 416 rgm@icsa.net 417 International Computer Security Association 419 Theodore Y. Ts'o 420 tytso@mit.edu 421 Massachusetts Institute of Technology