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 protected] > https://www.ietf.org/mailman/listinfo/homenet >
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
