idnits 2.17.1 draft-ietf-ipsec-isakmp-mode-cfg-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-04-16) 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. 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o RENEW_SECONDS - Specifies the number of seconds that the host can use all of the information set within the configuration transaction. The host MUST renew this information before this expiry time and MUST not use any of the information obtained through the configuration transaction after the expiry time. -- 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 (October 1, 1997) is 9694 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) == 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-04 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp-oakley (ref. 'Harkins97') == Outdated reference: A later version (-01) exists of draft-ietf-ipsec-doc-roadmap-00 ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-doc-roadmap (ref. 'Thayer97') Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force R. Pereira 2 IP Security Working Group TimeStep Corporation 3 Internet Draft S. Anand 4 Expires in six months Microsoft Corporation 5 October 1, 1997 7 The ISAKMP Configuration Mode 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 obsolete by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 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 mode that allows configuration 39 items to be set by using both push/acknowledge and request/reply 40 paradigms. 42 Internet Draft The ISAKMP Configuration Mode October, 97 44 Table of Contents 46 1. Introduction...................................................2 47 1.1. Specification of Requirements..............................2 48 2. Configuration Mode.............................................3 49 3. Configuration Transaction......................................3 50 3.1. Configuration Codes........................................4 51 4. Configuration Payload..........................................4 52 5. Configuration Attributes.......................................5 53 6. Security Considerations........................................6 54 7. References.....................................................6 55 8. Acknowledgments................................................7 56 9. Editors' Addresses.............................................7 58 1. Introduction 60 ISAKMP provides a framework to negotiate and derive Security 61 Associations. But since it is used within the IPSec framework, it 62 may also be used to configure secure hosts. This configuration may 63 take place between a gateway, an end-host client, or a 64 configuration manager. For example, this can be used to configure 65 multi-protocol IP tunnels securely. 67 It is assumed that the reader is familiar with the terms and 68 concepts described in the "Security Architecture for the Internet 69 Protocol" [Atkinson95] and "IP Security Document Roadmap" 70 [Thayer97] documents. 72 Readers are advised to be familiar with both [Harkins97] and 73 [ISAKMP] because of the terminology used within this document and 74 the fact that this document is an extension of both of those 75 documents. 77 1.1. Specification of Requirements 79 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 80 NOT", and "MAY" that appear in this document are to be interpreted 81 as described in [Bradner97]. 83 Internet Draft The ISAKMP Configuration Mode October, 97 85 2. Configuration Mode 87 Configuration Mode uses an XCHG type of 34 for the ISAKMP header. 88 This mode MUST NOT be used prior to establishment of an ISAKMP 89 Phase 1 Security Association. 91 Initiator Responder 92 ----------- ----------- 93 HDR*, HASH, CFG --> 94 <-- HDR*, HASH, CFG 96 where HASH is the prf output, using SKEYID_a as the key, and the 97 message-ID from the ISAKMP header concatenated with the entire CFG 98 payload, including attributes. In other words the hashes for the 99 above exchange are: 101 HASH = prf(SKEYID_a, M-ID | CFG) 103 Only one CFG payload MAY be present in one exchange of this mode. 105 3. Configuration Transaction 107 A "Configuration Transaction" is defined as two Configuration Mode 108 exchanges, the first being either a Set or a Request and the second 109 being either a Acknowledge or a Reply respectively. The Message ID 110 within the ISAKMP header identifies the configuration transaction 111 and MUST NOT be zero. 113 There are two paradigms to follow for this mode. 115 o "Set/Acknowledge" works on the push principle that allows a 116 configuration manager (a host that wishes to send information to 117 another) to start the configuration transaction. The 118 Acknowledge code MUST return zero length attributes that it 119 accepted. Those attributes that it did not accept will NOT be 120 sent back in the acknowledgement. 122 o "Request/Reply" allows a host to request information from an 123 informed host (a configuration manager). Attributes in the 124 Request exchange may have values filled in to request these 125 values once again. The Reply exchange MAY wish to choose those 126 values, or return new values. It MAY also add new attributes 127 and not include some requested attributes. 129 Transactions are completed once the Reply or Acknowledge code is 130 received. If one is not received, the implementation MAY wish to 131 retransmit the original exchange. 133 Internet Draft The ISAKMP Configuration Mode October, 97 135 If a badly formatted exchange is received, the exchange SHOULD be 136 dropped and logged locally, as per local policy. Badly formatted 137 exchanges would also include those with unknown codes or unknown 138 attributes within the Configuration Mode. 140 3.1. Configuration Codes 142 Code Value 143 ========================== =========== 144 ISKAMP_CFG_REQUEST 1 145 ISKAMP_CFG_REPLY 2 146 ISKAMP_CFG_SET 3 147 ISKAMP_CFG_ACK 4 148 Reserved for future use 5 - 127 149 Reserved for private use 128 - 255 151 4. Configuration Payload 153 The Configuration Payload is used to accomplish configuration 154 transactions between two secure hosts. Its "next payload" value is 155 13. 156 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Next Payload | RESERVED | Payload Length | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Code | RESERVED | Number of Attributes | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | | 164 ~ Attributes ~ 165 | | 166 +---------------------------------------------------------------+ 168 The Configuration Payload fields are defined as follows: 170 o Next Payload (1 octet) - Identifier for the payload type of the 171 next payload in the message. If the current payload is the last 172 in the message, then this field will be 0. For the 173 Configuration Mode, this field MUST be 0, since there is never a 174 next payload. 176 o RESERVED (1 octet) - Unused, set to 0. 178 o Payload Length (2 octets) - Length in octets of the entire 179 Configuration payload, including the Configuration payload 180 header and all of the attributes. 182 Internet Draft The ISAKMP Configuration Mode October, 97 184 o Code (1 octet) - A code that represents a command to be 185 fulfilled or an action that has been completed. Please see 186 Section 4.1 for a description of each code. 188 o RESERVED (1 octet) - Unused, set to 0. 190 o Number of Attributes (2 octets) - States the number of 191 attributes to follow. Note that both the payload length and the 192 number of attributes field may be used to process the 193 attributes. 195 o Attributes (variable) - One or more data attributes as defined 196 in [ISAKMP], section 3.3. Please see a later section for more 197 information on the contents of these attributes. 199 5. Configuration Attributes 201 Attribute Value Type Length 202 ========================== ======= ================ ============ 203 INTERNAL_IP4_ADDRESS 1 Variable 4 octets 204 INTERNAL_IPX_ADDRESS 2 Variable 6 octets 205 INTERNAL_NB_ADDRESS 3 Variable 16 octets 206 INTERNAL_IP4_DNS 4 Variable 4 octets 207 INTERNAL_IP4_NBNS 5 Variable 4 octets 208 RENEW_SECONDS 6 Basic/Variable 2 or 4 octets 209 USE_IP4_DHCP 7 Variable 4 octets 210 Reserved for future use 8-63 211 Reserved for private use 64-127 213 o INTERNAL_IP4_ADDRESS - Specifies an IPv4 address within the 214 internal network. This address is sometimes called a red node 215 address. This address is sometimes an illegal address on the 216 Internet. 218 o INTERNAL_IPX_ADDRESS - Specifies an IPX address within the 219 internal network. 221 o INTERNAL_NB_ADDRESS - Specifies a NetBios address within the 222 internal network. 224 o INTERNAL_IP4_DNS - Specifies an IPv4 address of a DNS server 225 within the network. 227 o INTERNAL_IP4_NBNS - Specifies an IPv4 address of a NetBios Name 228 Server (WINS) within the network. 230 Internet Draft The ISAKMP Configuration Mode October, 97 232 o RENEW_SECONDS - Specifies the number of seconds that the host 233 can use all of the information set within the configuration 234 transaction. The host MUST renew this information before this 235 expiry time and MUST not use any of the information obtained 236 through the configuration transaction after the expiry time. 238 o USE_IP4_DHCP - Instructs the host to request any subsequent 239 information through the DHCP protocol. This attribute holds the 240 IPv4 address of a DHCP server. 242 It is hoped that more attribute types will be defined in the 243 future. Some suggestions would be to distribute local policy, or 244 even authentication certificates. Also, note that no 245 recommendations are made to how an implementation actually figures 246 out what information to send. i.e. we do not recommend any 247 specific method of (a gateway) determining which DNS server should 248 be returned to a requesting host. 250 6. Security Considerations 252 This entire draft discusses a new ISAKMP mode to allow entities in 253 the network to acquire and share configuration information. 255 The draft mandates that this exchange always occur after the Phase 256 I Security Association has been set up and that the entire exchange 257 be protected by the Phase I SA. Thus the exchange is as secure as 258 any Phase II SA. 260 7. References 262 [Atkinson95] Atkinson, R., "Security Architecture for the Internet 263 Protocol", draft-ietf-ipsec-arch-sec-01 265 [Bradner97] Bradner, S., "Key words for use in RFCs to indicate 266 Requirement Levels", RFC2119, March 1997 268 [ISAKMP] D. Maughan, M. Schertler, M. Schneider, J. Turner, 269 "Internet Security Association and Key Management Protocol", 270 draft-ietf-ipsec-isakmp-08 272 [Harkins97] D. Harkins, "The Resolution of ISAKMP and Oakley", 273 draft-ietf-ipsec-isakmp-oakley-04 275 [Thayer97] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document 276 Roadmap", draft-ietf-ipsec-doc-roadmap-00 278 Internet Draft The ISAKMP Configuration Mode October, 97 280 8. Acknowledgments 282 The editors would like to thank Peter Ford of Microsoft and Bob 283 Moskowitz of Chrysler. 285 9. Editors' Addresses 287 Roy Pereira 288 rpereira@timestep.com 289 TimeStep Corporation 290 +1 (613) 599-3610 x 4808 292 Sanjay Anand 293 sanjayan@microsoft.com 294 Microsoft Corporation 295 +1 (206) 936-6367 297 The IPSec working group can be contacted via the IPSec working 298 group's mailing list (ipsec@tis.com) or through its chairs: 300 Robert Moskowitz 301 rgm@chrysler.com 302 Chrysler Corporation 304 Theodore Y. Ts�o 305 tytso@MIT.EDU 306 Massachusetts Institute of Technology