Internet DRAFT - draft-xwwang-ipv6-tesf

draft-xwwang-ipv6-tesf






Network Working Group                                      XingWei. Wang
Internet-Draft                                              ZhanKao. Wen
Intended status: Standards Track                                Jun. Liu
Expires: May 8, 2011                                       WeiDong. Wang
                                                          PengCheng. Liu
                                                                     NEU
                                                        November 4, 2010


                 TESF Based on True IPv6 Address Access
                      draft-xwwang-ipv6-tesf-00.txt

Abstract

   The current Email infrastructure has the property that any host
   sending mail to the mail system can identify itself as any user name
   it wants.  Furthermore, the current Email framework neither
   authenticates the sender nor traces the source of the mail, so even
   find a spam, the method is just to reject the mail or insert the mail
   source into "blacklist", and both of these methods can!_t deracinate
   the generation of spam.  This document design a Email source address
   authentication based on true IPv6 address access to identify and
   authenticate the mail source address, to trace the mail sender
   effectively, and to deracinate the generation of spam.

Status of this Memo

   This Internet-Draft is submitted to IETF 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 May 8, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal



Wang, et al.               Expires May 8, 2011                  [Page 1]

Internet-Draft   TESF Based on True IPv6 Address Access    November 2010


   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
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  TESF Overview  . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  TESF detailed view . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Intra-domain authentication  . . . . . . . . . . . . . . .  7
       3.1.1.  IPv6 address . . . . . . . . . . . . . . . . . . . . .  7
       3.1.2.  IPv6 address authentication  . . . . . . . . . . . . .  7
       3.1.3.  Update of variational IP address list  . . . . . . . .  8
     3.2.  Inter-domain authentication  . . . . . . . . . . . . . . .  9
   4.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Intra-domain authentication  . . . . . . . . . . . . . . . 12
       4.1.1.  IP address authentication faild  . . . . . . . . . . . 12
       4.1.2.  IP address authentication sucess . . . . . . . . . . . 12
     4.2.  Inter-domain authentication  . . . . . . . . . . . . . . . 13
       4.2.1.  Original mail  . . . . . . . . . . . . . . . . . . . . 13
       4.2.2.  Mail dealed by sender domain . . . . . . . . . . . . . 13
       4.2.3.  Mail passed inter-domain authentication  . . . . . . . 14
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
     5.1.  DNS  . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.2.  Key management . . . . . . . . . . . . . . . . . . . . . . 16
     5.3.  DNS spoofing . . . . . . . . . . . . . . . . . . . . . . . 16
   6.  Notes to Implementers  . . . . . . . . . . . . . . . . . . . . 17
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19














Wang, et al.               Expires May 8, 2011                  [Page 2]

Internet-Draft   TESF Based on True IPv6 Address Access    November 2010


1.  Introduction

   The current e-mail infrastructure has the property that any host
   injecting mail into the mail system can identify itself as any user
   name it wants.  While this feature is desirable in some
   circumstances, it is a major obstacle to reducing Unsolicited Bulk
   E-mail (UBE, aka "spam").  Furthermore, the current email framework
   on Internet can!_t trace the source of Email, so it can't deracinate
   the generation of spam.

   This document design a Email source address authentication based on
   true IPv6 address access.  The authentication is devided into inter-
   domain authentication and intra-domain authentication.  For the
   purposes of this document, authentication is seen from a user
   perspective, and is intended to answer the question "who sent this
   email and if the IP address he used has passed the authentication."
   where "who" is the email address the recipient sees and IP address
   pass the authentication means we can find out the sender of the spam
   using this IP address.

   This document defines a protocol by which domain owners may authorize
   its user and the user's IP addressto use their domain name in the
   "MAIL FROM" or "HELO" identity.  For other domain's mail,
   authenticate the domain included in "MAIL FROM" and "FROM" fields,
   because these two fields are mostly abused.

