Re: [secdir] Secdir review of draft-ietf-dhc-dhcpv6-radius-opt-11

["Leaf Yeh" <[e-mail]>]

Tero - I have no idea whether someone might use vendor specific radius
options in such way that this might cause problems, but perhaps adding note
about this to the security considerations section might be appropriate.

Any suggested text on it?


Tero - As an (bad) example of that such practice could be that some ISP
somewhere decides to add bithdate of the customer as vendor specific option
to radius, so they can filter out the web sites which are allowed to be
accessed from that client, and as that information has privacy concerns,
they make sure that the connection between NAS and radius server is
encypted. Now when this protocol is deployed those options gets relayed to
the DHCPv6 server in clear, which might not be what the ISP expected...

I believe the DHCPv6 server does not really need the privacy information
(eg. birth_date) for its address/prefix (or other parameters) assignment,
and the relay in this case could just forward the possible VAS RADIUS
attribute to the server. How about to add the following text in section 8,
'Network administrators should be aware that although RADIUS messages are
encrypted, DHCPv6 messages can not be encrypted. It is possible that some
VAS RADIUS attributes might contain the sensitive or confidential
information. Network administrators are strongly advised to prevent
including such information into DHCPv6 messages.'?


Best Regards,
Leaf



-----Original Message-----
From: Tero Kivinen [mailto:[e-mail]] 
Sent: Friday, May 17, 2013 5:30 AM
To: [e-mail]; [e-mail];
[e-mail]
Subject: Secdir review of draft-ietf-dhc-dhcpv6-radius-opt-11

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 specifies a way how the NAS / DHCPv6 relay agent can take some
data it received from the radius server and send it for the
DHCPv6 server. The data includes things like Delegated-IPv6-Prefix,
DNS-Server-IPv6-Address, Delegated-IPv6-Prefix-Pool etc.

In addition to those the IANA registry specifying which options should
forwarded includes Vendor-Specific. 

The connection between the NAS / DHCPv6 relay agent and Radius server might
be protected (encrypted with IPsec), but the connection between
DHCPv6 relay agent and the DHCPv6 server does not have that possibility (as
far as I understand things).

For most of the values forwarded that does not matter, as they are public to
the network anyways, and as
draft-ietf-dhc-dhcpv6-radius-opt-11 says the NAS is trusted network
component. For the Vendor specific that might not be true. It might be that
the vendor specific options returned from the RADIUS server contains
something that might not be public, and as the NAS / DHCPv6 relay agent does
not have to select which parts of that to forward (it will forward all of
them), that might leak that vendor specific information to the network even
when the connection between NAS and the RADIUS server was protected.

I have no idea whether someone might use vendor specific radius options in
such way that this might cause problems, but perhaps adding note about this
to the security considerations section might be appropriate.

As an (bad) example of that such practice could be that some ISP somewhere
decides to add bithdate of the customer as vendor specific option to radius,
so they can filter out the web sites which are allowed to be accessed from
that client, and as that information has privacy concerns, they make sure
that the connection between NAS and radius server is encypted. Now when this
protocol is deployed those options gets relayed to the DHCPv6 server in
clear, which might not be what the ISP expected... 
--
[e-mail]