Re: [Emu] TEAP Request-Action TLV

[Oleg Pekar <[e-mail]>]

Eliot gave me some hint offline and here's what we can do in TEAP with
regards of certificate provisioning/enrollment/renewal.

In the current TEAP RFC, when the peer wants to get list of Trusted Roots
it sends Trusted-Server-Root TLV with credential type field - a constant
value 1 for PKCS#7 and with no other content. The server replies
with Trusted-Server-Root TLV and puts PKCS#7 inside it. So there's a kind
of request-response with the same TLV.

However for certificate request the peer should send PKCS#10 TLV and the
server should response with PKCS#7 TLV. It shows some inconsistency on one
hand and gives no possibility for the server to control certificate renewal.

Suggest closing that gap by introducing a new "Peer-Certificate TLV" with
exactly the same format as Trusted-Server-Root TLV.

   - When the peer wants to request a certificate it
   sends "Peer-Certificate TLV" with credential type field equal to 1
   for PKCS#7 and optional PKCS#10 TLV as a content
   - If no PKCS#10 TLV attached then the server can just renew the existing
   certificate if it has such capabilities and required data (or can say that
   the peer wants a certificate based on its current certificate and the
   current server policies).
   - If PKCS#10 TLV is attached then the server generates peer certificate
   according to the data in the request
   - If the server wants to generate peer certificate it may reply with
   "Peer-Certificate TLV" with credential type field equal to 1 for PKCS#7
   and PKCS#10 TLV as a content.
   - If the server wants the peer to send certificate request with all the
   data - it sends "Peer-Certificate TLV" with credential type field equal to
   1 for PKCS#7 and no content
   - We don't need to use Request-Action TLV in the whole flow

Would that work?

Regards
Oleg

On Wed, May 6, 2020 at 4:57 PM Oleg Pekar <[e-mail]> wrote:

> Hi Eliot,
> Few thoughts:
>
>    - If the current client's certificate was requested via TEAP by
>    PKCS#10 TLV - then maybe it makes sense for the client to send
>    Request-Action TLV + PKCS#10 TLV again with the same certificate parameters
>    - If the current client's certificate was not requested via TEAP -
>    then there's no evidence that the certificate renewal will be addressed
>    (maybe TEAP is not connected to any CA)
>    - If the current client's certificate was obtained from the external
>    CA (e.g. via SCEP or EST) - then there's no evidence that the certificate
>    renewal will be addressed
>    - If the current client's certificate was preinstalled - then the
>    client may not have a clue what does it want and will be unable to
>    fill PKCS#10 request. On the other hand, the CA that TEAP server is
>    connected to could be unable to generate certificate with exactly the same
>    properties and the current client certificate. Simple example: the current
>    certificate is ECDSA and the CA can generate RSA only. Hard example: the
>    current client certificate contains vendor specific extensions like Policy
>    or Template Name. So it will be hard to put those extensions to the
>    generated certificate
>
> Regards
> Oleg
>
> On Thu, Apr 30, 2020 at 4:19 PM Eliot Lear <lear=
> [e-mail]> wrote:
>
>> 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
>> _______________________________________________
>> Emu mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/emu
>>
>