On Sat, 26 Aug 2023 at 21:13, Michael Richardson
wrote:
>
> Heikki Vatiainen wrote:
> > Test with Windows 11 and eapol_test - EAP-TLS followed by EAP-MSCHAPv2
>
> Are you saying that Windows 11 also has implemented (accessible via
> "insider
> program" only)?
>
I think TEAP has been generally a
On Sun, 27 Aug 2023, at 10:57, Heikki Vatiainen wrote:
> Weren't the observed differences against RFC 7170 one the main
> reasons why the draft was needed?
Exactly. In particular it was the use of the EAP-FAST-MSCHAPv2 key derivative
(reversed upper/lower bits) that triggered this and the fun aro
On Fri, 25 Aug 2023 at 22:30, Eliot Lear wrote:
> I agree with the sentiment, but I think it would be good for the words
> to soak a bit, since the paragraphs are a little involved. There may be
> a simpler way to say the same thing.
>
The diff between RFC 7170 and the current draft may help wit
On Aug 27, 2023, at 10:42 AM, Heikki Vatiainen
wrote:
> The diff between RFC 7170 and the current draft may help with the proposed
> change. I just noticed that 'EAP' was used more in the RFC than in the draft:
Yes. 7170 referred to "inner EAP method" in many places, even when it mean
"any
RFC 7170 and the current draft have diverged in how IMSK is calculated.
In short:
1. RFC 7170 pass EMSK to TLS-PRF whereas the draft passes both EMSK and MSK
to TLS-PRF.
2. While RFC 7170 adjusts only MSK to 32 octet length, the draft adjusts
both EMSK and MSK.
See section 5.2 "Intermediate Compo
Heikki
This change looks good. I want to code it with the PKCS ops to make
sure it's okay. That'll take a little bit.
Eliot
On 27.08.23 19:16, Heikki Vatiainen wrote:
RFC 7170 and the current draft have diverged in how IMSK is calculated.
In short:
1. RFC 7170 pass EMSK to TLS-PRF whereas
