Subject: [Emu] TEAP Request-Action TLV

From: Eliot Lear <[email-masked]>
Date: Thu, 30 Apr 2020 15:19:27 +0200

All:

Here is a circumstance one could easily imagine, and in fact we attempted to address in draft-lear-eap-teap-brski:

Client requires a new certificate for some reason or another.  Perhaps its is about to expire, or perhaps the signer has been compromised, or what have you.

We were thinking that we could use the Request-Action Frame for this purpose with a type of PKCS#10.  But that now seems wrong, as the language in the draft states that one appends a Request-Action frame with a full TLV, and not just a type,  and further that the other end process the TLV.  In looking at Jouni’s code, he is doing precisely that with the PAC TLV.

And so it seems we have three choices:

Create a new TLV that has a length of two that can be used in a REQUEST_ACTION frame.
Create a new TLV that is what we thought we meant: here is a list of two(ish)-byte types whose TLVs I want you to send to me.
Hard code the ordering of requests so everyone knows what to expect.

Each of these has its own problems. 

The first requires that we create a new EAP TYPE for TLV one end needs the other to send, but it’s pretty easy to process. The second requires extra processing but requires less standardization.  The last seems to go against the EAP model and reduces deployment flexibility.

Thoughts?

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Apr 2020 14:53:39 -0400

Eliot Lear <lear=[email-masked]> wrote:
    > Here is a circumstance one could easily imagine, and in fact we
    > attempted to address in draft-lear-eap-teap-brski:

    > Client requires a new certificate for some reason or another.  Perhaps
    > its is about to expire, or perhaps the signer has been compromised, or
    > what have you.

I think that's a really bad example.  I can talk about the reasons, but I
think it would detract from your query.
Maybe you can give me a different use case?

    > We were thinking that we could use the Request-Action Frame for this
    > purpose with a type of PKCS#10.  But that now seems wrong, as the
    > language in the draft states that one appends a Request-Action frame
    > with a full TLV, and not just a type,  and further that the other end
    > process the TLV.  In looking at Jouni’s code, he is doing precisely
    > that with the PAC TLV.

    > Create a new TLV that is what we thought we meant: here is a list of
    > two(ish)-byte types whose TLVs I want you to send to me.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Eliot Lear <[email-masked]>
Date: Thu, 30 Apr 2020 21:03:01 +0200

> On 30 Apr 2020, at 20:53, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

Certificate do need to roll, and we should handle that case.  One could use the ACME/LE model of just periodically sending a PKCS#10 request after 2/3rds of the expiry is past, but that doesn’t help us in the case where the signing cert needs to roll.

> Maybe you can give me a different use case?

A different use case might be (later on), “please send me a RATS attestation”.  The key point is that the EAP server is a good control channel to gate clients in a lock step fashion, but the Request-Action TLV doesn’t quite get us there, as written, as I see it.

Eliot