Network working group                                     Dacheng Zhang
 Internet Draft                              Huawei Technologies Co.,Ltd
 Category: Informational                                 Dmitriy Kuptsov
 Created: May 29, 2010    Helsinki Institute for Information Technology
 Expires: November 2010                                        Sean Shen

                     Host Identifier Revocation in HIP

 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), its areas, and its working groups. Note that
    other groups may also distribute working documents as Internet-

    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

    The list of Internet-Draft Shadow Directories can be accessed at

    This Internet-Draft will expire on November, 2010.

 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
    Provisions Relating to IETF Documents
    ( 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.

 Zhang  Kuptsov and Shen. Expires November 29, 2010             [Page 1]

 Internet-Draft    Host Identifier Revocation in HIP            May 2010


    This document mainly analyzes the key revocation issue with host
    identities (HIs) in the Host Identity Protocol (HIP). Generally, key
    revocation is an important functionality of key management systems;
    it is concerned with the issues of removing antique cryptographic
    keys from operational usages when they are not secure or not secure
    enough any more. This functionality is particularly important for
    the security systems expected to execute for long periods. This
    document also attempts to investigate several key issues that a
    designer of HI revocation mechanisms need to carefully consider.

 Conventions used in this document

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    document are to be interpreted as described in RFC-2119 [RFC2119].

 Table of Contents

    1. Introduction...................................................2
    2. Terminologies..................................................3
    3. Key Management.................................................3
    4. Key Revocation.................................................4
       4.1. Revocation of Transient and Permanent Keys................4
       4.2. Classification of permanent Key Revocation Mechanisms.....5
    5. Implicit HI Revocation in HIP..................................7
    6. Explicit HI Revocation........................................12
    7. Related Discussions...........................................14
       7.1. Influence of HI revocation on Already Generated HIP
       7.2. HI Refreshment...........................................14
    8. Conclusions...................................................16
    9. IANA Considerations...........................................16
    10. Acknowledgments..............................................16
    11. References...................................................16
       11.1. Normative References....................................16
       11.2. Informative References..................................17
    Authors' Addresses...............................................17

 1. Introduction

    In a HIP architecture [RFC5201], a HIP host needs to generate a
    "permanent" public key pair before it communicates with other HIP
    hosts. The public key is used as its HI while the private key is

 Zhang  Kuptsov  and Shen. Expires November 29, 2010           [Page 2]

 Internet-Draft    Host Identifier Revocation in HIP            May 2010

    kept securely by the host. When two HIP hosts attempt to initiate a
    communication (e.g., a TCP session), they can take advantage of
    their HI key pairs to perform mutual authentication and distribute
    keying materials for securing subsequent data and signaling packets.
    Therefore, the security of HIP architectures largely relies on the
    security of those HI key pairs. If the HI key pair of a HIP host is
    revealed, an attacker can easily impersonate the victim to carry out
    malicious attacks without being detected.

    It has been widely recognized that a cryptographic key (which can be
    either a symmetric key or a public key) should have a reasonable
    valid period [Recommendations]. After having been employed for a
    certain period, a cryptographic key will be in more dangers of
    compromise. As time elapses, an attacker can collect more materials
    (e.g., encrypted data, signatures and associated plain texts, etc.)
    and obtain more time to compromise the key. In addition, unexpected
    key disclosure is a common practical issue, which may be caused by,
    e.g., improper key management policies or hardware stealing.
    Consequently, in the design of a security system which is expected
    to execute for a long period, the issues with revoking the
    cryptographic keys which do not have enough security strengths must
    be considered.

    In current HIP architectures, the key revocation issues with
    transient (session) keys have been well discussed. HIP allows two
    communicating hosts to update their transient keys securely at run
    time. However, the key revocation issues with permanent keys (i.e.,
    HIs) have not been well explored yet. No facility is provided for HI
    revocation either.

 2. Terminologies

    BEX: Base Exchange

    HIP: Host Identity Protocol

    PKI: Public Key Infrastructure

 3. Key Management

    Key management aims at guaranteeing the security of cryptographic
    keys during the period of their application and includes all of the
    provisions made in a security system design which are related to
    generation, validation, exchange, storage, safeguard, application,
    and replacement of cryptographic keys. Appropriate key management is
    critical to security mechanisms providing confidentiality, entity

 Zhang  Kuptsov  and Shen. Expires November 29, 2010           [Page 3]

 Internet-Draft    Host Identifier Revocation in HIP            May 2010

    authentication, data origin authentication, data integrity, and
    digital signatures. Specifically, a full-fledged key management
    system should be able to support [Menezes et al. 1996]:

     1. Initialization of system users within a domain;

     2. Generation, distribution, and installation of keying material;

     3. Controlling the use of keying material;

     4. Update, revocation, and destruction of keying material; and

     5. Storage, backup/recovery, and archival of keying material.

 4. Key Revocation

    Key revocation is an essential functionality of a security system.
    By refreshing antique cryptographic keys, a security system can
    reduce the dangers of being compromised. Key revocation is also an
    important step when a security system attempts to confine and
    recover from the damages caused by attacks. The criteria measuring a
    key revocation mechanism should include security, efficiency,
    latency, overheads in terms of communication, and etc.

4.1. Revocation of Transient and Permanent Keys

    Cryptographic keys adopted in a security system can be classified
    into permanent keys and transient keys according to their life
    periods. As indicated by the name, permanent keys are maintained by
    holders for relatively long periods which can be various from months
    to years. Because frequent usages of permanent keys can damage their
    security strength and reduce their valid periods, in many security
    mechanisms, permanent keys are employed to generate and distribute
    transient keys which are only valid in relatively short periods
    (e.g., within a single TCP session). Key revocation issues with
    transient keys have been taken account of in most authentication
    mechanisms (e.g., Kerberos, IPSec, SSL, etc.). For instance, in
    Kerberos, a user can use her password to obtain a session key from a
    KDC; the session key then can be further used to securely discard
    and update antique sub-session keys. The revocation of transient
    keys is also considered in the design of HIP. A basic handshaking
    protocol (i.e., the HIP Base Exchange) has been proposed. Using it,
    two communicating HIP hosts can employ the authenticated Diffie-
    Hellman algorithm to securely distribute keying materials which will
    be used to generate new cryptographic keys in the following
    communications. After a handshake, the hosts are able to refresh

 Zhang  Kuptsov  and Shen. Expires November 29, 2010           [Page 4]

 Internet-Draft    Host Identifier Revocation in HIP            May 2010

    their transient keys and the corresponding HIP associations, using
    Update packets.

    The revocation issues with permanent keys are also taken into
    account in lots of key management mechanisms (e.g., PGP, PKI, Peer-
    to-Peer Key Management for Mobile Ad Hoc Networks [Merwe et al.
    2007]). Particularly, in PKI, key revocation issues are addressed in
    certificate revocation mechanisms.

4.2. Classification of permanent Key Revocation Mechanisms

    This draft focuses on the issues with permanent key revocation in
    HIP. In the remainder of this draft, key revocation indicates
    permanent key revocation, without mentioned otherwise.

    Mechanisms for key revocation can be classified in different ways,
    according to:

       Whether additional operations are needed. If a key revocation
       mechanism does not need any additional operation in the revoking
       process of a cryptographic key, it is called an implicit key
       revocation mechanism. The basic idea of an implicit HI revocation
       mechanism is to associate a key with a valid period and use
       cryptographic methods to prove the binding between the key and
       its valid period. Therefore, after the pre-defined period expires,
       the key is obsolete automatically. For instance, in PKI, a
       Certificate Authority (CA) can issue a certificate for a user in
       order to assert the association between the user and its public
       key. The certificate is associated with a life period. When the
       period expires, the user's public key is revoked automatically.
       If a key revocation mechanism needs to carry out additional
       operations (e.g., notifications) to revoke a cryptographic key,
       it is called an explicit key revocation mechanism. In different
       explicit key revocation mechanisms, such operations can be
       performed either by a dedicated server or by the owner of the key.
       Compared with implicit key revocation mechanisms, an explicit key
       revocation mechanism has the capability to revoke a cryptographic
       key before its life period expires. For instance, in X.509
       [RFC2459] based systems, an issuer can generate a list of
       certificates, which were revoked for some reasons before their
       expiring dates, for users to consult.

       Whether a secure third party is needed. In some revocation
       mechanisms, the status information of a cryptographic key is
       provided by a secure third party. A proof of validity is
       performed during each request from users, and the secure third

 Zhang  Kuptsov  and Shen. Expires November 29, 2010           [Page 5]

 Internet-Draft    Host Identifier Revocation in HIP            May 2010

       party provides up-to-date information. Online Certificate Status
       Protocol (OCSP) for X.509 certificate is such a mechanism. An
       OSPF client generates an OCSP request that primary contains the
       information of one or more queried certificates and send it to a
       trusted OCSP server. After receiving the OCSP request, the server
       creates an OCSP response containing the updated status
       information of the queried certificates. In some other revocation
       mechanism, validity information is distributed to the requester
       by a non-secured server. For example, in PGP, a principal can use
       its revoked key to sign a key revocation certificate and uploaded
       it to a key repository server. The server is regarded as "non-
       secured" only because the server only provides a repository
       service and does not make any assertion. Certificates themselves
       are individually secured by the signatures thereon, and need not
       be transferred over secured channels. In fact, authorization
       policies to a repository server in the form of write and delete
       protection is mandatory so as to enable maintenance and update
       without denial of service

       The list is adopted. According to the information provided, key
       revocation mechanisms can be classified into black list
       mechanisms and white list mechanisms. A black list mechanism can
       provide the information of the keys which are not valid anymore.
       The Certificate Revocation List (CRL) is an example of this kind
       of mechanism. In a CRL, revoked certificates are listed in a
       signed list, so that users can query the information about the
       revoked keys whenever it is convenient. White list mechanisms,
       instead, only provide information of valid keys. For example, SSH
       specify a kind of resource record (RR) called SSHFP [RFC4255]. A
       SSHFP RR contains the information of the fingerprint of a valid
       cryptographic key. If a key needs to be revoked, the associated
       SSHFP RR is removed. If a user cannot find the associated SSHFP
       RR from DNS, she will believe that the key inquired about is no
       longer valid.

       The way of distributing revocation information. In a key
       revocation mechanism applying the push model, upon a key is
       revoked, a server proactively contacts the related users to
       inform the case. In contrast, in a key revocation mechanism
       applying the pull model, a client needs to query a server for
       particular revocation information. OCSP, CRL, and the key
       revocation mechanisms adopted in PGP and SSH all belong to this

    There are few discussions about the HI revocation issues with HIP.
    In the current HIP architecture, hosts are allowed to update their

 Zhang  Kuptsov  and Shen. Expires November 29, 2010           [Page 6]

 Internet-Draft    Host Identifier Revocation in HIP            May 2010

    identifiers arbitrarily without notifying others. The lack of HI
    revocation mechanism can be taken advantage of by attackers to, for
    instance, escape tracking, bypass ACLs (Access Control Lists),
    impersonate others using the compromised HIs, etc. In remainder of
    this document, candidate approaches and related issues are discussed.

 5. Implicit HI Revocation in HIP

    Implicit key revocation is the simplest key revocation approach. By
    associating an HI with a life period, the holder of the HI needs to
    update the HI periodically so as to reduce the risk that the HI is
    compromised. In addition, life periods of HIs can help users to
    verify how long an HI has been used and how long the HI will still
    be valid. This is enable host managers to define more specific
    security policies.

    Note that the HI and the HIT of a host are cryptographic associated.
    A revocation of an HI will cause the revocation of the correspondent
    HIT, and vice versa. Therefore, without losing generality, in this
    document we assume that the life periods of an HI and its HIT are
    identical and they are generated and revoked concurrently in a same

    The life period of an HI can be specified either by the holder of
    the HI or by a trusted authority. During HIP BEXs, such life period
    information can be encapsulated in parameters and transported within
    HIP packets. If the life period of the HI is specified by its holder,
    the holder needs to use the associated private key to sign the
    parameter. If the life period of the HI is specified by a trusted
    authority, the authority needs to use its private key to sign a life
    period certificate for the HI. The certificate can be encapsulated
    within a CERT parameter and transported in HIP packets.

    Figure 1 illustrates an extended HOST_ID parameter which is able to
    transport an HI and the associated life period. This parameter can
    be adopted in the cases where the life period of the HI is specified
    by its holder. Similar with the live periods of X.509 certificates,
    the life period of an HI is specified by a Not Before Time and a Not
    After Time. In this parameter, the NB Length and NA Length fields
    indicate the lengths of Not Before Time and Not After Time fields
    respectively. The Not-Before-Time and the Not-After-Time can be in a
    format of either UTCTime or GeneralizedTime defined in [RFC2459].

    During a HIP base exchange, the parameter containing Initiator's HI
    and the associated life period information is transported in the I2

 Zhang  Kuptsov  and Shen. Expires November 29, 2010           [Page 7]

 Internet-Draft    Host Identifier Revocation in HIP            May 2010

    packet, while the parameter containing Responder's HI and the
    associated life period information is transported in the R1 packet.

    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             |


    |             HI Length         |DI-type|     DI Length         |


    |             NB Length         |           NA Length           |


    |                               Host Identity                   /


    /               |              Domain Identifier                /


    /                               |          Not Before Time      /


    /                               |          Not After Time       /


    /                             |          Padding                |


                 Figure 1 An extension of HOST_ID parameter

    The approach to enabling a holder to specify the life period of its
    HI does not rely on any trusted third party and introduces little
    performance penalty in verifying the life period. However, a concern

 Zhang  Kuptsov  and Shen. Expires November 29, 2010           [Page 8]

 Internet-Draft    Host Identifier Revocation in HIP            May 2010

    about this approach is how to ensure that HIP hosts will
    appropriately define and manage the life periods of their HIs. In
    practice, the revocation and refreshment of an HI can be quite
    complex. Apart from updating the key material locally, additional
    operations also need to be performed (e.g., updating the associated
    HIP resource record in DNS, proactively informing the partners which
    may be affected by the revocation, etc.). Therefore, a lazy manager
    of a HIP host may attempt to avoid refreshing the HI and HIT of her
    host. If the manager assigns an extremely long life period for its
    HI, other HIP hosts can easily detect the problem and refuse to
    communicate with the host. However, if the manager selects to assign
    a new life period with a reasonable length for her HI whenever the
    old life period has expired, the renewal of the life period can be
    difficult to be detected in current HIP architectures. For instance,
    in practice a HIP host normally does not maintain the HIs and other
    related information of its communicating partners for a long period,
    in order to reduce memory consumption and foil deny-of-service
    attacks. Moreover, because HITs are treated by applications as
    ordinary IP addresses which have no expire date, In referral
    scenarios the receiver of a HIT may not be able to obtain the
    knowledge of the life period of a HIT from the referrer. In the
    current HIP resolution solutions (e.g., HIP RR), there is no concern
    about the life periods of HIs. On such occasions, a host can only
    obtain the life period information from its communicating partner
    (i.e., the holder of the HI). Therefore, in current HIP
    architectures, the approach which allows a holder to specify the
    life period of its HI can only be feasible in the environments where
    there has already been a certain level of trust between two HIP
    hosts beforehand, that is, a HIP host can believe its communicating
    partner has specified an appropriate life period for its HI and will
    only attempt to use it within the valid period.

    The issues mentioned above can be largely addressed by assigning a
    trusted authority to manage the life periods of HIs. However, a
    dedicated trust third party may introduce complexity into the
    current HIP architecture, impose additional communications (e.g.,
    registration process, generation of certificate chain, etc.), and
    cause issues in terms of scalability and trust. The details of the
    issues imposed by such dedicated authorities are discussed in
    section 6.

    In the remainder of this sub-section, we introduce two complementary
    approaches to mitigating the issues of arbitrarily modifying HI life
    periods while imposing little performance penalty to HIP hosts.

 Zhang  Kuptsov  and Shen. Expires November 29, 2010           [Page 9]

 Internet-Draft    Host Identifier Revocation in HIP            May 2010

    The first approach is to extend resolution systems (e.g., DNS
    servers) to provide trustable life-period information of HIs. In
    this approach, the life-period information can be encapsulated in
    the same packet with other mapping information and sent back to
    users so as to eliminate addition communicating overheads between
    users and resolutions systems.

    In order to achieve this, spaces for the life period information
    needs to be allocated in the resource records sent back to users. In
    Figure 2, an extension of the HIP RR with life period information is
    illustrated. Same as the extended HOST_ID parameter in Figure 1, the
    NB Length and NA Length fields indicate the lengths of Not Before
    Time and Not After Time fields respectively. The Not-Before-Time and
    the Not-After-Time can be in a format of either UTCTime or
    GeneralizedTime defined in [RFC2459].

    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


    | HIT Length    |  PK algorithm |           PK Length           |


    |            NB Length          |          NA Length           |


    |                              HIT                              /


    /                               |        Public Key             /


    /                               |     Rendezvous Server         /


    /                               |       Not Before Time         /


 Zhang  Kuptsov  and Shen. Expires November 29, 2010          [Page 10]

 Internet-Draft    Host Identifier Revocation in HIP            May 2010

    /                               |       Not After Time          /


    /       |


                      Figure 2 An Extension of HIP RR

    The basic functionality of a resolution server is to provide mapping
    information for users. In practice, it is normally the
    responsibility of authorized users to maintain and update the
    contents of RRs while resolution severs can verify the contents of
    RRs against certain security policies. Therefore, in this approach,
    information of the life period of an HI, just like the other
    information in the RR, can be provided by an authorized user at the
    registration time. After the registration, the life period
    information is only allowed to be updated by the ones who have
    higher privileges (e.g., server managers).

    Let us use DNS servers as an example. After a user uploads the
    information of a HIP host in an authoritative DNS server, the user
    is not allowed to modify the Not Before Time and Not After Time
    fields of the HI any more. Moreover, after the life period of the HI
    has expired, the associated RRs needs to be removed.

    Until now, the ID to Locator mapping solutions in HIP has not been
    standardized yet. We argue that it is desired to integrate the
    implicit key revocation functionality into such systems.

    The second approach is to introduce the life periods of HIs into the
    generating process of HITs. For instance, the life period of an HI
    can be used as a part of the input for generating the associated HIT.
    This approach makes it computational difficult for the holder of an
    HI to modify the life period without modifying the associated HIT.
    Therefore, after a host advertises its contacting information in
    resolution servers, any attempts to modify the life period of the HI
    can be easily detected. For instance, in the case a host obtains a
    HIT from its referrer. It needs to first obtain the knowledge to
    access the host holding the HIT from resolution servers. Then it can
    get the associated HI and the life period from the HIT holder, and
    re-calculate the HIT to verify whether the life period of the HIT is
    valid. This approach needs little modification on the resolution
    servers and can be applied independently. A disadvantage of this

 Zhang  Kuptsov  and Shen. Expires November 29, 2010          [Page 11]

 Internet-Draft    Host Identifier Revocation in HIP            May 2010

    approach is its inflexibility in the cases where the life periods of
    HIs need to be extended.

 6. Explicit HI Revocation

    As mentioned previously, in many typical scenarios a cryptographic
    key should not be used any more even when it is still in its valid
    life period. For instance, when a key is detected to be compromised,
    it must to be revoked immediately even if it has not reached its
    expiration date. In such a case, explicit key revocation is needed.

    When an HI needs to be removed from operational use prior to its
    originally scheduled expiry, the revocation of the HI needs to be
    informed to all the hosts which might be affected. If there is no
    dedicated third party to rely on, the holder of the HI needs to
    deliver the revocation certificate signed by the associated private
    key to all the affected partners. The poor scalability of this
    solution is always a subject of debates. First of all, this solution
    requires the holder an HI to maintain a long list of information
    about the partner which may be affected by the revocation; this job
    can be onerous and error prone. In addition, because HIP does not
    support multicast, the holder has to generate a notification packet
    for each of its partners, and send them out during the revocation.
    When the number of related partners increases, the holder may have
    to spend a large amount of bandwidth, memory and computing resources
    in generating and delivering the notification packets. In order to
    improve the performance of this solution, the holder can send the
    certificate to a limited set of partners. These partners then relay
    the certificate to others. However, this solution may introduce
    additional latency and make the delivery of the certificate un-
    reliable. Besides the above issues, this solution requires all the
    involved partners to be online during an HI revocation process,
    which can be hardly fulfilled on many occasions. Basically, this
    solution is only suitable in the circumstances where the number of
    involved hosts is relatively small and stable.

    The experiences in PKI demonstrate that pull models can be more
    scalable in dealing with a large amount of users, and as a result,
    most of the certification revocation mechanisms (e.g., Certification
    Revocation Lists (CRLs) and the On-Line Certificate Status Protocol
    (OCSP)) proposed in PKI are based on pull models. In these
    mechanisms, the revocation information is maintained in a third
    party for users to query whenever it is convenient.

    PKI has provided a set of certificate management mechanisms. On many
    occasions, it is feasible for HIP to take advantage of PKI style

 Zhang  Kuptsov  and Shen. Expires November 29, 2010          [Page 12]

 Internet-Draft    Host Identifier Revocation in HIP            May 2010

    solutions to address the issues with HI management. However, it
    should be realized that PKI oriented solutions are not silver
    bullets and cannot be utilized to address all the issues that HIP
    has to encounter. After HIP has been globally deployed, it is
    expected that there will be billions of HIP users which may belong
    to different organizations and attach to the Internet through
    different ISPs. Due to the poor scalability of PKI and lack of trust,
    it is extremely difficult (if possible) to put such a big amount of
    geographically distributed users under the control of a unique PKI
    security domain. Therefore, it is reasonable to assume that there
    will be many different security domains all over the world. When two
    HIP hosts belong to two different security domains, it may be
    difficult for a host to verify the assertion made by the security
    server in the domain of the other one. Although there have been
    solutions of generating trust relationship across various security
    domains, all of them impose additional overheads with respect to the
    construction and verification of credential chains, communications
    with remote security servers, which negatively influences the
    performance of HIP. Therefore, the HIP community argues that two
    HIP-aware hosts should be able to communicate without any additional
    security facilities. Actually, the only third party server
    introduced in the base-line HIP architecture is the Rendezvous
    Server (RVS)[RFC5204]. A RVS only relays messages for the hosts
    which attempts to communicate with mobile hosts and provides little
    security functionality. The HIP hosts intending to communicate with
    each other still need to use the HIP Base Exchange protocol to carry
    out authentication and exchange keying material for future

    Again, resolution servers can be potentially adopted to construct a
    global explicit HI revocation mechanism applying a pull model. For
    instance, when a host intends to revoke its HI, it can send a
    revocation certificate signed by its private key to an authoritative
    DNS server. After receiving the certificate, the correspondent RR
    will be removed, and thus users will not obtain the information
    about the revoked HI any more. Therefore, DNS servers can perform as
    a white list HI revocation mechanism, just similar with what
    specified in SSH. To avoid the long delay in the spread of
    revocation information caused by caching RRs on DNS resolvers, the
    TTL (Time To Life) of RRs can be set to zero.

 Zhang  Kuptsov  and Shen. Expires November 29, 2010          [Page 13]

 Internet-Draft    Host Identifier Revocation in HIP            May 2010

 7. Related Discussions

7.1. Influence of HI Revocation on Already Generated HIP Associations

    In this sub-section, we investigate the possibility of using already
    generated HIP associations to transport the update information after
    the correspondent HI key pair is no longer valid.

    In a BEX, HI key pairs of the both communicating partners are used
    to carry out mutual authentication while the key materials for
    securing subsequent communication are generated by the Diffie-
    Hellman algorithm. Therefore, if an HI key pair is secure at the
    time when a HIP association is generated, the later revocation of
    the HI key pair will not affect the security of the keying materials.
    Assume there is an attacker which has compromised the HI key pair.
    It is still computational difficult for the attacker to decrypt the
    packets transported between the communicating partners. Because the
    Update packets are under the protection of HMAC, the attacker cannot
    forge them to interfere with the communications. Note that the
    attacker can try to forge Notify packets. However, according to [RFC
    5201] Notify packets are only informative, which will not affect the
    state of the communicating partners. Therefore, if no explicit key
    revocation occurs, the expiry of an HI will not affect the security
    of HIP associations generated using the HI when it is still valid.
    They still can be used until they reach their expiring time. However,
    if an HI is found to be compromised, the security of the keying
    materials of the already generated HIP associations cannot be
    guaranteed. In practice, the compromise of a cryptographic key can
    be perceived only after the attacks employing the key are detected.
    It is difficult for one to identify the exact time from which the
    key is no longer secure. Hence, under this circumstance, the pre-
    generated HIP associations can only be used to deliver revocation
    certificates, as it is difficult for the communicating partners to
    know whether the HI is still secure when the HIP associations were

7.2. HI Refreshment

    In key management mechanisms, key refreshment is concerned with the
    issues of using new cryptographic keys to take place of "old" ones.
    Therefore, it closely related with key revocation. A refreshment
    procedure of a key can occur either before or after the revocation
    of the key (Note that in the first case the key is still valid). In
    this section, we briefly discuss the issues with HI refreshment in

 Zhang  Kuptsov  and Shen. Expires November 29, 2010          [Page 14]

 Internet-Draft    Host Identifier Revocation in HIP            May 2010

    Ideally, the refreshment of an operational HI should be performed
    before its crypto-period is expired. That is, when an HI refreshment
    process is performed, the HI expected to be updated is still valid.
    The holder then can use the old HI to establish secure channels, and
    use Update packets to transport the refreshment information to
    related partners (in a push model) or to trusted third parties (in a
    pull model). In the Update packets, the new HI and other related
    information are encapsulated. Therefore, before the old HI expires,
    both HIs are valid, and the HIP associations generated with the old
    HI can still be applied.

    In practice, the third parties deployed for HI revocation can also
    be used to support HI refreshment. For instance, when using a pull
    model, a host can transport the HI revoking and the refreshing
    information to a third party. Therefore, when a user inquires of the
    third party about the status information of an HI, the user can get
    the status of the HI inquired about as well as the associated
    refreshment information.

    If an HI needs to be revoked due to accident disclosure or
    compromise, the update of the HI can be a little more complex, as a
    host cannot use the invalid key to securely transport the
    refreshment information any more. If a host has multiple HIs, it can
    also select a valid HI to generate secure channels to transport the
    refreshment information of another HI. The refreshment information
    can be transported in an Update packet in which both the new HI and
    the old HI are contained. This solution require that the partner
    communicating with the host can ensure that the HI used to generate
    secure channel and the HI going to be refreshed are possessed by the
    same HIP host. Such knowledge can be obtained from resolution
    systems or provided by the host. In the cases where all the HIs of a
    host become invalid (e.g., the host is found to compromised), the
    host only can distribute the refreshment information using an out-
    of-band way.

    A host can also implement a pull model by directly transporting the
    update information to resolution servers. If the information is
    forwarded to a DNS server, users can query the latest HI using FQDN
    of the host. In a resolution system providing ID to locator mapping
    services (e.g., DHT), users can only try to query the resolution
    systems using old HITs. In this case, besides the IP addresses
    inquired, the resolution system should also provide the latest HIs
    and other useful information. Note that it is assumed that no two
    HITs of different hosts are identical, even if they are adopted in
    different period. In practice, because the length of HITs is long,
    the possibility that two hosts select a same HI can be very low. In

 Zhang  Kuptsov  and Shen. Expires November 29, 2010          [Page 15]

 Internet-Draft    Host Identifier Revocation in HIP            May 2010

    order to further reduce the possibility, a user can also provide the
    life period of the inquired HIT in a query.

 8. Conclusions

    Key revocation is critical for HIP to be secure, practical and
    manageable. Particularly, HIP hosts are expected to keep working
    securely for a relatively long period, proper key revocation
    mechanisms for HIs must be provided. This document focuses on
    con/pro of different key revocations and analyzes their performances
    in different practical scenarios. Although key management has been
    an active research area for a long period and lots of successful
    key-management systems (e.g., PKI) are widely adopted in practice,
    many issues (e.g., scalability, lack of trust) still exist. There is
    no solution being found to meet the timeliness and performance
    requirements of all applications and environments that HIP is
    expected to support [McDaniel et al. 2001]. Therefore, it is
    predicable that various HI revocation approaches will be adopted
    after HIP has been globally adopted.

 9. IANA Considerations

    No such considerations.

 10. Acknowledgments

    Many Thanks to Thomas.R.Henderson for his kindly revision and
    precious comments.

 11. References

 11.1. Normative References

    [RFC2459] Internet X.509 Public Key Infrastructure: Certificate and
              CRL Profile January 1999.

    [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
              Henderson, "Host Identity Protocol", RFC 5201, April 2008.

    [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
              Rendezvous Extension", RFC 5204, April 2008.

    [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol
              (HIP) Domain Name System (DNS) Extensions", RFC 5205,
              April 2008.

 Zhang  Kuptsov  and Shen. Expires November 29, 2010          [Page 16]

 Internet-Draft    Host Identifier Revocation in HIP            May 2010

 11.2. Informative References


                Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
              "Recommendation for Key Management - Part1 -
              General(Revised)", NIST Special Publication 800-57, March
              2007, <

    [Menezes et al. 1996]

                MENEZES, A., VAN OORSCHOT, P., AND VANSTONE, S. 1996.
              Handbook in Applied Cryptography. CRC Press,Boca Raton, FL.

    [Merwe et al. 2007]

                Merwe, J., Dawoud, D., and McDONALD, S., "A Survey on
              Peer-to-Peer Key Management for Mobile Ad Hoc
              Networks" ,2007.

    [McDaniel et al. 2001]

                McDaniel, P., and Rubin, A., "A Response to "can we
              eliminate certificate revocation list?"", 2001.

    Authors' Addresses

    Dacheng Zhang
    Huawei Technologies Co.,Ltd
    KuiKe Building, No.9 Xinxi Rd.,
    Hai-Dian District
    Beijing, 100085
    P.R. China

    Dmitriy Kuptsov
    Helsinki Institute for Information Technology
    PO. Box 9800
    TKK  FI-02015

 Zhang  Kuptsov  and Shen. Expires November 29, 2010          [Page 17]

 Internet-Draft    Host Identifier Revocation in HIP            May 2010

    Sean Shen
    4, South 4th Street, Zhongguancun
    Beijing 100190
    P.R. China

 Zhang  Kuptsov  and Shen. Expires November 29, 2010          [Page 18]