Internet Engineering Task Force J. Pellikka
Internet-Draft Centre for Wireless
Intended status: Experimental Communications, University of Oulu
Expires: May 16, 2011 November 12, 2010
HIP Certificate Requests
draft-pellikka-hiprg-certreq-00
Abstract
This memorandum describes how the HIP control packets can be used to
send requests for preferred certificates to the correspondent hosts.
This document specifies a new CERTREQ parameter and describes its use
in requesting an issuance of certificates from accepted Certification
Authorities (CAs). This document focuses on the means as to how to
request for a certificate, and how to signal an error in case of the
desired certificate is not available. The syntax of certificates and
certificate requests is out of scope of this document.
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 RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted 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, and it may not be
published except as an Internet-Draft.
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."
This Internet-Draft will expire on May 16, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Pellikka Expires May 16, 2011 [Page 1]
Internet-Draft HIP CERTREQ November 2010
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
Certificate requests are authorized requests for an authority to
issue a certificate, which binds the identity and other relevant
information on the requestor to its public key. These requests
typically contain the public key of the requestor along with
registration information to be associated with the certificate by a
trusted Certification Authority (CA).
Host Identity Protocol (HIP) [RFC5201] is a mobility and multihoming
protocol, which separates the end-point-identifier and locator roles
of IP address. The protocol introduces a new cryptographic namespace
based on the public/private key cryptography. As HIP-capable hosts
are effectively identified by public keys and they are able to sign
information with their private key, their identity along with other
host related information can be verified by a trusted 3rd party.
This memorandum describes how HIP control packets can be harnessed to
transmit requests for desired type of certificates of an authority
accepted by the requestor. The document specifies a new CERTREQ
parameter to convey the certificate requests and describes its
combined use with the CERT parameter, a placeholder for the
certificate and certificate request related data. How to use the
CERT parameter to convey digital certificates is specified in
[I-D.ietf-hip-cert].
2. CERTREQ Parameter
The CERTREQ parameter provides HIP hosts with a means to request
preferred certificates via the HIP control packets. The CERTREQ
parameter MAY be included in the HIP Base Exchange (BEX) packets
(i.e. I1, R1, I2, R2) or other HIP control packets transmitted after
the communicating hosts have successfully authenticated one another.
It is, however, NOT RECOMMENDED to include a CERTREQ parameter in the
Pellikka Expires May 16, 2011 [Page 2]
Internet-Draft HIP CERTREQ November 2010
I1 packet, nor it is NOT RECOMMENDED to process the parameter if
present in the I1 packet.
A bit confusingly, the CERTREQ parameter is not to hold the actual
certificate request, but instead carries the type of the requested
certificate and a list of accepted CAs for it. The request for the
desired certificate values is conveyed inside the CERT parameter.
The syntax of this request is certificate type specific and thus is
not described in this document. The CERTREQ parameter is included in
HIP SIGNATURE, when present in the HIP packet.
The CERTREQ parameter is defined below. The fields Cert group, Cert
count, Cert ID, and Cert type has been previously defined in
[I-D.ietf-hip-cert] and their use conforms to what has been described
in that document. The use case described by this document, however,
maps the CERT and CERTREQ parameters in the same logical group by
sharing the same value in the Cert group field.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert group | Cert count | Cert ID | Cert type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certification Authority /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 770
Length Size in octets, excluding Type, Length, and Padding
Cert group Group ID grouping multiple related CERTREQ parameters
Cert count Total number of CERTREQ parameters in one request
Cert ID Sequence number for this CERTREQ parameter
Cert type Indicates the type for the requested certificate
Padding To make the TLV a multiple of 8 bytes (if needed)
As CERT and CERTREQ parameters are related, the Cert group field
provides a means to define the two parameters as belonging to the
same request. The value in the Cert ID field uniquely identifies a
CERTREQ parameter in the group, while the Cert count indicates the
total number of CERTREQ field belonging to the certificate request.
In other words, the namespace of Cert IDs are separate between the
CERT and CERTREQ parameters. In order to transmit a successful
request, at least one CERTREQ and one CERT parameter sharing the same
value in their Cert group fields MUST be transmitted. The Cert count
field is set to indicate the total count of CERTREQ parameters
Pellikka Expires May 16, 2011 [Page 3]
Internet-Draft HIP CERTREQ November 2010
belonging to the request. The values of the Cert ID and Cert group
fields MUST start from 1 and their namespaces are locally managed by
the host transmitting certificate requests in the HIP control
packets.
The Certificate Type field has the same values as those defined in
[I-D.ietf-hip-cert]. The Certificate Authority field contains an
indicator of trusted CAs for the certificate type. The field
contains a concatenation of all accepted CAs by order of preference,
listing the most preferred CA first. The encoding of each CA
indication is a SHA1 hash over the public key indicated in the
certificate of the CA in question. The hashes are appended without
any delimiters or other formatting. If the certificate type does not
explicitly allow a concatenated list as a payload, each accepted CA
MAY be included in separate CERTREQ parameters carried by the same or
sequential HIP control packets. Also in this case, the CAs are
listed by order of preference using the Cert ID field as an
identifier.
3. Error Signaling
If the requestee is prevented from delivering the desired kind of
certificate to the requestor, it MAY signal this by transmitting a
HIP NOTIFY packet with the error type of the NOTIFICATION parameter
set to CERTIFICATE_NOT_AVAILABLE. The CERTIFICATE_NOT_AVAILABLE
error type can be carried in the NOTIFICATION parameter of other HIP
packets as well. The CERTIFICATE_NOT_AVAILABLE error type is defined
as follows.
NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ -----
CERTIFICATE_NOT_AVAILABLE 52
Transmitted if the requestee is not able to deliver
a certificate of the requested type or a certificate
issued by any of the CAs accepted by the requestor.
Notification Data contains an octet, i.e. Cert group
to identify the request that the requestee was not
able not fulfil.
The CERTREQ parameter should not be considered as a mandate for a
certain type of certificate, but merely as a suggestion from the
requestor. Therefore, if the requestee is unable to deliver the
desired kind of certificate, this SHOULD NOT necessarily be
considered as error and the operation of the HIP protocol SHOULD
proceed as normal. In some cases where, e.g. a HIP host is
Pellikka Expires May 16, 2011 [Page 4]
Internet-Draft HIP CERTREQ November 2010
configured to require a certificate for a successful authentication
and authorization, it MAY, however, be required to terminate the BEX
or ongoing HIP session with the correspondent host if desired
credentials cannot be obtained.
4. IANA Considerations
This memorandum specifies the CERTREQ parameter for Host Identity
Protocol (HIP) [RFC5201]. The parameter is defined in Section 2 of
this document and identified by type 770. The assigned type number
needs to be confirmed and included to the "Host Identity Protocol
(HIP) Parameters" registry by IANA.
The CERTREQ parameter contains a 8-bit unsigned integer field for a
certificate type. The certificate types are maintained in a sub-
registry referred to as "HIP certificate types" under the "Host
Identity Protocol (HIP) Parameters" by IANA. This document conforms
with the certificate type values defined by [I-D.ietf-hip-cert] and
does not specify any additional values. It is assumed that the
values for certificate types are maintained in that particular
document.
Finally, in Section 3, this memorandum specifies a new type
CERTIFICATE_NOT_AVAILABLE for the "NOTIFY message types" sub-registry
under "Host Identity Protocol (HIP) Parameters". Its value is
specified as 52.
5. Security Considerations
The CERTREQ parameter SHOULD NOT be attached to the I1 packet of BEX.
If the Responder was to receive an I1 packet with a CERTREQ
parameter, it SHOULD ignore it and proceed with the BEX as normal.
The handling of CERTREQ parameter requires the Responder to utilize
CPU and memory, and therefore handling the parameter before the
correspondent host is authenticated would allow a Denial of Service
(DoS) attack toward the Responder.
6. Acknowledgements
The authors would like to thank A. Gurtov for fruitful conversations
on the subject of this document.
Pellikka Expires May 16, 2011 [Page 5]
Internet-Draft HIP CERTREQ November 2010
7. Normative References
[I-D.ietf-hip-cert]
Heer, T. and S. Varjonen, "Host Identity Protocol
Certificates", draft-ietf-hip-cert-05 (work in progress),
November 2010.
[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.
Author's Address
Jani Pellikka
Centre for Wireless Communications, University of Oulu
P.O. Box 4500, FI-90014
Oulu,
Finland
Phone: +358 8 553 2965
Email: jani.pellikka@ee.oulu.fi
URI: http://www.cwc.oulu.fi
Pellikka Expires May 16, 2011 [Page 6]