Network Working Group S. Krishnan
Internet-Draft Ericsson
Intended status: Standards Track A. Kukec
Expires: January 3, 2010 University of Zagreb
R. Gagliano
LACNIC
July 2, 2009
Certificate profile and certificate management for SEND
draft-ietf-csi-send-cert-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 3, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Krishnan, et al. Expires January 3, 2010 [Page 1]
Internet-Draft SEND certificate profile and management July 2009
Abstract
Secure Neighbor Discovery (SEND) Utilizes X.509v3 certificates for
performing router authorization. This document specifies a
certificate profile for SEND based on Resource Certificates along
with extended key usage values required for SEND.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Certificate Management . . . . . . . . . . . . . . . . . . . . 7
5.1. Per-ISP SEND model . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Support for OCSP in SEND . . . . . . . . . . . . . . . 8
5.2. RPKI SEND model . . . . . . . . . . . . . . . . . . . . . 9
6. Certificate profile . . . . . . . . . . . . . . . . . . . . . 10
6.1. Extended Key Usage Values . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Krishnan, et al. Expires January 3, 2010 [Page 2]
Internet-Draft SEND certificate profile and management July 2009
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 3, 2010 [Page 3]
Internet-Draft SEND certificate profile and management July 2009
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 also does not describe a revocation mechanism
for SEND certificates. This document describes different possible
solutions for the certificate management, as well as certificate
profile for certificates that a SEND capable node needs to support in
addition to what has been defined in [RFC5280].
Krishnan, et al. Expires January 3, 2010 [Page 4]
Internet-Draft SEND certificate profile and management July 2009
3. Terminology
End entity certificates issued in support of SeND MUST comply with
the RPKI resource profile [res-certificate-profile]. CA certificates
used to verify these router (EE) certificates also MUST comply with
this profile. This implies that these CA certificates MUST contain
at an RFC 3779 address extension representing the address space
allocations held by the service provider represented by the CA.
Relying parties (e.g., user devices that implement SeND and process
these router certificates) MUST be configured with one or more trust
anchors, to enable validation of the router certificates. These
trust anchors MAY be the default trust anchors defined for the RPKI,
or they MAY be self-signed (CA) certificates associated with the
service providers operating the routers in question. In either case,
it is RECOMMENDED that the RPKI trust anchor representation defined
in [res-certificate-profile] be employed.
Because of the flexibility afforded service through (local) trust
anchor configuration, certificates used for SeND support can be
issued prior to issuance of RPKI certificates under the global
address allocation hierarchy. Note, however, that a CA certificate
issued independently of the global RPKI will have to be reissued in
order to integrate a local PKI with the global RPKI.
Krishnan, et al. Expires January 3, 2010 [Page 5]
Internet-Draft SEND certificate profile and management July 2009
4. Terminology
SEND certificates Certificates described in [RFC3971] and
extended in this document. They belong
either to SEND routers or Secure Proxy ND
nodes:
* Router Authorization Certificate and
parent certificates in the Authorization
Delegation chain. There is no
difference in the profile of the Router
Authorization Certificate and other
(parent) certificates in the
Authorization Delegation process.
* Secure Proxy ND certificates for ND
Proxy, Mobile IPv6 Home Agent or Proxy
Mobile Access Gateway
[draft-ietf-csi-proxy-send-00].
SIDR RPKI certificates Certificates defined in
[draft-ietf-sidr-res-certs-16].
RPKI SIDR PKI hierarchy established in
accordance with [draft-ietf-sidr-arch-00]
whose Trust Anchors are entities which
provide administrative control of the IP
address space (IANA, RIRs).
SEND PKI PKI hierarchy used by SEND.
SEND RPKI SEND PKI established as part of the bigger
SIDR RPKI.
Krishnan, et al. Expires January 3, 2010 [Page 6]
Internet-Draft SEND certificate profile and management July 2009
5. Certificate Management
A certification path in SEND is transported in Certification Path
Advertisement (CPA) message sent from a router to SEND host. CPA
message is sent in reply to the Certification Path Solicitation
message (CPS) message. The certification path sent in CPA message is
a path between a router and SEND host's trust anchor and it might be
potentially voluminous. Thus, CPA and CPS messages are kept separate
from the rest of SEND messages.
SEND specification does not define any certificate management
routines (certific ate issuance and revocation). The only two
routines described in SEND specification are the Certificate path
validation and IP address extension verification.
This document explains two possible solutions for the SEND Public Key
Infrastructure (SEND PKI). The certificate management and
certificate profile will depend on the type of SEND PKI:
o Per-ISP (ISP-centric) PKI model (with CRL based revocation),
o SEND PKI being a part of the bigger RPKI (with OCSP based
revocation).
5.1. Per-ISP SEND model
The Per-ISP PKI model is a model with isolated ISP-centric PKI
islands. It does not have any prerequisites on certificate
revocation or certificate profile, contrary to RPKI model which uses
only CRLs (not even delta CRLs) and has defined certificate profile
[draft-ietf-sidr-res-certs-11]. Per-ISP PKI model could use in-band
revocation and OCSP. Two main advantages of OCSP over CRL in the
SEND context are:
o The size of the CRL is potentially large and unbounded, and would
be too big to carry in a CPA message.
o The relying party (SEND host) at the instant of receiving of CPA
message does not have an access to Internet. The SEND router
receives an OCSP response from OCSP responder and forwards it to
the SEND non-router node. With CRLs, the relying part would have
to accept certificates from the CPA message, consider them as
provisional and perform revocation out-of-band later when it gains
the Internet access.
The disadvantage of this model is that it represents a local PKI
where the mobile users would be ill-served, not knowing the the Trust
Anchors in the visited local PKI.
Krishnan, et al. Expires January 3, 2010 [Page 7]
Internet-Draft SEND certificate profile and management July 2009
5.1.1. Support for OCSP in SEND
This section suggests the solution for the support of OCSP in SEND.
It defines new options in the Certification Path Solicitation
message, as well as in the Certification Path Advertisement message.
The Certification Path Solicitation message would then have the
following options.
o Trust Anchor: Trust Anchors, as defined in Section 6.4.3 of
[RFC3971], which the client is willing to accept
o OCSP Responder: The hash of a trusted OCSP responder's public key
or a concatenated list of hashes of more OCSP Responders' public
keys.
The client (non-router SEND node) sends multiple OCSP responder
hashes in one CPS message, rather than one OCSP Responder per CPS
message. Matching of certificate waiting for validation with the
corresponding OCSP response can be achieved by matching the target
certificate identifier from the OCSP response to the corresponding
certificate.
The modified Certification Path Advertisement message contains the
following new, optional fields:
o Certificate
o Trust Anchor: to help the client to find out which advertisement
is useful
o OCSP response: One or more OCSP response messages, each containing
the response for a certificate from the request, as specified in
Section 2.2 of [RFC2560].
o OCSP responder: the hash of the trusted OCSP responder's public
key that is used to help the client to find the advertisement
which corresponds to the defined OCSP responder's public key.
The problem for the client is that when it is in the process of
forming a 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
problem using the hashes of OCSP responders. This problem is also
described in Section 5.1 of [RFC4806].
Krishnan, et al. Expires January 3, 2010 [Page 8]
Internet-Draft SEND certificate profile and management July 2009
5.2. RPKI SEND model
This solution suggests for the SEND PKI to be the part of the bigger
RPKI [draft-ietf-sidr-arch-03]. The main advantages of this model
are:
o It is a global model suitable for mobile users. The RPKI has a
default trust anchors that are widely used and available for
mobile users.
o The RPKI project (certificate management and certificate profile)
has been adopted by all 5 RIRs and IANA. SEND could simply adopt
well-known and already accepted RPKI mechanisms.
The disadvantages of this model are related to the fact that the SEND
specification was developed before the standardization of the RPKI.
Hence, SEND is not completely compliant with the RPKI specifications:
o It defines its own IP prefix validation routine and it is not
suitable for the use with CRLs, while the RPKI suports only CRLs.
o It requires different certificate profile, with the certificate
extensions described in the Section 6.
The solution would be to amend RPKI certificate profile to develop a
separate profile for SEND RPKI certificates, support for OCSP and
inclusion of SEND specific extensions (e.g. EKU extension) on the
lower (local) tiers of the RPKI. On the RIR and NIR tier of the
RPKI, CRL is not expected to grow to large sizes, but on the lower
tiers (SEND level), the link topology is expected to be more dynamic
and the CRL might grow to larger sizes. Thus, the use of OCSP is
more suitable than the use of the CRLs.
Krishnan, et al. Expires January 3, 2010 [Page 9]
Internet-Draft SEND certificate profile and management July 2009
6. Certificate profile
The SEND certificate profile is similar to the RPKI certificate
profile, but differs in the certificate extensions. In case of the
per-ISP SEND PKI model, the certificate profile described in this
section could be fully adopted. In case of the SEND RPKI model, the
described certificate extensions are not compliant with the current
SIDR documents [draft-ietf-sidr-res-certs-11]. In case of the SEND
RPKI model, such certificate profile requires the RPKI certificate
profile to be amended, to support OCSP and SEND RPKI certificates on
the lower tiers of the RPKI hierarchy.
The subjectAltName extension MAY appear in the SEND RPKI
certificates, and the Extended Key Usage MUST appear in the SEND RPKI
certificates, while they do not appear in the SIDR RPKI certificates.
CRL Distribution Points, Subject Information Access, Subject Key
Identifier and Authority Key Identifier, and the extension for AS
Resources which appear in SIDR RPKI certificates, MUST NOT appear in
SEND RPKI certificates.
The Trust Anchor option in CPS and CPA messages can be specified as
DER encoded X.501 Name or FQDN. The values of the Trust Anchor
option field is tied to the values of certificate fields. In the
first case (X.501 Name), the Trust Anchor option MUST be equal to the
Subject field from the certificate. The Subject field MUST be used
in accordance with both Resource Certificate Profile
[draft-ietf-sidr-res-certs-11] and SEND specification [RFC3971]. In
the case of FQDN, Trust Anchor option MUST be equal to the
subjectAltName of type FQDN in the certificate. If Subject Name is
empty, subjectAltName extension MUST be marked as critical [RFC5280].
The Key Usage extension defines the basic purposes for which the key
pair may be used. The Router Authorization Certificate MUST have the
digitalSignature bit set, since its key pair is used for the CGA
generation and Router Advertisement signing. Other certificates in
the Authorization Delegation chain MUST have the keyCertSign bit set.
Certificates MUST NOT have a CRLSign 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 Extended Key Usage extension is described in the section 5.1. It
MUST be marked as critical.
Certificate policy extension MAY be used in the SEND RPKI
certificates, as well as the Name Constraints and Policy Constraints,
in order to provide possibility for the future TA management
Krishnan, et al. Expires January 3, 2010 [Page 10]
Internet-Draft SEND certificate profile and management July 2009
[draft-ietf-pkix-ta-mgmt-reqs-00], but they MUST NOT 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, since the host can
learn the OCSP responder from its configuration file.
The extension for IP addresses MUST be used as described in
[[draft-ietf-sidr-res-certs-11]], but applications have to take into
account that IP addresses in the IP address extension might have a
larger scope than the IP addresses in SIDR-defined RPKI certificates
(e.g. null prefix).
All other extensions MUST be used in accordance with Resource
Certificate Profile [draft-ietf-sidr-res-certs-11].
6.1. Extended Key Usage Values
The Internet PKI document [RFC5280] 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]
Krishnan, et al. Expires January 3, 2010 [Page 11]
Internet-Draft SEND certificate profile and management July 2009
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 }
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 3, 2010 [Page 12]
Internet-Draft SEND certificate profile and management July 2009
7. 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 3, 2010 [Page 13]
Internet-Draft SEND certificate profile and management July 2009
8. 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.
[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.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
Krishnan, et al. Expires January 3, 2010 [Page 14]
Internet-Draft SEND certificate profile and management July 2009
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
Roque Gagliano
LACNIC
Email: roque@lacnic.net
Krishnan, et al. Expires January 3, 2010 [Page 15]
