Subject: [Emu] draft-lear-eap-teap-brski-05

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 5 Mar 2020 17:20:35 +0000

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*)?

Additionally, the TLS stack needs to expose the server certificate via an API so that the application layer can perform this delayed authentication. Since the spec does not define an API, are you essentially relying on implementation-specific features here?

Ciao
Hannes

(*): Mbed TLS supports this functionality but there may be other implementations that do not support this feature.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 5 Mar 2020 19:25:51 +0100

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 <[email-masked]> wrote:
> 
> Hi all, 
>  
> “
> “

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