idnits 2.17.1 draft-kuptsov-hhit-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2011) is 4792 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Kuptsov 3 Internet-Draft A. Gurtov 4 Intended status: Informational Helsinki Institute for Information 5 Expires: September 8, 2011 Technology, Aalto University 6 March 7, 2011 8 Hierarchical Host Identity Tags 9 draft-kuptsov-hhit-02 11 Abstract 13 This document describes the purpose, structure and possible use case 14 of hierarchical host identity tags for HIP protocol. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 8, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Structure of HHIT . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Use case . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 5. Normative References . . . . . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 This document specifies the purpose, structure and possible use case 66 of hierarchical host identity tags (HHIT) for Host Identity Protocol 67 (HIP) RFC 5201 [RFC5201]. 69 The purpose of HHIT is to enable online verification of flat 70 identifiers (in a scalable way), such as Host Identity Tags (HIT), by 71 corresponding organizations that are responsible for clients holding 72 such identifiers. While one way of verifying whether HIT belongs to 73 a client that is affiliated with some organization (or unit within 74 organization) is to use certificates; such approach can be undesired 75 because it (i) introduces high cost for certificate verification, and 76 (ii) does not directly allow certificate status verification 77 (consider the situation when private key of a particular host was 78 stolen and firewall enforcing certificate verification does not check 79 the revocation status of host's certificate). 81 2. Structure of HHIT 83 The following are the goals of HHIT: (i) allow any on the path 84 security gateway to distinguish to which authority the identifier 85 belongs, and later ask corresponding authority whether given HHIT is 86 valid; (ii) prevent misuse of HHIT by attackers (specifically, the 87 design allows to prevent replaying and constructing "fake" HHITs that 88 will enable attackers to bypass the security gateways). 90 The structure of hierarchical HHIT: 92 0 1 2 3 93 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 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | OID | 96 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | | HHIT | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 99 | | 100 + + 101 | | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | ENC_TIMESTAMP | 104 + + 105 | | 106 + + 107 | | 108 + + 109 | | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 Figure 1 114 o OID is organization identifier that depending of the application 115 of HHIT can be globally unique (e.g., assigned by Internet 116 Assigned Numbers Authority (IANA)), or unique within certain scope 117 (e.g., within organization and assigned on per department or unit 118 granularity). Length of OID is 48 bits. 120 o HHIT is an output of a pseudo-random function (PRF) under one-time 121 secret key and input taken as a concatenation of OID and flat 122 identifier (HIT): HHIT=PRF(OID || HIT, secret) The length of HHIT 123 field is 80 bits to guarantee sufficient level of security. 125 o ENC_TIMESTAMP field guarantees freshness of HHIT, it contains the 126 timestamp when particular HHIT was generated. This field is 127 encrypted (using symmetric encryption function) under the same 128 one-time secret as HHIT: ENC_TIMESTAMP = ENC(HHIT || #epoc, 129 secret), where HHIT is as described above, #epoc is a timestamp 130 indicating the time when HHIT was constructed, and secret is the 131 next yet unused secret key from a key pull, assigned to a client 132 by its authority. Because the usage of block cipher is assumed 133 for encryption, the length of ENC_TIMESTAMP field is a multiple of 134 the block size of a particular encryption algorithm. Since it is 135 sufficient for #epoch to be on the scale of seconds, 48 bits 136 reserved for this field. As a result, the length of 137 ENC_TIMESTAMP, when used together with AES-CBC algorithm, is 128 138 bits. 140 Because total length of OID||HHIT||ENC_TIMESTAMP exceeds reserved 128 141 bits for source address in HIP protocol, the source address may 142 contain only OID||HHIT while ENC_TIMESTAMP can be carried as option 143 in I1 packet. Observe, that it is only rational to have 144 ENC_TIMESTAMP filed in initial I1 packet. 146 3. Use case 148 Next we describe a possible use case: access control with HHIT: 150 Register HHIT (offline) 151 +----------------------+------------------>+-------------+ 152 | | | Domain 1 | 153 |Client (from domain 1)| Secret keys | authority | 154 +----------------------+<------------------+-------+-----+ 155 | HHIT /\ | OK 156 | | v 157 | I1 +---+---------+ 158 +------------------>| Security |-->... 159 +------------------>| gateway | 160 | I1 +---+---+-----+ 161 | HHIT | /\ 162 | Register HHIT v | Ok 163 +----------------------+------------------>+-------------+ 164 |Client (from domain 2)| | Domain 2 | 165 | | Secret keys | authority | 166 +----------------------+<------------------+-------+-----+ 168 Figure 2 170 We outline the protocol interaction: 172 o Each end-host that belongs to some organization, or organizational 173 unit, constructs its HIT (using the procedure described in RFC 174 5201 [RFC5201]), and registers it in an offline (and out-of-band) 175 manner in its organizational repository. Depending on the 176 application, the registration itself can involve authentication, 177 e.g. using passwords, certificates, biometric information, 178 passport, etc. Upon verification, domain authority generates set 179 of one-time-passwords (the number of such passwords again depends 180 on the application needs), and for each secret s populates its 181 database with the following records: HHIT = PRF(OID || HIT, s) 182 Domain authority then returns list of secrets to client over 183 secure channel (how this is achieved is out of scope). 185 o When a client wants to access the service that is behind security 186 gateway, it chooses next unused one-time secret "unused secret" 187 and constructs the HHIT as PRF(OID || HIT, "unused secret"), it 188 also takes the current #epoch "now" and constructs ENC_TIMESTAMP 189 as ENC(HHIT || "now", "unused secret"). The I1 packet then 190 contain the concatenation of OID, HHIT, and ENC_TIMESTAMP in the 191 source address field. 193 o When security gateway receives such I1 packet, it will look-up the 194 domain authority using OID found in the source address, and submit 195 OID, HHIT, and ENC_TIMESTAMP. Security gateway will buffer I1 196 until it will receive (positive or negative) response from 197 corresponding domain authority. 199 o Last, when domain authority receives OID, HHIT, and ENC_TIMESTAMP 200 for verification it looks up for the proper secret using HHIT as 201 index. If the record was not found, the domain authority 202 immediately responds to a gateway that information is not valid. 203 Else, domain authority attempts to decrypt ENC_TIMESTAMP field to 204 find #epoch. It also registers the current time "now". If "now" 205 - #epoch > Delta, the HHIT will be considered as invalid, and 206 negative response will be sent to security gateway, otherwise, 207 domain authority will remove the record from the database, and 208 reply to security gateway with positive response code. 210 o Security gateway will make a forwarding decision regarding 211 particular buffered I1 packet based on the response it receives 212 from domain authority: if the response is negative I1 packet is 213 dropped, otherwise the state will be created and I1 will be 214 forwarded. Note, for consequent R1, I2, R2 packets the forwarding 215 decisions by security gateway are done solely based on the stored 216 internal state: if it exists the packets are forwarded, otherwise 217 dropped. 219 4. Security Considerations 221 5. Normative References 223 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 224 "Host Identity Protocol", RFC 5201, April 2008. 226 Authors' Addresses 228 Dmitriy Kuptsov 229 Helsinki Institute for Information Technology, Aalto University 230 PO Box 19215 231 TKK 00076 Aalto 232 Finland 234 Phone: 235 Email: dmitriy.kuptsov@hiit.fi 237 Andrei Gurtov 238 Helsinki Institute for Information Technology, Aalto University 239 PO Box 19215 240 TKK 00076 Aalto 241 Finland 243 Phone: 244 Email: gurtov@hiit.fi