idnits 2.17.00 (12 Aug 2021) /tmp/idnits17852/draft-tschofenig-hiprg-hip-natfw-traversal-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1205. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1182. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1189. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1195. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1211), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 363 has weird spacing: '...rovided innov...' -- 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 18, 2004) is 6424 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: draft-ietf-hip-base has been published as RFC 5201 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-base (ref. 'I-D.ietf-hip-base') == Outdated reference: A later version (-02) exists of draft-fessi-nsis-natfw-threats-01 == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 == Outdated reference: draft-ietf-ipsec-nat-t-ike has been published as RFC 3947 == Outdated reference: draft-ietf-ipsec-udp-encaps has been published as RFC 3948 == Outdated reference: draft-ietf-nsis-fw has been published as RFC 4080 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 HIPRG H. Tschofenig 2 Internet-Draft A. Nagarajan 3 Expires: April 18, 2005 Siemens 4 V. Torvinen 5 J. Ylitalo 6 Ericsson 7 J. Grimminger 8 Siemens 9 October 18, 2004 11 NAT and Firewall Traversal for HIP 12 draft-tschofenig-hiprg-hip-natfw-traversal-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 18, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 The Host Identity Protocol is a signaling protocol which adds another 46 layer to the Internet model and establishes IPsec ESP SAs to protect 47 subsequent data traffic. HIP also aims to interwork with middleboxes 48 (such as NATs and Firewalls). This document investigates this aspect 49 in more detail. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 5. Solution Approach . . . . . . . . . . . . . . . . . . . . . . 9 58 5.1 Flow identifier interception . . . . . . . . . . . . . . . 9 59 5.2 Sender Invariance . . . . . . . . . . . . . . . . . . . . 10 60 5.3 Authentication and Authorization . . . . . . . . . . . . . 11 61 5.3.1 What is SPKI? . . . . . . . . . . . . . . . . . . . . 11 62 5.3.2 SAML Usage in HIP . . . . . . . . . . . . . . . . . . 12 63 5.3.3 SPKI usage for HIP . . . . . . . . . . . . . . . . . . 14 64 5.3.4 Authentication and authorization for Base Exchange . . 15 65 5.3.5 Authentication and authorization for Readdressing . . 18 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 69 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 70 8.2 Informative References . . . . . . . . . . . . . . . . . . . 23 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 72 A. Same FW at Initiator for both outgoing and incoming packets . 26 73 B. Different FWs at Initiator for outgoing and incoming 74 packets . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 75 C. Different Firewalls at Initiator and Receiver . . . . . . . . 30 76 Intellectual Property and Copyright Statements . . . . . . . . 33 78 1. Introduction 80 An IP address serves the dual role of a locator and an identifier for 81 every host on the Internet. End systems that use IP addresses as 82 identifiers cannot support dynamic changes in the mapping between the 83 identifier and the locator in case of multi-homing and mobility. 85 The Host Identity Protocol (HIP) [I-D.ietf-hip-base] proposes to 86 separate the identifier from the locator by adding an additional 87 layer between the transport layer and the network layer. The 88 transport layer uses a new, mobility-unrelated identifier, Host 89 Identity Tags (HITs), in place of IP addresses, while the network 90 layer uses conventional IP addresses. IPsec security associations 91 are bound to the HITs and are not modified with IP address changes. 92 In other words, a host despite being mobile or multi-homed can use a 93 single transport layer connection associated to one HIT and multiple 94 IP addresses. 96 One of the integral features of HIP is a protocol to establish IPsec 97 ESP which are subsequently used to encrypt data traffic between the 98 two end hosts. HIP being a mobility protocol also supports changes 99 in IP addresses. Because of this, HIP is liable to all known 100 incompatibilities of IPsec with middleboxes as NATs [RFC3022] and 101 firewalls. This draft investigates problems with the HIP protocol 102 when supporting the secure traversal of NATs and Firewalls. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 This draft used the terminology defined in [NATTerminology], 111 [I-D.ietf-hip-base] and [draft-moskowitz-hip-arch] and [RFC2401]. 113 The term SPI refers to the Security Parameter Index value used in 114 IPsec packets. The initiator selects one SPI(I) which is then used 115 by the responder to create an IPsec packet (ESP packet in this case) 116 for traffic sent to the initiator. The responder selects one SPI(R) 117 which is used by the initiator to encrypt all data sent to the 118 responder. 120 Other relevant abbreviations can be found in [I-D.ietf-hip-base]. 122 The concept of a flow identifier is described in [I-D.ietf-nsis-fw]. 124 3. Problem Statement 126 HIP, as defined in [I-D.ietf-hip-base], does not deal with NATs in 127 the classical way as proposed in [I-D.ietf-ipsec-nat-t-ike] for IKEv1 128 and [I-D.ietf-ipsec-ikev2] for IKEv2. The NAT traversal approach 129 described in [I-D.ietf-ipsec-nat-t-ike] and [I-D.ietf-ipsec-ikev2] 130 allows the NAT to be detected and IPsec protected packets to 131 experience UDP encapsulation (see also [I-D.ietf-ipsec-udp-encaps] 132 with regard to UDP encapsulation). HIP aims to interact with 133 middleboxes (and NATs). 135 In the context of middlebox signaling a few goals can be 136 accomplished: 137 o The UDP encapsulation could be avoided to allow the NAT to use the 138 triplet. The change of 139 an end hosts IP address requires this triplet to be updated. As 140 such it also provides a micro-mobility solution. 141 o Add some authentication and authorization capabilities to NAT 142 traversal. Many NAT traversal solutions today do not provide 143 security at all. 144 o Add secure firewall traversal functionality as another type of 145 middlebox signaling by using triplet. as a substitute for the typical < source IP, 147 destination IP, source port, destination port, transport protocol> 148 information. 150 The HIP protocol is a signaling protocol that carries (what NSIS 151 calls a flow identifier) inside the signaling protocol payloads. 152 Since HIP uses IPsec ESP to encrypt all its payload messages, the 153 flow identifier takes the shape of a . Although HIP is described as a two-party protocol, middle 155 boxes are supposed to intercept these messages in order to learn the 156 flow identifier and to process them correctly. In other words, a 157 multi party protocol is created such that the flow identifier is 158 available to middle boxes between the HIP hosts. To provide proper 159 security middleboxes should not be subject to denial of service 160 attacks and might want to authenticate or authorize entities which 161 create state. Note that the IPsec SA is unidirectional and therefore 162 two IPsec SAs (with two different SPIs) have to be established. 164 Figure 1 shows the HIP base exchange traversing a NAT. 166 I1 +-----------+ I1 167 +-------------------->| |----------------------+ 168 | | | | 169 | | | | 170 R1 | Intercept | R1 v 171 +---------+ <-------------| the flow |<---------------- +---------+ 172 |Initiator| I2 | identifer | I2 |Responder| 173 +---------+ ------------->| +---------+ 174 ^ | SPI,ESP> | 175 | | | | 176 | R2 | | R2 | 177 +---------------------| |<----------------------+ 178 +-----------+ 179 NAT 181 Figure 1: NAT and HIP Base Exchange 183 Subsequently, the HIP base exchange is described in more detail. 185 I -> R: I1: Trigger exchange 187 I <- R: R1: {Puzzle, D-H(R), HI(R), ESP Transform, 188 HIP Transform }SIG 190 I -> R: I2: {Solution, LSI(I), SPI(I), D-H(I), 191 ESP Transform, HIP Transform, {H(I)}SK }SIG 193 I <- R: R2: {LSI(R), SPI(R), HMAC}SIG 195 A potential responsibility of the NAT, as shown in Figure 1, can be 196 the following 197 o Intercept the signaling messages 198 o Authenticate and authorize the HIP nodes by verifying the 199 signatures. 200 o Process the flow identifier information 201 o Perform actions according to the state machine 202 o Create state based on the content of message I2 (SPI(I)) and R2 203 (SPI(R)). Additionally, it might be necessary to include support 204 for storing the respective HITs and host identities. 206 If HIP should also consider firewall traversal then the routing 207 asymmetry needs to be looked into and the fact that the messages I1 208 and I2 do not necessarily traverse the same devices as R1 and R2. 209 The same is true with more complex network topologies with a mixture 210 of NATs and Firewalls. This is an assumption made in the NSIS 211 working group (and therefore also with NAT/Firewall traversal). Pure 212 NAT traversal is therefore simpler to handle in comparison to 213 middlebox traversal which also includes devices such as Firewalls. 214 Figure 3 shows this circumstance graphically: 216 I1 +----------+ I1 217 +--------------------> | Firewall | -----------------------+ 218 | I2 | 1 | I2 | 219 | +-----------------> | | ------------------+ | 220 | | +----------+ v v 221 +---------+ +---------+ 222 |Initiator| |Responder| 223 +---------+ +---------+ 224 ^ ^ R1 +----------+ R1 | | 225 | +------------------ | Firewall | <-------------------+ | 226 | R2 | 2 | R2 | 227 +--------------------- | | <-----------------------+ 228 +----------+ 230 ............... IPsec ESP protected traffic (SPI(R)).........> 231 <.............. IPsec ESP protected traffic (SPI(I)).......... 233 Legend: 234 --- = HIP signaling 235 ... = IPsec protected data traffic 237 Figure 3: NAT and HIP Base Exchange 239 With one single NAT between the HIP nodes, all messages of the base 240 exchange are forced through it. With firewalls, it becomes obvious 241 that the nice property of a NAT with respect to the symmetric 242 forwarding path is lost and the individual firewalls (Firewall 1 and 243 Firewall 2) are unable to create the necessary firewall pinholes. 244 SPI(I) is exchanged in I2 message through firewall 1, however 245 firewall 2 only needs it. Similarly firewall 2 needs SPI (R) which 246 is sent in message R2 through firewall 1. 248 4. Goals 250 The main goal of the draft is to find a suitable NAT/FW traversal 251 solution for the Host Identity Protocol. Such a solution for 252 HIP-based middlebox signaling has to provide the following 253 properties: 254 o A HIP-aware NAT/FW MUST be able to authenticate the entity 255 requesting a NAT binding or a firewall pinhole. 256 o A HIP-aware NAT/FW MUST authorize the entity requesting a NAT 257 binding or a firewall pinhole before storing state information. 258 This requirement might be accomplished by identity based 259 authorization or an identity independent authorization mechanism. 260 o A HIP-aware NAT/FW MUST be able to intercept HIP messages in order 261 to extract the flow identifier information and other related 262 information. HIP messages are base exchange messages during 263 context establishment and readdressing messages during IP address 264 changes. A NAT/FW MUST be able to distinguish these messages. 265 o A NAT/FW node MUST NOT introduce new denial of service attacks 266 based on authentication or key management mechanisms. 267 o A potential solution MUST respect the property of some middleboxes 268 which do not allow traffic (data and signaling traffic) to 269 traverse this middlebox without proper authorization. 271 Some requirements are taken from [I-D.fessi-nsis-natfw-threats]. 273 5. Solution Approach 275 5.1 Flow identifier interception 277 The most important issue with the HIP NAT/FW traversal is to make the 278 flow identifier available to 279 the middleboxes. In the presence of NATs, we are always sure that 280 the forward path and the backward path are same, since the NAT forces 281 the IP packets to flow through these devices. Hence all the 4 282 messages I1, R1, I2 and R2 traverse through a single NAT. This makes 283 it possible for the NATs to intercept the messages for the relevant 284 flow identifier information. But, in the presence of firewalls, 285 routing asymmetry has to be taken into consideration. 287 To enable the firewalls intercept the correct mapping triplet < dest 288 IP, SPI, ESP > certain values have to be resent with the base 289 exchange messages. This is illustrated in the Figure 4. While the 290 IP value of the flow identifier can be intercepted from the IP header 291 of any base exchange message, the SPI value can be intercepted only 292 in messages I2 and R2. I generates its SPI(I) and sends it to R 293 through FW-R. However, FW-I needs this information to forward all 294 packets from R to I. Therefore there has to be someway FW-I can 295 learn this information. One possible method would be that message R2 296 could include the SPI(I) value. However, changes to the base 297 exchange are not desired and we try to keep the base exchange 298 unaffected. The only other possibility would be that once the base 299 exchange is complete, the HIP host I could inform the FW-I in its 300 domain about its SPI(I) value. Similarly, the receiver R could 301 inform the FW-R local to it about its SPI(R).This way, the firewalls 302 will be able to learn the SPI values needed to create the state. 304 FW-R 305 +-+ 306 1.I1 | | I1 307 -------------------------------------> | |---------> 308 | | 309 FW-I +-+ 310 +-+ 311 2.R1 | | R1 312 <---------| | <------------------------------------ 313 | | 314 +-+ FW-R 315 +-+ 316 3.I2 | | I2 317 -------------------------------------->| |---------> 318 | | 319 FW-I +-+ 320 +-+ 321 4.R2 | | R2 322 <---------| | <------------------------------------ 323 | | 324 +-+ 326 FW-I FW-R 327 +-+ +-+ 328 5.SPI(I) | | | | 5.SPI(R) 329 -------->| | | |<-------- 330 | | | | 331 +-+ +-+ 333 Figure 4: Firewalls and mapping information during Base exchange 335 5.2 Sender Invariance 337 The NAT/Firewall HIP node establishes state at possibly several 338 entities between the HIP Initiator and the HIP Responder. Providing 339 authentication of the signaling initiator to each individual HIP node 340 along the path might be possible but not particularly useful, since 341 the initiator is most likely unknown to some middlebox along the 342 path. Hence, authentication per se does not solve the security 343 problem. 345 With mobility it might be possible that intermediate HIP-aware 346 middlebox need some assurance that a particular node is the allowed 347 to modify existing state. No other entity should be allowed to 348 modify state since this would allow certain attacks (such as denial 349 of service or third party flooding). In some respect this issue is 350 similar to the authorization property in Mobile IP where the mobility 351 binding state established at the CN needs to be protected against 352 unauthorized modifications. 354 It seems that the property of "sender Invariance" is required in this 355 case: "A party is assured that the source of the communication has 356 remained the same as the one that started the communication, although 357 the actual identity of the source is not important to the recipient." 359 This property is particularly important in the context of mobility 360 which requires a change in the NAT binding or the packet filter. An 361 outline for solutions have been presented in 362 [I-D.tschofenig-nsis-sid]. SPINAT (see [SPINAT] and [SPINAT1]) 363 provided innovative aspects by using a hash chain approach in 364 combination with delayed authorization to secure state modifications 365 at NAT devices. 367 A future version of this document will address the aspect of sender 368 invariance in more details. 370 5.3 Authentication and Authorization 372 Before a middlebox can allocate a NAT binding or a pin hole, the HIP 373 nodes requesting them may need to be authenticated. Middleboxes 374 could potentially use information stored in the DNS to authenticate 375 the HIP end points. Since Host Identities are used to identify HIP 376 nodes, middleboxes can also use signature verification at relevant 377 HIP messages for authentication. This might raise some issues on 378 denial of service attacks at the middleboxes and these need to be 379 determined. Authorization is certainly more important than 380 authentication particularly since HIP supports ephemeral host 381 identities as a mechanism to preserve privacy. As such it would be 382 useful to use identity independent authorization assertions. SPKI 383 certificates, attribute certificates or similar mechanisms could be 384 of particular use, especially in cases where the HIP nodes prefer to 385 remain anonymous. 387 5.3.1 What is SPKI? 389 SPKI authorization certificates are used in access control and are 390 identity independent. Issuing and receiving an SPKI certificate is 391 completely local to the network domain and there is no need for a 392 higher certification authority to issue them. For a HIP protocol 393 this would mean whenever a HIP host wishes to create a NAT binding or 394 a FW pinhole, it can locally obtain the SPKI certificate for 395 authorization at middleboxes. The structure of the SPKI certificate 396 is shown in Figure 5. 398 +--------+---------+-----------------+ 399 | Key 1 | Key 2 | | 400 | Issuer | Receiver| Can delegate ? | 401 | | | | 402 +--------+---------+-----------------+ 403 | | 404 | Rights | 405 | | 406 +------------------------------------+ 407 | | 408 | Dates |Certificate signed 409 | |by issuer 410 +------------------------------------+ 412 Figure 5: SPKI certificate structure 414 o Key 1 is the public key of the certificate issuer. 415 o Key 2 is the public key of the certificate receiver. 416 o If a subject gets the right to re-delegate its rights, it can 417 re-delegate its certificates to other subjects. In addition, he 418 can freely sign new certificates to other subjects. 419 o Rights define access control of the receiver. 420 o Dates define the validity period of the certificate. 421 o The complete certificate is signed by the private key of the 422 issuer. 424 When a subject wishes to use his certificates, it sends a request 425 that is signed by the subject's private key. Attached are a chain of 426 certificates that belong not only to it but also to those of its 427 delegates. When a verifier receives requests along with a chain of 428 certificates from a subject, the verifier verifies the requests and 429 the certificates. If the verifier is satisfied with the 430 certificates, then the requested operation is allowed. Otherwise, 431 the requests will be refused. 433 5.3.2 SAML Usage in HIP 435 Security Assertion Markup Language (SAML) 436 [I-D.saml-tech-overview-1.1-03] is an XML extension for security 437 information exchange. It is being developed by OASIS. SAML enables 438 entities to access resources by providing assertions which allow 439 authorization. 441 5.3.2.1 Assertions 443 An Assertion is a package of information including authentication 444 statements, attribute statements and authorization decision 445 statements. All kinds of statements do not have to be present, but 446 at least one. An Assertion contains several elements: 448 Issuing information: 450 Who issued the assertion, when was it issued and the assertion 451 identifier. 453 Subject information: 455 The name of the subject, the security domain and optional subject 456 information, like public key. 458 Conditions under which the assertion is valid: 460 special kind of conditions like assertion validity period, 461 audience restriction and target restriction. 463 Additional advice: 465 explaining how the assertion was made, for example. 467 In an authentication statement, an issuing authority asserts that a 468 certain subject was authenticated by certain means at a certain time. 470 In an attribute statement, an issuing authority asserts that a 471 certain subject is associated with certain attributes which has 472 certain values. For example, user jon@cs.example.com is associated 473 with the attribute 'Department', which has the value 'Computer 474 Science'. 476 In an authorization decision statement, a certain subject with a 477 certain access type to a certain resource has given certain evidence 478 that the identity is correct. Based on this, the relying party then 479 makes the decision on giving access or not. The subject could be a 480 human or a program, the resource could be a webpage or a web service, 481 for example. 483 5.3.2.2 Artifact 485 The Artifact is a base-64 encoded string which is 40 bytes long. 20 486 bytes consists of the typecode, which is the source id. The 487 remaining 20 bytes consists of a 20-byte random number that servers 488 use to look up an assertion. The entity creating an Assertion stores 489 it temporarily. The entity performing the authorization decision 490 uses the received Artifact to retrieve the assertion. The purpose of 491 the Artifact is to act as a token which references an Assertion. 493 SAML also defines a request/response protocol for obtaining 494 Assertions. The request asks for an Assertion or makes queries for 495 authentication, attribute and authorization decisions. The response 496 is carrying back the requested Assertion. The XML format for 497 protocol messages are defined within an XML schema. 499 A HIP-aware NAT/Firewall can use this request/response protocol to 500 fetch assertions from the indicated place. 502 HIP can use SAML Assertions in CER payloads to provide a mechanism 503 for HIP end points to authorize them towards middlebox using an 504 emerging technology. Furthermore, SAML Assertions can be used to 505 bind the authorization decision of different protocols sessions from 506 different layers in the ISO-OSI model together. As an example, the 507 authorization decision by an application layer entity can be used to 508 bind it to a subsequent HIP exchange. SAML provides a complete 509 solution for authorization using Artifacts and Assertions and the 510 corresponding protocols to obtain them. The assertions are based on 511 XML which allows extensibility beyond the initially envisioned 512 deployment area. 514 5.3.3 SPKI usage for HIP 516 HIP has already defined the CERT parameter that can carry 517 certificates. The HIP nodes requesting a NAT/FW traversal can send 518 their base exchange message with the CERT parameter. The CERT will 519 carry the SPKI certificate and the packet will be signed by the 520 requesting HIP node. This would mean, messages I2 and R2 should 521 include the CERT parameter to get them authorized at the middleboxes. 522 The structure of the SPKI certificate for HIP is shown in Figure 6. 524 +------+-------+---------------+ 525 | Key1 |HI(I/R)|Can Delegate? | 526 +------+-------+---------------+ 527 | | 528 | Rights for NAT/FW traversal | 529 +------------------------------+ 530 | | 531 | Date and further info | 532 +------------------------------+ 533 | | 534 | Digital Signature | 535 +------------------------------+ 537 Figure 6: SPKI certificate structure for HIP 539 5.3.4 Authentication and authorization for Base Exchange 541 When a HIP host requests a NAT binding or a FW pinhole, it has to be 542 first authenticated and authorized by the middleboxes. Since all HIP 543 packets are signed using the private keys of the HIP hosts, 544 middleboxes can verify these packets using the signature 545 verifications. These of course will introduce certain kinds of 546 denial of service attacks. Denial of service attacks for signature 547 verification at middleboxes can be prevented by using the client 548 puzzle concept used by the HIP protocol. For more details the HIP 549 protocol [I-D.ietf-hip-base] can be consulted. This will force the 550 middleboxes to delay state creation and to also delay expensive 551 computational operations. As detailed in previous sections, we seek 552 to use non-identity based authorization mechanisms that can be 553 verified by the middleboxes before creating a NAT binding or FW 554 pinhole. Since NATs force the outbound and inbound packets to flow 555 through them, they are much easier to handle. For instance, the 556 mechanism used by SPINAT [SPINAT] can be used for authorization of 557 state modifications by utilizing hash chains and delayed 558 authentication with NATS. However, this is not presently suitable 559 for firewalls with asymmetric paths. More work needs to be done 560 towards extending this idea for a combination of NATs and firewalls 561 with routing asymmetry. 563 A HIP host behind a firewall might need to register itself with local 564 middleboxes before the base exchange can be initiated or completed. 565 Firewalls might not allow the traffic to bypass the firewall. For 566 this, we consider using messages I1',R1',I2' and R2' which are an 567 extended version of the normal base exchange messages used in HIP. 568 However, these messages are exclusively used only for configuring the 569 HIP host with the firewalls such that authentication and 570 authorization is complete before the firewall opens up a pinhole. 572 With this approach, we make fewer changes to the base exchange by 573 avoiding the inclusion of certain authorization parameters into them. 574 We refer to this exchange as 'Registration Procedure' as shown in 575 Figure 7 which provides more details of this lightweight protocol 576 exchange. 578 End host-to-Middlebox or E2M messages 580 I -> R: I1: Trigger exchange 581 OR 582 I -> FW1: I1': Trigger exchange 584 I <- FW1: R1': {Puzzle, D-H(R), HI(R),HIP Transform}SIG 586 I -> FW1: I2': {Solution,D-H(I),HIP Transform,{H(I)},CERT(I)}SIG 588 I <- FW1: R2': {HMAC}SIG 590 Figure 7: HIP NAT/Firewall Registration Procedure 592 As an overview, we modify the HIP exchange protocol to authenticate 593 the middlebox towards the initiator, to authorize (and possibly 594 authenticate) the initiator towards the firewall and to establish a 595 security association between the initiator and the responder. We 596 reuse the HIP protocol for this purpose to use the same 597 infrastructure and to benefit from a lightweight protocol. Note that 598 the message flow in Figure 7 does not establish IPsec security 599 associations. These security associations are not necessary in most 600 scenarios. 602 When a host I wishes to create a pinhole with a FW on its side (named 603 as FW-I), it has two choices: 604 o It sends a regular I1 message to the firewall. This assumes that 605 the end host knows that a firewall is located in the network and 606 additionally the address of this firewall is also known to the end 607 host. This might be the case in a corporate network environment. 608 This is shown as the I1' message. 609 o The initiator I can also send a regular HIP I1 message towards a 610 destination host (denoted as R). This message will then be 611 intercepted by the firewall and a R1' is returned. 613 With R1' the firewall sends a puzzle to the initiator similar to the 614 one sent from a HIP receiver to a HIP initiator. The initiator 615 solves the puzzle and sends the solution back to the FW along with 616 its SPKI certificate using the I2' message. Note that the Initiator 617 can send its certificate in the I1/I1' message. This will, however, 618 the FW to create a state even before the client puzzle solution is 619 obtained from the initiator. This raises some denial of service 620 concerns. The FW can validate this SPKI certificate and authorize 621 the HIP host I1. This packet is not liable to any denial of service 622 or replay attacks as the solution is dependent on the cookie that R1' 623 included. Hence, the FW can look into the cookie index to avoid 624 unwanted signature verifications. The ESP transforms are also 625 dropped here as the there will be no IPsec ESP packets exchanged 626 between the HIP host and the FW. There is also no need for the 627 SPI(I) values in I2' and R2' messages. 629 Once the FW receives the I2' packet, it verifies the solution to make 630 sure that it is the entity to which it sent the R1' packet. It sends 631 a R2' packet back to the initiator as an acknowledgement for 632 authorization. The R2' packet however should include a HMAC to 633 prevent denial of service attacks on I. 635 After I receives the R2' packet, it can now initiate the normal base 636 exchange that the FW will forward to R. 638 On receiving I1, receiver R will send a R1 message back to the 639 initiator. However, since the FW-R at the receiver end also needs to 640 authenticate and authorize the receiver, we run the registration 641 procedure with the E2M messages similar to the previous step between 642 FW-R and receiver R. Once receiver R receives the acknowledgement 643 R2', it now sends packet R1 to the initiator that the FW-R will 644 forward. The rest of the base exchange continues as usual. However 645 for the sake of the SPI interception at the firewalls, as mentioned 646 before signaling messages have to be sent from the HIP hosts to their 647 local middleboxes about the SPI values they have agreed on. 649 I1' FW-I 650 ----------------> +-+ 651 R1' | | 652 <---------------- | | 653 I2' | | 654 ----------------> | | 655 R2' | | 656 <---------------- | | 657 I1 | | 1.I1 658 ---------------> | | -----------------------------------> 659 +-+ 661 FW-R R1 662 +-+<--------------- 663 | | R1' 664 | |----------------> 665 | | I2' 666 | |<---------------- 667 | | R2' 668 | |----------------> 669 2.R1 | | R1 670 <--------------------------------------| |<--------------- 671 +-+ 673 FW-I 674 +-+ 675 3.I2 | | I2 676 ---------------> | | ------------------------------------> 677 | | 678 +-+ 680 FW-R 681 +-+ 682 4.R2 | | R2 683 <-------------------------------------| |<------------------ 684 | | 685 +-+ 687 FW-I FW-R 688 +-+ +-+ 689 5.SPI(I) | | | | 5.SPI(R) 690 --------------->| | | |<------------------ 691 | | | | 692 +-+ +-+ 694 Figure 8: Authentication and authorization for base exchange messages 696 5.3.5 Authentication and authorization for Readdressing 698 After the base exchange is complete, IPsec payload packets are 699 exchanged among the HIP hosts. The middleboxes use the state that is 700 established with them to forward such packets to the HIP hosts. The 701 state at FW-R is < SPI(R), IP(R), HIT(R) > and state at FW-I will be 702 < SPI(I), IP(I), HIT(I) >.When one of the HIP hosts moves, it sends 703 an UPDATE message to its peer informing about the new IP addresses. 704 The peer will send a new SPI value back to the initiator to make a 705 return routability check. If the peer receives data from the 706 initiator on the new security association with this new SPI, it 707 confirms the mobile node has moved and is indeed reachable at the new 708 IP address. For middleboxes that use as the flow identifier to forward HIP packets, this 710 information needs to be updated with every UPDATE message. FW-I 711 (assuming that I is mobile) has to intercept the new IP address of I 712 while FW-R (behind which is the peer R) has to update the new SPI(R) 713 to forward packets correctly. This is illustrated in Figure 9. 715 FW-R 716 +-+ 717 1.UPDATE with REA[new IP(I)] | | 718 ---------------------------------+ |----------------> 719 | | 720 FW-I +-+ 721 +-+ 722 | | 2.UPDATE[new SPI(R)] to IP(I) 723 <---------| |---------------------------------------- 724 | | 725 | | 726 +-+ 728 FW-R 729 +-+ 730 | | 3.new SPI(R) 731 | |<------------------ 732 | | 733 +-+ 734 FW-I 735 +-+ 736 | | 4.Data on the new SA 737 ---------| |----------------------------------------> 738 | | 739 | | 740 +-+ 742 Figure 9: Authentication and authorization for UPDATE messages 744 As seen, FW-R has the flow identifier information for receiver R and 745 FW-I has the flow identifier information for initiator I. When I 746 sends a UPDATE message with a REA parameter, R sends a new SPI(R) to 747 check the reachability of the new IP address. FW-I can intercept the 748 destination IP address from this message and can update its 749 information. After both the UPDATE and UPDATE reply messages have 750 been sent out, the receiver needs to signal the FW-R about it new 751 SPI(R). Denial of service attacks and replay attacks are 752 considerably reduced at firewalls if the firewalls keep track of the 753 UPDATE ID that is sent in the UPDATE messages. Every UPDATE REPLY 754 message carries the same number as the UPDATE message and hence the 755 middleboxes are able to keep up the sequence. Issues as to how the 756 receiver can inform the FW-R about its new SPI(R) even before it has 757 received a confirmation on the return routability test have to be 758 considered. 760 However, even this is true only if the new access point has the same 761 set of middleboxes. If the mobile node is behind a new firewall 762 while sending an UPDATE message, the firewall does not have any state 763 information to create a pin hole. Hence, it should send a trigger 764 message that will reinitiate the extended E2M messages between the 765 mobile node and the firewall as in Figure 8. 767 6. Security Considerations 769 In this approach, we have tried to extend the HIP base exchange to 770 create a state at the NAT/FW securely. Though it is possible to make 771 this configuration along with the base exchange messages itself, the 772 middlebox traversal will significantly alter the original base 773 exchange messages as including the sequence numbers and SPI values 774 for the middleboxes. By extending the base exchange messages as 775 I1',R1',I2' and R2', we also effectively make use of the security 776 features that comes with the HIP protocol to protect the 777 configuration information between the HIP hosts and the middleboxes. 778 We will now quickly look into some possible security threats at the 779 middleboxes and how extended HIP base exchange mechanism can protect 780 the configuration information. 782 Extended Base Exchange messages for configuration 783 o Message I1' is only a trigger message sent from the initiator to 784 the FW. FW has support to precompute many R1' messages and to 785 send them in response to the I1' messages. Since the FW does not 786 create any state at this point in time, it is quite difficult to 787 launch a DoS attack here. 788 o Message R1' can be spoofed by a MITM and can tie up an initiator 789 with solving puzzles for a long time. However, this is avoided by 790 solving puzzles in R1' messages that correspond to a previously 791 sent I1' message only. 792 o On receiving an I2' message, a FW is expected to verify the 793 signature and validate the certificates. There can be possible 794 DoS and replay attacks here either to create multiple false states 795 at the firewall or to reuse the certificates. However, the FW 796 maintains a cookie index and the corresponding cookie that was 797 sent in the R1' packet. The firewall can choose to validate the 798 certificate only if the cookie index and the cookie value both 799 match the expected values. These verifications can considerably 800 prevent such attacks. 801 o Hosts are protected against replays to R2' by use of a less 802 expensive HMAC verification preceding HIP signature verification. 803 o Hosts can prevent denial of service attacks and replay attacks 804 with the UPDATE message with the use of the UPDATE ID in the 805 UPDATE packets. These UPDATE messages are sequence numbers which 806 the middleboxes can keep a track of. They can simply precede any 807 signature verification by checking the UPDATE ID first. 809 7. Acknowledgements 811 The authors would like to thank Pekka Nikander, Dieter Gollmann and 812 Thomas Aura for their feedback to this document. 814 This document is a byproduct of the Ambient Networks Project, 815 partially funded by the European Commission under its Sixth Framework 816 Programme. It is provided "as is" and without any express or implied 817 warranties, including, without limitation, the implied warranties of 818 fitness for a particular purpose. The views and conclusions 819 contained herein are those of the authors and should not be 820 interpreted as necessarily representing the official policies or 821 endorsements, either expressed or implied, of the Ambient Networks 822 Project or the European Commission. 824 8. References 826 8.1 Normative References 828 [I-D.ietf-hip-base] 829 Moskowitz, R., "Host Identity Protocol", 830 draft-ietf-hip-base-00 (work in progress), June 2004. 832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 833 Requirement Levels", March 1997. 835 8.2 Informative References 837 [I-D.fessi-nsis-natfw-threats] 838 Fessi, A., "Security Threats for the NAT/Firewall NSLP", 839 draft-fessi-nsis-natfw-threats-01 (work in progress), July 840 2004. 842 [I-D.ietf-ipsec-ikev2] 843 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 844 draft-ietf-ipsec-ikev2-14 (work in progress), May 2004. 846 [I-D.ietf-ipsec-nat-t-ike] 847 Kivinen, T., "Negotiation of NAT-Traversal in the IKE", 848 draft-ietf-ipsec-nat-t-ike-08 (work in progress), February 849 2004. 851 [I-D.ietf-ipsec-udp-encaps] 852 A. Huttunen et all, A., "UDP Encapsulation of IPsec 853 Packets", DRAFT draft-ietf-ipsec-udp-encaps-07.txt, Jan 854 2003. 856 [I-D.ietf-nsis-fw] 857 Hancock, R., "Next Steps in Signaling: Framework", 858 draft-ietf-nsis-fw-05 (work in progress), October 2003. 860 [I-D.saml-tech-overview-1.1-03] 861 Maler, E. and J. Hughes, "Technical Overview of the OASIS 862 Security Assertion Markup Language (SAML) V1.1", March 863 2004. 865 [I-D.tschofenig-nsis-sid] 866 Tschofenig, H., "Security Implications of the Session 867 Identifier", draft-tschofenig-nsis-sid-00 (work in 868 progress), June 2003. 870 [NATTerminology] 871 Srisuresh, P. and M. Holdrege, "IP Network Address 872 Translator (NAT) Terminology and Considerations", Request 873 For Comments RFC 2663, August 1999. 875 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 876 Internet Protocol", RFC 2401, November 1998. 878 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 879 Address Translator (Traditional NAT)", RFC 3022, January 880 2001. 882 [SPINAT] Ylitalo, J., Melen, J., Nikander, P. and V. Torvinen, 883 "Re-thinking Security in IP based Micro-Mobility", 7th 884 Information Security Conference (ISC-04), Palo Alto,", 885 September 2004. 887 [SPINAT1] Ylitalo, J., Melen, J. and P. Nikander, "SPINAT: A 888 Security Framework for Local IP Mobility Management, 889 unpublished manuscript", November 2003. 891 [draft-crocker-multiaddr-analysis] 892 Crocker, D., "Choices for Multiaddressing", 893 draft-crocker-multiaddr-analysis-01.txt (work in 894 progress), October 2003. 896 [draft-ietf-ipsec-esp-v3-08] 897 Kent, S., "IP Encapsulating Security Payload (ESP)", 898 draft-ietf-ipsec-esp-v3-08 (work in progress) (work in 899 progress), March 2004. 901 [draft-moskowitz-hip-arch] 902 Moskowitz, R. and P. Nikander, "Host Identity Protocol 903 Architecture", draft-moskowitz-hip-arch-05 (work in 904 progress) (work in progress), September 2003. 906 [draft-nikander-hip-mm] 907 Nikander, P. and J. Arkko, "End-Host Mobility and 908 Multi-Homing with Host Identity Protocol", 909 draft-nikander-hip-mm-01.txt (work in progress) (work in 910 progress), December 2003. 912 [rfc3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 913 Address Translator (Traditional NAT)", Request For 914 Comments RFC 3022, January 2001. 916 Authors' Addresses 918 Hannes Tschofenig 919 Siemens 920 Otto-Hahn-Ring 6 921 Munich, Bayern 81739 922 Germany 924 EMail: Hannes.Tschofenig@siemens.com 926 Aarthi Nagarajan 927 Siemens 928 Otto-Hahn-Ring 6 929 Munich, Bayern 81739 930 Germany 932 EMail: aarthi.nagarajan@tuhh.de 934 Vesa Torvinen 935 Ericsson 936 Joukahaisenkatu 1 937 Turku FIN 20520 938 Finland 940 EMail: vesa.torvinen@ericsson.com 942 Jukka Ylitalo 943 Ericsson Research Nomadiclab 945 Jorvas FIN 02420 946 Finland 948 Phone: +358 9 299 1 949 EMail: jukka.ylitalo@ericsson.com 951 Jochen Grimminger 952 Siemens 953 Otto-Hahn-Ring 6 954 Munich, Bayern 81739 955 Germany 957 EMail: jochen.grimminger@siemens.com 959 Appendix A. Same FW at Initiator for both outgoing and incoming packets 961 This scenario assumes that the initiator I alone is behind a firewall 962 named FW(I). This firewall is both for the outgoing and incoming 963 packets and hence can look into all the base exchange messages. The 964 FW(I) is expected to authenticate and authorize the initiator to send 965 out going packets, receiver if necessary to let incoming packets and 966 intercept the flow identifier from the base exchange. With the E2M 967 messages, it can be achieved as follows. This is illustrated in 968 Figure 10 970 FW(I) 971 I1 +-----+ I1 972 +----------> | |--------------------------------------+ 973 | I2 | | I2 | 974 | +-----> | |---------------------------------+ | 975 | | | | | | 976 | | | | v v 977 ---------+ | | +--------+ 978 Initiator| | | |Receiver| 979 ---------+ | | +--------+ 980 ^ ^ | | 981 | | R2 | | R2 | | 982 | +------ | |< --------------------------------+ | 983 | R1 | | R1 | 984 +---------- | |< -------------------------------------+ 985 +-----+ 987 Figure 10: One FW only at initiator end 989 1. I1 packet is sent from the initiator I to receiver R. 990 2. FW(I) drops the packet and sends a R1' message back to I. This 991 is the End host-to-Middlebox or E2M message exchange initiation. 992 3. I sends I2' message with CERT(I) parameters to FW(I). It 993 requests the FW(I) to open up a pinhole. 994 4. FW verifies SPKI certificate and the signature of I. 995 Accordingly, it either sends a R2' to acknowledge I that it can 996 continue with the base exchange with message I1 or drops packet 997 if verification fails. 998 5. On receiving R2',I sends message I1 to R again. Now the FW(I) 999 will let the packet through. 1000 6. R sends the message R1 to I. 1001 7. On receiving R1, if FW(I) wishes to authenticate/authorize the 1002 receiver R, it should initiate E2M exchange here. It sends 1003 message R1'to R forcing R to send an I2' in exchange. 1004 8. R sends the CERT(R) parameter in I2'. 1006 9. FW verifies SPKI certificate and the signature of R. 1007 Accordingly, it either sends a R2' to acknowledge R that it can 1008 continue with the base exchange with message R1 or drops packet 1009 if verification fails. 1010 10. On receiving R2', R sends message R1 to I again. Now the FW(I) 1011 will let it through. 1012 11. The base exchange continues until complete. Since all messages 1013 I1,R1,I2 and R2 traverse through FW(I), it can look into these 1014 messages to learn the flow identifier information. 1016 Appendix B. Different FWs at Initiator for outgoing and incoming 1017 packets 1019 This scenario assumes that the initiator I alone is behind firewalls 1020 named FW1(I) and FW2(I).FW1(I) is for the incoming packets to I and 1021 FW2(I) is for the outgoing packets to R. The FW(I) is expected to 1022 authenticate and authorize the initiator to send out going packets, 1023 while FW2(I) would authenticate and authorize the receiver, if 1024 necessary to let incoming packets. It is sufficient that FW2(I) 1025 alone learns the flow identifier information of I. It should store 1026 the state to forward IPsec protected payload 1027 packets. This scenario is illustrated in Figure 11 1029 FW1(I) 1030 I1 +-----+ I1 1031 +----------> | |--------------------------------------+ 1032 | I2 | | I2 | 1033 | +-----> | |---------------------------------+ | 1034 | | +-----+ | | 1035 | | v v 1036 +---------+ +--------+ 1037 |Initiator| |Receiver| 1038 +---------+ FW2(I) +--------+ 1039 ^ ^ +-----+ 1040 | | R2 | | R2 | | 1041 | +------ | |< --------------------------------+ | 1042 | R1 | | R1 | 1043 +---------- | |< -------------------------------------+ 1044 +-----+ 1046 Figure 11: Two FWs at initiator's end 1048 1. I1 packet is sent from the initiator I to receiver R. 1049 2. FW1(I) drops the packet and sends a R1' message back to I. This 1050 is the E2M message exchange initiation. 1051 3. I sends I2' message with CERT(I) parameters to FW1(I). It 1052 requests the FW1(I) to open up a pinhole. 1053 4. FW1(I) verifies SPKI certificate and the signature of I. 1054 Accordingly, it either sends a R2' to acknowledge I that it can 1055 continue with the base exchange with message I1 or drops packet 1056 if verification fails. 1057 5. On receiving R2',I sends message I1 to R again. Now the FW1(I) 1058 will let the packet through. 1059 6. R sends the message R1 to I. 1060 7. On receiving R1, if FW2(I) wishes to authenticate/authorize the 1061 receiver R, it should initiate E2M exchange here. It sends 1062 message R1'to R forcing R to send an I2' in exchange. 1064 8. R sends the CERT(R) parameter in I2'. 1065 9. FW2(I) verifies SPKI certificate and the signature of R. 1066 Accordingly, it either sends a R2' to acknowledge R that it can 1067 continue with the base exchange with message R1 or drops packet 1068 if verification fails. 1069 10. On receiving R2', R sends message R1 to I again. Now the FW2(I) 1070 will let it through. 1071 11. Since FW2(I) needs the store the state, once the base exchange 1072 is complete, the initiator should inform the FW2(I) about the 1073 SPI it has chosen for the exchange. This way, FW2(I) can 1074 forward further IPsec payload packets from R to I 1076 Appendix C. Different Firewalls at Initiator and Receiver 1078 This scenario looks into a more complicated situation. Initiator I 1079 is behind multiple firewalls FW1(I) for outgoing packets and FW2(I) 1080 and FW3(I) are for incoming packets. Similarly, receiver R is behind 1081 FW1(R) and FW2(R) for incoming packets and FW3(R) for outgoing 1082 packets. The incoming firewalls are chosen based on the type of the 1083 application and the hosts are unaware from which firewall they 1084 receive packets. Here, however for our scenario we assume that 1085 FW2(R) and FW2(I) are chosen about which also the hosts are unaware 1086 of. The FW1(I) is expected to authenticate and authorize the 1087 initiator to send outgoing packets to R, while FW2(R) would 1088 authenticate and authorize the receiver to let outgoing packets to I. 1089 FW2(R) should store the state for the receiver 1090 while FW2(I) should store the state for the 1091 initiator. This scenario is illustrated in Figure 12 1092 +-----+ 1093 | | 1094 |FW1-R| 1095 | | 1096 +-----+ +-----+ 1097 I1 | | I1 +-----+ 1098 +------------| | -------------------> | |---------+ 1099 | I2 |FW1-I| I2 |FW2-R| | 1100 | +-------| | -------------------> | |----+ | 1101 | | | | +-----+ | | 1102 | | +-----+ v v 1103 +---------+ +--------+ 1104 |Initiator| |Receiver| 1105 +---------+ +--------+ 1106 ^ ^ +-----+ 1107 | | R2 | | R2 +-----+ | | 1108 | +------ |FW2-I| <--------------------| |-----+ | 1109 | R1 | | R1 |FW3-R| | 1110 +---------- | | <--------------------| |----------+ 1111 +-----+ | | 1112 +-----+ | | 1113 | | +-----+ 1114 |FW3-I| 1115 | | 1116 +-----+ 1118 Figure 12: Multiple FWs at initiator's and receiver's end 1120 1. I1 packet is sent from the initiator I to receiver R. 1121 2. FW1(I) drops the packet and sends a R1' message back to I. This 1122 is the E2M message exchange initiation. 1123 3. I sends I2' message with CERT(I) parameters to FW1(I). It 1124 requests the FW1(I) to open up a pinhole. 1125 4. FW1(I) verifies SPKI certificate and the signature of I. 1126 Accordingly, it either sends a R2' to acknowledge I that it can 1127 continue with the base exchange with message I1 or drops packet 1128 if verification fails. 1129 5. On receiving R2',I sends message I1 to R again. Now the FW1(I) 1130 will let the packet through. 1131 6. This packet would reach FW2(R). If this firewall wishes to 1132 authenticate and authorize the initiator I, then it can start a 1133 E2M exchange with I. After this is successfully completed, 1134 FW2(R) would open up a pinhole to send packets to R. 1135 7. R sends the message R1 to I. 1136 8. When R sends R1 to I, FW3(R) would initiate a E2M message to 1137 authenticate and authorize the receiver R. After this is 1138 complete, it will forward the packet to the initiator. On 1139 receiving R1, if FW2(I) wishes to authenticate/authorize the 1140 receiver R, it should initiate E2M exchange here. 1141 9. FW2(I) verifies SPKI certificate and the signature of R. 1142 Accordingly, it either sends a R2' to acknowledge R that it can 1143 continue with the base exchange with message R1 or drops packet 1144 if verification fails. 1145 10. On receiving R2', R sends message R1 to I again. Now the FW2(I) 1146 will let it through. 1147 11. This has completed only one round of authentication and 1148 authorization. However, the states are still not established at 1149 the firewalls. For this, the hosts have to signal their 1150 incoming firewalls about the SPI that they have chosen for IPsec 1151 ESP packets to follow. 1153 When hosts are behind multiple incoming firewalls, there are uble to 1154 decide to which firewall they have to inform their SPI values to. 1155 The first option would be to somehow make the chosen FW to signal the 1156 host about its requirement for a state to forward IPsec protected 1157 packets (similar to a pull model). This could be possibly done along 1158 with the first incoming packet which is R1. R1 packet could include 1159 extra signaling as record route to the initiator. The second option 1160 would be to inform firewall about the SPI values (like the push 1161 model). Here, however it would be necessary to send an extra message 1162 I3 from the initiator to the receiver which would include the SPI(I) 1163 for FW(I) and to resend the SPI(R) in I2 message for FW(R). 1165 The second problem is to secure the SPI signalling message from the 1166 end host to the FW. Since the endhosts authenticate and authorize to 1167 the FW that lets outgoing packets, they share keys only with them. 1168 However, they need to signal the SPI value to the FW on the other end 1169 which forwards incoming packets . For the sake of securing the SPI 1170 value, it might be necessary that the end hosts have to run a E2M 1171 exchange with the firewalls on the receiving end also. 1173 Intellectual Property Statement 1175 The IETF takes no position regarding the validity or scope of any 1176 Intellectual Property Rights or other rights that might be claimed to 1177 pertain to the implementation or use of the technology described in 1178 this document or the extent to which any license under such rights 1179 might or might not be available; nor does it represent that it has 1180 made any independent effort to identify any such rights. Information 1181 on the procedures with respect to rights in RFC documents can be 1182 found in BCP 78 and BCP 79. 1184 Copies of IPR disclosures made to the IETF Secretariat and any 1185 assurances of licenses to be made available, or the result of an 1186 attempt made to obtain a general license or permission for the use of 1187 such proprietary rights by implementers or users of this 1188 specification can be obtained from the IETF on-line IPR repository at 1189 http://www.ietf.org/ipr. 1191 The IETF invites any interested party to bring to its attention any 1192 copyrights, patents or patent applications, or other proprietary 1193 rights that may cover technology that may be required to implement 1194 this standard. Please address the information to the IETF at 1195 ietf-ipr@ietf.org. 1197 Disclaimer of Validity 1199 This document and the information contained herein are provided on an 1200 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1201 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1202 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1203 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1204 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1205 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1207 Copyright Statement 1209 Copyright (C) The Internet Society (2004). This document is subject 1210 to the rights, licenses and restrictions contained in BCP 78, and 1211 except as set forth therein, the authors retain all their rights. 1213 Acknowledgment 1215 Funding for the RFC Editor function is currently provided by the 1216 Internet Society.