Network Working Group S. Krishnan
Internet-Draft Ericsson
Intended status: Standards Track A. Kukec
Expires: April 29, 2010 University of Zagreb
R. Gagliano
LACNIC
October 26, 2009
Certificate profile and certificate management for SEND
draft-ietf-csi-send-cert-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 April 29, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Krishnan, et al. Expires April 29, 2010 [Page 1]
Internet-Draft SEND certificate profile and management October 2009
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 April 29, 2010 [Page 2]
Internet-Draft SEND certificate profile and management October 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 . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 7
5. Certificate profile and issuance . . . . . . . . . . . . . . . 8
5.1. Trust Anchor Material . . . . . . . . . . . . . . . . . . 8
5.2. Extended Key Usage Values . . . . . . . . . . . . . . . . 8
6. CRL profile and revocation . . . . . . . . . . . . . . . . . . 11
6.1. Certificate Revocation Solicitation message . . . . . . . 11
6.2. Certificate Revocation Advertisement message . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Krishnan, et al. Expires April 29, 2010 [Page 3]
Internet-Draft SEND certificate profile and management October 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 April 29, 2010 [Page 4]
Internet-Draft SEND certificate profile and management October 2009
2. Introduction
SEcure Neighbor Discovery [RFC3971] (SEND) utilizes X.509v3
certificates that include the [RFC3779] extension for IPv6 addresses
to certify a router's authority over an IPv6 prefix for the Neighbor
Discovery (ND) Protocol. SEND specification defines neither the
certificate profile nor any certificate management routines. It
specifies only the certificate path validation and the IP address
extension verification procedures. This document defines the
certificate profile, as well as certificate issuance and revocation
routines for SEND.
The SIDR WG in the IETF is working on a Certificate Profile for the
Resource Public Key Infrastructure (RPKI). The RPKI represents the
centralized model referred in Section 6.2 of [RFC3971].
Consequently, the SIDR certificate profile and certificate validation
detailed in [draft-ietf-sidr-res-certs-17] MUST be used for SEND.
The RFC 3779 extension for IPv6 addresses can be expressed as either
an addressPrefix or an addressRange. For SEND it does not matter how
the IPv6 address space is expressed (either an addressPrefix or an
addressRange) in the certificate as long as the IPv6 address space
that the entity is allowed to route is included. We will use the
term "certified IPv6 space" to refer to the IPv6 address space
included in an X.509v3 certificate using RFC 3779 extension for IPv6
addresses.
Since the IPv6 addresses extension does not mention what functions
the node can perform for the certified IPv6 space, 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
(optional in RPKI Certificates) of the X.509 certificate to mention
the purpose why 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.
In RFC 3971 two deployment models were described: centralized and
decentralized. With the advance of RPKI standardization we introduce
two different deployment models: local and public deployment models.
Krishnan, et al. Expires April 29, 2010 [Page 5]
Internet-Draft SEND certificate profile and management October 2009
3. Terminology
Certified IPv6 Addresses IPv6 address space included in an X.509v3
certificate using RFC 3779 extension for
IPv6 addresses.
ISP Internet Service Provider.
NIR National Internet Registry.
RIR Regional Internet Registry.
RPKI Resource PKI established in accordance with
[draft-ietf-sidr-arch-06].
RPKI certificates Certificates defined in
[draft-ietf-sidr-res-certs-17].
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].
CA and end entity certificates issued in support of SEND MUST comply
with the RPKI resource profile [draft-ietf-sidr-res-certs-17].
Krishnan, et al. Expires April 29, 2010 [Page 6]
Internet-Draft SEND certificate profile and management October 2009
4. Deployment Models
RFC 3971 describes two deployment models:centralized and
decentralized. These models were differentiated by having one or
many trust anchor. In this document we introduced two new deployment
models, not based on the number of trust anchors but on the
localization of the SEND deployment
The local SEND deployment model represent those cases where SEND
deployment is confined to an administrative domain. In this
scenario, the deployment of SEND MAY be done independently of the
existance of deployment in the upper RPKI hierarchy (i.e. and end
user could deploy SEND without the need of RPKI deployment in its
ISP) by the use of local trust anchors and configuring islands of
trust. This model MAY include ULA addresses.
The public SEND deployment models represent those cases where SEND
deployment is linked to RPKI deployment as described in
[draft-ietf-sidr-arch-06]. Trust anchor material MAY be part of a
different administrative domain (i.e. RIR, NIR or ISPs). It is a
global model suitable for mobile users.
Krishnan, et al. Expires April 29, 2010 [Page 7]
Internet-Draft SEND certificate profile and management October 2009
5. Certificate profile and issuance
End entity certificates issued in support of SEND MUST comply with
the RPKI resource profile [draft-ietf-sidr-res-certs-17]. CA
certificates used to verify these router (EE) certificates also MUST
comply with this profile. This implies that these CA certificates
MUST contain an RFC 3779 address extension representing the address
space allocations held by the service provider represented by the CA.
5.1. Trust Anchor Material
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 routers' certificates. The
trust anchor material MAY be either a CA certificate (which MAY be
self-signed) containing an RFC 3779 address extension or MAY be trust
anchor material as defined in [draft-ietf-sidr-ta-02].
In a local SEND deployment model, it is possible to use as a trust
anchor material a certificate that includes in its RFC 3779 address
extension the prefix ::/0. In this case no new trust anchor material
would be needed when renumbering. However, if trying to move from
the local deployment model to the public deployment model, new trust
anchor material will have to be distributed to relying parties.
By using the trust anchor model described in [draft-ietf-sidr-ta-02],
no address space is part of the trust anchor material. This allows
network renumbering without the need for issuing trust anchor
material in bith the local and the public model. In this case the
Relying party MUST obtain a certificate that includes an RFC 3779
address extension. This certificate will be obtained from the
publication point of certificate defined as trust anchor.
The identification for the Trust Anchor Material will be included in
the Name Type Field of the ICMP Trust Anchor Option as decribed in
RFC 3971 and MUST always to refer to a certificate that includes as
RFC 3779 address extension.
5.2. 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 is defined as
optional in [draft-ietf-sidr-res-certs-17] for end entity
certificates but MUST be present when issuing end entity certificates
Krishnan, et al. Expires April 29, 2010 [Page 8]
Internet-Draft SEND certificate profile and management October 2009
for SEND.
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 }
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
Krishnan, et al. Expires April 29, 2010 [Page 9]
Internet-Draft SEND certificate profile and management October 2009
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 April 29, 2010 [Page 10]
Internet-Draft SEND certificate profile and management October 2009
6. CRL profile and revocation
RPKI requires the use of CRLs [draft-ietf-sidr-res-certs-17]. CRLs
require an in-band exchange of the revocation material, and the
specification of new SEND messages - Certificate Revocation
Solicitation (CRS) message and the Certificate Revocation
Advertisement (CRA) message. While receiving a CPA message, SEND
host does not have an access to Internet, and therefore MUST accept
certificates within the CPA message, and consider them as
provisional. Once when the SEND host gains Internet access, it MUST
send the Certificate Revocation Solicitation (CRS) message to request
the CRL, and then perform the revocation after the receipt of the CRL
within the Certificate Revocation Advertisement (CRA) message.
6.1. Certificate Revocation Solicitation message
TBD.
6.2. Certificate Revocation Advertisement message
TBD.
Krishnan, et al. Expires April 29, 2010 [Page 11]
Internet-Draft SEND certificate profile and management October 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 April 29, 2010 [Page 12]
Internet-Draft SEND certificate profile and management October 2009
8. Normative References
[I-D.ietf-sidr-res-certs]
Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates",
draft-ietf-sidr-res-certs-17 (work in progress),
September 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[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 April 29, 2010 [Page 13]
Internet-Draft SEND certificate profile and management October 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
Rambla Rep Mexico 6125
Montevideo, 11400
UY
Email: roque@lacnic.net
Krishnan, et al. Expires April 29, 2010 [Page 14]
