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

Reply via email to