RFC 6813

The Network Endpoint Assessment (NEA) Asokan Attack Analysis

📅 published December 2012, from ietf

RFC 6813: The Network Endpoint Assessment (NEA) Asokan Attack Analysis 💖

okay bestie, this one is from the IETF (Internet Engineering Task Force) and it's labelled Category: Informational 🎀. It's published for information, not as a standard. It came out in December 2012 ✨. The ISSN is 2070-1721, and it's written by J. Salowey (Cisco Systems) and S. Hanna (Juniper Networks) 🫶. Its header doesn't list anything it obsoletes or updates.

Abstract 🌸

ngl the Network Endpoint Assessment (NEA) protocols have a sneaky forwarding attack that people now call the NEA Asokan Attack 😭. This doc breaks down the attack and the countermeasures that may be mounted against it.

Status of This Memo 📜

This document is not an Internet Standards Track specification; it is published for informational purposes.

It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that 🧚.

Info about the current status of this document, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc6813.

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License.

Table of Contents 🗺️

1. Introduction ....................................................2
2. NEA Asokan Attack Explained .....................................2
3. Lying Endpoints .................................................4
4. Countermeasures against the NEA Asokan Attack ...................4
   4.1. Identity Binding ...........................................4
   4.2. Cryptographic Binding ......................................5
        4.2.1. Binding Options .....................................5
5. Conclusions .....................................................6
6. Security Considerations .........................................6
7. Informative References ..........................................7
8. Acknowledgments .................................................7

1. Introduction ✨

okay so the NEA (Network Endpoint Assessment) [2] protocols have this subtle forwarding attack that everyone now calls the NEA Asokan Attack. This document describes the attack and the countermeasures that may be mounted. The Posture Transport (PT) protocols that the NEA working group built, PT-TLS [5] and PT-EAP [6], include mechanisms that can provide cryptographic-binding and identity-binding countermeasures 🦋.

2. NEA Asokan Attack Explained 🔥

The NEA Asokan Attack is a variation on an attack from a 2002 paper by Asokan, Niemi, and Nyberg [1] 📄. Figure 1 shows one version of the original Asokan attack. The attack tricks an authorized user into authenticating to a decoy Authentication, Authorization, and Accounting (AAA) server. That decoy then forwards the authentication protocol from one tunnel to another, which fools the real AAA server into thinking those messages came from the attacker-controlled machine. So the real AAA server grants access to the attacker-controlled machine 💀.

                            +-------------+ ========== +----------+
                            |   Attacker  |-AuthProto--|AAA Server|
                            +-------------+ ========== +----------+
                                   |
                               AuthProto
                                   |
   +--------------+ ========== +----------------+
   |AuthorizedUser|-AuthProto--|Decoy AAA Server|
   +--------------+ ========== +----------------+

              Figure 1: One Example of Original Asokan Attack

As the NEA Overview [2] describes, the NEA Reference Model is made of several nested protocols. The Posture Attribute (PA) protocol is nested in the Posture Broker (PB) protocol, and the PB protocol is nested in the PT protocol. When these protocols all work together, they let an NEA Server assess the security posture of an endpoint. The NEA Server may use that information to decide whether network access should be granted, or it may use it for other purposes 🌈.

Figure 2 shows an NEA Asokan Attack. The attacker wants to trick GoodServer into believing that DirtyEndpoint has good security posture. That could let the attacker bring an infected machine onto a network and infect others 😈. To pull it off, the attacker forwards PA messages from CleanEndpoint through BadServer to DirtyEndpoint, which sends them on to GoodServer. GoodServer thinks the PA messages came from DirtyEndpoint, so it considers DirtyEndpoint to be clean 🙈.

                            +-------------+ ========== +----------+
                            |DirtyEndpoint|-----PA-----|GoodServer|
                            +-------------+ ========== +----------+
                                   |
                                  PA
                                   |
   +-------------+ ========== +---------+
   |CleanEndpoint|-----PA-----|BadServer|
   +-------------+ ========== +---------+

                        Figure 2: NEA Asokan Attack

Countermeasures against an NEA Asokan Attack are covered in Section 4 🧚.

3. Lying Endpoints 🤥

Some people will say there are other attacks on NEA systems that are simpler than the Asokan attack, like lying endpoint attacks. And honestly, that's true 😭. It's easy for an endpoint to just lie about its posture. BUT there are defenses against lying endpoint attacks, like using an External Measurement Agent (EMA).

An EMA is hardware, software, or firmware that is especially secure, hard to compromise, and designed to report accurately on endpoint configuration. The EMA observes and reports on critical parts of endpoint posture, like which security-relevant firmware and software have been loaded 🔐.

When an EMA is used for NEA, the PA messages that reliably and securely establish endpoint posture get exchanged between the EMA itself and a Posture Validator on the NEA Server. The Posture Collector on the endpoint and any other intermediaries between the EMA and the Posture Validator on the NEA Server are not trusted. They just pass messages along as untrusted intermediaries 🦋.

