Network Working Group S. Krishnan Internet-Draft Ericsson Intended status: Standards Track A. Kukec Expires: January 15, 2009 University of Zagreb K. Ahmed Microsoft July 14, 2008 Certificate Profile for SEND draft-krishnan-cgaext-send-cert-eku-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 January 15, 2009. Krishnan, et al. Expires January 15, 2009 [Page 1] Internet-Draft SEND Certificate Profile July 2008 Abstract Secure Neighbor Discovery (SEND) Utilizes X.509v3 certificates for performing router authorization. This document specifies a certificate profile for SEND including extended key usage values, revocation details and supported extensions. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Extended Key Usage Values . . . . . . . . . . . . . . . . . . 5 4. Certificate Revocation . . . . . . . . . . . . . . . . . . . . 7 5. Certificate Extensions . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Krishnan, et al. Expires January 15, 2009 [Page 2] Internet-Draft SEND Certificate Profile July 2008 1. Requirements notation 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]. Krishnan, et al. Expires January 15, 2009 [Page 3] Internet-Draft SEND Certificate Profile July 2008 2. Introduction Secure Neighbor Discovery [RFC3971] Utilizes X.509v3 certificates for performing router authorization. It uses the X.509 extension for IP addresses to verify whether the router is authorized to advertise the mentioned IP addresses. Since the IP addresses extension does not mention what functions the node can perform for the IP addresses it becomes impossible to know the reason for which the certificate was issued. In order to facilitate issuance of certificates for specific functions, it is necessary to utilize the ExtKeyUsageSyntax field of the X.509 certificate to mention the purpose for which the certificate was issued. This document specifies three extended key usage values, one for routers, one for proxies, and one for address owners, for use with SEND. The SEND specification does not describe a revocation mechanism for SEND certifications. This document describes a revocation mechanism for SEND certificates that uses OCSP [RFC2560] Finally, this document defines the set of certificate extensions that a SEND capable node needs to support in addition to what has been defined in [RFC3280]. Krishnan, et al. Expires January 15, 2009 [Page 4] Internet-Draft SEND Certificate Profile July 2008 3. Extended Key Usage Values The Internet PKI document [RFC3280] specifies the extended key usage X.509 certificate extension. The extension indicates one or more purposes for which the certified public key may be used. The extended key usage extension can be used in conjunction with key usage extension, which indicates the intended purpose of the certified public key. The extended key usage extension syntax is repeated here for convenience: ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId KeyPurposeId ::= OBJECT IDENTIFIER This specification defines three KeyPurposeId values: one for authorizing routers, one for authorizing proxies, and one for address owners. The inclusion of the router authorization value indicates that the certificate has been issued for allowing the router to advertise prefix(es) that are mentioned using the X.509 extensions for IP addresses and AS identifiers [RFC3779] The inclusion of the proxy authorization value indicates that the certificate has been issued for allowing the proxy to perform proxying of neighbor discovery messages for the prefix(es) that are mentioned using the X.509 extensions for IP addresses and AS identifiers [RFC3779] The inclusion of the owner authorization value indicates that the certificate has been issued for allowing the node to use the address(es) or prefix(es) that are mentioned using the X.509 extensions for IP addresses and AS identifiers [RFC3779] Inclusion of multiple values indicates that the certified public key is appropriate for use by a node performing more than one of these functions. send-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) TBA1 } id-kp-sendRouter OBJECT IDENTIFIER ::= { send-kp 1 } id-kp-sendProxy OBJECT IDENTIFIER ::= { send-kp 2 } Krishnan, et al. Expires January 15, 2009 [Page 5] Internet-Draft SEND Certificate Profile July 2008 id-kp-sendOwner OBJECT IDENTIFIER ::= { send-kp 3 } The extended key usage extension MAY, at the option of the certificate issuer, be either critical or non-critical. Certificate-using applications MAY require the extended key usage extension to be present in a certificate, and they MAY require a particular KeyPurposeId value to be present (such as id-kp-sendRouter or id-kp-sendProxy) within the extended key usage extension. If multiple KeyPurposeId values are included, the certificate-using application need not recognize all of them, as long as the required KeyPurposeId value is present. Krishnan, et al. Expires January 15, 2009 [Page 6] Internet-Draft SEND Certificate Profile July 2008 4. Certificate Revocation Contrary to unbounded CRL sizes, OCSP response is bounded and small, and OCSP statements can be bounded with the certificate itself in the Certification Path messages eliminating the need for the relying party at one end to have a network connection. Thus, SEND should use inband revocation checking supported by the OCSP [RFC2560]. In order to support OCSP in SEND, this document defines new options in the Certification Path Solicitation message, as well as in Certification Path Advertisement message. The Certification Path Solicitation message would then have the following options. o Trust Anchor: TA which the client is willing to accept o OCSP Responder: The hash of the OCSP Responders public key trusted by the client, or the concatenated list of hashes of more OCSP Responders' public keys. The client could define only one OCSP Responder by each CPS message, to ensure easier matching of OCSP request and response, based on Identifier field in Certification Path Advertisement. However, it is more appropriate to send more OCSP responders in one CPS message, since it is possible to match certificate and corresponding OCSP response by matching the target certificate identifier from the OCSP response to the corresponding certificate. The Certification Path Advertisement message would have the following options. o Certificate o Trust Anchor: to help the client to find out which advertisement is useful o OCSP response: A definitive OCSP response message containing the response for each of the certificates from the request as specified in Section 2.2 of [RFC2560]. o OCSP responder: to help the client to find out which advertisement is useful. The problem for the client is that when it is in the process of forming the CPS message, it does not have certificates for which it is sending the OCSP request. Thus, it can not form the OCSP request as described in [RFC2560]. However, the client can work around this Krishnan, et al. Expires January 15, 2009 [Page 7] Internet-Draft SEND Certificate Profile July 2008 problem using the hashes of OCSP responders. This problem is also described in Section 5.1 of [RFC4806]. After the receipt of Solicitation Path Advertisement with OCSP response, the client can start with the OCSP response path validation logic defined in [RFC3280]. Before the end of this validation procedure, all certificates MUST be considered as provisional, and the client must perform this validation as soon as it connects to Internet, as described in [RFC3971]. Krishnan, et al. Expires January 15, 2009 [Page 8] Internet-Draft SEND Certificate Profile July 2008 5. Certificate Extensions This paragraph describes certificate extensions that a compliant SEND implementation MUST support and set the criticality bit: Subject Alternative Name, Extended Key Usage, Key Usage, Basic Constraints and Authority Information Access. Each compliant implementation SHOULD mark the following extensions as critical: Key Usage, Extended Key Usage, Subject Alternative Name and Basic Constraints. The Authority Information Extension MUST NOT be marked as critical. An implementation MUST reject all unrecognized critical extensions and MUST ignore all unrecognized non-critical extensions, as described in [RFC3280]. The Subject Alternative Name extension (type iPAddress) contains the subnet prefix that the router is authorized to advertize. It is described in [RFC3971]. It SHOULD be marked as critical, as it is possible that some certificates in the beginning does not contain this extension. In such scenarios the validation of subjectAltName iPAddress delegation extension MAY be relaxed. The Extended Key Usage extension defines the application or protocol specific purposes for which the certificate key pair may be used. It is described in Section 3. It MUST be marked as critical. The Key Usage extension defines the basic purposes for which the key pair may be used. The Router Authorization Certificate MUST have at least the digitalSignature and nonRepudiation bits set, since it's key pair is used for the CGA generation and Router Advertisement signing. Other certificates would usually have set the keyCertSign bit set. This extension MUST be marked as critical and MUST be processed independently of the Extended Key Usage extension. The certificate purpose must be consistent with both the Extended Key Usage extension and the Key Usage extension. The Basic Constraints extension defines specifies whether the subject of the certificates is a CA or an end entity, as well as the maximum depth of valid certification path. In accordance with [RFC3280], it MUST be marked as critical. The Authority Information Access extension specifies how to retrieve additional CA information, e.g. the information about the OCSP responder. It MUST be marked as non-critical and usually the host will learn the OCSP responder from the configuration file. Krishnan, et al. Expires January 15, 2009 [Page 9] Internet-Draft SEND Certificate Profile July 2008 6. Security Considerations The certification authority needs to ensure that the correct values for the extended key usage are inserted in each certificate that is issued. Relying parties may accept or reject a particular certificate for an intended use based on the information provided in these extensions. Incorrect representation of the information in the extended key usage field can cause the relying party to reject an otherwise appropriate certificate or accept a certificate that ought to be rejected. Krishnan, et al. Expires January 15, 2009 [Page 10] Internet-Draft SEND Certificate Profile July 2008 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999. [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. [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status Protocol (OCSP) Extensions to IKEv2", RFC 4806, February 2007. Krishnan, et al. Expires January 15, 2009 [Page 11] Internet-Draft SEND Certificate Profile July 2008 Authors' Addresses Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada Phone: +1 514 345 7900 x42871 Email: suresh.krishnan@ericsson.com Ana Kukec University of Zagreb Unska 3 Zagreb Croatia Email: ana.kukec@fer.hr Khaja Ahmed Microsoft Email: khaja@windows.microsoft.com Krishnan, et al. Expires January 15, 2009 [Page 12] Internet-Draft SEND Certificate Profile July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Krishnan, et al. Expires January 15, 2009 [Page 13]