1.1.  Motivation

   TESF(Trusted Email System Framework) is a simple and effective mail
   source authentication mechanism which is used to trace the sender of
   the spam by sender domain and affirm the sender domain by the
   receiver domain.

   TESF has the following characteristic:

   1.  Using IP address authentication to avoid the sender denies his
       mail;

   2.  Using variational IP address to support user mobility;

   3.  It can trace the spam sender by binding user's fixed IP address;

   4.  Using two levels authentication methanism to improve authentation
       efficency;

   5.  Support both of mail forwarding and mailing list.





Wang, et al.               Expires May 8, 2011                  [Page 3]

Internet-Draft   TESF Based on True IPv6 Address Access    November 2010


1.2.  Terminology

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   The key words "MUST", "RECOMMENDED, "MAY" and "OPTIONAL"in this
   document are to be interpreted as defined in "Key words for use in
   RFCs to Indicate Requirement Levels"[KEYWORDS].











































Wang, et al.               Expires May 8, 2011                  [Page 4]

Internet-Draft   TESF Based on True IPv6 Address Access    November 2010


2.  TESF Overview

   TESF divides the authentication to inter-domain and intra-domain
   authentication.  Inter-domain authentication is used to authenticate
   the mail sender!_s domain.  It combines path authentication-based,
   cryptographic authentication-based and reputation and accreditation
   system-based methods in order to support both of mail forwarding and
   mail list.  Authentication efficiency can be further improved by
   organizing authentication order properly.  Intra-domain is used to
   affirm the sender!_s IP address which is used to trace the sender.
   It supports user!_s mobility by combining the fixed and variational
   IP address.

   For intra-domain user's sending request, mail server first request
   his username and password, and then authenticae his IP address, if
   both pass, send the mail and add a Domainkeys signature on the mail
   header.

   For inter-domain's mail, mail source authenticaion flow isGBPo

   1.  Black-white list authentication;

   2.  SPF authentication;

   3.  Domainkeys authentication.

   For these three authentication, if anyone of them success, the finial
   authenticated result is success so that it can support both of mail
   forwording and mailing list, otherwise, authentication result is
   failed.





















Wang, et al.               Expires May 8, 2011                  [Page 5]

Internet-Draft   TESF Based on True IPv6 Address Access    November 2010


                           Interdomain
                          Authetication
                           /         \
                          / +-------+ \
         +----------------->|  DNS  |--------------------+
         |                  +-------+                    |
         |                                               V
   +------------+             Email                +------------+
   | sender MTA |--------------------------------->|receiver MTA|
   +------------+                                  +------------+
          A
          |<--------Intradomain
          |        Authetication
   +------------+
   |   sender   |
   +------------+

                                 Figure 1

































Wang, et al.               Expires May 8, 2011                  [Page 6]

Internet-Draft   TESF Based on True IPv6 Address Access    November 2010


3.  TESF detailed view

3.1.  Intra-domain authentication

   This module is used to authenticate user's identity, and it contain
   SASL and IPv6 address authentication.  It first authenticates user's
   username and password using SASL, and then authenticates user's IP
   address.  If either one of them failed, reject this user.


              +--------+ Yes  +---------+ No   +-----------+ Yes
   login----->|  SASL  |----->| IP used |----->|IP Password|----->accept
              +--------+       +---------+      +-----------+
                  |No              |Yes              |No
                  V                V                 V
                reject           accept            reject

                                 Figure 2

3.1.1.  IPv6 address

   According to RFC3513, even the same host computer, at the different
   time, its IPv6 address is different.  So, match IPv6 address can't
   match all of the 128bits while match part of them, for example, just
   match first 64 bits, and this means the authentication precision is a
   link of a network.

   Further more, IP address in this document is means IPv6 address.

