Hello,
On Wed, 23 Jul 2025, at 15:53, Alan DeKok wrote:
>
>> This would then no longer be limited to TEAP, you could maybe even retrofit
>> it to EAP-(T)TLS.
>
> TTLS would need to define a TTLS-specific attribute but sure.
No, it would be coupled to EAP-TLS and the exporter there, no changes or
extensions to any EAP methods are proposed.
So the machinery after a successful outer-TLS based EAP authentication:
DHCP-Option Value = H(Nonce + TLS-Exporter('eap-tls-and-dhcp-have-a-baby', ...))
Client includes in its DHCP Discovery includes this value.
DHCP Server uses this to figure out if it was a recent successful TLS session,
fetches the TLS Exporter key.
DHCP responds with an Offer including an option where the value is an HMAC
using the TLS-Exporter as a key.
Caveats:
* DHCP relays reordering the options; fortunately canonical ordering is not a
problem, all the option keys are numerics
* do inner TLS methods get chained onto the outer method?
* this is not a statement of "this is a good crypto sausage machine", its just
as a something we can massage into something that might work
Now vendors only need to have the DHCP server and RADIUS/EAP servers talk to
one another rather than having the switchport kit involved; a much easier task.
I understand some vendors even support RADIUS and DHCP in their server
implementation... :)
Cheers
Alex
_______________________________________________
Emu mailing list -- [email protected]
To unsubscribe send an email to [email protected]
