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: Tuesday, Mar 29, 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 Blue Sheets Jabber & Minute scribes Agenda bashing 1305 WG Status 1310 NEA Reference Model 1315 Discuss PT Candidates, Decide On Path Forward http://www.ietf.org/internet-drafts/draft-sangster-nea-pt-tls-02.txt http://www.ietf.org/internet-drafts/draft-cam-winget-eap-tlv-03.txt http://www.ietf.org/internet-drafts/draft-hanna-nea-pt-eap-01.txt 1455 Milestones 1500 Adjourn WG Status ========= Susan Thomson reviewed WG status. PT I-Ds have been updated to take into account the counter-measure to the NEA Asokan attack. There are 3 individual submissions for transport protocols - one proposes TLS based transport, one EAP based and one has models for both. The main objective of this meeting is to review the PT proposals, and decide which approaches should be adopted by the WG. NEA Reference Model ==================== Steve Hanna reviewed the NEA reference model for the benefit of those new to the WG. PT-TLS Review ============== Paul Sangster reviewed the PT-TLS proposal which has been defined in TCG. PT-TLS consists of 3 phases: - TLS Handshake - Version Negotiation - Optional Client authentication (not discussed) - NEA Assessments The message format is based on that of PA-TNC and PB-TNC to support code reuse. It supports vendor extensions, and a message-ID to help with error handling. Steve added that TNC supports legacy protocols, and thus the vendor ID is important for backwards compatibility. Kevin Fall asked a question about the NEA requirement to support UDP. Paul clarified that the requirement was to support TCP or UDP, and that the proposal met the requirement. EAP-TLV and PT-TCP ================== Nancy Winget described both the EAP and TCP proposals together since they are in the same document. The proposed EAP approach is to use TLV/AVP structures to carry PB-TNC messages in deployed EAP tunnel methods. The proposed L3-based approach is to use a TLV to carry NEA in TLS over TCP, and use the SASL framework for client authentication. PT-EAP ====== Steve described the PT-EAP proposal from TCG. In this proposal, EAP is encapsulated in an EAP tunnel method such as PEAP, EAP-TTLS and EAP-FAST. No change is required to the tunnel methods. This method supports chaining with other EAP methods, and can be proxed via RADIUS, and supports fragmentation when needed. Steve listed 9 PT-EAP implementations. Paul added that there is an OpenSEA implementation of PA and PB protocols running over PT-EAP. Also, that there is an implementation of PT-TLS. Kevin asked a question about which fields in the PT-EAP header were EAP-specific, versus specific to PT-EAP. Steve clarified that all fields were specific to PT-EAP. Stefan Winter asked whether either of the EAP proposals would support EAP-TLS, not just EAP tunnel methods. Steve explained that EAP-TLS does not allow for the opportunity to send data. Nancy further explained that if you were to add data to the EAP-TLS method, you would be effectively creating a new EAP tunnel method. Mauricio Sanchez asked whether there was a requirement to support TCG standards. Steve answered that there is no requirement in RFC 5209,but it is desirable for compatibility. Paul added that there was a requirement to select an open standard. Mauricio asked whether this meant that the spec could then not be changed. Steve said that the spec can be changed; the point was to take advantage of implementation experience. Susan said that the next item on the agenda was to evaluate the proposals. The L3 proposals would be compared first followed by the EAP-based proposals. There is a recommended path forward for the L3 proposals, and at the end of the discussion period there will be a consensus check. Evaluation of PT-TLS ==================== Paul described the pros of the PT-TLS approach. Besides being a TCG standard, the advantages are that PT-TLS supported versioning, vendor extensions and error handling. Concerns were expressed that the alternate proposal, PT-TCP, did not satisfy the selection requirement to prefer open standards. Also, that versioning and error handling are not supported. Paul then compared the message formats. Mauricio asked whether the differences in the message formats were just nits. Susan said that there is a recommendation to move forward on a converged proposal and therefore no need to dwell on differences in message formats. Enaluation of PT-TCP ====================== Nancy said that the main difference between the two proposals is that the client authentication is supported through SASL. Consensus Check on Merging PT-TLS and PT-TCP ============================================ Susan said that the recommendation was to merge the two proposals as follows: - Client authentication using SASL framework - Support version handling - Support error handling Susan asked the ADs whether the document could be a -00 WG document when it was published, or whether it needed to be another individual submission. Tim Polk said that assuming consensus was reached on the mailing list, that it could be published as a WG document. Stephen Farrell agreed on the assumption that there would be joint authors on the document. Kevin asked whether support for error handling meant support for Message-ID field or whether other approaches might be acceptable. Paul said that other approaches were possible. Susan asked for a show of hands for merging the documents as described. There was consensus to do so. The consensus will be checked on the mailing list. PT-EAP Evaluation ================== Steve said that there is no agreement on the EAP-based proposals yet. Steve said that the advantages of PT-EAP are that it works with any tunnel method and EAP transport, supports RADIUS proxy, is a TCG standard with deployment experience and security review by several parties, and supports fragmentation. Steve said that the concern with the alternate proposal, EAP-TLV, is that it does not meet the selection criteria of being an open standard, does not support fragmentation, is hard to proxy, and only has one implementation. Joe Salowey argued that proxying in either approach needs work. The main difference between the two is that, in PT-EAP, EAP is an existing attribute. Steve said that any AAA server has the capability for proxying an inner method inside a tunnel method. Joe said that this is not universal behavior, and it is also questionable behavior from a security point of view. Steve agreed that the transport of the posture needs to be secured. Mauricio asked whether proxying is a requirement or a nice to have. Steve said proxying was nice to have. Steve then compared the two proposals pointing out the main difference in the approach is whether an EAP method is used to carry posture information, or whether a TLV or AVP is used. Joe clarified that the reason that there are two encapsulations defined for carrying NEA in the EAP-TLV proposal is because the EAP tunnel methods use different encapsulations. Nancy argued that the main difference is whether to use an EAP method or a TLV. Existing tunnel methods provide a means to pass non- authentication-related data. Posture can be carried in a TLV because it is not authentication and no keys need to be generated. Stefan asked whether PT-EAP requires EAP chaining support from the tunnel method, and whether EAP-TLV treates the posture as an attribute. Steve says yes. Steve said that he agreed with Nancy that the main difference is whether to use an EAP method or TLV, and that otherwise there was not much difference when it came to header formats. He said that there was one other important difference that should be considered though: open standards, implementation experience and security reviews. Susan asked whether the protocol analysis was done prior to or after the change made to address the NEA Asokan attack. Steve said that the protocol has not been reviewed with the new counter-measure in place. Kevin asked what the diffence is between the original TCG proposal and the current proposal. Steve said that there had been WG consensus to use tls-unique extractor data as the counter-measure to the NEA Asokan attack. Evaluation of EAP-TLV: ======================= Nancy reiterated that the main difference is whether the posture data is carried inside an EAP method or TLV. She said a potential security concern of using an EAP method is that it can be carried outside an EAP tunnel method in an unprotected, standalone method. Stephen Farrell asked what the implementation status of EAP-TLV is. Nancy said that Cisco has implemented it, but chose to no longer support it after an acquisition. Consensus Check: ================ Susan asked the WG for a show of hands whether the WG favored adopting the PT-EAP proposal, the EAP-TLV proposal or neither. There was a majority in favor of adopting the PT-EAP proposal, with a minority in favor of the EAP-TLV proposal. One person indicated that he was not in favor of making a decision at this time. Kevin Fall argued, that it seemed that with more time, it would be possible to converge on a common proposal. Tim Polk argued that the decision need not be made today. Steve asked whether anybody had any suggestions about how the difference could be resolved. One person said that it should be evaluated whether security isues raised with the EAP method are a concern. Also, whether the size of posture data that can be carried is a concern. Tim Polk said it might be useful to pull in other EAP experts to see whether there are any other considerations that should be taken into account that might make one a winner over the other. Joe said we should also verify whether EAP chaining works in tunneled methods. Nancy asked about whether the EAP requirements document includes a requirement for EAP chaining. Joe said that it does. From a spec point of view, existing tunnel methods do support EAP chaining, but it is not known whether the implementations do. Joe said that running posture outside an EAP tunnel makes him nervous, and that maybe better security considerations text would help. Kathy Moriarty mentioned that it is better to not leave the choice up to the operator to make security decisions. Paul said that the D-H exchange in the original PT-EAP to defeat the Asokan attack may still be useful. The reason he mentions this is that this would only be an option with an EAP method. Joe argued that this could be done with a TLV-approach as well, and it would be needed in both EAP and L3 transports. Also, the D-H approach in the original approach only worked in the previous approach because the EMA Agent was able to authenticate in the PA tunnel. Susan proposed that the next step be to identify the architectural differences between the EAP-method approach versus the TLV approach (not the specs themselves, but the 2 approaches only), and then bring it back to the WG for a decision. Stephen asked whether the mailing list would have the same opinion as the WG. Susan said she thought yes as the question had been asked about a year ago with the same results. Tim Polk suggested that once the differences are identified, the ADs can also do some x-area review to get early feedback. Stephen Farrell said that it would be best if the approaches were combined, and that both looked sound. Milestones: ============ Susan reviewed the new milestones. Meeting adjourned.