Re: [dhcwg] Secure DHCPv6 Deployment Consideration - proposed text

["Dacheng Zhang" <[e-mail]>]

在 15-8-26 下午4:59， "dhcwg on behalf of Sheng Jiang"
<[e-mail]
on behalf of [e-mail]> 写入:

>Hi, Jin,
>
>My replies in lines.
>
>>> This document defines two authentication models: authentication
>>> based on public key certificates and PKI; and authentication based
>>> on leap of faith to public keys. It is worth noticing that in real
>>> deployment, the two models may be mixed together on the serve to be
>>> able to serve both stable clients and roaming clients, which may be
>>> treated with different service policies.
>>
>>I thought we chose to use TOFU (Trust-on-first-use) instead of "leap
>>of faith".  Is it intentional this text now uses the latter?
>
>Yes, TOFU. I will check the consistency when integrating these text into
>the document.
>
>>> 1. Authentication based on certificate and PKI
>>>
>>> This model would mainly be used in the scenarios such as enterprise
>>> networks where tight security policies are applied and the clients
>>> are stable terminal devices. It would provide tighter security
>>> protection because both server and client can be authenticated based
>>> on a common trusted CA. As with this precondition, this model would
>>> require more complicated pre-configuration, particularly on the
>>> client side.
>>
>>Once we say "require more complicated pre-configuration", we'll lose
>>the most boasted advantage of this proposal: ease of deployment.  So
>>text like this will also need to answer "then, why do we bother
>>to introduce a new mechanism?"  I thought this question is one of the
>>common feedback (or pushback) from post-WGLC reviews, and will have to
>>be addressed in some way.
>>
>>In my understanding, the honest answer is that "we think public-key
>>based mechanism is just more modern, that's it".  We could also note a
>>relatively minor security advantage in cases like silently stolen
>>client keys on the server.  There might also be cases where we can
>>show this approach actually improves deployability, but from the
>>lessons I learned from previous discussions I suspect such discussions
>>will be speculative at best, and will be unlikely to satisfy the
>>reviewers.
>
>PKI-based deployment is easier than symmetric key mechanism, particularly
>when there are multiple servers. PKI is more modern and common. It may be
>combined with other protocol deployment, not only DHCPv6. I will try to
>enhance the text, but such discussion actually belong to section 3,
>"Security Overview of DHCPv6".

In addition, the capability of generating cert chains can provide
additional flexibility than the solution based on pre-shared keys.

>
>>> The server can always be considered to have connectivity to
>>> authorized CA and verify the clients’ certificate. Because the
>>> client may have to validate the authentication in the condition of
>>> without connectivity wider than link-local，the verification on the
>>> client devices may have to be performed locally. One or multiple
>>> certificates, which form a certification path [RFC5280], need to be
>>> deployed in the client in order to verify the certificate sent from
>>> the server and so perform the authentication. Besides the
>>> certificate used to prove the identity, the server may also need to
>>> provide additional certificates to help the client generate a
>>> certificate chain from the certificates deployed in the client to
>>> the certificate.
>>
>>I'm not sure if this paragraph directly and clearly addresses the
>>concern regarding how the client validates the certificate or public
>>key.  I suspect we'll need to discuss something more specific, like
>>how a client could pre-cache a complete certification path with
>>discussions on its own risks.
>
>The establish, deployment and its risks of certification path is another
>generic issues, which a) is out of scope, it is secure dhcpv6 specific,
>b) it is addressed in the referred RFC.
>
>>> 2.  Authentication based on leap of faith
>>>
>>> This model would mainly be the scenarios that the security policies
>>> are loss and the clients may roam, such as public coffee
>>> shops. Therefore, the PKI could not be deployed in advance. This
>>> model requires minimum pre-configuration - server and client has a
>>> public/private key pair. A signed certificate could be an equivalent
>>> to a public key in this model.
>>
>>Several reviewers have already pointed out that TOFU (or leap of
>>faith) is not suitable for coffee shop cases (and I agree with them).
>>My personal answer to them is that a more appropriate case would be
>>initial setup in a closed home network.  We might also say TOFU can be
>>used for hijack prevention.
>
>Let's see what the reviewers may response. I can certainly modify the
>example. But I am not sure what else is the best model for coffee shop.

Maybe we could assume the customer needs to input the wifi password on the
wall first.... 

>
>>> The Leap of faith model by itself could not prevent a client to
>>> trust a malicious server or a server to trust a malicious client at
>>> the beginning of the first session. But the leap of faith mechanism
>>> guarantees the subsequent messages are sent by the same previous
>>> sender, and therefore narrows the time window that an attacker can
>>> perform attacks. Also, the message integrity is provided.
>>
>>what does "also, the message integrity is provided" mean in this
>>context?
>
>It means the receiver can validate the message does not modified in the
>middle.
>
>>> The server may constrain the resource and access rights to clients who
>>>is
>>based on leap of faith model to avoid potential malicious attacks
>>>
>>> Additional mechanisms to justify the trust relationship, such as
>>> requiring human intervention at the point of the leap of faith on
>>> the client or the server may run some algorithm to detect malicious
>>> behaviors from clients.
>>
>>"some algorithm to detect malicious behaviors from clients":
>>specifically what does this mean?
>>
>>If I remember correctly, there was also a concern about privacy leak
>>by exchanging clients' public keys or certificates.  Do we have
>>another section to address this point?
>
>I believe this has been mentioned, although not solved, by the last
>paragraph of section 7, Security Considerations.
>
>>Finally, a couple of editorial nits:
>>
>>> the two models may be mixed together on the serve to...
>>s/on the serve/on the server/?
>>
>>> The Leap of faith model by itself could not prevent a client to
>>> trust a malicious server or a server to trust a malicious client...
>>
>>s/to trust/from trusting/ (2 occurrences).
>
>Thanks. Corrected.
>
>Regards,
>
>Sheng
>
>>--
>>JINMEI, Tatuya
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dhcwg