idnits 2.17.1 draft-hanna-nea-pt-eap-01.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 3, 2011) is 4802 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) ** Obsolete normative reference: RFC 5246 (ref. '2') (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 5226 (ref. '6') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5996 (ref. '13') (Obsoleted by RFC 7296) == Outdated reference: A later version (-01) exists of draft-salowey-nea-asokan-00 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Hanna 2 Internet Draft Juniper Networks 3 Intended status: Proposed Standard P. Sangster 4 Expires: May 2010 Symantec Corporation 6 March 3, 2011 8 PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods 9 draft-hanna-nea-pt-eap-01.txt 11 Abstract 13 This document specifies PT-EAP, a Posture Broker Protocol compatible 14 with the Trusted Computing Group's IF-T Protocol Bindings for 15 Tunneled EAP Methods (also known as EAP-TNC). The document then 16 evaluates PT-EAP against the requirements defined in the NEA 17 Requirements and PB-TNC specifications. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on September 3, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction...................................................3 60 1.1. Prerequisites.............................................4 61 1.2. Message Diagram Conventions...............................4 62 1.3. Terminology...............................................5 63 1.4. Conventions used in this document.........................5 64 2. Use of EAP-TNC.................................................5 65 3. Definition of EAP-TNC..........................................5 66 3.1. Protocol Overview.........................................6 67 3.2. Version Negotiation.......................................6 68 3.3. Fragmentation.............................................7 69 3.4. EAP-TNC Message Format....................................8 70 3.5. Preventing MITM Attacks with Channel Bindings............10 71 4. Security Considerations.......................................11 72 4.1. Trust Relationships......................................11 73 4.1.1. Posture Transport Client............................11 74 4.1.2. Posture Transport Server............................12 75 4.2. Security Threats and Countermeasures.....................13 76 4.2.1. Message Theft.......................................14 77 4.2.2. Message Fabrication.................................14 78 4.2.3. Message Modification................................15 79 4.2.4. Denial of Service...................................15 80 4.2.5. NEA Asokan Attacks..................................16 81 4.3. Requirements for EAP Tunnel Methods......................16 82 4.4. Candidate EAP Tunnel Method Protections..................17 83 4.5. Security Claims for EAP-TNC as per RFC3748...............18 84 5. Privacy Considerations........................................18 85 6. IANA Considerations...........................................19 86 6.1. Registry for EAP-TNC Versions............................19 87 7. References....................................................20 88 7.1. Normative References.....................................20 89 7.2. Informative References...................................20 90 8. Acknowledgments...............................................21 91 Appendix A. Evaluation Against NEA Requirements..................23 92 A.1. Evaluation Against Requirement C-1.......................23 93 A.2. Evaluation Against Requirements C-2......................23 94 A.3. Evaluation Against Requirements C-3......................23 95 A.4. Evaluation Against Requirements C-4......................24 96 A.5. Evaluation Against Requirements C-5......................24 97 A.6. Evaluation Against Requirements C-6......................24 98 A.7. Evaluation Against Requirements C-7......................24 99 A.8. Evaluation Against Requirements C-8......................25 100 A.9. Evaluation Against Requirements C-9......................25 101 A.10. Evaluation Against Requirements C-10....................25 102 A.11. Evaluation Against Requirements C-11....................26 103 A.12. Evaluation Against Requirements PT-1....................26 104 A.13. Evaluation Against Requirements PT-2....................26 105 A.14. Evaluation Against Requirements PT-3....................27 106 A.15. Evaluation Against Requirements PT-4....................27 107 A.16. Evaluation Against Requirements PT-5....................27 108 A.17. Evaluation Against Requirements PT-6 (from PB-TNC 109 specification)................................................28 110 A.18. Evaluation Against Requirements PT-7 (from PB-TNC 111 specification)................................................28 112 A.19. Evaluation Against Requirements PT-8 (from PB-TNC 113 specification)................................................28 114 A.20. Evaluation Against Requirements PT-9 (from PB-TNC 115 specification)................................................28 117 1. Introduction 119 This document specifies PT-EAP, a Posture Transport Protocol (PT) 120 compatible with the Trusted Computing Group's IF-T Protocol Bindings 121 for Tunneled EAP Methods (also known as EAP-TNC) [10]. The document 122 then evaluates PT-EAP against the requirements defined in the NEA 123 Requirements [7] and PB-TNC specifications [4]. 125 The PT protocol in the NEA architecture is responsible for 126 transporting PB-TNC batches (often containing PA-TNC [3] attributes) 127 across the network between the NEA Client and NEA Server. The PT 128 protocol also offers strong security protections to ensure the 129 exchanged messages are protected from a variety of threats from 130 hostile intermediaries. 132 NEA protocols are intended to be used both for pre-admission 133 assessment of endpoints joining the network and to assess endpoints 134 already present on the network. In order to support both usage 135 models, two types of PT protocols are needed. One type of PT 136 operates after the endpoint has an assigned IP address, layering on 137 top of the IP protocol to carry a NEA exchange. The other type of PT 138 operates before the endpoint gains any access to the IP network. This 139 specification defines PT-EAP, the PT protocol used to assess 140 endpoints before they gain access to the network. 142 PT-EAP is comprised of two related protocols, an outer EAP tunnel 143 method (not defined in this specification) and an inner EAP method 144 that carries the NEA assessment inside the protections of the outer 145 EAP tunnel method. This specification uses the term PT-EAP to refer 146 to both collectively. The inner EAP method is based upon a method 147 called EAP-TNC, which is part of the Trusted Computing Group's TNC 148 architecture and standards. This specification defines the EAP-TNC 149 inner EAP method, while allowing the outer EAP tunnel method to be 150 specified in another specification (possibly defined by another IETF 151 WG). The reason to define PT-EAP as including both the outer EAP 152 tunnel method and the inner EAP method is because both are required 153 to meet the PT requirements. 155 EAP-TNC is designed to operate as an inner EAP [8] method over an EAP 156 tunnel method that meets the Requirements for a Tunnel Based EAP 157 Method [15]. PT-EAP therefore can operate over a number of existing 158 access protocols that support EAP for authentication. Some examples 159 of such access protocols include 802.1X [5] for wired and wireless 160 networks and IKEv2 [13] for establishing VPNs over IP networks. 162 This document defines a standard EAP inner method called EAP-TNC. It 163 also shows how EAP-TNC may be carried over two existing EAP tunnel 164 EAP methods: EAP-FAST [12] and EAP-TTLS [14]. 166 1.1. Prerequisites 168 This document does not define an architecture or reference model. 169 Instead, it defines a protocol that works within the reference model 170 described in the NEA Requirements specification [7]. The reader is 171 assumed to be thoroughly familiar with that document. No familiarity 172 with Trusted Computing Group (TCG) specifications is assumed. 174 1.2. Message Diagram Conventions 176 This specification defines the syntax of EAP-TNC messages using 177 diagrams. Each diagram depicts the format and size of each field in 178 bits. Implementations MUST send the bits in each diagram as they are 179 shown, traversing the diagram from top to bottom and then from left 180 to right within each line (which represents a 32-bit quantity). 181 Multi-byte fields representing numeric values MUST be sent in network 182 (big endian) byte order. 184 Descriptions of bit field (e.g. flag) values are described referring 185 to the position of the bit within the field. These bit positions are 186 numbered from the most significant bit through the least significant 187 bit so a one octet field with only bit 0 set has the value 0x80. 189 1.3. Terminology 191 This document reuses many terms defined in the NEA Requirements 192 document [7], such as Posture Transport Client and Posture Transport 193 Server. The reader is assumed to have read that document and 194 understood it. 196 When defining the EAP-TNC method, this specification does not use the 197 terms "EAP peer" and "EAP authenticator". Instead, it uses the terms 198 "NEA Client" and "NEA Server" since those are considered to be more 199 familiar to NEA WG participants. However, these terms are equivalent 200 for the purposes of these specifications. The part of the NEA Client 201 that terminates EAP-TNC (generally in the Posture Transport Client) 202 is the EAP peer for EAP-TNC. The part of the NEA Server that 203 terminates EAP-TNC (generally in the Posture Transport Server) is the 204 EAP authenticator for EAP-TNC. 206 1.4. Conventions used in this document 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 210 document are to be interpreted as described in RFC 2119 [1]. 212 2. Use of EAP-TNC 214 EAP-TNC is designed to encapsulate PB-TNC batches in a simple EAP 215 method that can be carried within EAP tunnel methods. The EAP tunnel 216 methods provide confidentiality and message integrity, so EAP-TNC 217 does not have to do so. Therefore, EAP-TNC MUST only be used inside 218 an EAP tunnel method that provides strong cryptographic 219 authentication (possibly server only), message integrity and 220 confidentiality services. 222 3. Definition of EAP-TNC 224 The EAP-TNC protocol operates between a Posture Transport Client and 225 a Posture Transport Server, allowing them to send PB-TNC batches to 226 each other over an EAP tunnel method. When EAP-TNC is used, the 227 Posture Transport Client in the NEA reference model acts as an EAP 228 peer (terminating the EAP-TNC method on the endpoint) and the Posture 229 Transport Server acts as an EAP authenticator (terminating the EAP- 230 TNC method on the NEA Server). 232 This section describes and defines the EAP-TNC method. First, it 233 provides a protocol overview and a flow diagram. Second, it describes 234 specific features like version negotiation and fragmentation. Third, 235 it gives a detailed packet description. Finally, it describes how the 236 tls-unique channel binding [18] may be used to PA-TNC exchanges to 237 the EAP tunnel method, defeating MITM attacks such as the Asokan 238 attack [11]. 240 3.1. Protocol Overview 242 EAP-TNC has two phases that follow each other in strict sequence: 243 negotiation and data transport. 245 The EAP-TNC method begins with the negotiation phase. The NEA Server 246 starts this phase by sending an EAP-TNC Start message: an EAP Request 247 message of type EAP-TNC with the S (Start) flag set. The NEA Server 248 also sets the Version field as described in section 3.2. This is the 249 only message in the negotiation phase. 251 The data transport phase is the only phase of EAP-TNC where PB-TNC 252 batches are allowed to be exchanged. This phase always starts with 253 the NEA Client sending a PB-TNC batch to the NEA Server. The NEA 254 Client and NEA Server then engage in a round-robin exchange with one 255 PB-TNC batch in flight at a time. The data transport phase always 256 ends with an EAP Response message from the NEA Client to the NEA 257 Server. This message may be empty (not contain any data) if the NEA 258 Server has just sent the last PB-TNC batch in the PB-TNC exchange. 260 At the end of the EAP-TNC method, the NEA Server will indicate 261 success or failure to the EAP tunnel method. Some EAP tunnel methods 262 may provide explicit confirmation of inner method success; others may 263 not. This is out of scope for the EAP-TNC method. Successful 264 completion of EAP-TNC does not imply successful completion of the 265 overall authentication nor does EAP-TNC failure imply overall 266 failure. This depends on the administrative policy in place. 268 The NEA Server and NEA Client may engage in an abnormal termination 269 of the EAP-TNC exchange at any time by simply stopping the exchange. 270 This may also require terminating the EAP tunnel method, depending on 271 the capabilities of the EAP tunnel method. 273 The NEA Server and NEA Client MUST follow the protocol sequence 274 described in this section. 276 3.2. Version Negotiation 278 EAP-TNC version negotiation takes place in the first EAP-TNC message 279 sent by the NEA Server (the Start message) and the first EAP-TNC 280 message sent by the NEA Client (the response to the Start message). 281 The NEA Server MUST set the Version field in the Start message to the 282 maximum EAP-TNC version that the NEA Server supports and is willing 283 to accept. 285 The NEA Client chooses the EAP-TNC version to be used for the 286 exchange and places this value in the Version field in its response 287 to the Start message. The NEA Client SHOULD choose the value sent by 288 the NEA Server if the NEA Client supports it. However, the NEA Client 289 MAY set the Version field to a value less than the value sent by the 290 NEA Server (for example, if the NEA Client only supports lesser EAP- 291 TNC versions). If the NEA Client only supports EAP-TNC versions 292 greater than the value sent by the NEA Server, the EAP client MUST 293 abnormally terminate the EAP negotiation. 295 If the version sent by the NEA Client is not acceptable to the NEA 296 Server, the NEA Server MUST terminate the EAP-TNC session 297 immediately. Otherwise, the version sent by the NEA Client is the 298 version of EAP-TNC that MUST be used. Both the NEA Client and the NEA 299 Server MUST set the Version field to the chosen version number in all 300 subsequent EAP-TNC messages in this exchange. 302 This specification defines version 1 of EAP-TNC. Version 0 is 303 reserved and MUST never be sent. New versions of EAP-TNC (values 2-7) 304 may be defined by Standards Action, as defined in RFC 5226 [6]. 306 3.3. Fragmentation 308 In most cases, EAP-TNC fragmentation will not be required. But PB-TNC 309 batches can be very long and EAP message length is sometimes tightly 310 constrained so EAP-TNC includes a fragmentation mechanism to be used 311 when a particular PB-TNC batch is too long to fit into a single EAP- 312 TNC message. 314 The fragmentation mechanism used in EAP-TNC is quite similar to the 315 mechanism used by EAP-TLS [17], EAP-TTLS [14], and EAP-FAST [12]. It 316 uses the L flag (length included) and the M flag (more fragments) as 317 well as the Data Length field. 319 A party (NEA Client or NEA Server) that needs to fragment a long PB- 320 TNC batch SHOULD break the batch into pieces (called "fragments") 321 that will fit into EAP-TNC messages. Then this party sends the 322 fragments in proper sequence, one fragment per EAP-TNC message. The 323 receiving party recognizes the fragments and holds them for 324 reassembly, sending an acknowledgment for each fragment so that the 325 next fragment can be sent (since EAP only allows one message in 326 flight and is half duplex). 328 The EAP-TNC message that contains the first fragment MUST have the L 329 flag set to indicate that fragmentation is being initiated. This 330 packet also MUST contain the Data Length field, indicating the total 331 octet length of the unfragmented batch and allowing the party 332 receiving the fragments to know how much data will eventually be 333 coming. The L flag MUST NOT be set and the Data Length field MUST NOT 334 be present in any EAP-TNC message unless that message contains the 335 first fragment of a fragmented PB-TNC batch. The M flag MUST be set 336 on all but the last fragment and MUST NOT be set on the last 337 fragment. 339 A party that receives an EAP-TNC message with the M flag set MUST 340 respond with an EAP-TNC Acknowledgement message: an EAP-TNC message 341 with no Data and with the L, M, and S flags set to 0. The party that 342 sent an EAP-TNC message with the M flag set MUST wait for the EAP-TNC 343 Acknowledgement packet before sending the next fragment. 345 EAP-TNC authenticators and NEA Clients MUST include support for EAP- 346 TNC fragmentation with Data Lengths up to 100,000 octets. However, a 347 NEA Server or peer still MAY decide to terminate an EAP-TNC exchange 348 at any time for a variety of reasons. 350 3.4. EAP-TNC Message Format 352 This section provides a detailed description of the fields in an EAP- 353 TNC message. For a description of the diagram conventions used here, 354 see section 1.2. Since EAP-TNC is an EAP method, the first four 355 fields in each message are mandated by and defined in EAP. 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Code | Identifier | Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Type | Flags | Ver | Data Length | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Data Length | Data ... | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Code 369 The Code field is one octet and identifies the type of the EAP 370 message. The only values used for EAP-TNC are: 372 1 - Request 374 2 - Response 376 Identifier 378 The Identifier field is one octet and aids in matching Responses 379 with Requests. 381 Length 383 The Length field is two octets and indicates the length in octets 384 of this EAP-TNC message, starting from the Code field. If an EAP- 385 TNC message has been fragmented, the Length field will cover only 386 this fragment and thus doesn't reflect the overall length of the 387 entire unfragmented EAP-TNC message. 389 Type 391 38 393 [IANA Note: This value was previously reserved for another purpose 394 but has been used for EAP-TNC for some time and never used for the 395 other purpose so please assign this value to EAP-TNC.] 397 Flags 399 +-+-+-+-+-+ 400 |L M S R R| 401 +-+-+-+-+-+ 403 L: Length included 405 Indicates the presence of the Data Length field in the EAP-TNC 406 message. This flag MUST be set for an EAP-TNC message that 407 contains the first fragment of a fragmented EAP-TNC message and 408 only for such a message. This flag MUST NOT be set for non- 409 fragmented messages. 411 M: More fragments 413 Indicates that more fragments are to follow. This flag MUST be set 414 for all EAP-TNC messages that contain a fragmented EAP-TNC message 415 except that this bit MUST NOT be set for EAP-TNC messages that 416 contain the last fragment of a fragmented message. This flag MUST 417 NOT be set for EAP-TNC messages that contain unfragmented Data. 419 S: Start 420 Indicates the beginning of an EAP-TNC exchange. This flag MUST be 421 set only for the first message from the NEA Server. If the S flag 422 is set, the EAP message MUST NOT contain Data or have the L or M 423 flags set. 425 R: Reserved 427 This flag MUST be set to 0 and ignored upon receipt. 429 Version 431 This field is used for version negotiation, as described in 432 section 3.2. 434 Data Length 436 Data Length is an optional field four octets in length. It MUST be 437 present if and only if the L flag is set. When present, it 438 indicates the total length, before fragmentation, of a fragmented 439 PB-TNC batch. The Data Length field MUST be set in the EAP-TNC 440 message that contains the first in a series of fragments and MUST 441 NOT be set in subsequent fragments. 443 Data 445 Variable length data. The length of the Data field in a particular 446 EAP-TNC message may be determined by subtracting the length of the 447 EAP-TNC header fields from the value of the two octet Length 448 field. Note, however, that this data may be just one part of a 449 longer fragmented PB-TNC batch conveyed in multiple EAP-TNC 450 messages. 452 3.5. Preventing MITM Attacks with Channel Bindings 454 As described in the NEA Asokan Attack Analysis [16], a sophisticated 455 MITM attack can be mounted against NEA systems. The attacker 456 forwards PA-TNC messages from a healthy machine through an unhealthy 457 one so that the unhealthy machine can gain network access. Because 458 there are easier attacks on NEA systems, like having the unhealthy 459 machine lie about its configuration, this attack is generally only 460 mounted against machines with an External Measurement Agent (EMA). 461 The EMA is a separate entity, difficult to compromise, which measures 462 and attests to the configuration of the endpoint. 464 To protect against NEA Asokan attacks, the Posture Broker on an EMA- 465 equipped endpoint SHOULD pass the tls-unique channel binding [18] for 466 PT-EAP's tunnel method to the EMA. This value can then be included 467 in the EMA's attestation and the Posture Validator responsible for 468 communicating with the EMA may then confirm that the value matches 469 the tls-unique channel binding for its end of the tunnel. If the 470 values match and the integrity of the endpoint is good, the posture 471 sent by the EMA and NEA Client is from the same endpoint as the 472 client side of the TLS connection (since the endpoint knows the tls- 473 unique value) so no man-in-the-middle is forwarding posture. If they 474 differ, an attack has been detected and the Posture Validator SHOULD 475 fail its verification. 477 4. Security Considerations 479 This section discusses the major threats and countermeasures provided 480 by the EAP-TNC inner EAP method. As discussed throughout the 481 document, the EAP-TNC method is designed to run inside an EAP tunnel 482 method which is capable of protecting the EAP-TNC protocol from many 483 threats. Since the EAP tunnel method will be specified separately, 484 these security considerations specify requirements on the tunnel 485 method but do not evaluate its ability to meet those requirements. 486 4.1. Trust Relationships 488 In order to understand where security countermeasures are necessary, 489 this section starts with a discussion of where the NEA architecture 490 envisions some trust relationships between the processing elements of 491 the PT-EAP protocol. The following sub-sections discuss the trust 492 properties associated with each portion of the NEA reference model 493 directly involved with the processing of the PT-TNC protocol. 495 4.1.1. Posture Transport Client 497 The Posture Transport Client is trusted by the Posture Broker Client 498 to: 500 o Not to observe, fabricate or alter the contents of the PB-TNC 501 batches received from the network 503 o Not to observe, fabricate or alter the PB-TNC batches passed down 504 from the Posture Broker Client for transmission on the network 506 o Transmit on the network any PB-TNC batches passed down from the 507 Posture Broker Client 509 o Deliver properly security protected messages received from the 510 network that are destined for the Posture Broker Client 512 o Provide configured security protections (e.g. authentication, 513 integrity and confidentiality) for the Posture Broker Client's PB- 514 TNC batches sent on the network 516 o Expose the authenticated identity of the Posture Transport Server 518 o Verify the security protections placed upon messages received from 519 the network to ensure the messages are authentic and protected 520 from attacks on the network 522 o Provide a secure, reliable, in order delivery, full duplex 523 transport for the Posture Broker Client's messages 525 The Posture Transport Client is trusted by the Posture Transport 526 Server to: 528 o Not send malicious traffic intending to harm (e.g. denial of 529 service) the Posture Transport Server 531 o Not to intentionally send malformed messages to cause processing 532 problems for the Posture Transport Server 534 o Not to send invalid or incorrect responses to messages (e.g. 535 errors when no error is warranted) 537 o Not to ignore or drop messages causing issues for the protocol 538 processing 540 o Verify the security protections placed upon messages received from 541 the network to ensure the messages are authentic and protected 542 from attacks on the network 544 4.1.2. Posture Transport Server 546 The Posture Transport Server is trusted by the Posture Broker Server 547 to: 549 o Not to observe, fabricate or alter the contents of the PB-TNC 550 batches received from the network 552 o Not to observe, fabricate or alter the PB-TNC batches passed down 553 from the Posture Broker Server for transmission on the network 555 o Transmit on the network any PB-TNC batches passed down from the 556 Posture Broker Server 558 o Deliver properly security protected messages received from the 559 network that are destined for the Posture Broker Server 561 o Provide configured security protections (e.g. authentication, 562 integrity and confidentiality) for the Posture Broker Server's 563 messages sent on the network 565 o Expose the authenticated identity of the Posture Transport Client 567 o Verify the security protections placed upon messages received from 568 the network to ensure the messages are authentic and protected 569 from attacks on the network 571 The Posture Transport Server is trusted by the Posture Transport 572 Client to: 574 o Not send malicious traffic intending to harm (e.g. denial of 575 service) the Posture Transport Server 577 o Not to send malformed messages 579 o Not to send invalid or incorrect responses to messages (e.g. 580 errors when no error is warranted) 582 o Not to ignore or drop messages causing issues for the protocol 583 processing 585 o Verify the security protections placed upon messages received from 586 the network to ensure the messages are authentic and protected 587 from attacks on the network 589 4.2. Security Threats and Countermeasures 591 Beyond the trusted relationships assumed in section 4.1. the PT-EAP 592 EAP method faces a number of potential security attacks that could 593 require security countermeasures. 595 Generally, the PT protocol is responsible for providing strong 596 security protections for all of the NEA protocols so any threats to 597 PT's ability to protect NEA protocol messages could be very damaging 598 to deployments. For the PT-EAP method, most of the cryptographic 599 security is provided by the outer EAP tunnel method and EAP-TNC is 600 encapsulated within the protected tunnel. Therefore, this section 601 highlights the cryptographic requirements that need to be met by the 602 EAP tunnel method carrying EAP-TNC in order to meet the NEA PT 603 requirements. 605 Once the message is delivered to the Posture Broker Client or Posture 606 Broker Server, the posture brokers are trusted to properly safely 607 process the messages. 609 4.2.1. Message Theft 611 When EAP-TNC messages are sent over unprotected network links or 612 spanning local software stacks that are not trusted, the contents of 613 the messages may be subject to information theft by an intermediary 614 party. This theft could result in information being recorded for 615 future use or analysis by the adversary. Messages observed by 616 eavesdroppers could contain information that exposes potential 617 weaknesses in the security of the endpoint, or system fingerprinting 618 information easing the ability of the attacker to employ attacks more 619 likely to be successful against the endpoint. The eavesdropper might 620 also learn information about the endpoint or network policies that 621 either singularly or collectively is considered sensitive 622 information. For example, if EAP-TNC is housed in an EAP tunnel 623 method that does not provide confidentiality protection, an adversary 624 could observe the PA-TNC attributes included in the PB-TNC batch and 625 determine that the endpoint is lacking patches, or particular sub- 626 networks have more lenient policies. 628 In order to protect again NEA assessment message theft, the EAP 629 tunnel method carrying EAP-TNC MUST provide strong cryptographic 630 authentication, integrity and confidentiality protection. The use of 631 bi-directional authentication in the EAP tunnel method carrying EAP- 632 TNC ensures that only properly authenticated and authorized parties 633 may be involved in an assessment message exchange. When EAP-TNC is 634 carried within a cryptographically protected EAP tunnel method like 635 EAP-TTLS, all of the PB-TNC and PA-TNC protocol messages contents are 636 hidden from potential theft by intermediaries lurking on the network. 638 4.2.2. Message Fabrication 640 Attackers on the network or present within the NEA system could 641 introduce fabricated PT-EAP messages intending to trick or create a 642 denial of service against aspects of an assessment. For example, an 643 adversary could attempt to insert into the message exchange fake PT- 644 EAP error codes in order to disrupt communications. 646 The EAP tunnel method carrying an EAP-TNC method needs to provide 647 strong security protections for the complete message exchange over 648 the network. These security protections prevent an intermediary from 649 being able to insert fake messages into the assessment. For example, 650 the EAP-TTLS method's use of hashing algorithms provides strong 651 integrity protections that allow for detection of any changes in the 652 content of the message exchange. Additionally, adversaries are 653 unable to observe the EAP-TNC method housed inside of an encrypting 654 EAP tunnel method (e.g. EAP-TTLS) because the messages are encrypted 655 by the TLS [2] ciphers, so an attacker would have difficulty in 656 determining where to insert the falsified message, since the attacker 657 is unable to determine where the message boundaries exist. 659 4.2.3. Message Modification 661 This attack could allow an active attacker capable of intercepting a 662 message to modify a PT-EAP message or transported PA-TNC attribute to 663 a desired value to ease the compromise of an endpoint. Without the 664 ability for message recipients to detect whether a received message 665 contains the same content as what was originally sent, active 666 attackers can stealthily modify the attribute exchange. 668 The EAP-TNC method leverages the EAP tunnel method (e.g. EAP-TTLS) to 669 provide strong authentication and integrity protections as a 670 countermeasure to this threat. The bi-directional authentication 671 prevents the attacker from acting as an active man-in-the-middle to 672 the protocol that could be used to modify the message exchange. The 673 strong integrity protections (hashing) offered by EAP-TTLS allows the 674 EAP-TNC message recipients to detect message alterations by other 675 types of network based adversaries. Because EAP-TNC does not itself 676 provide explicit integrity protection for the EAP-TNC payload, an EAP 677 tunnel method that offers strong integrity protection is required to 678 mitigate this threat. 680 4.2.4. Denial of Service 682 A variety of types of denial of service attacks are possible against 683 the PT-EAP if the message exchange are left unprotected while 684 traveling over the network. The Posture Transport Client and 685 Posture Transport Server are trusted not to participate in the denial 686 of service of the assessment session, leaving the threats to come 687 from the network. 689 The EAP-TNC method primarily relies on the outer EAP tunnel method to 690 provide strong authentication (at least of one party) and deployers 691 are expected to leverage other EAP methods to authenticate the other 692 party (typically the client) within the protected tunnel. The use of 693 a protected bi-directional authentication will prevent unauthorized 694 parties from participating in a PT-EAP exchange. 696 After the cryptographic authentication by the EAP tunnel method, the 697 session can be encrypted and hashed to prevent undetected 698 modification that could create a denial of service situation. 700 However it is possible for an adversary to alter the message flows 701 causing each message to be rejected by the recipient because it fails 702 the integrity checking. 704 4.2.5. NEA Asokan Attacks 706 As described in section 3.5. and in the NEA Asokan Attack Analysis 707 [16], a sophisticated MITM attack can be mounted against NEA systems. 708 The attacker forwards PA-TNC messages from a healthy machine through 709 an unhealthy one so that the unhealthy machine can gain network 710 access. Section 3.5. and the NEA Asokan Attack Analysis provide a 711 detailed description of this attack and of the countermeasures that 712 can be employed against it. 714 Because lying endpoint attacks are much easier than Asokan attacks 715 and the only known effective countermeasure against lying endpoint 716 attacks is the use of an External Measurement Agent (EMA), 717 countermeasures against an Asokan attack are not necessary unless an 718 EMA is in use. However, PT-EAP implementers may not know whether an 719 EMA will be used with their implementation. Therefore, PT-EAP 720 implementers SHOULD support these countermeasures by providing the 721 value of the tls-unique channel binding to higher layers in the NEA 722 reference model: Posture Broker Clients, Posture Broker Servers, 723 Posture Collectors, and Posture Validators. 725 4.3. Requirements for EAP Tunnel Methods 727 Because the PT-EAP inner method described in this specification 728 relies on the outer EAP tunnel method for a majority of its security 729 protections, this section reiterates the PT requirements that MUST be 730 met by the IETF standard EAP tunnel method for use with PT-EAP. 732 The security requirements described in this specification MUST be 733 implemented in any product claiming to be PT-EAP compliant. The 734 decision of whether a particular deployment chooses to use these 735 protections is a deployment issue. A customer may choose to avoid 736 potential deployment issues or performance penalties associated with 737 the use of cryptography when the required protection has been 738 achieved through other mechanisms (e.g. physical isolation). If 739 security mechanisms may be deactivated by policy, an implementation 740 SHOULD offer an interface to query how a message will be (or was) 741 protected by PT so higher layer NEA protocols can factor this into 742 their decisions. 744 RFC 5209 includes the following requirement that is to be applied 745 during the selection of the EAP tunnel method(s) used in conjunction 746 with EAP-TNC: 748 PT-2 The PT protocol MUST be capable of supporting mutual 749 authentication, integrity, confidentiality, and replay 750 protection of the PB messages between the Posture Transport 751 Client and the Posture Transport Server. 753 Note that mutual authentication could be achieved by a combination of 754 a strong authentication of one party (e.g. TLS server when EAP-TTLS 755 is used) by the EAP tunnel method in conjunction with a second 756 authentication of the other party (e.g. client authentication inside 757 the protected tunnel) by another EAP method running prior to EAP-TNC. 759 Having the Posture Transport Client always authenticate the Posture 760 Transport Server provides assurance to the NEA Client that the NEA 761 Server is authentic (not a rogue or MiTM) prior to disclosing secret 762 or potentially privacy sensitive information about what is running or 763 configured on the endpoint. However the NEA Server's policy may 764 allow for the delay of the authentication of the NEA Client until a 765 suitable protected channel has been established allowing for non- 766 cryptographic NEA Client credentials (e.g. username/password) to be 767 used. Whether the communication channel is established with both or 768 one party performing a cryptographic authentication, the resulting 769 channel needs to provide strong integrity and confidentiality 770 protection to its contents. These protections are to be bound to at 771 least the authentication of the NEA Client, so the session is 772 cryptographically bound to a particular authentication event. 774 To support countermeasures against NEA Asokan attacks as described in 775 section 3.5. the EAP Tunnel Method used with EAP-TNC will need to 776 support the tls-unique channel binding. This should not be a high bar 777 since all EAP tunnel methods currently support this but not all 778 implementations of those methods may do so. 780 4.4. Candidate EAP Tunnel Method Protections 782 This section discusses how EAP-TNC is used within various EAP tunnel 783 methods to meet the PT requirements from section 4.3. 785 EAP-FAST and EAP-TTLS make use of TLS [2] to protect the transport of 786 information between the NEA Client and NEA Server. Each of these EAP 787 tunnel methods has two phases. In the first phase, a TLS tunnel is 788 established between NEA Client and NEA Server. In the second phase, 789 the tunnel is used to pass other information. PT-EAP requires that 790 establishing this tunnel include at least an authentication of the 791 NEA Server by the NEA Client. 793 The phase two dialog may include authentication of the user by doing 794 other EAP methods or in the case of TTLS by using non-EAP 795 authentication dialogs. EAP-TNC is also carried by the phase two 796 tunnel allowing the NEA assessment to be within an encrypted and 797 integrity protected transport. 799 With all these methods, a cryptographic key is derived from the 800 authentication that may be used to secure later transmissions. Each 801 of these methods employs at least a NEA Server authentication using 802 an X.509 certificates. Within each EAP tunnel method will exist a 803 set of inner EAP method (or an equivalent using TLVs if inner methods 804 aren't directly supported.) These inner methods may perform 805 additional security handshakes including more granular 806 authentications or exchanges of integrity information (such as EAP- 807 TNC.) At some point after the conclusion of each inner EAP method, 808 some of the methods will export the established secret keys to the 809 outer tunnel method. It's expected that the outer method will 810 cryptographically mix these keys into any keys it is currently using 811 to protect the session and perform a final operation to determine 812 whether both parties have arrived at the same mixed key. This 813 cryptographic binding of the inner method results to the outer 814 methods keys is essential for detection of conventional (non-NEA) 815 Asokan attacks. 817 4.5. Security Claims for EAP-TNC as per RFC3748 819 This section summarizes the security claims as required by RFC3748 820 Section 7.2: 822 Auth. mechanism: None 823 Ciphersuite negotiation: No 824 Mutual authentication: No 825 Integrity protection: No 826 Replay protection: No 827 Confidentiality: No 828 Key derivation: No 829 Key strength: N/A 830 Dictionary attack resistant: N/A 831 Fast reconnect: No 832 Crypt. binding: N/A 833 Session independence: N/A 834 Fragmentation: Yes 835 Channel binding: No 837 5. Privacy Considerations 839 The role of PT-EAP is to act as a secure transport for PB-TNC over a 840 network before the endpoint has been admitted to the network. As a 841 transport protocol, PT-EAP does not directly utilize or require 842 direct knowledge of any personally identifiable information (PII). 843 PT-EAP will typically be used in conjunction with other EAP methods 844 that provide for the user authentication (if bi-directional 845 authentication is used), so the user's credentials are not directly 846 seen by the EAP-TNC inner method. Therefore, the Posture Transport 847 Client and Posture Transport Server's implementation of EAP-TNC MUST 848 NOT observe the contents of the carried PB-TNC batches that could 849 contain PII carried by PA-TNC or PB-TNC. 851 While EAP-TNC does not provide cryptographic protection for the PB- 852 TNC batches, it is designed to operate within an EAP tunnel method 853 that provides strong authentication, integrity and confidentiality 854 services. Therefore, it is important for deployers to leverage these 855 protections in order to prevent disclosure of PII potentially 856 contained within PA-TNC or PB-TNC within the EAP-TNC payload. 858 6. IANA Considerations 860 This document defines an EAP method type named EAP-TNC with the 861 value 38. 863 [IANA Note: This value was previously reserved for another 864 purpose but has been used for EAP-TNC for some time and never 865 used for another purpose so please assign this value to EAP- 866 TNC.] 868 This document also defines one new IANA registry: EAP-TNC 869 Versions. This section explains how this registry works. 871 Because only eight (8) values are available in this registry, a 872 high bar is set for new assignments. The only way to register 873 new values in this registry is through Standards Action (via an 874 approved Standards Track RFC). 876 6.1. Registry for EAP-TNC Versions 878 The name for this registry is "EAP-TNC Versions". Each entry 879 in this registry includes a decimal integer value between 1 and 880 7 identifying the version, and a reference to the RFC where the 881 version is defined. 883 The following entries for this registry are defined in this 884 document. Once this document becomes an RFC, they will become 885 the initial entries in the registry for EAP-TNC Versions. 886 Additional entries to this registry are added by Standards 887 Action, as defined in RFC 5226 [6]. 889 Value Defining Specification 890 ----- ---------------------- 891 1 RFC # Assigned to this I-D 893 7. References 895 7.1. Normative References 897 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 898 Levels", BCP 14, RFC 2119, March 1997. 900 [2] Dierks T., Rescorla E., "The Transport Layer Security (TLS) 901 Protocol Version 1.2", RFC 5246, August 2008. 903 [3] Sangster P., Narayan K., "PA-TNC: A Posture Attribute Protocol 904 (PA) Compatible with TNC", RFC 5792, March 2010. 906 [4] Sahita, R., Hanna, S., and R. Hurst, "PB-TNC: A Posture Broker 907 Protocol (PB) Compatible with TNC", RFC 5793, March 2010. 909 [5] LAN/MAN Standards Committee of the IEEE Computer Society, 910 Standard for Local and Metropolitan Area Networks - Port Based 911 Network Access Control, IEEE Std. 802.1X-2004, December 2004. 913 [6] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 914 Considerations Section in RFCs", RFC 5226, May 2008. 916 7.2. Informative References 918 [7] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 919 Tardo, "Network Endpoint Assessment (NEA): Overview and 920 Requirements", RFC 5209, June 2008. 922 [8] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 923 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 924 3748, June 2004. 926 [9] Sangster, P., "PT-TLS: A Posture Transport Protocol (PT) 927 Compatible with TNC Using Transport Layer Security (TLS)", 928 draft-sangster-nea-pt-tls-02.txt, work in progress, March 2011. 930 [10] Trusted Computing Group, "TNC IF-T: Binding to TLS", 931 http://www.trustedcomputinggroup.org/files/resource_files/51F07 932 57E-1D09-3519-AD63B6FD099658A6/TNC_IFT_TLS_v1_0_r16.pdf, May 933 2009. 935 [11] N. Asokan, Valtteri Niemi, Kaisa Nyberg, "Man in the Middle 936 Attacks in Tunneled Authentication Protocols", Nokia Research 937 Center, Finland, Nov. 11, 2002, 938 http://eprint.iacr.org/2002/163.pdf 940 [12] N. Cam-Winget, D. McGrew, J. Salowey, H. Zhou, "The Flexible 941 Authentication via Secure Tunneling Extensible Authentication 942 Protocol Method (EAP-FAST)", RFC 4851, May 2007. 944 [13] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, "Internet Key 945 Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. 947 [14] P. Funk, S. Blake-Wilson, "Extensible Authentication Protocol 948 Tunneled Transport Layer Security Authenticated Protocol 949 Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 951 [15] K. Hoeper, S. Hanna, H. Zhou, J. Salowey, "Requirements for a 952 Tunnel Based EAP Method", draft-ietf-emu-eaptunnel-req-09.txt 953 (work in progress), December 2010. 955 [16] J. Salowey, S. Hanna, "NEA Asokan Attack Analysis", draft- 956 salowey-nea-asokan-00.txt (work in progress), October 2010. 958 [17] D. Simon, B. Aboba, R. Hurst, "The EAP-TLS Authentication 959 Protocol", RFC 5216, March 2008. 961 [18] J. Altman, N. Williams, L. Zhu, "Channel Bindings for TLS", RFC 962 5929, July 2010. 964 8. Acknowledgments 966 Thanks to the Trusted Computing Group for contributing the initial 967 text upon which this document was based. 969 The authors of this draft would like to acknowledge the following 970 people who have contributed to or provided substantial input on the 971 preparation of this document or predecessors to it: Amit Agarwal, 972 Morteza Ansari, Diana Arroyo, Stuart Bailey, Boris Balacheff, Uri 973 Blumenthal, Gene Chang, Scott Cochrane, Pasi Eronen, Aman Garg, 974 Sandilya Garimella, David Grawrock, Thomas Hardjono, Chris Hessing, 975 Ryan Hurst, Hidenobu Ito, John Jerrim, Meenakshi Kaushik, Greg 976 Kazmierczak, Scott Kelly, Bryan Kingsford, PJ Kirner, Sung Lee, Lisa 977 Lorenzin, Mahalingam Mani, Bipin Mistry, Seiji Munetoh, Rod 978 Murchison, Barbara Nelson, Kazuaki Nimura, Ron Pon, Ivan Pulleyn, 979 Alex Romanyuk, Ravi Sahita, Chris Salter, Mauricio Sanchez, Paul 980 Sangster, Dean Sheffield, Curtis Simonson, Jeff Six, Ned Smith, 981 Michelle Sommerstad, Joseph Tardo, Lee Terrell, Chris Trytten, and 982 John Vollbrecht. 984 This document was prepared using 2-Word-v2.0.template.dot. 986 Appendix A. Evaluation Against NEA Requirements 988 This section evaluates the PT-EAP protocol against the PT 989 requirements defined in the NEA Overview and Requirements and 990 PB-TNC specifications. Each subsection considers a separate 991 requirement and highlights how PT-EAP meets the requirement. 993 A.1. Evaluation Against Requirement C-1 995 Requirement C-1 says: 997 C-1 NEA protocols MUST support multiple round trips between 998 the NEA Client and NEA Server in a single assessment. 1000 PT-EAP meets this requirement. Use of the EAP protocol along 1001 with EAP-TNC and suitable EAP tunnel methods will allow for 1002 multiple roundtrips. 1004 A.2. Evaluation Against Requirements C-2 1006 Requirement C-2 says: 1008 C-2 NEA protocols SHOULD provide a way for both the NEA 1009 Client and the NEA Server to initiate a posture assessment or 1010 reassessment as needed. 1012 PT-EAP does NOT meet this requirement. Generally EAP is used 1013 by the endpoint during the joining of the network. At that 1014 time, the endpoint lacks an IP address so is unable to accept 1015 inbound posture assessment requests from the NEA Server. 1016 Subsequent reassessments of the endpoint after it has been 1017 given access to a portion of the IP network can use the PT-TLS 1018 protocol that supports the NEA Client and NEA Server to 1019 initiate an assessment. 1021 A.3. Evaluation Against Requirements C-3 1023 Requirement C-3 says: 1025 C-3 NEA protocols including security capabilities MUST be 1026 capable of protecting against active and passive attacks by 1027 intermediaries and endpoints including prevention from replay 1028 based attacks. 1030 PT-EAP meets this requirement by leveraging the security 1031 capabilities of the underlying EAP tunnel method. EAP-TNC 1032 itself does not provide protection against a variety of 1033 potential attacksso it relies on cryptographic support by the 1034 EAP tunnel method. 1036 A.4. Evaluation Against Requirements C-4 1038 Requirement C-4 says: 1040 C-4 The PA and PB protocols MUST be capable of operating over 1041 any PT protocol. For example, the PB protocol must provide a 1042 transport independent interface allowing the PA protocol to 1043 operate without change across a variety of network protocol 1044 environments (e.g. EAP/802.1X, PANA, TLS and IKE/IPsec). 1046 Not applicable to PT, but PT-EAP is independent of PA and PB 1047 allowing those protocols to operate over other PT protocols. 1049 A.5. Evaluation Against Requirements C-5 1051 Requirement C-5 says: 1053 C-5 The selection process for NEA protocols MUST evaluate and 1054 prefer the reuse of existing open standards that meet the 1055 requirements before defining new ones. The goal of NEA is not 1056 to create additional alternative protocols where acceptable 1057 solutions already exist. 1059 Based on this requirement, PT-EAP should receive a strong 1060 preference. PT-EAP is compatible with IF-T Binding to Tunneled 1061 EAP Methods 1.1, an open TCG specification that has been widely 1062 implemented. 1064 A.6. Evaluation Against Requirements C-6 1066 Requirement C-6 says: 1068 C-6 NEA protocols MUST be highly scalable; the protocols MUST 1069 support many Posture Collectors on a large number of NEA 1070 Clients to be assessed by numerous Posture Validators residing 1071 on multiple NEA Servers. 1073 PT-EAP meets this requirement. The PT-EAP protocol is 1074 independent of the number of Posture Collectors and Posture 1075 Validators. 1077 A.7. Evaluation Against Requirements C-7 1079 Requirement C-7 says: 1081 C-7 The protocols MUST support efficient transport of a large 1082 number of attribute messages between the NEA Client and the NEA 1083 Server. 1085 PT-EAP meets this requirement, subject to the limitations of 1086 the underlying EAP protocol. PT-EAP allows for the transport 1087 of a very large number of attributes, up to 2^32 - 1 octets per 1088 PB-TNC batch. Furthermore, the PT-EAP protocol transports data 1089 efficiently, only adding 10 octets of overhead per PT-EAP 1090 message, which is small considering that a single PT-EAP 1091 message may carry multiple PA-TNC attributes. 1093 However, it is important to note that the EAP protocol that 1094 underlies PT-EAP is not a good choice for transporting large 1095 amounts of data. EAP only supports one packet in flight at a 1096 time, which severely limits throughput. Further, some network 1097 equipment imposes timeout restrictions on EAP exchanges. 1098 Therefore, PT-EAP should not be used to transport large amounts 1099 of attributes. 1101 A.8. Evaluation Against Requirements C-8 1103 Requirement C-8 says: 1105 C-8 NEA protocols MUST operate efficiently over low bandwidth 1106 or high latency links. 1108 PT-EAP protocols meet this requirement. PT-EAP was designed to 1109 minimize the amount of overhead included in the protocol to 1110 allow for efficient use over bandwidth or latency constrained 1111 network links. 1113 A.9. Evaluation Against Requirements C-9 1115 Requirement C-9 says: 1117 C-9 For any strings intended for display to a user, the 1118 protocols MUST support adapting these strings to the user's 1119 language preferences. 1121 PT-EAP meets this requirement. PT-EAP does not include 1122 messages intended for display to the user. 1124 A.10. Evaluation Against Requirements C-10 1126 Requirement C-10 says: 1128 C-10 NEA protocols MUST support encoding of strings in UTF-8 1129 format. 1131 PT-EAP meets this requirement. The PT-EAP protocol does not 1132 include any strings in its fields but it allows higher-layer 1133 protocols to encode their strings in UTF-8 format. This allows 1134 the protocol to support a wide range of languages efficiently. 1136 A.11. Evaluation Against Requirements C-11 1138 Requirement C-11 says: 1140 C-11 Due to the potentially different transport 1141 characteristics provided by the underlying candidate PT 1142 protocols, the NEA Client and NEA Server MUST be capable of 1143 becoming aware of and adapting to the limitations of the 1144 available PT protocol. For example, some PT protocol 1145 characteristics that might impact the operation of PA and PB 1146 include restrictions on: which end can initiate a NEA 1147 connection, maximum data size in a message or full assessment, 1148 upper bound on number of roundtrips, and ordering (duplex) of 1149 messages exchanged. The selection process for the PT protocols 1150 MUST consider the limitations the candidate PT protocol would 1151 impose upon the PA and PB protocols. 1153 PT-EAP meets this requirement. The PT-EAP implementations may 1154 be limited in number of roundtrips, assessment overall time, or 1155 data transmission. These constraints will be exposed up the 1156 protocol stack so the Posture Broker Client and Posture Broker 1157 Server can optimize and make most efficient use of the 1158 available resources during the assessment. 1160 A.12. Evaluation Against Requirements PT-1 1162 Requirement PT-1 says: 1164 PT-1 The PT protocol MUST NOT interpret the contents of PB 1165 messages being transported, i.e., the data it is carrying must 1166 be opaque to it. 1168 PT-EAP meets this requirement. The PT-EAP encapsulates PB-TNC 1169 batches without interpreting their contents. 1171 A.13. Evaluation Against Requirements PT-2 1173 Requirement PT-2 says: 1175 PT-2 The PT protocol MUST be capable of supporting mutual 1176 authentication, integrity, confidentiality, and replay 1177 protection of the PB messages between the Posture Transport 1178 Client and the Posture Transport Server. 1180 PT-EAP meets this requirement. The PT-EAP protocol leverages 1181 an EAP tunnel method to provide mutual authentication, 1182 integrity protection and confidentiality as well as replay 1183 protection. For more information see the Security 1184 Considerations in section 4. 1186 A.14. Evaluation Against Requirements PT-3 1188 Requirement PT-3 says: 1190 PT-3 The PT protocol MUST provide reliable delivery for the PB 1191 protocol. This includes the ability to perform fragmentation 1192 and reassembly, detect duplicates, and reorder to provide in- 1193 sequence delivery, as required. 1195 EAP-TNC includes support for fragmentation and the underlying 1196 EAP tunnel methods include support for duplicate detection and 1197 reordering to provide in-sequence delivery. 1199 A.15. Evaluation Against Requirements PT-4 1201 Requirement PT-4 says: 1203 PT-4 The PT protocol SHOULD be able to run over existing 1204 network access protocols such as 802.1X and IKEv2. 1206 PT-EAP meets this requirement. The PT-EAP operates on top of 1207 the 802.1X and IKEv2 protocols. 1209 A.16. Evaluation Against Requirements PT-5 1211 Requirement PT-5 says: 1213 PT-5 The PT protocol SHOULD be able to run between a NEA Client 1214 and NEA Server over TCP or UDP (similar to Lightweight 1215 Directory Access Protocol (LDAP)). 1217 PT-EAP does NOT meet this requirement. PT-EAP is intended for 1218 a different usage. PT-EAP is intended to be used for pre- 1219 network admission before the endpoint has been given an IP 1220 address and routes on the network. This means that network 1221 layer protocols such as IP are not yet able to communicate with 1222 the system. The PT-TLS (PT Binding to TLS) [9] meets this 1223 requirement. 1225 A.17. Evaluation Against Requirements PT-6 (from PB-TNC specification) 1227 Requirement PT-6 says: 1229 PT-6 The PT protocol MUST be connection oriented; it MUST 1230 support confirmed initiation and close down. 1232 PT-EAP meets this requirement. The PT-EAP fits into the EAP 1233 framework which provides for orderly initiation and shutdown. 1235 A.18. Evaluation Against Requirements PT-7 (from PB-TNC specification) 1237 Requirement PT-7 says: 1239 PT-7 The PT protocol MUST be able to carry binary data. 1241 PT-EAP meets this requirement. The PT-EAP is capable of 1242 carrying binary data. 1244 A.19. Evaluation Against Requirements PT-8 (from PB-TNC specification) 1246 Requirement PT-8 says: 1248 PT-8 The PT protocol MUST provide mechanisms for flow control 1249 and congestion control. 1251 PT-EAP meets this requirement. The PT-EAP utilizes EAP's half 1252 duplex, round robin message exchange to provide flow and 1253 congestion control. 1255 A.20. Evaluation Against Requirements PT-9 (from PB-TNC specification) 1257 Requirement PT-9 says: 1259 PT-9 PT protocol specifications MUST describe the capabilities 1260 that they provide for and limitations that they impose on the 1261 PB protocol (e.g. half/full duplex, maximum message size). 1263 PT-EAP specification meets this requirement. This 1264 specification discusses the level of transport service provided 1265 to the Posture Broker Client and Posture Broker Server. 1266 Generally, the PT-EAP method supports the pre-network admission 1267 usages discussed in RFC 5209. The maximum message size for PT- 1268 EAP is 2^16-10 octets. EAP by its nature is half duplex and 1269 simple which allows it to be used in a wide variety of settings 1270 including over link layer protocols during the entrance to the 1271 network. 1273 Authors' Addresses 1275 Steve Hanna 1276 Juniper Networks, Inc. 1277 79 Parsons Street 1278 Brighton, MA 02135 USA 1279 Email: shanna@juniper.net 1281 Paul Sangster 1282 Symantec Corporation 1283 6825 Citrine Drive 1284 Carlsbad, CA 92009 USA 1285 Email: paul_sangster@symantec.com