Network Working Group                                         V. Cakulev
Internet-Draft                                            Alcatel Lucent
Intended status: Standards Track                                 A. Lior
Expires: December 3, 2011                            Bridgewater Systems
                                                            June 1, 2011


Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to
                      Diameter Server Interaction
               draft-ietf-dime-ikev2-psk-diameter-07.txt

Abstract

   The Internet Key Exchange protocol version 2 (IKEv2) is a component
   of the IPsec architecture and is used to perform mutual
   authentication as well as to establish and to maintain IPsec security
   associations (SAs) between the respective parties.  IKEv2 supports
   several different authentication mechanisms, such as the Extensible
   Authentication Protocol (EAP), certificates, and pre-shared secrets.

   Diameter interworking for Mobile IPv6 between the Home Agent, as a
   Diameter client, and the Diameter server has been specified.
   However, that specification focused on the usage of EAP and did not
   include support for pre-shared secret based authentication available
   with IKEv2.  This document specifies IKEv2 server, as a Diameter
   client, to the Diameter server communication for IKEv2 with pre-
   shared secret based authentication.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on December 3, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the



Cakulev & Lior          Expires December 3, 2011                [Page 1]


Internet-Draft             Diameter IKEv2 PSK                  June 2011


   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   3.  Application Identifier . . . . . . . . . . . . . . . . . . . .  5
   4.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Support for IKEv2 and Pre-Shared Secrets . . . . . . . . .  6
     4.2.  Session Management . . . . . . . . . . . . . . . . . . . .  6
       4.2.1.  Session-Termination-Request/Answer . . . . . . . . . .  7
       4.2.2.  Abort-Session-Request/Answer . . . . . . . . . . . . .  7
   5.  Command Codes for Diameter IKEv2 with PSK  . . . . . . . . . .  8
     5.1.  IKEv2-PSK-Request (IKEPSKR) Command  . . . . . . . . . . .  8
     5.2.  IKEv2-PSK-Answer (IKEPSKA) Command . . . . . . . . . . . .  9
   6.  Attribute Value Pair Definitions . . . . . . . . . . . . . . . 11
     6.1.  IKEv2-Nonces . . . . . . . . . . . . . . . . . . . . . . . 11
       6.1.1.  Ni . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       6.1.2.  Nr . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  AVP Occurrence Tables  . . . . . . . . . . . . . . . . . . . . 12
   8.  AVP Flag Rules . . . . . . . . . . . . . . . . . . . . . . . . 13
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     9.1.  Command Codes  . . . . . . . . . . . . . . . . . . . . . . 14
     9.2.  AVP Codes  . . . . . . . . . . . . . . . . . . . . . . . . 14
     9.3.  AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 14
     9.4.  Application Identifier . . . . . . . . . . . . . . . . . . 14
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     11.2. Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17









Cakulev & Lior          Expires December 3, 2011                [Page 2]


Internet-Draft             Diameter IKEv2 PSK                  June 2011


1.  Introduction

   [RFC5996] defines the version 2 of Internet Key Exchange (IKE) as a
   protocol that performs mutual authentication between two parties and
   establishes a security association (SA) that includes shared secret
   information that can be used to efficiently establish SAs for
   Encapsulating Security Payload (ESP) [RFC4303] and/or Authentication
   Header (AH) [RFC4302], and a set of cryptographic algorithms to be
   used by the SAs to protect the traffic that they carry.  The IKEv2
   protocol allows several different mechanisms for authenticating a
   IKEv2 Peer to be used, such as the Extensible Authentication
   Protocol, certificates, and pre-shared secrets.

   From a service provider perspective, it is important to ensure that a
   user is authorized to use the services.  Therefore, the IKEv2 Server
   must verify that the IKEv2 Peer is authorized for the requested
   services possibly with the assistance of the operator's Diameter
   servers.  [RFC5778] defines the home agent as a Diameter client to
   the Diameter server communication when the mobile node authenticates
   using the IKEv2 protocol with the Extensible Authentication Protocol
   (EAP) [RFC3748] or using the Mobile IPv6 Authentication Protocol
   [RFC4285].  This document specifies IKEv2 server, as a Diameter
   client, to the Diameter server communication for IKEv2 with pre-
   shared secret based authentication.

   This document does not assume that the IKEv2 Server has the pre-
   shared secrets (PSK) with the IKEv2 Peer.  Instead, it allows for PSK
   to be derived for a specific IKEv2 session and exchanged between
   IKEv2 Server and Home Authentication, Authorization and Accounting
   (HAAA) server.  This is accomplished through the use of a new
   Diameter application specifically designed for performing IKEv2
   authorization decisions.



















