Hi,
Thanks for all comments. I am doing a small recap. Let me know if I forgot
something. I provide context and questions so people can catch up the
discussion and can comment.
Best Regards,
Daniel
1) Replacing Time Option by the Network Time Protocol (NTP) Server Option
for DHCPv6. [RFC5908]
To avoid DNS request, the Option MUST provide at least an IP addresses.
This option only provides IPv6 addresses. The main advantage is that the
authenticity of the information does not relay anymore on a trusted
relation with the DHCPv6 Server and the DHCPv6 Client, but mechanisms to
authenticate [RFC5906] offers a way for NTP responses to be authenticated.
Issues:
a) How TA for NTP is provisioned is out of scope of the draft... but it
exists.
b) We assume that Home Networks are IPv6, but NTP Servers MUST also run
over IPv6. Can we reasonably assume this? If not any proposition for
reusing/encapsulating [RFC2132] option-42 ?
>From then one can assume the device can get time in a secure way and
enables signature checks.
Any remarks on that point?
2) Security Models
I am not sure I have been clear enough on the security model or the use
case I am considering in my draft. I hope I am clarifying this point now.
My device -- say a CPE or smartphone, my PC -- only performs DNSSEC
resolutions, that is to say always perform signature checks, and so MUST
have valid KSKs, even when a emergency key roll over is performed.
Suppose a CPE is attached with a wire connection and performs DNSSEC
validation for my Home Network. Suppose a KSK roll over is performed by
.tld. There are two possibilities:
- a) information received by the DHCP Server is reliable, valid KSKs
are provided to the CPE via the OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR. The CPE
updates its TA, and performs DNSSEC validation.
- b) information received by the DHCP Server is not reliable. KSK is
authenticated by a trusted authority (CERT). The trusted authority is a
third party. It can be any authority trusted by the CPE.
Suppose a smartphone is attached to a random WLAN AP and a KSK roll over
is performed by .tld. Updating KSKs is necessary. The smartphone can only
accept KSK validated by a trusted third party. Otherwise it ignores the
KSKs provided by the DHCP Server. One way to update my KSKs is to reach a
trusted network like my Home Network using a VPN for example.
Suppose a smartphone attached to your home network WLAN AP or a wire line.
The attachment is secured with WPA2 for example. The smartphone updates its
KSKs the same way the CPE does it.
Suppose the smartphone is attached to a random WLAN AP. The DHCP Server
provides a KSK for the attached domain. This KSK MUST only be used for that
domain and MUST be removed when the smartphone changes its administrative
domain.
Remarks:
- a) We need to define what a Trusted DHCP Server is.
- b) KSKs other than KSKs with local scope are between configuration and
"local" setting for connectivity.
- c) In case certification authorities are used, we hope that their keys
will be not subject to emergency key roll over.
Do these scenarios address the security model and clarify the scope of the
draft ?
3) Trust DHCP Server
The draft assumes a trust relation between a DHCP Server and a DHCP Client.
Removing the Time Option reduces the necessity of this requirements. I
assumed there are different relations between DHCP Client and Servers: When
you receive an information from the DHCP Server two things matters:
- a) Do you trust the DHCP Server = information emitted by the DHCP
Server
- b) Do you trust the information you receive = can anyone on path
modify this information?
Suppose you have no alternate way to check the information, like receiving
the OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR. It is important that you answer YES
to a) and b) if the DHCP Server provides information (TA) that modify the
settings of the device. Note also that security protocols help to address
b) but not a). Thus a) requires a configuration settings or interaction
with the end user.
All DHCP Servers are not the same and I consider two categories: Those you
trust information you get from and those you don't. You might share a key
with some, not with others and you might have different policies for each
category. In any cases long term TA like TLD TA, Root TA that modify the
settings of the devices MUST NOT be considered if a and b are not met.
Is that fine we consider these two categories: Trusted DHCP / Untrusted
DHCP?
A YES means OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR may be used for TLD TA, Root
TA. A NO means that OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR MUST only carry TA
with a local scope (like for the split zone).
4) What are the trusted networks?
Home and corporate networks may be considered as trusted network. There are
different way to define you are in a trusted network:
- Ask the user
- Authenticate the DHCP Server
- other ways ??
5) CERT for KSKs
It seems that some do not like the idea that KSKs are provided via CERT.
First, I agree we should find a CA that is almost unlikely to perform key
roll over. Then, a "KSKs TA office" may be created ;-). It does not exist
yet, so I mentioned ISPs in my draft, but I could have specified any third
party. I have no problem with that.
Any remarks on the use of CERT for KSKs ?
On Wed, Oct 23, 2013 at 1:02 AM, Michael Thomas <m...@mtcc.com> wrote:
> On 10/22/13 3:58 PM, Ted Lemon wrote:
>
>> On Oct 22, 2013, at 6:52 PM, Michael Thomas <m...@mtcc.com> wrote:
>>
>>> Oh, ok. This goes back to the duality problem with DHCP then (discovery,
>>> configuration).
>>> Has anybody ever posited a DHCP configuration-only protocol where you
>>> could have
>>> normal transport (ie, not to a broadcast address, you could have, say,
>>> (d)TLS, it doesn't
>>> have to be link local, etc, etc)?
>>>
>>> Or maybe what they really want is tr-069?
>>>
>> Doesn't TR-069 use DHCP?
>>
>> Sheng Jiang has proposed a mechanism for securing DHCP messages using
>> public key encryption. It's up for discussion in the DHC working group at
>> the moment.
>>
>> I haven't looked at how to use DTLS to secure DHCP messages. It would
>> be nice if it were possible.
>>
>> Tr-069 is just a plain old tcp protocol afaik. The cpe might use a dhcp
> option to find
> the tr-069 headend though. TR-069 is pretty isp-oriented too, so i doubt
> they'd have a
> problem adding stuff like dnssec roots to their data model.
>
> Mike
>
> ______________________________**_________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/**listinfo/homenet<https://www.ietf.org/mailman/listinfo/homenet>
>
--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
