Re: [Emu] RFC7170bis and lack of identities

[Alan DeKok <[e-mail]>]

On Feb 7, 2023, at 1:04 AM, Joseph Salowey <[e-mail]> wrote:
> [Joe]  The intent here was that the client authenticated using a certificate during the TLS handshake and that the server viewed this as sufficient to meet the authentication requirements, but the client requires another method to be executed so it uses the request action frame to start up a new exchange.   Example C4 shows TLS client authentication with renegotiation, but it seems a bit weird to me in that it is client initiated in response to a server EAP-IDentity Request.  
> 
> Did you find out if any of this is supported? 

  We support authentication via client certs for all TLS-based EAP methods.  However, that isn't currently tied into TEAP.

  i.e. the client can send a cert, and the TEAP server will check it.  But that won't affect the protocol exchange in phase 2.

  I think that's easy to change in the code, and it's worth leaving in the document.  Especially as TLS 1.3 hides the client certificate information.  And draft-ietf-emu-tls-eap-types allows the use of client certs with TEAP for TLS 1.3, too.

  And just comparing the "tls-eap-types" document to this one, this one is missing discussion about client certs sent in phase 1.  i.e.

* client certs MUST include Identity-Type as an outer TLV, in order to signal the type of identity which that client certificate is for.

* if there's a client cert, then something MUST happen in phase 2, otherwise TEAP devolves to EAP-TLS.

  I'll add some text.

> [Joe] Although this seems OK, I'd rather be removing things than adding things. I think we should make sure that the working group wants this.  

  I agree.  I do think that this is one of those "here be dragons" issues.  Where people decide one way because of lack of information about the "correct" way to do it.  And then later realize the decision should have gone the other way.

  I think the only way to side-step this issue is to realize that the lack of an Identity-Hint TLV means TEAP deployments will be limited to either password, OR EAP authentication in phase 2, but not both in the same system.

  Alan DeKok.