idnits 2.17.1 draft-ietf-nea-asokan-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2012) is 4200 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-nea-pt-tls-07 == Outdated reference: A later version (-09) exists of draft-ietf-nea-pt-eap-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Salowey 2 Internet Draft Cisco Systems 3 Intended status: Informational S. Hanna 4 Expires: April 2013 Juniper Networks 5 October 19, 2012 7 NEA Asokan Attack Analysis 8 draft-ietf-nea-asokan-02.txt 10 Abstract 12 The Network Endpoint Assessment protocols are subject to a subtle 13 forwarding attack that has become known as the NEA Asokan Attack. 14 This document describes the attack and countermeasures that may be 15 mounted. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on April 19, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with 50 respect to this document. Code Components extracted from this 51 document must include Simplified BSD License text as described in 52 Section 4.e of the Trust Legal Provisions and are provided without 53 warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction...................................................2 58 2. NEA Asokan Attack Explained....................................2 59 3. Lying Endpoints................................................4 60 4. Countermeasures Against The NEA Asokan Attack..................4 61 4.1. Identity Binding..........................................4 62 4.2. Cryptographic Binding.....................................5 63 4.2.1. Binding Options......................................5 64 5. Conclusions....................................................6 65 6. IANA Considerations............................................6 66 7. Security Considerations........................................6 67 8. References.....................................................6 68 8.1. Informative References....................................6 69 9. Acknowledgments................................................7 71 1. Introduction 73 The Network Endpoint Assessment [2] protocols are subject to a 74 subtle forwarding attack that has become known as the NEA Asokan 75 Attack. This document describes the attack and countermeasures that 76 may be mounted. The posture transport (PT) protocols developed by 77 the NEA working group, PT-TLS [5] and PT-EAP [6], include mechanisms 78 that can provide cryptographic binding and identity binding 79 countermeasures. 81 2. NEA Asokan Attack Explained 83 The NEA Asokan Attack is a variation on an attack described in a 84 2002 paper written by Asokan, Niemi, and Nyberg [1]. Figure 1 85 depicts one version of the original Asokan attack. This attack 86 involves tricking an authorized user into authenticating to a decoy 87 AAA server, which forwards the authentication protocol from one 88 tunnel to another, tricking the real AAA server into believing these 89 messages originated from the attacker controlled machine. As a 90 result the real AAA server grants access to the attacker controlled 91 machine. 93 +-------------+ ========== +----------+ 94 | Attacker |-AuthProto--|AAA Server| 95 +-------------+ ========== +----------+ 96 | 97 AuthProto 98 | 99 +--------------+ ========== +----------------+ 100 |AuthorizedUser|-AuthProto--|Decoy AAA Server| 101 +--------------+ ========== +----------------+ 103 Figure 1: One Example of Original Asokan Attack 105 As described in the NEA Overview [2], the NEA Reference Model is 106 composed of several nested protocols. The PA protocol is nested in 107 the PB protocol, which is nested in the PT protocol. When used 108 together successfully, these protocols allow a NEA Server to assess 109 the security posture of an endpoint. The NEA Server may use this 110 information to decide whether network access should be granted or 111 for other purposes. 113 Figure 2 illustrates a NEA Asokan Attack. The attacker wants to 114 trick GoodServer into believing that DirtyEndpoint has good security 115 posture. This might allow the attacker to bring an infected machine 116 onto a network and infect others, for example. To accomplish this 117 goal, the attacker forwards PA messages from CleanEndpoint through 118 BadServer to DirtyEndpoint, which sends them on to GoodServer. 119 GoodServer is tricked into thinking that the PA messages came from 120 DirtyEndpoint and therefore considers DirtyEndpoint to be clean. 122 +-------------+ ========== +----------+ 123 |DirtyEndpoint|-----PA-----|GoodServer| 124 +-------------+ ========== +----------+ 125 | 126 PA 127 | 128 +-------------+ ========== +---------+ 129 |CleanEndpoint|-----PA-----|BadServer| 130 +-------------+ ========== +---------+ 132 Figure 2: NEA Asokan Attack 134 Countermeasures against a NEA Asokan Attack are described in section 135 4. 137 3. Lying Endpoints 139 Some may argue that there are other attacks against NEA systems that 140 are simpler than the Asokan attack, such as lying endpoint attacks. 141 That is true. It's easy for an endpoint to simply lie about its 142 posture. But there are defenses against lying endpoint attacks, such 143 as using an external measurement agent (EMA). 145 An EMA is hardware, software, or firmware designed to accurately 146 report on endpoint configuration but to be especially secure and 147 hard to compromise. The EMA observes and reports on critical aspects 148 of endpoint posture such as which security-relevant firmware and 149 software has been loaded. 151 When an EMA is used for NEA, the PA messages that reliably and 152 securely establish endpoint posture are exchanged between the EMA 153 itself and a Posture Validator on the NEA Server. The Posture 154 Collector on the endpoint and any other intermediaries between the 155 EMA and the Posture Validator on the NEA Server are not trusted. 156 They just pass messages along as untrusted intermediaries. 158 To ensure that the EMA's messages are accurately conveyed to the 159 Posture Validator even if the Posture Collector or other 160 intermediaries have been compromised, these PA messages must provide 161 integrity protection, replay protection, and source authentication 162 between the EMA and the Posture Validator. Confidentiality 163 protection is not needed, at least with respect to the software on 164 the endpoint. But integrity protection should include protection 165 against message deletion and session truncation. Organizations that 166 have developed EMAs have typically developed remote attestation 167 protocols that provide these properties (e.g. TCG's PTS Protocol 168 Binding to IF-M [7]). While the development of lying endpoint 169 detection technologies is out of scope for NEA, these technologies 170 must be supported by the NEA protocols. Therefore, the NEA protocols 171 must support countermeasures against the NEA Asokan Attack. 173 4. Countermeasures Against The NEA Asokan Attack 175 4.1. Identity Binding 177 One way to mitigate the Asokan attack is to bind the identities used 178 in tunnel establishment into a cryptographic exchange at the PA 179 layer. While this can go a long way to preventing the attack it 180 does not bind the exchange to a specific TLS exchange, which is 181 desirable. In addition, there is no standard way to extract an 182 identity from a TLS session, which could make implementation 183 difficult. 185 4.2. Cryptographic Binding 187 One way to thwart the NEA Asokan Attack is for the PA exchange to be 188 cryptographically bound to the PT exchange and to any keying 189 material or privileges granted as a result of these two exchanges. 190 This allows the NEA Server to ensure that the PA messages pertain to 191 the same endpoint as the party terminating the PT exchange and that 192 no other party gains any access or advantage from this exchange. 194 4.2.1. Binding Options 196 This section discusses binding protocol solution options and 197 provides analysis. Since PT-TLS and PT-EAP involve TLS, this 198 document focuses on TLS based solutions that can work with either 199 transport. 201 4.2.1.1. Information from the TLS Tunnel 203 The TLS handshake establishes cryptographic state between the TLS 204 client and TLS server. There are several mechanisms that can be 205 used to export information derived from this state. The client and 206 server independently include this information in calculations to 207 bind the instance of the tunnel into the PA protocol. 209 Keying Material Export - RFC 5705 [8] defines Keying Material 210 Exporters for TLS that allow additional secret key material to be 211 extracted from the TLS master secret. 213 tls-unique Channel Binding Data - RFC 5929 [9] defines several 214 quantities that can be extracted from the TLS session to bind the 215 TLS session to other protocols. The tls-unique binding consists of 216 data extracted from the TLS handshake finished message. 218 4.2.1.2. TLS Cipher Suites 220 In order to eliminate the possibility of a man-in-the-middle and 221 thwart the Asokan attack it is important that neither TLS endpoint 222 be in sole control of the TLS pre-master secret. Cipher suites 223 based on key transport such as RSA cipher suites do not meet this 224 requirement, instead Diffie-Hellman Cipher Suites, such as RSA-DHE, 225 are required when this mechanism is employed. 227 4.2.1.3. Using Additional Key Material from TLS 229 In some cases key material is extracted from the TLS tunnel and used 230 to derive ciphering keys used in another protocol. For example, 231 EAP-TLS [10] uses key material extracted from TLS in lower layer 232 ciphering. In this case the extracted keys must not be under the 233 control of a single party so the considerations in the previous 234 section are important. 236 4.2.1.4. EMA assumptions 238 The EMA needs to obtain the binding data from the TLS exchange and 239 prove knowledge of the binding data in an exchange that has 240 integrity protection, source authentication and replay protection. 242 5. Conclusions 244 The recommendations for addressing the NEA Asokan Attack are as 245 follows: 247 1. Protocols should make use of cryptographic binding, in addition 248 binding identities of the tunnel endpoints in the EMA may be 249 useful. 250 2. In particular, L2 and L3 TLS-based PT transports (e.g. PT-TLS and 251 PT-EAP) should use the same cryptographic binding mechanism 252 3. The preferred approach is to use the tls-unique channel binding 253 data from RFC 5929 [9]. The tls-unique value will be made 254 available to the EMA that will use it. This approach can utilize 255 any TLS cipher suite based on a strong cipher algorithm. 257 6. IANA Considerations 259 This document has no actions for IANA. 261 7. Security Considerations 263 This document is primarily concerned with analyzing and proposing 264 countermeasures for the NEA Asokan Attack. That does not mean that 265 it covers all the possible attacks against the NEA protocols or 266 against the NEA Reference Model. For a broader security analysis, 267 see the Security Considerations section of the NEA Overview [2], PA- 268 TNC [3], PB-TNC [4], PT-TLS [5], and PT-EAP [6]. 270 8. References 272 8.1. Informative References 274 [1] N. Asokan, Valtteri Niemi, Kaisa Nyberg, "Man in the Middle 275 Attacks in Tunneled Authentication Protocols", Nokia Research 276 Center, Finland, Nov. 11, 2002, 277 http://eprint.iacr.org/2002/163.pdf 279 [2] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 280 Tardo, "Network Endpoint Assessment (NEA): Overview and 281 Requirements", RFC 5209, June 2008. 283 [3] Sangster, P., and K. Narayan, "PA-TNC: A Posture Attribute 284 (PA) Protocol Compatible with Trusted Network Connect (TNC)", 285 RFC 5792, March 2010. 287 [4] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: A 288 Posture Broker (PB) Protocol Compatible with Trusted Network 289 Connect (TNC)", RFC 5793, March 2010. 291 [5] Sangster, P., N. Cam-Winget, and J. Salowey, "PT-TLS: A TCP- 292 based Posture Transport (PT) Protocol", draft-ietf-nea-pt-tls- 293 07.txt (work in progress), August 2012. 295 [6] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport 296 (PT) Protocol For EAP Tunnel Methods", draft-ietf-nea-pt-eap- 297 03.txt (work in progress), July 2012. 299 [7] Trusted Computing Group, "TCG Attestation PTS Protocol: 300 Binding to TNC IF-M", Version 1.0, Revision 27, August 2011. 302 [8] Rescorla, E., "Keying Material Exporters for Transport Layer 303 Security (TLS)", RFC 5705, March 2010. 305 [9] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for 306 TLS", RFC 5929, July 2010. 308 [10] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 309 Authentication Protocol", RFC 5216, March 2008. 311 9. Acknowledgments 313 The members of the NEA Asokan Design Team were critical to the 314 development of this document: Nancy Cam-Winget, Steve Hanna, Joe 315 Salowey, and Paul Sangster. 317 The authors would also like to recognize N. Asokan, Valtteri Niemi, 318 and Kaisa Nyberg who published the original paper on this type of 319 attack and Pasi Eronen who extended this attack to NEA protocols. 321 This document was prepared using 2-Word-v2.0.template.dot. 323 Authors' Addresses 325 Joseph Salowey 326 Cisco Systems, Inc. 327 2901 3rd. Ave 328 Seattle, WA 98121 329 USA 330 Email: jsalowey@cisco.com 332 Steve Hanna 333 Juniper Networks, Inc. 334 79 Parsons Street 335 Brighton, MA 02135 336 USA 337 Email: shanna@juniper.net