[ipv6hackers] IPv6 security presentation at Hack.lu 2011

[Arturo Servin]

Geoff,

	Thanks, I did not know that we could do that with EE certificates. You have trigger some curiosity to dig more on SEND.

	

regards,	
-as


On 22 Sep 2011, at 16:45, Geoff Huston wrote:

> On 23/09/2011, at 5:30 AM, Arturo Servin wrote:
> 
>> 
>> 	Not really.
>> 
>> 	It is getting worse.
>> 
>> 	In RPKI RIRs are issuing certificates to entities that have received resources (IPv4, IPv6 and ASNs) from them. Those entities will use those certificates to create other objects (called ROAs) that will be used by routers to perform origin validation in BGP.
>> 
>> 	It has to do nothing with SEND.
>> 
>> 	And there are several documents describing RPKI, not just one. See (basically the ones in the Editors Queue):
>> 
>> http://tools.ietf.org/wg/sidr/
>> 
>> Regards.
>> as
>> 
> 
> Actually, as far as I am aware the answer is yes, RPKI can be used to support EE certs issued to routers, or at least that was the intention back in 2009 when we were working on the RPKI and SEND documents in the IETF.
> 
> 
> In the RPKI specs we added the following in the certificate profile:
> 
> 4.8.5.  Extended Key Usage
> 
>   The Extended Key Usage (EKU) extension MUST NOT appear in any CA
>   certificate in the RPKI.  This extension also MUST NOT appear in EE
>   certificates used to verify RPKI objects (e.g., ROAs or manifests.
>   The extension MUST NOT be marked critical.
> 
>   The EKU extension MAY appear in EE certificates issued to routers or
>   other devices.  Permitted values for the EKU OIDs will be specified
>   in Standards Track RFCs issued by other IETF working groups that
>   adopt the RPKI profile and that identify application-specific
>   requirements that motivate the use of such EKUs.
> 
> 
> So with the EKU extension RPKI EE certs can be issued to SEND routers.
> 
> The following text was proposed to the SEND document to match this:
> 
> 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.
> 
> ---
> End entity certificates issued to routers in support of SeND applications MUST contain an Extended Key Usage (EKU) extension. The inclusion of this extension, using one or more of the values defined here, is consistent with the RPKI resource certificate profile [res-certificate-profile], since explicit provision is made for using this extension in such contexts.
> 
> 
> probably a good idea to check with the SEND documents to see where all this ended up
> 
> regards,
> 
>   Geoff
>