On Sat, 25 Mar 2023 at 10:53, Alexander Clouter <alex+i...@coremem.com>
wrote:
> Conjuring up a scenario so it can be picked apart and discussed...
>
> Is it possible to build an implementation of something like EAP-TLS backed
> by an external system (ie. TPM/hardward-offload) and the EMSK material are
> not avaliable?
>
> RFC5247 section 1.2 has this to say about the EMSK: "...and is never
> shared with a third party." I read this to include any userspace code
> implementation (ie. Radiator, FreeRADIUS, hostapd, ...) as a 'third party'
> as section 1.5 there also labels the backend authentication server as a
> third party.
>
> If the other end was an implementation though that does provide the EMSK,
> we would have a legitimate split.
>
That might be the case if there's an API that hides TLS-Exporter output and
only hands out MSK while making EMSK unavailable.
With TLSv1.3 that would be even more intentional because the requested
length affects the exporter output.
To refresh everyones recollection of this, when TLS-Exporter is used, MSK
comes first followed by EMSK. Using EAP-TLSv1.3 RFC as an example:
Type = 0x0D
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
Type, 128)
[cut some other definitions]
MSK = Key_Material(0, 63)
EMSK = Key_Material(64, 127)
--
Heikki Vatiainen
h...@radiatorsoftware.com
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
