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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf