idnits 2.17.1 draft-cakulev-ibake-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (November 14, 2011) is 4509 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-cakulev-emu-eap-ibake-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Cakulev 3 Internet-Draft G. Sundaram 4 Intended status: Informational I. Broustis 5 Expires: May 17, 2012 Alcatel Lucent 6 November 14, 2011 8 IBAKE: Identity-Based Authenticated Key Exchange 9 draft-cakulev-ibake-06.txt 11 Abstract 13 Cryptographic protocols based on public key methods are based on 14 certificates and public key infrastructure (PKI) to support 15 certificate management. The emerging field of Identity Based 16 Encryption protocols allows to simplify the infrastructure 17 requirements via a Private-key Generator (PKG) while providing the 18 same flexibility. However one significant limitation of Identity 19 Based Encryption methods is that the PKG can end up being a de-facto 20 key escrow server with undesirable consequences. Another observed 21 deficiency is a lack of mutual authentication of communicating 22 parties. Here, Identity Based Authenticated Key Exchange (IBAKE) 23 Protocol is specified which does not suffer from the key escrow 24 problem and in addition provides mutual authentication and a perfect 25 forward and backwards secrecy. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 17, 2012. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 65 2.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Identity Based Authenticated Key Exchange . . . . . . . . . . 6 67 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.2. IBAKE Message Exchange . . . . . . . . . . . . . . . . . . 7 69 3.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.2. IBAKE Protocol . . . . . . . . . . . . . . . . . . . . . . 12 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 6.1. Normative References . . . . . . . . . . . . . . . . . . . 15 76 6.2. Informative References . . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 Authenticated Key Agreements are cryptographic protocols where two or 82 more participants, authenticate each other and agree on a key for 83 future communication. These protocols could be symmetric key or 84 asymmetric public key protocols. Symmetric key protocols require an 85 out-of-band security mechanism to bootstrap a secret key. On the 86 other hand, public key protocols require certificates and large scale 87 public key infrastructure. Clearly public key methods are more 88 flexible, however the requirement for certificates and a large scale 89 public key infrastructure have proved to be challenging. In 90 particular, efficient methods to support large scale certificate 91 revocation and management have proved to be elusive. 93 Recently, Identity Based Encryption (IBE) protocols have been 94 proposed as a viable alternative to public key methods by simplifying 95 the PKI requirements and replacing them with a Private-key Generator 96 (PKG) to generate private keys. However, one significant limitation 97 of Identity Based Encryption methods is that the PKG can end up being 98 a de-facto key escrow server with undesirable consequences. Another 99 limitation is a lack of mutual authentication between communicating 100 parties. Here an Identity Based Authenticated Key Agreement Protocol 101 is specified which does not suffer from the key escrow problem and 102 Provides mutual authentication. In addition, the scheme described in 103 this document allows the use of time-bound public identities and 104 corresponding public and private keys, resulting in automatic 105 expiration of private keys at the end of a time span indicated in the 106 identity itself. With the self-expiration of the public identities, 107 the traditional real-time validity verification and revocation is not 108 required. For example, if the public identity is bound to one day, 109 then, at the end of the day, the Public/Private Key pair issued to 110 this peer will simply not be valid anymore. Nevertheless, just like 111 with Public-Key-based certificate systems, if there is a need to 112 revoke keys before the designated expiry time, communication with a 113 third party will be needed. Finally, the protocol also provides 114 forward and backwards secrecy of session keys. 116 2. Requirements notation 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 2.1. Definitions 124 Identity-Based Encryption (IBE): Identity-based encryption (IBE) is a 125 public-key encryption technology that allows a public key to be 126 calculated from an identity and set of public parameters, and the 127 corresponding private key to be calculated from the public key. The 128 public key can then be used by an Initiator to encrypt messages which 129 the recipient can decrypt using the corresponding private key. IBE 130 framework is defined in [RFC5091], [RFC5408] and [RFC5409]. 132 2.2. Abbreviations 134 EC Elliptic Curve 136 IBE Identity Based Encryption 138 IBAKE Identity Based Authenticated Key Exchange 140 IDi Initiator's Identity 142 IDr Responder's Identity 144 K_PR Private Key 146 K_PUB Public Key 148 PKG Private-key Generator 150 PKI Public Key Infrastructure 152 2.3. Conventions 154 o E is an elliptic curve over a finite field F 156 o P is a point on E of large prime order 158 o e: E x E -> G is a bi-linear map on E. G is the group of n-th 159 roots of unity where n is a function of the number of points on E 160 over F. Typical example of a bi-linear map is the Weil pairing 161 [BF]. 163 o s is a non-zero positive integer. s is a secret stored in a 164 Private-key Generator (PKG). This is a system-wide secret and not 165 revealed outside the PKG. 167 o Ppub = sP is the public key of the system that is known to all 168 participants. sP denotes a point in E, and denotes the point P 169 added to itself s times where addition refers to the group 170 operation one E. 172 o H1 is a known hash function that takes a string and assigns it to 173 a point on the elliptic curve, i.e., H1(A) = QA on E, where A is 174 usually based on the identity. 176 o dA = sQA is the private key computed by the PKG, corresponding to 177 the public identity A, and delivered only to A 179 o H2 is a known hash function that takes an element of G and assigns 180 it to a string 182 o E(k, A) denotes that A is IBE-encrypted with the key k 184 o s||t denotes concatenation of the strings s and t 186 o K_PUBx denotes Public Key of x 188 3. Identity Based Authenticated Key Exchange 190 3.1. Overview 192 IBAKE consists of a three-way exchange between an Initiator and a 193 Responder. In the figure below, a conceptual signaling diagram of 194 IBAKE is depicted. 196 +---+ +---+ 197 | I | | R | 198 +---+ +---+ 200 MESSAGE_1 201 ----------------------------------> 202 MESSAGE_2 203 <---------------------------------- 204 MESSAGE_3 205 ----------------------------------> 207 Figure 1: Example IBAKE Message Exchange 209 The Initiator (I) and Responder (R) are attempting to mutually 210 authenticate each other and agree on a key using IBAKE. This 211 specification assumes that the Initiator and the Responder trust a 212 third party, the Private-key Generator (PKG). Rather than a single 213 PKG, several different PKGs may be involved, e.g. one for the 214 Initiator and one for the Responder. The Initiator and the Responder 215 do not share any credentials, however they know or can obtain each 216 other's public parameters. This specification does not make any 217 assumption on when and how the Private Keys are obtained. However, 218 to complete the protocol described (i.e. to decrypt encrypted 219 messages in the IBAKE protocol exchange) the Initiator and the 220 Responder need to have their respective Private Keys. The procedures 221 needed to obtain the private keys and public parameters are outside 222 of scope of this specification. The details of these procedures can 223 be found in [RFC5091] and [RFC5408]. Finally, the protocol described 224 relies on the use of elliptic curves. Section 3.3 discusses the 225 choice of elliptic curves. However, how the Initiator and the 226 Responder agree on a specific elliptic curve is left to application 227 that is leveraging IBAKE protocol (see [I-D.cakulev-emu-eap-ibake] 228 for example). 230 The Initiator chooses random x. In the first step, the Initiator 231 computes xP (i.e., P, as a point on E, added to itself x times using 232 the addition law on E), encrypts xP, IDi and IDr using Responder's 233 public key (e.g., K_PUBr=H1(IDr||date)) and includes this encrypted 234 information in a MESSAGE_1 message sent to the Responder. In this 235 step encryption refers to identity based encryption described in 236 [RFC5091] and [RFC5408]. 238 The Responder, upon receiving the message, IBE-decrypts it using its 239 private key (e.g. private key for that date), and obtains xP. The 240 Responder next chooses random y and computes yP. The Responder then 241 IBE-encrypts Initiator's identity (IDi), its own identity (IDr), xP, 242 and yP using Initiator's Public Key (e.g., K_PUBi=H1(IDi||date)). 243 The Responder includes this encrypted information in MESSAGE_2 244 message sent to the Initiator. 246 The Initiator upon receiving and IBE-decrypting MESSAGE_2 obtains yP. 247 Subsequently, the Initiator sends MESSAGE_3 message to the Responder, 248 including IBE-encrypted IDi, IDr and yP. At this point both the 249 Initiator and the Responder are able to compute the same session key 250 as xyP. 252 3.2. IBAKE Message Exchange 254 Initially, the Initiator selects a random x and computes xP; The 255 Initiator MUST use a fresh, random value for x on each run of the 256 protocol. The Initiator then encrypts xP, IDi and IDr using 257 Responder's public key (e.g., K_PUBr=H1(IDr||date)). The Initiator 258 includes this encrypted information in a MESSAGE_1 and sends it to 259 the Responder as shown below. 261 Initiator ----> Responder 263 MESSAGE_1 = E(K_PUBr, IDi || IDr || xP) 265 Upon receiving MESSAGE_1 message, the Responder SHALL perform the 266 following: 268 o Decrypt the message as specified in [RFC5091] and [RFC5408] 270 o Obtain xP 272 o The Responder selects a random y and computes yP. The Responder 273 MUST use a fresh, random value for x on each run of the protocol. 275 o Encrypt the Initiator's identity (IDi), its own identity (IDr), xP 276 and yP using Initiator's Public Key (K_PUBi). 278 Responder ----> Initiator 280 MESSAGE_2 = E(K_PUBi, IDi || IDr || xP || yP) 282 Upon receiving MESSAGE_2 message, the Initiator SHALL perform the 283 following: 285 o Decrypt the message as specified in [RFC5091] and [RFC5408] 287 o Verify that the received xP is the same as sent in MESSAGE_1 289 o Obtain yP 291 o Encrypt its own identity (IDi), the Responder's identity (IDr) and 292 yP using Responder's Public Key (K_PUBi). 294 Initiator ----> Responder 296 MESSAGE_3 = E(K_PUBr, IDi || IDr || yP) 298 Upon receiving MESSAGE_3 message, the Responder SHALL perform the 299 following: 301 o Decrypt the message as specified in [RFC5091] and [RFC5408]. 303 o Verify that the received yP is the same as sent in MESSAGE_2 305 If any of the above verifications fails, the protocol halts; 306 otherwise, following this exchange both the Initiator and the 307 Responder have authenticated each other and are able to compute xyP 308 as the session key. At this point, both protocol participants MUST 309 discard all intermediate cryptographic values, including x and y. 310 Similarly, both parties MUST immediately discard these values 311 whenever the protocol terminates as a result of a verification 312 failure or timeout. 314 3.3. Discussion 316 Properties of the protocol are as follows: 318 o Immunity from key escrow: Observe that all the steps in the 319 protocol exchange are encrypted using IBE. So clearly the PKG can 320 decrypt all the exchanges. However, given the above made 321 assumption that PKGs are trusted and well behaved (e.g., PKGs will 322 not mount an active Man-in-the-Middle attack), the PKG cannot 323 compute the session key. This is because of the hardness of the 324 elliptic curve Diffie-Hellman problem. In other words, given xP 325 and yP it is computationally hard to compute xyP. 327 o Mutually Authenticated Key Agreement: Observe that all the steps 328 in the protocol exchange are encrypted using IBE. In particular 329 only the Responder and its corresponding PKG can decrypt the 330 contents of the MESSAGE_1 and MESSAGE_3 sent by the Initiator, and 331 similarly only the Initiator and its corresponding PKG can decrypt 332 the contents of the MESSAGE_2 sent by the Responder. Again, given 333 the above made assumption that PKGs are trusted and well behaved 334 (e.g., a PKG will not impersonate a user it issued a Private Key 335 to) upon receiving MESSAGE_2, the Initiator can verify the 336 Responder's authenticity since xP could have been sent in 337 MESSAGE_2 only after decryption of the contents of MESSAGE_1 by 338 the Responder. Similarly, upon receiving MESSAGE_3, the Responder 339 can verify the Initiator's authenticity since yP could have been 340 sent back in MESSAGE_3 only after correctly decrypting the 341 contents of MESSAGE_2 and this is possible only by the Initiator. 342 Finally both the Initiator and the Responder can agree on the same 343 session key. In other words, the protocol is a mutually 344 authenticated key agreement protocol based on IBE. The hardness 345 of the key agreement protocol relies on the hardness of the 346 Elliptic curve Diffie-Hellman problem. So clearly in any 347 practical implementation care should be devoted to the choice of 348 elliptic curve. 350 o Perfect forward and backwards secrecy: Since x and y are random, 351 xyP is always fresh and unrelated to any past or future sessions 352 between the Initiator and the Responder. 354 o No passwords: Clearly the IBAKE protocol does not require any 355 offline exchange of passwords or secret keys between the Initiator 356 and the Responder. In fact the method is applicable to any two 357 parties communicating for the first time through any communication 358 network. The only requirement is to ensure that both the 359 Initiator and the Responder are aware of each other's public keys 360 and public parameters of PKG which generated the corresponding 361 private keys. 363 o PKG availability: Observe that PKGs need not be contacted during 364 IBAKE protocol exchange, which dramatically reduces availability 365 requirements on PKG. 367 o Choice of elliptic curves: This specification relies on the use of 368 elliptic curves for both IBE encryption as well as for Elliptic 369 Curve Diffie-Hellman exchange. When making a decision on the 370 choice of elliptic curves, it is beneficial to choose two 371 different elliptic curves, one for the internal calculations of 372 Elliptic Curve Diffie-Hellman values xP and yP, and another for 373 the IBE encryption/decryption. For the calculations of Elliptic 374 Curve Diffie-Hellman values, it is beneficial to use the NIST 375 recommended curves [FIPS-186]. These curves make the calculations 376 simpler while keeping the security high. On the other hand, 377 identity-based encryption (IBE) systems are based on bilinear 378 pairings. Therefore, the choice of an elliptic curve for IBE is 379 restricted to a family of supersingular elliptic curves over 380 finite fields of large prime characteristic. The appropriate 381 elliptic curves for IBE encryption are described in [RFC5091]. 383 o Implementation considerations: An implementation of IBAKE would 384 consist of two primary modules, i.e., point addition operations 385 over a NIST curve, and IBE operations over a super-singular curve. 386 The implementation of both modules only needs to be aware of the 387 following parameters: (a) the full description of the curves that 388 are in use (fixed or negotiated), (b) the public parameters of the 389 KGF used for the derivation of IBE private keys and (c) the exact 390 public identity of each IBAKE participant. The knowledge of these 391 parameters is sufficient to perform ECC operations in different 392 terminals and produce the same results, independently of the 393 implementation. 395 4. Security Considerations 397 This draft is based on the basic Identity Based Encryption protocol, 398 as specified in [BF], [RFC5091]), [RFC5408] and [RFC5409], and as 399 such inherits some properties of that protocol. For instance, by 400 concatenating the "date" with the identity (to derive the public 401 key), the need for any key revocation mechanisms is virtually 402 eliminated. Moreover, by allowing the participants to acquire 403 multiple private keys (e.g., for duration of contract) the 404 availability requirements on the PKG are also reduced without any 405 reduction in security. The granularity associated with the "date" is 406 a matter of security policy, and as such a decision made by the PKG 407 administrator. However, the granularity applicable to any given 408 participant should be publicly available and known to other 409 participants. For example, this information can be made available in 410 the same venue which provides "public information" of PKG server 411 (i.e., P, sP) needed to execute IB encryption. 413 4.1. General 415 Attacks on the cryptographic algorithms used in Identity Based 416 Encryption are outside the scope of this document. It is assumed 417 that any administrator will pay attention to the desired strengths of 418 the relevant cryptographic algorithms based on an up to date 419 understanding of the strength of these algorithms from published 420 literature as well as known attacks. 422 It is assumed that the PKGs are secure, not compromised, trusted, and 423 will not engage in launching active attacks independently or in a 424 collaborative environment. Nevertheless, if an active adversary can 425 fool the parties that it is a legitimate PKG then it can mount a 426 successful MitM attack. Therefore, care should be taken when 427 choosing a PKG. In addition, any malicious insider could potentially 428 launch passive attacks (by decryption of one or more message 429 exchanges offline). While it is in the best interest of 430 administrators to prevent such issue, it is hard to eliminate this 431 problem. Hence, it is assumed that such problems will persist, and 432 hence the session key agreement protocols are designed to protect 433 participants from passive adversaries. 435 It is also assumed that the communication between participants and 436 their respective PKGs is secure. Therefore, in any implementation of 437 the protocols described in this document, administrators of any PKG 438 have to ensure that communication with participants is secure and not 439 compromised. 441 Finally, concatenating the "date" to the identity ensures that the 442 corresponding private key is applicable only to that date. This 443 serves to limit the damages related to a leakage or compromise of 444 private keys to just that date. This in particular, eliminates the 445 revocation mechanisms that are typical to various certificate based 446 public key protocols. 448 4.2. IBAKE Protocol 450 For the basic IBAKE protocol from a cryptographic perspective 451 following security considerations apply. 453 In every step Identity Based Encryption (IBE) is used, with the 454 recipient's public key. This guarantees that only the intended 455 recipient of the message and its corresponding PKG can decrypt the 456 message [BF]. 458 Next, the use of identities within the encrypted payload is intended 459 to eliminate some basic reflection attacks. For instance, suppose we 460 did not use identities as part of the encrypted payload, in the first 461 step of the IBAKE protocol (i.e., MESSAGE_1 of Figure 1 in 462 Section 3.1). Furthermore, assume an adversary who has access to the 463 conversation between initiator and responder and can actively snoop 464 into packets and drop/modify them before routing them to the 465 destination. For instance, assume that the IP source address and 466 destination address can be modified by the adversary. After the 467 first message is sent by the initiator (to the responder), the 468 adversary can take over and trap the packet. Next the adversary can 469 modify the IP source address to include adversary's IP address, 470 before routing it onto the responder. The responder will assume the 471 request for an IBAKE session came from the adversary, and will 472 execute step 2 of the IBAKE protocol (i.e., MESSAGE_2 of Figure 1 in 473 Section 3.1) but encrypt it using the adversary's public key. The 474 above message can be decrypted by the adversary (and only by the 475 adversary). In particular, since the second message includes the 476 challenge sent by the initiator to the responder, the adversary will 477 now learn the challenge sent by the initiator. Following this, the 478 adversary can carry on a conversation with the initiator "pretending" 479 to be the responder. This attack will be eliminated if identities 480 are used as part of the encrypted payload. In summary, at the end of 481 the exchange both initiator and responder can mutually authenticate 482 each other and agree on a session key. 484 Recall that Identity Based Encryption guarantees that only the 485 recipient of the message can decrypt the message using the private 486 key. The caveat being, the PKG which generated the private key of 487 recipient of message can decrypt the message as well. However, the 488 PKG cannot learn the public key "xyP" given "xP" and "yP" based on 489 the hardness of the Elliptic Curve Diffie-Hellman problem. This 490 property of resistance to passive key escrow from the PKG, is not 491 applicable to the basic IBE protocols proposed in [RFC5091]), 492 [RFC5408] and [RFC5409]. 494 Observe that the protocol works even if the initiator and responder 495 belong to two different PKGs. In particular, the parameters used for 496 encryption to the responder and parameters used for encryption to the 497 initiator can be completely different and independent of each other. 498 Moreover, the Elliptic Curve used to generate the session key "xyP" 499 can be completely different and chosen during the key exchange. If 500 such flexibility is desired, then it would be required to add 501 optional extra data to the protocol to exchange the algebraic 502 primitives used in deriving the session key. 504 In addition to mutual authentication, and resistance to passive 505 escrow, the Diffie-Hellman property of the session key exchange 506 guarantees perfect secrecy of keys. In others, accidental leakage of 507 one session key does not compromise past or future session keys 508 between the same initiator and responder. 510 5. IANA Considerations 512 At this time there are no IANA considerations. 514 6. References 516 6.1. Normative References 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, March 1997. 521 6.2. Informative References 523 [BF] Boneh, D. and M. Franklin, "Identity-Based Encryption from 524 the Weil Pairing", in SIAM J. of Computing, Vol. 32, 525 No. 3, pp. 586-615, 2003. 527 [FIPS-186] 528 National Institute of Standards and Technology, "FIPS Pub 529 186-3: Digital Signature Standard (DSS)", June 2009. 531 [I-D.cakulev-emu-eap-ibake] 532 Cakulev, V. and I. Broustis, "An EAP Authentication Method 533 Based on Identity-Based Authenticated Key Exchange", 534 draft-cakulev-emu-eap-ibake-00 (work in progress), 535 March 2011. 537 [RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography 538 Standard (IBCS) #1: Supersingular Curve Implementations of 539 the BF and BB1 Cryptosystems", RFC 5091, December 2007. 541 [RFC5408] Appenzeller, G., Martin, L., and M. Schertler, "Identity- 542 Based Encryption Architecture and Supporting Data 543 Structures", RFC 5408, January 2009. 545 [RFC5409] Martin, L. and M. Schertler, "Using the Boneh-Franklin and 546 Boneh-Boyen Identity-Based Encryption Algorithms with the 547 Cryptographic Message Syntax (CMS)", RFC 5409, 548 January 2009. 550 Authors' Addresses 552 Violeta Cakulev 553 Alcatel Lucent 554 600 Mountain Ave. 555 3D-517 556 Murray Hill, NJ 07974 557 US 559 Phone: +1 908 582 3207 560 Email: violeta.cakulev@alcatel-lucent.com 562 Ganapathy S. Sundaram 563 Alcatel Lucent 564 600 Mountain Ave. 565 3D-517 566 Murray Hill, NJ 07974 567 US 569 Phone: +1 908 582 3209 570 Email: ganesh.sundaram@alcatel-lucent.com 572 Ioannis Broustis 573 Alcatel Lucent 574 600 Mountain Ave. 575 3D-526 576 Murray Hill, NJ 07974 577 US 579 Phone: +1 908 582 3744 580 Email: ioannis.broustis@alcatel-lucent.com