idnits 2.17.1 draft-ietf-ipsecme-ikev2-resumption-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 15, 2009) is 5459 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: 'CERTREQ' is mentioned on line 271, but not defined -- Looks like a reference, but probably isn't: '3' on line 955 -- Looks like a reference, but probably isn't: '8' on line 956 == Unused Reference: 'RFC4718' is defined on line 890, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-07) exists of draft-eronen-ipsec-ikev2-eap-auth-06 == Outdated reference: A later version (-13) exists of draft-ietf-ipsecme-ikev2-redirect-09 == Outdated reference: A later version (-11) exists of draft-ietf-ipsecme-ikev2bis-03 == Outdated reference: A later version (-12) exists of draft-ietf-rohc-ikev2-extensions-hcoipsec-08 -- Obsolete informational reference (is this intentional?): RFC 4718 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Sheffer 3 Internet-Draft Check Point 4 Intended status: Standards Track H. Tschofenig 5 Expires: November 16, 2009 Nokia Siemens Networks 6 L. Dondeti 7 V. Narayanan 8 QUALCOMM, Inc. 9 May 15, 2009 11 IKEv2 Session Resumption 12 draft-ietf-ipsecme-ikev2-resumption-04.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on November 16, 2009. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 The Internet Key Exchange version 2 (IKEv2) protocol has a certain 51 computational and communication overhead with respect to the number 52 of round-trips required and the cryptographic operations involved. 53 In remote access situations, the Extensible Authentication Protocol 54 (EAP) is used for authentication, which adds several more round trips 55 and consequently latency. 57 To re-establish security associations (SAs) upon a failure recovery 58 condition is time consuming especially when an IPsec peer (such as a 59 VPN gateway) needs to re-establish a large number of SAs with various 60 end points. A high number of concurrent sessions might cause 61 additional problems for an IPsec peer during SA re-establishment. 63 In order to avoid the need to re-run the key exchange protocol from 64 scratch it would be useful to provide an efficient way to resume an 65 IKE/IPsec session. This document proposes an extension to IKEv2 that 66 allows a client to re-establish an IKE SA with a gateway in a highly 67 efficient manner, utilizing a previously established IKE SA. 69 A client can reconnect to a gateway from which it was disconnected. 70 The proposed approach requires passing opaque data from the IKEv2 71 responder to the IKEv2 initiator, which is later made available to 72 the IKEv2 responder for re-authentication. We use the term ticket to 73 refer to the opaque data that is created by the IKEv2 responder. 74 This document does not specify the format of the ticket but 75 recommendations are provided. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 6 82 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7 83 4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 7 84 4.2. Receiving a Ticket . . . . . . . . . . . . . . . . . . . . 9 85 4.3. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 9 86 4.4. IKE_SESSION_RESUME Details . . . . . . . . . . . . . . . . 11 87 4.5. Requesting a Ticket During Resumption . . . . . . . . . . 11 88 4.6. IP Address Change and NAT . . . . . . . . . . . . . . . . 11 89 4.7. IKE Notifications . . . . . . . . . . . . . . . . . . . . 11 90 4.7.1. TICKET_LT_OPAQUE Notify Payload . . . . . . . . . . . 12 91 4.7.2. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . 12 92 4.8. Computing the AUTH Payload . . . . . . . . . . . . . . . . 13 93 5. Processing Guidelines for IKE SA Establishment . . . . . . . . 13 94 6. The State After Resumption . . . . . . . . . . . . . . . . . . 14 95 7. Ticket Handling . . . . . . . . . . . . . . . . . . . . . . . 16 96 7.1. Ticket Content . . . . . . . . . . . . . . . . . . . . . . 16 97 7.2. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17 98 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 100 9.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 18 101 9.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 18 102 9.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 18 103 9.4. Key Management for Tickets By Value . . . . . . . . . . . 19 104 9.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 19 105 9.6. Ticket by Value Format . . . . . . . . . . . . . . . . . . 19 106 9.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 20 107 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 108 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 109 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 110 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 111 Appendix A. Ticket Format . . . . . . . . . . . . . . . . . . . . 22 112 A.1. Example Ticket by Value Format . . . . . . . . . . . . . . 22 113 A.2. Example Ticket by Reference Format . . . . . . . . . . . . 23 114 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24 115 B.1. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 116 B.2. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 117 B.3. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 118 B.4. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 119 B.5. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 120 B.6. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 121 B.7. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 122 B.8. -04 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 123 B.9. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 124 B.10. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 125 B.11. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 126 B.12. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 129 1. Introduction 131 The Internet Key Exchange version 2 (IKEv2) protocol has a certain 132 computational and communication overhead with respect to the number 133 of round-trips required and the cryptographic operations involved. 134 In particular the Extensible Authentication Protocol (EAP) is used 135 for authentication in remote access cases, which increases latency. 137 To re-establish security associations (SA) upon a failure recovery 138 condition is time-consuming, especially when an IPsec peer, such as a 139 VPN gateway, needs to re-establish a large number of SAs with various 140 end points. A high number of concurrent sessions might cause 141 additional problems for an IPsec responder. 143 In many failure cases it would be useful to provide an efficient way 144 to resume an interrupted IKE/IPsec session. This document proposes 145 an extension to IKEv2 that allows a client to re-establish an IKE SA 146 with a gateway in a highly efficient manner, utilizing a previously 147 established IKE SA. 149 A client can reconnect to a gateway from which it was disconnected. 150 One way to ensure that the IKEv2 responder is able to recreate the 151 state information is by maintaining IKEv2 state (or a reference into 152 a state store) in a "ticket", an opaque data structure. This ticket 153 is created by the server and forwarded to the client. The IKEv2 154 protocol is extended to allow a client to request and present a 155 ticket. This document does not mandate the format of the ticket 156 structure but a recommendation is provided. In Appendix A a ticket 157 by value and a ticket by reference format is proposed. 159 This approach is similar to the one taken by TLS session resumption 160 [RFC5077] with the required adaptations for IKEv2, e.g., to 161 accommodate the two-phase protocol structure. We have borrowed 162 heavily from that specification. 164 The proposed solution should additionally meet the following goals: 166 o Using only symmetric cryptography to minimize CPU consumption. 167 o Providing cryptographic agility. 168 o Having no negative impact on IKEv2 security features. 170 The following are non-goals of this solution: 171 o Failover from one gateway to another. This use case may be added 172 in a future specification. 173 o Providing load balancing among gateways. 174 o Specifying how a client detects the need for resumption. 176 2. Terminology 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 This document uses terminology defined in [RFC4301] and [RFC4306]. 183 In addition, this document uses the following terms: 185 Ticket: An IKEv2 ticket is a data structure that contains all the 186 necessary information that allows an IKEv2 responder to re- 187 establish an IKEv2 security association. 189 In this document we use the term "ticket" and thereby refer to an 190 opaque data structure that may either contain IKEv2 state as 191 described above or a reference pointing to such state. 193 3. Usage Scenario 195 This specification envisions two usage scenarios for efficient IKEv2 196 and IPsec SA session re-establishment. 198 The first is similar to the use case specified in Section 1.1.3 of 199 the IKEv2 specification [RFC4306], where the IPsec tunnel mode is 200 used to establish a secure channel between a remote access client and 201 a gateway; the traffic flow may be between the client and entities 202 beyond the gateway. This scenario is further discussed below. 204 The second use case focuses on the usage of transport (or tunnel) 205 mode to secure the communicate between two end points (e.g., two 206 servers). The two endpoints have a client-server relationship with 207 respect to a protocol that runs using the protections afforded by the 208 IPsec SA. 210 (a) 212 +-+-+-+-+-+ +-+-+-+-+-+ 213 ! ! IKEv2/IKEv2-EAP ! ! Protected 214 ! Remote !<------------------------>! ! Subnet 215 ! Access ! ! Access !<--- and/or 216 ! Client !<------------------------>! Gateway ! Internet 217 ! ! IPsec tunnel ! ! 218 +-+-+-+-+-+ +-+-+-+-+-+ 220 (b) 222 +-+-+-+-+-+ +-+-+-+-+-+ 223 ! ! IKE_SESSION_RESUME ! ! 224 ! Remote !<------------------------>! ! 225 ! Access ! ! Access ! 226 ! Client !<------------------------>! Gateway ! 227 ! ! IPsec tunnel ! ! 228 +-+-+-+-+-+ +-+-+-+-+-+ 230 Figure 1: Resuming a Session with a Remote Access Gateway 232 In the first use case above, an end host (an entity with a host 233 implementation of IPsec [RFC4301]) establishes a tunnel mode IPsec SA 234 with a gateway in a remote network using IKEv2. The end host in this 235 scenario is sometimes referred to as a remote access client. At a 236 later stage when a client needs to re-establish the IKEv2 session it 237 may choose to establish IPsec SAs using a full IKEv2 exchange or the 238 IKE_SESSION_RESUME exchange (shown in Figure 1). 240 4. Protocol Details 242 This section provides protocol details and contains the normative 243 parts. This document defines two protocol exchanges, namely 244 requesting a ticket, see Section 4.1, and presenting a ticket, see 245 Section 4.3. 247 4.1. Requesting a Ticket 249 A client MAY request a ticket in the following exchanges: 251 o In an IKE_AUTH exchange, as shown in the example message exchange 252 in Figure 2 below. 254 o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed (and only 255 when this exchange is initiated by the client). 256 o In an Informational exchange at any time, e.g. if the gateway 257 previously replied with an N(TICKET_ACK) instead of providing a 258 ticket, or when the ticket lifetime is about to expire. All such 259 Informational exchanges MUST be initiated by the client. 260 o While resuming an IKE session, i.e. in the IKE_AUTH exchange that 261 follows an IKE_SESSION_RESUME exchange, see Section 4.5. 263 Normally, a client requests a ticket in the third message of an IKEv2 264 exchange (the first of IKE_AUTH). Figure 2 shows the message 265 exchange for this typical case. 267 Initiator Responder 268 ----------- ----------- 269 HDR, SAi1, KEi, Ni --> 271 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 273 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] 274 AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} --> 276 Figure 2: Example Message Exchange for Requesting a Ticket 278 The notification payloads are described in Section 4.7. The above is 279 an example, and IKEv2 allows a number of variants on these messages. 280 Refer to [RFC4306] and [I-D.ietf-ipsecme-ikev2bis] for more details 281 on IKEv2. 283 When an IKEv2 responder receives a request for a ticket using the 284 N(TICKET_REQUEST) payload it MUST perform one of the following 285 operations if it supports the extension defined in this document: 286 o it creates a ticket and returns it with the N(TICKET_LT_OPAQUE) 287 payload in a subsequent message towards the IKEv2 initiator. This 288 is shown in Figure 3. 289 o it returns an N(TICKET_NACK) payload, if it refuses to grant a 290 ticket for some reason. 291 o it returns an N(TICKET_ACK), if it cannot grant a ticket 292 immediately, e.g., due to packet size limitations. In this case 293 the client MAY request a ticket later using an Informational 294 exchange, at any time during the lifetime of the IKE SA. 295 Regardless of this choice, there is no change to the behavior of the 296 responder with respect to the IKE exchange, and the proper IKE 297 response (e.g. an IKE_AUTH response or an error notification) MUST be 298 sent. 300 4.2. Receiving a Ticket 302 The IKEv2 initiator receives the ticket and may accept it, provided 303 the IKEv2 exchange was successful. The ticket may be used later with 304 an IKEv2 responder that supports this extension. Figure 3 shows how 305 the initiator receives the ticket. 307 Initiator Responder 308 ----------- ----------- 309 <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, 310 TSr, N(TICKET_LT_OPAQUE) } 312 Figure 3: Receiving a Ticket 314 When a multi-round-trip IKE_AUTH exchange is used, the 315 N(TICKET_REQUEST) payload MUST be included in the first IKE_AUTH 316 request, and N(TICKET_LT_OPAQUE) (or TICKET_NACK/TICKET_ACK) MUST 317 only be returned in the final IKE_AUTH response. 319 4.3. Presenting a Ticket 321 A client MAY initiate a regular (non-ticket-based) IKEv2 exchange 322 even if it is in possession of a valid ticket. Note that the client 323 can only judge validity in the sense of the ticket lifetime. A 324 client MUST NOT present a ticket when it knows that the ticket's 325 lifetime has expired. 327 It is up to the client's local policy to decide when the 328 communication with the IKEv2 responder is seen as interrupted and the 329 session resumption procedure is to be initiated. 331 Tickets are intended for one-time use, i.e. a client MUST NOT reuse a 332 ticket. A reused ticket SHOULD be rejected by a gateway. Note that 333 a ticket is considered as used only when an IKE SA has been 334 established successfully with it. 336 This document specifies a new IKEv2 exchange type called 337 IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is 338 equivalent to the IKE_SA_INIT exchange, and MUST be followed by an 339 IKE_AUTH exchange. The client SHOULD NOT use this exchange type 340 unless it knows that the gateway supports it. 342 Initiator Responder 343 ----------- ----------- 344 HDR, Ni, N(TICKET_OPAQUE) [,N+] --> 346 The exchange type in HDR is set to 'IKE_SESSION_RESUME'. The 347 initiator sets the SPIi value in the HDR to a new random value and 348 the SPIr value is set to 0. 350 When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE) 351 payload it MUST perform one of the following steps if it supports the 352 extension defined in this document: 354 o If it is willing to accept the ticket, it responds as shown in 355 Figure 4. 356 o It responds with an unprotected N(TICKET_NACK) notification, if it 357 rejects the ticket for any reason. In that case, the initiator 358 should re-initiate a regular IKE exchange. One such case is when 359 the responder receives a ticket for an IKE SA that has previously 360 been terminated on the responder itself, which may indicate 361 inconsistent state between the IKEv2 initiator and the responder. 362 However, a responder is not required to maintain the state for 363 terminated sessions. 365 Initiator Responder 366 ----------- ----------- 367 <-- HDR, Nr [,N+] 369 Figure 4: IKEv2 Responder accepts the ticket 371 Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'. The 372 responder copies the SPIi value from the request, and the SPIr value 373 is set to a new random value . 375 At this point the client MUST initiate an IKE_AUTH exchange, as per 376 [RFC4306]. See Section 4.8 for guidelines on computing the AUTH 377 payloads. The IDi value sent in this exchange MUST be identical to 378 the value included in the ticket. Following this exchange, a new IKE 379 SA is created by both parties, see Section 5, and a child SA is 380 derived, per Section 2.17 of [RFC4306]. 382 When the responder receives a ticket for an IKE SA that is still 383 active and if the responder accepts it, then the old SA SHOULD be 384 silently deleted without sending a DELETE informational exchange. 385 Consequently, all the dependent IPsec child SAs are also deleted. 386 This happens after both peers have been authenticated. 388 4.4. IKE_SESSION_RESUME Details 390 Where not specified otherwise, the IKE_SESSION_RESUME exchange 391 behaves exactly like the IKE_SA_INIT exchange. Specifically: 393 o The first message may be rejected in denial of service situations, 394 with the initiator instructed to send a cookie. 395 o Notifications normally associated with IKE_SA_INIT can be sent. 396 In particular, NAT detection payloads. 397 o The SPI values and Message ID fields behave similarly to 398 IKE_SA_INIT. 399 o NAT may be detected during the IKE_SESSION_RESUME exchange, in 400 which case the initiator switches to UDP encapsulation to port 401 4500, as per [RFC4306], Sec. 2.23. 403 4.5. Requesting a Ticket During Resumption 405 When resuming a session, a client will typically request a new ticket 406 immediately, so it is able to resume the session again in the case of 407 a second failure. The N(TICKET_REQUEST) and N(TICKET_LT_OPAQUE) 408 notifications will be included in the IKE_AUTH exchange that follows 409 the IKE_SESSION_RESUME exchange, with similar behavior to a ticket 410 request during a regular IKE exchange, Section 4.1. 412 The returned ticket (if any) will correspond to the IKE SA created 413 per the rules described in Section 5. 415 4.6. IP Address Change and NAT 417 The client MAY resume the IKE exchange from an IP address different 418 from its original address. The gateway MAY reject the resumed 419 exchange if its policy depends on the client's address (although this 420 rarely makes sense). 422 The client's NAT traversal status SHOULD be determined anew upon 423 session resumption, by using the appropriate notifications. This 424 status is explicitly not part of the session resumption state. 426 See also Section 4.4 for related details. 428 4.7. IKE Notifications 430 This document defines a number of notifications. The notification 431 numbers are TBA by IANA. 433 +-------------------+--------+-------------------+ 434 | Notification Name | Number | Data | 435 +-------------------+--------+-------------------+ 436 | TICKET_LT_OPAQUE | TBA1 | See Section 4.7.1 | 437 | TICKET_REQUEST | TBA2 | None | 438 | TICKET_ACK | TBA3 | None | 439 | TICKET_NACK | TBA4 | None | 440 | TICKET_OPAQUE | TBA5 | See Section 4.7.2 | 441 +-------------------+--------+-------------------+ 443 For all these notifications, the Protocol ID and the SPI Size fields 444 MUST both be sent as 0. 446 4.7.1. TICKET_LT_OPAQUE Notify Payload 448 The data for the TICKET_LT_OPAQUE Notify payload consists of the 449 Notify message header, a Lifetime field and the ticket itself. The 450 four octet Lifetime field contains a relative time value, the number 451 of seconds until the ticket expires (encoded as an unsigned integer). 453 0 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 ! Next Payload !C! Reserved ! Payload Length ! 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 ! Protocol ID ! SPI Size = 0 ! Notify Message Type ! 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 ! Lifetime ! 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 ! ! 463 ~ Ticket ~ 464 ! ! 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Figure 5: TICKET_LT_OPAQUE Notify Payload 469 4.7.2. TICKET_OPAQUE Notify Payload 471 The data for the TICKET_OPAQUE Notify payload consists of the Notify 472 message header, and the ticket itself. Unlike the TICKET_LT_OPAQUE 473 payload no lifetime value is included in the TICKET_OPAQUE Notify 474 payload. 476 0 1 2 3 477 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 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 ! Next Payload !C! Reserved ! Payload Length ! 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 ! Protocol ID ! SPI Size = 0 ! Notify Message Type ! 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 ! ! 484 ~ Ticket ~ 485 ! ! 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Figure 6: TICKET_OPAQUE Notify Payload 490 4.8. Computing the AUTH Payload 492 The value of the AUTH payload is derived in a manner similar to the 493 usage of IKEv2 pre-shared secret authentication, as shown below: 495 AUTH = prf(SK_px, ) 497 Each of the initiator and responder uses its own SK_p value, taken 498 from the newly generated IKE SA, Section 5. 500 The exact material to be signed is defined in Section 2.15 of 501 [RFC4306]. The notation "IDr'" in RFC 4306 should be applied to the 502 new IDr value included in the exchange, rather than the value in the 503 ticket. 505 5. Processing Guidelines for IKE SA Establishment 507 When a ticket is presented, the gateway needs to obtain the ticket 508 state. In case a ticket by reference was provided by the client, the 509 gateway needs to resolve the reference in order to obtain this state. 510 In case the client has already provided a ticket per value, the 511 gateway can parse the ticket to obtain the state directly. In either 512 case, the gateway needs to process the ticket state in order to 513 restore the state of the old IKE SA, and the client retrieves the 514 same state from its local store. Both peers now create state for the 515 new IKE SA as follows: 517 o The SA value (transforms etc.) is taken directly from the ticket. 519 o The Message ID values are reset to 0 in IKE_SESSION_RESUME, and 520 subsequently incremented normally. 521 o The IDi value is obtained from the ticket. 522 o The IDr value is obtained from the new exchange. The gateway MAY 523 make policy decisions based on the IDr value encoded in the 524 ticket. 525 o The SPI values are created anew during IKE_SESSION_RESUME, 526 similarly to a regular IKE_SA_INIT exchange. SPI values from the 527 ticket MUST NOT be reused, and they are sent merely to help the 528 gateway to locate the old state. The restriction on SPI reuse is 529 to avoid problems caused by collisions with other SPI values used 530 already by the initiator/responder. 532 The cryptographic material is refreshed based on the ticket and the 533 nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED 534 value is derived as follows: 536 SKEYSEED = prf(SK_d_old, "Resumption" | Ni | Nr) 538 where SK_d_old is taken from the ticket. The literal string is 539 encoded as 10 ASCII characters, with no NULL terminator. 541 The keys are derived as follows, unchanged from IKEv2: 543 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = 544 prf+(SKEYSEED, Ni | Nr | SPIi | SPIr) 546 where SPIi, SPIr are the SPI values created in the new IKE exchange. 548 See [RFC4306] for the notation. "prf" is determined from the SA value 549 in the ticket. 551 6. The State After Resumption 553 The following table, compiled by Pasi Eronen, describes the IKE and 554 IPsec state of the peers after session resumption, and how it is 555 related to their state before the IKE SA was interrupted. When the 556 table mentions that a certain state item is taken "from the ticket", 557 this should be construed as: 558 o The client retrieves this item from its local store. 559 o In the case of ticket by value, the gateway encodes this 560 information in the ticket. 562 o In the case of ticket by reference, the gateway fetches this 563 information from the ticket store. 565 +--------------------------------------+----------------------------+ 566 | State Item | After Resumption | 567 +--------------------------------------+----------------------------+ 568 | IDi | From the ticket (but must | 569 | | also be exchanged in | 570 | | IKE_AUTH) | 571 | IDr | From the new exchange (but | 572 | | old value included in the | 573 | | ticket) | 574 | Authentication method (PKI, | From the ticket | 575 | pre-shared secret, EAP, PKI-less EAP | | 576 | [I-D.eronen-ipsec-ikev2-eap-auth] | | 577 | etc.) | | 578 | Certificates (when applicable) | Unspecified, see note 1 | 579 | Local IP address/port, peer IP | Selected by the client, | 580 | address/port | see note 2 | 581 | NAT detection status | From new exchange | 582 | SPIs | From new exchange | 583 | Which peer is the "original | Determined by the | 584 | initiator"? | initiator of | 585 | | IKE_SESSION_RESUME | 586 | IKE SA sequence numbers (Message ID) | Start from 0 | 587 | IKE SA algorithms (SAr) | From the ticket | 588 | IKE SA keys (SK_*) | SK_d from the ticket, | 589 | | others are refreshed | 590 | IKE SA window size | Reset to 1 | 591 | Child SAs (ESP/AH) | Created in new exchange, | 592 | | see note 5 | 593 | Internal IP address | Not resumed, but see note | 594 | | 3 | 595 | Other Configuration Payload | Not resumed | 596 | information | | 597 | Peer vendor IDs | Unspecified (needed in the | 598 | | ticket only if | 599 | | vendor-specific state is | 600 | | required) | 601 | Peer supports MOBIKE [RFC4555] | From new exchange | 602 | MOBIKE additional addresses | Not resumed, should be | 603 | | resent by client if | 604 | | necessary | 605 | Time until re-authentication | From new exchange (but | 606 | [RFC4478] | ticket lifetime is bounded | 607 | | by this duration) | 608 | Peer supports redirects | From new exchange | 609 | [I-D.ietf-ipsecme-ikev2-redirect] | | 610 +--------------------------------------+----------------------------+ 612 Note 1: Certificates don't need to be stored if the peer never uses 613 them for anything after the IKE SA is up (but would be 614 needed if exposed to applications via IPsec APIs). 615 Note 2: If the certificate has an iPAddress SubjectAltName, and the 616 implementation requires it to match the peer's source IP 617 address, the same check needs to be performed on session 618 resumption and the required information saved locally or in 619 the ticket. 620 Note 3: The client can request the address it was using earlier, and 621 if possible, the gateway SHOULD honor the request. 622 Note 4: IKEv2 features that affect only the IKE_AUTH exchange 623 (including HTTP_CERT_LOOKUP_SUPPORTED, multiple 624 authentication exchanges [RFC4739], ECDSA authentication 625 [RFC4754], and OCSP [RFC4806]) don't usually need any state 626 in the IKE SA (after the IKE_AUTH exchanges are done), so 627 resumption doesn't affect them. 628 Note 5: Since information about CHILD SAs and configuration payloads 629 is not resumed, IKEv2 features related to CHILD SA 630 negotiation (such as IPCOMP_SUPPORTED, 631 ESP_TFC_PADDING_NOT_SUPPORTED, ROHC-over-IPsec 632 [I-D.ietf-rohc-ikev2-extensions-hcoipsec] and configuration 633 aren't usually affected by session resumption. 634 Note 6: New IKEv2 features that are not covered by notes 4 and 5 635 should specify how they interact with session resumption. 637 7. Ticket Handling 639 7.1. Ticket Content 641 When passing a ticket by value to the client, the ticket content MUST 642 be integrity protected and encrypted. 644 A ticket by reference does not need to be encrypted, as it does not 645 contain any sensitive material, such as keying material. However, 646 access to the storage where that sensitive material is stored MUST be 647 protected so that only unauthorized access is not allowed. We note 648 that such a ticket is analogous to the concept of 'stub', as defined 649 in [I-D.xu-ike-sa-sync], or the concept of a Session ID from TLS. 651 Although not strictly required for cryptographic protection, it is 652 RECOMMENDED to integrity-protect the ticket by reference. Failing to 653 do so could result in various security vulnerabilities on the gateway 654 side, depending on the format of the reference. Potential 655 vulnerabilities include access by the gateway to unintended URLs 656 (similar to cross-site scripting) or SQL injection. 658 When the state is passed by value, the ticket MUST encode at least 659 the following state from an IKE SA. The same state MUST be stored in 660 the ticket store, in the case of ticket by reference. 662 o IDi, IDr. 663 o SPIi, SPIr. 664 o SAr (the accepted proposal). 665 o The authentication method used. 666 o SK_d. 668 The ticket by value MUST include a key identity field, so that keys 669 for encryption and authentication can be changed, and when necessary, 670 algorithms can be replaced. 672 7.2. Ticket Identity and Lifecycle 674 Each ticket is associated with a single IKE SA. In particular, when 675 an IKE SA is deleted, the client MUST delete its stored ticket. 676 Similarly, when credentials associated with the IKE SA are 677 invalidated (e.g. when a user logs out), the ticket MUST be deleted. 678 When the IKE SA is rekeyed the ticket is invalidated, and the client 679 SHOULD request a new ticket. 681 The lifetime of the ticket sent by the gateway SHOULD be the minimum 682 of the IKE SA lifetime (per the gateway's local policy) and its re- 683 authentication time, according to [RFC4478]. Even if neither of 684 these are enforced by the gateway, a finite lifetime MUST be 685 specified for the ticket. 687 The key that is used to protect the ticket MUST have a lifetime that 688 is significantly longer than the lifetime of an IKE SA. 690 In normal operation, the client will request a ticket when 691 establishing the initial IKE SA, and then every time the SA is 692 rekeyed or re-established because of re-authentication. 694 8. IANA Considerations 696 This document requires a number of IKEv2 notification status types in 697 Section 4.7, to be registered by IANA. The "IKEv2 Notify Message 698 Types - Status Types" registry was established by IANA. 700 The document defines a new IKEv2 exchange in Section 4.3. The 701 corresponding registry was established by IANA. 703 9. Security Considerations 705 This section addresses security issues related to the usage of a 706 ticket. 708 9.1. Stolen Tickets 710 An man-in-the-middle may try to eavesdrop on an exchange to obtain a 711 ticket by value and use it to establish a session with the IKEv2 712 responder. This can happen in different ways: by eavesdropping on 713 the initial communication and copying the ticket when it is granted 714 and before it is used, or by listening in on a client's use of the 715 ticket to resume a session. However, since the ticket's contents is 716 encrypted and the attacker does not know the corresponding secret 717 key, a stolen ticket cannot be used by an attacker to successfully 718 resume a session. An IKEv2 responder MUST use strong encryption and 719 integrity protection of the ticket to prevent an attacker from 720 obtaining the ticket's contents, e.g., by using a brute force attack. 722 A ticket by reference does not need to be encrypted. When an 723 adversary is able to eavesdrop on an exchange, as described in the 724 previous paragraph, then the ticket by reference may be obtained. A 725 ticket by reference cannot be used by an attacker to successfully 726 resume a session, for the same reasons as for a ticket by value. 727 Moreover, the adversary MUST NOT be able to resolve the ticket via 728 the reference, i.e., access control MUST be enforced to ensure 729 disclosure only to authorized entities. 731 9.2. Forged Tickets 733 A malicious user could forge or alter a ticket by value in order to 734 resume a session, to extend its lifetime, to impersonate as another 735 user, or to gain additional privileges. This attack is not possible 736 if the content of the ticket by value is protected using a strong 737 integrity protection algorithm. 739 In case of a ticket by reference an adversary may attempt to 740 construct a fake ticket by reference to point to state information 741 stored by the IKEv2 responder. This attack will fail because the 742 adversary is not in possession of the keying material associated with 743 the IKEv2 SA. As noted in Section 7.1, it is often useful to 744 integrity-protect the ticket by reference, too. 746 9.3. Denial of Service Attacks 748 An adversary could generate and send a large number of tickets by 749 value to a gateway for verification. To minimize the possibility of 750 such denial of service, ticket verification should be lightweight 751 (e.g., using efficient symmetric key cryptographic algorithms). 753 When an adversary chooses to send a large number of tickets by 754 reference then this may lead to an amplification attack as the IKEv2 755 responder is forced to resolve the reference to a ticket in order to 756 determine that the adversary is not in possession of the keying 757 material corresponding to the stored state or that the reference is 758 void. To minimize this attack, the protocol to resolve the reference 759 should be as lightweight as possible. and should not generate a large 760 number of messages. 762 9.4. Key Management for Tickets By Value 764 A full description of the management of the keys used to protect the 765 ticket by value is beyond the scope of this document. A list of 766 RECOMMENDED practices is given below. 767 o The keys should be generated securely following the randomness 768 recommendations in [RFC4086]. 769 o The keys and cryptographic protection algorithms should be at 770 least 128 bits in strength. 771 o The keys should not be used for any other purpose than generating 772 and verifying tickets. 773 o The keys should be changed regularly. 774 o The keys should be changed if the ticket format or cryptographic 775 protection algorithms change. 777 9.5. Ticket Lifetime 779 An IKEv2 responder controls the validity period of the state 780 information by attaching a lifetime to a ticket. The chosen lifetime 781 is based on the operational and security requirements of the 782 environment in which this IKEv2 extension is deployed. The responder 783 provides information about the ticket lifetime to the IKEv2 784 initiator, allowing it to manage its tickets. 786 9.6. Ticket by Value Format 788 Great care must be taken when defining a ticket format such that the 789 requirements outlined in Section 7.1 are met. In particular, if 790 confidential information, such as a secret key, is transferred to the 791 client it MUST be done using channel security to prevent attackers 792 from obtaining or modifying the ticket. Also, the ticket by value 793 MUST have its integrity and confidentiality protected with strong 794 cryptographic techniques to prevent a breach in the security of the 795 system. 797 9.7. Identity Privacy, Anonymity, and Unlinkability 799 Since opaque state information is passed around between the IKEv2 800 initiator and the IKEv2 responder it is important that leakage of 801 information, such as the identities of an IKEv2 initiator and a 802 responder, MUST be avoided. 804 When an IKEv2 initiator presents a ticket as part of the 805 IKE_SESSION_RESUME exchange, confidentiality is not provided for the 806 exchange. There is thereby the possibility for an on-path adversary 807 to observe multiple exchange handshakes where the same state 808 information is used and therefore to conclude that they belong to the 809 same communication end points. 811 This document therefore requires that the ticket be presented to the 812 IKEv2 responder only once; under normal circumstances (e.g. no active 813 attacker), there should be no multiple use of the same ticket. 815 10. Acknowledgements 817 We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler, 818 Stephen Kent, Sean Shen, Xiaoming Fu, Stjepan Gros, Dan Harkins, Russ 819 Housely, Yoav Nir and Tero Kivinen for their comments. We would like 820 to particularly thank Florian Tegeler and Stjepan Gros for their help 821 with their implementation efforts and Florian Tegeler for his formal 822 verification using the CASPER tool set. 824 We would furthermore like to thank the authors of 825 [I-D.xu-ike-sa-sync](Yan Xu, Peny Yang, Yuanchen Ma, Hui Deng and Ke 826 Xu) for their input on the stub concept. 828 We would like to thank Hui Deng, Tero Kivinen, Peny Yang, Ahmad 829 Muhanna and Stephen Kent for their feedback regarding the ticket by 830 reference concept. 832 11. References 834 11.1. Normative References 836 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 837 Requirement Levels", BCP 14, RFC 2119, March 1997. 839 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 840 RFC 4306, December 2005. 842 11.2. Informative References 844 [I-D.eronen-ipsec-ikev2-eap-auth] 845 Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension 846 for EAP-Only Authentication in IKEv2", 847 draft-eronen-ipsec-ikev2-eap-auth-06 (work in progress), 848 April 2009. 850 [I-D.ietf-ipsecme-ikev2-redirect] 851 Devarapalli, V. and K. Weniger, "Redirect Mechanism for 852 IKEv2", draft-ietf-ipsecme-ikev2-redirect-09 (work in 853 progress), May 2009. 855 [I-D.ietf-ipsecme-ikev2bis] 856 Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 857 "Internet Key Exchange Protocol: IKEv2", 858 draft-ietf-ipsecme-ikev2bis-03 (work in progress), 859 April 2009. 861 [I-D.ietf-rohc-ikev2-extensions-hcoipsec] 862 Ertekin, E., Christou, C., Jassani, R., Kivinen, T., and 863 C. Bormann, "IKEv2 Extensions to Support Robust Header 864 Compression over IPsec (ROHCoIPsec)", 865 draft-ietf-rohc-ikev2-extensions-hcoipsec-08 (work in 866 progress), February 2009. 868 [I-D.rescorla-stateless-tokens] 869 Rescorla, E., "How to Implement Secure (Mostly) Stateless 870 Tokens", draft-rescorla-stateless-tokens-01 (work in 871 progress), March 2007. 873 [I-D.xu-ike-sa-sync] 874 Xu, Y., Yang, P., Ma, Y., Deng, H., and H. Deng, "IKEv2 SA 875 Synchronization for session resumption", 876 draft-xu-ike-sa-sync-01 (work in progress), October 2008. 878 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 879 Requirements for Security", BCP 106, RFC 4086, June 2005. 881 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 882 Internet Protocol", RFC 4301, December 2005. 884 [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange 885 (IKEv2) Protocol", RFC 4478, April 2006. 887 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 888 (MOBIKE)", RFC 4555, June 2006. 890 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 891 Implementation Guidelines", RFC 4718, October 2006. 893 [RFC4739] Eronen, P. and J. Korhonen, "Multiple Authentication 894 Exchanges in the Internet Key Exchange (IKEv2) Protocol", 895 RFC 4739, November 2006. 897 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 898 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 899 RFC 4754, January 2007. 901 [RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status 902 Protocol (OCSP) Extensions to IKEv2", RFC 4806, 903 February 2007. 905 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 906 "Transport Layer Security (TLS) Session Resumption without 907 Server-Side State", RFC 5077, January 2008. 909 Appendix A. Ticket Format 911 This document does not specify a mandatory-to-implement or a 912 mandatory-to-use ticket format. The formats described in the 913 following sub-sections are provided as useful examples. 915 A.1. Example Ticket by Value Format 916 struct { 917 [authenticated] struct { 918 octet format_version; // 1 for this version of the protocol 919 octet reserved[3]; // sent as 0, ignored by receiver. 920 octet key_id[8]; // arbitrary byte string 921 opaque IV[0..255]; // actual length (possibly 0) depends 922 // on the encryption algorithm 924 [encrypted] struct { 925 opaque IDi, IDr; // the full payloads 926 octet SPIi[8], SPIr[8]; 927 opaque SA; // the full SAr payload 928 octet SK_d[0..255]; // actual length depends on SA value 929 enum ... authentication_method; 930 int32 expiration; // an absolute time value, seconds 931 // since Jan. 1, 1970 932 } ikev2_state; 933 } protected_part; 934 opaque MAC[0..255]; // the length (possibly 0) depends 935 // on the integrity algorithm 936 } ticket; 938 Note that the key defined by "key_id" determines the encryption and 939 authentication algorithms used for this ticket. Those algorithms are 940 unrelated to the transforms defined by the SA payload. 942 The reader is referred to [I-D.rescorla-stateless-tokens] that 943 recommends a similar (but not identical) ticket format, and discusses 944 related security considerations in depth. 946 A.2. Example Ticket by Reference Format 948 For implementations that prefer to pass a reference to IKE state in 949 the ticket, rather than the state itself, we suggest the following 950 format: 952 struct { 953 [authenticated] struct { 954 octet format_version; // 1 for this version of the protocol 955 octet reserved[3]; // sent as 0, ignored by receiver. 956 octet key_id[8]; // arbitrary byte string 958 struct { 959 opaque state_ref; // reference to IKE state 960 int32 expiration; // an absolute time value, seconds 961 // since Jan. 1, 1970 962 } ikev2_state_ref; 963 } protected_part; 964 opaque MAC[0..255]; // the length depends 965 // on the integrity algorithm 966 } ticket; 968 Appendix B. Change Log 970 B.1. -04 972 Closed issue #105, Non-PKI use of EAP, and resumption. 974 Closed issue #106, Resumption and NAT detection and changing ports. 976 B.2. -03 978 Changed the protocol from one to two round trips, to simplify the 979 security assumptions. Eliminated security considerations associated 980 with the previous version. 982 Closed issue #69, Clarify behavior of SPI and sequence numbers. 984 Closed issue #70, Ticket lifetime - explicit or not? (and ticket push 985 from gateway). 987 Closed issue #99, Ticket example: downgrade. 989 Closed issue #76, IPsec child SAs during resumption. 991 Closed issue #77, Identities in draft-ietf-ipsecme-ikev2-resumption. 993 Closed issue #95, Minor nits for ikev2-resumption-02. 995 Closed issue #97, Clarify what state comes from where. 997 Closed issue #98, Replays in 1-RTT protocol. 999 Closed issue #100, NAT detection [and] IP address change. 1001 Closed issue #101, Assorted issues by Tero. 1003 B.3. -02 1005 Added a new TICKET_OPAQUE payload that does not have a lifetime field 1006 included. 1008 Removed the lifetime usage from the IKE_SESSION_RESUME exchange 1009 (utilizing the TICKET_OPAQUE) when presenting the ticket to the 1010 gateway. 1012 Removed IDi payloads from the IKE_SESSION_RESUME exchange. 1014 Clarified that IPsec child SAs would be deleted once the old IKE SA 1015 gets deleted as well. 1017 Clarified the behavior of SPI and sequence number usage. 1019 B.4. -01 1021 Addressed issue#75, see 1022 http://tools.ietf.org/wg/ipsecme/trac/ticket/75. This included 1023 changes throughout the document to ensure that the ticket may contain 1024 a reference or a value. 1026 B.5. -00 1028 Resubmitted document as a WG item. 1030 B.6. -01 1032 Added reference to [I-D.xu-ike-sa-sync] 1034 Included recommended ticket format into the appendix 1036 Various editorial improvements within the document 1038 B.7. -00 1040 Issued a -00 version for the IPSECME working group. Reflected 1041 discussions at IETF#72 regarding the strict focus on session 1042 resumption. Consequently, text about failover was removed. 1044 B.8. -04 1046 Editorial fixes; references cleaned up; updated author's contact 1047 address 1049 B.9. -03 1051 Removed counter mechanism. Added an optional anti-DoS mechanism, 1052 based on IKEv2 cookies (removed previous discussion of cookies). 1053 Clarified that gateways may support reallocation of same IP address, 1054 if provided by network. Proposed a solution outline to the problem 1055 of key exchange for the keys that protect tickets. Added fields to 1056 the ticket to enable interoperability. Removed incorrect MOBIKE 1057 notification. 1059 B.10. -02 1061 Clarifications on generation of SPI values, on the ticket's lifetime 1062 and on the integrity protection of the anti-replay counter. 1063 Eliminated redundant SPIs from the notification payloads. 1065 B.11. -01 1067 Editorial review. Removed 24-hour limitation on ticket lifetime, 1068 lifetime is up to local policy. 1070 B.12. -00 1072 Initial version. This draft is a selective merge of 1073 draft-sheffer-ike-session-resumption-00 and 1074 draft-dondeti-ipsec-failover-sol-00. 1076 Authors' Addresses 1078 Yaron Sheffer 1079 Check Point Software Technologies Ltd. 1080 5 Hasolelim St. 1081 Tel Aviv 67897 1082 Israel 1084 Email: yaronf@checkpoint.com 1085 Hannes Tschofenig 1086 Nokia Siemens Networks 1087 Linnoitustie 6 1088 Espoo 02600 1089 Finland 1091 Phone: +358 (50) 4871445 1092 Email: Hannes.Tschofenig@gmx.net 1093 URI: http://www.tschofenig.priv.at 1095 Lakshminath Dondeti 1096 QUALCOMM, Inc. 1097 5775 Morehouse Dr 1098 San Diego, CA 1099 USA 1101 Phone: +1 858-845-1267 1102 Email: ldondeti@qualcomm.com 1104 Vidya Narayanan 1105 QUALCOMM, Inc. 1106 5775 Morehouse Dr 1107 San Diego, CA 1108 USA 1110 Phone: +1 858-845-2483 1111 Email: vidyan@qualcomm.com