Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarifications and considerations regarding forward secrecy #97

Open
emanjon opened this issue Nov 12, 2021 · 0 comments
Open

Clarifications and considerations regarding forward secrecy #97

emanjon opened this issue Nov 12, 2021 · 0 comments

Comments

@emanjon
Copy link
Member

emanjon commented Nov 12, 2021

@ms-s @jsalowey @kaduk

https://mailarchive.ietf.org/arch/msg/saag/6ImeENhteXGdLsnaJHRoN6LW1zk/

I think it would be good to have some additional clarifications and considerations regarding forward secrecy. TLS 1.3 (RFC 8446) uses the term "forward secrecy" for both the asymmetric (EC)DHE and the symmetric KeyUpdate. EAP-TLS 1.3 proudly states that is always gives forward secrecy but EAP-TLS 1.3 differs from TLS 1.3 as EAP-TLS 1.3 uses (EC)DHE but does not use KeyUpdate. To get similar protection as offered by TLS KeyUpdate, the application using the MSK or EMSK would need to implement something similar to KeyUpdate. KeyUpdate types of mechanisms limits the effects of key leakage in one direction but an attacker can still do so called static key exfiltration [RFC 7624]. To mitigate static key exfiltration, the application would need to regularly rerun EAP-TLS 1.3, this forces attackers to dynamic key exfiltration [RFC 7624].

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant