Subject: secdir review of draft-ietf-csi-send-cert-03

From: Richard Barnes <[email-masked]>
Date: Tue, 18 May 2010 20:37:19 -0400

I have reviewed this document as part of the security directorate's  
ongoing effort to review all IETF documents being processed by the  
IESG.  These comments were written primarily for the benefit of the  
security area directors.  Document editors and WG chairs should treat  
these comments just like any other last call comments.

This document defines a certificate profile for use in the Secure  
Neighbor Discovery protocol for IPv6.  Starting from the RPKI cert  
profile, it adds some refinements for SEND, e.g., EKUs that authorize  
the subject to act in certain roles within SEND (router, proxy, host).

Overall, the document is reasonably well-written, but could benefit  
from more precision in its use of terminology.  There are a few points  
(noted below) where certificate processing rules are unclear.  With  
regard to the security considerations in particular, I would prefer if  
they stated the risks slightly more directly (text is suggested  
below), but in general, the authors address the major security concerns.

Detailed comments follow.

--Richard

Sec 2 Para 1
Suggest changing "authority over an" to "authorization to advertise an".

Sec 2 Para 2
Suggest rewording to avoid referring to SIDR WG (which is temporary).   
Suggested text: "The Resource Public Key Infrastructure (RPKI) is the  
global PKI that attests to allocation of IP address space."  Also,  
instead of "SIDR certificate profile", use "RPKI certificate profile".

Sec 2 Para 3, General
I'm confused by the several instances of the phrase "address owner" in  
the document (the phrase is not used in RFC 3971).  Do you mean "host"?

Sec 3 Para "End Entity"
This definition is incorrect.  Refer to RFC 4949.

Sec 4 Para 1
The RPKI profile should be applied in *addition* to the RFC 3971  
profile, right?  Please clarify.

Sec 4 Para 2
Why can there only be one RFC 3779 extensions?  It doesn't seem like  
there's a risk in including IPv4 space (e.g., for a dual-stack router  
that was vouching for IPv4 space in some other application?), or  
multiple extensions for IPv6 space.

Sec 5
This section should note that another deployment model (arguably the  
most likely) is a combination of these two, in which most resources  
are certified under the global RPKI, while some (e.g., ULAs) are  
certified under local TAs.

Sec 6 Para 4
The requirement for RFC 3779 extension seems to contradict the use of  
ETAs as Trust Anchor Material, i.e., the last sentence of the first  
paragraph in this section.

Sec 7 Para "The inclusion of ..." et seq.
It would be helpful for the document to specify how prefix matching  
should be done when validating these extensions.  Which of the  
following should the RP use?
-- Exact matching
-- Subset matching (RA within cert)
-- The weird subset/intersection algorithm that RFC 3971 defines
What prefix should the RP be matching against from SEND, per EKU?   
E.g., for id-kp-sendRouter, the RFC 3779 extension in the cert should  
match against any RAs the router emits.  It may be useful to refer to  
the ROA validation document [draft-ietf-sidr-roa-validation].

Sec 7 Para "Certificate-using applications..."
Suggest changing "Certificate-using applications" to "Relying Parties".

Sec 8
This section correctly identifies the main risk with these extensions  
(namely, issuance of certs with incorrect roles assigned), but it  
would be helpful to clarify the application-level impact of these bad  
issuances.  Suggested text:
"
Since a SEND certificate attest that its subject is authorized to play  
a given role in the SEND protocol, certificates that contain incorrect  
EKU values can enable some of the same attacks that SEND was meant to  
prevent.  For example, if a malicious host can obtain a certificate  
that authorizes it to act as a router for a given prefix, then it can  
masquerade as a router for that prefix, e.g., in order to attract  
traffic from local nodes.
"

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 31 May 2010 01:35:08 -0400

Hi Richard,
   Thanks a lot for your extensive review. Please find responses inline.

> Suggest changing "authority over an" to "authorization to advertise an".

OK.

> instead of "SIDR certificate profile", use "RPKI certificate profile".

Sounds good.

> the document (the phrase is not used in RFC 3971).  Do you mean "host"?

Since RFC3971 did not expect hosts to use certificates to defend their 
addresses (hosts traditionally use CGAs), this role was not defined. I 
proposed the following text to explain what the address owner role means

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]. For an address
in such certificate the host can assign the address, send/receive
traffic from this address, and can respond to NSes about that address.
For a prefix in such certificate the node can perform all the above
mentioned operations for any address in that prefix. Also, when a prefix
is present in the certificate with the owner authorization value, the
node cannot advertise the prefix in an RA.

