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

[Tero Kivinen <[e-mail]>]

Leaf Yeh writes:
> 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.

I agree that it does not need those, but even as section 5 says that
"relay agent MAY include", i.e. it is not mandated to include all
vendor specific attributes (I assume VAS = vendor specific?), there is
guidance what options to include. 

> 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.'?

That addition text seems to be just what I was looking for. Perfect,
but better still spell out the VAS, as it is not currently used in
draft.

BTW, while reading the section 4.1. I noticed following text:

     New RADIUS attributes
   MAY be added to this list after the IETF Expert Review [RFC5226].

I do not think MAY is suitable there. The IANA allocation rules either
are or are not, there is no MAY in there...

Also this same text is also in the section 9, so it might be enough to
remove it from here, and fix the section 9 to say:

  The allocation policy of this 'RADIUS attributes permitted in DHCPv6
  RADIUS option' registry is Expert Review [RFC5226].

(Note, that Expert might not really be IETF Expert, it might also be
just for example RADIUS Expert in this case).

Also I do not think the SHOULD statement given to the Expert (again
better remove the IETF and talk about Expert or Designated Expert)
should just say that without capital letters. Implementors quite often
check all MUST/SHOULD etc to make sure they are done, and finding this
kind of text just causes extra work for them, and if you have skipped
some MUST/SHOULD you need to explain why you did not implement it...
:-)
-- 
[e-mail]