Dacheng Zhang (HUAWEI)

1
Host Identifier Revocation in HIPdraft-zhang-hip
-hi-revocation-02

• Dacheng Zhang (HUAWEI)
• Dmitriy Kuptsov (HITT)
• Sean Shen (CNNIC)

2
Aganda

• Classifications of Permanent Key Revocation
  Mechanisms
• Implicit HI Revocation in HIP
• An Issue Caused by Changing Life Periods of HIs
  without Controls
• Candidate Solutions
• Influence of HI Revocation on Already Generated
  HIP Associations
• A Brief Discussion with HI Refreshment

3
Classification of Permanent Key Revocation
Mechanisms

• Mechanisms for key revocation can be classified
  in different ways, according to, for example
• Whether additional operations are needed
• Implicit or Explicit Key Revocation
• Whether a third party is needed
• Online secure server or Repository server
• Which kind of list is adopted
• Black list or white list
• The way of distributing revocation information.
• Push model or pull model

4
Implicit HI Revocation in HIP (1)

• The basic idea of an implicit HI revocation
  mechanism is to assign a key with a valid period
  and use cryptographic methods to prove the
  binding between the key and its valid period.
• Questions
• Who has the privileges to specify the life
  periods of HIs?
• How to transport the life periods of HIs?
• How to verify whether a HI is in its valid
  period?

5
Implicit HI Revocation in HIP (2)

• The life period an HI can be specified either by
  the holder of the HI or by a trusted authority.
  During HIP Base Exchanges (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 transported in a
  CERT parameter in a HIP packet

6
Implicit HI Revocation in HIP (3)

• An Extension of HOST_ID Parameter
• The Not-Before-Time and the Not-After-Time should
  be in a format of either UTCTime or
  GeneralizedTime defined in RFC2459.

7
An Issue Caused by Modifying Life Periods of HIs
without Controls

• A lazy manager of a HIP host may attempt to avoid
  refreshing the HI and HIT of her host to avoid,
  e.g., complex HI revocation processes. Such
  activity may be difficult to detected
• It is inefficient for HIP handler to maintain the
  life period information for every communicating
  partner
• In referral scenarios, HIT is forwarded by upper
  layer applications as IP addresses, which does
  not have life period

8
Candidate Solutions (1)

• Resolution systems (e.g., DNS servers) can be
  used to provide trustable life-period information
  of HIs for communicating partners
• An extension of HIP RR

9
Candidate Solutions (2)

• Introduce the life periods of HIs into the
  generating process of HITs
• It can prevent host managers from updating the
  life period of HI without changing the associate
  HIT
• It is compatible with the first solution
• When the solution is adopted independently, it
  can mitigate the issue

10
Influence of HI Revocation on Already Generated
HIP Associations

• Influence of HI Revocation on Already Generated
  HIP Associations
• The expiry of a HI key pair will not affect the
  security of the keying materials already
  generated.
• It is practically difficult to identify when a
  key pair is compromised
• If the key is found to be compromised, the
  pre-generated HIP associations can only be used
  to deliver revocation certificates

11
A Brief Discussion with HI Refreshment

• Ideally, 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 case of accident disclosure or compromise
  of an HI
• If a host has multiple HIs, it can also select a
  valid HI to generate secure channels to transport
  the refreshment information of the invalid HI
• If all the HIs of a host become invalid (e.g.,
  the host is found to compromised), the host only
  can distribute the refreshment information in an
  out- of-band way

12

• Any Comments?

13
(No Transcript)