This will replace paragraph 6 of section 7. Does this work?

> This definition is incorrect.  Refer to RFC 4949.

Can we use

"End Entity - an entity that is not a CA"

> profile, right?  Please clarify.

Not really. The csi wg decided to base the new SEND certificate profile 
solely on the RPKI profile.

> multiple extensions for IPv6 space.

I am not sure where this restriction is specified. Can you clarify?

> certified under local TAs.

Sounds good. Will add the following text about a hybrid deployment model 
at the end of section 5.

"  These two models are not mutually exclusive.  It is entirely possible
    to have a hybrid model that incorporates features from both these
    models.  In one such hybrid deployment model most IP address
    resources (e.g. global unicast addresses) would be certified under
    the global RPKI, while some others (e.g., ULAs) are certified under
    local TAs."

> paragraph in this section.

Good catch. I am not sure how to resolve this. One way would be to 
specify that the ETA EE certificates are exempt from requiring the 
RFC3779 extensions. Do you have any suggestions?

> the ROA validation document [draft-ietf-sidr-roa-validation].

My gut feel is subset matching, but we need to make sure this will work 
with all scenarios. We will come back with text proposals for this.

> Suggest changing "Certificate-using applications" to "Relying Parties".

OK.

> "                                                              > "

I will include this text in the security considerations section.

Thanks
Suresh

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 31 May 2010 20:22:57 -0400

Hey Suresh,

Most of these comments look OK to me.  Couple of responses inline.

--Richard

> This will replace paragraph 6 of section 7. Does this work?

Ok, I understand the difficulty more now, and that text looks fine.

> "End Entity - an entity that is not a CA"

Might want to note that the entity in question is the subject of a  
certificate in the PKI rather than, say, my cat (which, AFAIK, does  
not hold any certificates).  Suggested text:
"End Entity - An entity in the PKI that is not a CA"

> Not really. The csi wg decided to base the new SEND certificate  
> profile solely on the RPKI profile.

Ok, that should be clearer in the document.  Suggest adding this after  
the first sentence of Section 4:
"This certificate profile supercedes the profile for router  
certificates specified in RFC 3971.  That is, certificates used in  
SEND (by routers, proxies, or address owners) MUST conform to this  
certificate profile and MAY conform to the original profile in RFC  
3971."

>> Sec 4 Para 2
>> Why can there only be one RFC 3779 extensions?  It doesn't seem  
>> like  there's a risk in including IPv4 space (e.g., for a dual- 
>> stack router  that was vouching for IPv4 space in some other  
>> application?), or  multiple extensions for IPv6 space.
>

The text I was referring to is the following:
"
SEND certificates MUST include the IP Resources extension for IPv6  
Address Family (AFI=0002)    described in section 3.9.10 of [I-D.ietf- 
sidr-res-certs] and MUST be the only resource extension present.
"
I had read this to mean that the only resources that could be in the  
certificate could be a single IPv6 address block.  Suggest replacing  
with the following clarification:
"
SEND certificates MUST include the IP Resources extension [RFC3779].   
This extension MUST include at least one address block for the IPv6  
Address Family (AFI=0002), as described in Section 3.9.10 of [I-D.ietf- 
sidr-res-certs].  SEND certificates MUST NOT have more than one IP  
Resources extension.
"

>> Sec 5
>> This section should note that another deployment model (arguably  
>> the  most likely) is a combination of these two, in which most  
>> resources  are certified under the global RPKI, while some (e.g.,  
>> ULAs) are  certified under local TAs.
>
> Sounds good. Will add the following text about a hybrid deployment  
> model at the end of section 5.
>

That text looks good, thanks.

>> Sec 6 Para 4
>> The requirement for RFC 3779 extension seems to contradict the use  
>> of  ETAs as Trust Anchor Material, i.e., the last sentence of the  
>> first  paragraph in this section.
>

I think the rest of the section is clear enough -- the TA material  
either has to be a self-signed certificate or it has to be an ETA.  So  
maybe you could just delete the phrase "and MUST always refer to a  
certificate that includes a RFC 3779 address extension"?

As an aside, do you want to specify that in the first case (the non- 
ETA case), the self-signed TA cert MUST conform to the RPKI profile?