idnits 2.17.1 draft-srisuresh-ike-policy-extensions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 478 has weird spacing: '... ...' == Line 481 has weird spacing: '... octets requi...' == Line 490 has weird spacing: '... ...' == Line 493 has weird spacing: '... octets requi...' == Line 502 has weird spacing: '... ...' == (5 more instances...) == 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 (January 2001) is 8502 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: 'Ref 8' is mentioned on line 183, but not defined == Missing Reference: '3-255' is mentioned on line 702, but not defined == Unused Reference: 'ESP' is defined on line 749, but no explicit reference was found in the text == Unused Reference: 'OAKLEY' is defined on line 763, but no explicit reference was found in the text == Unused Reference: 'CRYPTO' is defined on line 766, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. 'AH') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (ref. 'IPSEC-DOI') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'SKEME' ** Obsolete normative reference: RFC 2408 (ref. 'ISAKMP') (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2412 (ref. 'OAKLEY') -- Possible downref: Non-RFC (?) normative reference: ref. 'CRYPTO' ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) Summary: 13 errors (**), 0 flaws (~~), 14 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Srisuresh 3 INTERNET-DRAFT Jasmine Networks 4 Expires by July 24, 2001 J. Vilhuber 5 Cisco Systems 6 January 2001 8 IKE extensions to support Dynamic Policies 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), 16 its areas, and its working groups. Note that other groups may also 17 distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 To view the entire list of current Internet-Drafts, please check 26 the "1id-abstracts.txt" listing contained in the Internet-Drafts 27 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 28 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 29 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 30 (US West Coast). 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 As IPsec is widely deployed, there is increasing need to negotiate 41 security keys using IKE at application level granularity. 42 IKE, as currently proposed, has restrictions in negotiating keys 43 for applications with bundled sessions and complex policies. 44 The draft identifies the problem with IKE and suggests extensions 45 to make IKE application and policy friendly. The proposed solution 46 suggests extensions to the conceptual operation of IPsec as well as 47 IKE, but does not require changes to existing IKE payloads. The 48 document introduces a new policy payload that complements existing 49 IKE payloads and suggests replacing ID payload with the Policy 50 payload, in Quick mode. 52 1. Introduction and Overview 54 IP packets may be subject to IPsec security enforcement by peering 55 end nodes or enroute by intermediate systems. The enforcement is 56 policy based. As IPsec is widely deployed, there is increasing 57 desire to make these policies granular to a specific application 58 detail. The focus of the document is facilitating enforcement of 59 application driven dynamic policies across peering nodes, using 60 IKE. 62 IKE protocol uses part of Oakley and part of SKEME ([SKEME] in 63 conjunction with ISAKMP ([ISAKMP])to obtain authenticated keying 64 material for use with ISAKMP, and for IPsec DOI security 65 associations such as AH ([AH]) and ESP (ESP]. As such, any 66 changes and extension to IKE ([IKE]) could potentially mandate 67 changes to every one of the sub-components. This document 68 identifies extensions required of each of the sub-components to 69 bring about the appropriate policy extensions to IKE Phase-II 70 based security associations for IPsec DOI ([IPSEC-DOI). 72 2.0 Terms and Technical Definitions 74 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" 75 and "MAY" that appear in this document are to be interpreted as 76 described in [STD-KEYWORDS]. Further, the security terms 77 defined in [IPSEC] and keywords used in [IKE] have been used 78 profusely throughout the document. As such, prior understanding 79 of [IPSEC] and [IKE] are a requirement for reviewing this 80 document. 82 2.1 Technical Definitions 84 2.1.1 Security Gateway 86 A security gateway refers to an intermediate system that 87 implements IPSec protocols. For example, a router or a 88 firewall implementing IPSec is a security gateway. 90 2.1.2 Security Domain 92 A set of communicating entities and resources that share a 93 common security policy enforced at one or more enforcement 94 agents or at an individual host. The definition of security 95 domain applies to networks protected by security gateways as 96 well as to single hosts, since a host may be the enforcer of 97 its own policies. Security domains could exist inside other 98 security domains. 100 2.1.3 Application Level Gateway (ALG) 102 Application Level Gateway (ALG) is a trusted entity that has 103 application specific knowledge it can use to determine dynamic 104 security policy requirements for the application. ALG on an 105 IPsec enforcement node may use the information to update the 106 SPD of IPsec and to interface with IKE (directly or 107 indirectly) to enforce the policy extensions with peering 108 Ipsec node. 110 2.1.4 Dynamic Policy Agent (DPA) 112 Dynamic Policy Agent (DPA) is an entity that interfaces with 113 ALGs, IKE and IPsec-SPD to keep the applications, Ipsec security 114 engine and policy enforcement with peers in sync. Specifically, 115 the Dynamic Policy Agent interfaces with the ALGs to gather 116 the dynamic policy requirements of applications, exchanges the 117 information with peering security node and updates the 118 IPsec-SPD to enforce security. 120 2.1.5 Policy Payload 122 Policy Payload is a new ISAKMP payload introduced to facilitate 123 flexible definition of policy description and dynamic updates to 124 the original description. 126 3. Problem with dynamic policy enforcement in IPsec and IKE 128 We will consider the following diagram to illustrate IPsec policy 129 enforcement, as packets traverse the enforcement devices. For the 130 purposes of this document, a security gateway is an intermediate 131 system implementing IPSec. 133 An application on Host-A that needed to communicate with Host-B, 134 in a different administrative domain would typically cross a 135 minimum of two policy enforcement devices - A security gateway 136 local to the administrative domain and another local to the peer 137 node's administrative domain. Figure 3.1 below is meant to be an 138 example and does not cover the various configurations in which 139 administrative domains may be connected to each other. In 140 practice, there may be multiple security gateways. However, 141 the diagram does provide the necessary base to address policy 142 specific issues. Further, even though we selected a security 143 Gateway to illustrate, the discussion is applicable to both 144 transport and tunnel odes of IPsec, equally well. 146 ________________ 147 ( ) 148 +--+ ( Administrative ) 149 |__|------( Boundary - B ) 150 /____\ ( ) 151 Host-B (________________) 152 | 153 +--------------------+ 154 | Security Gateway | 155 | - GW-B | 156 +--------------------+ 157 __________ | 158 ( ) | 159 +-----------------+ ( ) +-----------------+ 160 | Border Router-A |--( Internet )--| Border Router-B | 161 +-----------------+ ( ) +-----------------+ 162 | (__________) 163 | 164 +--------------------+ 165 | Security Gateway | 166 | - GW-A | 167 +--------------------+ 168 | 169 ---------------- 170 ( ) 171 +--+ ( Administrative ) 172 |__|------( Boundary - A ) 173 /____\ ( ) 174 Host-A (________________) 176 Figure 3.1: Security Gateways connected across the Internet. 178 A security gateway operating in tunnel mode may encrypt and/or 179 authenticate a packet and forward it through a tunnel destined to 180 peer security gateway. The peer gateway in turn, de-tunnels the IP 181 packet from the tunnel and reverse-transforms it to extract the 182 original packet. It then forwards it to the destination, as 183 specified in the original packet [Ref 8]. There is however a 184 pitfall for certain type of applications. 186 An application comprised of a session bundle may work only 187 partially. For example, a security Gateway cannot create an SA 188 (one or more) that can secure all session of the FTP application 189 (i.e., FTP control and data sessions), unless your policy is to 190 preserve all of TCP. Here is why. You could have a policy that 191 preserves FTP control session by selecting src or Dest TCP port 192 to be 21. But, the data session parameters set by, say PASV 193 response, will decide the port number used by the ensuing data 194 session. Only the end-nodes know the data session port numbers. 195 Dynamically selected ports in a session cannot not be known to 196 IKE or IPsec, unless IKE and Ipsec have application specific 197 knowledge to examine the payload. Even as applications can 198 notify the security Gateway of the data sessions, IKE does not 199 know to add or delete sessions to reuse of the same key (as 200 used for FTP control session) for securing data sessions. 202 3. Suggested changes to Security policy enforcement in IPsec and IKE 204 The solution we are about to propose requires changes in the way 205 the IPsec SPD rules are defined and accessed. A Dynamic policy 206 Agent (DPA) is introduced to interface with IPsec-SPD to keep 207 the SPD in sync with the requirements of end-to-end applications. 208 Further, additional changes in IKE are proposed to communicate 209 dynamic policy updates securely across peering security nodes. 211 3.1 Dynamic Policy Agent (DPA) 213 A new entity, labeled Dynamic Policy Agent (DPA) is envisioned to 214 coordinate exchange of dynamic policy updates between peering IKE 215 nodes, followed by an update of the same in the local IPsec SPD. 216 DPA uses Policy-ID to co-ordinate these policy updates. 218 3.2 Suggested changes to IPsec SPD 220 Application specific IPsec policy rules in SPD must be allowed to 221 be associated with an application specific ALGs. Each policy rule 222 in the SPD will also have a 4-octet long Policy-ID to uniquely 223 identify the policy within the node. These Policy rules, along 224 with their policy ID are exchanged with peering IKE nodes. 225 Specification of an ALG for a policy rule is optional. When an 226 ALG is specified in the policy, the ALG will become a part of 227 the IPsec data path. The ALGs are trusted entities by the 228 application and will have application specific knowledge to 229 determine the dynamic policy requirements of an application. 230 These ALGs interface with dynamic policy agent (DPA) to notify 231 policy updates to the existing policy rules in IPsec SPD. 233 Changes to IPsec data path at the enforcement points may be 234 captured as follows in the following two diagrams. 236 +---------+ +---------+ +------------+ 237 | | | | | | 238 Outgoing |Does the | Yes |Redirect | SA |Perform | Forward 239 -------->|pkt match|---->|pkt to |----->|Outbound |-------> 240 Packet |Outbound | |ALG, if | Keys |Security | Packet 241 |Policy? | |specified| |(ex:encrypt)| 242 +---------+ +---------+ +------------+ 244 Figure 3.2.1. Operation of IPsec on outgoing packets. 246 +------------+ +---------+ +---------+ 247 Incoming |Perform | Clear |Does the | Yes |Redirect | Send to 248 -------->|Inbound |------>|pkt match|---->|pkt to |-------> 249 Packet |Security | Pkt |Inbound | |ALG, if | Appl. 250 |(ex:Decrypt)| |Policy? | |specified| 251 +------------+ +---------+ +---------+ 253 Figure 3.2.2. Operation of IPsec on Incoming packets 255 3.3. Suggested changes to IKE 257 A new type of Policy payload is added to the list of ISAKMP 258 payloads. This payload is to be used only in IKE phase II and is 259 designed to be flexible, so as not to be constrained to the form of 260 a single rule. Each new policy will have a policy-ID associated with 261 it. A policy may be defined using one or more policy payloads. The 262 payload allows for the specification of a range of addresses and 263 transport ports, while also permitting selective exclusion. 265 3.3.1. Provide Dynamic Policy Updates(Add/Delete) to Enforcement Points 267 For IPsec, the end nodes should be able to influence policies 268 associated with an IPsec SA dynamically. This is independent of 269 whether the SA was between the peers directly or between 2 gateway 270 nodes in between. An end node should be able to add/delete policies 271 dynamically from an SA. Without this, application specific policies 272 are hard to enforce on an SA. 274 For instance, take a policy that mandates security for FTP 275 application between 2 hosts. Once a SA is established for securing 276 the control session of the FTP application, the end nodes ought to 277 be able to (a) add/delete newer policies (describing the parameters 278 of ensuing FTP data sessions) to the existing FTP control session SA, 279 or (b) create newer SAs dynamically confirming to dynamically 280 generated policy parameters. 282 Exchange of Dynamic policy updates in IKE phase II is made possible 283 with the notion of DPA. The DPA interacts with IKE locally to either 284 notify IKE to initiate a policy update or to confirm the validity of 285 a proposed update coming in from a remote node. IKE peers exchange 286 new policies and the policy updates securely in quick mode. The 287 policy updates may involve addition or subtractions to the original 288 policy rule. Each policy rule is uniquely identified by a Policy-ID. 289 Once the policy updates are securely exchanged, the DPA updates the 290 local SPD to reflect the changes associated with the Policy-ID. 291 The following diagram summarizes the role of DPA in conjunction with 292 IKE in dynamic policy update process. 294 +------+ +--------+ +---------+ 295 | | Dynamic | | Exchange Policy | | 296 +-| ALGn |<------->| Dynamic|<----------------->| IKE | 297 | +------+ Policy | Policy | Updates (based on | Process | 298 +-| ...| Updates | Agent | Policy-ID handle) | | 299 | +------+ +--------+ +---------+ 300 | ALG1 | | ^ | 301 +------+ Reflect dynamic | | | 302 policy updates | Security | |Negotiated 303 exchanged with | Policies & | |parameters, 304 peering IKE node| SA proposals | |SA Keys 305 v | v 306 +---------+ +---------+ 307 | |------------------>| | 308 | IPsec- | | IPsec | 309 | SPD | | Process | 310 | | | | 311 +---------+ +---------+ 313 Figure 3.3.3. DPA coordinating between ALGs, IKE and IPsec-SPD. 315 4. New Policy Payload for use in IKE phase 2 317 IKE uses ID payload in phase I to authenticate the peers. The ID 318 payload is further extended in phase II to exchange the IPsec 319 policies. While this reduces the number of payload types to work 320 with, it became a stretch to extend the ID payload to describe 321 IPsec policies in IKE phase 2. Policy specification using ID 322 payload has been rather inflexible and prone to errors. So, a 323 new policy payload is introduced for a policy definition that 324 is more flexible and less error prone. 326 4.1 IPsec Policy Payload format 328 The Policy Payload contains DOI-specific data used to exchange 329 Policy information. This information is used for exchanging the 330 Policies of communicating peers for which keys need to be 331 generated. Figure 4.1 shows the format of the Policy Payload. 333 The Policy Payload fields are defined as follows: 335 o Next Payload (1 octet) - Identifier for the payload type of the 336 next payload in the message. If the current payload is the last 337 in the message, then this field will be 0. 339 o Policy OpCode (1 octet) - Specifies the type of Operation 340 to be performed. This can be one of POLICY-OP-CREATE (0x00), 341 POLICY-OP-ADD (0x01) or POLICY-OP-DEL (0x02). 343 o Payload Length (2 octets) - Length in octets of the current 344 payload, including the generic payload header. 346 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 ! Next Payload ! Policy Opcode ! Payload Length ! 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 ! Policy IDentifier ! 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 353 ! ! 354 ~ Policy Data ~ 355 ! ! 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Figure 4.1. Policy Payload Format 360 o DOI Specific Policy-ID (4 octets) - Contains DOI specific 361 Identification data. 363 o Policy Data (variable length) - Contains Policy information. 364 Specific details for the IETF IP Security DOI Policy Data 365 may be specified as follows. 367 The payload type for the Policy Payload may be assigned a value of 368 fourteen (14), so as not to conflict with the definitions for 369 recognized ISAKMP payload types, as defined in [ISAKMP] sections 370 4.3 through 4.14. 372 4.2 IPsec Policy Payload Content format 374 The Policy Payload, used in IKE phase II, is used to ensure that a 375 certain security association is applied only to those packets that 376 confirm to the policy exchanged in conjunction with the SA 377 negotiation. The policy payload of the initiator SHOULD be used 378 by the responder to determine the correct host system security policy 379 requirement for the association. For example, a host might choose to 380 require authentication and integrity without confidentiality (AH) 381 from a certain set of IP addresses and full authentication with 382 confidentiality (ESP) from another range of IP addresses. The 383 policy Payload provides information that can be used by the 384 responder to make this decision. 386 The following diagram illustrates the content of the Policy Payload. 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 !P!RSRVD! IPvx !SA-Type!DA-Type!SP-type|DP-type! Protocol ID ! 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 ~ Src-address-Data ~ 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 ~ Src-Port-Data ~ 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 ~ Dest-address-Data ~ 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 ~ Dest-Port-Data ~ 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 ~ Optional Policy Extensions in Tag-Length-Value format ~ 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Figure 4.2. IPsec DOI Policy Data content Format 405 The Policy Payload fields are defined as follows: 407 o P (1 bit) - Polarity of the Policy. The policy must be 408 interpreted as outbound policy from the policy senders 409 view. When set to 0, the position of source and destination 410 fields for Address and port are interpreted as described 411 in the figure. When set to 1, the position of the source 412 and destination fields must be reversed. 414 o RSRVD (4 bits) - Must be set to 0. 416 o IPvx (4 bits) - Value describing the IP address Length. 417 A value of 4 refers to IPv4 and an IP address length of 418 4 octets. A value of 6 refers to IPv6 and an IP address 419 length of 16 octets. 421 o SA-Type (4 bits) - Value describing the format of 422 information found in the Src-Address-Data field. 424 o DA-Type (4 bits) - Value describing the format of 425 information found in the Dest-Address-Data field. 427 o SP-Type (4 bits) - Value describing the format of 428 information found in the Src-Port-Data field. 430 o DP-Type (4 bits) - Value describing the format of 431 information found in the Dest-Port-Data field. 433 o Protocol ID (1 octet) - Value specifying an associated IP 434 protocol ID (e.g. UDP/TCP). A value of zero means that the 435 Protocol ID field should be ignored. 437 o Src-address-Data, Src-Port-Data, Dest-address-Data, 438 Dest-Port-Data (variable length) - Value, as indicated by 439 the fields IPvx, SA-Type, SP-type, DA-Type and DP-type. 441 4.2.1 SA-Type and DA-Type Values 443 The following table lists the assigned values for the Address type 444 fields found in the Policy data. 446 Address Type Value 447 ------------ ----- 448 RESERVED 0 449 POLICY_ADDR_SINGLE 1 450 POLICY_ADDR_RANGE 2 451 POLICY_ADDR_SUBNET 3 452 POLICY_ADDR_LIST_SINGLE 9 453 POLICY_ADDR_LIST_RANGE 10 454 POLICY_ADDR_LIST_SUBNET 11 456 The POLICY_ADDR_SINGLE type specifies a single IP address in the 457 Address-Data field. This will be four (4) octets, when IPvx is 458 set to 4. This will be sixteen (16) octets, when IPvx is set to 6. 460 The POLICY_ADDR_RANGE type specifies a range of IP addresses, 461 represented by two four or sixteen octet values, based on whether 462 IPvx is set to 4 or 6. The first value is the beginning IP address 463 (inclusive) and the second value is the ending IP address 464 (inclusive). Note that all addresses falling between the two 465 specified addresses are considered to be within the list. 467 The POLICY_ADDR_SUBNET type specifies two IP addresses, 468 each represented by two four or sixteen octet values, based on 469 whether IPvx is set to 4 or 6. The first value is an IP address. 470 The second is an IP network mask. Note that ones (1s) in the 471 network mask indicate that the corresponding bit in the address 472 is fixed, while zeros (0s) indicate a "wildcard" bit. 474 The POLICY_ADDR_LIST_SINGLE type specifies a variable number of 475 individual IP addresses in the Address-Data field. The 476 Address-Data field will have the addresses listed as follows. 478 <----List of individual IP Addresses------> 479 <- 2 bytes -> <- Multiples of 4(IPv4) or 16(IPv6) bytes-> 481 The is the sum total of octets required to specify 482 the address list and the 2 bytes required by the 483 field. The 485 The POLICY_ADDR_LIST_RANGE type specifies a variable number of 486 individual IP address ranges in the Address-Data field. The 487 Address-Data field will have the address ranges listed as 488 follows. 490 <------List of IP Address ranges----------> 491 <- 2 bytes -> <- Multiples of 8(IPv4) or 32(IPv6) bytes-> 493 The is the sum total of octets required to specify 494 the address ranges and the 2 bytes required by the 495 field. 497 The POLICY_ADDR_LIST_SUBNET type specifies a variable number of 498 individual IP address subnets in the Address-Data field. The 499 Address-Data field will have the address subnets listed as 500 follows. 502 <------List of IP Address subnets---------> 503 <- 2 bytes -> <- Multiples of 8(IPv4) or 32(IPv6) bytes-> 505 The is the sum total of octets required to specify 506 the address subnets and the 2 bytes required by the 507 field. 509 4.2.2 SP-Type and DP-Type Values 511 The following table lists the assigned values for the Port type 512 fields(SP-Type, DP-Type) found in the Policy data. 514 Type Value 515 ------------ ----- 516 POLICY_PORT_IGNORE 0 517 POLICY_PORT_SINGLE 1 518 POLICY_PORT_RANGE 2 519 POLICY_PORT_LIST_SINGLE 9 520 POLICY_PORT_LIST_RANGE 10 522 POLCY_PORT_IGNORE type indicates that the associated Port-Data 523 field should be ignored. 525 POLICY_PORT_SINGLE type would specify a 2 octet port-data field. 527 POLICY_PORT_RANGE type would specify a pair of 2-octet port 528 numbers in Port-Data field. The first value is the beginning port 529 number (inclusive) and the second value is the ending port 530 number (inclusive). 532 POLICY_PORT_LIST_SINGLE would specify a variable number of bytes 533 in the Port-Data field as follows. The Port-date filed will have 534 the variable count of port numbers listed as follows: 536 537 <- 2 bytes -> <----- Multiples of 2 bytes ----> 539 The is the sum total of octets required to specify 540 the individual ports and the 2 bytes required by the 541 field. 543 POLICY_PORT_LIST_RANGE would specify a variable number of bytes 544 in the Port-Data field as follows. The Port-date filed will have 545 the variable count of port ranges listed as follows: 547 548 <- 2 bytes -> <------ Multiples of 4 bytes --------> 550 The is the sum total of octets required to specify 551 the individual ports and the 2 bytes required by the 552 field. 554 4.2.3. Optional policy extensions 556 Optionally, additional fields (over and above 5 tuples for address, 557 protocol and port numbers) may also be specified as part of the 558 Policy specification in Tag-Length-Value format. Existense of 559 additional fields in policy specification may be surmised when 560 the Policy payload length (refer section 4.2.1) exceeds the 561 five-tuple policy data. 563 For example, the Diffserv Field in IP header may be specified as 564 as an additional field as follows, 565 566 567 569 The will be specified in a single octet. field is the 570 sum total of bytes necessary to list the DS-fields allowed and the 571 two bytes necessary to specify the and fields. 573 5. Modifications to IKE Phase 2 - Quick Mode 575 IKE Quick Mode is used to derive keying material for IPsec policies 576 commonly shared between the IKE peers. The information exchanged in 577 Quick Mode is protected by the ISAKMP SA (Phase 1). 579 The message ID in the ISAKMP header identifies the Quick Mode in 580 progress. Quick Mode is essentially a SA negotiation, IPsec policy 581 communication and an exchange of nonces that provides replay 582 protection. 584 The Policies for which SAs negotiated in Quick Mode are implicitly 585 assumed to be between the IP addresses of the ISAKMP peers, unless 586 policy operations are explicitly specified in Quick Mode. 588 With the new approach, Policy based payloads are exchanged in place 589 of IDci and IDcr. If the client policies are not acceptable to the 590 Quick Mode responder, a Notify payload with Notify Message Type 591 INVALID-POLICY-INFORMATION SHOULD be sent. A value of thirty one 592 (31) may be assigned to INVALID-POLICY-INFORMATION, so as not to 593 conflict with the error codes listed in 3.14.1 of [ISAKMP]. 595 5.1. New Policy Exchange in Quick mode 597 Policy based Quick Mode may be described as follows for brand new 598 key generation. 600 Initiator Responder 601 ----------- ----------- 602 HDR*, HASH(1), SA, Ni 603 [, KE ] (, POLi)* --> 604 <-- HDR*, HASH(2), SA, Nr 605 [, KE ] (, POLr)* 606 HDR*, HASH(3) --> 608 Where: 609 HASH(1) is the prf over the message id (M-ID) from the ISAKMP header 610 concatenated with the entire message that follows the hash, including 611 all payload headers, but excluding any padding added for encryption. 612 HASH(2) is identical to HASH(1) except the initiator's nonce-- Ni, 613 minus the payload header-- is added after M-ID but before the 614 complete message. The addition of the nonce to HASH(2) is for a 615 liveliness proof. HASH(3)-- for liveliness-- is the prf over the 616 value zero represented as a single octet, followed by a concatenation 617 of the message id and the two nonces-- the initiator's followed by 618 the responder's-- minus the payload header. In other words, the 619 hashes for the above exchange are: 621 HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] | POLi* ) 622 HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | POLr* ) 623 HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b) 625 HASH, SA, and Nonce payloads must be sent in that order. 627 A single SA negotiation results in two security associations-- one 628 inbound and one outbound. Different SPIs for each SA (one chosen by 629 the initiator, the other by the responder) guarantee a different key 630 for each direction. The SPI chosen by the destination of the SA is 631 used to derive KEYMAT for that SA. 633 Multiple SAs and keys can be negotiated with one exchange such that 634 you have two keys each way for both SAs. New policy payload must be 635 accompanied by a SA negotiation payload. 637 5.2. Dynamic Policy update in Quick Mode 639 For exchanges that do not involve Key generation, but simply policy 640 updates, Updates to Policies previously negotiated may be performed 641 as follows. These policy updates do not mandate SA negotiation 642 payload. However, a single SA negotiation payload is optional. 644 Initiator Responder 645 ----------- ----------- 646 HDR*, HASH(1), [SA, ] Ni 647 , POLi (, POLi)* --> 648 <-- HDR*, HASH(2), [SA, ] Nr 649 , POLr (, POLr)* 650 HDR*, HASH(3) --> 652 Hashes for the above exchange are: 654 HASH(1) = prf(SKEYID_a, M-ID | [ SA |] Ni | POLi* ) 655 HASH(2) = prf(SKEYID_a, M-ID | Ni_b | [SA |] Nr | POLr* ) 656 HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b) 658 When no SA is specified, the policy updates made in POLi/POLr simply 659 update the corresponding policy rule in SPD. Hence, the SA 660 associated with the POLICY-ID will be reused for the updated policy. 661 However, when SA payload is present, the new SA negotiation results 662 in two new security associations-- one inbound and one outbound for 663 the Policy Updates. These new SA keys will be used to secure the 664 policy updates exchanged. 666 6. Security Considerations 668 The document suggests a new Policy-ID payload and modifications 669 to IKE protocol. This however, does not jeopardize the security 670 provided by the base IKE protocol. Additions and deletions 671 pertaining to a Policy ID are communicated in a secure way 672 so as not to jeopardize the ability of the application to run. 674 7. IANA Considerations 676 This document proposes a new ISAKMP payload type and a new Notify 677 error code. 679 7.1. ISAKMP Policy Payload type 681 The ISAKMP payload types are discussed in sections 3.4 through 3.15 682 of [ISAKMP]. And, Section 4.6 of [IPSEC-DOI] lists the ISAKMP 683 payloads whose data representations are dependent on the applicable 684 DOI. The new ISAKMP payload type discussed in section 4.1 of this 685 document will be an addition to the payload types discussed in 686 [ISAKMP] as well as [IPSEC_DOI]. However, the ISAKMP payload types 687 are not listed as items to be managed by IANA in [ISAKMP]. Assuming 688 this to have been an omission, we propose that the new payload type 689 specified in this document be considered by IANA as an addition to 690 the ISAKMP payload types listed in sections 3.4 through 3.15 in 691 [ISAKMP]. 693 Within the context of this new policy payload type, three sub-fields 694 are defined that may be assigned newer values in the future. 695 The following sub-section explains the criteria to be used by the 696 IANA to assign additional numbers as values to these sub-fields, 697 described in section 4.1, 4.2.1 and 4.2.2 699 7.1.1. Policy Opcode field 701 Values 0-2 of the Policy-Opcode field are defined in Section 4.1. 702 the remaining values [3-255] are available for assignment by the 703 IANA with IETF Consensus [IANA]. 705 7.1.2. SA-Type and DA-Type fields 707 SA-Type and DA-type fields are 4-bits long. Values 0-3, 9-11 for 708 these fields are defined in Section 4.2.1. The remaining values 709 4-8, 12-15 are available for assignment by the IANA with 710 IETF Consensus [IANA]. It is recommended that values 4 through 7 711 be allowed to specify fixed length types and the values 8 and 712 12 through 15 be alowed to specify variable length types. 714 7.1.3. SP-Type and DP-Type fields 716 SP-Type and DP-Type fields are 4-bits long. Values 0-2, 9-10 for 717 these fields are defined in Section 4.2.2. The remaining values 718 3-8, 11-15 are available for assignment by the IANA with IETF 719 Consensus [IANA]. It is recommended that values 3 through 7 720 be allowed to specify fixed length types and the values 8 and 721 11 through 15 be alowed to specify variable length types. 723 7.2. ISAKMP Notify payload error message type 725 Section 3.14.1 of [ISAKMP] lists the Notification error codes in the 726 range of 1-30. Error codes 31-8191 are reserved for future use and 727 error codes 8192-16383 are set aside for private use. Of these, 728 error code 8192 is reserved by the IPSEC-DOI in section 4.6.3 of 729 [IPSEC-DOI]. We define a new INVALID-POLICY-INFORMATION error code 730 31 in section 5.0. 732 Once again, the error codes lised for use within the Notify 733 payload in [ISAKMP] are not listed as items to be managed by IANA 734 in [ISAKMP]. Assuming this to have been an omission, we propose 735 that the error code specified in this document be considered by 736 IANA as an addition to the Notify payload error codes listed in 737 3.14.1 of [ISAKMP]. 739 REFERENCES 741 [STD-KEYWORDS] Bradner, S., "Key Words for use in RFCs to indicate 742 Requirement Levels", RFC2119, March 1997. 744 [IPSEC] S. Kent, R. Atkinson, "Security Architecture for the 745 Internet Protocol", RFC 2401. 747 [AH] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402 749 [ESP] S. Kent, R. Atkinson, "IP Encapsulating Security Payload 750 (ESP)", RFC 2406. 752 [IPSEC-DOI] D. Piper, "The Internet IP Security Domain of 753 Interpretation for ISAKMP", RFC 2407. 755 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange 756 Mechanism for Internet", from IEEE Proceedings of the 1996 757 Symposium on Network and Distributed Systems Security. 759 [ISAKMP] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, 760 "Internet Security Association and Key Management Protocol 761 (ISAKMP)", RFC 2408, November 1998. 763 [OAKLEY] Orman, H., "The Oakley Key Determination Protocol", 764 RFC 2412. 766 [CRYPTO] Schneier, B., "Applied Cryptography, Protocols, 767 Algorithms, and Source Code in C", 2nd edition. 769 [IKE] Harkins, D., Carrel, D.,"The Internet Key Exchange (IKE)", 770 RFC 2409. 772 [IANA] Narten, T. and H. Alvestrand, "Guidelines for writing an 773 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 774 October 1998. 776 Authors' Address: 778 Pyda Srisuresh 779 Jasmine Networks, Inc. 780 3061 Zanker Road, Suite B 781 San Jose, CA 95134 782 U.S.A. 784 Voice: (408) 895-5032 785 EMail: srisuresh@yahoo.com 787 Jan Vilhuber 788 Cisco Systems 789 170 West Tasman Drive 790 San Jose, CA 95134 791 U.S.A. 793 E-mail: vilhuber@cisco.com