On Jan 9, 2023, at 6:24 AM, Alexander Clouter <alex+i...@coremem.com> wrote:
> 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.
Yes, that's a good change.
> 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.
Agreed. Maybe we need to change the IMSK definition to use IMSK[j]:
IMSK[j] = First 32 octets of TLS-PRF(EMSK[j], "teapbind...@ietf.org",
0x00 \| 0x00 \| 0x40)
And note that the inner key is EMSK[j] or MSK[j], depending...
> The problematic bit is what happens to 'j' if there is no EMSK for one of the
> methods in a sequence?
All zeros?
> 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.
I've changed that to "last successful inner method", where "inner method" has
a new definition of "any inner authentication".
> 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.
I don't think so.
> 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?
I would say "required":
Where a Vendor-Specific TLV carries an authentication protocol in the
inner method, it MUST define values for MSK and EMSK. Where these
values cannot be derived from cryptographic primitives, they MUST be
set to zero, as happens when Basic-Password-Auth-Req is used.
> 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}'.
Every inner method MUST derive IMSK. It can be all zeros. Anything else is
painful.
> 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 )
Yes.
> 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" :-/
I'll put some text together.
> 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
Yes, We still have to decide if this document updates TEAP for TLS 1.3.
Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
