Internet Engineering Task Force J. Pellikka Internet-Draft Centre for Wireless Intended status: Experimental Communications, University of Expires: October 17, 2011 Oulu April 15, 2011 HIP Certificate Requests draft-pellikka-hiprg-certreq-01 Abstract This memorandum describes how the HIP control packets can be used to send requests for preferred certificates to the correspondent hosts, and also requests for a Certification Authority (CA) to issue a certificate. The document specifies two new HIP parameters CERT_REQ and CERT_SIGN_REQ and describes their use. The means as to how to signal an error in case of the desired certificate is not available is also discussed. The syntax of certificates and certificate requests is out of scope of the document and defined elsewhere. 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 October 17, 2011. Copyright Notice Pellikka Expires October 17, 2011 [Page 1] Internet-Draft HIP CERTREQ April 2011 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 Host Identity Protocol (HIP) [RFC5201] is a mobility and multihoming protocol, which separates the end-point identifier and locator roles of the IP address, and introduces a new namespace based on public-key cryptography. As HIP hosts are effectively identified by their public keys and are able to sign information with their private keys, relevant information associated to the hosts, as well as their identities can be certified by a trusted 3rd party. Trusted 3rd party is commonly referred to as Certification Authority (CA), which is a centralized trust anchor responsible for managing and issuing certificates, i.e. digital documents that bind the holder's public key and/or a set of attributes with the holder's identity. To access a service or a resource under the control of a CA, a host is typically required to proof its identity and that it has the right to access the particular service or resource. This is commonly performed as part of authentication and authrorization process, where certificates are exchanged between the host and an authenticator entity. This memorandum describes how HIP Base Exchange (BEX) and other control packets can be harnessed to 1) request for a desired type of certificate from a peer host, and to 2) request for signing of a certificate by an accepted CA. It specifies two new HIP parameters CERT_REQ and CERT_SIGN_REQ for these two purposes, respectively. The parameters are jointly used with the CERT parameter, which conveys the actual certificate request. Description as to how to use the CERT parameter to carry certificates is described in detail in [I-D.ietf-hip-cert]. Pellikka Expires October 17, 2011 [Page 2] Internet-Draft HIP CERTREQ April 2011 2. Certificate Request Parameters 2.1. CERT_REQ Parameter The CERT_REQ parameter provides a HIP host with a mechanism to request its peer to send a preferred certificate via HIP control packets. The CERT_REQ parameter MAY be used in all HIP packets, although including it in I1 packets is NOT RECOMMENDED for it can increase the processing burden on the receiving host and expose the host to Denial-of-Service (DoS) attacks. Naturally, should a host receive an I1 packet with a CERT_REQ parameter, it is RECOMMENDED the host to ignore it. CERT_REQ is included in HIP SIGNATURE, if present in the HIP packet, and is a non-critical parameter. The CERT_REQ parameter is not intended as a placeholder for the request message, but rather to indicate the desire to obtain a certificate from the peer host and to convey a list of preferred CAs for it. The actual certificate request is conveyed in the CERT parameter, which specifies the desired certificate type, as well as certificate fields and values. Typically, the certificate payload in the CERT parameter would contain a self-signed certificate. However, the semantics of such a certificate is outside the scope of this memorandum and discussed elsewhere. The purpose of this document is merely to provide a generic mechanism for requesting certificates of peers. Pellikka Expires October 17, 2011 [Page 3] Internet-Draft HIP CERTREQ April 2011 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cert group | CA count | CA ID | CA type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Certification Authority / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length Size in octets, excluding Type, Length, and Padding Cert group Value grouping multiple CERT_REQ and CERT parameters CA count Total number of CERT_REQ parameters in the request CA ID Sequence number for this particular CERT_REQ parameter CA type Defines the format the CA indication is expressed in Padding To make the TLV a multiple of 8 bytes (if needed) The following CA indication types are defined: +--------------------------------+-------------+ | CA indication format | Type number | +--------------------------------+-------------+ | Reserved | 0 | | HIT | 1 | | SHA-1 hash | 2 | +--------------------------------+-------------+ A HIP control packet MAY contain multiple CERT_REQ parameters that MAY be related to each other. Related CERT_REQ parameters are managed and grouped together through the Cert group field, whose value defines the list of accepted CAs belonging to the same certificate request. Related CERT_REQ parameters with the same Cert group value SHOULD be interpreted in the order of preference, and they MUST have the CA count field set to the total number of accepted CAs in the list. Parameters not belonging to the same request MUST have separate unique values in their Cert group fields, i.e. they MUST NOT share the same Cert group namespace. A successful certificate request MUST consist of at least one related CERT_REQ and CERT parameter. A shared value in the Cert group fields of these two parameters define them as belonging to the same certificate request. One request MAY contain several CERT parameters, e.g. for specifying alternatives for certificate types and certificate values. In this case, the fields of the CERT parameters MUST be set as specified in [I-D.ietf-hip-cert]. Pellikka Expires October 17, 2011 [Page 4] Internet-Draft HIP CERTREQ April 2011 The CA ID field contains a unique sequence number that identifies the CA within a Cert group. The first CERT_REQ parameter in a request MUST always have value 1, and the last parameter MUST be equal to the value in the CA count field. The Certificate Authority field contains an indication of an accepted CA in the certificate request. The encoding of this field is defined by the CA type field. SHA-1 refers to an encoding where the indication of the CA is expressed by a SHA-1 hash taken over the Subject Public Key Info element in the CA's certificate as descibed in [RFC3280]. HIT, in turn, refers to an encoding where the CA is expressed by a HIT. This HIT SHOULD be exactly the same HIT that identifies the CA in the CA certificate. 2.2. CERT_SIGN_REQ Parameter The CERT_SIGN_REQ parameter allows a HIP host to request for issuance of a certificate (e.g. short-lived attribute certificate) for the host itself through HIP control packets. The CERT_SIGN_REQ parameter is intended to be included in the BEX packets, but in addition to packets I1, R1, I2, and R2, the parameter MAY be included in other HIP control packets as well. CERT_SIGN_REQ is included in HIP SIGNATURE, if present in the HIP packet, and is a non-critical parameter. Pellikka Expires October 17, 2011 [Page 5] Internet-Draft HIP CERTREQ April 2011 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cert group | CA count | CA ID | CA type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Certification Authority / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length Size in octets, excluding Type, Length, and Padding Cert group Value grouping multiple CERT_SIGN_REQ and CERT params CA count Number of CERT_SIGN_REQ parameters in the request CA ID Sequence number for this particular parameter CA type Defines the format the CA indication is expressed in Padding To make the TLV a multiple of 8 bytes (if needed) The use of the CERT_SIGN_REQ parameter fields are described in detail in section 2.1. The available values for the CA type field are also defined in this section. 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 can be used with both CERT_REQ and CERT_SIGN_REQ parameters. Pellikka Expires October 17, 2011 [Page 6] Internet-Draft HIP CERTREQ April 2011 NOTIFICATION PARAMETER - ERROR TYPES Value ------------------------------------ ----- CERTIFICATE_NOT_AVAILABLE TBD 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 fulfill. In case of, e.g. erroneous certificate data was received in the CERT parameter, a host can use the CERT parameter specific error signaling mechanisms defined in [I-D.ietf-hip-cert]. 4. IANA Considerations This memorandum specifies two new parameters to Host Identity Protocol (HIP) [RFC5201]: CERT_REQ and CERT_SIGN_REQ. These parameters are defined in sections 2.1 and 2.2, respectively. Two new type numbers need to be defined and included to the "Host Identity Protocol (HIP) Parameters" registry by IANA. The CERT_REQ and CERT_SIGN_REQ parameters contain a 8-bit unsigned integer field for a certification authority type. The type values need to be maintained in a new sub-registry referred to as "HIP certificate authority types" under the "Host Identity Protocol (HIP) Parameters" by IANA. Section 3 specifies a new type CERTIFICATE_NOT_AVAILABLE for the "NOTIFY message types" sub-registry under "Host Identity Protocol (HIP) Parameters". This value also needs to be defined by IANA. 5. Security Considerations It is NOT RECOMMENDED to attach the CERT_REQ or CERT_SIGN_REQ parameters to the I1 packet. If a host was to receive an I1 packet with either of these parameters, the host SHOULD ignore the packet and proceed with the BEX as normal. Processing the CERT_REQ and CERT_SIGN_REQ parameters requires the receiver to consume CPU cycles and memory, and possibly to create a state. Thus, handling these parameters before the requestor host has been properly authenticated is NOT RECOMMENDED, as it is possible to mount a DoS attack using the parameters. Pellikka Expires October 17, 2011 [Page 7] Internet-Draft HIP CERTREQ April 2011 6. Acknowledgements The authors would like to thank A. Gurtov for the fruitful conversations on the subject of this document, and especially T. Heer and S. Varjonen for their valuable comments and suggestions. 7. Normative References [I-D.ietf-hip-cert] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", draft-ietf-hip-cert-12 (work in progress), March 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [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 October 17, 2011 [Page 8]