Cakulev & Lior          Expires December 3, 2011                [Page 3]


Internet-Draft             Diameter IKEv2 PSK                  June 2011


2.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].














































Cakulev & Lior          Expires December 3, 2011                [Page 4]


Internet-Draft             Diameter IKEv2 PSK                  June 2011


3.  Application Identifier

   This specification defines a new Diameter application and its
   respective Application Identifier:

      Diameter IKE PSK  (IKEPSK)  TBD1 by IANA


   The IKEPSK Application Identifier is used when the IKEv2 Peer is to
   be authenticated and authorized using IKEv2 with PSK-based
   authentication.








































Cakulev & Lior          Expires December 3, 2011                [Page 5]


Internet-Draft             Diameter IKEv2 PSK                  June 2011


4.  Protocol Description

4.1.  Support for IKEv2 and Pre-Shared Secrets

   When IKEv2 is used with PSK-based initiator authentication, the
   Diameter commands IKEv2-PSK-Request/Answer defined in this document
   are used between IKEv2 server and a Home AAA server (HAAA) to
   authorize the IKEv2 Peer for the services.  Upon receiving the
   IKE_AUTH message from the IKEv2 Peer, the IKEv2 Server uses the
   information received in IDi and the SPI if available, to determine if
   it has the PSK for this IKEv2 Peer.  If there is no PSK found
   associated with this IKEv2 Peer, the IKEv2 Server MUST send an
   Authorize-Only (Auth-Request-Type set to "Authorize-Only") Diameter
   IKEv2-PSK message with the IKEv2 Peer's IDi payload and SPI if
   available to the HAAA to obtain the PSK.  The IDi payload extracted
   from the IKE_AUTH message MUST contain an identity that is meaningful
   for the Diameter infrastructure, such as a Network Access Identifier
   (NAI), since it is used by the IKEv2 Server to populate the User-Name
   AVP in the Diameter message.  The IKEv2 Server also includes in the
   IKEv2-Nonces AVP of the same Diameter message the initiator and
   responder nonces (Ni and Nr) exchanged during initial IKEv2 exchange.

   The IKEv2-PSK-Request message is routed to the IKEv2 Peer's HAAA.
   Upon receiving Diameter IKEv2-PSK-Request message from the IKEv2
   Server, the HAAA SHALL use the User-Name AVP and the Key-SPI AVP if
   included to retrieve the associated keying material.  The HAAA SHALL
   use the nonces Ni and Nr received in IKEv2-Nonces AVP to generate the
   PSK.  The HAAA returns the PSK to the IKEv2 Server using the Key AVP
   as specified in [I-D.ietf-dime-local-keytran].  It is outside of
   scope of this document how the HAAA obtains or generates the PSK.
   For example, if the HAAA previously performed EAP based access
   authentication and authorization of the IKEv2 Peer, it can use the
   available EMSK to generate the PSK [RFC5295].

   Once the IKEv2 Server receives the PSK from the HAAA, the IKEv2
   Server verifies the IKE_AUTH message received from the IKEv2 Peer.
   If the verification of AUTH is successful, the IKEv2 Server sends the
   IKE message back to the IKEv2 Peer.

4.2.  Session Management

   The HAAA may maintain state or may be stateless.  This is indicated
   by presence or absence of the Auth-Session-State AVP.  The IKEv2
   Server MUST support the Authorization Session State Machine defined
   in [RFC3588].

   This specification makes an assumption that each IKE_SA created
   between the IKEv2 Peer and the IKEv2 Server as a result of a



Cakulev & Lior          Expires December 3, 2011                [Page 6]


Internet-Draft             Diameter IKEv2 PSK                  June 2011


   successful IKEv2 negotiation exchange together with CHILD_SAs set up
   through that particular IKE_SA corresponds to one currently active
   PSK and one active Diameter session.

4.2.1.  Session-Termination-Request/Answer

   In the case where HAAA is maintaining session state, when the IKEv2
   Server terminates the SA it SHALL send a Session-Termination-Request
   (STR) message [RFC3588] to inform the HAAA that the authorized
   session has been terminated.

   The Session-Termination-Answer (STA) message [RFC3588] is sent by the
   HAAA to acknowledge the notification that the session has been
   terminated.

