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