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

"Leaf Yeh" <leaf.yeh.sdo@gmail.com> Sat, 18 May 2013 13:25 UTC

Return-Path: <leaf.yeh.sdo@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151D221F9092; Sat, 18 May 2013 06:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.099
X-Spam-Level:
X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnkGkQBbyt4a; Sat, 18 May 2013 06:25:35 -0700 (PDT)
Received: from mail-da0-x22e.google.com (mail-da0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 60E0521F9057; Sat, 18 May 2013 06:25:35 -0700 (PDT)
Received: by mail-da0-f46.google.com with SMTP id e20so620659dak.5 for <multiple recipients>; Sat, 18 May 2013 06:25:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=mDOJZrBcHDZ1F64rDVjMinwmX24RJ8eo4b+owCkpjEo=; b=ThdYcdKRg4KkMvf9CGP4tyxpLBkWu+lOAsdMTcnwZSc/JrdRHL7uFjlU85tDGzoCgW ErR7FrdpaXXk7ebacy8cNqRw7L+16d/3p9t5iwLyvxwW79AaB1+iCMPDV8NCJLkfiQ8H IM0JAX8T+Yj1XHgLZtkIM0B+YICUjrvatsY98XDmSkhTkyCfkLNXaunjD2wWYqfeIW5T ZB9PNhcg+UjkQoW4v9LM66Shuw/skxMXyX6RmtgVy/F+XagSz1y+KITHDAE7jYwU8pSe DAjg9xPnE35AXAimN5fQmdjJ1EkNbNtNxccMxLX/zRcIm44U4Ibf+86K/PHmckkvsO7D HjKw==
X-Received: by 10.68.42.134 with SMTP id o6mr20117157pbl.149.1368883535123; Sat, 18 May 2013 06:25:35 -0700 (PDT)
Received: from PC ([221.223.164.6]) by mx.google.com with ESMTPSA id zo4sm15660002pbc.21.2013.05.18.06.25.31 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 18 May 2013 06:25:34 -0700 (PDT)
From: "Leaf Yeh" <leaf.yeh.sdo@gmail.com>
To: "'Tero Kivinen'" <kivinen@iki.fi>
References: <20885.20435.315856.407689@fireball.kivinen.iki.fi> <51967458.22d9440a.44f5.7843@mx.google.com> <20886.31527.670959.767940@fireball.kivinen.iki.fi>
In-Reply-To: <20886.31527.670959.767940@fireball.kivinen.iki.fi>
Date: Sat, 18 May 2013 21:25:19 +0800
Message-ID: <5197814e.04fc440a.31ee.7730@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac5TLu9gpPxWMznnRpKXGnZCRhevUAALMUhA
Content-Language: zh-cn
X-Mailman-Approved-At: Sat, 18 May 2013 08:09:39 -0700
Cc: draft-ietf-dhc-dhcpv6-radius-opt.all@tools.ietf.org, 'Tomek Mrugalski' <tomasz.mrugalski@gmail.com>, 'Ted Lemon' <Ted.Lemon@nominum.com>, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-dhc-dhcpv6-radius-opt-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 May 2013 13:25:36 -0000

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:kivinen@iki.fi] 
Sent: Saturday, May 18, 2013 2:47 AM
To: Leaf Yeh
Cc: iesg@ietf.org; secdir@ietf.org;
draft-ietf-dhc-dhcpv6-radius-opt.all@tools.ietf.org; '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...
:-)
--
kivinen@iki.fi