3.1.2.  IPv6 address authentication

   For every user, his corresponding information include a fixed IP
   address and a variational IP address list.

   IPv6 address authentication algorithm is as follows:

   1.  If user's current IP address equal to his fixed IP address,
       authenticaion success, goto 4, otherwise goto 2.

   2.  If user's current IP address exsit in his variational IP address
       list, authenticaion success, goto 4, otherwise goto 3.

   3.  Request user to input his IP auth password, if match, update the
       variational IP address list, authenticaion success, goto 4,
       otherwise authentication failed, goto 4.

   4.  Algorithm Ends.




Wang, et al.               Expires May 8, 2011                  [Page 7]

Internet-Draft   TESF Based on True IPv6 Address Access    November 2010


3.1.3.  Update of variational IP address list

   Variational IP address list storage user's variational IP addresses
   (mobility user's temporary address).  It's organised as a list, and
   every element in the list contain a IP address and a counter.  If
   user's current IP address is neither his fixed IP address nor in his
   variational IP address list, update the variational IP address list
   according to the LRU algorithm.

   a.  If variational IP address list doesn't reach its max length, add
       the current IP address into the variational IP address list and
       then set all the couter to 0.

   b.  If current IP address exist in the variational IP address list,
       add its counter by 1.

   c.  If don't match these two rules, find out the minimaze counter in
       the list (if there are more than one of these IP address, find
       out the last one), delete it and add the current IP address into
       the variational IP address list and then set all the couter to 0.

   We expatiate these three rules bellow, suppose max list size is 5,
   current user jack@mail.neu6.edu.cn's list size is 4.

   a.  If jack@mail.neu6.edu.cn use a new IP address 2001:200:0:8002:*
       to send mail, IP address list change as follows, suppose there
       just match first 64 bits of IPv6 address, so the last 64 ones is
       ignored.


    +----------------------+---+         +----------------------+---+
    | 2001:da8:9000:b255:* | 5 |         | 2001:da8:9000:b255:* | 0 |
    +----------------------+---+         +----------------------+---+
    | 5f1b:df0:ce3e:e200:* | 2 |         | 5f1b:df0:ce3e:e200:* | 0 |
    +----------------------+---+         +----------------------+---+
    | 3ffe:b80:3a0f:9ad1:* | 4 | ------> | 3ffe:b80:3a0f:9ad1:* | 0 |
    +----------------------+---+         +----------------------+---+
    |  2001:200:20:4819:*  | 1 |         |  2001:200:20:4819:*  | 0 |
    +----------------------+---+         +----------------------+---+
    |                      |   |         |  2001:200:20:8002:*  | 0 |
    +----------------------+---+         +----------------------+---+

                                   Figure 3

   b.  If jack@mail.neu6.edu.cn use 5f1b:df0:ce3e:e200:* to send mail,
       because this address is already exsit in the address list, so
       just add the counter by 1.




Wang, et al.               Expires May 8, 2011                  [Page 8]

Internet-Draft   TESF Based on True IPv6 Address Access    November 2010


    +----------------------+---+         +----------------------+---+
    | 2001:da8:9000:b255:* | 5 |         | 2001:da8:9000:b255:* | 5 |
    +----------------------+---+         +----------------------+---+
    | 5f1b:df0:ce3e:e200:* | 2 |         | 5f1b:df0:ce3e:e200:* | 3 |
    +----------------------+---+         +----------------------+---+
    | 3ffe:b80:3a0f:9ad1:* | 4 | ------> | 3ffe:b80:3a0f:9ad1:* | 4 |
    +----------------------+---+         +----------------------+---+
    |  2001:200:20:4819:*  | 1 |         |  2001:200:20:4819:*  | 1 |
    +----------------------+---+         +----------------------+---+
    |  2001:200:20:8002:*  | 3 |         |  2001:200:20:8002:*  | 3 |
    +----------------------+---+         +----------------------+---+

                                   Figure 4

   c.  If jack@mail.neu6.edu.cn use a new address 2001:288:3b0:1c04:* to
       send mail, because this address isn't in the address list, so
       replace the least and recently used IP address, and then clear
       the couter of every address.


    +----------------------+---+         +----------------------+---+
    | 2001:da8:9000:b255:* | 5 |         | 2001:da8:9000:b255:* | 0 |
    +----------------------+---+         +----------------------+---+
    | 5f1b:df0:ce3e:e200:* | 3 |         | 5f1b:df0:ce3e:e200:* | 0 |
    +----------------------+---+         +----------------------+---+
    | 3ffe:b80:3a0f:9ad1:* | 4 | ------> | 3ffe:b80:3a0f:9ad1:* | 0 |
    +----------------------+---+         +----------------------+---+
    |  2001:200:20:4819:*  | 1 |         |  2001:288:3b0:1c04:* | 0 |
    +----------------------+---+         +----------------------+---+
    |  2001:200:20:8002:*  | 3 |         |  2001:200:20:8002:*  | 0 |
    +----------------------+---+         +----------------------+---+

                                   Figure 5

3.2.  Inter-domain authentication

   Inter-domain authentication is used to affirm the mail's domain.  It
   conbines multi-methanisms to offset the weakness of just use one
   methanism.  It combines path authentication-based, cryptographic
   authentication-based and reputation and accreditation system-based
   methods in order to support both of mail forwarding and mail list.
   Authentication efficiency can be further improved by organizing
   authentication order properly.  The path authentication-based method
   is SPF, cryptographic authentication-based is Domainkeys and
   reputation and accreditation system-based method is blacklist.

   Because reputation can't affirm if the mail sender domain is true, it
   can just affirm which domain always sends spam, so first do the



Wang, et al.               Expires May 8, 2011                  [Page 9]

Internet-Draft   TESF Based on True IPv6 Address Access    November 2010


   reputation authentication, reject the domain exsiting in the
   blacklist.  For SPF and Domainkeys, SFP is authenticted before the
   mail body is send while Domainkeys is authenticated after all the
   mail is send, meanwhile SPF's effiency is better then Domainkeys, so
   do SPF first and then do Domainkeys authentication.  So, if SPF is
   success, there is no need to do the Domainkeys, which can further
   improve the authenticaiton effiency.  Inter-domain authenticaion flow
   is as follows:

   1.  Do the DNS blacklist authenticaion, if the sender domain is in
       the blacklist, reject it, otherwise do the SPF authentication.

   2.  Do SPF authenticaion, if success, add "X-Mail-Source-Auth: Pass"
       into mail's header, inter-domain authenticaion success, otherwise
       do Domainkeys authentication.

   3.  If Domainkeys authentication successGBP[not]add "X-Mail-Source-
       Auth: Pass" into mail's header, inter-domain authenticaion
       success, otherwise inter-domain authenticaion failed, reject the
       sending request.

   The Inter-domain authenticaion flow is:





























Wang, et al.               Expires May 8, 2011                 [Page 10]

Internet-Draft   TESF Based on True IPv6 Address Access    November 2010


                      +-------------+  hate
                      |  Reputation |-----+
                      +-------------+     |
                             |            |
                             |love/shrug  |
                             V            |
                 pass +-------------+     |
           +----------|     SPF     |     |
           |          +-------------+     |
           |                 |fail/       |
           |                 |unknown     |
           |                 V            |
           |     pass +-------------+     |
           | <--------| Domainkeys  |     |
           |          +-------------+     |
           |                 |fail/       |
           |                 |unknown     |
           |                 |<-----------+
           V                 V
       +-------+         +-------+
       |  pass |         | fail  |
       +-------+         +-------+

                                 Figure 6



























Wang, et al.               Expires May 8, 2011                 [Page 11]

Internet-Draft   TESF Based on True IPv6 Address Access    November 2010


4.  Examples

4.1.  Intra-domain authentication

   This module is a extension of SASL.  If IPv6 address authentication
   success, it same as the normal SASL, otherwise need user to input his
   IP auth password.

4.1.1.  IP address authentication faild

   If user's current IP address isn't his fixed IP and doesn't exsit in
   his variational IP address, mail server request user to input his IP
   auth password.


         S: 220 smtp.example.com ESMTP server ready
         C: EHLO mail.example.com
         S: 250-smtp.example.com
         S: 250 AUTH PLAIN LOGIN
         C: AUTH LOGIN
         S: 334
         C: bGl1cGNAdGVzdG1haWwubmV1Ni5lZHUuY24=
         S: 334
         C: dGVzdA==
         S: 334
         C: YWJjQGV4YW1wbGUuY29t
         S: 235 Authentication successful

                                 Figure 7

4.1.2.  IP address authentication sucess

   If user's current IP address is his fixed IP or exsit in his
   variational IP address, it's the same as the traditional SASL.

















Wang, et al.               Expires May 8, 2011                 [Page 12]

Internet-Draft   TESF Based on True IPv6 Address Access    November 2010


         S: 220 smtp.example.com ESMTP server ready
         C: EHLO mail.example.com
         S: 250-smtp.example.com
         S: 250 AUTH PLAIN LOGIN
         C: AUTH LOGIN
         S: 334
         C: bGl1cGNAdGVzdG1haWwubmV1Ni5lZHUuY24=
         S: 334
         C: dGVzdA==
         S: 235 Authentication successful

                                 Figure 8

4.2.  Inter-domain authentication

4.2.1.  Original mail

   The example mail is:


   From: "liupc" <liupc@testmail2.neu6.edu.cn>
   To: liupc@testmail.neu.edu.cn
   Subject: test
   Date: Sun, 19 Nov 2006 15:48:18 +0800

   HI
     this is a test
   bye

                                 Figure 9

4.2.2.  Mail dealed by sender domain

   User's mail is dealed at his domain MTA, which add some header fields
   and Domainkeys signature.  For the example mail above, the mail is
   changed to:















Wang, et al.               Expires May 8, 2011                 [Page 13]

Internet-Draft   TESF Based on True IPv6 Address Access    November 2010


   DomainKey-Signature: a=rsa-sha1; b=YouIbq+DaoJud3Jc34oOqAvCdecqp/6x57
                        Jpw+dlcZTOWIUv57gtSfdkdCtDYPbzWWeeZFYchoTG8h8i+m
                        MKH/qTymjsObPk2c6fhhR/QCula/R1l73nOyehtl9ktZ5JPd
                        U2ZHxkLCZ8DgpzsajnGiRoqNFgb1VkBhDUAQ7k2cM=; c=no
                        fws; d=testmail2.neu6.edu.cn; q=dns; s=selector1
   Received: by testmail2.neu6.edu.cn (Postfix, from userid 502)
           id 8F08994511; Sun, 19 Nov 2006 15:48:18 +0800 (CST)
   From: "" <liupc@testmail2.neu6.edu.cn>
   To: liupc@testmail.neu6.edu.cn
   Subject: =?gb2312?B?dGVzdA==?=
   Date: Sun, 19 Nov 2006 15:48:18 +0800
   X-Originating-IP: [2001:da8:9000:b255:cc22:18a4:4732:f6c2]
   Message-Id: <20061119074818.8F08994511@testmail2.neu6.edu.cn>

   HI
     this is a test
   bye

                                 Figure 10

4.2.3.  Mail passed inter-domain authentication

   Receiver's domain MTA add the "X-Mail-Source-Auth-Domain: PASS" and
   some other headers.  Suppose the mail above passes Domainkeys while
   fail SPF, and the mail is changed to:


























Wang, et al.               Expires May 8, 2011                 [Page 14]

Internet-Draft   TESF Based on True IPv6 Address Access    November 2010


  Received: from testmail.neu6.edu.cn (localhost.localdomain [IPv6:::1])
          by testmail.neu6.edu.cn (Postfix) with ESMTP id 3410CF3A8A
          for <liupc@testmail.neu6.edu.cn>; Sun, 19 Nov 2006 15:59:01
              +0800 (CST)
  Received: from testmail.neu6.edu.cn (localhost.localdomain [IPv6:::1])
          by testmail.neu6.edu.cn (Postfix) with ESMTP id 1592EF3A1E
          for <liupc@testmail.neu6.edu.cn>; Sun, 19 Nov 2006 15:59:01
              +0800 (CST)
  X-Mail-Source-Auth-Domain: PASS
  Authentication-Results: localhost.localdomain from=liupc@testmail2.neu
                          6.edu.cn; domainkey=pass
  Received-SPF-IPv6: reject Please see http://spf.pobox.com/why.html?sen
                     der=liupc%40testmail2.neu6.edu.cn&ip=2001%3ada8%3a9
                     000%3ab255%3a202%3ab3ff%3afeb7%3a27f2&receiver=loca
                     lhost.localdomain
  Received: from testmail2.neu6.edu.cn (unknown [IPv6:2001:da8:9000:b255
            :202:b3ff:feb7:27f2])
          by testmail.neu6.edu.cn (Postfix) with ESMTP
          for <liupc@testmail.neu6.edu.cn>; Sun, 19 Nov 2006 15:59:01
              +0800 (CST)

                                 Figure 11





























Wang, et al.               Expires May 8, 2011                 [Page 15]

Internet-Draft   TESF Based on True IPv6 Address Access    November 2010


5.  Security Considerations

5.1.  DNS

   The objective of the SAAF is to authenticate the sender domain by a
   reliable ways, but SAAF mostly depends on DNS, which is vulnerable.

   The SAAF increases the load of the DNS servers, for it has to provide
   SPF records and Domainkey records for receiver MTA.  Frequent using
   The SAAF makes the DNS query increase sharply, and then lots of cheat
   IP addresses appear, which makes the situation more and more worse.

5.2.  Key management

   Because Domainkeys is one of the main part of the SASF, one of
   problems is to guarantee the security of the private key.  Once the
   private key is lost, the whole mechanism will be disable.

5.3.  DNS spoofing

   If there is a spam sender applies an independent domain, configures
   SPF and Domainkeys in it, then the SAAF will be disable.  And with
   the growth of the spam senders under this domain, the domain will be
   added into blacklist, then the successive spams will rejected
   directedly.  But the spams before that will be delivered.


























Wang, et al.               Expires May 8, 2011                 [Page 16]

Internet-Draft   TESF Based on True IPv6 Address Access    November 2010


6.  Notes to Implementers

   Besides the modifications of the e-mail system, one of the most
   important works is to make DNS to support TESF, that is, configures
   TXT records of the SPF and Domainkeys in the DNS servers.














































Wang, et al.               Expires May 8, 2011                 [Page 17]

Internet-Draft   TESF Based on True IPv6 Address Access    November 2010


7.  Normative References

   [RFC1883]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 1883, December 1995.

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

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513, April 2003.

   [RFC4408]  Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
              for Authorizing Use of Domains in E-Mail, Version 1",
              RFC 4408, April 2006.































Wang, et al.               Expires May 8, 2011                 [Page 18]

Internet-Draft   TESF Based on True IPv6 Address Access    November 2010


Authors' Addresses

   XingWei Wang
   Northeastern University
   No.11, Lane 3, WenHua Road, HePing District
   Shenyang, Liaoning, China  110004


   Phone:
   Email: wangxw@mail.neu.edu.cn
   URI:


   ZhanKao Wen
   Northeastern University


   Phone:
   Email: wzk@mail.neu.edu.cn
   URI:


   Jun Liu
   Northeastern University


   Phone:
   Email: liuj@mail.neu.edu.cn
   URI:


   WeiDong Wang
   Northeastern University


   Phone:
   Email: wangwd@mail.neu.edu.cn
   URI:


   PengCheng Liu
   Northeastern University


   Phone:
   Email: lpengcheng@126.com
   URI:




Wang, et al.               Expires May 8, 2011                 [Page 19]