idnits 2.17.1 draft-cam-winget-eap-tlv-03.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 7, 2011) is 4789 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: 'RFC3748' is defined on line 738, but no explicit reference was found in the text == Unused Reference: 'RFC4493' is defined on line 745, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 4493 == Outdated reference: A later version (-01) exists of draft-salowey-nea-asokan-00 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Cam-Winget 3 Internet-Draft J. Salowey 4 Intended status: Standards Track H. Zhou 5 Expires: September 8, 2011 Cisco Systems 6 March 7, 2011 8 Transport Layer Security (TLS) Based Transports for Network Endpoint 9 Assessment (NEA) Protocol Exchanges 10 draft-cam-winget-eap-tlv-03 12 Abstract 14 This document describes how Network Endpoint Assessment (NEA) data 15 can be carried under the protection of a Transport Layer Security 16 (TLS) secured tunnel. This document defines NEA transports for TLS- 17 based Extensible Authentication Protocol (EAP) tunnel methods and for 18 TLS used over TCP. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 8, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Specification Requirements . . . . . . . . . . . . . . . . . . 4 68 3. Protocol Layering Model . . . . . . . . . . . . . . . . . . . 4 69 4. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4.1. PT-TCP Protocol Flow . . . . . . . . . . . . . . . . . . . 5 71 4.1.1. Initiating a PT-TCP session . . . . . . . . . . . . . 5 72 4.1.2. TCP Port Usage . . . . . . . . . . . . . . . . . . . . 5 73 4.1.3. TLS Setup Phase . . . . . . . . . . . . . . . . . . . 5 74 4.1.4. NEA Data Transport Phase in PT-TCP . . . . . . . . . . 6 75 4.1.5. Entity Authentication using SASL in PT-TCP . . . . . . 6 76 4.1.5.1. Service Name . . . . . . . . . . . . . . . . . . . 7 77 4.1.5.2. Mechanism Negotiation . . . . . . . . . . . . . . 7 78 4.1.5.3. Message Definition . . . . . . . . . . . . . . . . 7 79 4.1.5.4. Authorization Identity . . . . . . . . . . . . . . 7 80 4.1.5.5. Aborting Authentication . . . . . . . . . . . . . 7 81 4.1.5.6. Security Layers . . . . . . . . . . . . . . . . . 7 82 4.1.5.7. Multiple Authentications . . . . . . . . . . . . . 7 83 4.2. Tunnel EAP Message Flow . . . . . . . . . . . . . . . . . 8 84 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 8 85 5.1. PT-TCP transport Format . . . . . . . . . . . . . . . . . 9 86 5.1.1. NEA TLV . . . . . . . . . . . . . . . . . . . . . . . 10 87 5.1.2. SASL-MECH TLV . . . . . . . . . . . . . . . . . . . . 11 88 5.1.3. SASL-AUTH TLV . . . . . . . . . . . . . . . . . . . . 12 89 5.1.4. SASL-RESULT TLV . . . . . . . . . . . . . . . . . . . 13 90 5.2. Using tunnel EAP to transport NEA data . . . . . . . . . . 14 91 5.2.1. Carrying NEA data in PEAP or EAP-FAST . . . . . . . . 14 92 5.2.2. Carrying NEA data in TTLS . . . . . . . . . . . . . . 16 93 6. Binding the PA exchange to the TLS Tunnel . . . . . . . . . . 17 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 96 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 98 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 99 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 100 Appendix A. Evaluation Against NEA Requirements . . . . . . . . . 19 101 A.1. Evaluation Against Requirement C-1 . . . . . . . . . . . . 19 102 A.2. Evaluation Against Requirement C-2 . . . . . . . . . . . . 19 103 A.3. Evaluation Against Requirement C-3 . . . . . . . . . . . . 19 104 A.4. Evaluation Against Requirement C-4 . . . . . . . . . . . . 20 105 A.5. Evaluation Against Requirement C-5 . . . . . . . . . . . . 20 106 A.6. Evaluation Against Requirement C-6 . . . . . . . . . . . . 21 107 A.7. Evaluation Against Requirement C-7 . . . . . . . . . . . . 21 108 A.8. Evaluation Against Requirement C-8 . . . . . . . . . . . . 21 109 A.9. Evaluation Against Requirement C-9 . . . . . . . . . . . . 22 110 A.10. Evaluation Against Requirement C-10 . . . . . . . . . . . 22 111 A.11. Evaluation Against Requirement C-11 . . . . . . . . . . . 22 112 A.12. Evaluation Against Requirement PT-1 . . . . . . . . . . . 23 113 A.13. Evaluation Against Requirement PT-2 . . . . . . . . . . . 23 114 A.14. Evaluation Against Requirement PT-3 . . . . . . . . . . . 23 115 A.15. Evaluation Against Requirement PT-4 . . . . . . . . . . . 24 116 A.16. Evaluation Against Requirement PT-5 . . . . . . . . . . . 24 117 A.17. Evaluation Against Requirement PT-6 . . . . . . . . . . . 24 118 A.18. Evaluation Against Requirement PT-7 . . . . . . . . . . . 25 119 A.19. Evaluation Against Requirement PT-8 . . . . . . . . . . . 25 120 A.20. Evaluation Against Requirement PT-9 . . . . . . . . . . . 25 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 123 1. Introduction 125 NEA has standardized a transport agnostic Posture Broker (PB) 126 protocol defined in [RFC5793] to effect a network endpoint assessment 127 between a Posture Broker Client and a Posture Broker Server. These 128 PB messages can be transported inside the already defined Type- 129 Length-Value containers in existing TLS-based tunne EAP methods such 130 as PEAP, EAP-FAST and TTLS. Similarly, this document also defines a 131 TCP based transport, PT-TCP, that uses TLVs encapsulated within TLS. 133 2. Specification Requirements 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119] . 139 3. Protocol Layering Model 141 When using EAP as the transport, the PB messages can be encapsulated 142 in the TLVs defined by the tunnel EAP methods. For TLS a new TLV 143 container is defined to facilitate the PB transport over TCP. The 144 following diagram demonstrates the relationship between protocols 145 when an EAP tunnel method is used: 147 +---------------------------------------------------------------+ 148 | TLV Encapsulation of PB-PA message | 149 |---------------------------------------------------------------| 150 | TLS | 151 |---------------------------------------------------------------| 152 | EAP tunnel based method | 153 |---------------------------------------------------------------| 154 | EAP | 155 |---------------------------------------------------------------| 156 | Carrier Protocol (EAPOL, RADIUS, Diameter, etc.) | 157 +---------------------------------------------------------------+ 159 EAP based Protocol Layering Model 161 The following diagram demonstrates the protocol relationship of PB 162 when PT-TCP is used: 164 +---------------------------------------------------------------+ 165 | TLV Encapsulation of PB-PA message | 166 |---------------------------------------------------------------| 167 | TLS | 168 +---------------------------------------------------------------+ 169 | TCP | 170 +---------------------------------------------------------------+ 172 PT-TCP based Protocol Layering Model 174 4. Protocol Flows 176 There are two distinct phases in TLS based transport operation: 178 1. TLS Setup Phase: are the messages used to establish TLS channel 179 protection for the posture messages. The TLS Setup Phase begins 180 with either the Posture Transport Client or Posture Transport 181 Server initiating the TLS Handshake protocol to establish the 182 protected TLS channel. 184 2. Data Transport Phase: are the messages that are protected by the 185 TLS Record encapsulation. This phase is usually broken up into 186 an optional entity authentication phase followed by the exchange 187 of TLVs carrying NEA data. 189 4.1. PT-TCP Protocol Flow 191 This section describes the general flow of messages between the NEA 192 Posture Transport Client and the NEA Posture Transport Server. 194 4.1.1. Initiating a PT-TCP session 196 With the use of TLS as the transport, it is possible for either the 197 Posture Transport Client or the Posture Transport Server to initiate 198 a PT-TCP session. 200 4.1.2. TCP Port Usage 202 IANA is requested to allocate a TCP Port number for the use of PT-TCP 203 so that both the Posture Transport Client and Posture Transport 204 Server can communicate on a known allocated port. 206 4.1.3. TLS Setup Phase 208 Typically, it is the NEA Client (e.g. the Posture Transport Client) 209 that initiates the TLS Setup Phase. However, either party, e.g. the 210 Posture Transport Client or the Posture Transport Server may 211 establish a TCP connection and initiate the TLS Handshake protocol. 212 Furthermore, the TLS Handshake protocol is also used to establish the 213 cryptographic protections used to secure the data carried within TLS 214 Records. 216 In typical deployments, it is expected for the initiator of a NEA 217 exchange to initiate the TLS Setup. However, this specification 218 allows for multiple NEA data transactions and as such, each 219 transaction may originate from either the NEA client or the NEA 220 server. Furthermore, through the use of the TLS session 221 capabilities, PT-TCP also allows for the re-use of the TLS based (PT- 222 TCP) session to allow either the NEA Client or the NEA Server to 223 trigger subsequent NEA exchanges. 225 4.1.4. NEA Data Transport Phase in PT-TCP 227 Once the PT-TCP session has been established, either the NEA Client 228 or the NEA Server can trigger a NEA data transaction (typically a 229 posture assessment). The initiator for the NEA data transaction 230 encapsulates the PB messages in a TLV as described in Section 5.1. 232 As PT-TCP is full-duplex (by the TLS design), it supports the full 233 capabilities of the PB-TNC state machine. 235 4.1.5. Entity Authentication using SASL in PT-TCP 237 Implementations may support entity authentication through the use of 238 SASL [RFC4422]. This section details the SASL profile for PT-TCP. 240 Typically, the PT-TCP initiator will also initiate the SASL exchange. 241 The responder presents a list of SASL mechanism it supports through 242 the use of the SASL-AUTH-MECH TLV. The initiator may request a list 243 of SASL authentication mechanisms by sending an empty list of 244 mechanisms in the SASL-AUTH-MECH TLV. 246 The initiator starts the authentication by sending a SASL-AUTH TLV 247 with the mech field containing the name of the mechanism it selects. 248 If the selected mechanism has an initial response then the client 249 includes that response in the auth-data field. If necessary the 250 responder sends a SASL-AUTH TLV with the auth-data field containing a 251 SASL challenge for the selected mechanism. The SASL-AUTH exchange 252 continues in this manner until the authentication completes upon 253 completion the responder sends a SASL-RESULT TLV. If the 254 authentication is successful the SASL-RESULT TLV contains an result 255 code of success. If the authentication fails the SASL-RESULT TLV 256 contains a result code indicating the reason for the failure. The 257 initiator may abort the exchange by sending a SASL-RESULT TLV with an 258 ABORT result code. 260 Implementations MUST provide the EXTERNAL SASL mechanism if the 261 initiator is authenticated during the TLS establishment. 262 Implementations MUST also support the PLAIN SASL mechanism. 264 4.1.5.1. Service Name 266 The service name for PT-TCP is "nea-pt-tcp". 268 4.1.5.2. Mechanism Negotiation 270 Mechanism Negotiation is performed using the SASL-AUTH-MECH TLV. The 271 SASL-AUTH-MECH TLV contains the list of mechanisms supported by the 272 responder. The initiator may send a SASL-AUTH-MECH TLV with an 273 emptily list to request a list format from the responder. 275 4.1.5.3. Message Definition 277 The initiator starts authentication by sending a SASL-AUTH TLV 278 indicating the sleeted mechanism. The initial message may contain an 279 initial response if required by the selected mechanism. Subsequent 280 challenges and response are carried within SASL-AUTH TLVs between the 281 initiator and responder carrying the authentication data for the 282 mechanism. The authentication outcome is communicated in a SASL- 283 RESULT TLV containing a status code. 285 4.1.5.4. Authorization Identity 287 The nea-pt-tcp protocol does not make use of an authorization 288 identity. 290 4.1.5.5. Aborting Authentication 292 The initiator may abort the authentication exchange by sending the 293 SASL-AUTH-RESULT TLV with a status code of ABORT. 295 4.1.5.6. Security Layers 297 The NEA PT-TCP protocol always runs under the protection of TLS. 298 SASL security layers are not used. 300 4.1.5.7. Multiple Authentications 302 Only one authentication may be in progress at any one time. Once an 303 authentication completes, successfully on unsuccessfully, a new 304 authentication may be initiated. 306 4.2. Tunnel EAP Message Flow 308 This section discusses the general flow of messages between the NEA 309 Client's Posture Transport Client and the NEA Server's Posture 310 Transport Server in order to perform NEA assessments when using a 311 tunnel EAP method. 313 When NEA data exchange is conducted in a tunnel EAP method, it 314 typically consists of four phases: 316 1. Establishment of EAP tunnel method: a secure and protected TLS 317 channel is established between the Transport Client and Transport 318 Server, after the Transport Server's identity has been 319 authenticated and a shared secret encryption key is established 320 between them. 322 2. Entity authentication: during this phase, the NEA Client's 323 Posture Transport Client's identity might be optionally 324 authenticated, so appropriate posture assessment policy could be 325 applied according to the authenticated entity. Typically, it is 326 done via an inner EAP method or authentication exchanges within 327 the protected tunnel. In addition, the identity could also be 328 authenticated as part of the tunnel establishment instead (e.g., 329 the client sends a client certificate as part of the tunnel 330 establishment). 332 3. Posture assessment: the posture data are exchanged between the 333 NEA Client's Posture Transport client and NEA Server's Posture 334 Transport Server. The posture data is encapsulated in a TLV or 335 TLV like type object, as described in Section 5.2. 337 4. Conclusion phase: the result of the authentication and/or posture 338 assessment is exchanged between the client and server, so they 339 will have synchronized state. Optional cryptographic binding 340 might be done to ensure both peers are involved in both the 341 tunnel establishment and the inner method exchanges. Both sides 342 are ready to tear down the tunnel and finish the EAP method. 344 At the end of the tunnel EAP method, an EAP-Success or EAP-Failure 345 will be sent by the EAP server to indicate the end of the EAP 346 authentication, and the NAS will apply appropriate authorization 347 policy based on the authentication and posture assessment result. 349 5. Packet Formats 351 As there is no explicit authentication expected in the PB-PA message 352 exchanges, no new inner EAP method is required; rather, the TLV 353 formats defined in existing EAP tunnel methods can be used to 354 encapsulate and transport PB-PA messages. Similarly, when using TLS 355 a TLV format can be defined to carry NEA data. This section 356 describes how NEA data can be carried in either a tunnel EAP method 357 or TLS. 359 5.1. PT-TCP transport Format 361 This section defines a Type-Length-Value (TLV) encapsulation for 362 carrying NEA data in a TLS channel. The TLS channel MUST be 363 protected to carry NEA data using the encapsulation defined below. 364 The fields are transmitted from left to right. 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | R | TLV Type | Length | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Length | Data | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Data | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 R 378 Reserved, set to zero (0) 380 TLV Type 382 TLV Type Code. Allocated Types include: 384 0 Reserved 386 1 NEA TLV 388 2 SASL-MECH TLV 390 3 SASL-AUTH TLV 392 4 SASL-RESULT TLV 394 Length 396 The length of the Data field in octets. 398 Data 400 Data according to the TLV type. 402 5.1.1. NEA TLV 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | R | TLV Type | Length | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Length | PB-TNC Header | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | PB-TNC Header | PB-PA Message... | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | PB-PA Message... | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 R 418 Reserved, set to zero (0) 420 TLV Type 422 1 for NEA TLV 424 Length 426 The length of the Value field in octets. 428 PB-TNC Header 430 The PB-TNC encapsulation header as described in [RFC5793]. 432 PB-PA Message 434 The message between the Posture Broker Client and Posture Broker 435 Server as described in [RFC5793]. 437 5.1.2. SASL-MECH TLV 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | R | TLV Type | Length | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Length | Mech-Name-Length | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Mechanism Name | 447 | | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Mech-Name-Length | | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 451 | Mechanism Name | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 ... 455 The SASL-MECH TLV contains a list of supported SASL mechanisms. Each 456 mechanism name consists of a name length followed by the name. The 457 total length of the list is determined by the TLV length field. 459 R 461 Reserved, set to zero (0) 463 TLV Type 465 2 for SASL-MECH TLV 467 Length 469 The length of the Value field in octets. The value field contains 470 the list of mechanism names. 472 Mech-Name-Length 474 Length of the mechanism name in bytes. 476 Mech-Name 478 SASL mechanism Name adhering to the rules defined in [RFC4422]. 480 5.1.3. SASL-AUTH TLV 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | R | TLV Type | Length | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Length | Mech-Name-Length | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Mechanism Name | 490 | | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | | 493 | | 494 | Mechanism Data | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 The SASL-AUTH TLV contains data pertaining a SASL mechanism. The 498 mechanism name is included in each SASL-AUTH TLV. The TLV is used by 499 the initiator to select from a list of supported mechanisms provided 500 by the responder. The initial response from the initiator may 501 contain Mechanism Data containing the initial response. If the 502 mechanism selected does not use an initial response then the 503 mechanism data field is not included. The SASL-AUTH TLV is also used 504 to communicate SASL mechanism data from the responder to the 505 initiator. 507 R 509 Reserved, set to zero (0) 511 TLV Type 513 3 for SASL-AUTH TLV 515 Length 517 The length of the Value field in octets. The value field contains 518 a mechanism name and optional mechanism data.. 520 Mech-Name-Length 522 Length of the mechanism name in bytes. 524 Mech-Name 526 SASL mechanism Name adhering to the rules defined in [RFC4422]. 527 This is the mechanism selected for use by the initiator. 529 Mech-Name 531 SASL mechanism data for named mechanism. This field may be 532 omitted in the initial response from the initiator if the selected 533 mechanism does not use an initial response. 535 5.1.4. SASL-RESULT TLV 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | R | TLV Type | Length | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Length | Result-Code | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 The SASL-RESULT TLV contains the result of the SASL Exchange. A 546 result code of 0 indicates success. Other result codes indicate some 547 sort of failure. A result code of 1 indicates the exchange was 548 aborted by the sender. A result code of 2 indicates a failure within 549 the mechanism. Only the responder side of the conversation may send 550 a successful result code. Either side may send a failure result code 551 which terminates the current authentication conversation. 553 R 555 Reserved, set to zero (0) 557 TLV Type 559 4 for SASL-Result TLV 561 Length 563 The length of the Value field in octets. This field is set to 2. 565 Result Code 567 The value of the result code. 569 0 Success 571 1 Abort 573 2 Mechanism Failure 575 5.2. Using tunnel EAP to transport NEA data 577 This section describes the TLV encapsulation used in three 578 predominant tunnel EAP methods deployed today: PEAP, EAP-FAST and 579 TTLS. When using EAP tunnel methods, the tunnel MUST be protected. 581 5.2.1. Carrying NEA data in PEAP or EAP-FAST 583 As TLV format for PEAP and EAP-FAST are the same, the diagram below 584 shows how PB-PA messages can be encapsulated in the TLVs. Note 585 however that the type assignments when using PEAP versus EAP-FAST may 586 be different. The fields are transmitted from left to right. 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 |M|R| TLV Type | Length | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | PB-TNC Header | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | PB-PA Message... | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 M 600 0 Optional TLV 602 1 Mandatory TLV 604 R 606 Reserved, set to zero (0) 608 TLV Type 610 The EAP-FAST NEA TLV type: 612 TBD 614 Length 616 The length of the Value field in octets. 618 PB-TNC Header 620 The PB-TNC encapsulation header as described in [RFC5793]. 622 PB-PA Message 624 The message between the Posture Broker Client and Posture 625 Broker Server as described in [RFC5793]. 627 5.2.2. Carrying NEA data in TTLS 629 The TTLS AVP Format to carry PB-PA messages is defined and described 630 below. The fields are transmitted from left to right. 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | AVP Code | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | AVP Flags | AVP Length | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | PB-TNC Header | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | | 642 | PB-PA-Message... | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 AVP Code 647 The TTLS NEA AVP type code: 649 TBD 651 AVP Flags 653 The AVP flags are set to 0. 655 AVP Length 657 The length of the AVP in octets. 659 PB-TNC Header 661 The PB-TNC encapsulation header as described in [RFC5793]. 663 PB-PA Message 665 The message between the Posture Broker Client and Posture 666 Broker Server as described in [RFC5793]. 668 6. Binding the PA exchange to the TLS Tunnel 670 Some implementations of the NEA system allow for the external 671 validation of the data collected and sent by the posture collector. 672 In these cases, an external measurement agent (EMA) signs the data 673 sent by the collector. In order to prevent posture data of the 674 endpoint from being used on another machine, the TLS tunnel and the 675 posture data signed by the EMA must be bound together. This is done 676 using the "tls-unique" channel binding defined in RFC 5929 [RFC5929]. 677 The data from the first TLS Finished message sent on the most recent 678 TLS connection handshake is included in the data signed by the EMA. 679 The PA attributes used are specific to the EMA used by the posture 680 collector. 682 The "tls-unique" channel-binding data can be used whenever a TLS 683 transport is provided, including TLS over TCP and TLS used in tunnel 684 EAP methods. It is RECOMMENDED that posture collectors that support 685 an EMA provide a PA attribute to carry the "tls-unique" channel 686 binding data. The channel binding data MAY be combined with other 687 data using a cryptographic hash or similar technique. The channel 688 binding attribute MUST be signed by the EMA. Posture validators that 689 receive channel binding data MUST verify that it is consistent with 690 the channel binding data obtained from the server-side of the TLS 691 connection. 693 7. Security Considerations 695 The NEA TLV container carries network endpoint assessment information 696 between the Posture Broker Client and the Posture Broker Server. As 697 some of this data can be sensitive, TLS cipher suites that provide 698 encryption are RECOMMENDED. 700 To address the potential man-in-the-middle attack similar to the 701 Asokan attack described in [I-D.salowey-nea-asokan] the channel 702 binding mechanism defined in Section 6 SHOULD be used whenever an EMA 703 is available to sign the posture data. 705 8. IANA Considerations 707 IANA is requested to assign a TCP port number in the "Registered 708 Port" range with the keyword "pt-tcp". This port will be the default 709 port for PT-TCP defined in this document. 711 IANA is requested to allocate a TLV type from the EAP-FAST TLV Type 712 registry for carrying posture data as specified in Section 5.2.1. 714 IANA is requested to allocate a Diameter AVP code from the Diameter 715 AVP code registry for carrying posture data as specified in 716 Section 5.2.2. 718 This document defines a registry for TLV types to be carried within 719 PT-TCP, which may be assigned by Specification Required as defined in 720 [RFC2434] 722 9. Acknowledgements 724 The authors would like to recognize Susan Thomson, Syam Appala and 725 Subbu Srinivasan for providing input into this draft. 727 10. References 729 10.1. Normative References 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, March 1997. 734 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 735 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 736 October 1998. 738 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 739 Levkowetz, "Extensible Authentication Protocol (EAP)", 740 RFC 3748, June 2004. 742 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 743 Security Layer (SASL)", RFC 4422, June 2006. 745 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 746 AES-CMAC Algorithm", RFC 4493, June 2006. 748 [RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: 749 A Posture Broker (PB) Protocol Compatible with Trusted 750 Network Connect (TNC)", RFC 5793, March 2010. 752 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 753 for TLS", RFC 5929, July 2010. 755 10.2. Informative References 757 [I-D.salowey-nea-asokan] 758 Salowey, J. and S. Hanna, "NEA Asokan Attack Analysis", 759 draft-salowey-nea-asokan-00 (work in progress), 760 October 2010. 762 Appendix A. Evaluation Against NEA Requirements 764 This section evaluates both the PT-TCP and EAP based protocols 765 against the PT requirements defined in the NEA Overview and 766 Requirements and PB-TNC specifications. 768 A.1. Evaluation Against Requirement C-1 770 Requirement C-1 states: 772 C-1 NEA protocols MUST support multiple round trips between the NEA 773 Client and the NEA Server in a single assessment. 775 PT-TCP meets this requirement. By using the TLS protocol over TCP, 776 multiple roundtrips of TLS records and thus PT-TCP messages are 777 allowed. 779 Tunnel EAP meets this requirement. All available Tunnel EAP methods 780 are based on the TLS design which allows for multiple round trips. 782 A.2. Evaluation Against Requirement C-2 784 Requirement C-2 states: 786 C-2 NEA protocols SHOULD provide a way for both the NEA Client and 787 the NEA Server to initiate a posture assessment or reassessment as 788 needed. 790 PT-TCP meets this requirement. PT-TCP allows either the NEA Client 791 or the NEA Server to initiate an assessment or reassessment. 793 Tunnel EAP does not meet this requirement. The typical use case 794 scenario for using a Tunnel EAP method is to service the layer 2 795 network stack. In this use case, the endpoint would not have an IP 796 address yet as it is requesting network access and thus would not be 797 able to accept requests from the NEA Server. However, once network 798 access has been granted, then yes, the NEA Client could receive 799 (re)assessment requests from the NEA Server. 801 A.3. Evaluation Against Requirement C-3 803 Requirement C-3 states: 805 C-3 NEA protocols including security capabilities MUST be capable of 806 protecting against active and passive attacks by intermediaries and 807 endpoints including prevention from replay based attacks. 809 PT-TCP meets this requirement. TLS includes mechanisms that provide 810 strong cryptographic authentication, message integrity and 811 confidentiality for NEA. In addition, to further mitigate man-in-the 812 middle attacks, the use of channel binding at the PA layer must be 813 used. 815 Tunnel EAP meets this requirement. All available Tunnel EAP methods 816 are based on the TLS design which provide strong cryptographic 817 authentication, message integrity and confidentiality for NEA. In 818 addition, to further mitigate man-in-the middle attacks, the use of 819 channel binding at the PA layer must be used. 821 A.4. Evaluation Against Requirement C-4 823 Requirement C-4 states: 825 C-4 The PA and PB protocols MUST be capable of operating over any PT 826 protocol. 828 This requirement is not applicable to PT, though the PT-TCP protocol 829 is independent of both the PA and PB layer. 831 This requirement is not applicable to PT, though the Tunnel EAP 832 protocols are independent of both the PA and PB layer. 834 A.5. Evaluation Against Requirement C-5 836 Requirement C-5 states: 838 C-5 The selection process for NEA protocols MUST evaluate and prefer 839 the reuse of existing open standards that meet the requirements 840 before defining new ones. The goal of NEA is not to create 841 additional alternative protocols where acceptable solutions already 842 exist. 844 As TLS is a widely used open standard, it should meet this 845 requirement. 847 As EMU is still in the early stages of standardizing a Tunnel EAP 848 method, this specification reuses already widely deployed, published 849 Tunnel EAP methods. Rather than defining a new Tunnel EAP method, 850 this specification proposes to adopt already used ones and provides 851 guidance for how new Tunnel EAP methods can meet this criteria to 852 allow for NEA to use the method standardized by EMU at some future 853 date. 855 A.6. Evaluation Against Requirement C-6 857 Requirement C-6 states: 859 C-6 NEA protocols MUST be highly scalable; the protocols MUST support 860 many Posture Collectors on a large number of NEA Clients to be 861 assessed by numerous Posture Validators residing on multiple NEA 862 Servers. 864 PT-TCP meets this requirement. As PT-TCP is a protocol to establish 865 a protected channel by which NEA data can be transported, it is 866 independent of the content of the data it is transporting and thus 867 can allow for carrying batches of data to multiple Posture Validators 868 or Posture Collectors. 870 Tunnel EAP methods meet this requirement. As the Tunnel EAP methods 871 define a protected transport channel that is independent of the 872 content it transports, it can carry batches of data from and to 873 multiple Posture Collectors and Posture Validators. 875 A.7. Evaluation Against Requirement C-7 877 Requirement C-7 states: 879 C-7 The protocols MUST support efficient transport of a large number 880 of attribute messages between the NEA Client and the NEA Server. 882 PT-TCP meets this requirement. The PT-TCP usurps 6 octets of 883 overhead per PT-TCP message; a small overhead to the ability to carry 884 very many PA-TNC attributes within a PB-TNC batch. 886 The Tunnel EAP methods meet this requirements subject to the 887 limitations of the underlying EAP protocol and encapsulation 888 mechanisms. Note that a typical use case for the Tunnel EAP methods 889 is that the assessments are brief and used for enabling network 890 access; as such, it is not recommended to use Tunnel EAP methods to 891 carry large amounts of attributes. 893 A.8. Evaluation Against Requirement C-8 895 Requirement C-8 states: 897 C-8 NEA protocols MUST operate efficiently over low bandwidth or high 898 latency links. 900 PT-TCP meets this requirement. As TLS was originally designed to 901 work at the TCP layer, it has been proven to work well over either 902 low bandwidth or high latency links. 904 EAP Tunnel methods meet this requirement. The underlying EAP 905 framework was designed and proven to work under constrained and low 906 latency links. 908 A.9. Evaluation Against Requirement C-9 910 Requirement C-9 states: 912 C-9 For any strings intended for display to a user, the protocols 913 MUST support adapting these strings to the user's language 914 preferences. 916 PT-TCP meets this requirement. The PT-TCP protocol does not define 917 messages intended for display to the user. 919 EAP Tunnel methods meet this requirement. The EAP Tunnel methods do 920 not define messages intended for display to the user. 922 A.10. Evaluation Against Requirement C-10 924 Requirement C-10 states: 926 C-10 NEA protocols MUST support encoding of strings in UTF-8 format. 928 PT-TCP meets this requirement. The PT-TCP protocol does not define 929 messages intended for display to the user. 931 EAP Tunnel methods meet this requirement. The EAP Tunnel methods do 932 not define messages intended for display to the user. 934 A.11. Evaluation Against Requirement C-11 936 Requirement C-11 states: 938 C-11 Due to the potentially different transport characteristics 939 provided by the underlying candidate PT protocols, the NEA Client and 940 the NEA Server MUST be capable of becoming aware of and adapting to 941 the limitations of the available PT protocol. 943 PT-TCP meets this requirement. The PT-TCP protocol uses TLS which is 944 designed to provide reliable transport that can adapt to constrained 945 or low bandwidth links. 947 EAP Tunnel methods meet this requirement. The EAP Tunnel methods are 948 based on TLS which is designed to provide reliable transport and have 949 been proven to adapt and work well under high latency or low 950 bandwidth conditions. 952 A.12. Evaluation Against Requirement PT-1 954 Requirement PT-1 states: 956 PT-1 The PT protocol MUST NOT interpret the contents of PB messages 957 being transported, i.e., the data it is carrying must be opaque to 958 it. 960 PT-TCP meets this requirement. The PT-TCP protocol encapsulates PB 961 messages in a TLV container without interpreting their contents. 963 EAP Tunnel methods meet this requirement. The EAP Tunnel methods 964 define encapsulations for carrying arbitrary data without 965 interpreting their contents. 967 A.13. Evaluation Against Requirement PT-2 969 Requirement PT-2 states: 971 PT-2 The PT protocol MUST be capable of supporting mutual 972 authentication, integrity, confidentiality, and replay protection of 973 the PB messages between the Posture Transport Client and the Posture 974 Transport Server. 976 PT-TCP meets this requirement. The PT-TCP protocol uses TLS to 977 provide mutual authentication, integrity, confidentiality, and replay 978 protection. 980 EAP Tunnel methods meet this requirement. The EAP Tunnel methods are 981 based on TLS which is designed to provide mutual authentication, 982 integrity, confidentiality, and replay protection. 984 A.14. Evaluation Against Requirement PT-3 986 Requirement PT-3 states: 988 PT-3 The PT protocol MUST provide reliable delivery for the PB 989 protocol. This includes the ability to perform fragmentation and 990 reassembly, detect duplicates, and reorder to provide in-sequence 991 delivery, as required. 993 PT-TCP meets this requirement. The PT-TCP protocol is designed to 994 work over TCP which provides the fragmentation and reassembly 995 services, detect duplicates and reorder messages if they arrive out 996 of order. 998 EAP Tunnel methods meet this requirement. The EAP Tunnel methods are 999 based on the EAP framework which provides retransmissions, while 1000 reordering and fragmentation are handled by the individual EAP Tunnel 1001 methods. 1003 A.15. Evaluation Against Requirement PT-4 1005 Requirement PT-4 states: 1007 PT-4 The PT protocol SHOULD be able to run over existing network 1008 access protocols such as 802.1X and IKEv2. 1010 PT-TCP does NOT meet this requirement as it is designed to operate 1011 over TCP. 1013 EAP Tunnel methods meet this requirement. The EAP Tunnel methods are 1014 based on EAP which has been enabled on both 802.1X and IKEv2. 1016 A.16. Evaluation Against Requirement PT-5 1018 Requirement PT-5 states: 1020 PT-5 The PT protocol SHOULD be able to run between a NEA Client and 1021 NEA Server over TCP or UDP (similar to Lightweight Directory Access 1022 Protocol (LDAP)) 1024 PT-TCP meets this requirement. The PT-TCP protocol is designed to 1025 operate over a TCP connection. 1027 EAP Tunnel methods do NOT meet this requirement. The EAP Tunnel 1028 methods are designed to work pre-network admission and thus are not 1029 able to communicate at the IP layer. 1031 A.17. Evaluation Against Requirement PT-6 1033 Requirement PT-6 states: 1035 PT-6 The PT protocol MUST be connection oriented; it MUST support 1036 confirmed initiation and close down. 1038 PT-TCP meets this requirement. The PT-TCP protocol is designed to 1039 operate over a TCP connection which is connection oriented and 1040 supports initiation and tear down of the connection. 1042 EAP Tunnel methods meet this requirement. The EAP Tunnel methods are 1043 based on EAP which provides both initiation and shutdown. 1045 A.18. Evaluation Against Requirement PT-7 1047 Requirement PT-7 states: 1049 PT-7 The PT protocol MUST be able to carry binary data. 1051 PT-TCP meets this requirement. The PT-TCP protocol is capable of 1052 carrying binary data. 1054 EAP Tunnel methods meet this requirement. The EAP Tunnel methods are 1055 capable of carrying binary data. 1057 A.19. Evaluation Against Requirement PT-8 1059 Requirement PT-8 states: 1061 PT-8 The PT protocol MUST provide mechanisms for flow control and 1062 congestion control. 1064 PT-TCP meets this requirement. The PT-TCP protocol operates over TCP 1065 which provides flow control and congestion control. 1067 EAP Tunnel methods meet this requirement. The EAP Tunnel methods are 1068 based on EAP which, by use of the half-duplex, round-robin message 1069 exchange, flow and congestion control are provided. 1071 A.20. Evaluation Against Requirement PT-9 1073 Requirement PT-9 states: 1075 PT-9 The PT protocol specifications MUST describe the capabilities 1076 that they provide for and limitations that they impose on the PB 1077 protocol (e.g. half/full duplex, maximum message size). 1079 PT-TCP meets this requirement. This specification has provided the 1080 required information. 1082 EAP Tunnel methods meet this requirement. This specification has 1083 provided the required information. 1085 Authors' Addresses 1087 Nancy Cam-Winget 1088 Cisco Systems 1089 80 West Tasman Drive 1090 San Jose, CA 95134 1091 US 1093 Email: ncamwing@cisco.com 1095 Joseph Salowey 1096 Cisco Systems 1097 2901 Third Avenue 1098 Seattle, WA 98121 1099 US 1101 Email: jsalowey@cisco.com 1103 Hao Zhou 1104 Cisco Systems 1105 4125 Highlander Parkway 1106 Richfield, OH 44286 1107 US 1109 Email: hzhou@cisco.com