I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
Document: draft-ietf-dhc-dhcpv6-radius-opt-12 Reviewer: Martin Thomson Review Date: 30 May 2013 IETF LC End Date: 30 May 2013 IETF Telechat Date: 30 May 2013 Summary: This document is ready for publication as proposed standard. Major Issues: None Minor Issues: The security of this mechanism seems to rely on trust in the relay. None of the RADIUS options are authenticated by the DHCP server, so the integrity of the relay is paramount. The "may" in the following statement should probably be removed: The mechanism described in this document may^H^H^H introduce new attack vector against the DHCPv6 server in case the DHCPv6 relay agent is compromised. Adding a statement to the effect that the authenticity of RADIUS options is not assured by any means other than trust in the relay would be better, e.g., No mechanism is provided to support the authenticity of RADIUS attributes that are encapsulated in this way. The DHCPv6 server relies on trust in the DHCPv6 relay to avoid making decisions based on forged RADIUS attributes. The statement below doesn't really highlight what sort of "security" problems might arise when relaying RADIUS options to the DHCP server: [...] Designated expert should carefully consider the security implications of allowing the relay agent to include new RADIUS attribute for the addition to this registry. I think that this refers to the text regarding encryption in Section 8, but it implies that there might be other issues. (The above is also grammatically suspect.) Editorial nits: None p.s., My apologies about the timing of this review. -12 fixed my earlier issues, so I had to start over. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
