Internet DRAFT - draft-heer-hip-service
draft-heer-hip-service
Host Identity Protocol T. Heer
Internet-Draft H. Wirtz
Intended status: Experimental RWTH Aachen University,
Expires: March 7, 2012 Communication and Distributed
Systems Group
Varjonen
Helsinki Institute for
Information Technology
September 4, 2011
Service Identifiers for HIP
draft-heer-hip-service-01
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].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
Heer, et al. Expires March 7, 2012 [Page 1]
Internet-Draft Hip-Service-ID September 2011
This Internet-Draft will expire on March 7, 2012.
Copyright Notice
Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
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 March 7, 2012 [Page 2]
Internet-Draft Hip-Service-ID September 2011
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 or SERVICE_OFFER_UNSIGNED
to an R1, I2, R2, or UPDATE packet. In addition, the
SERVICE_OFFER_UNSIGNED can also be aded to I1 packets. 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 and if the service requires an acknowledgement
(indicated by a set ACK bit in the parameter), 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 or no
acknowledgement is required, 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
Heer, et al. Expires March 7, 2012 [Page 3]
Internet-Draft Hip-Service-ID September 2011
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
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
Heer, et al. Expires March 7, 2012 [Page 4]
Internet-Draft Hip-Service-ID September 2011
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.
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 970 (SERVICE OFFER SIGNED)
65334 (SERVICE OFFER UNSIGNED)
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 March 7, 2012 [Page 5]
Internet-Draft Hip-Service-ID September 2011
SERVICE_PROPERTIES field structure:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 |REQ ACK COM FOR TER INI ACI ACR CEI CER AUT <--- RESERVED ---> |
1 | <--- RESERVED ---> |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 REQ - Required: Non adherence to the requested
authentication will result in denial of
service.
1 ACK - Acknowledgement: The service requires a signed
acknowledgement in a SERVICE_ACK parameter.
2 COM - Commercial: Use of this service may result in monetary
costs.
3 FOR - Forwarding: This service entails forwarding of packets.
4 TER - Terminal: This HIP-aware middlebox is located at the
last hop towards the responder.
5 INI - Initial: This HIP-aware middlebox is located at the
first hop towards the responder.
6 ACI - ACL Initiator: The HIT of the Initiator must be in the ACL
of the service.
7 ACR - ACL Responder: The HIT of the Responder must be in the ACL
of the service.
8 CEI - Cert Initiator: Cert from Initiator required. Cert type
defined in variable SD field.
9 CER - Cert Responder: Cert from Responder required. Cert type
defined in variable SD field.
10 AUT - Additional Auth: Additional authentication measures are
required. Authentication type defined in
variable SD field.
Bits 10 to 31 are reserved for future purposes.
Heer, et al. Expires March 7, 2012 [Page 6]
Internet-Draft Hip-Service-ID September 2011
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.
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 974
Length 160 bit
SID Unique service ID identifying the service or type of
service. 0 (zero) to 2^31-1 assigned by IANA, the rest
is 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
Heer, et al. Expires March 7, 2012 [Page 7]
Internet-Draft Hip-Service-ID September 2011
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.
Likewise, an end-host or middlebox can inform a HIP host that
additional authentication measures (e.g., password authentication
[I-D.varjonen-hip-eap]) must be performed during or after the base
exchange. By setting the REQ and FOR bits, the middlebox or end-host
can express that forwarding of payload packet will not be performed
until the authentication is completed. The exact type of
authentication is expressed in the variable SD field.
If the end-host fails in providing sufficient credentials to the
service provider it can respond with a NOTIFICATION with
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
Heer, et al. Expires March 7, 2012 [Page 8]
Internet-Draft Hip-Service-ID September 2011
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.
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_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.
Using a SERVICE_OFFER_UNSIGNED parameter in an I1 packet with a set
ACK bit may require the Responder to echo the relevant
SERVICE_OFFER_UNSIGNED parts in a SERVICE_ACK parameter. This may
require the Responder to generate a live signature for the R2 packet
and makes the use of pre-created R1 packets impossible. Hence, the
Responder SHOULD treat such I1 packets with lower priority.
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
Heer, et al. Expires March 7, 2012 [Page 9]
Internet-Draft Hip-Service-ID September 2011
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.
This draft requires three new HIP parameter numbers. Two within the
signed part of the HIP packets (970 and 974) and one ithin the
unsigned part of the packet (65334).
7. Changelog
7.1. Version 1
- Fixed broken parameter numbers.
- Extended IANA consideration to accomodate new parameter numbers.
- Added reference to draft-varjonen-hip-eap-00.
- Added AUT bit for additional authentication (see eap).
- Added text to security considerations about SERVICE_OFFER_UNSIGNED
in I1.
8. 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-02 (work in progress),
February 2009.
[I-D.ietf-hip-cert]
Heer, T. and S. Varjonen, "Host Identity Protocol
Certificates", draft-ietf-hip-cert-12 (work in progress),
March 2011.
[I-D.varjonen-hip-eap]
Heer, et al. Expires March 7, 2012 [Page 10]
Internet-Draft Hip-Service-ID September 2011
Varjonen, S., "HIP and User Authentication",
draft-varjonen-hip-eap-00 (work in progress), July 2009.
[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
RWTH Aachen University, Communication and Distributed Systems Group
Ahornstrasse 55
Aachen 52062
Germany
Email: heer@cs.rwth-aachen.de
URI: http://www.comsys.rwth-aachen.de/team/tobias-heer/
Hanno Wirtz
RWTH Aachen University, Communication and Distributed Systems Group
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
Gustaf Haellstroemin katu 2b
Helsinki
Finland
Email: samu.varjonen@hiit.fi
URI: http://www.hiit.fi
Heer, et al. Expires March 7, 2012 [Page 11]