4.2.2.  Abort-Session-Request/Answer

   The Abort-Session-Request (ASR) message [RFC3588] is sent by the HAAA
   to the IKEv2 Server to terminate the authorized session.  When the
   IKEv2 Server receives the ASR message, it MUST delete the
   corresponding IKE_SA and all CHILD_SAs set up through it.

   The Abort-Session-Answer (ASA) message [RFC3588] is sent by the IKEv2
   Server in response to an ASR message.



























Cakulev & Lior          Expires December 3, 2011                [Page 7]


Internet-Draft             Diameter IKEv2 PSK                  June 2011


5.  Command Codes for Diameter IKEv2 with PSK

   This section defines new Command-Code values that MUST be supported
   by all Diameter implementations conforming to this specification.

    +-------------------+---------+------+-------------+-------------+
    |    Command-Name   | Abbrev. | Code |  Reference  | Application |
    +-------------------+---------+------+-------------+-------------+
    | IKEv2-PSK-Request | IKEPSKR | TBD2 | Section 5.1 |    IKEPSK   |
    |                   |         |      |             |             |
    |  IKEv2-PSK-Answer | IKEPSKA | TBD2 | Section 5.2 |    IKEPSK   |
    +-------------------+---------+------+-------------+-------------+

                          Table 1: Command Codes

5.1.  IKEv2-PSK-Request (IKEPSKR) Command

   The IKEv2-PSK-Request message, indicated with the Command-Code set to
   TBD2 and the 'R' bit set in the Command Flags field, is sent from the
   IKEv2 Server to the HAAA to initiate IKEv2 with PSK authorization.
   In this case, the Application-ID field of the Diameter Header MUST be
   set to the Diameter IKE PSK Application ID (value of TDB1).

   Message format


         <IKEv2-PSK-Request> ::= < Diameter Header: TBD2, REQ, PXY >
                                 < Session-Id >
                                 { Auth-Application-Id }
                                 { Origin-Host }
                                 { Origin-Realm }
                                 { Destination-Realm }
                                 { Auth-Request-Type }
                                 [ Destination-Host ]
                                 [ NAS-Identifier ]
                                 [ NAS-IP-Address ]
                                 [ NAS-IPv6-Address ]
                                 [ NAS-Port ]
                                 [ Origin-State-Id ]
                                 { User-Name }
                                 [ Key-SPI ]
                                 [ Auth-Session-State ]
                                 { IKEv2-Nonces }
                               * [ Proxy-Info ]
                               * [ Route-Record ]
                                 ...
                               * [ AVP ]




Cakulev & Lior          Expires December 3, 2011                [Page 8]


Internet-Draft             Diameter IKEv2 PSK                  June 2011


   The IKEv2-PSK-Request message MUST include a IKEv2-Nonces AVP
   containing the Ni and Nr nonces exchanged during initial IKEv2
   exchange.  The IKEv2-PSK-Request message MAY contain a Key-SPI AVP
   (Key-SPI AVP is specified in [I-D.ietf-dime-local-keytran]).  If
   included, it contains the Security Parameter Index (SPI) that SHALL
   be used to identify the appropriate PSK.

5.2.  IKEv2-PSK-Answer (IKEPSKA) Command

   The IKEv2-PSK-Answer (IKEPSKA) message, indicated by the Command-Code
   field set to TBD2 and the 'R' bit cleared in the Command Flags field,
   is sent by the HAAA to the IKEv2 Server in response to the IKEPSKR
   command.  In this case, the Application-ID field of the Diameter
   Header MUST be set to the Diameter IKE PSK Application ID (value of
   TDB1).

   Message format


           <IKEv2-PSK-Answer> ::= < Diameter Header: TBD2, PXY >
                                  < Session-Id >
                                  { Auth-Application-Id }
                                  { Auth-Request-Type }
                                  { Result-Code }
                                  { Origin-Host }
                                  { Origin-Realm }
                                  [ User-Name ]
                                  [ Key ]
                                  [ Auth-Session-State ]
                                  [ Error-Message ]
                                  [ Error-Reporting-Host ]
                                * [ Failed-AVP ]
                                  [ Origin-State-Id ]
                                * [ Redirect-Host ]
                                  [ Redirect-Host-Usage ]
                                  [ Redirect-Max-Cache-Time ]
                                * [ Proxy-Info ]
                                * [ Route-Record ]
                                  ...
                                * [ AVP ]

   If the authorization procedure is successful then the IKEv2-PSK-
   Answer message SHALL include the Key AVP as specified in
   [I-D.ietf-dime-local-keytran].  The value of the Key-Type AVP SHALL
   be set to IKEv2-PSK (TBD3).  The Keying-Material AVP SHALL contain
   the PSK.  If Key-SPI AVP is received in IKEv2-PSK-Request, Key-SPI
   AVP SHALL be included in Key AVP.  Exactly how the PSK is derived is
   beyond the scope of this document.  The Key-Lifetime AVP may be



