These notes do not attempt to duplicate the content of the slides. Instead, they summarize the material presented, and focus on comments and discussion. Notes taken by Mauricio Sanchez and Kent Landfield Agenda ====== Date: Wednesday, July 27, 2011 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 NEA Reference Model 1315 Discuss and Resolve Open PT-TLS Comments draft-ietf-nea-pt-tls-00.txt 1400 Discuss and Resolve EAP vs. TLVs for L2 PT draft-cam-winget-eap-tlv-03.txt draft-hanna-nea-pt-eap-01.txt 1500 Adjourn WG Status ========= Susan Thomson reviewed WG status. We now have a WG draft for the TLS-based transport. Please review and comment. Plan to do a WGLC on this soon. For the EAP-based transport, we have two competing proposals with no agreement yet. Today, we'll discuss the key differences between the proposals as agreed by the proponents. Maybe that will help us get WG consensus. If not, we have agreed that our AD will decide. NEA Reference Model ==================== Steve Hanna reviewed the NEA reference model for the benefit of those new to the WG. Discuss and Resolve Open PT-TLS Comments ======================================== Paul Sangster described the latest PT-TLS specification, draft-ietf-nea-pt-tls-00.txt. The main new change is the addition of messages to carry SASL authentication. Paul asked several questions: 1) The SASL TLVs are mandatory to implement and optional to use. Is that OK? Nobody in the room objected. 2) The PLAIN and External SASL Mechanisms are mandatory to implement. Is that OK? Do we need any other mechanisms? We could include some as a SHOULD or a MAY. Paul pointed out that other commonly used SASL mechanisms include Kerberos or GS2, which supports certificate-based client authentication. Mike Boyle said that it would be extremely desirable to be able to do both user and device authentication using certificates, at least for certain circumstances. Paul suggested saying that if your implementation is intended to be used in environments where it's desirable to do both user and device authentication using certificates, then you SHOULD support GS2. Trevor Freeman pointed out that this is a tunneled authentication protocol but there's no channel binding. Paul described how the draft calls for TLS-Unique to be used to bind the TLS session to an External Measurement Agent like a TPM. Trevor said that when you use the Kerberos SASL mechanism, you must make the client prove possession of the shared secret. Paul said this could be done by hashing TLS-Unique with the Kerberos secret and having the TPM sign that hash. Joe Salowey asked whether the kitten WG has defined a way to do channel binding with SASL. Shawn Emery said they have with GS2. He's not sure if it will work for all mechanisms. Klaas Wierenga suggested supporting SCRAM since that supports channel bindings. Joe said GS2 is probably more useful for our use cases. Klaas said GS2 has lot of other benefits. Paul asked whether we should make GS2 a SHOULD. Shawn said yes. Joe said the important thing is to talk about channel bindings and how to do them with SASL. We can make it a MAY, as long as we explain how to do it. Paul agreed that he'll make GS2 a MAY and talk to the kitten folks about channel bindings so that we can explain how to do that properly. Paul said the next step is to publish a -01 draft (preferably in August) and then do a WGLC. We'll discuss any substantial comments from WGLC at IETF 82. Stephen Farrell asked about trust anchor storage. Will we have any guidance on that? Paul said that we don't know. Stephen said that we should so that people know not to just use the operating system's list of trust anchors. Discuss and Resolve EAP vs. TLVs for L2 PT ========================================== Steve Hanna and Nancy Cam-Winget came to the front and gave a joint presentation on the key differences between the two competing proposals: PT-EAP and EAP-TLV. The presentation was only one slide but after each line on the slide there was discussion of that line. Here is a summary of the discussion. However, this cannot do justice to all the details given in the full discussion. For that, listen to the audio recording. Encapsulation: Steve favors using an EAP method to carry NEA messages. Nancy favors using a general container approach that can ride across many transports (including EAP). We are not really doing authentication, architecturally. Proxy: Steve favors usage of EAP because facilitates proxy behavior, specifically the ability to proxy NEA exchanges beyond the end of the EAP tunnel method. Nancy feels the EAP framework is too tied to the authentication process/RADIUS too much. Should be about NEA client/server framework, not a AAA framework. Also, security of EAP-TNC not guaranteed. Nancy: Could have strong language in draft requiring strong protection for the NEA exchange. Joe: Sees proxying as not a useful feature. Spent a lot of time over 10 years moving away from insecure EAP methods. EAP-TNC introduces special cases to keep it secure. Steve: Proxying is clearly valued by some people. Stefan Winter recently emailed the NEA list, saying that proxying should have been included in the original NEA requirements. Clearly, any such proxying would need to be protected. Regardless of approach, our draft should mandate that the NEA exchange be strongly protected at all times. Joe: Feels that TLV approach allows security to be built into the design easier. Klaas: Thinks ability to proxy is very important. Can't assume trust relationship between client and server. Example is eduroam. Stefan Winter (via Jabber): Yes, proxying is a desirable property. But it's important to be able to blend together the result of the authentication with the NEA exchange. Joe: Proxying can mean different things. Proxying entire conversation can be done with either approach. Proxying components of the conversation does lead to a different capability. Implementations: Nancy: The EAP-TLV approach is based on several existing working models. Microsoft SoH uses a TLV approach. Steve Hanna: PT-EAP is equivalent to EAP-TNC, which is a TCG spec that is 5 years old and has 9 independent implementations. There have been many security reviews and several papers written on EAP-TNC also. If we're talking about architecturally similar implementations (like SOH is to EAP-TLV), there are several proprietary implementations that use an EAP approach. Stephen Farrell: Asks about deployments of TCG specification. Steve H: Millions of users, however unclear how many are leveraging a close variant of EAP-TNC. Of course, the latest NEA transport drafts added TLS-Unique for use with hardware-based health checks. But nobody does that anyway, at least now. Nancy: Reiterated whether group really wants to promote what is an insecure EAP (EAP-PT). Steve responds that authentication could be added to our L2 PT if need be, but it was not a requirement since the EAP tunnel method handles that. EAP-TLV also has no built-in security. Architecture: Nancy: EAP-TLV uses a TLV transport since transport is the goal, not authentication. Using EAP for a non-authentication purpose causes problems. Steve H: As we saw in a discussion on the list recently, most EAP implementations today (like Windows 7) have a pluggable architecture for adding new EAP methods but not for adding new TLVs. Nancy retorts that it's exactly that pluggable architecture that highlights the opportunity to run PT-EAP unprotected. Nancy asks whether EAP tunnel methods handle multiple inner methods or whether they handle it consistently. Main point is that software upgrades will need to be done with either method. Joe S.: One additional concern between authentication vs. non-authentication is that the EAP RFCs define quantities that an EAP method should define, like peer ID and server ID. While you can operate without those, on the server side the lack of that information is problematic because it doesn't know what it should do if it needs to make authorization decisions. We may be able to special case, but all with additional complexity. Authentication/NEA sequencing: Steve: EAP-TLV can run the NEA handshake in parallel with an EAP authentication. PT-EAP can't. There are some good reasons to do authentication in parallel with NEA handshake, but that can also introduce some undesirable traits. Some orgs want authz first then NEA, others reverse. Nancy: Early on identified need to do both serial and parallel approaches. Steve: EAP-TLV draft not entirely clear how serial and parallel should be done. Nancy: This can be cleaned up in future drafts. Key export: Steve: We used key export early on, before we decided to move to TLS-Unique. Very useful for binding the inner and outer EAP methods. At this point, value of being able to do key export is not as clear. Nancy: Design goal for EAP-TLV is just for a transport and not authentication. Moreover, key export capabilities in PT-EAP are suspect in security. Joe: Worried that design of key export in PT-EAP is fragile. Steve: Actually, key export was dropped from most recent draft of PT-EAP. Could be added back in but it's not in there now. Standards: Nancy: EAP-TLV is a new proposal. Steve: One of the requirements in the NEA Reference Model is that we have to prefer existing open standards. PT-EAP is definitely a standard. Whether you consider it open or not depends on your definition of open standards. It's available for free from the TCG web site and has been for five years. The I-D has been contributed to the IETF Trust so at this point it's up to IETF to decide what to do with it. Susan did a consensus check. Prefer PT-EAP? 6 in favor Prefer NEA-TLV approach? 6 in favor Neither? 0 prefer neither Next Steps: Stephen Farrell (AD) discussed next steps given result. Stephen will be gathering opinions over the week online and offline. He will be thinking about it over next several weeks and make decision by the end of August. Then he'll post his decision to the NEA list. Steve H. asked for consensus check on process of having AD choose between PT-EAP and EAP-TLV. More than 12 people are OK with AD choose. Nobody is against. Nancy asked if we need to have a formal consensus check on process on the email list since WG chairs and ADs can make process decisions. Agreed that there's no need to have do a formal consensus check on that. However, we will do a formal consensus check on PT-EAP vs. EAP-TLV (2 weeks on the list) and we'll warn people that if that consensus check fails to produce a consensus, our AD will decide. Milestones ========== Susan went through a new set of proposed milestones, as listed on the slides. There were no questions or comments. Meeting adjourned.