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

From: Tero Kivinen <[email-masked]>
Date: Fri, 17 May 2013 00:29:55 +0300

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... 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 17 May 2013 21:47:03 +0300

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...
:-)
-- 
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 May 2013 18:52:36 +0000

> but better still spell out the VAS, as it is not currently used in

That makes sense.

> are or are not, there is no MAY in there...

That's correct—this will get you a DISCUSS from Pete, so it's best to avoid it.  :)

> just for example RADIUS Expert in this case).

That's a good point—we need to decide what sort of expert we want here.   The draft should give some guidance about that.

---

From: "Leaf Yeh" <[email-masked]>
Date: Sat, 18 May 2013 02:17:45 +0800

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?

attribute to the server. How about to add the following text in section 8,

Best Regards,
Leaf

-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]] 
Sent: Friday, May 17, 2013 5:30 AM
To: [email-masked]; [email-masked];
[email-masked]
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.

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... 
--
[email-masked]

---

From: "Leaf Yeh" <[email-masked]>
Date: Sat, 18 May 2013 21:25:19 +0800

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:[email-masked]] 
Sent: Saturday, May 18, 2013 2:47 AM
To: Leaf Yeh
Cc: [email-masked]; [email-masked];
[email-masked]; '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 

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.

     New RADIUS attributes

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

(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...
:-)
--
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 20 May 2013 16:11:13 +0300

> attribute for the addition to this registry.' OK?

Looks good.
-- 
[email-masked]

---

From: "Leaf Yeh" <[email-masked]>
Date: Mon, 20 May 2013 23:47:06 +0800

FYI, the draft has been ver.-12, the updates can be found @
http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-radius-opt-12 .

Best Regards,
Leaf

-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]] 
Sent: Monday, May 20, 2013 9:11 PM
To: Leaf Yeh
Cc: [email-masked]; [email-masked];

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

Looks good.
--
[email-masked]