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

From: Daniel Migault <[email-masked]>
Date: Tue, 16 Jun 2015 17:33:24 -0400

Hi Ray,

Thank you for the comments. Please see inline my response.

BR,
Daniel

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.
>
> I agree we may have had a better terminology. I changed Security to
Supported Authentication.

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

I do not see any issue as long as the link between the DHCP Server an dthe
CPE is trusted. I have added the following text:

" A CPE may update its Public Key by sending a new value in the DHCP Public
Key Option (OPTION_PUBLIC_KEY) as this document assumes the link between
the CPE and the DHCP Server is considered authenticated and trusted."

>
> 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.
>
>
Section 9.2 mentions already mentions
"In fact, the channel MUST be secured because the CPE provides
authentication credentials. Unsecured channel may result in CPE
impersonation attacks."

and there is a reference to the RFC3315. Maybe that would be clearer to
have this sentence in the begining of the section. Is that fine for you?

> 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.
>
> I agree, however, it appears to me as a whole topic in itself. I would
suggest we leave that for future work.

> regards,
> RayH
>
>
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>