Internet Engineering Task Force Mohamed Khalil INTERNET-DRAFT Raja Narayanan Emad Qaddoura Date: October, 1999 Haseeb Akhtar Expires: April, 2000 Nortel Networks Key Exchange for Network Architectures (KENA) Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract As deployment of global IP networks become more widespread, there are several challenges that become apparent, one of the more important ones being secure access from a users perspective. Based on the users service requirements, secure access will have to be setup between a multitude of nodes in a distributed fashion. The nature of these security requirements may well be real-time and dynamic in nature and MUST protect the confidentiality of the user. These requirements are clearly manifested in the mobility domain. This draft outlines a general purpose Key Exchange framework for Network Architectures [KENA] with centralised key generation and management tailored for distributed nodes. The draft also describes Khalil, et al. Expires April 2000 [Page 1] Internet-Draft KENA 16 October 1999 a specific implementation of KENA in the IP mobility domain by extending Mobile IP [Perkins96]. 1. Introduction IP network deployment has picked up considerable momentum in recent times. Whether it the third generation cellular packet networks or packet cable based networks, utilization of IP as the choosen layer three transport medium for packets brings a host of problems that need to be solved. Security is one key area that presents several dimensions. A multitude of rich packet based services (mobility being one of them) require that users interface with a variety of nodes providing these services, exploding the need to dynamically setup secure paths. Requirements like LAES (Lawful Authorized Electronic Survellience) translate into a centralised key management requirement as otherwise the problem of obtaining a handle on the security parameters might become insurmountable. A requirement to be able to setup on demand services (mobility being one) brings a real-time flavor to security. KENA is a simple general purpose framework that solves the problem of centralised key management and distribution in a dynamic fashion. KENA protects the confidentiality of the user. Key exchanges, the basic building block of establishing secure paths, for a particular users communication channel is what KENA primarily focusses on. KENA fulfills several authentication requirements as discussed in Dommety99. The most significant ones being the requirement for the mobile node to be able to authenticate the credentials of the foreign domain and the requirement that the mobile nodes credentials be unforgeable. KENA implementations MAY also choose to add value security attributes and policy information to key exchange. Implementations of KENA may occur through extensions to different protocols. Mobile IP [Perkins96] is one such protocol that may be easily extended to solve requirements in the IP mobility domain. Several alternate proposals exist for addressing security issues. Voluntary tunnelling and IKE [Harkins98] being two of them. The problems associated with these two methods are well articulated in McCann99. Additionally, implementing requirements like LAES become extremely difficult if not impossible with both the methods mentioned above. Khalil, et al. Expires April 2000 [Page 2] Internet-Draft KENA 16 October 1999 2. Terminology This document uses the following terminology: SA Security Association is the logical term used to capture the shared secret keys, secruity attributes and policy that needs to be defined in order to apply protection to traffic between any two nodes in a network. SPI (defined below) uniquely identifies a SA within the context of a host. MN Mobile Node [Perkins98] HA Home Agent [Perkins98] FA Foreign Agent [Perkins98] AAA Authentication, Authorization, and Accounting Server SPI Security Parameters Index is a 32 bit number to index a SA in a database. 3. Specification Language The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. 4. Assumptions We assume that a shared secret MUST exist between the user and the users home. In the mobile IP case this would be the MN user and HA. In addition, in the case of a distributed network as in mobile IP wherein the home network and serving network are different, we assume that a secure path MUST exist between the foreign domain and home domain. KENA distributes keys between the nodes in the serving and home network for securing/encrypting the traffic of a user. An assummption is made that the nodes within a network MUST be able to communicate with each other securely such that keys MAY be Khalil, et al. Expires April 2000 [Page 3] Internet-Draft KENA 16 October 1999 distributed to them in the first place. 5. Requirements 5.1. Generic KENA Requirements 1- User confidentiality and authentication 2- Centralised key generation and distribution for user's communication channel 3- Real-time sensitive 4- Implementable using extensions to existing protocols 5.2. Mobility Requirements One of the important goals for any mobile system is to minimize data loss and speed the process of handoff while maintaining a secure environment for the different entities (e.g. MN, HA, FA) to exchange data and control messages. Handoff process in IP mobility has some requirements to perform this process in an efficient and secure way. This section describes the list of requirements to allow an efficient and secure handoff. The requirements are stated with respect to Home Agent and Foreign Agent in a generic sense. 1- Mobile nodes and new Foreign domain MUST be authenticated before the start of any data sessions. 2- The MN's and User's personal information (e.g.USER's NAI , MN's IP address) sent to the home subnetwork through the foreign domain during initial the registration phase should be completely hidden from the foreign domain. 3- Keys MUST be distributed such that secure paths using the keys are established for a particular MN and MUST not be shared by another MN. 4- Layer three encryption is a MUST since not all the access technologies support layer two encryption. 5- Central authority for short session key generation to enable easier service management and certain legal requirements. 6- Proactive key distribution prior to handoff Khalil, et al. Expires April 2000 [Page 4] Internet-Draft KENA 16 October 1999 6. KENA Framework This section describes the general purpose KENA framework and solution. KENA relies on the assumption that a shared secret MUST exist between a user and the user's home authentication, authorization and accounting agency. KENA provides a strategy by which the user's home is responsible for generating the keys required for securing paths between nodes which provide the user his/her services. The point of attachment MAY be the home system or a serving system other than the home system. A serving system CANNOT be trusted until the home authenticates it. KENA assumes that the authetication between a home and serving system SHOULD occur through SLA or third party certification. Once the serving system and home system have a secure link, the home generetes keys and SPIs (and MAY potentially security attributes and policies) for use by all nodes in the serving and home system between which the users traffic will flow. This distribution of the information is achieved through extensions to existing protocols for service initiation [example Mobile IP]. It is expected that adding extensions to facilitate KENA philisophy would be fairly straighforward to any service initiation type protocols. Having a central authority for key management provides tremondous value when it comes to service management and facilitating requirements like LAES. As such the functionality provided by KENA fits neatly into the functions that COULD to be provided by a AAA server. 7. KENA over Mobile IP ---- ---- | MN |............SS1 (Predefined)......| HA | ---- K1 ---- . . . . . . . ---- . .......no SS....| FA |.....SS2......... K3 ---- K2 Figure 1: Kena over Mobile IP Khalil, et al. Expires April 2000 [Page 5] Internet-Draft KENA 16 October 1999 SS1 is a shared secret that is predefined between the MN and HA. A corresponding SPI is also predefined. We assume that a secure path (SS2) exists between FA and HA. This secure path may exist by virtue of SLA or maybe triggered to be setup dynamically by the first mobile user who requests service from a particular HA. K1, K2 & K3 are generated at the user's home and distributed to MN and FA using SS1 and SS2. K1 is the key to be used for MN-HA link, K2 is the key for FA-HA link and K3 is the key for MN-FA link. When the mobile node roams into a foreign domain it will receive an agent advertisement from the foreign agent. The agent advertisement carries information which specifies the identity of the foreign agent and foreign domain such as the foreign agent IP address [Perkins96]. Three new extensions to mobile IP are defined as a part of this draft. The extensions are IP extension, Session SA extension and Layer 2 address extension. In addition changes to the home IP address field in the mobile IP registration message and changes to the NAI extension [Calhoun99a] are required. 7.1. MN Considerations When the mobile node receives the agent advertisement and finds that it has moved to a new foreign domain it initiates the registration process by sending a Registration Request to its home domain. The Home IP address field is blanked out by using TBD value, the NAI extension encrypted, IP extension encrypted, and Layer 2 extension encrypted. All encryption MUST be executed using SS1. If the MN has an IP address then it MUST include the IP extension, else the extension MUST be dropped. The NAI extension and the Layer 2 extension MUST be included. 7.2. FA Considerations for Registration Request The FA recieving this information cannot store the MN's Home IP Address or NAI since they are encrypted. FA simply relays the message onto to the Home Agent. Behavior of the FA is otherwise the same as specified in Perkins86. This ensures that MN/mobile user's identity is fully hidden from the FA until the HA authenticates the FA. FA relays the registration request over a secure link to the home. Khalil, et al. Expires April 2000 [Page 6] Internet-Draft KENA 16 October 1999 The existence of such a secure link (SS2 shown in Figure 1) signifies that the HA and FA are aware of each other as trusted parties. Should such a secure link be absent, then the MN registration request SHOULD trigger an IKE exchange between the FA and HA such that they authenticate each other and establish a secure link. 7.3. HA Considerations for Registration Request and Registration Reply Receipt of the user's Registration Request using the SA between the Home and Foreign domain signifies that the FA is a trusted party. The HA then authenticates the user by decoding the encrypted information in the registration request and extensions using SS1. The HA then MUST interface with a key distribution center and obtain three keys and corresponding SPIs. K2 and its corresponding SPI are for all future communication between the HA and FA for the particular MN registering. K3 and its corresponding SPI are for the purposes of the MN - FA link. K1 and its corresponding SPI are for the purposes of the MN - HA link. Generation of the keys ensures that the HA interfaces with the Central Key Distribution Center (CKDC). Distribution of the keys and SPI occurs as follows. The HA MUST attach four Session SA extensions to the Registration reply. The first extension MUST carry K2 in the clear. The second extension MUST carry K3 in the clear. The first and second extension is sent in the clear since the HA-FA link is secure. The third extension MUST carry K3 encrypted using SS1. The fourth extension MUST carry K1 encrypted using SS1. The third and fourth extensions are intended for delivery to mobile node and are encrypted since MN-FA link is not secure. HA MUST also attach the layer 2 extension in the clear. The MN's IP address MUST be in the clear for use by the FA. All other functions of the HA are as defined in Perkins86. 7.4. FA Considerations for Registration Reply The FA upon receipt of the the Registration reply MUST strip the first 2 Session SA extensions. K2 and its SPI SHOULD be used for all further communication with the HA for traffic pertaining to the particular MN. Key K3 and corresponding SPI MAY be used for all communication with the MN. It is expected that certain technologies may provide layer 2 Khalil, et al. Expires April 2000 [Page 7] Internet-Draft KENA 16 October 1999 encrption and therefore choose not to implement MN-FA layer 3 security from a performance perspective. The FA forwards the third and fourth extensions to the MN in the Registration Reply. The FA is able to identify the mobile node since it now has the MN's Home IP address and layer 2 extension from the HA. 7.5. End to End Flow MN FA HA 1. R.Req [Encrypted Identity using SS1] ------------------------------> (insecure link) 2. R.Req relayed ---------------------------> (secure link SS2) 3. R.Reply [K2, K3, K3 & K1 encrypted using SS1] <--------------------------- (secure link SS2) 4. R.Reply [K3 & K1 encrypted using SS1] <----------------------------- (insecure link) All further traffic All further taffic <----------------------------> <--------------------------> (secure link using K3) (secure link using K2) <-----------------------------------------------------------> (secure link using K1) Figure 2: End to End Flow using MIP messaging and extensions Khalil, et al. Expires April 2000 [Page 8] Internet-Draft KENA 16 October 1999 7.6. Handoff considerations In the mechanism described above, the key generation and distribution has occured during registration. This adds great value from a handoff perspective where in the requirements are real-time sensitive. Keys are setup in a single step as opposed to a two step process that will be required with a a solution using IKE. 8. KENA over Mobile IP - Message Specification 8.1. NAI Extension Khalil, et al. Expires April 2000 [Page 9] Internet-Draft KENA 16 October 1999 This section defines a general purpose NAI extension for different types of entities such MN, HA, FA etc. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | length | content-type |E| rsv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAI-INFO ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD length The length of the NAI-INFO field. content-type this field describes the type of the entity which owns the NAI. The following types are defined: 0 MN-NAI 1 FA-NAI 2 HA-NAI E if 1 then the contents of NAI-INFO field is encrypted. SPI Security Parameter Index. Defines the key and type of encrypted algorithm which used to encrypt the NAI. This parameter is included only if the E bit set ( E=1). NAI-INFO Contains the NAI string in an encrypted or regular string format. Should the mobile node not send the HA's IP address in the registration request, then it MUST inlcude the HA NAI in the clear. 8.2. L2 Address Extension Khalil, et al. Expires April 2000 [Page 10] Internet-Draft KENA 16 October 1999 This section defines a general purpose L2 Address extension for different types transport technologies. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | length | content-type |E| rsv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2-ADDRESS-INFO ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD length The length of the L2 ADDRESS-INFO field. content-type this field describes the type of L2 addresses included in the extension. The following types are defined: 0 ETHERNET-ADDRESS 1 IMSI 2 MIN E if 1 then the contents of L2-ADDRESS-INFO field is encrypted. SPI Security Parameter Index. Defines the key and type of encrypted algorithm which used to encrypt the L2-ADDRESS-INFO filed. This parameter is included only if the E bit set ( E=1). L2-ADDRESS-INFO Contains the L2 address in an encrypted of reqular format. 8.3. IP Extension Khalil, et al. Expires April 2000 [Page 11] Internet-Draft KENA 16 October 1999 This section defines a general purpose IP extension which carry IP addresses in encrypted or unencrypted format. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | length | content-type |E| rsv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP-INFO ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD length The length of the IP-INFO field. content-type defines the type of entity which owns the IP address: 0 MN-HOME-IP 1 DEFAULT-ROUTER-IP E if 1 then the contents of IP-INFO field is encrypted. SPI Security Parameter Index. Defines the key and type of encrypted algorithm which used to encrypt the IP-INFO filed. This parameter is included only if the E bit set ( E=1). IP-INFO Contains the IP address in an encrypted of reqular format. 8.4. Per Session Security Association Extension Khalil, et al. Expires April 2000 [Page 12] Internet-Draft KENA 16 October 1999 This section defines a general purpose security association extension which carry information necessary to establish security association between different entities in the MIP model (e.g. MN-FA SA and FA-HA SA). 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | length | content-type |E| rsv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SA-INFO ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD length The length of the SA-INFO field. content-type defines the type of entity which owns the IP address: 0 MN-FA-SA 1 FA-HA-SA E if 1 then the contents of SA-INFO field is encrypted. SPI Security Parameter Index. Defines the key and type of encrypted algorithm which used to encrypt the SA-INFO field. This parameter is included only if the E bit set ( E=1). SA-INFO This field encode the information to establish security association such as SPI, private key, type of algorithm reqiured for enceryption and decryption etc. 9. KENA over Mobile IP using AAA KENA lends itself to be used with AAA and the strategy is to have the Home AAA server be the centralised key generating and distribution entity [Perkins99] The general architecture and flow Khalil, et al. Expires April 2000 [Page 13] Internet-Draft KENA 16 October 1999 is as indicated in the figure below. ---- ------ | MN |............SS1 (Predefined)......| HAAA | ---- ------ . . . . . . . . . . . . . . ------ . . . ................| FAAA |.....(SS2)...... . . ------ . . . . . . . . . . . . . . . ---- ---- . ................| FA |................| HA | . K3 ---- K2 ---- . . ............................................. K1 Figure 3: KENA with AAA The implementation of KENA here is identical to the implementation in the mobile IP case. The MN MUST have a predefined shared secret SS1 with the Home AAA server. There MUST be a secure path between the Foreign AAA and Home AAA (SS2 in this example). The MNs critical information MUST be encrypted during the registration process and the secure link between the FAAA and HAAA is used to distribute the keys K1, K2 and K3. An implicit assumption here is that the links between the FAAA and FA and that between the HA and HAAA are secure. The detailed message specification for this section is deferred to a future date. Khalil, et al. Expires April 2000 [Page 14] Internet-Draft KENA 16 October 1999 MN FA FAAA HAAA HA Reg-Request |(SS1) | | | | (a)|------------->| | | | | |AMR (SS1) | | | (b)| |----------->| | | | | |(SS2)AMR (SS1)| | (c)| | |------------->| | | | | |AMR | (d)| | | |--------------->| | | | |AMA {SS1(K1), | | | | |SS1(K3), K2, K3}| (e)| | | |<---------------| | | |(SS2) AMA | | | | |{ K2, K3, | | | | |SS1(K3), | | | | |SS1(K1) } | | (f)| | |<-------------| | | |AMA | | | | |{ K2, K3 | | | | |SS1(K3), | | | | |SS1(K1) } | | | (g)| |<-----------| | | | Reg-Reply | | | | | { SS1(K1), | | | | | SS1(K3) } | | | | (h)|<-------------| | | | Figure 4: KENA with AAA flows Figure 4 shows the message flow from the MN to HA and back to the MN passing through FAAA and HAAA [Calhoun99b]. (a) The MN sends a Registration Request to FA with all of its personal information (e.r. MN's Home IP address, User's NAI etc.) encrypted using SS1. (b) The FA receives the Registration Request and creates AMR [Calhoun98] message. It then forwards the AMR to FAAA using the secure link (between FA and FAAA). The user's personal information is still encrypted (using SS1) inside the AMR. (c) The FAAA forwards the AMR to the appropriate HAAA using the secure tunnell (SS2). As before, the user's personal information is still encrypted (using SS1) inside the AMR. Khalil, et al. Expires April 2000 [Page 15] Internet-Draft KENA 16 October 1999 (d) The HAAA forwards the AMR to the appropriate HA using the secure link (between HAAA and HA). (e) The HA then decrypts the user's personal information using SS1. It then proceeds with the registration process which includes authenticating the credentials of both the MN and the foeign domain (FA, in this case). It also interfaces with CKDC and gets all the keys (K1, K2 and K3). HA next creates the AMA [Calhoun98] message and sends it to HAAA using the secure link (between HA and HAAA). It sends K2, K3 in the clear and K1, K3 encrypted using SS1. (f) The HAAA forwards the AMA to HAAA using the secure tunnel (SS2). (g) The FAAA forwards the AMA message to FA using the secure link (between FAAA and FA). (h) Upon receiving the AMA, the FA creates the Registration Reply and sends it to MN. The Registration Reply includes the encrypted keys K1 and K3. The FA also receives K2 and K3 in the clear (using SS2). The MN at this point has esablished a session security association with the FA and HA. 10. Security Considerations This draft deals with a general purpose key exchange mechanism to fulfill certain security requirements. An implementation of KENA to fulfill mobility requirements is specified using Mobile IP. 11. Acknowledgements The authors would like to thank Russ Coffin and Basavaraj Patil for their input on this draft and Marcus Leech on discussions with respect to KENA. Khalil, et al. Expires April 2000 [Page 16] Internet-Draft KENA 16 October 1999 12. References [1] [McCann99] McCann, Hiller, "IP Tansform Policy Distribution using Mobile IP/DIAMETER", draft-mccann-transform-00.txt, June 1999. Work in Progress. [2] [Patil99] Patil, Narayanan, Qaddoura, "Security Requirements/Implementation Guidelines for Mobile IP using IP Security", draft-bpatil-mobileip-sec-guide-00.txt, June 99 [3] [Calhoun98] Calhoun, Perkins, "DIAMETER Mobile IP Extensions", draft-calhoun-diameter-mobileip-01.txt, November 1998. Work in Progress. [4] [Calhoun99a] Calhoun, Perkins, "Mobile IP Network Access Identifier Extension", draft-ietf-mobileip-mn-nai-04.txt [5] [Dommety99] Dommety, Glass, Hiller, Jacobs, Patil, Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", draft-ietf-aaa-mobile-ip-req-00.txt [6] [Perkins99] Perkins, Calhoun, "AAA Registration Keys for Mobile IP" draft-ietf-mobileip-aaa-key-00.txt [7] [Khalil99] Khalil, Akhtar, Qaddoura, "Buffer Management for Mobile IP", draft-mkhalil-mobileip-buffer-00.txt [8] [Ladley99] Ladley, "A DIAMETER-based Authentication and Access Control Protocol", draft-ladley-diameter-pr-00.txt [9] [Calhoun99b] Calhoun, Perkins, "DIAMETER Mobile IP extensions", draft-calhoun-diameter-mobileip-02.txt [10] [Harkins98] Harkins, Carrel, "The Interent Key Exchange", RFC 2409, November 1998. [11] [Perkins96] Perkins, "IP mobility Support", RFC 2002, Oct 96 13. Authors' Addresses Questions about this document can be directed to: Khalil, et al. Expires April 2000 [Page 17] Internet-Draft KENA 16 October 1999 Mohamed Khalil Emad Qaddoura Nortel Networks Inc. Nortel Networks Inc. 2201 Lakeside Blvd 2201 Lakeside Blvd Richardson, TX 75082-4399 Richardson, TX 75082-4399 Phone: +1 972 685-0564 Phone: +1 972 684-2705 E-mail: mkhalil@nortelnetworks.com E-mail: emadq@nortelnetworks.com Raja Narayanan Haseeb Akhtar Nortel Networks Inc. Nortel Networks Inc. 2201 Lakeside Blvd 2201 Lakeside Blvd Richardson, TX 75082-4399 Richardson, TX 75082-4399 Phone: +1 972 684-5707 Phone: +1 972 684-8850 E-mail: raja@nortelnetworks.com E-mail: haseeb@nortelnetworks.com Khalil, et al. Expires April 2000 [Page 18]