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]