Hi Hannes,
N.B., this draft is undergoing a fair amount of change. However, what you are
discussing wasn’t in scope for those particular changes, not that your points
shouldn’t lead to changes if needed.
> On 5 Mar 2020, at 18:20, Hannes Tschofenig <hannes.tschofe...@arm.com> wrote:
>
> Hi all,
>
> I have a fundamental question about draft-lear-eap-teap-brski-05.
>
> The draft makes an assumption about how a TLS client performs authentication
> of the server side. Because the client is unable to validate the server
> certificate it delays the authentication till it receives the voucher. The
> voucher is a fancy name for a certificate chain that allows the client to
> trace the chain back from the provided certificate to the
> manufacturer-provided certificate.
>
> Here is the relevant text:
> “
> o Step 2: Device establishes provisional TLS connection to registrar.
>
> The device establishes an outer TEAP tunnel with the TEAP server and does not
> validate the server certificate.
> “
>
> Which part of the text in the TLS spec makes you believe that this is
> actually supported via the spec (rather than being supported by some
> implementations*)?
>
This model is identical to that of draft-ietf-anima-bootstrapping-keyinfra (by
design). We are just shifting that capability down a layer. We’ve tested that
this is something that can at least be done in OpenSSL on the client side. I
won’t make claims about other software. The specification is a wireline
RESTful spec.
> Additionally, the TLS stack needs to expose the server certificate via an API
> so that the application layer can perform this delayed authentication.
Not necessarily. One merely need only defer the validation step. What is
required is that the trust anchor set be configurable.
Eliot
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
