Re: [Emu] TEAP Request-Action TLV
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 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 40cisco@dmarc.ietf.org> 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 >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu >> > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] TEAP Request-Action TLV
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 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 > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] TEAP Request-Action TLV
> On 30 Apr 2020, at 20:53, Michael Richardson wrote: > > Signed PGP part > > Eliot Lear 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. 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 signature.asc Description: Message signed with OpenPGP ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] TEAP Request-Action TLV
Eliot Lear 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. > 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. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] TEAP Request-Action TLV
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 Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
