[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00 01
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]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/