Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-06.txt

[John Mattsson <[e-mail]>]

Hi,

I read through the high level parts of the draft and have following comments:


- "compromising smart cards"
  Not sure the attacks actually attacked the smart cards. I suggest reformulating this as
  "compromising the smart card supply chain".


- I think the draft should mention zero-trust. Suggestion to add the following text:
  "Always assuming breach such as key compromise and minimizing the impact of breach are essential zero-trust principles. Forward secrecy is therefore a requirement for zero-trust"


- I think the draft should add mandatory client identity protection. EAP-TLS 1.3 (RFC 9190) has the following requirement, which makes a lot of sense:

  "A client supporting TLS 1.3 MUST NOT send its username
   (or any other permanent identifiers) in cleartext in the Identity
   Response (or any message used instead of the Identity Response)."

  I think mandatory to use client identity protection should be a requirement in all
  future EAP methods. I suggest adding similar text:

    "A client supporting EAP-AKA' FS MUST NOT send its username
   (or any other permanent identifiers) in cleartext in the Identity
   Response (or any message used instead of the Identity Response)."


- "or turn off FS."

  I think the draft should have a recommendation to long term completely phase out AKA without FS. Best practice security today is very clearly to mandate FS for this type of access authentication (as is done in WPA3, EAP-TLS 1.3, EAP-TTLS 1.3, etc).


- I think the description of consequences of key compromise can be improved. My summary would be:

"If a mechanism without forward secrecy (5G-AKA, EAP-AKA’) is used the effects of key compromise are devastating. The serious consequences of breach somewhere in the supply chain or after delivery that are possible when 5G-AKA or EAP-AKA' is used but not when something with forward secrecy like EAP-AKA-FS is used are:

1. A passive attacker can eavesdrop (decrypt) all future 5G communication (control and user plane both directions).
2. A passive attacker can decrypt 5G communication that they previously recorded in the past (control and user plane both directions).
3. An active attacker can impersonate UE and Network and inject messages in an ongoing 5G connection between the real UE and the real network (control and user plane both directions).
4. An active attacker modify messages (block real message and send new modified message) in an ongoing 5G connection between the real UE and the real network (control and user plane both directions)."

I think only 1. is described in detail. At least 2. And 3. deserves a detailed explanation.


- I think the draft should have security considerations on the limits of forward secrecy and why frequent use of Diffie-Hellman (i.e. frequently rerunning EAP-AKA' FS) provides even better security and privacy against key compromise. The following text written by me was just added to RFC8446bis. Could be a basis for
text added to EAP-AKA' FS.

"Forward secrecy limits the effect of key leakage in one direction (compromise of a key at time T2 does not compromise some key at time T1 where T1 < T2). Protection in the other direction (compromise at time T1 does not compromise keys at time T2) can be achieved by rerunning EC(DHE). If a long-term authentication key has been compromised, a full handshake with EC(DHE) gives protection against passive attackers. If the resumption_master_secret has been compromised, a resumption handshake with EC(DHE) gives protection against passive attackers and a full handshake with EC(DHE) gives protection against active attackers. If a traffic secret has been compromised, any handshake with EC(DHE) gives protection against active attackers. Using the terms in {{RFC7624}}, forward secrecy without rerunning EC(DHE) does not stop an attacker from doing static key exfiltration. After key exfiltration of application_traffic_secret_N, an attacker can e.g., passively eavesdrop on all future data sent on the connection including data encrypted with application_traffic_secret_N+1, application_traffic_secret_N+2, etc. Frequently rerunning EC(DHE) forces an attacker to do dynamic key exfiltration (or content exfiltration)."

Cheers,
John

From: Emu <[e-mail]> on behalf of [e-mail] <[e-mail]>
Date: Monday, 7 March 2022 at 22:20
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [Emu] I-D Action: draft-ietf-emu-aka-pfs-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update WG of the IETF.

        Title           : Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)
        Authors         : Jari Arkko
                          Karl Norrman
                          Vesa Torvinen
        Filename        : draft-ietf-emu-aka-pfs-06.txt
        Pages           : 26
        Date            : 2022-03-07

Abstract:
   Many different attacks have been reported as part of revelations
   associated with pervasive surveillance.  Some of the reported attacks
   involved compromising smart cards, such as attacking SIM card
   manufacturers and operators in an effort to compromise shared secrets
   stored on these cards.  Since the publication of those reports,
   manufacturing and provisioning processes have gained much scrutiny
   and have improved.  However, the danger of resourceful attackers for
   these systems is still a concern.

   This specification is an optional extension to the EAP-AKA'
   authentication method which was defined in [RFC9048].  The extension,
   when negotiated, provides Forward Secrecy for the session key
   generated as a part of the authentication run in EAP-AKA'.  This
   prevents an attacker who has gained access to the long-term pre-
   shared secret in a SIM card from being able to decrypt any past
   communications.  In addition, if the attacker stays merely a passive
   eavesdropper, the extension prevents attacks against future sessions.
   This forces attackers to use active attacks instead.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-emu-aka-pfs-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-aka-pfs-06


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


_______________________________________________
Emu mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/emu