Re: [saag] Whether TOFU should be considered in secure DHCPv6?

Dear Paul,

Thanks a lot for your nice reply and guidance.
We just want to apply opportunistic security into secure DHCPv6 deployment.
So, how about the following policy for secure DHCPv6 deployment?
1. If the client/server is pre-configured with authorized certificates,
then it can achieve the authentication.
2. If the certificate cannot be validated and require validation, then it
is blocked from the Internet.
3. If the certificate cannot be validated and don't want to blocked from
the Internet, then it may want either TOFU or a warning each time an
un-validated connection is made.

Looking forward to your further guidance.

Best Regards,
Lishan

2016-09-01 10:43 GMT+08:00 Paul Hoffman <paul.hoffman@vpnc.org>:

> On 31 Aug 2016, at 17:20, Randy Bush wrote:
>
> used for authentication based ... using trust-on-first-use.
>>>
>>
>> uh, what is wrong with this picture?
>>
>
> Uh, the fact that you removed relevant parts of the quotation?
>
> For those of you who want to follow more completely, the Abstract of
> draft-ietf-dhc-sedhcpv6-13 says:
>
>    The mechanism provides encryption in all cases, and
>    can be used for authentication based either on pre-sharing of
>    authorized certificates, or else using trust-on-first-use.
>
> So, we're back to the same problem described in glorious detail in RFC
> 7435. In this case, if a DHCPv6  client wants to only use
> fully-authenticated security, and the DHCPv6 server has a certificate that
> the client can't validate, the client fails to communicate with the server.
> Some people will want that result and thus want to be able to configure to
> always require validation; others won't want to be blocked from the
> Internet and therefore will want either TOFU or (more likely) a warning
> each time an unvalidated connection is made.
>
> --Paul Hoffman
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>