To make sure the EMA's messages get accurately conveyed to the Posture Validator, even if the Posture Collector or other intermediaries have been compromised, these PA messages must provide integrity protection, replay protection, and source authentication between the EMA and the Posture Validator. Confidentiality protection is not needed, at least with respect to the software on the endpoint. But integrity protection should include protection against message deletion and session truncation. Organizations that have built EMAs have typically built remote attestation protocols that provide these properties, for example the Trusted Computing Group's (TCG's) Platform Trust Service (PTS) Protocol Binding to IF-M [7] 🛡️. Developing lying endpoint detection technologies is out of scope for NEA, but these technologies must be supported by the NEA protocols. So the NEA protocols must support countermeasures against the NEA Asokan Attack 👑.

4. Countermeasures against the NEA Asokan Attack 🎀

4.1. Identity Binding 🪪

One way to mitigate the Asokan attack is to bind the identities used in tunnel establishment into a cryptographic exchange at the PA layer. This can go a long way toward preventing the attack. However, it doesn't bind the exchange to a specific TLS exchange, which is desirable. Also, there's no standard way to extract an identity from a TLS session, and that could make implementation difficult 😬.

4.2. Cryptographic Binding 🔗

Another way to thwart the NEA Asokan Attack is for the PA exchange to be cryptographically bound to the PT exchange and to any keying material or privileges granted as a result of those two exchanges. This lets the NEA Server make sure the PA messages pertain to the same endpoint as the party terminating the PT exchange, and that no other party gains any access or advantage from this exchange 💖.

4.2.1. Binding Options ⚙️

This section discusses binding protocol solution options and provides analysis. Since PT-TLS and PT-EAP involve TLS, this document focuses on TLS-based solutions that can work with either transport 🌸.

4.2.1.1. Information from the TLS Tunnel 🚇

The TLS handshake sets up a cryptographic state between the TLS client and TLS server. Several mechanisms can export information derived from this state. The client and server each independently include this information in their calculations to bind the instance of the tunnel into the PA protocol 🧠.

Keying Material Export: RFC 5705 [8] defines Keying Material Exporters for TLS, which let additional secret key material be extracted from the TLS master secret ✨.

tls-unique Channel Binding Data: RFC 5929 [9] defines several quantities that can be extracted from the TLS session to bind the TLS session to other protocols. The tls-unique binding is made of data extracted from the TLS handshake finished message 🔑.

4.2.1.2. TLS Cipher Suites 🧁

To eliminate the possibility of a man-in-the-middle attack and thwart the Asokan attack when using the keying material export binding export mechanism, it's important that neither TLS endpoint be in sole control of the TLS pre-master secret. Cipher suites based on key transport, like RSA cipher suites, don't meet this requirement. Instead, Diffie-Hellman Cipher Suites, such as RSA-DHE, are required when this mechanism is employed 💅.

4.2.1.3. Using Additional Key Material from TLS 🗝️

Sometimes key material gets extracted from the TLS tunnel and used to derive ciphering keys for another protocol. For example, EAP-TLS [10] uses key material extracted from TLS in lower-layer ciphering. In this case the extracted keys must not be under the control of a single party, so the considerations in the previous section are important 🙌.

4.2.1.4. EMA Assumptions 🦋

The EMA needs to obtain the binding data from the TLS exchange, and it needs to prove knowledge of that binding data in an exchange that has integrity protection, source authentication, and replay protection 💜.

⏭️ part 2 is coming next, and it picks up with Section 5 (Conclusions) 🫶

5. Conclusions 🎀

okay so here's the bestie-approved checklist for beating the NEA Asokan Attack 💅

  1. Protocols should make use of cryptographic binding 🔒. Binding the identities of the tunnel endpoints in the EMA might be useful too 🫶.
  2. Specifically, L2 and L3 TLS-based PT transports (like PT-TLS and PT-EAP) should use the same cryptographic binding mechanism 👯‍♀️. Consistency is everything!
  3. The preferred approach is to use the tls-unique channel binding data from [9] ✨. The tls-unique value will be made available to the EMA, which will use it 💖. This approach can use any TLS cipher suite based on a strong cipher algorithm 🔥.

6. Security Considerations 💀

okay, serious moment, bestie 🙈. This document is mainly about analyzing the NEA Asokan Attack and proposing countermeasures for it. That does NOT mean it covers every possible attack on the NEA protocols or the NEA Reference Model 😭. Lowkey, there's a whole lot more out there. For the bigger security picture, go check the Security Considerations sections of the NEA Overview [2], PA-TNC [3], PB-TNC [4], PT-TLS [5], and PT-EAP [6] 📚🫶.

7. Informative References 📚

  • [1] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle Attacks in Tunneled Authentication Protocols", Nokia Research Center, Finland, Nov. 11, 2002, http://eprint.iacr.org/2002/163.pdf. 🦋
  • [2] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008. 🌸
  • [3] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, March 2010. 🧚
  • [4] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5793, March 2010. 💜
  • [5] Sangster, P., N. Cam-Winget, and J. Salowey, "PT-TLS: A TCP-based Posture Transport (PT) Protocol", Work in Progress, October 2012. 🍓
  • [6] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods", Work in Progress, July 2012. ✨
  • [7] Trusted Computing Group, "TCG Attestation PTS Protocol: Binding to TNC IF-M", Version 1.0, Revision 27, August 2011. 🔐
  • [8] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, March 2010. 🔑
  • [9] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, July 2010. 🌈
  • [10] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008. 👑

8. Acknowledgments 🫶

The members of the NEA Asokan Design Team were critical to building this document, and we love them for it 💕: Nancy Cam-Winget, Steve Hanna, Joe Salowey, and Paul Sangster 👑.

The authors would also like to shout out N. Asokan, Valtteri Niemi, and Kaisa Nyberg, who published the original paper on this type of attack 📝. They'd also like to recognize Pasi Eronen, who extended this attack to NEA protocols 🙌.

Authors' Addresses 🌷

Joseph Salowey Cisco Systems, Inc. 2901 3rd. Ave Seattle, WA 98121 USA EMail: jsalowey@cisco.com

Steve Hanna Juniper Networks, Inc. 79 Parsons Street Brighton, MA 02135 USA EMail: shanna@juniper.net

📦 where this page comes from