idnits 2.17.1 draft-ietf-nea-pt-eap-09.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 (March 29, 2013) is 4040 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5792' is defined on line 841, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-emu-eap-tunnel-method-06 ** Downref: Normative reference to an Informational RFC: RFC 5209 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEA N. Cam-Winget 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track P. Sangster 5 Expires: September 30, 2013 Symantec Corporation 6 March 29, 2013 8 PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods 9 draft-ietf-nea-pt-eap-09 11 Abstract 13 This document specifies PT-EAP, an Extensible Authentication Protocol 14 (EAP) based Posture Transport (PT) protocol designed to be used only 15 inside a TLS protected EAP tunnel method. The document also 16 describes the intended applicability of PT-EAP. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 30, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 3 54 1.2. Message Diagram Conventions . . . . . . . . . . . . . . . 3 55 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.4. Conventions used in this document . . . . . . . . . . . . 4 57 1.5. Compatibility with other Specifications . . . . . . . . . 4 58 2. Use of PT-EAP . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Definition of PT-EAP . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 5 62 3.3. PT-EAP Message Format . . . . . . . . . . . . . . . . . . 6 63 3.4. Preventing MITM Attacks with Channel Bindings . . . . . . 8 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 4.1. Trust Relationships . . . . . . . . . . . . . . . . . . . 9 66 4.1.1. Posture Transport Client . . . . . . . . . . . . . . 9 67 4.1.2. Posture Transport Server . . . . . . . . . . . . . . 10 68 4.2. Threats and Countermeasures . . . . . . . . . . . . . . . 10 69 4.2.1. Message Confidentiality . . . . . . . . . . . . . . . 11 70 4.2.2. Message Fabrication . . . . . . . . . . . . . . . . . 12 71 4.2.3. Message Modification . . . . . . . . . . . . . . . . 12 72 4.2.4. Denial of Service . . . . . . . . . . . . . . . . . . 12 73 4.2.5. NEA Asokan Attacks . . . . . . . . . . . . . . . . . 13 74 4.3. Candidate EAP Tunnel Method Protections . . . . . . . . . 13 75 4.4. Security Claims for PT-EAP as per RFC3748 . . . . . . . . 14 76 5. Requirements for EAP Tunnel Methods . . . . . . . . . . . . . 15 77 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 7.1. Registry for PT-EAP Versions . . . . . . . . . . . . . . 17 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 83 9.2. Informative References . . . . . . . . . . . . . . . . . 19 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 86 1. Introduction 88 This document specifies PT-EAP, a Posture Transport (PT) protocol 89 protected by a TLS protected EAP tunnel method. The PT protocol in 90 the NEA architecture is responsible for transporting Posture Broker 91 (PB-TNC [RFC5793]) batches (often containing Posture Attributes [PA- 92 TNC [RFC5792]] attributes) across the network between the NEA Client 93 and NEA Server. The PT-EAP protocol must be protected by an outer 94 TLS-based EAP tunnel method to ensure the exchanged messages are 95 protected from a variety of threats from hostile intermediaries. 97 NEA protocols are intended to be used both for pre-admission 98 assessment of endpoints joining the network and to assess endpoints 99 already present on the network. In order to support both usage 100 models, two types of PT protocols are needed. One type of PT, PT-TLS 101 [I-D.ietf-nea-pt-tls], operates after the endpoint has an assigned IP 102 address, layering on top of the IP protocol to carry a NEA exchange. 103 The other type of PT operates before the endpoint gains any access to 104 the IP network. This specification defines PT-EAP, the PT protocol 105 used to assess endpoints before they gain access to the network. 107 PT-EAP is an inner EAP [RFC3748] method designed to be used inside a 108 protected tunnel such as TEAP [I-D.ietf-emu-eap-tunnel-method], EAP- 109 FAST [RFC4851] or EAP-TTLS [RFC5281]. That is, an outer EAP method 110 is typically a TLS-based EAP method that first establishes a 111 protected tunnel by which other conversations, such as other EAP 112 methods (e.g. "inner" EAP methods) can ensue under the tunnel 113 protection. 115 1.1. Prerequisites 117 This document does not define an architecture or reference model. 118 Instead, it defines a protocol that works within the reference model 119 described in the NEA Requirements specification [RFC5209]. The 120 reader is assumed to be thoroughly familiar with that document. 122 1.2. Message Diagram Conventions 124 This specification defines the syntax of PT-EAP messages using 125 diagrams. Each diagram depicts the format and size of each field in 126 bits. Implementations MUST send the bits in each diagram as they are 127 shown, traversing the diagram from top to bottom and then from left 128 to right within each line (which represents a 32-bit quantity). 129 Multi-byte fields representing numeric values MUST be sent in network 130 (big endian) byte order. 132 Descriptions of bit field (e.g. flag) values are described referring 133 to the position of the bit within the field. These bit positions are 134 numbered from the most significant bit through the least significant 135 bit so a one octet field with only bit 0 set has the value 0x80. 137 1.3. Terminology 139 This document reuses many terms defined in the NEA Requirements 140 document [RFC5209], such as Posture Transport Client and Posture 141 Transport Server. The reader is assumed to have read that document 142 and understood it. 144 When defining the PT-EAP method, this specification does not use the 145 terms "EAP peer" and "EAP authenticator". Instead, it uses the terms 146 "NEA Client" and "NEA Server" since those are considered to be more 147 familiar to NEA WG participants. However, these terms are equivalent 148 for the purposes of these specifications. The part of the NEA Client 149 that terminates PT-EAP (generally in the Posture Transport Client) is 150 the EAP peer for PT-EAP. The part of the NEA Server that terminates 151 PT-EAP (generally in the Posture Transport Server) is the EAP 152 authenticator for PT-EAP. 154 1.4. Conventions used in this document 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC 2119 [RFC2119]. 160 1.5. Compatibility with other Specifications 162 One of the goals of the NEA effort is to deliver a single set of 163 endpoint assessment standards, agreed upon by all parties. For this 164 reason, the authors understand that the Trusted Computing Group (TCG) 165 will be replacing its existing posture transport protocols with new 166 versions that are equivalent to and interoperable with the NEA 167 specifications. 169 2. Use of PT-EAP 171 PT-EAP is designed to encapsulate PB-TNC batches in a simple EAP 172 method that can be carried within EAP tunnel methods. The EAP tunnel 173 methods provide confidentiality and message integrity, so PT-EAP does 174 not have to do so. Therefore, PT-EAP MUST be used inside a TLS-based 175 EAP tunnel method that provides strong cryptographic authentication 176 (possibly server only), message integrity and confidentiality 177 services. 179 3. Definition of PT-EAP 181 The PT-EAP protocol operates between a Posture Transport Client and a 182 Posture Transport Server, allowing them to send PB-TNC batches to 183 each other over an EAP tunnel method. When PT-EAP is used, the 184 Posture Transport Client in the NEA reference model acts as an EAP 185 peer (terminating the PT-EAP method on the endpoint) and the Posture 186 Transport Server acts as an EAP authenticator (terminating the PT-EAP 187 method on the NEA Server). 189 This section describes and defines the PT-EAP method. First, it 190 provides a protocol overview. Second, it describes specific features 191 like version negotiation. Third, it gives a detailed packet 192 description. Finally, it describes how the tls-unique channel 193 binding [RFC5929] may be used to bind PA-TNC exchanges to the EAP 194 tunnel method, defeating MITM attacks such as the Asokan attack 195 [Asokan]. 197 3.1. Protocol Overview 199 PT-EAP has two phases that follow each other in strict sequence: 200 negotiation and data transport. 202 The PT-EAP method begins with the negotiation phase. The NEA Server 203 starts this phase by sending a PT-EAP Start message: an EAP Request 204 message of type PT-EAP with the S (Start) flag set. The NEA Server 205 also sets the Version field as described in Section 3.2. This is the 206 only message in the negotiation phase. 208 The data transport phase is the only phase of PT-EAP where PB-TNC 209 batches are allowed to be exchanged. This phase always starts with 210 the NEA Client sending a PB-TNC batch to the NEA Server. The NEA 211 Client and NEA Server then take turns sending a PB-TNC batch. The 212 data transport phase always ends with an EAP Response message from 213 the NEA Client to the NEA Server. The Data field of this message may 214 have zero length if the NEA Server has just sent the last PB-TNC 215 batch in the PB-TNC exchange. 217 Note that the success of PT-EAP does not mean the overall 218 authentication (using the outer EAP tunnel method) will succeed. 219 Neither does the failure of PT-EAP mean that the overall 220 authentication will fail. Success of the overall authentication 221 depends on the policy configured by the administrator. 223 At the end of the PT-EAP method, the NEA Server will indicate success 224 or failure to the EAP tunnel method. Some EAP tunnel methods may 225 provide explicit confirmation of inner method success; others may 226 not. This is out of scope for the PT-EAP method specification. 227 Successful completion of PT-EAP does not imply successful completion 228 of the overall authentication nor does PT-EAP failure imply overall 229 failure. This depends on the administrative policy in place. 231 The NEA Server and NEA Client may engage in an abnormal termination 232 of the PT-EAP exchange at any time by simply stopping the exchange. 233 This may also require terminating the EAP tunnel method, depending on 234 the capabilities of the EAP tunnel method. 236 3.2. Version Negotiation 238 PT-EAP version negotiation takes place in the first PT-EAP message 239 sent by the NEA Server (the Start message) and the first PT-EAP 240 message sent by the NEA Client (the response to the Start message). 241 The NEA Server MUST set the Version field in the Start message to the 242 maximum PT-EAP version that the NEA Server supports and is willing to 243 accept. 245 The NEA Client chooses the PT-EAP version to be used for the exchange 246 and places this value in the Version field in its response to the 247 Start message. The NEA Client SHOULD choose the value sent by the 248 NEA Server if the NEA Client supports it. However, the NEA Client 249 MAY set the Version field to a value less than the value sent by the 250 NEA Server (for example, if the NEA Client only supports lesser PT- 251 EAP versions). If the NEA Client only supports PT-EAP versions 252 greater than the value sent by the NEA Server, the NEA Client MUST 253 abnormally terminate the EAP negotiation. 255 If the version sent by the NEA Client is not acceptable to the NEA 256 Server, the NEA Server MUST terminate the PT-EAP session immediately. 257 Otherwise, the version sent by the NEA Client is the version of PT- 258 EAP that MUST be used. Both the NEA Client and the NEA Server MUST 259 set the Version field to the chosen version number in all subsequent 260 PT-EAP messages in this exchange. 262 This specification defines version 1 of PT-EAP. Version 0 is 263 reserved and MUST never be sent. New versions of PT-EAP (values 2-7) 264 may be defined by Standards Action, as defined in [RFC5226]. 266 3.3. PT-EAP Message Format 268 This section provides a detailed description of the fields in a PT- 269 EAP message. For a description of the diagram conventions used here, 270 see Section 1.2. Since PT-EAP is an EAP method, the first four 271 fields (e.g. Code, Identifier, Length and Type as shown in Figure 1) 272 in each message are mandated by and defined in EAP. The other 273 fields, e.g. Flags, Version and Data are specific to PT-EAP. 275 0 1 2 3 276 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Code | Identifier | Length | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Type | Flags | Ver | Data ... | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 1: PT-EAP Message Format 285 Code 286 The Code field is one octet and identifies the type of the EAP 287 message. The only values used for PT-EAP are: 289 1 Request 291 2 Response 293 Identifier 295 The Identifier field is one octet and aids in matching 296 Responses with Requests. 298 Length 300 The Length field is two octets and indicates the length in 301 octets of this PT-EAP message, starting from the Code field. 303 Type 305 TBD EAP Method Type [RFC3748] assignment for PT-EAP. 307 Flags 309 +-+-+-+-+-+ 310 |S R R R R| 311 +-+-+-+-+-+ 313 S: Start 315 Indicates the beginning of a PT-EAP exchange. This flag MUST be 316 set only for the first message from the NEA Server. If the S flag 317 is set, the EAP message MUST NOT contain Data. 319 R: Reserved 321 This flag MUST be set to 0 and ignored upon receipt. 323 Version 324 This field is used for version negotiation, as described in 325 Section 3.2. 327 Data 329 Variable length data. This field is processed by the PB layer 330 and MUST include PB-TNC messages. For more information see PB- 331 TNC [RFC5793]. 333 The length of the Data field in a particular PT-EAP message may be 334 determined by subtracting the length of the PT-EAP header fields 335 from the value of the two octet Length field. 337 3.4. Preventing MITM Attacks with Channel Bindings 339 As described in the NEA Asokan Attack Analysis [I-D.ietf-nea-asokan], 340 a sophisticated MITM attack can be mounted against NEA systems. The 341 attacker forwards PA-TNC messages from a healthy machine through an 342 unhealthy one so that the unhealthy machine can gain network access. 343 Because there are easier attacks on NEA systems, like having the 344 unhealthy machine lie about its configuration, this attack is 345 generally only mounted against machines with an External Measurement 346 Agent (EMA). The EMA is a separate entity, difficult to compromise, 347 which measures and attests to the configuration of the endpoint. 349 To protect against NEA Asokan attacks, it is necessary for the 350 Posture Broker on an EMA-equipped endpoint to pass the tls-unique 351 channel binding [RFC5929] from PT-EAP's tunnel method to the EMA. 352 This value can then be included in the EMA's attestation so that the 353 Posture Validator responsible may then confirm that the value matches 354 the tls-unique channel binding for its end of the tunnel. If the 355 tls-unique values of the NEA Client and NEA Server match and this is 356 confirmed by the EMA, then the posture sent by a trustworthy EMA (and 357 thus the NEA Client) is from the same endpoint as the client side of 358 the TLS connection (since the endpoint knows the tls-unique value) so 359 no man-in-the-middle is forwarding posture. If they differ, an 360 attack has been detected and the Posture Validator SHOULD fail its 361 verification. 363 Note that tls-unique, as opposed to invoking a mutual cryptographic 364 binding, is used as there is no keying material being generated by 365 PT-EAP (the method is defined to facilitate the transport of posture 366 data and is not an authentication method). However, the NEA Client 367 may host an EMA which can be used as the means to cryptographically 368 bind the tls-unique content that may be validated by the Posture 369 Validator interfacing with the EAP Server. The binding of the tls- 370 unique to the client authentication prevents the client's message 371 from being used in another context. This prevents a poorly 372 configured client from unintentionally compromising the NEA system. 373 Strong mutual authentication of the NEA server and client is still 374 REQUIRED to prevent the disclosure of possibly sensitive NEA client 375 information to an attacker. 377 4. Security Considerations 379 This section discusses the major threats and countermeasures provided 380 by PT-EAP. As discussed throughout the document, the PT-EAP method 381 is designed to run inside an EAP tunnel method which is capable of 382 protecting the PT-EAP protocol from many threats. Since the EAP 383 tunnel method will be specified separately, this section describes 384 the considerations on the EAP tunnel method but does not evaluate its 385 ability to meet those requirements. The security considerations and 386 requirements for NEA can be found in [RFC5209]. 388 4.1. Trust Relationships 390 In order to understand where security countermeasures are necessary, 391 this section starts with a discussion of where the NEA architecture 392 envisions some trust relationships between the processing elements of 393 the PT-EAP protocol. The following sub-sections discuss the trust 394 properties associated with each portion of the NEA reference model 395 directly involved with the processing of the PT-EAP protocol flowing 396 inside an EAP tunnel. 398 4.1.1. Posture Transport Client 400 The Posture Transport Client is trusted by the Posture Broker Client 401 to: 403 o Not disclose to unauthorized parties, fabricate or alter the 404 contents of the PB-TNC batches received from the network 406 o Not observe, fabricate or alter the PB-TNC batches passed down 407 from the Posture Broker Client for transmission on the network 409 o Transmit on the network any PB-TNC batches passed down from the 410 Posture Broker Client 412 o Provide configured security protections (e.g. authentication, 413 integrity and confidentiality) for the Posture Broker Client's PB- 414 TNC batches sent on the network 416 o Expose the authenticated identity of the Posture Transport Server 417 to the Posture Broker Client. 419 o Verify the security protections placed upon messages received from 420 the network to ensure the messages are authentic and protected 421 from attacks on the network 423 o Deliver to the Posture Broker Client the PB-TNC batches received 424 from the network so long as they are properly security protected 426 o Provide a secure, reliable, in order delivery, full duplex 427 transport for the Posture Broker Client's messages 429 Since the Posture Transport Server can not validate the 430 trustworthiness of the Posture Transport Client; the Posture 431 Transport Server should protect itself appropriately. 433 4.1.2. Posture Transport Server 435 The Posture Transport Server is trusted by the Posture Broker Server 436 to: 438 o Not observe, fabricate or alter the contents of the PB-TNC batches 439 received from the network 441 o Not observe, fabricate or alter the PB-TNC batches passed down 442 from the Posture Broker Server for transmission on the network 444 o Transmit on the network any PB-TNC batches passed down from the 445 Posture Broker Server 447 o Ensure PB-TNC batches received from the network is properly 448 protected from a security perspective 450 o Provide configured security protections (e.g. authentication, 451 integrity and confidentiality) for the Posture Broker Server's 452 messages sent on the network 454 o Expose the authenticated identity of the Posture Transport Client 455 to the Posture Broker Server 457 o Verify the security protections placed upon messages received from 458 the network to ensure the messages are authentic and protected 459 from attacks on the network 461 Since the Posture Transport Client can not validate the 462 trustworthiness of the Posture Transport Server; the Posture 463 Transport Client should protect itself appropriately 465 4.2. Threats and Countermeasures 466 Beyond the trusted relationships assumed in Section 4.1, the PT-EAP 467 EAP method faces a number of potential security attacks that could 468 require security countermeasures. 470 Generally, the PT protocol is responsible for providing strong 471 security protections for all of the NEA protocols so any threats to 472 PT's ability to protect NEA protocol messages could be very damaging 473 to deployments. For the PT-EAP method, most of the cryptographic 474 security is provided by the outer EAP tunnel method and PT-EAP is 475 encapsulated within the protected tunnel. Therefore, this section 476 highlights the cryptographic requirements that need to be met by the 477 EAP tunnel method carrying PT-EAP in order to meet the NEA PT 478 requirements. 480 Once the message is delivered to the Posture Broker Client or Posture 481 Broker Server, the posture brokers are trusted to properly safely 482 process the messages. 484 4.2.1. Message Confidentiality 486 When PT-EAP messages are sent over unprotected network links or 487 spanning local software stacks that are not trusted, the contents of 488 the messages may be subject to information theft by an intermediary 489 party. This theft could result in information being recorded for 490 future use or analysis by an adversary. Messages observed by 491 eavesdroppers could contain information that exposes potential 492 weaknesses in the security of the endpoint, or system fingerprinting 493 information easing the ability of the attacker to employ attacks more 494 likely to be successful against the endpoint. The eavesdropper might 495 also learn information about the endpoint or network policies that 496 either singularly or collectively is considered sensitive 497 information. For example, if PT-EAP is carried by an EAP tunnel 498 method that does not provide confidentiality protection, an adversary 499 could observe the PA-TNC attributes included in the PB-TNC batch and 500 determine that the endpoint is lacking patches, or particular sub- 501 networks have more lenient policies. 503 In order to protect against NEA assessment message theft, the EAP 504 tunnel method carrying PT-EAP must provide strong cryptographic 505 authentication, integrity and confidentiality protection. The use of 506 bi-directional authentication in the EAP tunnel method carrying PT- 507 EAP ensures that only properly authenticated and authorized parties 508 may be involved in an assessment message exchange. When PT-EAP is 509 carried within a cryptographically protected EAP tunnel method like 510 EAP-FAST or EAP-TTLS, all of the PB-TNC and PA-TNC protocol messages 511 contents are hidden from potential theft by intermediaries lurking on 512 the network. 514 4.2.2. Message Fabrication 516 Attackers on the network or present within the NEA system could 517 introduce fabricated PT-EAP messages intending to trick or create a 518 denial of service against aspects of an assessment. For example, an 519 adversary could attempt to insert a PT-EAP message to tell a NEA 520 Server that the endpoint is totally infected. This could cause the 521 device to be blocked from accessing a critical resource, which would 522 be a denial of service. 524 The EAP tunnel method carrying a PT-EAP method needs to provide 525 strong security protections for the complete message exchange over 526 the network. These security protections prevent an intermediary from 527 being able to insert fake messages into the assessment. See 528 Section 5 for more details on the EAP tunnel requirements. 530 4.2.3. Message Modification 532 This attack could allow an active attacker capable of intercepting a 533 message to modify a PT-EAP message or transported PA-TNC attribute to 534 a desired value to ease the compromise of an endpoint. Without the 535 ability for message recipients to detect whether a received message 536 contains the same content as what was originally sent, active 537 attackers can stealthily modify the attribute exchange. 539 PT-EAP leverages the EAP tunnel method (e.g. TEAP, EAP-FAST or EAP- 540 TTLS) to provide strong authentication and integrity protections as a 541 countermeasure to this threat. The bi-directional authentication 542 prevents the attacker from acting as an active man-in-the-middle to 543 the protocol that could be used to modify the message exchange. The 544 strong integrity protections offered by the TLS-based EAP tunnel 545 method allows the PT-EAP message recipients to detect message 546 alterations by other types of network based adversaries. Because PT- 547 EAP does not itself provide explicit integrity protection for the PT- 548 EAP payload, an EAP tunnel method that offers strong integrity 549 protection is needed to mitigate this threat. 551 4.2.4. Denial of Service 553 A variety of types of denial of service attacks are possible against 554 PT-EAP if the message exchange is left unprotected while traveling 555 over the network. The Posture Transport Client and Posture Transport 556 Server are trusted not to participate in the denial of service of the 557 assessment session, leaving the threats to come from the network. 559 The PT-EAP method primarily relies on the outer EAP tunnel method to 560 provide strong authentication (at least of one party) and deployers 561 are expected to leverage other EAP methods to authenticate the other 562 party (typically the client) within the protected tunnel. The use of 563 a protected bi-directional authentication will prevent unauthorized 564 parties from participating in a PT-EAP exchange. 566 After the cryptographic authentication by the EAP tunnel method, the 567 session can be protected cryptographically to provide confidentiality 568 and source authenticity. Such protection prevents undetected 569 modification that could create a denial of service situation. 570 However it is possible for an adversary to alter the message flows 571 causing each message to be rejected by the recipient because it fails 572 the integrity checking. 574 4.2.5. NEA Asokan Attacks 576 As described in Section 3.4 and in the NEA Asokan Attack Analysis 577 [I-D.ietf-nea-asokan], a sophisticated MITM attack can be mounted 578 against NEA systems. The attacker forwards PA-TNC messages from a 579 healthy machine through an unhealthy one so that the unhealthy 580 machine can gain network access. Section 3.4 and the NEA Asokan 581 Attack Analysis provide a detailed description of this attack and of 582 the countermeasures that can be employed against it. 584 Because lying endpoint attacks are much easier than Asokan attacks 585 and an effective countermeasure against lying endpoint attacks is the 586 use of an External Measurement Agent (EMA), countermeasures against 587 an Asokan attack are not necessary unless an EMA is in use. However, 588 PT-EAP implementers may not know whether an EMA will be used with 589 their implementation. Therefore, PT-EAP implementers SHOULD support 590 these countermeasures by providing the value of the tls-unique 591 channel binding to higher layers in the NEA reference model: Posture 592 Broker Clients, Posture Broker Servers, Posture Collectors, and 593 Posture Validators. If the tls-unique channel binding is 594 implemented,it must be verified before any other attestations are 595 evaluated. 597 4.3. Candidate EAP Tunnel Method Protections 599 This section discusses how PT-EAP is used within various EAP tunnel 600 methods to meet the PT requirements from Section 5. 602 TEAP [I-D.ietf-emu-eap-tunnel-method], EAP-FAST [RFC4851] and EAP- 603 TTLS [RFC5281] make use of TLS [RFC5246] to protect the transport of 604 information between the NEA Client and NEA Server. Each of these EAP 605 tunnel methods has two phases. In the first phase, a TLS tunnel is 606 established between NEA Client and NEA Server. In the second phase, 607 the tunnel is used to pass other information. PT-EAP requires that 608 establishing this tunnel include at least an authentication of the 609 NEA Server by the NEA Client. 611 The phase two dialog may include authentication of the user by doing 612 other EAP methods or in the case of EAP-TTLS by using EAP or non-EAP 613 authentication dialogs. PT-EAP is also carried by the phase two 614 tunnel allowing the NEA assessment to be within an encrypted and 615 integrity protected transport. 617 With all these methods (e.g. TEAP [I-D.ietf-emu-eap-tunnel-method], 618 EAP-FAST [RFC4851] and EAP-TTLS [RFC5281]), a cryptographic key is 619 derived from the authentication that may be used to secure later 620 transmissions. Each of these methods employs at least a NEA Server 621 authentication using an X.509 certificate. Within each EAP tunnel 622 method will exist a set of inner EAP methods. These inner methods 623 may perform additional security handshakes including more granular 624 authentications or exchanges of integrity information (such as PT- 625 EAP.) At some point after the conclusion of each inner EAP method, 626 some of the methods will export the established secret keys to the 627 outer tunnel method. It's expected that the outer method will 628 cryptographically mix these keys into any keys it is currently using 629 to protect the session and perform a final operation to determine 630 whether both parties have arrived at the same mixed key. This 631 cryptographic binding of the inner method results to the outer 632 method's keys is essential for detection of conventional (non-NEA) 633 Asokan attacks. 635 TEAP [I-D.ietf-emu-eap-tunnel-method] is the mandatory to implement 636 EAP tunnel method. 638 4.4. Security Claims for PT-EAP as per RFC3748 640 This section summarizes the security claims for this specification, 641 as required by RFC3748 Section 7.2: 643 Auth. mechanism: None 644 Ciphersuite negotiation: No 645 Mutual authentication: No 646 Integrity protection: No 647 Replay protection: No 648 Confidentiality: No 649 Key derivation: No 650 Key strength: N/A 651 Dictionary attack resistant: N/A 652 Fast reconnect: No 653 Crypt. binding: N/A 654 Session independence: N/A 655 Fragmentation: No 656 Channel binding: No 658 5. Requirements for EAP Tunnel Methods 660 Because the PT-EAP inner method described in this specification 661 relies on the outer EAP tunnel method for a majority of its security 662 protections, this section reiterates the PT requirements that MUST be 663 met by the IETF standard EAP tunnel method for use with PT-EAP. 665 At the time of this writing, the IETF EAP Method Update (EMU) working 666 group is working on standardizing on TEAP 667 [I-D.ietf-emu-eap-tunnel-method] as a Standards Track EAP tunnel 668 method that will satisfy NEA's requirements and is the mandatory to 669 implement EAP tunnel method. 671 The security requirements described in this specification MUST be 672 implemented in any product claiming to be PT-EAP compliant. The 673 decision of whether a particular deployment chooses to use these 674 protections is a deployment issue. A customer may choose to avoid 675 potential deployment issues or performance penalties associated with 676 the use of cryptography when the required protection has been 677 achieved through other mechanisms (e.g. physical isolation). If 678 security mechanisms may be deactivated by policy, an implementation 679 SHOULD offer an interface to query how a message will be (or was) 680 protected by PT so higher layer NEA protocols can factor this into 681 their decisions. 683 RFC 5209 [RFC5209] includes the following requirement that is to be 684 applied during the selection of the EAP tunnel method(s) used in 685 conjunction with PT-EAP: 687 PT-2: The PT protocol MUST be capable of supporting mutual 688 authentication, integrity, confidentiality, and replay protection 689 of the PB messages between the Posture Transport Client and the 690 Posture Transport Server. 692 Note that mutual authentication could be achieved by a combination of 693 a strong authentication of one party (e.g. server authentication 694 while establishing the TLS-based tunnel) by the EAP tunnel method in 695 conjunction with a second authentication of the other party (e.g. 696 client authentication inside the protected tunnel) by another EAP 697 method running prior to PT-EAP. 699 Having the Posture Transport Client always authenticate the Posture 700 Transport Server provides assurance to the NEA Client that the NEA 701 Server is authentic (not a rogue or MiTM) prior to disclosing secret 702 or potentially privacy sensitive information about what is running or 703 configured on the endpoint. However the NEA Server's policy may 704 allow for the delay of the authentication of the NEA Client until a 705 suitable protected channel has been established allowing for non- 706 cryptographic NEA Client credentials (e.g. username/password) to be 707 used. Whether the communication channel is established with mutual 708 or server-side only authentication, the resulting channel needs to 709 provide strong integrity and confidentiality protection to its 710 contents. These protections are to be bound to at least the 711 authentication of the NEA Server by the NEA Client, so the session is 712 cryptographically bound to a particular authentication event. 714 The EAP tunnel method carrying PT-EAP MUST provide strong 715 cryptographic authentication, integrity and confidentiality 716 protection to protect against NEA assessment message theft as 717 described in Section 4.2.1. The cryptographically protected EAP 718 tunnel ensures that all of the PA-TNC and PB-TNC protocol messages 719 are hidden from intermediaries wanting to steal NEA data. 721 To support countermeasures against NEA Asokan attacks as described in 722 Section 3.4, the EAP Tunnel Method used with PT-EAP will need to 723 support generation of the tls-unique value to be used with the higher 724 layers of the NEA reference model. This should not be a high bar 725 since all EAP tunnel methods currently support this but not all 726 implementations of those methods may do so. 728 6. Privacy Considerations 730 The role of PT-EAP is to act as a secure transport for PB-TNC over a 731 network before the endpoint has been admitted to the network. As a 732 transport protocol, PT-EAP does not directly utilize or require 733 direct knowledge of any personally identifiable information (PII). 734 PT-EAP will typically be used in conjunction with other EAP methods 735 that provide for the user authentication (if bi-directional 736 authentication is used), so the user's credentials are not directly 737 seen by the PT-EAP inner method. 739 While PT-EAP does not provide cryptographic protection for the PB-TNC 740 batches, it is designed to operate within an EAP tunnel method that 741 provides strong authentication, integrity and confidentiality 742 services. Therefore, it is important for deployers to leverage these 743 protections in order to prevent disclosure of PII potentially 744 contained within PA-TNC or PB-TNC within the PT-EAP payload. 746 7. IANA Considerations 748 This section provides guidance to the Internet Assigned numbers 749 Authority (IANA) regarding registration of values related to the PT- 750 EAP protocol, in accordance with BCP 26 [RFC5226]. 752 The EAP Method type for PT-EAP needs to be assigned; e.g. the 753 assignment for TYPE in Section 3.3. 755 +---------+---------------------------+-----------------------------+ 756 | Value | Description | Reference | 757 +---------+---------------------------+-----------------------------+ 758 | TBD | EAP Method Type for PT- | RFC number assigned to this | 759 | | EAP | draft | 760 +---------+---------------------------+-----------------------------+ 762 [TO BE REMOVED PRIOR TO PUBLICATION: This registration should take 763 place at the following location: http://www.iana.org/assignments/eap- 764 numbers/eap-numbers.xml#eap-numbers-3 ] 766 This document also defines one new IANA top-level registry: PT-EAP 767 Versions. This section explains how this registry works. Because 768 only eight (8) values are available in this registry, a high bar is 769 set for new assignments. The only way to register new values in this 770 registry is through Standards Action (via an approved Standards Track 771 RFC). 773 7.1. Registry for PT-EAP Versions 775 The name for this registry is "PT-EAP Versions". Each entry in this 776 registry includes a decimal integer value between 1 and 7 identifying 777 the version, and a reference to the RFC where the version is defined. 779 The following entries for this registry are defined in this document. 780 Once this document becomes an RFC, they will become the initial 781 entries in the registry for PT-EAP Versions. Additional entries to 782 this registry are added by Standards Action, as defined in RFC 5226 783 [RFC5226]. 785 +-------+----------------------------+ 786 | Value | Defining Specification | 787 +-------+----------------------------+ 788 | 0 | Reserved | 789 | 1 | RFC # Assigned to this I-D | 790 +-------+----------------------------+ 792 8. Acknowledgements 794 Thanks to the Trusted Computing Group for contributing the initial 795 text upon which this document was based. 797 The authors of this draft would like to acknowledge the following 798 people who have contributed to or provided substantial input on the 799 preparation of this document or predecessors to it: Amit Agarwal, 800 Morteza Ansari, Diana Arroyo, Stuart Bailey, Boris Balacheff, Uri 801 Blumenthal, Gene Chang, Scott Cochrane, Pasi Eronen, Aman Garg, 802 Sandilya Garimella, David Grawrock, Stephen Hanna, Thomas Hardjono, 803 Chris Hessing, Ryan Hurst, Hidenobu Ito, John Jerrim, Meenakshi 804 Kaushik, Greg Kazmierczak, Scott Kelly, Bryan Kingsford, PJ Kirner, 805 Sung Lee, Lisa Lorenzin, Mahalingam Mani, Bipin Mistry, Seiji 806 Munetoh, Rod Murchison, Barbara Nelson, Kazuaki Nimura, Ron Pon, Ivan 807 Pulleyn, Alex Romanyuk, Ravi Sahita, Chris Salter, Mauricio Sanchez, 808 Joseph Salowey, Dean Sheffield, Curtis Simonson, Jeff Six, Ned Smith, 809 Michelle Sommerstad, Joseph Tardo, Lee Terrell, Susan Thomson, Chris 810 Trytten, and John Vollbrecht. 812 This document was prepared using template-bare-05.xml. 814 9. References 816 9.1. Normative References 818 [I-D.ietf-emu-eap-tunnel-method] 819 Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 820 "Tunnel EAP Method (TEAP) Version 1", draft-ietf-emu-eap- 821 tunnel-method-06 (work in progress), March 2013. 823 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 824 Requirement Levels", BCP 14, RFC 2119, March 1997. 826 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 827 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 828 3748, June 2004. 830 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 831 Tardo, "Network Endpoint Assessment (NEA): Overview and 832 Requirements", RFC 5209, June 2008. 834 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 835 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 836 May 2008. 838 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 839 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 841 [RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute 842 (PA) Protocol Compatible with Trusted Network Connect 843 (TNC)", RFC 5792, March 2010. 845 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 846 A Posture Broker (PB) Protocol Compatible with Trusted 847 Network Connect (TNC)", RFC 5793, March 2010. 849 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 850 for TLS", RFC 5929, July 2010. 852 9.2. Informative References 854 [Asokan] Asokan, N., Niemi, V., Nyberg, K., Nokia Research Center, 855 Finland, ""Man in the Middle Attacks in Tunneled 856 Authentication Protocols"", Nov 2002, 857 . 859 [I-D.ietf-nea-asokan] 860 Salowey, J. and S. Hanna, "NEA Asokan Attack Analysis", 861 draft-ietf-nea-asokan-02 (work in progress), October 2012. 863 [I-D.ietf-nea-pt-tls] 864 Sangster, P., Cam-Winget, N., and J. Salowey, "PT-TLS: A 865 TLS-based Posture Transport (PT) Protocol", draft-ietf- 866 nea-pt-tls-08 (work in progress), October 2012. 868 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 869 Flexible Authentication via Secure Tunneling Extensible 870 Authentication Protocol Method (EAP-FAST)", RFC 4851, May 871 2007. 873 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 874 Protocol Tunneled Transport Layer Security Authenticated 875 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 877 Authors' Addresses 879 Nancy Cam-Winget 880 Cisco Systems 881 80 West Tasman Drive 882 San Jose, CA 95134 883 US 885 Email: ncamwing@cisco.com 887 Paul Sangster 888 Symantec Corporation 889 6825 Citrine Drive 890 Carlsbad, CA 92009 891 USA 893 Email: paul_sangster@symantec.com