Re: [Emu] TLS1.3 and TEAP (RE: POST WGLC Comments draft-ietf-emu-eap-tls13)

2019-11-08 Thread Jorge Vergara
> Since it looks like TEAP hasn't actually been implemented much, it's probably 
> best to move the TLS 1.3 fixes into a general "oops, we need to fix TEAP" 
> document.

I can understand the reasoning here, but it's my opinion that we should default 
to including TEAP changes for TLS1.3 in draft-dekok-emu-tls-eap-types. If the 
changes become lengthy or complex then I would understand moving them to a 
different document. But it's my belief that the currently proposed updates in 
draft-dekok-emu-tls-eap-types are sufficient. Are there further TEAP specific 
changes that are thought to be needed?

The latest Windows insider builds contain a TEAP implementation if you would 
like to play with another supplicant implementation.

-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: Thursday, November 7, 2019 9:50 AM
To: Owen Friel (ofriel) 
Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG ; John Mattsson 
; Michael Richardson 

Subject: Re: [Emu] TLS1.3 and TEAP (RE: POST WGLC Comments 
draft-ietf-emu-eap-tls13)

On Nov 7, 2019, at 12:30 PM, Owen Friel (ofriel)  wrote:
> 
> 
> [ofriel] Question to the WG: should the TEAP changes for TLS1.3 be included 
> in draft-dekok-emu-tls-eap-types?

  If they're minor, it may be OK.

> Or in draft-lear-eap-teap-brski - and note that the title is changed to " 
> TEAP Update and Extensions for Bootstrapping "? Or potentially both? Eliot, 
> Nancy and I had planned on adding TLS1.3 updates to 
> draft-lear-eap-teap-brski, but haven't got it done yet.

  Since it looks like TEAP hasn't actually been implemented much, it's probably 
best to move the TLS 1.3 fixes into a general "oops, we need to fix TEAP" 
document.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femudata=02%7C01%7Cjovergar%40microsoft.com%7Cff6d16a2debe42fe552608d763aade1d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637087458127841459sdata=uNLeQQn%2BPI2BAi1FweVNdKNG9MhBzxIu8oozlp%2F774s%3Dreserved=0

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-11-08 Thread Alan DeKok
On Nov 7, 2019, at 11:08 PM, Joseph Salowey  wrote:
> [Joe] How about 
> "If an implementation supports an external PSK it MUST provide a way to 
> configure the realm so it can create an Anonymous NAI to send in the 
> EAP-Identity response.  An EAP-TLS 1.3  implementation MUST NOT copy the 
> PSK-ID into the EAP-Identity response. "

  That's good.

> If someone thinks there is a need to allow the PSK-ID to be copied then the 
> phrase could be extended with " unless there is prior knowledge that this 
> will have an acceptable impact to privacy and the use case supports Identity 
> responses that are not in the form of an NAI.  

  ... and the PSK identity is compatible with the requirements of the EAP 
Identity field, i.e. UTF-8.

> [Joe] The TLS 1.3 base spec teats certificate auth and external PSK auth as 
> mutually exclusive for a particular handshake.   I do not think it restricts 
> a particular server from supporting both external PSK and certificate 
> authentication for separate connections.  

  OK.  I'm back to "how do you tell?"

  If the document suggests that plain PSK is OK, it would be very useful to 
describe the impact of that.  What does an implementation do?  How should 
administrators tell PSK identities apart?  If the EAP authenticator can't 
control the derivation of PSK identities for resumption, is it even possible to 
have manually provisioned PSKs?

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu