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:[email protected]] On Behalf Of
[email protected]
Sent: Tuesday, May 19, 2015 11:59 AM
To: [email protected]
Cc: [email protected]
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
[email protected]
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
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
