On Mar 25, 2019, at 12:59 AM, John Mattsson <[email protected]> wrote:
>
> Noticed the following:
>
> draft-ietf-emu-eap-tls13-04 defines the key hierarchy as
>
> Type-Code = 0x0D
> Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
> Type-Code, 128)
> IV = TLS-Exporter("EXPORTER_EAP_TLS_IV",
> Type-Code, 64)
> Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",
> Type-Code, 64)
> Session-Id = Type-Code || Method-Id
>
> But section 1.4 of RFC 5247 defines Session-Id as
>
> Session-Id = Type-Code || Method-Id
>
> or
>
> Session-Id = 0xFE || Vendor-Id || Vendor-Type || Method-Id
>
> The definition in draft-ietf-emu-eap-tls13-04 does not seem compatible with
> extended EAP types.
TBH, the simple approach is to extend the definition of Type-Code when
extended types are used.
Type-Code = 0x0d
for types < 254
Type-Code = 0xFE || Vendor-Id || Vendor-Type
for extended types
And then use that definition for Key_Material, Method-Id, Session-Id, etc.
Alan DeKok.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
