Host Identity Protocol T. Heer, Ed. Internet-Draft H. Wirtz Intended status: Experimental Distributed Systems Group, RWTH Expires: August 31, 2009 Aachen University S. Varjonen Helsinki Institute for Information Technology February 27, 2009 Service Identifiers for HIP draft-heer-hip-service-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC and to translate it into languages other than English. 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 August 31, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights Heer, et al. Expires August 31, 2009 [Page 1] Internet-Draft Hip-Service-ID February 2009 and restrictions with respect to this document. Abstract The Host Identity Protocol [RFC5201] is a signaling protocol for secure communication, mobility, and multihoming that introduces a cryptographic namespace. This document specifies an extension for HIP that enables HIP end-hosts and HIP-aware middleboxes to announce services to HIP hosts during a HIP Base EXchange (BEX) or HIP update. Service providers are able to specify the type and requirements of a service; clients can then decide to agree on the terms of service. This allows the service provider to verify the accordance of the client with the service conditions while the client is able to verify the authenticity of the used service. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1. Introduction The Host Identity Protocol (HIP) introduces a new cryptographic namespace, based on public keys, in order to secure Internet communication. Several HIP-related documents are concerned with the provision and discovery of services, e.g., the HIP registration extension [RFC5203] and the HIP middlebox authentication extension [I-D.heer-hip-middle-auth]. This document specifies a new HIP parameter that lets service providers communicate properties and requirements of a service to the HIP end-hosts and to on-path HIP- aware network entities. Service providers can either be other HIP end-hosts (Initiator or Responder), on-path network entities (HIP- aware middleboxes and other HIP-aware network infrastructure elements), or entities using the HIP registration extension. 2. Terminology In addition to the terminology defined in [RFC5203], this document defines the following terms: Service provider: A HIP end-host or HIP-aware on-path entity (middlebox) that offers a service to a HIP end-host. Middleboxes that offer a service can either use the HIP registration extension [RFC5203] or the HIP middlebox authentication extension [I-D.heer-hip-middle-auth]. Heer, et al. Expires August 31, 2009 [Page 2] Internet-Draft Hip-Service-ID February 2009 Client: A HIP end-host (Initiator or Responder) that is offered a service. The client can choose whether to accept or to deny the offered service. 3. Protocol Overview The service announcement and service acknowledgement procedure defined in this document is a two-way communication process that integrates into the regular HIP control channel packet exchanges (i.e. the HIP BEX and the HIP update mechanism). During a base exchange or HIP update mechanism, a service provider (the HIP end-host or a HIP-aware service provider on the communication path) can add a SERVICE_OFFER to an I1, R1, I2, R2, or UPDATE packet. The SERVICE_OFFER provides general information about the service and service-specific information for the client. This information is addressed to the receiver of the HIP control packet. Each HIP packet can contain multiple SERVICE_OFFER parameters from one or more service providers. The client reads the SERVICE_OFFER parameters from the incoming HIP control packet and based on local policies decides to accept or deny the service offer from the service provider. If it decides to accept the service offer, it responds by creating a SERVICE_ACK parameter which it sends in the signed part of the next regular HIP control packet. If the HIP control packet containing the SERVICE_OFFER does not require an immediate response in the next control packet, the receiver of the SERVICE_OFFER generates an additional HIP UPDATE packet that contains the SERVICE_ACK. If a client declines the service offer, it does not respond with a SERVICE_ACK parameter. The SERVICE_OFFER parameter comes in two flavors: SERVICE_OFFER and SERVICE_OFFER_UNSIGNED. The SERVICE_OFFER parameter is covered by the signature of the HIP control packet that contains it. Therefore, it can only be added by the HIP end-host that generates the HIP control packet. The SERVICE_OFFER_UNSIGNED is not covered by the signature in the HIP control packet, it is added by HIP-aware middleboxes or HIP end-hosts. Consequently, end-hosts can decide whether to use the signed or unsigned version of the parameter. An example in which an end-host may prefer to use the unsigned parameter is the use of pre-created R1 packets which should include a SERVICE_OFFER that depends on properties of the Initiator (e.g. its HI or IP address). The service provider can determine whether the client acknowledges the service offer by checking the presence of a SERVICE_ACK parameter with a matching SERVICE_ID in the next packet. The SERVICE_ACK Heer, et al. Expires August 31, 2009 [Page 3] Internet-Draft Hip-Service-ID February 2009 contains the hash of the service offer, allowing the service provider to verify that the user has accepted the terms of service as added by the service provider in the SERVICE_OFFER. Replying with the hash of the complete SERVICE_OFFER ensures that the client adheres to all conditions of the service offer and that the SERVICE_OFFER_UNSIGNED parameter was delivered without modification in transit. Additionally, the service provider SHOULD verify the validity of the signature in the HIP control packet. In order to shelter against Denial-of-Service (DoS) attacks, end-hosts and middleboxes can utilize the puzzle mechanisms specified in [RFC5201] for end-hosts and [I-D.heer-hip-middle-auth] for middleboxes 3.1. HIP Parameters 3.1.1. SERVICE_OFFER and SERVICE_OFFER_UNSIGNED Parameters The SERVICE_OFFER and the SERVICE_OFFER_UNSIGNED have identical structures and semantics. The two parameters differ only in their type numbers. Therefore, we discuss only about the contents of the SERVICE_OFFER parameter while the following specifications concerning the SERVICE_OFFER parameter also apply to the SERVICE_OFFER_UNSIGNED parameter. The SERVICE_OFFER parameter is depicted below. It consists of three parts: 1. SERVICE_PROPERTIES (SP): The SERVICE_PROPERTIES field provides the receiving host with a basic classification of the service based on general parameters. The service properties are an aid for the end-hosts for understanding the nature of an unknown service. 2. SERVICE_ID (SID): The SERVICE_ID is a number that identifies a service or a class of services. The SERVICE_DESCRIPTION is interpreted depending on the SERVICE_ID. The SERVICE_ID MUST be known to all hosts that intend to use that particular service. The SID numbers from 0 to 2^31-1 are assigned by IANA. SID numbers from 2^31 to 2^32-1 are unallocated and may be used by service providers without prior request or notice. 3. SERVICE_DESCRIPTION (SD): The SERVICE_DESCRIPTION field is a variable-length data blob that is interpreted based on the information in the SID field. It MUST be understood by all hosts that intend to use the service. The SD field allows a service to provide specific service-related information. The structure and semantics of the SD field are not part of this document but are specified by the service operators. Heer, et al. Expires August 31, 2009 [Page 4] Internet-Draft Hip-Service-ID February 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SP (SERVICE_PROPERTIES) (32 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (SERVICE_ID) (32 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SD (SERVICE_DESCRIPTION (variable length) / / +-+-+-+-+-+-+-+-+-+-| / | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65334 Length Variable SP Service Properties. A bit field characterizing the service (see below). SID Unique service ID identifying the service or type of service. 0 (zero) to 2^31-1 assigned by IANA, rest unallocated and in free use. SD Service Description and service conditions specified by the service provider and interpreted by the client. Heer, et al. Expires August 31, 2009 [Page 5] Internet-Draft Hip-Service-ID February 2009 SERVICE_PROPERTIES field structure: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0 |REQ COM FOR TER INI ACI ACR CEI CER <--- RESERVED ---> | 1 | <--- RESERVED ---> | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0 REQ - Required: Non adherence to the requested authentication will result in denial of service. 1 COM - Commercial: Use of this service may result in monetary costs. 2 FOR - Forwarding: This service entails forwarding of packets. 3 TER - Terminal: This HIP-aware middlebox is located at the last hop towards the responder. 4 INI - Initial: This HIP-aware middlebox is located at the first hop towards the responder. 5 ACI - ACL Initiator: The HIT of the Initiator must be in the ACL of the service. 6 ACR - ACL Responder: The HIT of the Responder must be in the ACL of the service. 7 CEI - Cert Initiator: Cert from Initiator required. Cert type defined in variable SD field. 8 CER - Cert Responder: Cert from Responder required. Cert type defined in variable SD field. Bits 9 to 32 are reserved for future purposes. 3.1.2. SERVICE_ACK A host that accepts a SERVICE_OFFER or SERVICE_OFFER_UNSIGNED replies with a SERVICE_ACK parameter in its next regular HIP packet. The service acknowledgement contains the SID as reference to the acknowledged service and the hash of the SERVICE_OFFER parameter. The hash is generated by applying SHA-1 hash function to the SERVICE_OFFER or SERVICE_OFFER_UNSIGNED parameter. Heer, et al. Expires August 31, 2009 [Page 6] Internet-Draft Hip-Service-ID February 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SID (Service IDentifier) (32 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SH (Service Hash) (128 bit) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65334 Length 160 bit SID Unique service ID identifying the service or type of service. 0 (zero) to 2^31-1 assigned by IANA, rest unallocated and in free use. SH SHA-1 hash of the accepted SERVICE_OFFER parameter belonging to the SID 4. Applications and Use Cases 4.1. Certificates Middleboxes or end-hosts may require certificates that state that the host is entitled to perform certain actions (e.g. connect to a host, use a certain link, use a certain service) [I-D.ietf-hip-cert]. The HIP CERT parameter allows HIP hosts to transmit certificate information within HIP control packets. However, a host may possess multiple certificates and therefore it must decide which certificate to transmit. End-hosts and middleboxes can require the client to present a certificate by adding a SERVICE_OFFER parameter to the next packer addressed to the client. Setting the CEI bit set indicates that a certificate is required and should be sent on the consequent control packet in order to get service. The type of certificate can be transmitted in the SD field. If the end-host fails in providing sufficient credentials to the service provider it can respond with a NOTIFICATION with Heer, et al. Expires August 31, 2009 [Page 7] Internet-Draft Hip-Service-ID February 2009 BLOCKED_BY_POLICY if the service provider is an end-host or a NOTIFICATION with BLOCKED_BY_POLICY_M if the service provider is a middlebox to signal the error. BLOCKED_BY_POLICY is defined in [RFC5201] and BLOCKED_BY_POLICY_M is defined below. NOTIFY MESSAGES - ERROR TYPES Value ------------------------------ ----- BLOCKED_BY_POLICY 42 The Responder is unwilling to set up an association for policy reasons. BLOCKED_BY_POLICY_M 8192 The middlebox is not willing to service the client for policy reasons. The policy reason for not serving or setting up an association in this case would be a missing or insufficient certificate. 4.2. Quality of Service Services may offer a free basic service and a commercial premium service. In such cases, the service provider can add a SERVICE_OFFER for the premium service and default to the basic service if the client does not send a matching SERVICE_ACK. Alternatively, the service provider can add multiple SERVICE_OFFER parameters to a hip control packets, leaving it to the client to acknowledge the appropriate offer. Further service details (e.g. payment and the quality of the offered services) can be negotiated by using the SERVICE_DETAILS field. By signing the SERVICE_ACK, the end-host agrees to the terms of service. The service provider can use the signed HIP packet containing the SERVICE_ACK as proof that the client has requested the service. It can later use this proof for billing. Service providers MAY send a NOTIFICATION if the client does not respond with a matching SERVICE_ACK by sending either BLOCKED_BY_POLICY (end-host) or BLOCKED_BY_POLICY_M (middlebox) if they decide to deny the service. See section Section 4.1 for the definition of these parameters. Heer, et al. Expires August 31, 2009 [Page 8] Internet-Draft Hip-Service-ID February 2009 5. Security Considerations The question of whether a client must subscribe to a service and the question of whether a service is on the shortest direct path between the Initiator and the Responder is out of scope for this document. However, service operators can design the SERVICE_OFFER parameter in a way that allows semantic sanity checks. For example, a host can detect a suspicios situation if two middleboxes claim to be inital or terminal middleboxes (active INI or TER bits in the SD field of the SERVICE_OFFER parameter). In such cases, end-hosts may require to react based on policies or user interaction. This document makes no assumptions about the authenticity of the SERVICE_OFFER and SERVICE_OFFER_UNSIGNED parameter. Especially the identity of a service provider is not verified. However, should a service require authentication of a service provider, it can implement this in the variable data field in the SERVICE_OFFER and SERVICE_OFFER_UNSIGNED parameter. 6. IANA Considerations This draft specifies a new namespace for service identifiers (SID numbers). The SID numbers from 0 to 2^31-1 are to be assigned by IANA. SID numbers from 2^31 to 2^32-1 are unallocated and may be used by service providers without prior request or notice. The SID numbers in the unmanaged SID number space should be selected in a random fashion. There is no guarantee that the SID numbers in the unmanaged SID space are free from collisions. Service providers that use SID numbers from the unallocated SID space should, therefore, take precautions for cases of collisions. In addition to the SID, a service is described by its SP-flags. To guarantee consistent extensibility of service descriptions, assignment of flags and their positions should also be provided by IANA. 7. Normative References [I-D.heer-hip-middle-auth] Heer, T., Wehrle, K., and M. Komu, "End-Host Authentication for HIP Middleboxes", draft-heer-hip-middle-auth-01 (work in progress), July 2008. [I-D.ietf-hip-cert] Heer, T. and S. Varjonen, "HIP Certificates", Heer, et al. Expires August 31, 2009 [Page 9] Internet-Draft Hip-Service-ID February 2009 draft-ietf-hip-cert-00 (work in progress), October 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008. [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity Protocol (HIP) Registration Extension", RFC 5203, April 2008. Authors' Addresses Tobias Heer (editor) Distributed Systems Group, RWTH Aachen University Ahornstrasse 55 Aachen 52062 Germany Phone: +49 241 80 20776 Email: heer@cs.rwth-aachen.de URI: http://ds.cs.rwth-aachen.de/members/heer Hanno Wirtz Distributed Systems Group, RWTH Aachen University Ahornstrasse 55 Aachen 52062 Germany Phone: +49 241 80 20773 Email: hanno.wirtz@rwth-aachen.de URI: http://ds.cs.rwth-aachen.de/members/wirtz Samu Varjonen Helsinki Institute for Information Technology Metsnneidonkuja 4 Helsinki Finland Fax: +358 969 49768 Email: samu.varjonen@hiit.fi URI: http://www.hiit.fi Heer, et al. Expires August 31, 2009 [Page 10]