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

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

Tero - (I assume VAS = vendor specific?)

The above 'VAS' should be VSA - Vendor-Specific Attribute. My typo, sorry
about that.


Tero - ...but better still spell out the VAS, as it is not currently used in
draft.

Ok, I will spell out it to be '..some RADIUS vendor-specific attributes...'
in the sentence.


Tero - 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, 

I think we can use 'can' to replace 'MAY' here.


Tero - and fix the section 9 to say:    The allocation policy of this
'RADIUS attributes permitted in DHCPv6 RADIUS option' registry is Expert
Review [RFC5226].

I will adopted it in the section 9.


Tero - 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.

The text in section 9 will be 'The allocation policy of this 'RADIUS
attributes permitted in DHCPv6 RADIUS option' registry is Expert Review
<xref target="RFC5226"/>. Designated expert should carefully consider the
security implications of allowing the relay agent to include new RADIUS
attribute for the addition to this registry.' OK?



Best Regards,
Leaf



-----Original Message-----
From: Tero Kivinen [mailto:[e-mail]] 
Sent: Saturday, May 18, 2013 2:47 AM
To: Leaf Yeh
Cc: [e-mail]; [e-mail];
[e-mail]; 'Tomek Mrugalski'; 'Ted
Lemon'
Subject: RE: Secdir review of draft-ietf-dhc-dhcpv6-radius-opt-11

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]