Cakulev & Lior          Expires December 3, 2011                [Page 9]


Internet-Draft             Diameter IKEv2 PSK                  June 2011


   included and if it is included then the associated key SHALL NOT be
   used if the lifetime has expired.

















































Cakulev & Lior          Expires December 3, 2011               [Page 10]


Internet-Draft             Diameter IKEv2 PSK                  June 2011


6.  Attribute Value Pair Definitions

   This section defines new AVPs for the IKEv2 with PSK.

6.1.  IKEv2-Nonces

   The IKEv2-Nonces AVP (Code TBD4) is of type Grouped and contains the
   nonces exchanged between the IKEv2 Peer and the IKEv2 Server during
   IKEv2 initial exchange.  The nonces are used for PSK generation.


               IKEv2-Nonces ::= < AVP Header: TBD4>
                                {Ni}
                                {Nr}
                               *[AVP]

6.1.1.  Ni

   The Ni AVP (AVP Code TBD5) is of type Unsigned32 and contains the
   IKEv2 initiator nonce.

6.1.2.  Nr

   The Nr AVP (AVP Code TBD6) is of type Unsigned32 and contains the
   IKEv2 responder nonce.


























Cakulev & Lior          Expires December 3, 2011               [Page 11]


Internet-Draft             Diameter IKEv2 PSK                  June 2011


7.  AVP Occurrence Tables

   The following tables present the AVPs defined or used in this
   document and their occurrences in Diameter messages.  Note that AVPs
   that can only be present within a Grouped AVP are not represented in
   this table.

   The table uses the following symbols:

   0:

      The AVP MUST NOT be present in the message.


   0+:

      Zero or more instances of the AVP MAY be present in the message.


   0-1:

      Zero or one instance of the AVP MAY be present in the message.


   1:

      One instance of the AVP MUST be present in the message.



                                     +-------------------+
                                     |   Command-Code    |
                                     |---------+---------+
      AVP Name                       | IKEPSKR | IKEPSKA |
      -------------------------------|---------+---------+
      Key                            |    0    |   0-1   |
      Key-SPI                        |   0-1   |    0    |
      IKEv2-Nonces                   |    1    |    0    |
                                     +---------+---------+

                  IKEPSKR and IKEPSKA Commands AVP Table










Cakulev & Lior          Expires December 3, 2011               [Page 12]


Internet-Draft             Diameter IKEv2 PSK                  June 2011


8.  AVP Flag Rules

   The following table describes the Diameter AVPs, their AVP Code
   values, types, possible flag values, and whether the AVP MAY be
   encrypted.  The Diameter base [RFC3588] specifies the AVP Flag rules
   for AVPs in Section 4.5.


                                               +--------------------+
                                               |   AVP Flag rules   |
                                               +----+---+------+----+
                      AVP  Defined             |    |   |SHOULD|MUST|
    Attribute Name    Code in       Value Type |MUST|MAY| NOT  | NOT|
   +-------------------------------------------+----+---+------+----+
   |Key               TBD  Note 1   Grouped    |  M | P |      | V  |
   +-------------------------------------------+----+---+------+----+
   |Keying-Material   TBD  Note 1   OctetString|  M | P |      | V  |
   +-------------------------------------------+----+---+------+----+
   |Key-Lifetime      TBD  Note 1   Integer64  |  M | P |      | V  |
   +-------------------------------------------+----+---+------+----+
   |Key-SPI           TBD  Note 1   Unsigned32 |  M | P |      | V  |
   +-------------------------------------------+----+---+------+----+
   |Key-Type          TBD  Note 1   Enumerated |  M | P |      | V  |
   +-------------------------------------------+----+---+------+----+
   |IKEv2-Nonces      TBD4 6.2      Grouped    |  M | P |      | V  |
   +-------------------------------------------+----+---+------+----+
   |Ni                TBD5 6.2.1    Unsigned32 |  M | P |      | V  |
   +-------------------------------------------+----+---+------+----+
   |Nr                TBD6 6.2.2    Unsigned32 |  M | P |      | V  |
   +-------------------------------------------+----+---+------+----+

                           AVP Flag Rules Table

   Note 1: Key, Keying-Material, Key-Type, Key-SPI and Key-Lifetime AVPs
   are defined in [I-D.ietf-dime-local-keytran].
















