Re: [Emu] Issue 59 - Key Update

On Mon, Apr 12, 2021 at 4:58 AM Alan DeKok wrote: > On Apr 11, 2021, at 10:40 PM, Joseph Salowey wrote: > > This does seem to require some more specification. Here is a proposal. > > > > "TLS 1.3 introduced the Post-Handshake KeyUpdate message which is not > useful and not expected in EAP-TLS.

Re: [Emu] Issue 47 Certificate identity checks

> On 12 Apr 2021, at 18:25, Joseph Salowey > wrote: > >> >> I would agure there that the federation should have it's own CA. > > That’s what I’m thinking. But I could imagine hardcoded devices that make > use of it. That’s all. > > > [Joe] Relying on a burned

Re: [Emu] Issue 47 Certificate identity checks

On Apr 12, 2021, at 2:15 PM, Tim Cappalli wrote: > > Pinning the server certificate is unrealistic. A properly configured > supplicant with a trusted private root and subject match is adequate and > allows good security hygiene with server cert rotation. While I agree, many customers don't.

Re: [Emu] Issue 47 Certificate identity checks

Pinning the server certificate is unrealistic. A properly configured supplicant with a trusted private root and subject match is adequate and allows good security hygiene with server cert rotation. I believe the id-kp-eapOverLAN EKU should be a MUST. Public CAs should not be issuing server

Re: [Emu] Issue 47 Certificate identity checks

> On 12 Apr 2021, at 19:54, Alan DeKok wrote: > > On Apr 12, 2021, at 12:22 PM, Joseph Salowey wrote: >> [Joe] without some sort of name matching using certs from a public CA is >> unwise. > > The only other alternative is to "pin" the server cert. Many systems > support this. Perhaps

Re: [Emu] Issue 47 Certificate identity checks

On Apr 12, 2021, at 12:22 PM, Joseph Salowey wrote: > [Joe] without some sort of name matching using certs from a public CA is > unwise. The only other alternative is to "pin" the server cert. Many systems support this. Perhaps mentioning Time of First Use (TOFU) would help here.

Re: [Emu] Issue 47 Certificate identity checks

On Mon, Apr 12, 2021 at 6:02 AM Eliot Lear wrote: > Hi Alan, > > On 12 Apr 2021, at 14:52, Alan DeKok wrote: > > > EAP TLS peer implementations MUST allow for configuration of a unique > trust root to validate the server's certificate. > > > This statement seems independent of the previous one,

Re: [Emu] Issue 47 Certificate identity checks

On Mon, Apr 12, 2021 at 5:48 AM Alan DeKok wrote: > On Apr 11, 2021, at 11:19 PM, Joseph Salowey wrote: > > RFC 5216 lacks guidance on how to validate the EAP server's certificate > especially with respect to identities. > > Yes. :) > > > RFC 5216 recommends validating the certificate path

Re: [Emu] Issue 47 Certificate identity checks

On Apr 11, 2021, at 11:19 PM, Joseph Salowey wrote: > 2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN EKU > specified in RFC 3770. EAP TLS peer implementations SHOULD allow for the > configuration to require the id-kp-eapOverLAN EKU for validation of EAP > server

Re: [Emu] Issue 47 Certificate identity checks

Hi Alan, > On 12 Apr 2021, at 14:52, Alan DeKok wrote: > >>> >>> EAP TLS peer implementations MUST allow for configuration of a unique trust >>> root to validate the server's certificate. >> >> This statement seems independent of the previous one, and may be overly >> broad. Let me give

Re: [Emu] Issue 47 Certificate identity checks

On Apr 12, 2021, at 3:54 AM, Eliot Lear wrote: > “EAP peers need to have some basis to decide which networks are authorized. > A key signal for this purpose is the validation of the server certificate. > To prevent use of the wrong server, the peer SHOULD have some means to select > and

Re: [Emu] Issue 47 Certificate identity checks

On Apr 11, 2021, at 11:19 PM, Joseph Salowey wrote: > RFC 5216 lacks guidance on how to validate the EAP server's certificate > especially with respect to identities. Yes. :) > RFC 5216 recommends validating the certificate path is valid and that the > extended key usage attributes are

Re: [Emu] Issue 59 - Key Update

On Apr 11, 2021, at 10:40 PM, Joseph Salowey wrote: > This does seem to require some more specification. Here is a proposal. > > "TLS 1.3 introduced the Post-Handshake KeyUpdate message which is not useful > and not expected in EAP-TLS. Implementations SHOULD NOT send a KeyUpdate > message.

Re: [Emu] Issue 61 Clarifying NAI handling during resumption

On Apr 11, 2021, at 11:39 PM, Joseph Salowey wrote: > Alan's review raised the issue that the text allows for different identities > to be used for the initial handshake and subsequent resumption. Instead the > proposal is to always use the same NAI for resumption as for the initial >

Re: [Emu] Issue 47 Certificate identity checks

Hi Joe, I’m okay with most of this text except for as follows: > 2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN EKU > specified in RFC 3770. The above sentence is unnecessary. Of COURSE CAs can issue certs with that EKU or any other. What I think you mean is this: