These notes do not attempt to duplicate the content of the slides. Instead, they summarize the material presented, and focus on comments and discussion. Agenda ====== Date: Monday, March 22, 2010 Time: 1300-1500 WG Charter: http://www.ietf.org/html.charters/nea-charter.html WG Tools: http://tools.ietf.org/wg/nea WG email: nea@ietf.org 1300 Administrivia Jabber & Minute scribes Agenda bashing 1305 WG Status 1310 Summary of NEA WG virtual interim meeting 1315 Review PT submissions http://www.ietf.org/id/draft-sangster-nea-pt-tls-00.txt http://www.ietf.org/id/draft-hanna-nea-pt-eap-00.txt http://www.ietf.org/id/draft-cam-winget-eap-nea-tlv-00.txt http://www.ietf.org/id/draft-cam-winget-eap-tlv-00.txt 1330 Discuss MITM attack and counter-measure 1350 Discuss how proposals meet PT requirements 1400 Discuss impact on existing supplicants for EAP-based PT 1405 Discuss feedback from ADs re EAP process 1425 Discuss PT proposals 1440 Consensus Check 1450 Discuss Next Steps 1500 Adjourn WG Status & Plans ================= Susan Thomson reviewed WG status. Since IETF 76, two NEA WG documents have been published as RFCs: PA-TNC and PB-TNC. That just leaves one deliverable in our charter: PT. Three proposals for PT were submitted before the January 4 deadline. A virtual interim NEA WG meeting was held on January 28 to review these proposals. Summary of NEA WG Virtual Interim Meeting ========================================= Susan Thomson gave a brief summary of the NEA WG virtual interim meeting held on January 28, 2010. We started the virtual interim by reviewing the PT submissions. One was based on TLS: EAP-TLS (draft-sangster-nea-pt-tls-00.txt). Two PT were based on EAP: PT-EAP (draft-hanna-nea-pt-eap-00.txt) and EAP-NEA-TLV (draft-cam-winget-eap-nea-tlv-00.txt). EAP-NEA-TLV has a dependency on EAP-TLV (draft-cam-winget-eap-tlv-00.txt). After reviewing the PT submissions, we ran several consensus checks. Do you support work on TLS-based PT? (Yes/No/Defer) Meeting Result: Yes Do you support adoption of PT-TLS as a -00 WG draft? (Yes/No/Defer) Meeting Result: No consensus Do you support work on EAP-based PT? (Yes/No/Defer) Meeting Result: Yes What should we adopt as EAP-based PT? (EAP-TNC/NEA TLV/Other) Meeting Result: No consensus The main issues that came up at the virtual interim meeting were: * With PT-TLS, should we use some existing client authentication framework? * With PT-EAP, there was some uncertainty about the trust model, especially the MITM threat and counter-measure. * With EAP-NEA-TLV, there was disagreement on whether EAP-NEA-TLV meets the NEA requirements. * Can we proceed with our work or do we need to wait for the EMU WG to agree on an EAP Tunnel Method? The following action items came out of the virtual interim meeting: * Describe MITM attack and the D-H PN countermeasure. * Discuss how proposals meet PT requirements * Determine impact on existing supplicants * Consult with AD on process for standardizing EAP-based PT PT-TLS Overview =============== Paul Sangster gave an overview of PT-TLS. This protocol provides a NEA exchange over TLS. It runs at the application layer so it does not require any changes to TLS. PT-TLS is identical to the IF-T binding for TLS from TCG (Trusted Computing Group). PT-TLS meets all applicable PT requirements (not the one that says it must run over EAP. Paul reviewed four common use cases for PT-TLS: NEA Assessment on a Non-802.1X Network, Large Amount of Data in NEA Assessment, Posture Reassessment, and Application Server Needs NEA Assessment. PT-TLS has three phases: TLS Handshake, Pre-Negotiation, and Data Transport. PT-EAP Overview =============== Paul Sangster gave an overview of PT-EAP. This protocol provides a NEA exchange over EAP. It runs inside any of the EAP Tunnel Methods (PEAP, EAP-TTLS, or EAP-FAST) without requiring any changes to those methods. Like the PT-TLS spec, PT-EAP is identical to a TCG specification: IF-T Protocol Bindings for Tunneled EAP Methods. PT-EAP meets all applicable PT requirements (but not the one that says it must run over TCP/IP). Paul reviewed two common use cases for PT-EAP: NEA Assessment on 802.1X Network and NEA Assessment during IKEv2 Handshake. PT-EAP has three phases: Optional Diffie-Hellman Pre-Negotiation, PB-TNC Exchange, and Optional Key Derivation and Export. Paul reviewed the features of PT-EAP. EAP-NEA-TLV Overview ==================== Nancy Cam-Winget gave an overview of EAP-NEA-TLV. First, she reviewed EAP-TLV, which is a general container format for transporting data over an EAP Tunnel Method. EAP-NEA-TLV uses EAP-TLV to carry PB-TNC messages over EAP. EAP-NEA-TLV addresses the same use cases as PT-EAP. Nancy explained how the TLV encapsulation works. The sequencing of EAP-NEA-TLV is similar to PT-TLS, except that it adds EAP encapsulation. Nancy reviewed the features of EAP-NEA-TLV. Discuss MITM Attack and Countermeasure ====================================== Steve Hanna walked through a description of the Asokan attack, which was summarized and illustrated in documents that he sent to the NEA WG list last week. He also discussed how Crypto Bindings can be used to foil the Asokan attack. He also described how the Asokan attack applies to NEA and how Diffie-Hellmann Pre-Negotiation (D-H PN) stops it. Steve asserted that RFC 5209 (NEA Requirements) requires that we support countermeasures to the Asokan attack. Nancy asked a series of questions about how D-H PN works and Steve answered them. Nancy discussed RFC 5209 protocol requirements for MITM countermeasures. Nancy quoted section 8.3.1 where text says that the EAP Tunnel Method should handle MITM. Steve asserted that if Asokan attack were a typical MITM, standard MITM countermeasures as recommended by 8.3.1 would suffice, but Askon is not a standard MITM. Nancy countered by asking why Asokan attack is being addressed in layer 2 and not layer 3. Steve responded that the Asokan attack should also be addressed at layer 3. Nancy asserted that the DH approach proposed by Steve relies on unauthenticated DH and therefore does not address MITM attack. Paul commented that modifying PT-TLS to address MITM would not be difficult. Nancy suggested that we explore other ways to address the Asokan attack, such as RFC 5705 (TLS Extractor). Steve asserted that RFC5705 will not work because RFC5705 is just extracting additional data from TLS and won't address the crypto binding requirements. But we should look into what other approaches might work. Nancy feels that we need to step back and identify what the requirements are. Steve suggested that we should agree on whether we should address Askon attack. If we agree that we should, then we can talk about how. Joe Salowey said that the current proposal for Asokan mitigation relies heavily on the TPM. Unauthenticated DH does not solve the problem, unless TPM is present. Steve responds that exporting a key from the inner EAP method ensures that the inner and outer tunnel terminate at the same endpoint. But that's not helpful unless you have a way to ensure that the client isn't just fabricating methods, such as having a separate VM giving accurate information. Joe asks whether TPM needs to be present. Steve says no. Asokan countermeasures have value without the TPM. Nancy asserts that the draft reads as if TPM needs to be present to fully mitigate the Asokan attack. Nancy wants to have a way that mitigation not require TPM as the solution. Paul and Steve both feel that there are additional ways to address the Asokan attack without requiring TPM, based on the ability to prevent fabricated endpoint measurements. Tim Polk states that NEA WG cannot be doing anything that requires anyone to have a TPM. That is out of scope. And solving the lying client problem is not the goal here. However, in systems where there are additional technologies such as TPM, NEA should be able to leverage those solutions. Tim wants NEA to leverage other technologies like TPM in a beneficial manner, but not mandate them. Steve says that someone should write up an Asokan attack mitigation that doesn't rely on TPM. How Protocols Meet NEA Requirements =================================== Paul discussed how PT-TLS meets all applicable NEA requirements, except for 802.1X and IKEv2 requirements. These two requirements are optional (SHOULD) and drove PT-EAP. Paul discussed PT-EAP meets all applicable NEA requirements, except running over TCP. This requirement is optional (SHOULD) and drove PT-TLS. Nancy discussed how EAP-NEA-TLV address all requirements except requirements C-2 and PT-5 (because EAP-NEA-TLV runs over EAP), C-9 and C-10 (because EAP-NEA-TLV doesn't use strings), and PT-3 (but EAP shouldn't be used to carry large amounts of data). Nancy reviewed concerns with PT-EAP. She feels there is a reliance on TPM. Also, it is not an existing open standard. Also, PT-EAP dependences on having an EAP Tunnel Method. Steve responds that PT-EAP does not reply on a TPM. Exporting a key from a EAP method is common security practice. The only reason that TPM has anything to do with it is that NEA without TPM is not secure so there's no reason to bother exporting a key from the method. Steve does feel that there is an opportunity to drive a non-TPM solution, as discussed earlier in the meeting. Steve challenges Nancy's definition of open standard. PT-EAP is a TCG standard. TCG is an open standards group. So PT-EAP should be considered an open standard given that similar efforts like SAML are considered open standards. Yes, PT-EAP requires that there be an EAP Tunnel Method but there are already three of them so that should not be a problem. Nancy said that if we want to get interoperability, we need to agree on a single EAP Tunnel Method. Nancy explained that the way she read the draft led her to believe that TPM was mandatory. She'd like to see what PT-EAP would look like without TPM. Steve responded that it would be good to do that. Steve reviewed his concerns with EAP-NEA-TLV. He said that it doesn't meet requirements C-5 (not an open standard), C-7 (limited to 2^16 bytes), PT-2 (no protection to Asokan attack), PT-3 (no support for fragmentation), and it has a normative reference to EAP-TLV, which is just a -00 independent submission. It will need to go through EMU WG and become a Standards Track RFC before EAP-NEA-TLV can become a Standards Track RFC. Joe responded that the group could spend endless cycles on the definition of open standard. He feels that PT-EAP is not an open standard because TCG's not an open standards organization. On the limited data payload, he asserts that the EAP RFC discourages the use of EAP for bulk data transfer. Nancy responded on PT-2. She asserted that the dependency on EAP tunneled methods address Asokan attack, the lying NAS attack. Steve challenged that solving the lying NAS problem doesn't solve the Asokan attack. Nancy responded that EMU crypto binding can address Asokan attack. Steve says that if a method doesn't export keying material, it can't solve the Asokan attack. Nancy says that the requirement on EAP methods to export keying material was not explained in RFC 5209. It could be added in EAP-NEA-TLV. Steve agreed that EAP-NEA-TLV could be modified to address most of his concerns. Nancy repeated that our layer 2 NEA transport was not supposed to designed for bulk data transfer. Steve McCann agreed that packet sizes should be kept small. Nancy responded to the dependency on a -00 independent submission. She stated that EAP-TLV will be discussed in EMU. It addresses a number of use cases that require transport of arbitrary data. Joe feels that EAP-TLV is a nice way of carrying a variety of data over EAP. Steve feels that creating a dependency on EAP-TLV will cause work in NEA to stall while waiting for EMU to complete work on EAP-TLV. Tim Polk responded that he wants feedback on how fast EMU WG can move with EAP-TLV. It's not entirely new technology and the situation may not be as dire as Steve . It's reasonable to get feedback from them. Tim will ask how fast EMU will run EAP-TLV. Tim commented on the concern about open standards. Tim says that in his own work on federal standards, the group was trying to define what an open standard is. They gave up. Tim will talk to Jari and others about what's a reasonable limitation on the amount of data to be conveyed over EAP. Steve suggested talking to Pasi about the Asokan attack since Pasi was the person who pointed out that attack would apply here. Tim wants to find out how actively this attack is being mounted. Discuss impact on existing supplicants for EAP-based PT ======================================================= This issue was raised at the virtual interim meeting in January. After some research, the conclusion was that either approach (PT-EAP or EAP-NEA-TLV) would impact existing supplicants in largely the same manner. Discuss feedback from ADs re EAP process ======================================== Susan and Steve talked with Tim recently about whether NEA WG needs to wait for EMU WG to agree on an EAP Tunnel Method before we can get an EAP-based PT approved as a Standards Track RFC. Tim's response was that we're not going to serialize this work. Clearly, we'll have greater interoperability when we agree on an EAP Tunnel Method but this group doesn't need to wait. If documents are needed to describe how the EAP-based PT works over particular tunnel methods, those documents can be Informational for now. If NEA takes on EAP-NEA-TLV, Tim feels that EAP-TLV should be taken on by EMU WG and accelerated. The ADs would put pressure on EMU to get that EAP-TLV completed quickly. Tim feels that NEA WG is not being blocked by progress in EMU. Discuss PT proposals ==================== The group now engaged in open discussion of the PT proposals. Paul asked the group whether it feels that PT-TLS is farther along than the EAP-based PT protocols. Several questions were raised in January but they have now all been addressed. Is the WG ready to pick up this PT-TLS as a WG draft? Nancy said that we seem to have agreed that PT-TLS needs to address the Asokan attack. Maybe that should go into a -01 before we pick up that document as a WG document. Paul responded that he would be glad to add wording on that after the document is picked up as a WG draft. Joe questioned whether the WG should even address the Asokan attack if we're not concerned with lying endpoints. Steve said that our charter requires us to not preclude mechanisms that allow the NEA protocols to be used with stronger security protocols. We need to include a few features like crypto bindings to enable those stronger mechanisms. Joe said there may be other ways to enable those stronger mechanisms with the NEA protocols. Steve encouraged him to describe those other ways if he thinks they exist. Consensus Check Questions ========================= Susan explained that we will go through the same consensus check questions that we used at the virtual interim meeting to see if the folks in the room have made progress. Of course, this will need to be verified on the email list. A show of hands was used. Do you support work on TLS-based PT? Yes: about 6 No: 0 Defer: a couple Do you support adoption of PT-TLS as a -00 WG draft? Yes: about 4 No: about 3 Defer: about 2 Do you support work on EAP-based PT? Yes: about 6 No: about 1 Defer: 0 Which should we adopt as EAP-based PT PT-EAP: 3 NEA-TLV: 3 Other: 0 Next Steps ========== Steve stated that there still seems to be some confusion about the Asokan attack. How many believe that we should address the Asokan attack for NEA? Yes: 7 No: 0 Uncertain: 5 How many people feel that the Asokan attack needs to be described further? Yes: several Steve said that seems to indicate that we need to spend some more time explaining and discussing the Asokan attack. Let's take that to the list. Steve asked what needs to be resolved before we can adopt PT-TLS as a WG draft. Joe said the group needs to decide whether we need to address the Asokan attack at all. Steve asked if there are any other issues that need to be resolved before adopting PT-TLS as a WG draft. None were raised. So we need to understand the Asokan attack and decide whether it needs to be addressed. Steve pointed out that we have made progress since the virtual interim meeting. The questions for the AD and the question about supplicant support have both been resolved. Steve asked what needs to be resolved before we can decide which EAP method to adopt. The Asokan attack, maybe? Should we ask how each EAP-based method would address that attack? Steve McCann asked whether there is any chance that both EAP proposals could be combined. Steve M. says that he supports EAP-NEA-TLC because it derives from a generic method for carrying data in EAP. But maybe a compromise would be helpful. No other ideas were raised. Steve Hanna said that our next step seems to be an email discussion of the Asokan attack. Meeting adjourned.