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

[Suresh Krishnan <[e-mail]>]

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

Richard Barnes wrote:
> 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".

OK.

> 
> 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".

Sounds good.

> 
> 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"?

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?

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

Can we use

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

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

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

> 
> 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.

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

> 
> 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.

"  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."

> 
> 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.

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?

> 
> 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].

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.

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

OK.

> 
> 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:
> "                                                              > "

I will include this text in the security considerations section.

Thanks
Suresh