Host Identifier Revocation in HIP
draft-irtf-hiprg-revocation-04
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Dacheng Zhang , Dmitriy Kuptsov , Sean Shen | ||
| Last updated | 2011-10-31 (Latest revision 2011-07-11) | ||
| RFC stream | Internet Research Task Force (IRTF) | ||
| Formats | |||
| Additional resources | |||
| Stream | IRTF state | (None) | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-irtf-hiprg-revocation-04
Network Working Group D. Zhang
Internet-Draft Huawei Technologies Co.,Ltd
Intended status: Informational D. Kuptsov
Expires: May 3, 2012
S. Shen
CNNIC
October 31, 2011
Host Identifier Revocation in HIP
draft-irtf-hiprg-revocation-04
Abstract
This document mainly analyzes the key revocation issue with host
identifiers (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 cryptographic
keys from operational use 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 issues that a designer
of HI revocation mechanisms need to carefully consider.
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 May 3, 2012.
Copyright Notice
Zhang, et al. Expires May 3, 2012 [Page 1]
Internet-Draft HI Revocation October 2011
Copyright (c) 2011 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Key Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Classification of permanent Key Revocation Mechanisms . . 4
4.2. Classification of permanent Key Revocation Mechanisms . . 5
5. Implicit HI Revocation in HIP . . . . . . . . . . . . . . . . 7
6. Explicit HI Revocation in HIP . . . . . . . . . . . . . . . . 11
7. Related Discussions . . . . . . . . . . . . . . . . . . . . . 13
7.1. Influence of HI revocation on Already Generated HIP
Associations . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. HI Refreshment . . . . . . . . . . . . . . . . . . . . . . 14
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Zhang, et al. Expires May 3, 2012 [Page 2]
Internet-Draft HI Revocation October 2011
1. Introduction
In a HIP architecture [RFC5201], a HIP host needs to generate a
public/private key pair before it communicates with other HIP hosts.
The private key is kept securely by the host and the public key is
used to represent its identity. When two HIP hosts attempt to
initiate a conversation (e.g., a TCP session), they can take
advantage of their HI key pairs to perform mutual authentication and
generate 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 danger of
compromise. As time elapses, an attacker can collect more material
(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 that 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. Terminology
BEX (Base Exchange): The handshaking protocol defined in [RFC5201],
which enable two HIP hosts use their public keys pairs to generate
key materials for subsequent communication.
HI (Host Identifier): A public key kept by a HIP host to represent
the identity of the host.
HIT (Host Identity Tag): A 128-bit value generated by hashing the
associated HI.
Zhang, et al. Expires May 3, 2012 [Page 3]
Internet-Draft HI Revocation October 2011
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
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 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, etc.
4.1. Classification of permanent Key Revocation Mechanisms
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 vary from months to
years. Because frequent use 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
Zhang, et al. Expires May 3, 2012 [Page 4]
Internet-Draft HI Revocation October 2011
update old 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 specified. Using it, two
communicating HIP hosts can employ the authenticated Diffie-Hellman
algorithm to securely distribute keying material which will be used
to generate new cryptographic keys in the following communication.
After a handshake, the hosts are able to refresh 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, unless mentioned otherwise.
Mechanisms for key revocation can be classified in various ways,
according to:
o Whether additional operations are needed. If a key revocation
mechanism does not need any additional operation in the revocation
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.
Zhang, et al. Expires May 3, 2012 [Page 5]
Internet-Draft HI Revocation October 2011
o Whether a trusted 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
party provides up-to-date information. Online Certificate Status
Protocol (OCSP) for X.509 certificate is such a mechanism. An
OCSP client generates an OCSP request that primarily 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 upload 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 secure 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.
o 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.
o The way of distributing revocation information. In a key
revocation mechanism applying the push model, when 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 category.
There are few discussions about the HI revocation issues with HIP.
Zhang, et al. Expires May 3, 2012 [Page 6]
Internet-Draft HI Revocation October 2011
In the current HIP architecture, hosts are allowed to update their
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 most basic 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 enables host managers to define more specific security
policies.
Note that the HI and the HIT of a host are cryptographically
associated. A revocation of an HI will cause the revocation of the
corresponding HIT, and vice versa. The life periods of an HI and its
HIT are identical; the revocation of a HI implies the revocation of
the associated HIT, and vice versa.
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 (to be specified) 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 to the life 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
packet, while the parameter containing Responder' s HI and the
Zhang, et al. Expires May 3, 2012 [Page 7]
Internet-Draft HI Revocation October 2011
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
This approach enables a holder to specify the life period of its HI.
It does not rely on any dedicated trusted authority and introduces
little performance penalty in verifying the life period. However,
when using this approach in an environment where communicating HIP
hosts lack sufficient trust, it is difficult for a HIP host to
believe that the remote host has appropriately defined and managed
its HI life period. For instance, the revocation and refreshment of
an HI can be quite complex. Apart from updating the key material
locally, lots of 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. Other HIP
hosts can easily detect the problem if the manager attempts to assign
an unreasonably long life period for its HI. However, In order to
reduce memory consumption and foil deny-of-service attacks, HIP hosts
normally do not maintain the information of the HIP hosts that they
used to communicated with for a long period. In addition, in the
current HIP resolution solutions (e.g., HIP RR), no information about
the life periods of HIs is provided. If the manager assigns a new
life period with a reasonable length for her HI before the expiration
of the old life period, the update of the life period is unlikely to
be detected. Moreover, because HITs are treated by applications as
ordinary IP addresses which have no expiration 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
Zhang, et al. Expires May 3, 2012 [Page 8]
Internet-Draft HI Revocation October 2011
current HIP resolution solutions (e.g., HIP RR), there is no concern
about the life periods of HIs. Therefore, in current HIP
architectures, the approach cannot work properly unless 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 and the binding
between HIs and HITs. However, a dedicated trusted 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, two complementary solution to
mitigate the issues of arbitrarily modifying HI life periods are
introduced. Both solution impose little performance penalty to HIP
hosts. 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 additional communication between users and
resolutions systems.
In order to achieve this, space 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].
Zhang, et al. Expires May 3, 2012 [Page 9]
Internet-Draft HI Revocation October 2011
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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | 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 solution in HIP has not been
standardized yet. However, it is reasonable to integrate the
implicit HI revocation functionality into such systems.
The other approach is to introduce the life period of a HI into the
generating process of the associated HIT. For instance, the life
period of an HI can be used as a part of the input for generating the
associated HIT. Therefore it is computationally difficult even for
the holder of the HI to modify the life period without modifying the
HIT. Therefore, after a host advertises its contacting information
Zhang, et al. Expires May 3, 2012 [Page 10]
Internet-Draft HI Revocation October 2011
in resolution servers, any attempts to modify the life period of the
HI can be easily detected. For instance, in the case that 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 approach is its inflexibility in the cases where the life
periods of HIs need to be extended.
6. Explicit HI Revocation in HIP
As mentioned previously, in many typical scenarios (e.g., the
compromise of a key is detected), a cryptographic key should be
revoked before its life period expires. 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 type
of solution is always a subject of debates. First, this solution
requires the holder an HI to maintain a long list of information
about the partners, that 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), delta CRLs [RFC2459], and the On-Line
Zhang, et al. Expires May 3, 2012 [Page 11]
Internet-Draft HI Revocation October 2011
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
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 chain and communication
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
communications. However, RVSes can be extended to support HI
revocation if necessary. When a mobile host changes its HI, it can
inform its RVS. Therefore, when the RVS find that a host attempts to
access the mobile host with the old HI, the RVS can send the mapping
information of the antique HI and the new HI to the host. The RVS
needs to use its private key to sign the mapping information in order
to ensure the information will not be tampered with. Upon receiving
the mapping information, the remote host can use the new HI in the
subsequent communications. Additionally, since it is suggested in
[RFC5204] that a user get the information of RVSes from DNS, the
security of the communication between the remote host and DNS servers
needs to be protected. Otherwise, an attacker can easily convince a
witness that she is a legal RVS by forwarding a bogus DNS RR
Zhang, et al. Expires May 3, 2012 [Page 12]
Internet-Draft HI Revocation October 2011
consisting of its information to the witness. DNSSEC can be applied
to address this issue.
Also, 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, similar to what is 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. In order to secure the revocation information,
DNSSEC should be adopted.
7. Related Discussions
7.1. Influence of HI revocation on Already Generated HIP Associations
In a BEX, HI key pairs of the both communicating partners are used to
carry out mutual authentication while the key material 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 material. Assume there is
an attacker which has compromised the HI key pair. It is still
computationally 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 communication. 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 does not have to affect the security
strength 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 material 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
generated.
Zhang, et al. Expires May 3, 2012 [Page 13]
Internet-Draft HI Revocation October 2011
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, the issues with HI refreshment in HIP are discussed.
Ideally, an operational HI should be refreshed before its crypt-
period is expired. In thsi case, the holder 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.
Although the invalid key can be used to send a "suicide" information
to others (e.g., resolution systems, RVSes, or any entities which may
be affected by the revocation), it cannot be used to securely
transport the refreshment information any more.
If a host has multiple HIs, it can select a HI still valid to
securely transport the refreshment information. The refreshment
information should consist of both the new HI and the compromised HI.
This solution requires that the partner communicating with the host
can ensure that the HI used to generate secure channel and the
compromised HI are possessed by the same HIP host. Such knowledge
can be obtained from resolution systems or provided by the host. It
is recommended that there is a HI used only for HI refreshment.
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
Zhang, et al. Expires May 3, 2012 [Page 14]
Internet-Draft HI Revocation October 2011
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 time period. In practice, because the length of HITs is
long, the possibility that two hosts select a same HI can be very
low. In 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 pros
and cons of different key revocations and analyzes their security and
practicality 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 predicted that various HI revocation approaches will be adopted
after HIP has been globally adopted.
9. IANA Considerations
This document makes no request of IANA.
10. Security Considerations
The update of HIs is not rare, although it is relatively infrequent
in compare with the change of IP addresses. In the existing HIP
architectures, the HI of a HIP host acts as both the identifier and
the public key of the HIP host at the same time. The revocation of
the host's public key will result in the change of the identifier of
the host. Without the assistance of other measures, the host will be
regarded as a different one by others. The instability issue
introduced by the HI revocation must be considered in designing
identity management and resolution systems for HIP hosts. For
instance, during the revocation of a HI, all the TCP sessions
Zhang, et al. Expires May 3, 2012 [Page 15]
Internet-Draft HI Revocation October 2011
identified with the associated HIT have to be broken. There are two
solutions can be considered in addressing this problem.The first one
is to check the life period of a HI before using it to construct a
TCP session and guarantee that the HI can be stable during the
communication. The second one is to introduce a stable identifier to
represent a HIP host for up layer protocols. The new identifier
should not have to be changed during the update of a HI.
11. Acknowledgements
Many Thanks to Thomas.R.Henderson for his kindly revision and
precious comments.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2459] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and CRL
Profile", RFC 2459, January 1999.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., 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.
12.2. Informative References
[McDaniel et al. 2001]
McDaniel, P. and A. Rubin, "A Response to "can we
eliminate certificate revocation list?"", 2001.
[Menezes et al. 1996]
MENEZES, A., VAN OORSCHOT, P., and S. AND VANSTONE,
"Handbook in Applied Cryptography", 1996.
[Merwe et al. 2007]
Merwe, J., Dawoud, D., and S. McDONALD, "A Survey on Peer-
Zhang, et al. Expires May 3, 2012 [Page 16]
Internet-Draft HI Revocation October 2011
to-Peer Key Management for Mobile Ad Hoc Networks", 2007.
[Recommendations]
Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
"Recommendation for Key Management-Part1-
General(Revised)", March 2007.
Authors' Addresses
Dacheng Zhang
Huawei Technologies Co.,Ltd
HuaWei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District
Beijing, 100085
P. R. China
Phone:
Fax:
Email: zhangdacheng@huawei.com
URI:
Dmitriy Kuptsov
Helsinki Institute for Information Technology
PO. Box 9800, TKK FI-02015
Finland
Phone:
Fax:
Email: dmitriy.kuptsov@hiit.fi
URI:
Sean Shen
CNNIC
4, South 4th Street, Zhongguancun
Beijing, 100190
P.R. China
Phone:
Fax:
Email: shenshuo@cnnic.cn
URI:
Zhang, et al. Expires May 3, 2012 [Page 17]