On Thu, 5 Jan 2023, at 20:13, internet-dra...@ietf.org wrote: > Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1 > Filename : draft-ietf-emu-rfc7170bis-02.txt > Pages : 101 <-- "now available over the counter to deal with > insomnia..." > Date : 2023-01-05
...Section 5 deserves a thread of it's own. Going to skip the bits around 'to-length-or-not-to-length' as there is an active discussion on this over at: https://www.rfc-editor.org/errata/eid5128: https://github.com/emu-wg/rfc7170bis/commit/fd8a7e809051c0ddc0d63a45a2546795242cf447 [Emu] Resolution for TEAP Errata 5128: https://mailarchive.ietf.org/arch/msg/emu/kd2LUuUPcUjiKVlfpRsNV8WLSbA/ Section 5.1 TEAP Authentication Phase 1: Key Derivations Can we slip in the equation definition too with the worded definition (assuming 'length' language which is a different debate[1]): session_key_seed = TLS_Exporter("EXPORTER: teap session key seed", , 40) This helps those with bad habits (ie. me!) that skim read and rely on grep/Ctrl-f to get the definition quickly for what they need at the time. Section 5.2 - Intermediate Compound Key Derivations The big one here, which impacts section 5.4 was highlighted in https://www.rfc-editor.org/errata/eid5770 by Jouni (hostapd author). To actually implement this, the *least* contradictory and inconsistent with the RFC way to do so is to track separately a MSK based S-IMCK and EMSK (where available) based S-IMCK. You then use, and carry over So this is how hostapd implemented it, and it turns out so did Win10/11. FreeRADIUS did so to as...well...erm...interop and all. So we need to tell implementers instead to carry around both S-IMCK{MSK}[j] and S-IMCK{EMSK}[j], especially through EAP sequences. The problematic bit is what happens to 'j' if there is no EMSK for one of the methods in a sequence? Section 5.3 does offer the tidbit "...where j is the number of the last successfully executed inner EAP method" but that means we now we have two *independent* values for j in EAP sequences. Could it be considered a jump that the 'j' in section 5.3 is the same 'j' in section 5.2? I believe it is the same as 'j' in section 5.4 is obviously the same 'j' found in section 5.2. This may have been ignorable simply as I suspect no one does the EAP sequence EAP-FAST-MSCHAPv2[user] (MSK only) *followed* by EAP-TLS[machine] (EMSK), it typically is the other way around. On a related note, is a Vendor-Specific TLV allowed to emit a MSK or EMSK that can be used in the S-IMCK calculation? So section 5.2 should be amended to show that there is simultaneously a MSK and EMSK seeded S-IMCK[j{msk,emsk}] being used throughout. It needs to be explicitly highlighted that 'j' is *not* the "index of the EAP method in a sequence" but is now 'j{msk}' and 'j{emsk}' where each is only incremented when a EAP method (or Vendor-Specific TLV?) emits a MSK or EMSK. IIRC a zero-MSK increments 'j{msk}'. Section 5.3 - Computing the Compound MAC It is utterly confusing to have: CMK = CMK[j] Compound-MAC = MAC( CMK, BUFFER ) Can this be changed to the much simpler (and grep'able): Compound-MAC = MAC( CMK[j], BUFFER ) Section 5.4 - EAP Master Session Key Generation So the $64,000 question is, what is S-IMCK[j] here? 1. MSK|EMSK uses the *same* S-IMCK[j] value, and that value is either S-IMCK[j{msk}] *or* S-IMCK[j{emsk}] and the logic on which depends on something else 2. MSK is S-IMCK[j{msk}] and EMSK is S-IMCK[j{emsk}] For FreeRADIUS the most interoperable option I used was the first option which ended up being "use the EMSK version if the client Cryptobinding TLV includes a verified EMSK, otherwise carry the MSK version". I could probably do better and instead having thought of it tried the second approach which probably would also work...probably...probably not..."needs more testing" :-/ Maybe an ASCII diagram showing when 'j' increments in an EAP Sequence would help others? Maybe we should get the wording done first and see if that clears things up enough? Thanks [1] which will impact implementations for TLSv1.3 as the content output of TLS_Exporter varies with the requested output length _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
