Re: [Emu] More TEAP issues

[Alan DeKok <[e-mail]>]

On Dec 16, 2022, at 6:42 AM, Owen Friel (ofriel) <[e-mail]> wrote:
> 
> 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.

  While these are useful, I think we need to take care with extending the document.  If updates are just defining new TLVs, that seems OK.  Anything past that will push out the publication date, which is problematic.

> 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.

  If we can make the TLVs generic, that may be possible.  i.e. define a new TLV, but without going into details about use-cases.  That way multiple use-cases can leverage the TLV.

  i.e. if the TLV is specific to brski bootstrapping, it shouldn't go into the 7170-bis document.  If they're generic "contains CSR stuff...", then could be useful to add them, and note that detailed use-cases come later.

  But my inclination is to just patch 7170 based on implementation experience, and change nothing else.  That way it can go out the door quickly, and be used in shipping products.

  Alan DeKok.