There are a few useful TLVs defined in https://datatracker.ietf.org/doc/html/draft-lear-eap-teap-brski-06
CSR Attributes as Eliot has mentioned, as well as e.g. Retry-After TLV which could be useful if the TEAP server has to communicate with a backend CA to get a PKCS#10 CSR signed. There is also a cert issuance use case that https://www.rfc-editor.org/rfc/rfc7170#section-3.8.2 does not account for. The section recommends using tls-unique channel binding in the PKCS#10 CSR so that server can verify that the client holds the private key associated with the public key in the CSR. This assumes that the public/private keypair were used in the outer tunnel TLS handshake. This makes sense if a client is using an LDevID to establish the TEAP tunnel, and wants to reenroll to get a new LDevID that has the same keypair e.g. the cert is about to expire. It does not account for the bootstrapping use case where a client has a manufacturing time installed IDevID and needs a deployment-specific LDevID for network access. It establishes the outer tunnel using the keys in its IDevID, but is sending a PKCS#10 CSR with different keys. Therefore the proposed tls-unique binding will fail. Maybe addressing this (and the various TLVs proposed in draft-lear-eap-teap-brski) is too much to bite off in rfc7170bis and we need to revisit and address in draft-lear-eap-teap-brski. -----Original Message----- From: Emu <emu-boun...@ietf.org> On Behalf Of Eliot Lear Sent: Wednesday 30 November 2022 06:24 To: Joseph Salowey <j...@salowey.net>; Alan DeKok <al...@deployingradius.com> Cc: EMU WG <emu@ietf.org> Subject: Re: [Emu] More TEAP issues I'd support a revision as well. See below: On 30.11.22 02:14, Joseph Salowey wrote: > [Joe] speaking as a participant, I'd be happy to assist with a > revision. I think it is needed. Most of the current errata are > tracked here - https://github.com/emu-wg/teap-errata/pulls. I think > the target would be to obsolete 7170 with a revision that just fixes > the errata and makes any needed clarifications. We can also work on > posting the Errata, but the revised document would be more effective > at getting these issues fixed. I'd also like to take some time to consider what additional TLVs may be required. Right now there is an incongruence between TEAP and other protocols that sign certs in that there is no CSR attributes TLV. There may be several others to consider. 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