idnits 2.17.1 draft-heer-hip-service-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (September 4, 2011) is 4608 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-02 ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5203 (Obsoleted by RFC 8003) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Host Identity Protocol T. Heer 3 Internet-Draft H. Wirtz 4 Intended status: Experimental RWTH Aachen University, 5 Expires: March 7, 2012 Communication and Distributed 6 Systems Group 7 Varjonen 8 Helsinki Institute for 9 Information Technology 10 September 4, 2011 12 Service Identifiers for HIP 13 draft-heer-hip-service-01 15 Abstract 17 The Host Identity Protocol [RFC5201] is a signaling protocol for 18 secure communication, mobility, and multihoming that introduces a 19 cryptographic namespace. This document specifies an extension for 20 HIP that enables HIP end-hosts and HIP-aware middleboxes to announce 21 services to HIP hosts during a HIP Base EXchange (BEX) or HIP update. 22 Service providers are able to specify the type and requirements of a 23 service; clients can then decide to agree on the terms of service. 24 This allows the service provider to verify the accordance of the 25 client with the service conditions while the client is able to verify 26 the authenticity of the used service. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 7, 2012. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 1. Introduction 67 The Host Identity Protocol (HIP) introduces a new cryptographic 68 namespace, based on public keys, in order to secure Internet 69 communication. Several HIP-related documents are concerned with the 70 provision and discovery of services, e.g., the HIP registration 71 extension [RFC5203] and the HIP middlebox authentication extension 72 [I-D.heer-hip-middle-auth]. This document specifies a new HIP 73 parameter that lets service providers communicate properties and 74 requirements of a service to the HIP end-hosts and to on-path HIP- 75 aware network entities. Service providers can either be other HIP 76 end-hosts (Initiator or Responder), on-path network entities (HIP- 77 aware middleboxes and other HIP-aware network infrastructure 78 elements), or entities using the HIP registration extension. 80 2. Terminology 82 In addition to the terminology defined in [RFC5203], this document 83 defines the following terms: 85 Service provider: A HIP end-host or HIP-aware on-path entity 86 (middlebox) that offers a service to a HIP end-host. Middleboxes 87 that offer a service can either use the HIP registration extension 88 [RFC5203] or the HIP middlebox authentication extension 89 [I-D.heer-hip-middle-auth]. 91 Client: A HIP end-host (Initiator or Responder) that is offered a 92 service. The client can choose whether to accept or to deny the 93 offered service. 95 3. Protocol Overview 97 The service announcement and service acknowledgement procedure 98 defined in this document is a two-way communication process that 99 integrates into the regular HIP control channel packet exchanges 100 (i.e. the HIP BEX and the HIP update mechanism). 102 During a base exchange or HIP update mechanism, a service provider 103 (the HIP end-host or a HIP-aware service provider on the 104 communication path) can add a SERVICE_OFFER or SERVICE_OFFER_UNSIGNED 105 to an R1, I2, R2, or UPDATE packet. In addition, the 106 SERVICE_OFFER_UNSIGNED can also be aded to I1 packets. The 107 SERVICE_OFFER provides general information about the service and 108 service-specific information for the client. This information is 109 addressed to the receiver of the HIP control packet. Each HIP packet 110 can contain multiple SERVICE_OFFER parameters from one or more 111 service providers. 113 The client reads the SERVICE_OFFER parameters from the incoming HIP 114 control packet and based on local policies decides to accept or deny 115 the service offer from the service provider. If it decides to accept 116 the service offer and if the service requires an acknowledgement 117 (indicated by a set ACK bit in the parameter), it responds by 118 creating a SERVICE_ACK parameter which it sends in the signed part of 119 the next regular HIP control packet. If the HIP control packet 120 containing the SERVICE_OFFER does not require an immediate response 121 in the next control packet, the receiver of the SERVICE_OFFER 122 generates an additional HIP UPDATE packet that contains the 123 SERVICE_ACK. If a client declines the service offer or no 124 acknowledgement is required, it does not respond with a SERVICE_ACK 125 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 970 (SERVICE OFFER SIGNED) 206 65334 (SERVICE OFFER UNSIGNED) 208 Length Variable 210 SP Service Properties. A bit field characterizing the 211 service (see below). 213 SID Unique service ID identifying the service or type of 214 service. 0 (zero) to 2^31-1 assigned by IANA, rest 215 unallocated and in free use. 217 SD Service Description and service conditions specified 218 by the service provider and interpreted by the client. 220 SERVICE_PROPERTIES field structure: 222 0 1 223 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 224 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 225 0 |REQ ACK COM FOR TER INI ACI ACR CEI CER AUT <--- RESERVED ---> | 226 1 | <--- RESERVED ---> | 227 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 229 0 REQ - Required: Non adherence to the requested 230 authentication will result in denial of 231 service. 233 1 ACK - Acknowledgement: The service requires a signed 234 acknowledgement in a SERVICE_ACK parameter. 236 2 COM - Commercial: Use of this service may result in monetary 237 costs. 239 3 FOR - Forwarding: This service entails forwarding of packets. 241 4 TER - Terminal: This HIP-aware middlebox is located at the 242 last hop towards the responder. 244 5 INI - Initial: This HIP-aware middlebox is located at the 245 first hop towards the responder. 247 6 ACI - ACL Initiator: The HIT of the Initiator must be in the ACL 248 of the service. 250 7 ACR - ACL Responder: The HIT of the Responder must be in the ACL 251 of the service. 253 8 CEI - Cert Initiator: Cert from Initiator required. Cert type 254 defined in variable SD field. 256 9 CER - Cert Responder: Cert from Responder required. Cert type 257 defined in variable SD field. 259 10 AUT - Additional Auth: Additional authentication measures are 260 required. Authentication type defined in 261 variable SD field. 263 Bits 10 to 31 are reserved for future purposes. 265 3.1.2. SERVICE_ACK 267 A host that accepts a SERVICE_OFFER or SERVICE_OFFER_UNSIGNED replies 268 with a SERVICE_ACK parameter in its next regular HIP packet. 270 The service acknowledgement contains the SID as reference to the 271 acknowledged service and the hash of the SERVICE_OFFER parameter. 272 The hash is generated by applying SHA-1 hash function to the 273 SERVICE_OFFER or SERVICE_OFFER_UNSIGNED parameter. 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Type | Length | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | | 281 | SID (Service IDentifier) (32 bit) | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | | 284 | SH (Service Hash) (128 bit) | 285 | | 286 | | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Type 974 291 Length 160 bit 293 SID Unique service ID identifying the service or type of 294 service. 0 (zero) to 2^31-1 assigned by IANA, the rest 295 is unallocated and in free use. 297 SH SHA-1 hash of the accepted SERVICE_OFFER parameter 298 belonging to the SID 300 4. Applications and Use Cases 302 4.1. Certificates 304 Middleboxes or end-hosts may require certificates that state that the 305 host is entitled to perform certain actions (e.g. connect to a host, 306 use a certain link, use a certain service) [I-D.ietf-hip-cert]. The 307 HIP CERT parameter allows HIP hosts to transmit certificate 308 information within HIP control packets. However, a host may possess 309 multiple certificates and therefore it must decide which certificate 310 to transmit. 312 End-hosts and middleboxes can require the client to present a 313 certificate by adding a SERVICE_OFFER parameter to the next packer 314 addressed to the client. Setting the CEI bit set indicates that a 315 certificate is required and should be sent on the consequent control 316 packet in order to get service. The type of certificate can be 317 transmitted in the SD field. 319 Likewise, an end-host or middlebox can inform a HIP host that 320 additional authentication measures (e.g., password authentication 321 [I-D.varjonen-hip-eap]) must be performed during or after the base 322 exchange. By setting the REQ and FOR bits, the middlebox or end-host 323 can express that forwarding of payload packet will not be performed 324 until the authentication is completed. The exact type of 325 authentication is expressed in the variable SD field. 327 If the end-host fails in providing sufficient credentials to the 328 service provider it can respond with a NOTIFICATION with 329 BLOCKED_BY_POLICY if the service provider is an end-host or a 330 NOTIFICATION with BLOCKED_BY_POLICY_M if the service provider is a 331 middlebox to signal the error. BLOCKED_BY_POLICY is defined in 332 [RFC5201] and BLOCKED_BY_POLICY_M is defined below. 334 NOTIFY MESSAGES - ERROR TYPES Value 335 ------------------------------ ----- 337 BLOCKED_BY_POLICY 42 339 The Responder is unwilling to set up an association 340 for policy reasons. 342 BLOCKED_BY_POLICY_M 8192 344 The middlebox is not willing to service the client for 345 policy reasons. 347 The policy reason for not serving or setting up an association in 348 this case would be a missing or insufficient certificate. 350 4.2. Quality of Service 352 Services may offer a free basic service and a commercial premium 353 service. In such cases, the service provider can add a SERVICE_OFFER 354 for the premium service and default to the basic service if the 355 client does not send a matching SERVICE_ACK. Alternatively, the 356 service provider can add multiple SERVICE_OFFER parameters to a hip 357 control packets, leaving it to the client to acknowledge the 358 appropriate offer. 360 Further service details (e.g. payment and the quality of the offered 361 services) can be negotiated by using the SERVICE_DETAILS field. By 362 signing the SERVICE_ACK, the end-host agrees to the terms of service. 363 The service provider can use the signed HIP packet containing the 364 SERVICE_ACK as proof that the client has requested the service. It 365 can later use this proof for billing. 367 Service providers MAY send a NOTIFICATION if the client does not 368 respond with a matching SERVICE_ACK by sending either 369 BLOCKED_BY_POLICY (end-host) or BLOCKED_BY_POLICY_M (middlebox) if 370 they decide to deny the service. See section Section 4.1 for the 371 definition of these parameters. 373 5. Security Considerations 375 The question of whether a client must subscribe to a service and the 376 question of whether a service is on the shortest direct path between 377 the Initiator and the Responder is out of scope for this document. 378 However, service operators can design the SERVICE_OFFER parameter in 379 a way that allows semantic sanity checks. For example, a host can 380 detect a suspicios situation if two middleboxes claim to be inital or 381 terminal middleboxes (active INI or TER bits in the SD field of the 382 SERVICE_OFFER parameter). In such cases, end-hosts may require to 383 react based on policies or user interaction. 385 This document makes no assumptions about the authenticity of the 386 SERVICE_OFFER_UNSIGNED parameter. Especially the identity of a 387 service provider is not verified. However, should a service require 388 authentication of a service provider, it can implement this in the 389 variable data field in the SERVICE_OFFER and SERVICE_OFFER_UNSIGNED 390 parameter. 392 Using a SERVICE_OFFER_UNSIGNED parameter in an I1 packet with a set 393 ACK bit may require the Responder to echo the relevant 394 SERVICE_OFFER_UNSIGNED parts in a SERVICE_ACK parameter. This may 395 require the Responder to generate a live signature for the R2 packet 396 and makes the use of pre-created R1 packets impossible. Hence, the 397 Responder SHOULD treat such I1 packets with lower priority. 399 6. IANA Considerations 401 This draft specifies a new namespace for service identifiers (SID 402 numbers). The SID numbers from 0 to 2^31-1 are to be assigned by 403 IANA. SID numbers from 2^31 to 2^32-1 are unallocated and may be 404 used by service providers without prior request or notice. The SID 405 numbers in the unmanaged SID number space should be selected in a 406 random fashion. There is no guarantee that the SID numbers in the 407 unmanaged SID space are free from collisions. Service providers that 408 use SID numbers from the unallocated SID space should, therefore, 409 take precautions for cases of collisions. 411 In addition to the SID, a service is described by its SP-flags. To 412 guarantee consistent extensibility of service descriptions, 413 assignment of flags and their positions should also be provided by 414 IANA. 416 This draft requires three new HIP parameter numbers. Two within the 417 signed part of the HIP packets (970 and 974) and one ithin the 418 unsigned part of the packet (65334). 420 7. Changelog 422 7.1. Version 1 424 - Fixed broken parameter numbers. 426 - Extended IANA consideration to accomodate new parameter numbers. 428 - Added reference to draft-varjonen-hip-eap-00. 430 - Added AUT bit for additional authentication (see eap). 432 - Added text to security considerations about SERVICE_OFFER_UNSIGNED 433 in I1. 435 8. Normative References 437 [I-D.heer-hip-middle-auth] 438 Heer, T., Wehrle, K., and M. Komu, "End-Host 439 Authentication for HIP Middleboxes", 440 draft-heer-hip-middle-auth-02 (work in progress), 441 February 2009. 443 [I-D.ietf-hip-cert] 444 Heer, T. and S. Varjonen, "Host Identity Protocol 445 Certificates", draft-ietf-hip-cert-12 (work in progress), 446 March 2011. 448 [I-D.varjonen-hip-eap] 449 Varjonen, S., "HIP and User Authentication", 450 draft-varjonen-hip-eap-00 (work in progress), July 2009. 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, March 1997. 455 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 456 "Host Identity Protocol", RFC 5201, April 2008. 458 [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity 459 Protocol (HIP) Registration Extension", RFC 5203, 460 April 2008. 462 Authors' Addresses 464 Tobias Heer 465 RWTH Aachen University, Communication and Distributed Systems Group 466 Ahornstrasse 55 467 Aachen 52062 468 Germany 470 Email: heer@cs.rwth-aachen.de 471 URI: http://www.comsys.rwth-aachen.de/team/tobias-heer/ 473 Hanno Wirtz 474 RWTH Aachen University, Communication and Distributed Systems Group 475 Ahornstrasse 55 476 Aachen 52062 477 Germany 479 Phone: +49 241 80 20773 480 Email: hanno.wirtz@rwth-aachen.de 481 URI: http://ds.cs.rwth-aachen.de/members/wirtz 483 Samu Varjonen 484 Helsinki Institute for Information Technology 485 Gustaf Haellstroemin katu 2b 486 Helsinki 487 Finland 489 Email: samu.varjonen@hiit.fi 490 URI: http://www.hiit.fi