[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/