Internet Engineering Task Force D. Kuptsov
Internet-Draft A. Gurtov
Intended status: Informational Helsinki Institute for Information
Expires: September 8, 2011 Technology, Aalto University
March 7, 2011
Hierarchical Host Identity Tags
draft-kuptsov-hhit-02
Abstract
This document describes the purpose, structure and possible use case
of hierarchical host identity tags for HIP protocol.
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-
Drafts.
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 8, 2011.
Copyright Notice
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
Kuptsov & Gurtov Expires September 8, 2011 [Page 1]
Internet-Draft HHIT March 2011
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 BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Structure of HHIT . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use case . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Kuptsov & Gurtov Expires September 8, 2011 [Page 2]
Internet-Draft HHIT March 2011
1. Introduction
This document specifies the purpose, structure and possible use case
of hierarchical host identity tags (HHIT) for Host Identity Protocol
(HIP) RFC 5201 [RFC5201].
The purpose of HHIT is to enable online verification of flat
identifiers (in a scalable way), such as Host Identity Tags (HIT), by
corresponding organizations that are responsible for clients holding
such identifiers. While one way of verifying whether HIT belongs to
a client that is affiliated with some organization (or unit within
organization) is to use certificates; such approach can be undesired
because it (i) introduces high cost for certificate verification, and
(ii) does not directly allow certificate status verification
(consider the situation when private key of a particular host was
stolen and firewall enforcing certificate verification does not check
the revocation status of host's certificate).
2. Structure of HHIT
The following are the goals of HHIT: (i) allow any on the path
security gateway to distinguish to which authority the identifier
belongs, and later ask corresponding authority whether given HHIT is
valid; (ii) prevent misuse of HHIT by attackers (specifically, the
design allows to prevent replaying and constructing "fake" HHITs that
will enable attackers to bypass the security gateways).
The structure of hierarchical HHIT:
Kuptsov & Gurtov Expires September 8, 2011 [Page 3]
Internet-Draft HHIT March 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | HHIT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENC_TIMESTAMP |
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
o OID is organization identifier that depending of the application
of HHIT can be globally unique (e.g., assigned by Internet
Assigned Numbers Authority (IANA)), or unique within certain scope
(e.g., within organization and assigned on per department or unit
granularity). Length of OID is 48 bits.
o HHIT is an output of a pseudo-random function (PRF) under one-time
secret key and input taken as a concatenation of OID and flat
identifier (HIT): HHIT=PRF(OID || HIT, secret) The length of HHIT
field is 80 bits to guarantee sufficient level of security.
o ENC_TIMESTAMP field guarantees freshness of HHIT, it contains the
timestamp when particular HHIT was generated. This field is
encrypted (using symmetric encryption function) under the same
one-time secret as HHIT: ENC_TIMESTAMP = ENC(HHIT || #epoc,
secret), where HHIT is as described above, #epoc is a timestamp
indicating the time when HHIT was constructed, and secret is the
next yet unused secret key from a key pull, assigned to a client
by its authority. Because the usage of block cipher is assumed
for encryption, the length of ENC_TIMESTAMP field is a multiple of
the block size of a particular encryption algorithm. Since it is
sufficient for #epoch to be on the scale of seconds, 48 bits
reserved for this field. As a result, the length of
ENC_TIMESTAMP, when used together with AES-CBC algorithm, is 128
bits.
Kuptsov & Gurtov Expires September 8, 2011 [Page 4]
Internet-Draft HHIT March 2011
Because total length of OID||HHIT||ENC_TIMESTAMP exceeds reserved 128
bits for source address in HIP protocol, the source address may
contain only OID||HHIT while ENC_TIMESTAMP can be carried as option
in I1 packet. Observe, that it is only rational to have
ENC_TIMESTAMP filed in initial I1 packet.
3. Use case
Next we describe a possible use case: access control with HHIT:
Register HHIT (offline)
+----------------------+------------------>+-------------+
| | | Domain 1 |
|Client (from domain 1)| Secret keys | authority |
+----------------------+<------------------+-------+-----+
| HHIT /\ | OK
| | v
| I1 +---+---------+
+------------------>| Security |-->...
+------------------>| gateway |
| I1 +---+---+-----+
| HHIT | /\
| Register HHIT v | Ok
+----------------------+------------------>+-------------+
|Client (from domain 2)| | Domain 2 |
| | Secret keys | authority |
+----------------------+<------------------+-------+-----+
Figure 2
We outline the protocol interaction:
o Each end-host that belongs to some organization, or organizational
unit, constructs its HIT (using the procedure described in RFC
5201 [RFC5201]), and registers it in an offline (and out-of-band)
manner in its organizational repository. Depending on the
application, the registration itself can involve authentication,
e.g. using passwords, certificates, biometric information,
passport, etc. Upon verification, domain authority generates set
of one-time-passwords (the number of such passwords again depends
on the application needs), and for each secret s populates its
database with the following records: HHIT = PRF(OID || HIT, s)
Domain authority then returns list of secrets to client over
secure channel (how this is achieved is out of scope).
o When a client wants to access the service that is behind security
gateway, it chooses next unused one-time secret "unused secret"
Kuptsov & Gurtov Expires September 8, 2011 [Page 5]
Internet-Draft HHIT March 2011
and constructs the HHIT as PRF(OID || HIT, "unused secret"), it
also takes the current #epoch "now" and constructs ENC_TIMESTAMP
as ENC(HHIT || "now", "unused secret"). The I1 packet then
contain the concatenation of OID, HHIT, and ENC_TIMESTAMP in the
source address field.
o When security gateway receives such I1 packet, it will look-up the
domain authority using OID found in the source address, and submit
OID, HHIT, and ENC_TIMESTAMP. Security gateway will buffer I1
until it will receive (positive or negative) response from
corresponding domain authority.
o Last, when domain authority receives OID, HHIT, and ENC_TIMESTAMP
for verification it looks up for the proper secret using HHIT as
index. If the record was not found, the domain authority
immediately responds to a gateway that information is not valid.
Else, domain authority attempts to decrypt ENC_TIMESTAMP field to
find #epoch. It also registers the current time "now". If "now"
- #epoch > Delta, the HHIT will be considered as invalid, and
negative response will be sent to security gateway, otherwise,
domain authority will remove the record from the database, and
reply to security gateway with positive response code.
o Security gateway will make a forwarding decision regarding
particular buffered I1 packet based on the response it receives
from domain authority: if the response is negative I1 packet is
dropped, otherwise the state will be created and I1 will be
forwarded. Note, for consequent R1, I2, R2 packets the forwarding
decisions by security gateway are done solely based on the stored
internal state: if it exists the packets are forwarded, otherwise
dropped.
4. Security Considerations
5. Normative References
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008.
Kuptsov & Gurtov Expires September 8, 2011 [Page 6]
Internet-Draft HHIT March 2011
Authors' Addresses
Dmitriy Kuptsov
Helsinki Institute for Information Technology, Aalto University
PO Box 19215
TKK 00076 Aalto
Finland
Phone:
Email: dmitriy.kuptsov@hiit.fi
Andrei Gurtov
Helsinki Institute for Information Technology, Aalto University
PO Box 19215
TKK 00076 Aalto
Finland
Phone:
Email: gurtov@hiit.fi
Kuptsov & Gurtov Expires September 8, 2011 [Page 7]