Cakulev & Lior          Expires December 3, 2011               [Page 13]


Internet-Draft             Diameter IKEv2 PSK                  June 2011


9.  IANA Considerations

   Upon publication of this memo as an RFC, IANA is requested to assign
   values as described in the following sections.

9.1.  Command Codes

   IANA is requested to allocate a command code value for the the
   following new command from the Command Code namespace defined in
   [RFC3588].

      Command Code                     | Value
      ---------------------------------+------
      IKEv2-PSK-Request/Answer         | TBD2



9.2.  AVP Codes

   This specification requires IANA to register the following new AVPs
   from the AVP Code namespace defined in [RFC3588].


   o  IKEv2-Nonces - TBD4

   o  Ni - TBD5

   o  Nr - TBD6


   The AVPs are defined in Section 6.

9.3.  AVP Values

   IANA is requested to create a new value for the Key-Type AVP.  The
   new value TBD3 signifies that IKEv2 PSK is being sent.

9.4.  Application Identifier

   This specification requires IANA to allocate one new value "Diameter
   IKE PSK" from the Application Identifier namespace defined in
   [RFC3588].

   Application Identifier         | Value
   -------------------------------+------
   Diameter IKE PSK (IKEPSK)      | TBD1





Cakulev & Lior          Expires December 3, 2011               [Page 14]


Internet-Draft             Diameter IKEv2 PSK                  June 2011


10.  Security Considerations

   The security considerations of the Diameter Base protocol [RFC3588]
   are applicable to this document.

   The Diameter messages between the IKEv2 Server and the HAAA may be
   transported via one or more AAA brokers or Diameter agents.  In this
   case, the IKEv2 Server to the Diameter server AAA communication
   relies on the security properties of the intermediating AAA inter-
   connection networks, AAA brokers, and Diameter agents.  Furthermore,
   any agents that process IKEv2-PSK-Answer messages can see the
   contents of the Key AVP.  For this reason, this specification
   strongly recommends avoiding Diameter agents when they cannot be
   trusted to keep the keys secret.

   This specification expects that the HAAA derives and returns the
   associated PSK to the IKEv2 Server.  For the key derivation this
   specification recommends the use of short lived secrets, possibly
   based on a previous network access authentication run, if such
   secrets are available.  To ensure key freshness, limit the key scope
   etc., this specification also recommends the use of nonces included
   in IKEv2-PSK-Request.  However, this specification does not define
   how the Diameter server actually derives required keys.  The details
   of the key derivation depends on the deployment where this
   specification is used and therefore the security properties of the
   system depend on how this is done.

























Cakulev & Lior          Expires December 3, 2011               [Page 15]


Internet-Draft             Diameter IKEv2 PSK                  June 2011


11.  References

11.1.  Normative References

   [I-D.ietf-dime-local-keytran]
              Wu, W. and G. Zorn, "Diameter Attribute-Value Pairs for
              Cryptographic Key Transport",
              draft-ietf-dime-local-keytran-01 (work in progress),
              January 2010.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 5996, September 2010.

11.2.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC4285]  Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
              Chowdhury, "Authentication Protocol for Mobile IPv6",
              RFC 4285, January 2006.

   [RFC5295]  Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
              "Specification for the Derivation of Root Keys from an
              Extended Master Session Key (EMSK)", RFC 5295,
              August 2008.

   [RFC5778]  Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G.,
              and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home
              Agent to Diameter Server Interaction", RFC 5778,
              February 2010.






Cakulev & Lior          Expires December 3, 2011               [Page 16]


Internet-Draft             Diameter IKEv2 PSK                  June 2011


Authors' Addresses

   Violeta Cakulev
   Alcatel Lucent
   600 Mountain Ave.
   3D-517
   Murray Hill, NJ  07974
   US

   Phone: +1 908 582 3207
   Email: violeta.cakulev@alcatel-lucent.com


   Avi Lior
   Bridgewater Systems
   303 Terry Fox Drive
   Ottawa, Ontario  K2K 3J1
   Canada

   Phone: +1 613-591-6655
   Email: avi@bridgewatersystems.com






























Cakulev & Lior          Expires December 3, 2011               [Page 17]