Skip to main content

Last Call Review of draft-ietf-dhc-dhcpv6-radius-opt-12
review-ietf-dhc-dhcpv6-radius-opt-12-genart-lc-thomson-2013-05-30-00

Request Review of draft-ietf-dhc-dhcpv6-radius-opt
Requested revision No specific revision (document currently at 14)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-05-28
Requested 2013-05-23
Authors Leaf Yeh , Mohamed Boucadair
I-D last updated 2013-05-30
Completed reviews Genart Last Call review of -11 by Martin Thomson (diff)
Genart Last Call review of -12 by Martin Thomson (diff)
Secdir Last Call review of -11 by Tero Kivinen (diff)
Assignment Reviewer Martin Thomson
State Completed
Request Last Call review on draft-ietf-dhc-dhcpv6-radius-opt by General Area Review Team (Gen-ART) Assigned
Reviewed revision 12 (document currently at 14)
Result Ready
Completed 2013-05-30
review-ietf-dhc-dhcpv6-radius-opt-12-genart-lc-thomson-2013-05-30-00
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.