Internet DRAFT - draft-zhang-hip-privacy-protection
draft-zhang-hip-privacy-protection
Network Working Group D. Zhang
Internet-Draft Huawei
Intended status: Experimental M. Komu
Expires: July 14, 2012 January 11, 2012
An Extension of HIP Base Exchange to Support Identity Privacy
draft-zhang-hip-privacy-protection-04
Abstract
In this document, an extension of HIP Base Exchange (BEX) is proposed
protect the identity privacy of HIP hosts. Apart from describing the
protocol and packet formats, the applicability and the security
strength of the proposed approach are analyzed. This work is based
on BLIND [YLI04].
Requirements Language
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 RFC 2119 [RFC2119].
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 July 14, 2012.
Copyright Notice
Copyright (c) 2012 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
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Zhang & Komu Expires July 14, 2012 [Page 1]
Internet-Draft HIP Privacy January 2012
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of the Protocol . . . . . . . . . . . . . . . . . . . 4
4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 4
4.1. Base Exchange Extensions . . . . . . . . . . . . . . . . . 5
4.1.1. Blind Initiator and Responder . . . . . . . . . . . . 5
4.1.2. Blind Initiator . . . . . . . . . . . . . . . . . . . 6
4.1.3. Blind Responder . . . . . . . . . . . . . . . . . . . 8
4.2. UPDATE Extensions . . . . . . . . . . . . . . . . . . . . 8
4.3. CLOSE . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Control Header Flags . . . . . . . . . . . . . . . . . . . 9
6. Applicability Consideration . . . . . . . . . . . . . . . . . 9
6.1. Opportunistic Base Exchange . . . . . . . . . . . . . . . 9
6.2. Comparison of Disposable Identities vs. Blind . . . . . . 10
6.3. HIP-based Middleboxes . . . . . . . . . . . . . . . . . . 10
6.4. Immediate Carriage and Conveyance of Upper-layer
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Zhang & Komu Expires July 14, 2012 [Page 2]
Internet-Draft HIP Privacy January 2012
1. Introduction
The Host Identity Protocol (HIP) [RFC5201] was proposed as a complete
solution to address multiple critical issues (e.g., mobility, multi-
homing, and security) which the current Internet infrastructure
suffers from. In order to achieve this objective, HIP separates the
semantics of host identifier from IP addresses by intercepting an
"ID" layer in the middle of the network layer and the transport
layer. Compared to other ID/Locator separating solutions (e.g.,
LISP, GSE, ILNP, etc.), HIP is security-inherent. Each HIP host has
a public key pair; the public key is used as the Host Identifier (HI)
transported over the Internet while the private key is maintained
locally.
Additionally, a HIP host also needs to generate a 128-bits long Host
Identity Tag (HIT) by hashing its HI. HITs are transported in the
common parts of HIP headers and regarded by upper layer protocols
(e.g., TCP) as ordinary IPv6 addresses. Before two HIP hosts
communicate with each other, they use the HIP Base Exchange protocol
(HIP BEX) to verify each other's identity and create shared keying
material for subsequent communications. Normally, the HIT and HI of
a host are much steadier than its locator (i.e., IP address).
Therefore, the changes in the location of a host will not be detected
by upper layer protocols.
In the current version of HIP BEX, the identities (i.e., HITs and
HIs) of communicating partners are transported in plaintexts. This
caused an identity privacy issue. In many scenarios, a user may want
to keep its identity confidential to other unrelated entities.
However, by eavesdropping HIP BEXs, it is possible for a third party
to identify a HIP host even when the host is attached to different
locations in the network. As a consequence, it is easier for an
attacker to combine the host's activities to reason additional useful
information.
The identity privacy issue mentioned here is closely related with the
location privacy issues. As illustrated in [RFC4882], the movement
of a mobile host can be detected if any constant information related
with the host is detected by a third party. Such information can be
a Security Parameter Index (SPI) in an IPsec [RFC4301] header, an
Interface Identifier (IID) [RFC2462] in an IPv6 address that remains
unchanged across networks, the home address of a host supporting
mobile IP, the MAC address of a mobile host, an identifier of a
mobile host adopted in a upper layer protocol, and so on. Therefore,
in order to protect the privacy of a mobile HIP host, a comprehensive
solution which cover multiple layers must be provided, and the
identity privacy is one of the most important issues which need to be
considered in such a solution. In the current HIP BEX, HIs and HITs
Zhang & Komu Expires July 14, 2012 [Page 3]
Internet-Draft HIP Privacy January 2012
are the only permanent information transported in plaintext in
different HIP BEXs. Although SPIs are also transported in plaintext,
the valid period of a SPI is no longer than the associated IPsec SA.
Therefore, without tracing the permanent identity of a host, SPIs
mean much less for attackers.
Instead of attempting to address the overall privacy problem, the
solution proposed in this document only addresses the identity
privacy issue, that is, the solution provides protection against the
attempts to track HIP hosts by inspecting the HITs and HIs
transported in HIP BEXs.
2. Terminology
BEX: Base Exchange
HIP: Host Identity Protocol
HI: Host Identifier
HIT: Host Identity Tag
3. Overview of the Protocol
The proposed solution is an extension of BLIND, a framework for
protecting the identity privacy of hosts that are identified with
their public keys. In our solution, if an initiator of a HIP base
exchange intends to protect its identity privacy, it will not
transport its HI and HIT in plaintexts over the network. Instead, it
generates a scramble HIT for itself. The scramble HIT is called a
blinded HIT in this document. If the initiator intends to protect
the identity privacy of its communicating partner, it also needs to
generate a blinded HIT for the partner as well. A blinded HIT is
generated by hashing the concatenation of a nonce and the associated
HIT.
4. Protocol Description
In order to benefit the discussion, assume there is a HIP host called
Initiator which intends to communicate with a HIP host called
Responder. The HITs of Initiator are referred to as HIT-Is, and the
HITs of Responder are referred to as HIT-Rs. Additionally, the
blinded HITs of Initiator and Responder are referred to as B-HIT-Is
and B-HIT-Rs respectively. In the discussion of this section, it is
assumed that Initiator has got a HIT-R through an out-of-band method
Zhang & Komu Expires July 14, 2012 [Page 4]
Internet-Draft HIP Privacy January 2012
before initiating a BEX. Otherwise, it needs to communicate with
Responder in an opportunistic mode. The related issues with the
opportunistic mode are discussed in section 6.1. Additionally, in
this work, Initiator and Responder do not need to know each other's
HI beforehand. Such information will be transported in the BEX in an
encrypted way.
4.1. Base Exchange Extensions
In order to distinguish the proposed approach from the ordinary BEX
protocol, two control header bits, I and R are introduced. In the
HIP packet, I indicates that the HI and HIT of the initiator of an
HIP BEX transported in the HIP header are scrambled, and R indicates
that the HI and HIT of the responder of an HIP BEX transported in the
HIP header are scrambled.
4.1.1. Blind Initiator and Responder
In the scenarios where the identity privacy of both communicating
partners needs to be protected, Initiator needs to generate a blind
HIT (i.e., B-HIT-I) for itself and a blind HIT (i.e., B-HIT-R) for
Responder before initiating a BEX.
In order to achieve this, Initiator first selects a random number
nonce, N. Then, Initiator generates a B-HIT-I by SHA-1 hashing the
concatenation of N and HIT-I, that is, B-HIT-I=SHA-1(N, HIT-I). In
the same way, Initiator generates a B-HIT-R for Responder. B-HIT-
R=SHA-1(N, HIT-R).
An extended BEX handshake is illustrated in Figure 1. In the I1
packet transported in the step 1, the blinded HITs of Initiator and
Responder, and the nonce, N, are transported in plaintexts.
After receiving the I1 packet, Responder needs to calculate an SHA-1
hash value from the concatenation of N and HIT-R, and compare it with
the B-HIT-R transported in the I1 packet. Note that if the Responder
has multiple HITs, this process may need to be performed repeatedly.
If there is no hash identical to the B-HIT-R, I1 packet will be
discarded. If a hash value matches the B-HIT-R, Responder sends a
pre-generated R1 packet of the associated HI to Initiator (see step 2
in Figure 1). In order to avoid Deny of Service attacks, Responder
should not maintain any state information at this step. However, in
practice, although it is not recommended, Responder can also select
to maintain the mapping from the pseudonym and the associated HI in
order to simplify the process of the I2 packet.
If Initiator has already got the HI of Responder, it can use the HI
to assess the validity of the signature of the R1 packet. Otherwise,
Zhang & Komu Expires July 14, 2012 [Page 5]
Internet-Draft HIP Privacy January 2012
Initiator cannot verify the signature of the R1 packet until it gains
the HI from the R2 packet. No matter whether Initiator can assess
the signature, Initiator generates a symmetric key, KDH, using the
Diffie-Hellman algorithm and adopts the key to calculate the keying
material with the HIT-R and B-HIT-I:
Key1=SHA1 (KDH, HIT-R, B-HIT-I, 1), ...
Keyn=SHA1 (KDH, HIT-R, B-HIT-I, n),
Keying material=Key1 XOR ... XOR Keyn.
The keying material is then used to generate a symmetric key to
encrypt the HI of Initiator. The encrypted information is sent to
Responder in an I2 packet (see step 3). Additionally, the I2 packet
also contains the nonce which was transported in I1 and the pseudonym
which was transported in R1. After receiving the I2 packet,
Responder computes a key in the same way as the Initiator. Using the
key, Responder decrypts the HIT and HI information of Initiator, and
verifies the correctness of B-HIT-I. Moreover, Responder encrypts
its HI using the obtained symmetric key and transports the encrypted
HI to Initiator in a R2 packet (see step 4). After Initiator
receives the R2 packets, it decrypts the Responder's HI. If
Initiator does not know the HI of Responder, Initiator can assess its
correctness against HIT-R and then verify the validity of the R1
packet.
Finally, the whole BEX handshake completes successfully. In the
packets transported in the exchange, both R and S are set.
+-----+ +------+
| | 1. I1: B-HIT-I, B-HIT-R, Nonce | |
| |------------------------------------------------------>| |
| | 2. R1: B-HIT-I, B-HIT-R, puzzle, DH(r), Echo-REQ, Sig.| |
| |<------------------------------------------------------| |
| I |3. I2: B-HIT-I, B-HIT-R, Nonce, DH(i), Puzzle Solution,| R |
| | SPI Encrypt { HI-I}, RESP, Signature | |
| |------------------------------------------------------>| |
| |4. R2: B-HIT-I, B-HIT-R, Encrypt {HI-R}, | |
| | SPI, HMAC, Sig. | |
| |<------------------------------------------------------| |
+-----+ +------+
Figure 1. An Extended HIP Base Exchange
4.1.2. Blind Initiator
In the many circumstances, only the identity privacy of Initiator
needs to be protected. For instance, a client may want to keep its
identity untraceable to any third party while the server which the
Zhang & Komu Expires July 14, 2012 [Page 6]
Internet-Draft HIP Privacy January 2012
client tries to communicate with intends to eliminate the overhead
introduced by encrypting its HIT and HI. In this case, the client
only needs to generate a blind HIT for itself before initiating a
BEX. The process of generating B-HIT-I is as same as what is
illustrated in section 4.1.1. Then Initiator sends an I1 packet to
Responder (see step 1 in Figure 2). The packet consists of B-HIT-I,
the actual HIT of Responder (HIT-R), and the nonce used in generating
B-HIT-I. After receiving I1, Responder sends back Initiator a R1
packet (see step 2). The process of generating the R1 packet is
identical to the ordinary BEX. Upon receiving R1, Initiator verifies
the validity of R1 and calculates the keying material in the same way
illustrated in section 4.1.1. In addition, Initiator encrypts its HI
using a key derived from the keying material and transports the
encrypted information in I2 (see step 3). Therefore, after receiving
I2, Responder can compute a symmetric key to verify the correctness
of B-HIT-I. The symmetric key is also used to calculate the HMAC of
the R2 packet. Therefore, by verifying the HMAC of R2, Initiator can
prove that Responder has shared a symmetric key with it. In this
exchange, only the control flag I is set.
+-----+ +------+
| |1. I1: B-HIT-I, HIT-R, Nonce | |
| |---------------------------------------------------->| |
| |2. R1: B-HIT-I, HIT-R, puzzle, DH(r), HI-R, Echo-REQ | |
| | Sig. | |
| |<----------------------------------------------------| |
| I |3. I2: B-HIT-I, HIT-R, Nonce, DH(i), Puzzle Solution,| R |
| | SPI, Encrypt {HIT-I, HI-I}, HI-R, RESP, Signature | |
| |---------------------------------------------------->| |
| |4. R2: B-HIT-I, HIT-R, SPI, HMAC, Sig. | |
| |<--------------------------------------------------- | |
+-----+ +------+
Figure 2. An Extended HIP Base Exchange
Typically, an Initiator can decide whether to protect its identity
privacy according to its local policy. Before initiating a HIP
exchange, the Initiator can also attempt to learn whether the
responder intends to protect its identity privacy (e.g., from
resolution systems or referrers). However, if there is no trustable
method for an initiator to learn the privacy protecting policies of
its communicating partner in advance, the initiator should carry out
BEX in the way described in section 4.1.1. Otherwise, if the
initiator uncovers the HIT or HI of Responder in I1, there is no
opportunity left for the responder to decide whether to protect its
identity privacy. When receiving such an I1 packet, the responder
can select to 1) drop the packet directly if it does not support the
extended HIP BEX, 2) carry out the handshake with the initiator in
the way illustrated in the above section if it supports the extended
Zhang & Komu Expires July 14, 2012 [Page 7]
Internet-Draft HIP Privacy January 2012
HIP BEX and prefers to protect its identity privacy, or 3) send a
notify back if it supports the extended HIP BEX and does not intend
to protect its identity privacy. In the third case, the notify
packet is used to illustrate its identity privacy protecting
policies. In the notify packet, the responder can proactively
disclose its HIT. Therefore, after receiving the notify packet, the
initiator can decide whether to restart a new HIP BEX.
4.1.3. Blind Responder
In the circumstance where an initiator which does not intend to
protect its identity privacy attempts to contact another host which
intends to protect its identity privacy, the initiator can only
scramble the HIT of the responder and transport its own HIT in
plaintext.
Figure 3 illustrates such a HIP BEX between Initiator and Responder.
In the first step, Initiator sends HIT-I, B-HIT-R, and the nonce used
to generate B-HIT-R in R1 to Responder. After receiving I1,
Responder tries to find out the associated HI using the method
indicated in section 4.1.1. If the HI is found, Responder then sends
a pre-generated R1 packet of the associated HI back to Initiator (see
step 2). In R1, B-HIT-R is encapsulated. After calculating the
puzzle, Initiator sends an I2 packet back to Responder (see step 3).
In step 4, responder sends its HI in the encapsulated part of R2
packet to Initiator.
+-----+ +------+
| |1. I1: HIT-I, B-HIT-R, Nonce | |
| |---------------------------------------------------->| |
| |2. R1: HIT-I, B-HIT-R, puzzle, DH(r), Echo-REQ | |
| | Sig. | |
| |<----------------------------------------------------| |
| I |3. I2: HIT-I, B-HIT-R, Nonce, DH(i), Puzzle Solution,| R |
| | SPI, HI-I, RESP, Signature | |
| |---------------------------------------------------->| |
| |4. R2: HIT-I, B-HIT-R, Encrypt {HI-R}, SPI, HMAC, | |
| | Sig. | |
| |<--------------------------------------------------- | |
+-----+ +------+
Figure 3. An Extended HIP Base Exchange
4.2. UPDATE Extensions
After two hosts achieve a HIP BEX, they may also need to change their
SPIs or HITs for certain reasons. Such information can be
transported in update packets. Because the confidentiality of SPIs
and HITs needs to be protected, such information should be
Zhang & Komu Expires July 14, 2012 [Page 8]
Internet-Draft HIP Privacy January 2012
transported in an encrypted way.
Additionally, according to different security requirement, the hosts
changing its IP address also needs to select a new nonce to generate
new scramble HIT(s). The nonce and scrambled are used in the HIP
header. The associated flags are set as well. For instance, if the
identity privacy of both communicating parties needs to be protected,
a new pair of scramble HITs need to be generated. The new pair of
scrambled HITs and the nonce are transported within the packet
header. After receiving the packet, the receiver needs to first find
out the associate private HITs and then locate the proper keys to
verify the signature and decrypt the SPIs.
4.3. CLOSE
When an existing HIP association is no longer needed, it can be
closed using closing mechanism defined in [RFC5201].
5. Packet Formats
5.1. Control Header Flags
In order to distinguish the packets in extended BEX from those in
ordinary BEX, two control header flags are defined here:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | |I|R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I: if this bit is set to 1, the initiator's HIT transported in the
packet is scrambled, and the HI in this packet is encrypted.
Otherwise, the initiator's HIT and HI are transported within the
common part of the packet header in an unencrypted way.
R: if this bit is set to 1, the responder's HIT transported in the
packet is scrambled, and the HI in this packet is encrypted.
Otherwise, the responder's HIT and HI are transported without
encryption. Note that in opportunistic mode, this flag in an I1
packet only indicate the initiator support scrambled HITs.
6. Applicability Consideration
6.1. Opportunistic Base Exchange
When an Initiator does not know the HIT of its communicating partner
beforehand, it can try to initiate the handshaking in the
opportunistic mode.
Zhang & Komu Expires July 14, 2012 [Page 9]
Internet-Draft HIP Privacy January 2012
If the initiator intends to protect its identity privacy, it can send
its blind HIT and the associated nonce in an I1 packet to the
responder. Both the I and R flag in the I1 packet are set. If the
responder would like to protect its identity privacy, it can use the
nonce to generate a blind HIT and send it back in a R1 packet. The
operations of both communicating partner in the rest of the
handshaking is identical to what is described in section 4.1.1. If
the initiator does not want to protect its identity privacy, it can
send its plain HIT in an I1 packet to the responder. The R flag in
the I1 packet can be set to indicate that the initiator supports
scrambled HITs. If the responder would like to protect its identity
privacy, it can choose a nonce and use it to generate a blind HIT for
itself. Both the blind HIT and the nonce are sent back in a R1
packet. The operations of both communicating partner in the rest of
the handshaking is identical to what is described in section 4.1.3.
In the both cases above, if the responder supports scrambled HITs but
does not want to protect its identity privacy, it can just send its
plain HIT in the R1 packet and unset the R flag.
6.2. Comparison of Disposable Identities vs. Blind
During the design of the proposed approach, the solutions using
ephemeral identities are also considered. A host can attempt to
prevent itself from being tracked by using different HIs in different
BEXs. However, some upper layer server applications may use HIs or
HITs to identify hosts. When a host uses ephemeral HI, it may be
difficult for the applications to find proper state to provide
service correctly.
Additionally, it is difficult for a responder to use ephemeral HI to
protect its identity, as the initiator normally need to know the
responder's HIT to initiate a HIP BEX.
6.3. HIP-based Middleboxes
Currently, there is only a type of middlebox (RVS) specified in the
HIP architecture. Our solution introduces additional overheads to a
RVS but will not damage its functionality. When a RVS received an I1
packet containing a blind HIT of the responder, the RVS has to use
the nonce to find out the associated HIT. Considering the large
number of the HITs that a RVS may hold, an Initiator can select to
disclose some bites of the plain HIT of the responder to reduce the
overhead imposed on the RVS.
Zhang & Komu Expires July 14, 2012 [Page 10]
Internet-Draft HIP Privacy January 2012
6.4. Immediate Carriage and Conveyance of Upper-layer Protocol
If a host receives a hiccups based packet, it must respond with an R1
as described in [I-D.nikander-hip-hiccups].
7. Security Considerations
Our solution should be a component of a multi-layer privacy
protection solution. Although the confidentiality of consistent
information transported in higher layer protocol can be protected by
the key derived from HIP BEX, one still have to carefully avoid the
consistent information transported below HIP layer to be disclosed to
adversaries. For instance, an attacker may identify the FQDN of a
host by querying the reverse DNS system with the IP address of the
host.
In addition, our privacy extension may be incompatible with HIP based
firewalls [RFC5207], relay servers [RFC5770], and other
authentication service provided by middle boxes
[I-D.heer-hip-middle-auth].
8. Contributors
This work is based on the research of Jukka Ylitalo.
9. Acknowledgements
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4882] Koodli, R., "IP Address Location Privacy and Mobile IPv6:
Problem Statement", RFC 4882, May 2007.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
Zhang & Komu Expires July 14, 2012 [Page 11]
Internet-Draft HIP Privacy January 2012
"Host Identity Protocol", RFC 5201, April 2008.
10.2. Informative References
[I-D.heer-hip-middle-auth]
Hummen, R., Heer, T., and M. Komu, "End-Host
Authentication for HIP Middleboxes",
draft-heer-hip-middle-auth-04 (work in progress),
October 2011.
[I-D.nikander-hip-hiccups]
Nikander, P., Camarillo, G., and J. Melen, "HIP (Host
Identity Protocol) Immediate Carriage and Conveyance of
Upper- layer Protocol Signaling (HICCUPS)",
draft-nikander-hip-hiccups-04 (work in progress),
August 2009.
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
Firewall Traversal Issues of Host Identity Protocol (HIP)
Communication", RFC 5207, April 2008.
[RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A.
Keranen, "Basic Host Identity Protocol (HIP) Extensions
for Traversal of Network Address Translators", RFC 5770,
April 2010.
[YLI04] Ylitalo, J., "LIND: A Complete Identity Protection
Framework for End-points", April 2004.
Authors' Addresses
Dacheng Zhang
Huawei
Email: zhangdacheng@huawei.com
Miika Komu
Laboratory of Software Technology
Department of Computer Science and Engineering, Aalto University
Finland
Email: miika@iki.fi
Zhang & Komu Expires July 14, 2012 [Page 12]