>> This raises the question what TEAP TLS 1.2 implementations do today? Are
>> they only using outdated and non-secure cipher suites or are they doing
>> something unspecified to derive Compound-MAC with an AEAD cipher suite?
> It's not clear. I'd have to double-check hostap, which is the
On Sep 1, 2020, at 12:05 PM, John Mattsson
wrote:
>
> I have reviewed draft-ietf-emu-tls-eap-types-01. Looks good. Two crypto
> related comments below:
>
> - "MAC is the MAC function negotiated in TLS 1.3."
>
> There is no MAC function negotiated in TLS 1.3. Also, a modern TLS
>
Hi,
I have reviewed draft-ietf-emu-tls-eap-types-01. Looks good. Two crypto related
comments below:
- "MAC is the MAC function negotiated in TLS 1.3."
There is no MAC function negotiated in TLS 1.3. Also, a modern TLS
implementation would not negotiate any MAC funtion in TLS 1.2 as they
Hi,
If the ability to send a descriptive TLS Fatal Alert back to the peer is a
requirement, changing to close_notify seems like a bad idea. My understanding
is that is would add an extra roundtrip without any clear benefits compared to
sending an encrypted 0x00 application data.
EAP Peer
On Sep 1, 2020, at 8:24 AM, John Mattsson wrote:
> Reading up on the mail discussion more (I have been on parental leave), I
> don't see any real motivation for this late technical change suggestion...
My $0.02 is that it's philosophical. EAP-TLS does authentication using TLS.
Adding an
Hi,
Reading up on the mail discussion more (I have been on parental leave), I don't
see any real motivation for this late technical change suggestion...
Hannes wrote that the draft-ietf-emu-eap-tls13 does not work with Mbed because
it introduces a new message and requires unencrypted data. One
Hi,
Note that close_notify (no more data) is not an exact replacement for the
Commitment Message (no more handshake data). A change from 0x00 to close_notify
invalidates Figure 6: EAP-TLS unsuccessful client authentication in the
document.
EAP Peer