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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]