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, Nov 9, 2009 Time: 1740-1940 WG Charter: http://www.ietf.org/html.charters/nea-charter.html WG Tools: http://tools.ietf.org/wg/nea WG email: nea@ietf.org 1740 Administrivia Blue Sheets Jabber & Minute scribes Agenda bashing 1745 WG Status 1750 Review Process for soliciting proposals for PT 1755 NEA Reference Model Review 1800 Review PA-TNC changes http://www.ietf.org/internet-drafts/draft-ietf-nea-pa-tnc-06.txt 1805 Review PB-TNC changes http://www.ietf.org/internet-drafts/draft-ietf-nea-pb-tnc-06.txt 1815 Conceptual overview of Posture Transport protocols 1930 Discuss Proposed Milestone Updates 1940 Adjourn WG Status & Plans ================= Susan Thomson reviewed WG status. Since IETF75, both PA-TNC and PB-TNC I-Ds were updated to address IESG and other Last Call comments. The IESG has approved PA-TNC as a Proposed Standard. The IESG is also ready to approve PB-TNC. However, a few significant changes were made to the PB-TNC protocol. These changes are currently in review in the WG with a call for comments by Nov 16. Assuming the WG agrees with the changes, the IESG will submit the PB- TNC document for publication as Proposed Standard. The IESG has approved changes to the NEA WG charter to move forward on PT protocols. A call for individual submissions has been made that ends Jan 4, 2010. Review of Process for Working on Posture Transport Protocols: ============================================================= Susan also reviewed the process for working on PT protocols. It is the same process as followed for the PA and PB protocols. Individual submissions will be reviewed in the WG after the Jan 4 submission deadline. The WG will then determine the contents of a -00 version of a WG document. Normal IETF process will follow from there. Changes to -05 version of PA-TNC I-D: ===================================== After recapping the NEA reference model for the benefit of those new to the WG, Steve Hanna proceeded to summarize the two sets of changes to the PA-TNC and PB-TNC I-Ds made between IETF 75 and IETF 76. Changes to -05 version of PA-TNC I-D included the following: 1. Removed section on TCG and replaced with acknowledgement 2. Removed PA-TNC field types since not being used anywhere 3. Added language tag to remediation string 4. Removed reference to an I-D that we decided not to go forward with 5. Various minor fixes and clarifications Changes to -06 version of PA-TNC I-D: ===================================== 1. Added text on how PT security protects PA-TNC 2. Relaxed requirement in IANA Considerations for registering vendor- specific values based on IESG and WG input 3. Other minor fixes and clarifications Changes to -05 version of PB-TNC I-D: ===================================== 1. Removed section on TCG and replaced with acknowledgement 2. Tightened up error handling 3. Added a new CLOSE batch type 4. Added PT additional requirements 5. Added language tag for remediation string 6. Changed language tag length to 8 bits 7. Various fixes and clarifications Of the above, the new CLOSE batch type and PT requirements are considered the most significant changes to the PB-TNC draft. Steve elaborated on these two changes and re-iterated that the last call to confirm consensus on these changes is Nov 16. New CLOSE batch type: Steve explained that prior to this change, the way to indicate a fatal error was to include a TLV in a (inappropriate) batch type, i.e. a batch type that would be sent under a non-error condition. There was also no way to close a connection gracefully. Thus, an explicit CLOSE batch type was added to indicate fatal errors and a non-error close. New PT Requirements: In response to comments from one of the Transport ADs, a new section was added to PB-TNC to include additional PT requirements, supplementing those in RFC 5209. Additional requirements include that the protocol must be connection- oriented, be able to carry binary data, and provide mechanisms for flow and congestion control. Also, the PT protocol specifications must describe the capabilities they provide for and limitations they impose on the PB protocol. Changes to -06 version of PB-TNC I-D: ===================================== 1. Relaxed requirement in IANA Considerations for registering vendor- specific values based on IESG and WG input 2. Other minor fixes and clarifications In conclusion, Steve asked the WG whether these changes seemed reasonable. There was no dissent. Conceptual Overview of PT Proposals =================================== Steve presented an overview of two proposals for the PT protocol: 1. A Posture Transport based on EAP (PT-EAP) 2. A Posture Transport based on TLS (PT-TLS) TCG plans to submit two protocols in response to the NEA WG Call for submissions based on the above two transports. Specifications of these protocols are available on the TCG web site, where they are called "IF-T Protocol Bindings for Tunneled EAP Methods" and "IF-T Binding to TLS". PT-EAP: Steve explained that the use case for PT-EAP was to allow posture to be considered in a network access control decision e.g. 802.1x and IKEv2, while supporting isolation of endpoints for remediation, and quarantining or blocking of non-compliant endpoints. The proposed protocol is designed to run as an inner EAP method which can be chained with authentication and other inner methods within a tunneled method such as EAP-TTLS, PEAP or EAP-FAST. PT-EAP supports 3 phases: 1. Optional Diffie-Helmann pre-negotiation to establish an initial key 2. Posture assessment hashed into eventual key 3. Key derivation and export The above provides the option to cryptographically bind the PT-EAP exchange to the outer tunnel, assuming the tunneled method supports this. One limitation of EAP is that it cannot support posture policies that require the transfer of large amounts of data, e.g. examining all hotfixes on a machine. This is because only one packet can be in flight at a time. Other characteristics include that it is half-duplex, supports simple congestion control, and is extensible. Steve said there are some open-source and commercial implementations of the TCG protocol. Yaron Schaffer asked whether the rule of one packet in flight applied even when fragmentation is in use. Steve explained that this was the case. Tim Polk added that EAP is a very simple lock-step protocol. Only one packet is in flight at a time. Steve said that this is the reason why EAP should not be used for large data transfers. Use PT-TLS instead. PT-TLS: Use cases for a TLS-based transport include networks where posture policies require large amounts of data to be transferred, where monitoring of posture compliance rather than enforcement is desired, or for more detailed assessment or re-assessment after an endpoint has been granted access to the network. Another use case may be an application server that requires both authentication and posture compliance for use of a service. The proposed protocol is designed to carry posture as application data. No changes to TLS are required. There are 3 phases to PT-TLS: 1. TLS Handshake (unmodified) 2. Pre-Negotiation including version negotiation and optional user authentication 3. Data Transport for posture assessment Steve said that the proposed protocol meets the PT requirements. The #1 feature is that the protocol leverages the full capabilities of TLS and does not reinvent the wheel. Features of a TLS-based protocol include the fact that it has established security support (latest discovered security flaw notwithstanding), is full-duplex and hence allows server-triggered re-assessment, supports posture policy with higher bandwidth requirements, is easy to implement using available TLS libraries, and is extensible. Steve asked whether people have issues with having two proposed standards-track protocols, rather than one. Tim said that, while he normally prefers one standards-track protocol, in this particular environment, the use cases are different enough that 2 standards-track protocols are warranted. He would be prepared to support both. Steve said that the tricky part is going to be to define which protocols are mandatory to implement. One does not want to be in a situation where a NEA client supports one standard, and a NEA server the other. People need to think more about this, but one option is to specify that both are mandatory to implement. Tim agreed that this requires careful thought. He suggested that the option of having the NEA server support both (versus the client) may indeed be the way to go. Proposed Milestone Update: ========================== Susan proposed an update to the current milestones. Because of the delay in updating the charter to start work on PT, the dates associated with the milestones in the current charter need to be extended by roughly the timeframe of one IETF. The intent is still to hold a virtual interim meeting in January to expedite progress. There was some discussion about the rules for conducting such a meeting. Tim said that his recollection was that a 30-day notice is required, and that AD approval is needed in writing before sending an announcement. There is an IESG statement on the topic that should be read prior to arranging the meeting. A virtual interim meeting cannot be held instead of a regular IETF face-to-face meeting; it is intended to be in addition to existing meetings. [Editorial Note: On reviewing the IESG statement after the meeting, the rules Tim mentioned above are for face-to-face interim meetings. For interim meetings that are conducted via conference call, the rules are relaxed somewhat, e.g. a 2-week versus 30-day notice period is required.] The goal of the virtual meeting is to get consensus on the content of the -00 WG drafts. Steve pointed out that, as with any meeting, consensus will be confirmed on the mailing list. Meeting adjourned.