Re: [homenet] FW: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-02.txt

[Ray Hunter <[e-mail]>]

Daniel Migault wrote:
> Hi,
>
> I believe draft-ietf-homenet-front-end-naming-delegation [1] , draft-ietf-homenet-naming-architecture-dhc-options [2] have addressed all comments we received so far. I believe these document are ready.
>
> draft-ietf-homenet-front-end-naming-delegation-02 addresses the renumbering issue and added significant text in the security considerations section. So, please have a look these sections.
>
> draft-ietf-homenet-naming-architecture-dhc-options-02.txt. The only changes from the previous version is the replacement of master/slave by primary/secondary.
>
> Feel free to provide feed backs!
> BR,
> Daniel
>
> [1] https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-02
> [2] https://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options-02
>
> -----Original Message-----
> From: homenet [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: Tuesday, May 19, 2015 11:59 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [homenet] I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-02.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Home Networking Working Group of the IETF.
>
>          Title           : DHCP Options for Homenet Naming Architecture
>          Authors         : Daniel Migault
>                            Wouter Cloetens
>                            Chris Griffiths
>                            Ralf Weber
> 	Filename        : draft-ietf-homenet-naming-architecture-dhc-options-02.txt
> 	Pages           : 28
> 	Date            : 2015-05-19
>
> Abstract:
>     CPEs are usually constraint devices with reduced network and CPU
>     capacities.  As such, a CPE hosting on the Internet the authoritative
>     naming service for its home network may become vulnerable to resource
>     exhaustion attacks.  One way to avoid exposing CPE is to outsource
>     the authoritative service to a third party.  This third party can be
>     the ISP or any other independent third party.
>
>     Outsourcing the authoritative naming service to a third party
>     requires setting up an architecture which may be unappropriated for
>     most end users.  To leverage this issue, this document proposes DHCP
>     Options so any agnostic CPE can automatically proceed to the
>     appropriated configuration and outsource the authoritative naming
>     service for the home network.  This document shows that in most
>     cases, these DHCP Options make outsourcing to a third party (be it
>     the ISP or any ISP independent service provider) transparent for the
>     end user.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=aft-ietf-homenet-naming-architecture-dhc-options-02
>
>
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> homenet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet
>

I have just read through 
https://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options-02 
again

Generally, it is looking pretty good.

A couple of comments:

1. The use of the name "Security Field" in section 6.1 this draft is 
rather unfortunate IMHO.

Humbly suggest "Supported Authentication Methods"? [to match terminology 
in 
https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-02 
]

Plus s/Security/Supported Authentication Methods/g in other sections.

2. I miss more detailed discussion in Section 7.1 about when/if a server 
should accept an update of the public key record from a CPE.

Section 9.2 notes this problem but doesn't address the problem further.

Section 9.2 should also probably note:
"The initial update of the public key between the CPE to the ISP 
infrastructure is fundamental to the security of the entire name 
delegation process. If an attacker can subvert the initial public key 
update, then all further security and encryption mechanisms may also be 
subverted."

Shouldn't section 9.2 of the draft " It is therefore RECOMMENDED to use 
the Authentication Option as specified in Section 22.11 of RFC3315"

I realise that there are conflicting requirements between zeroconf and 
knowing precisely which CPE is related to which customer.

3. Is there a need here for potentially further 
authentication/validation of the public key update option itself?

A number of mechanisms come to mind for consideration:
- no additional security
- server enforces a strong coupling between DHCP DUID <-> CPE 
authentication and customer related data (domain names, CPE public key)
- identifying a CPE by physical port of the inbound DHCP message and 
rejecting messages received on other physical ports
- locking updates on the server for public key records whilst an 
existing key is valid for this DUID/ DHCP Authentication pairing
- magic trust bootstrap via an out of band exchange leading to a nonce 
to be included with the OPTION_PUBLIC_KEY option

The first four items on the list would be server specific implementation 
choices, whereas the last would require an additional DHCP option to 
transport any nonce.

regards,
RayH