idnits 2.17.1 draft-heer-hip-service-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 abstract seems to contain references ([RFC5201]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 27, 2009) is 5534 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-heer-hip-middle-auth-01 == Outdated reference: A later version (-12) exists of draft-ietf-hip-cert-00 ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5203 (Obsoleted by RFC 8003) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Host Identity Protocol T. Heer, Ed. 3 Internet-Draft H. Wirtz 4 Intended status: Experimental Distributed Systems Group, RWTH 5 Expires: August 31, 2009 Aachen University 6 S. Varjonen 7 Helsinki Institute for 8 Information Technology 9 February 27, 2009 11 Service Identifiers for HIP 12 draft-heer-hip-service-00 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may not be modified, 18 and derivative works of it may not be created, except to format it 19 for publication as an RFC and to translate it into languages other 20 than English. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 31, 2009. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 The Host Identity Protocol [RFC5201] is a signaling protocol for 54 secure communication, mobility, and multihoming that introduces a 55 cryptographic namespace. This document specifies an extension for 56 HIP that enables HIP end-hosts and HIP-aware middleboxes to announce 57 services to HIP hosts during a HIP Base EXchange (BEX) or HIP update. 58 Service providers are able to specify the type and requirements of a 59 service; clients can then decide to agree on the terms of service. 60 This allows the service provider to verify the accordance of the 61 client with the service conditions while the client is able to verify 62 the authenticity of the used service. 64 Requirements Language 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in [RFC2119]. 70 1. Introduction 72 The Host Identity Protocol (HIP) introduces a new cryptographic 73 namespace, based on public keys, in order to secure Internet 74 communication. Several HIP-related documents are concerned with the 75 provision and discovery of services, e.g., the HIP registration 76 extension [RFC5203] and the HIP middlebox authentication extension 77 [I-D.heer-hip-middle-auth]. This document specifies a new HIP 78 parameter that lets service providers communicate properties and 79 requirements of a service to the HIP end-hosts and to on-path HIP- 80 aware network entities. Service providers can either be other HIP 81 end-hosts (Initiator or Responder), on-path network entities (HIP- 82 aware middleboxes and other HIP-aware network infrastructure 83 elements), or entities using the HIP registration extension. 85 2. Terminology 87 In addition to the terminology defined in [RFC5203], this document 88 defines the following terms: 90 Service provider: A HIP end-host or HIP-aware on-path entity 91 (middlebox) that offers a service to a HIP end-host. Middleboxes 92 that offer a service can either use the HIP registration extension 93 [RFC5203] or the HIP middlebox authentication extension 94 [I-D.heer-hip-middle-auth]. 96 Client: A HIP end-host (Initiator or Responder) that is offered a 97 service. The client can choose whether to accept or to deny the 98 offered service. 100 3. Protocol Overview 102 The service announcement and service acknowledgement procedure 103 defined in this document is a two-way communication process that 104 integrates into the regular HIP control channel packet exchanges 105 (i.e. the HIP BEX and the HIP update mechanism). 107 During a base exchange or HIP update mechanism, a service provider 108 (the HIP end-host or a HIP-aware service provider on the 109 communication path) can add a SERVICE_OFFER to an I1, R1, I2, R2, or 110 UPDATE packet. The SERVICE_OFFER provides general information about 111 the service and service-specific information for the client. This 112 information is addressed to the receiver of the HIP control packet. 113 Each HIP packet can contain multiple SERVICE_OFFER parameters from 114 one or more service providers. 116 The client reads the SERVICE_OFFER parameters from the incoming HIP 117 control packet and based on local policies decides to accept or deny 118 the service offer from the service provider. If it decides to accept 119 the service offer, it responds by creating a SERVICE_ACK parameter 120 which it sends in the signed part of the next regular HIP control 121 packet. If the HIP control packet containing the SERVICE_OFFER does 122 not require an immediate response in the next control packet, the 123 receiver of the SERVICE_OFFER generates an additional HIP UPDATE 124 packet that contains the SERVICE_ACK. If a client declines the 125 service offer, it does not respond with a SERVICE_ACK parameter. 127 The SERVICE_OFFER parameter comes in two flavors: SERVICE_OFFER and 128 SERVICE_OFFER_UNSIGNED. The SERVICE_OFFER parameter is covered by 129 the signature of the HIP control packet that contains it. Therefore, 130 it can only be added by the HIP end-host that generates the HIP 131 control packet. The SERVICE_OFFER_UNSIGNED is not covered by the 132 signature in the HIP control packet, it is added by HIP-aware 133 middleboxes or HIP end-hosts. Consequently, end-hosts can decide 134 whether to use the signed or unsigned version of the parameter. An 135 example in which an end-host may prefer to use the unsigned parameter 136 is the use of pre-created R1 packets which should include a 137 SERVICE_OFFER that depends on properties of the Initiator (e.g. its 138 HI or IP address). 140 The service provider can determine whether the client acknowledges 141 the service offer by checking the presence of a SERVICE_ACK parameter 142 with a matching SERVICE_ID in the next packet. The SERVICE_ACK 143 contains the hash of the service offer, allowing the service provider 144 to verify that the user has accepted the terms of service as added by 145 the service provider in the SERVICE_OFFER. Replying with the hash of 146 the complete SERVICE_OFFER ensures that the client adheres to all 147 conditions of the service offer and that the SERVICE_OFFER_UNSIGNED 148 parameter was delivered without modification in transit. 149 Additionally, the service provider SHOULD verify the validity of the 150 signature in the HIP control packet. In order to shelter against 151 Denial-of-Service (DoS) attacks, end-hosts and middleboxes can 152 utilize the puzzle mechanisms specified in [RFC5201] for end-hosts 153 and [I-D.heer-hip-middle-auth] for middleboxes 155 3.1. HIP Parameters 157 3.1.1. SERVICE_OFFER and SERVICE_OFFER_UNSIGNED Parameters 159 The SERVICE_OFFER and the SERVICE_OFFER_UNSIGNED have identical 160 structures and semantics. The two parameters differ only in their 161 type numbers. Therefore, we discuss only about the contents of the 162 SERVICE_OFFER parameter while the following specifications concerning 163 the SERVICE_OFFER parameter also apply to the SERVICE_OFFER_UNSIGNED 164 parameter. 166 The SERVICE_OFFER parameter is depicted below. It consists of three 167 parts: 169 1. SERVICE_PROPERTIES (SP): The SERVICE_PROPERTIES field provides 170 the receiving host with a basic classification of the service 171 based on general parameters. The service properties are an aid 172 for the end-hosts for understanding the nature of an unknown 173 service. 175 2. SERVICE_ID (SID): The SERVICE_ID is a number that identifies a 176 service or a class of services. The SERVICE_DESCRIPTION is 177 interpreted depending on the SERVICE_ID. The SERVICE_ID MUST be 178 known to all hosts that intend to use that particular service. 179 The SID numbers from 0 to 2^31-1 are assigned by IANA. SID 180 numbers from 2^31 to 2^32-1 are unallocated and may be used by 181 service providers without prior request or notice. 183 3. SERVICE_DESCRIPTION (SD): The SERVICE_DESCRIPTION field is a 184 variable-length data blob that is interpreted based on the 185 information in the SID field. It MUST be understood by all hosts 186 that intend to use the service. The SD field allows a service to 187 provide specific service-related information. The structure and 188 semantics of the SD field are not part of this document but are 189 specified by the service operators. 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Type | Length | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | SP (SERVICE_PROPERTIES) (32 bit) | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | SID (SERVICE_ID) (32 bit) | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | SD (SERVICE_DESCRIPTION (variable length) / 201 / +-+-+-+-+-+-+-+-+-+-| 202 / | Padding | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Type 65334 207 Length Variable 209 SP Service Properties. A bit field characterizing the 210 service (see below). 212 SID Unique service ID identifying the service or type of 213 service. 0 (zero) to 2^31-1 assigned by IANA, rest 214 unallocated and in free use. 216 SD Service Description and service conditions specified 217 by the service provider and interpreted by the client. 219 SERVICE_PROPERTIES field structure: 221 0 1 222 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 223 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 224 0 |REQ COM FOR TER INI ACI ACR CEI CER <--- RESERVED ---> | 225 1 | <--- RESERVED ---> | 226 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 228 0 REQ - Required: Non adherence to the requested authentication 229 will result in denial of service. 231 1 COM - Commercial: Use of this service may result in monetary 232 costs. 234 2 FOR - Forwarding: This service entails forwarding of packets. 236 3 TER - Terminal: This HIP-aware middlebox is located at the 237 last hop towards the responder. 239 4 INI - Initial: This HIP-aware middlebox is located at the 240 first hop towards the responder. 242 5 ACI - ACL Initiator: The HIT of the Initiator must be in the ACL 243 of the service. 245 6 ACR - ACL Responder: The HIT of the Responder must be in the ACL 246 of the service. 248 7 CEI - Cert Initiator: Cert from Initiator required. Cert type 249 defined in variable SD field. 251 8 CER - Cert Responder: Cert from Responder required. Cert type 252 defined in variable SD field. 254 Bits 9 to 32 are reserved for future purposes. 256 3.1.2. SERVICE_ACK 258 A host that accepts a SERVICE_OFFER or SERVICE_OFFER_UNSIGNED replies 259 with a SERVICE_ACK parameter in its next regular HIP packet. 261 The service acknowledgement contains the SID as reference to the 262 acknowledged service and the hash of the SERVICE_OFFER parameter. 263 The hash is generated by applying SHA-1 hash function to the 264 SERVICE_OFFER or SERVICE_OFFER_UNSIGNED parameter. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Type | Length | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 | SID (Service IDentifier) (32 bit) | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | | 275 | SH (Service Hash) (128 bit) | 276 | | 277 | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Type 65334 282 Length 160 bit 284 SID Unique service ID identifying the service or type of 285 service. 0 (zero) to 2^31-1 assigned by IANA, rest 286 unallocated and in free use. 288 SH SHA-1 hash of the accepted SERVICE_OFFER parameter 289 belonging to the SID 291 4. Applications and Use Cases 293 4.1. Certificates 295 Middleboxes or end-hosts may require certificates that state that the 296 host is entitled to perform certain actions (e.g. connect to a host, 297 use a certain link, use a certain service) [I-D.ietf-hip-cert]. The 298 HIP CERT parameter allows HIP hosts to transmit certificate 299 information within HIP control packets. However, a host may possess 300 multiple certificates and therefore it must decide which certificate 301 to transmit. 303 End-hosts and middleboxes can require the client to present a 304 certificate by adding a SERVICE_OFFER parameter to the next packer 305 addressed to the client. Setting the CEI bit set indicates that a 306 certificate is required and should be sent on the consequent control 307 packet in order to get service. The type of certificate can be 308 transmitted in the SD field. 310 If the end-host fails in providing sufficient credentials to the 311 service provider it can respond with a NOTIFICATION with 312 BLOCKED_BY_POLICY if the service provider is an end-host or a 313 NOTIFICATION with BLOCKED_BY_POLICY_M if the service provider is a 314 middlebox to signal the error. BLOCKED_BY_POLICY is defined in 315 [RFC5201] and BLOCKED_BY_POLICY_M is defined below. 317 NOTIFY MESSAGES - ERROR TYPES Value 318 ------------------------------ ----- 320 BLOCKED_BY_POLICY 42 322 The Responder is unwilling to set up an association 323 for policy reasons. 325 BLOCKED_BY_POLICY_M 8192 327 The middlebox is not willing to service the client for 328 policy reasons. 330 The policy reason for not serving or setting up an association in 331 this case would be a missing or insufficient certificate. 333 4.2. Quality of Service 335 Services may offer a free basic service and a commercial premium 336 service. In such cases, the service provider can add a SERVICE_OFFER 337 for the premium service and default to the basic service if the 338 client does not send a matching SERVICE_ACK. Alternatively, the 339 service provider can add multiple SERVICE_OFFER parameters to a hip 340 control packets, leaving it to the client to acknowledge the 341 appropriate offer. 343 Further service details (e.g. payment and the quality of the offered 344 services) can be negotiated by using the SERVICE_DETAILS field. By 345 signing the SERVICE_ACK, the end-host agrees to the terms of service. 346 The service provider can use the signed HIP packet containing the 347 SERVICE_ACK as proof that the client has requested the service. It 348 can later use this proof for billing. 350 Service providers MAY send a NOTIFICATION if the client does not 351 respond with a matching SERVICE_ACK by sending either 352 BLOCKED_BY_POLICY (end-host) or BLOCKED_BY_POLICY_M (middlebox) if 353 they decide to deny the service. See section Section 4.1 for the 354 definition of these parameters. 356 5. Security Considerations 358 The question of whether a client must subscribe to a service and the 359 question of whether a service is on the shortest direct path between 360 the Initiator and the Responder is out of scope for this document. 361 However, service operators can design the SERVICE_OFFER parameter in 362 a way that allows semantic sanity checks. For example, a host can 363 detect a suspicios situation if two middleboxes claim to be inital or 364 terminal middleboxes (active INI or TER bits in the SD field of the 365 SERVICE_OFFER parameter). In such cases, end-hosts may require to 366 react based on policies or user interaction. 368 This document makes no assumptions about the authenticity of the 369 SERVICE_OFFER and SERVICE_OFFER_UNSIGNED parameter. Especially the 370 identity of a service provider is not verified. However, should a 371 service require authentication of a service provider, it can 372 implement this in the variable data field in the SERVICE_OFFER and 373 SERVICE_OFFER_UNSIGNED parameter. 375 6. IANA Considerations 377 This draft specifies a new namespace for service identifiers (SID 378 numbers). The SID numbers from 0 to 2^31-1 are to be assigned by 379 IANA. SID numbers from 2^31 to 2^32-1 are unallocated and may be 380 used by service providers without prior request or notice. The SID 381 numbers in the unmanaged SID number space should be selected in a 382 random fashion. There is no guarantee that the SID numbers in the 383 unmanaged SID space are free from collisions. Service providers that 384 use SID numbers from the unallocated SID space should, therefore, 385 take precautions for cases of collisions. 387 In addition to the SID, a service is described by its SP-flags. To 388 guarantee consistent extensibility of service descriptions, 389 assignment of flags and their positions should also be provided by 390 IANA. 392 7. Normative References 394 [I-D.heer-hip-middle-auth] 395 Heer, T., Wehrle, K., and M. Komu, "End-Host 396 Authentication for HIP Middleboxes", 397 draft-heer-hip-middle-auth-01 (work in progress), 398 July 2008. 400 [I-D.ietf-hip-cert] 401 Heer, T. and S. Varjonen, "HIP Certificates", 402 draft-ietf-hip-cert-00 (work in progress), October 2008. 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, March 1997. 407 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 408 "Host Identity Protocol", RFC 5201, April 2008. 410 [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity 411 Protocol (HIP) Registration Extension", RFC 5203, 412 April 2008. 414 Authors' Addresses 416 Tobias Heer (editor) 417 Distributed Systems Group, RWTH Aachen University 418 Ahornstrasse 55 419 Aachen 52062 420 Germany 422 Phone: +49 241 80 20776 423 Email: heer@cs.rwth-aachen.de 424 URI: http://ds.cs.rwth-aachen.de/members/heer 426 Hanno Wirtz 427 Distributed Systems Group, RWTH Aachen University 428 Ahornstrasse 55 429 Aachen 52062 430 Germany 432 Phone: +49 241 80 20773 433 Email: hanno.wirtz@rwth-aachen.de 434 URI: http://ds.cs.rwth-aachen.de/members/wirtz 436 Samu Varjonen 437 Helsinki Institute for Information Technology 438 Metsnneidonkuja 4 439 Helsinki 440 Finland 442 Fax: +358 969 49768 443 Email: samu.varjonen@hiit.fi 444 URI: http://www.hiit.fi